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

[Ryan <hap9@xxxxxxxxxxxxxx>]

On Tue, 2006-02-07 at 15:19 +0000, Keir Fraser wrote:
> 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.

There was a change somewhere between 2.6.12 and 2.6.15 (I can't remember
exactly where now) where Linux now tries to reassign resources that it
detects as unassigned. I think the behavior that you reference used to
be true, but is different now. See pcibios_assign_resources in
arch/i386/pci/i386.c.

It is strange that it tries to shuffle things... I can't seem to track
down in the source the exact conditions under which Linux tries to
reassign the BARs and doesn't just use what the BIOS/Backend provided.
pci_assign_unassigned_resources was never called in 2.6.12 (at least not
on x86) so it was not an issue before. If someone else is more familiar
with that code, please let me know, perhaps there's a better workaround.

> 
> 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.

I thought about testing at run-time for whether or not the PCI frontend
was active, but I decided against it because I suspected that would
involve creating some kind of global variable or globally-visible
function. I don't want to create a test for dom0 because that rules out
putting the PCI backend in it's own driver domain. Perhaps a global
variable is a better workaround for now than a compile-time ifdef.

> 
> Perhaps this restriction will make it easier to pick between the raw-op 
> and non-raw-op virtualised pci access methods? :-)
> 

Perhaps if I understood why the -domU was trying to reallocate the PCI
resources, maybe it would help make the decision for us. But I'm not
sure that the choice between the two methods of operation for the PCI
frontend is related to this problem with
pci_assign_unassigned_resources.

Ryan


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