This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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