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

["roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>]

Hello,

My 2cents on what are the plans on PVH/x86.

On Wed, Jun 28, 2017 at 04:22:48PM +0100, Julien Grall wrote:
> 
> 
> 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.

Hotplug will be done using an hypercall. We already have them in place
for PV, and this is simply going to be reused:

Hotplug PCI devices:
PHYSDEVOP_manage_pci_add{_ext}

hotplug MMCFG (ECAM) regions:
PHYSDEVOP_pci_mmcfg_reserved

> > 
> > 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?

Hm, I'm not sure I follow here, I don't see AER tied to ACPI. AER is a
PCIe capability, and according to the spec can be setup completely
independent to ACPI.

In any case, Xen can trap or hide the capability from guests, Xen
could possibly even emulate AER somehow if that's more suitable (ie:
guest sets up AER, Xen traps accesses to this capability and filters
the errors Xen wants to handle itself vs the errors that should be
propagated to the guest).

The biggest issue I see with AER (and DPC) is that it requires an
interrupt. So Xen would have to stole one (or more) interrupts from
the guest in order to make use of those capabilities if they are to be
exclusively managed by Xen. This could be done by simply telling the
guest the device has less MSI/MSI-X interrupts than it really has.

> > 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.

As Julien said, I think that you probably know more about AER/DPC than
we do, so it would be good if you could go over the design document
and mare sure that the current approach can work with the way you
intend to use AER/DPC.

Thanks, Roger.

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