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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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

~Andrew

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