[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH][2/4] PCI Driver Domains: PCI Backend/Frontend
On 7 Feb 2006, at 15:59, Ryan wrote: Perhaps this restriction will make it easier to pick between the raw-opand non-raw-op virtualised pci access methods? :-)Sorry, I misunderstood you the first time I read your statement above.Yes, I think the restriction of having one domain compile for both -dom0and -domU will make the decision for us as the non-raw-op version (the arch-independent version) actually replaces the native PCI code. If we have to get 'grubby' and do the raw-op version and modify arch-dep pci code, perhaps it makes sense to gate pci_assign_unassigned_resources on a global am-i-virtual flag. I expect we would add the virtual access ops as a fall-back pci access method (preferring direct hardware access if possible CONF1/CONF2/MMCONF etc). If we do fall back then we set the global flag and gate certain things. It certainly would be better to not need to gate things at all -- but clearly calling pci_assign_unassigned_resources can never help things in a virtualized-pci guest. :-) Will you be working support for dual-mode pci access support into your patches? I'd probably check them in now except for this current limitation. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |