[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 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> Attachment:
pci-ddi.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |