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

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

On Thu, 2007-09-13 at 21:54 -0500, Anthony Liguori wrote:

> 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.

Okay, so how does virtio help at all?  I guess I am missing the primary
motivation for why it is a good thing.


> > 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.

Wouldn't we still need to add code to emulate these layers beneath
virtio if that is in fact how our virtual devices interact?  This is the
primary reason I see virtio as being unproductive for VMware.

> 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.

Looking at the problem from a high level, with the assumption of keeping
our current driver models, this seems to state that the best thing to do
is adapt virtio into a layer that can meet the goals of all SCSI and
IDE / CD / DVD / USB devices.

But the problem is that Linux already has great layers of code to do
that.  Why are we re-inventing the wheel and encapsulating all this
beneath another layer of interface when the real interfaces we want
already exist?

If we want a cleaner driver model that separates architecture and
communication tranports from the driver implementation, shouldn't we be
doing that at a higher level - one that actually has nothing at all to
do with virtualization?

Zach