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

[Ryan <hap9@xxxxxxxxxxxxxx>]

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

I believe that I've found the correct solution to the resource issue
with pci_assign_unassigned_resources and it doesn't involve any kind of
global variables. It turns out that pci_assign_unassigned_resources (and
the functions it calls) iterate over all of the resources in a struct
pci_dev and if they don't have a parent resource, it considers them
"unassigned". By forcibly claiming resources (using pci_claim_resource),
the PCI frontend can mark all of those resources as assigned so the
kernel doesn't try to change them later in
pci_assign_unassigned_resources.

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

When you say "dual-mode", to you mean having the PCI frontend and
backend in the same kernel? If so, yes. I tested it out with this patch
and my dom0 kernel works fine in domU and dom0 with both the PCI
frontend and the PCI backend compiled in. It prefers direct access to
the PCI bus and falls back on the Xen pcifront stub if that fails.


I've attached a new patch for the PCI frontend/backend that replaces
patch 2 of 4 that I sent earlier today. The other patches sent today
remain unchanged.

One issue with this patch (at least the frontend part of it) is that it
will probably only work correctly with x86 (I don't have access to other
architectures to test on) and the kconfig menu entries will appear
regardless of the architecture (they don't list x86 as a dependency).
Should they list x86 as a dependency? Right now, they're under the "Xen"
menu with the other backends and frontends. Should I move the PCI
frontend configuration option into the "Bus options/PCI Access" menu
next to the mmconfig, direct, and bios options? I think it would be
better placed under the "Bus options/PCI Access" menu but I wasn't sure
if all the backends and frontends needed to be listed together. 

Signed-off-by: Ryan Wilson <hap9@xxxxxxxxxxxxxx>

pci-ddi.patch
Description: Text Data

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