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

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

On Fri, 2007-09-14 at 14:49 -0500, Anthony Liguori wrote:
> 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.

I don't know what the upstream plans are.  It will require some phasing
to get tools in sync with our product releases and into vendors hands.

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

Okay, that is worth noting, nice to sponsor the design, but I'm not sure
we want any extra churn or destabilization of our drivers.  Bugs happen,
and driver bugs happen a lot.  Paravirt bugs happen a lot more as well -
the complexity of the system has been increased.  It seems like virtio
unnecessarily exposes us to risk, when our standalone network driver
module has a very much lower change rate.  We've gone on and evolved our
network driver much farther (started long before virtio), and maybe the
next version of it might fit in with virtio, but I think the vmxnet
driver as is will be pretty much frozen in stone in any relevant time
frame.  It's not worth rewriting the driver and increasing the
maintenance burden of what will eventually become legacy.


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

We have an LSIlogic and a BusLogic SCSI controller.  And a PIIX4 IDE
controler.  Very little point trying to make those work under virtio.

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

My point is, there is nothing inherently to do with paravirt about that.
I consider it a device driver interface prettying, not a paravirt
specific thing.  So I think calling it virtio is somewhat misguided.
Lots of device drivers of the same type and roughly the same function
could share a library of roughly equivalent code.  That is where I see
this eventually going, and it looks like a gargantuan task of rewriting
a bunch of drivers to have cool, clean, modular interfaces with a shared
device library.  It's a valuable cleanup and it might eventually reduce
the overall number of bugs in the greater driver code base.  But it
doesn't actually accomplish anything spectacular for virtualization.


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

The same applies to hardware busses or architectures.  It's basically
modularizing a couple of driver classes to be cleaner and have transport
independent interfaces.  It's like writing a nice hardware free network
driver that has a bunch of plugins to do the actual work, so the high
level can focus on proper algorithms, hot-plug, discovery and all that.
Exactly how a well thought out native driver should be designed.

So if virtio gets it right, don't you see actual hardware drivers using
virtio starting to arrive in the future?  I would argue that is a good
thing; but I would also argue it's a huge time-sink and it will probably
not converge anytime soon.  That makes it hard to justify converting our
legacy drivers to virtio.

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

It's much harder to take existing drivers and mold them to virtio than
the other way around.  I expect we will keep virtio in mind as we work
on new drivers though.  I need to brush up on the PCI aspects of
detection to make sure it would work for us - we need to selectively
bridge individual native PCI devices to virtio drivers.  If that can
work, there is nothing to stop us from moving new devices to virtio.

Such a thing might actually be costly, however.  Virtio isn't in older
kernels, and some new devices might be important to add to older
kernels.  Until the broad Linux base has virtio support, we might need
to maintain drivers which work with both virtio and non-virtio kernels.
Obviously the right answer is, "Use a newer kernel, knucklehead!".  But
That's a marketing cost basis decision that I have nothing to do with.
Fortunately, as time progresses and older distros get phased out, the
decision becomes easier.

Thanks for the feedback,

Zach