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

[Anthony L. <an...@co...>]

Zachary Amsden wrote:
> 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.
>   

There are two questions I think.  The first is whether you should invest
in switching your current drivers over to virtio.  This would be useful
if you were looking to get something upstream as I don't think your
drivers are dramatically different than what the virtio ones would look
like.

The second question is whether you're interested in virtio for things
that you currently don't support.  Since ya'll were talking about
switching the drivers away from the current backdoor stuff, it seemed
like that would be a good time to perhaps shim in virtio.  Keep in mind,
there doesn't have to be only one virtio network driver.  The advantage
of virtio is if you guys port your driver over to virtio, other
hypervisors can potentially (easily) make use of it.

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

Rusty's current virtio block device provides SCSI pass through so things
like CD/DVD control commands work.  It's more sophisticated than the Xen
driver in that regard.  But I thought you guys don't use a paravirt
block driver?  I'm much less convinced that a paravirt block device
offers a lot of advantages over SCSI emulation (but it exists b/c lguest
doesn't want to do any emulation).

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

I really don't see it that way.  virtio as an abstraction makes sense
from two perspectives.  If you start with the assumption that most
paravirt device drivers of the same type (and roughly the same function)
are going have a bunch of roughly equivalent code, then virtio makes
sense as a way for those various drivers to share that common code.

If you start with the assumption that most VMMs end up using roughly the
same sort of transport for all drivers, and that all those transports
have roughly the same properties, then virtio is a very nice way to
abstract that hypervisor interface so people can just target it and
largely avoid having to implement the same driver for N different VMMs.

But you guys have to do whatever makes sense for you.  virtio is
certainly not a solution for everything.

Regards,

Anthony Liguori

> Zach
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> open-vm-tools-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel
>
>