Re: [RFC] ARM PCI Passthrough design document

[Manish Jaggi <mjaggi@caviumnetworks.com>]

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