| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home