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

[Zachary A. <za...@vm...>]

> > 2) The current thinking in the kernel community is that we'll converge
> > on virtio based paravirtual devices.  I haven't looked at the VMware
> > transports deeply enough to know yet whether they would fit 
> > nicely into
> > the virtio model but my suspicion is that they could.  Is 
> > there interest
> > in this?

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.

We also have devices that present much more complex abstractions than
the virtio layer is prepared to deal with.  If we were to write a virtio
block device backend today, it would take virtio requests, convert them
into SCSI SCBs, and then issue them to our virtual SCSI card.  That
makes no sense.

Virtio also complicates things quite a bit for us - now we have devices
which present as virt-io devices on virt-io kernels, and as PCI devices
elsewhere (perhaps they may present differently even on the same kernel,
configured differently).

I don't understand why we should go and rewrite our device code to use
virtio because I don't see any tangible benefit for anyone in that
endeavor.  I see:

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.

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.

Zach