Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

[Vikram Sethi <vikrams@xxxxxxxxxxxxxxxx>]

Hi Julien, 
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)?

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.

Thanks,
Vikram

-----Original Message-----
From: Julien Grall [mailto:julien.grall@xxxxxxxxxx] 
Sent: Wednesday, June 28, 2017 10:23 AM
To: Vikram Sethi <vikrams@xxxxxxxxxxxxxxxx>; Stefano Stabellini 
<sstabellini@xxxxxxxxxx>
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>; edgar.iglesias@xxxxxxxxxx; 
Steve Capper <Steve.Capper@xxxxxxx>; punit.agrawal@xxxxxxx; Wei Chen 
<Wei.Chen@xxxxxxx>; Dave P Martin <Dave.Martin@xxxxxxx>; Sameer Goel 
<sgoel@xxxxxxxxxxxxxxxx>; Sinan Kaya <okaya@xxxxxxxxxxxxxxxx>; 
roger.pau@xxxxxxxxxx; manish.jaggi@xxxxxxxxxxxxxxxxxx; Vijaya Kumar K 
<Vijaya.Kumar@xxxxxxxxxxxxxxxxxx>; Andre Przywara <andre.przywara@xxxxxxx>
Subject: Re: [RFC] ARM PCI Passthrough design document



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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel