[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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

Or maybe I'm simply not getting what you mean to put in place here.

Jan


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.