[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> On 11/12/2008 03:10, "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
wrote:
> 
> > So if the PV drivers loaded early in the boot process, they would
write
> > to a designated IO port and qemu would then tell the PCI devices to
not
> > work anymore. Because I would do it at the driver level rather than
at
> > the device level, it should happen even before windows has loaded
the
> > pci.sys driver and started probing the PCI space.
> >
> > Does that sound acceptable?
> 
> It sounds good in principle. Do you know how you would hack it into
qemu?
> Ian Jackson may have views on that.
> 

The attached patch is what I have developed so far. There is also a
logging facility in there too - XenSource has something similar but mine
is better :) (with the exception of rate limiting, which mine doesn't do
yet)

Basically, I use ioports 0x10-0x1F for communication. Reads to 0x10-0x12
return 'X', 'E', and 'N' respectively. 0x13 returns a version number.
This is to allow to detection of the mechanism (otherwise I have to
fallback to the previous method of disabling the ide and network drivers
in windows, which is unreliable and messy and the WHQL guys will laugh
at me :)

Writes to ports 0x10-0x17 records data in logging buffers (1 per port),
printing on a newline. I wanted to be able to have a method of logging
that relied on the barest minimum of overhead. Synchronising access to
an ioport across multiple windows drivers would require setup and I
needed to be able to log before that setup. So what I do is raise the
IRQL to HIGH_LEVEL (disabling interrupts) and then write to port
0x10+cpu. Without that I was getting log messages mixed up with each
other during high rates of logging, where I was looking for races etc.
This way it's clean and I even get to know what the CPU doing the
logging is. It's only really useful for debugging so I think the
performance hit is acceptable. If you don't want to include that part of
it then that's fine.

A write to port 0x18 with a non-zero value will set the global variable
xen_pci_disable_devices. A write of 0 will unset it, but I'm not sure
where that would be useful.

I have added a disable_flag variable to the pci dev structure. This is
set to 1 for devices that should be disabled when PV drivers are in use
(ide and rtl8139, possibly others?).

In pci_data_read, if xen_pci_disable_devices and pci_dev->disable_flag
are both set, all 1's are returned as per when no device is there at
all. If this is done before windows loads pci.sys and scans for devices,
it's as if the device isn't there.

Let me know what you think.

James

Attachment: qemu-pci-disable.patch
Description: qemu-pci-disable.patch

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.