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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.

Roger.

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