[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-op
and 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 -dom0
and -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



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