| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] disable qemu PCI devices in HVM domains
>
> James Harper writes ("RE: [Xen-devel] disable qemu PCI devices in HVM
> domains"):
> > Basically, I use ioports 0x10-0x1F for communication.
>
> You seem to mean thedse absolute addresses in IO space ? Rather than
> offsets in the Xen platform device, for example ?
Yes. Under the current scheme I need to disable the other PCI devices
before the platform pci device is enumerated.
> And your driver is
> going to write, blind, into these locations ?
No. A read is done first to check for some magic bytes.
> Surely that risks
> causing problems if your driver is run in a situation where those
> ports are used for something else ?
Perhaps, but under Xen+qemu we have a tightly controlled situation where
that is unlikely, I would have thought. Perhaps you have a situation in
mind where this would be a problem? Would a passed-through pci device
ever try and use these ports? If I had allocated them in qemu then
wouldn't pci passthrough avoid them?
> 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.
>
> And presumably the instrunction to do so should be given via the Xen
> PCI platform device ?
>
Possibly. A hot unplug could work too, but it would need to happen after
windows had enumerated all the pci devices (if done from platform pci)
but before windows had enumerated and started using the ide devices.
Remember that windows is closed source and therefore is a huge pita when
trying to do something they hadn't thought of, like make something
happen at a very specific point during boot.
> Also, what if the user wants (for some reason) to use PV drivers for
> disk but emulated-real-hardware drivers for network, or something ?
I could allow for that - just set up the disable flag as masks instead.
The previous 'xenhide' windows driver scheme allowed that, but it was
seldom used. With the exception of a user trying to avoid a bug in the
PV drivers (in which case time would be better spent fixing the bug than
implementing a mechanism to avoid it) the only time it would be useful
is for when a CDROM is used - blkback doesn't have a mechanism for
ejecting physical CDROM devices. Unfortunately the latter would be even
harder as the CDROM is not a PCI device itself, and at the PCI device
level we don't know what is going to be attached...
James
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home