Re: [Xen-devel] [PATCH v3 1/8] public / x86: Introduce __HYPERCALL_dm_op...

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.01.17 at 16:06, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 17/01/17 12:29, George Dunlap wrote:
>> On Tue, Jan 17, 2017 at 11:22 AM, Andrew Cooper
>> <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 16/01/17 16:16, Jan Beulich wrote:
>>>>>>> On 16.01.17 at 17:05, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>>> On 13/01/17 12:47, Jan Beulich wrote:
>>>>>>>>>> The kernel already has to parse this structure anyway, and will know 
>>>>>>>>>> the
>>>>>>>>>> bitness of its userspace process.  We could easily (at this point)
>>>>>>>>>> require the kernel to turn it into the kernels bitness for 
>>>>>>>>>> forwarding on
>>>>>>>>>> to Xen, which covers the 32bit userspace under a 64bit kernel 
>>>>>>>>>> problem,
>>>>>>>>>> in a way which won't break the hypercall ABI when 128bit comes along.
>>>>>>>> But that won't cover a 32-bit kernel.
>>>>>>> Yes it will.
>>>>>> How that, without a compat translation layer in Xen?
>>>>> Why shouldn't there be a compat layer?
>>>> Because the compat layer we have is kind of ugly to maintain. Hence
>>>> I would expect additions to it to not make the situation any better.
>>> This is because our compat handling is particularly ugly (partially
>>> because our ABI has varying-size fields at random places in the middle
>>> of structures).  Not because a compat layer is the wrong thing to do.
>>>
>>>>>>>> And I'm not sure we really need to bother considering hypothetical
>>>>>>>> 128-bit architectures at this point in time.
>>>>>>> Because considering this case will avoid us painting ourselves into a
>>>>>>> corner.
>>>>>> Why would we consider this case here, when all other part of the
>>>>>> public interface don't do so?
>>>>> This is asking why we should continue to shoot ourselves in the foot,
>>>>> ABI wise, rather than trying to do something better.
>>>>>
>>>>> And the answer is that I'd prefer that we started fixing the problem,
>>>>> rather than making it worse.
>>>> Okay, so 128 bit handles then. But wait, we should be prepared for
>>>> 256-bit environments to, so 256-bit handles then. But wait, ...
>>> Precisely. A fixed bit width doesn't work, and cannot work going
>>> forwards.  Using a fixed bitsize will force is to burn a hypercall
>>> number every time we want to implement this ABI at a larger bit size.
>> Are we running so low on hypercall numbers that "burning" them when
>> the dominant bit width doubles in size is going to be an issue?
> 
> There is a fixed ABI of 63 hypercalls.
> 
> This can compatibly be extend up to 255 (the amount of extra room in the
> hypercall page), but no further, as c/s 2a33551d in 2008 added:
> 
> /*
>  * Leaf 3 (0x40000002)
>  * EAX: Number of hypercall transfer pages. This register is always
> guaranteed
>  *      to specify one hypercall page.
> 
> to our public ABI.

As said in the other reply - there's nothing keeping us from making
the hypervisor fill stub N such that it passes N+0x1000 as hypercall
number.

Jan


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