This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ryan <hap9@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][2/4] PCI Driver Domains: PCI Backend/Frontend
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 7 Feb 2006 15:19:40 +0000
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 07 Feb 2006 15:24:22 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1139323021.26777.26.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1139323021.26777.26.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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

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