[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |