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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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