All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.