[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
- From: Julien Grall <julien.grall@xxxxxxxxxx>
- Date: Wed, 8 Mar 2017 21:51:03 +0000
- Cc: "Edgar Iglesias \(edgar.iglesias@xxxxxxxxxx\)" <edgar.iglesias@xxxxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Steve Capper <Steve.Capper@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Jiandi An <anjiandi@xxxxxxxxxxxxxx>, Punit Agrawal <punit.agrawal@xxxxxxx>, alistair.francis@xxxxxxxxxx, Campbell Sean <scampbel@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "manish.jaggi@xxxxxxxxxxxxxxxxxx" <manish.jaggi@xxxxxxxxxxxxxxxxxx>, Shanker Donthineni <shankerd@xxxxxxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Wed, 08 Mar 2017 21:51:20 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
Hi Stefano,
On 08/03/2017 19:55, Stefano Stabellini wrote:
On Wed, 8 Mar 2017, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 08, 2017 at 07:06:23PM +0000, Julien Grall wrote:
Hi,
On 02/02/17 23:06, Stefano Stabellini wrote:
On Thu, 2 Feb 2017, Julien Grall wrote:
On 01/02/17 10:55, Roger Pau Monné wrote:
On Wed, Jan 25, 2017 at 06:53:20PM +0000, Julien Grall wrote:
On 24/01/17 20:07, Stefano Stabellini wrote:
On Tue, 24 Jan 2017, Julien Grall wrote:
For DT, I would have a fallback on mapping the root complex to DOM0 if we
don't support it. So DOM0 could still use PCI.
For ACPI, I am expecting all the platform ECAM compliant or require few
quirks. So I would mandate the support of the root complex in Xen in order to
get PCI supported.
Sound good. Ack.
I am currently rewriting the design document to take into account all the
comments and follow the path to have the host bridge in Xen and DOM0 will
get an emulated one.
I began to look at scanning and configuring PCI devices in Xen. Looking at
the PCI firmware specification, the firmware is not required to configure
the BAR register other than for boot and console devices. This means an
Operating System (or the hypervisor in our case) may have to configure some
devices.
In order to configure the BAR register, Xen would need to know where are the
PCI resources. On ACPI they can be found in ASL, however Xen is not able to
parse it. In the case of Device Tree with can retrieve the PCI resources
using the property "ranges".
I can see a couple of solutions:
1# Rely on DOM0 to do the PCI configuration. This means that DOM0 should
see all the PCI devices and therefore will not be possible to hide from DOM0
if we know at boot a device will be used by a guest (i.e something similar
to pciback.hide but directly handled in Xen).
.. this as for SR-IOV devices you need the drivers to kick the hardware
to generate the new bus addresses. And those (along with the BAR regions) are
not visible in ACPI (they are constructued dynamically).
Yes indeed. In truth, SR-IOV is a much bigger problem than the BARs. In
reality, the BARs are always setup by the firmware (all cases I have
seen), but SR-IOV definitely need the Linux driver to poke the device.
The truth is you don't know if the firmware will configure that BAR as
the specification does not require it.
For instance, looking at U-boot I don't see any PCI BAR initialization.
And it makes sense otherwise why would Linux bother to rescan and
configure all the PCI devices at boot?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
