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


 


Rackspace

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