Re: [open-vm-tools-devel] FW: VMTools for other OSes

[Anthony L. <ali...@us...>]

Zachary Amsden wrote:
> Actually, virtio does not look to be very useful for VMware.  We don't
> have truly paravirtual devices.  We have devices that function almost
> exactly and present exactly as real hardware devices.  As such, we have
> none of the problems that virtio intends to solve - device discovery,
> hotplug and enumeration are already handled by the platform for USB,
> SCSI, IDE, or PCI, depending on how we present the device.
>   

Hey Zach,

Actually, I think you're making a bad assumption here.  virtio does not 
mandate how discover happens.  It's only interested in the transport 
protocol of the PV device (not the actual mechanism of transport).  For 
KVM, the current direction is to actually implement virtio on top of a 
PCI device.  The current implementation uses PCI for discovery but is 
using hypercalls mainly to avoid the fact that PCI interrupts require 
acking.  I think this is something we may just end up biting though such 
that virtio devices wouldn't even use hypercalls.

> 1) The likelihood of us having paravirt-only devices that present on
> non-hardware busses is near zero in I would guess the next 5 years.  It
> seemse unlikely we would ever use a non-hardware bus interface unless it
> was adopted as a common cross-platform standard for virtualization.
>   

I am not interested in non-hardware busses.  I think there's pretty wide 
agreement (with the exception of the s390 folks) that PCI is the way to go.

> 2) We don't have any new discovery / configuration / enumeration
> problems that are specific to virtual devices on new busses.
>
> 3) Our devices are more complex than the current virtio models can
> support, meaning we lose functionality (CD / DVD control commands
> reduced to generic block device, etc..); and we also have to reimplement
> an ATA or SCSI like layer underneath virtio, which is wasteful in terms
> of code and performance.
>
> 4) Presenting our virtual devices differently to different kernels leads
> to either VM configuration problems (where user must choose PCI vs
> virtio, then is stuck with potentially unusuable kernels), or exposes
> the virtio layer to the problem of separating and cherry-picking devices
> out of PCI, USB, ... spaces to connect through virt-io transports.  So
> we would either complicate the virtio code, or subvert PCI and USB
> detection through nefarious and ugly hacks.
>
> 5) We're exposed to more code churn (at least initially) in the virtio
> layer than the maintenance effort we have maintaining our existing
> drivers, presenting greater bug risk to us.
>
> It's not that virtio is a bad thing if you have true, virtual-only
> busses and devices, it's just this layer is totally unnecessary for us
> and it doesn't seem like anyone would benefit from us going down that
> route for any of our existing drivers.  It might, perhaps, make sense
> for VHCI, but that remains to be seen.
>   

I don't think you should just drop your current drivers.  However, I 
suspect that it would be more fruitful to focus on getting the virtio 
drivers up to your standards instead of attempting to get your existing 
upstream (if that is at all a goal).  I think a lot of your concerns are 
valid for any VMM so participating in this area would be generally helpful.

Regards,

Anthony Liguori

> Zach
>
>