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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.02.16 at 16:00, <roger.pau@xxxxxxxxxx> wrote:
> El 5/2/16 a les 15:31, Jan Beulich ha escrit:
>>>>> On 05.02.16 at 15:27, <roger.pau@xxxxxxxxxx> wrote:
>>> El 5/2/16 a les 14:22, Jan Beulich ha escrit:
>>>> 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?
>> 
>> In polling mode.
> 
> I guess this is not very common, since most uarts use a GSI < 16. In
> which case, couldn't the ones that use a GSI >= 16 just be used in
> polling mode _forever_?

It could, but it's inefficient.

>>> 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.
>> 
>> Once again - it can't without Dom0's help if the interrupt isn't in
>> the legacy GSI range (below 16).
> 
> Which devices is Xen expected to use with a GSI >= 16? I can only think
> of the uart, but maybe there are others which I'm missing?

Right now only the UART, but who knows what's to come?

Jan


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