[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] disable qemu PCI devices in HVM domains
> > 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |