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

[George Dunlap <dunlapg@xxxxxxxxx>]

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?

Actually I don't think that it will be possible to run out of
hypercalls by duplicating them all every time the word size doubles --
as when that happens, the maximum hypercall number will exponentially
increase as well.

 -George

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