From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Subject: Re: HVMlite ABI specification DRAFT A Date: Fri, 5 Feb 2016 16:35:44 +0100 Message-ID: <56B4C150.8000806@citrix.com> References: <56B38EDE.5090700@citrix.com> <56B396ED.7010209@citrix.com> <56B4757A02000078000CEE45@prv-mh.provo.novell.com> <56B47048.8090206@citrix.com> <56B48A1E02000078000CEF6F@prv-mh.provo.novell.com> <56B487D1.4080902@citrix.com> <56B4995F02000078000CF019@prv-mh.provo.novell.com> <56B48C95.1030102@citrix.com> <56B4B03602000078000CF07F@prv-mh.provo.novell.com> <56B4B15C.5020104@citrix.com> <56B4C06102000078000CF1CF@prv-mh.provo.novell.com> <56B4B927.2090403@citrix.com> <56B4CDCC02000078000CF2C6@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aRiQJ-0001Tw-Tk for xen-devel@lists.xenproject.org; Fri, 05 Feb 2016 15:35:52 +0000 In-Reply-To: <56B4CDCC02000078000CF2C6@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Wei Liu , Stefano Stabellini , Andrew Cooper , Tim Deegan , Paul Durrant , David Vrabel , xen-devel , samuel.thibault@ens-lyon.org, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org El 5/2/16 a les 16:29, Jan Beulich ha escrit: >>>> On 05.02.16 at 16:00, wrote: >> El 5/2/16 a les 15:31, Jan Beulich ha escrit: >>>>>> On 05.02.16 at 15:27, 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.