RE: [Xen-devel] disable qemu PCI devices in HVM domains

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

> > I'm not sure if the approach taken by the Citrix drivers could be at
all
> > useful. Cc'ing Steven Smith in case he has any comments to make.
> I can't see any reason why the approach we take in our closed-source
> drivers wouldn't work here as well.  I've attached the appropriate
> patches from our product qemu patchqueue, tidied up and stripped of
> the most obviously XenServer-specific bits, and made to apply to
> current ioemu-remote.
> 
> 
> The protocol covers three basic things:
> 
> -- Disconnecting emulated devices.
> -- Getting log messages out of the drivers and into dom0.
> -- Allowing dom0 to block the loading of specific drivers.  This is
>    intended as a backwards-compatibility thing: if we discover a bug
>    in some old version of the drivers, then rather than working around
>    it in Xen, we have the option of just making those drivers fall
>    back to emulated mode.
> 
> The current protocol works like this (from the point of view of
> drivers):
> 
> 1) When the drivers first come up, they check whether the unplug logic
>    is available by reading a two-byte magic number from IO port 0x10.
>    These should be 0x49d2.  If the magic number doesn't match, the
>    drivers don't do anything.
> 
> 2) The drivers read a one-byte protocol version from IO port 0x12.  If
>    this is 0, skip to 6.
> 
> 3) The drivers write a two-byte product number to IO port 0x12.  At
>    the moment, the only drivers using this protocol are our
>    closed-source ones, which use product number 1.
> 
> 4) The drivers write a four-byte build number to IO port 0x10.
> 
> 5) The drivers check the magic number by reading two bytes from 0x10
>    again.  If it's changed from 0x49d2, the drivers are blacklisted
>    and should not load.
> 
> 6) The drivers write a two-byte bitmask of devices to unplug to IO
>    port 0x10.  The defined fields are:
> 
>    1 -- All IDE disks (not including CD drives)
>    2 -- All emulated NICs
>    4 -- All IDE disks except for the primary master (not including CD
>       drives)

Interesting. This seems more flexible than my initial approach which was
to block just the PCI devices. I guess it makes sense to leave the qemu
CDROM's as they support the eject etc functionality, and performance is
seldom such a problem.

>    The relevant emulated devices then disappear from the relevant
>    buses.  For most guest operating systems, you want to do this
>    before device enumeration happens.
> 
> ...) Once the drivers have checked the magic number (and the
>      blacklist, if appropriate), they can send log messages to qemu
>      which will be logged to wherever qemu's logs go
>      (/var/log/xen/qemu-dm.log on normal Xen, dom0 syslog on
>      XenServer).  These messages are written to IO port 0x12 a byte at
>      a time, and are terminated by newlines.  There's a fairly
>      aggressive rate limiter on these messages, so they shouldn't be
>      used for anything even vaguely high-volume, but they're rather
>      useful for debugging and support.
> 
> This isn't exactly a pretty protocol, but it does solve the problem.
> 
> 
> The blacklist is, from qemu's point of view, handled mostly through
> xenstore.  A driver version is considered to be blacklisted if
> /mh/driver-blacklist/{product_name}/{build_number} exists and is
> readable, where {build_number} is the build number from step 4 as a
> decimal number.  {product_name} is a string corresponding to the
> product number in step 3; at present, the only product number is 1,
> which has a product_name of xensource-windows.
> 
> 
> A previous version of the protocol put the IO ports on the PCI
> platform device.  Unfortunately, that makes it difficult to get at
> them before PCI bus enumeration happens, which complicates removal of
> the emulated NICs.  It is possible to work around these but (at least
> on Windows) it's complicated and messy, and generally best avoided.

I found that too :)

It's a bit more complicated than I would have preferred, but I think
there is value in keeping the tree's in sync rather than re-implementing
things.

As a result of this patch, does that mean that the Citrix Windows PV
drivers might work on the GPL tree? Is that a problem?

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel