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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.01.17 at 12:22, <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.

Well, I disagree. The best possible solution is no translation layers,
as they're only a source of possible extra mistakes.

>>>>>> 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.

With wider machine word width the number space of hypercalls
widens too, so I would not be worried at all using new hypercall
numbers, or even wholesale new hypercall number ranges.

>> Or maybe I'm simply not getting what you mean to put in place here.
> 
> The interface should be in terms of void * (and where appropriate,
> size_t), from the guests point of view, and is what a plain
> GUEST_HANDLE() gives you.

As said - that'll further break 32-bit tool stacks on 64-bit kernels.
As much as you say we should try to avoid making it harder to
accommodate a hypothetical 128-bit architecture, I think I can
validly demand that the 32-bit tool stack on 64-bit kernel case
should not be broken further than it already is (as you say;
certain things surely work quite okay). Instead such known
brokenness should be fixed, the more that for several years
we've been "successfully" ignoring the x32 ABI with our libraries
and the public interface as a whole.

Jan


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