Re: [Xen-devel] [PATCH v2 for 4.5] xen/arm: Add support for GICv3 for domU

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On November 8, 2014 1:01:10 PM EST, Julien Grall <julien.grall@xxxxxxxxxx> 
wrote:
>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, <julien.grall@xxxxxxxxxx> wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On 05/11/2014 17:15, Jan Beulich wrote:
>>>>>>>>> Julien Grall <julien.grall@xxxxxxxxxx> 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.
>

<nods>

>But, the DOMCTL interface is not considered as a stable ABI. I guess we
>could kill this hypercall in Xen 4.6.

If that is the intent we should really wrap all of the functionality (in 
userspace) with Xen v4.5 version check such that it is not exposed to earlier 
or newer versions of tools.

That is to guard against somebody building against libxc or libxl and then 
becoming dependent on this and then complaining that it is not in Xen 4.6. 

Perhaps even add in headers a big warning that this is an band-aid!
>
>Regards,



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