Re: [PATCH 2/6] virtio_config

[Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>]

On Thu, 2007-09-20 at 14:55 +0200, Avi Kivity wrote:
> Avi Kivity wrote:
> > Rusty Russell wrote:
> >> Previous versions of virtio didn't commonalize probing.  For every
> >> driver, every virtio implementation (KVM, lguest, etc) needed an
> >> in-kernel stub to join their bus to the probe code.
> >>
> >> To solve this, we introduce a "virtio_config" mechanism, which is
> >> simply a set of [u8 type][u8 len][...data...] fields for each device.
> >> Some convenient wrapper functions make this fairly easy for drivers to
> >> unpack their configuration data themselves.
> >>
> >> This configuration data could be PCI config space, or an unrelated bus
> >> (eg. lguest) or manufactured by the kernel itself.  It's designed to
> >> be extensible: fields get marked as the device reads them so a host
> >> supporting some future extension can tell if the guest driver
> >> understood it.  This also applies to bitfields: the guest explicitly
> >> acks the bits it understands.
> >>
> >> There's also a simple status bitmask useful for low-level host
> >> analysis of what the guest is doing with the device.
> >>
> >>   
> >
> > Lovely.
> >
> 
> A side effect of this is that Xen drivers can no longer use virtio.

I'm not so sure.

We were always assuming that Xen could do state management in its virtio
layer.  If this is not true, it implies we need hooks in the virtio
drivers, and I don't think we've made it worse by making it translate
xenbus config info into virtio_config.

Rusty.


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