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