From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Tim Deegan <tim@xen.org>, Paul Durrant <paul.durrant@citrix.com>,
David Vrabel <david.vrabel@citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>,
samuel.thibault@ens-lyon.org,
Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: HVMlite ABI specification DRAFT A
Date: Fri, 5 Feb 2016 16:35:44 +0100 [thread overview]
Message-ID: <56B4C150.8000806@citrix.com> (raw)
In-Reply-To: <56B4CDCC02000078000CF2C6@prv-mh.provo.novell.com>
El 5/2/16 a les 16:29, Jan Beulich ha escrit:
>>>> On 05.02.16 at 16:00, <roger.pau@citrix.com> wrote:
>> El 5/2/16 a les 15:31, Jan Beulich ha escrit:
>>>>>> On 05.02.16 at 15:27, <roger.pau@citrix.com> 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?
TBH (and maybe I'm being overly confident here) I expect that anything
new will just use MSI.
Roger.
next prev parent reply other threads:[~2016-02-05 15:35 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 17:48 HVMlite ABI specification DRAFT A Roger Pau Monné
2016-02-04 18:22 ` Andrew Cooper
2016-02-04 19:33 ` Roger Pau Monné
2016-02-04 20:24 ` Boris Ostrovsky
2016-02-05 14:44 ` Ian Campbell
2016-02-05 14:46 ` Roger Pau Monné
2016-02-05 9:12 ` Jan Beulich
2016-02-05 9:50 ` Roger Pau Monné
2016-02-05 10:40 ` Jan Beulich
2016-02-05 11:04 ` Andrew Cooper
2016-02-05 11:07 ` Jan Beulich
2016-02-05 11:30 ` Roger Pau Monné
2016-02-05 11:45 ` Jan Beulich
2016-02-05 11:50 ` Roger Pau Monné
2016-02-05 13:22 ` Jan Beulich
2016-02-05 14:27 ` Roger Pau Monné
2016-02-05 14:31 ` Jan Beulich
2016-02-05 15:00 ` Roger Pau Monné
2016-02-05 15:29 ` Jan Beulich
2016-02-05 15:35 ` Roger Pau Monné [this message]
2016-02-04 18:38 ` Boris Ostrovsky
2016-02-04 18:51 ` Samuel Thibault
2016-02-04 19:21 ` Roger Pau Monné
2016-02-04 20:17 ` Boris Ostrovsky
2016-02-04 20:29 ` Konrad Rzeszutek Wilk
2016-02-04 20:37 ` Andrew Cooper
2016-02-05 8:23 ` Roger Pau Monné
2016-02-04 22:23 ` Samuel Thibault
2016-02-04 19:09 ` Samuel Thibault
2016-02-04 19:18 ` Boris Ostrovsky
2016-02-04 22:21 ` Samuel Thibault
2016-02-04 22:25 ` Andrew Cooper
2016-02-04 22:41 ` Samuel Thibault
2016-02-05 10:20 ` Ian Campbell
2016-02-05 16:01 ` Tim Deegan
2016-02-05 16:13 ` Roger Pau Monné
2016-02-05 17:14 ` Andrew Cooper
2016-02-05 18:05 ` Tim Deegan
2016-02-05 18:44 ` Andrew Cooper
2016-02-08 12:10 ` Stefano Stabellini
2016-02-08 13:21 ` David Vrabel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B4C150.8000806@citrix.com \
--to=roger.pau@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=paul.durrant@citrix.com \
--cc=samuel.thibault@ens-lyon.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).