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

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

> > >> I like the principle of disabling the drivers via an instruction
to
> > >> qemu rather than by attempting to wrestle with the Windows driver
> > >> machinery to try to hide the devices.  But couldn't we simulate a
PCI
> > >> unplug or a medium change or something instead ?  Then you could
do
> it
> > >> later in the boot after your own drivers have properly bound.
> > >>
> > >
> > > Is the 'pci unplug' as simple as making a call somewhere like
> > > pci_unplug(id of ide adapter)? I'm concerned that Windows may not
like
> > > this.
> > My own opinion is that the ioports are fine, but they should be
offsets
> from
> > the xen-platform-pci device's ioport bar. Also we ought to document
the
> > ports in xen-platform-pci's source file, as it's going to start
getting
> > messy in there.
> >
> > 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.
> 
> 
> 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.

It appears that you set it to '0xd249' when the driver is blacklisted.
Can I rely on that?

My logging code runs independently in a number of unrelated places, and
may not be called for some of those places until after the blacklist
process has occurred. So testing for == 0x49d2 || == 0xd249 would tell
me if the backend supported logging.

James

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