>>> On 05.02.16 at 12:50, <roger....@citrix.com> wrote:
> El 5/2/16 a les 12:45, Jan Beulich ha escrit:
>>>>> On 05.02.16 at 12:30, <roger....@citrix.com> wrote:
>>> El 5/2/16 a les 11:40, Jan Beulich ha escrit:
>>>>>>> On 05.02.16 at 10:50, <roger....@citrix.com> 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"). 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).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
