Re: [RFC] ARM PCI Passthrough design document

From: Julien Grall <julien.grall@linaro.org>
To: Vikram Sethi <vikrams@qti.qualcomm.com>,
	Stefano Stabellini <sstabellini@kernel.org>
Cc: "edgar.iglesias@xilinx.com" <edgar.iglesias@xilinx.com>,
	Sinan Kaya <okaya@qti.qualcomm.com>, Wei Chen <Wei.Chen@arm.com>,
	Steve Capper <Steve.Capper@arm.com>,
	Andre Przywara <andre.przywara@arm.com>,
	"manish.jaggi@caviumnetworks.com"
	<manish.jaggi@caviumnetworks.com>,
	"punit.agrawal@arm.com" <punit.agrawal@arm.com>,
	Sameer Goel <sgoel@qti.qualcomm.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Dave P Martin <Dave.Martin@arm.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	"roger.pau@citrix.com" <roger.pau@citrix.com>
Subject: Re: [RFC] ARM PCI Passthrough design document
Date: Wed, 28 Jun 2017 16:22:48 +0100	[thread overview]
Message-ID: <8bfc13f3-f8c0-e308-3660-4d2e9a2a31e4@linaro.org> (raw)
In-Reply-To: <d60d8ebcd41445d1898bfbc3dca46276@NASANEXM01B.na.qualcomm.com>

On 20/06/17 01:19, Vikram Sethi wrote:
> Hi Julien,

Hi Vikram,

Thank you for your feedbacks.

> Thanks for posting this. I think some additional topics need to be covered in the design document, under 3 main topics:

I wanted to limit the scope of the PCI passthrough work to the strict 
minimum. I didn't consider hotplug and AER in the scope because it is 
optional feature.

>
> Hotplug: how will Xen support hotplug? Many rootports may require firmware hooks such as ACPI ASL to take care of platform specific MMIO initialization on hotplug. Normally firmware (UEFI) would have done that platform specific setup at boot.

We don't have ASL support in Xen. So I would expect the hotplug to be 
handled by the hardware domain and then report it to Xen.

This would also fit quite well to the current design as the hardware 
domain will scan PCI devices at boot and then register them to Xen via 
an hypercall.

>
> AER: Will PCIe non-fatal and fatal errors (secondary bus reset for fatal) be recoverable in Xen?
> Will drivers in doms be notified about fatal errors so they can be quiesced before doing secondary bus reset in Xen?
> Will Xen support Firmware First Error handling for AER? i.e When platform does Firmware first error handling for AER and/or filtering of AER, sends associated ACPI HEST logs to Xen
> How will AER notification and logs be propagated to the doms: injected ACPI HEST?
>
> PCIe DPC (Downstream Port Containment): will it be supported in Xen, and Xen will register for DPC interrupt? When Xen brings the link back up will it send a simulated hotplug to dom0 to show link back up?

I don't feel it is necessary to look at AER for the first work of PCI 
passthrough. I consider it as a separate feature that could probably 
come with the RAS story.

At the moment, I don't know who is going to handle the error and even 
how they will be reported to the guest. But I don't think this will have 
any impact on our design choice here.

Let me know if you think it may have an impact.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel