From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v2 for 4.5] xen/arm: Add support for GICv3 for domU Date: Sat, 08 Nov 2014 18:01:10 +0000 Message-ID: <545E5A66.2000609@linaro.org> References: <1414872625-2961-1-git-send-email-julien.grall@linaro.org> <20141103163904.GF1638@laptop.dumpdata.com> <54590C48.4080100@linaro.org> <545A5B4F02000078000C1073@mail.emea.novell.com> <545B4325.9000801@linaro.org> <545B577D0200007800045407@mail.emea.novell.com> <545B4D1D.4090000@linaro.org> <20141107154502.GC14076@laptop.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XnAKG-0008FG-HU for xen-devel@lists.xenproject.org; Sat, 08 Nov 2014 18:01:28 +0000 Received: by mail-wi0-f177.google.com with SMTP id ex7so7175165wid.10 for ; Sat, 08 Nov 2014 10:01:26 -0800 (PST) In-Reply-To: <20141107154502.GC14076@laptop.dumpdata.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: Konrad Rzeszutek Wilk Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, vijay.kilari@gmail.com, stefano.stabellini@eu.citrix.com, tim@xen.org, Vijaya.Kumar@caviumnetworks.com, ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com, Jan Beulich , xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org Hi Konrad, On 07/11/2014 15:45, Konrad Rzeszutek Wilk wrote: > On Thu, Nov 06, 2014 at 10:27:41AM +0000, Julien Grall wrote: >> >> >> On 06/11/2014 10:11, Jan Beulich wrote: >>>>>> On 06.11.14 at 10:45, wrote: >>>> Hi Jan, >>>> >>>> On 05/11/2014 17:15, Jan Beulich wrote: >>>>>>>> Julien Grall 11/04/14 6:27 PM >>> >>>>>> On 11/03/2014 04:39 PM, Konrad Rzeszutek Wilk wrote: >>>>>>> It also needs Acks from Daniel and Jan. >>>>>> >>>>>> This patch doesn't modify the x86 part. So I'm not sure if Jan ack is >>>>>> required. Would Ian C. ack be enough? >>>>> >>>>> Yes, it would. >>>>> >>>>>> Anyway, Jan do you have any objection on this patch? >>>>> >>>>> As said previously, I'm not particularly happy about it, but I also don't >>>> strongly >>>>> mind it going in in the current shape. >>>> >>>> May I ask what is wrong with the new approach to the a DOMCTL in this patch? >>>> >>>> The DOMCTL has been clearly identify as arm specific (there is "arm" in >>>> the name). Therefore it doesn't seem necessary to expose it for other >>>> architecture than ARM32 and ARM64. >>> >>> I didn't say there's anything actively wrong with it, all I said is that >>> I'm not particularly happy about it: Irrespective of its name it doesn't >>> look to be really arch-specific in the long run, plus it feels like the >>> data being set here should rather be specified right at domain >>> creation, or via a mechanism similar to x86'es HVM parameters (iirc >>> the value set here can't be changed once the domain got first >>> unpaused). >> >> >> TBH I choose this solution because I though you would be disagree with >> extending the domain create hypercall. >> >> In long run, there will be more parameters such as the number of spis. All >> will be required at the same time. So the HVM parameters solution won't >> really help here. >> >> However, I could give a look to extending the domain creation hypercall >> (xen_domctl_createdomain) to add arch specific field. >> >> But I don't think it's Xen 4.5 material. So I would prefer to stay on this >> approach for this release because we'd like to have GICv3 guest support on >> Xen. Though I could rename the DOMCTL to DOMCTL_get_gic_version. > > That is a bit unfortunate as it sounds like that for Xen 4.6 you will > then ditch this hypercall and focus on the new one? Won't this one then > be bitrotten? Unfortunately yes. Modifying the xen_domctl_createdomain hypercall at this time of the release is not safe. Even though I like challenge, I don't want do be blamed because of a bug that would slip the release date. But, the DOMCTL interface is not considered as a stable ABI. I guess we could kill this hypercall in Xen 4.6. Regards, -- Julien Grall