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: Mon, 3 Jul 2017 15:35:31 +0100	[thread overview]
Message-ID: <d84c36e9-a966-4418-9249-a5621ef55a8a@linaro.org> (raw)
In-Reply-To: <4e3a99bebf984a80848a9aa74f525eab@NASANEXM01B.na.qualcomm.com>

On 29/06/17 16:17, Vikram Sethi wrote:
> Hi Julien,

Hi Vikram,

> My thoughts are that while it is not essential to recover from AER and DPC initially, it is critical to at least take the slot offline and notify drivers so they quiesce.
> Without this basic handling, it is possible to create backups in some hardware that result in CPU hangs for loads to adapter MMIO/cfg space and we don't want that.
> i.e it is probably OK to lose the slot/adapter in initial implementation, but IMO it is NOT ok to crash/reboot the system by having watchdog kick in.
> We do need to minimally describe what we will do with the AER and DPC interrupts: are they first handled by Xen and sent as "emulated" interrupt to owning domain?
> Or are the interrupts ignored in initial implementation (not a good idea IMO)?

I don't think it is possible to ask everything to be supported in the 
initial implementation. We have to draw a line so we can get a tech 
preview support in Xen as soon as possible.

At the moment, I am focusing on the foundation that will be required for 
all the boards. I have put them in my low priority tasks because AER, 
DPC, hotplug are optional features and hence not available everywhere.

Feel free to send me a proposal for the design document, patch series if 
you want them to be included in the initial implementation.

>
> Hotplug also does not need to be solved right away. But we need to at least walk through the flows and convince ourselves we are not painting ourselves in a corner.
> I will be in Budapest for Xen developer summit and we can walk through the ACPI hotplug flow and see how that *could* fit into proposed Xen design.

Glad to know that. Let's schedule some discussions during the summit.

Cheers,

-- 
Julien Grall

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