Re: [Xen-devel] [PATCH][2/4] PCI Driver Domains: PCI Backend/Frontend

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel