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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 7 Feb 2006, at 14:37, Ryan wrote:

> 2) arch/i386/pci/i386-xen.c needed to return. Calling
> pci_assign_unassigned_resources in a driver domain with the PCI 
> frontend
> fails. The PCI backend restricts writing to the configuration space (it
> would be dangerous if we let the driver domain change the resource
> allocations in the BARs, see drivers/xen/pciback/conf_space_header.c 
> for
> how this is done). When pci_assign_unassigned_resources tries to update
> the BARs, it will fail (and then the struct pci_dev's resources will 
> not
> reflect the real resources of the devices and things just won't work).
> To fix this problem, I added a #ifdef around the call to
> pci_assign_unassigned_resources in i386-xen.c so that it only works if
> the PCI frontend is not compiled in. However, I'm not certain that this
> is the best solution so please let me know if you can think of a better
> way.
Isn't absence of PCI_ASSIGN_ROMS supposed to mean that the OS tries to 
use the existing resource allocations? So, unless someone says 
'pci=rom' as a boot parameter I would have hoped that things would just 
work and the OS would not try shuffling resources around. If it is 
shuffling things, that's a bit worrying.
In any case, it is important that we continue to be able to build a 
single kernel image that works as both dom0 and domU. This means that 
you need to support both direct PCI access and virtualised PCI access 
*in the same kernel build*. Compile-time ifdef's are right out: worst 
case you'll have to test at runtime whether or not you are dom0.
Perhaps this restriction will make it easier to pick between the raw-op 
and non-raw-op virtualised pci access methods? :-)
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel