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

[Manish Jaggi <mjaggi@xxxxxxxxxxxxxxxxxx>]

Hi Roger/Vikram/Stefano,


On 07/08/2017 01:04 PM, Roger Pau Monné wrote:
> On Fri, Jul 07, 2017 at 02:50:01PM -0700, Stefano Stabellini wrote:
> > On Fri, 7 Jul 2017, Roger Pau Monné wrote:
> > > On Thu, Jul 06, 2017 at 03:55:28PM -0500, Vikram Sethi wrote:
> > > > > > > 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.
> > > > True, it can be independent if not using firmware first AER handling (FFH). But
> > > > Firmware tells the OS whether firmware first is in use.
> > > > If FFH is in use, the AER interrupt goes to firmware and then firmware processes
> > > I'm sorry, but how is the firmware supposed to know which interrupt is
> > > AER using? That's AFAIK setup in the PCI AER capabilities, and
> > > depends on whether the OS configures the device to use MSI or MSI-X.
> > >
> > > Is there some kind of side-band mechanism that delivers the AER
> > > interrupt using a different method?
> > >
> > > > the AER logs, filters errors, and sends a ACPI HEST log with the filtered AER
> > > > regs to OS along with an ACPI event/interrupt. Kernel is not supposed to touch
> > > > the AER registers directly in this case, but act on the register values in the
> > > > HEST log.
> > > > http://elixir.free-electrons.com/linux/latest/source/drivers/pci/pcie/aer/aerdrv_acpi.c#L94
> > > That's not a problem IMHO, Xen could even mask the AER capability from
> > > the Dom0/guest completely if needed.
> > >
> > > > If Firmware is using FFH, Xen will get a HEST log with AER registers, and must
> > > > parse those registers instead of reading AER config space.
> > > Xen will not get an event, it's going to be delivered to Dom0 because
> > > when using ACPI Dom0 is the OSPM (not Xen). I assume this event is
> > > going to be notified by triggering an interrupt from the ACPI SCI?
> > It is still possible to get the event in Xen, either by having Dom0 tell
> > Xen about it, or my moving ACPI SCI handling in Xen. If we move ACPI SCI
> > handling in Xen, we could still forward a virtual SCI interrupt to Dom0
> > in cases where Xen decides that Dom0 should be the one handling the
> > event. In other cases, where Xen knows how to handle the event, then
> > nothing would be sent to Dom0. Would that work?
> Maybe that's different on ARM vs x86, but when receiving the SCI
> interrupt the OSPM has to execute some AML in order to figure out
> which event has triggered. Even if Xen can trap the SCI, it has no way
> to execute AML, and that in any case can only be done by one entity,
> the OSPM.
>
> IMHO, for this to be viable Dom0 should notify the event to Xen.
Any further update on this discussion ?
> Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel