Re: [Xen-devel] HVMlite ABI specification DRAFT A

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

El 5/2/16 a les 14:22, Jan Beulich ha escrit:
>>>> On 05.02.16 at 12:50, <roger.pau@xxxxxxxxxx> wrote:
>> El 5/2/16 a les 12:45, Jan Beulich ha escrit:
>>>>>> On 05.02.16 at 12:30, <roger.pau@xxxxxxxxxx> wrote:
>>>> El 5/2/16 a les 11:40, Jan Beulich ha escrit:
>>>>>>>> On 05.02.16 at 10:50, <roger.pau@xxxxxxxxxx> wrote:
>>>>>> For legacy PCI interrupts, we can parse the MADT inside of Xen in order
>>>>>> to properly setup the lines/overwrites and inject the interrupts that
>>>>>> are not handled by Xen straight into the hardware domain. This will
>>>>>> require us to be able to emulate the same topology as what is found in
>>>>>> native (eg: if there are two IO APICs in the hardware we should also
>>>>>> provide two emulated ones to the hw domain).
>>>>>
>>>>> I don't think MADT contains all the needed information, or else we
>>>>> wouldn't need PHYSDEVOP_setup_gsi.
>>>>
>>>> AFAICT, I think we could do something like:
>>>>
>>>>  - IRQs [0, 15]: edge-trigger, low-polarity.
>>>>  - IRQs [16, n]: level-triggered, high-polarity.
>>>
>>> That's not a valid assumption - I've seen systems with other settings
>>> on GSI >= 16 ...
>>
>> Then we just propagate how the emulated IO APIC pins are setup to the
>> real one, this should match reality, and is no different from using
>> PHYSDEVOP_setup_gsi. AFAICT it's just a different way of getting the
>> same information.
> 
> That won't work either I'm afraid: For one, Dom0 may not even write
> RTEs for interrupts it never enables. And even if it did, it would write
> them masked, yet we mustn't derive information from masked RTEs -
> see commit 669d4b85c4 ("x86/IO-APIC: don't create pIRQ mapping
> from masked RTE").

In which case, why does Xen need to setup this interrupt/RTE if it's
never used by Dom0?

> Also consider e.g. the device IRQ which the
> serial driver may be using: We specifically suppress modifications to
> RTEs for in-use IRQs in current code and would of course need to
> do so in the PVHv2 code too. That way there would be no proper
> way to establish the two bits (short of grabbing the data from what
> Dom0 tries to write despite us otherwise suppressing the write).

For devices in use by Xen itself, like the uart, doesn't Xen already
take care of setting the right interrupt configuration? Or else how does
the uart work before Dom0 is launched?

The plan was to use the STAO ACPI table in order to notify Dom0 that
certain devices (like the uart) are not accessible, thus preventing Dom0
from setting any interrupts for this devices at all (ie: they should
just be ignored/skipped by Dom0 when doing device enumeration).

And in any case, writes to pins that are in use by Xen should not be
propagated to the physical IO APIC at all, since I would assume Xen has
already set them up properly.

Roger.


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