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

Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment



Hi,

On 22/04/2020 08:56, Roger Pau Monné wrote:
On Tue, Apr 21, 2020 at 07:44:55PM +0100, Julien Grall wrote:
Hi,

On 21/04/2020 18:30, Roger Pau Monné wrote:
On Tue, Apr 21, 2020 at 11:13:23AM +0200, Jan Beulich wrote:
First of all avoid excessive conversions. copy_{from,to}_guest(), for
example, work fine with all of XEN_GUEST_HANDLE{,_64,_PARAM}().

I'm not sure I understand the difference between those two, as they
are both placeholders for linear guest addresses?

AFAICT XEN_GUEST_HANDLE should be used for guest pointers inside of an
hypercall struct, while XEN_GUEST_HANDLE_PARAM is for guest pointers
as hypercall arguments. But those are both just guest pointers,
whether they are a parameter to the hypercall or a field in a
struct, and hence could use the same type?

I assume there's some reason for not doing so, and I see the comment
about other arches, but again a linear guest address is just that in
all arches, regardless of it's placement.

On Arm:
  * XEN_GUEST_HANDLE() will always be 64-bit on both 32-bit and 64-bit
hypervisor.
  * XEN_GUEST_HANDLE_PARAM() will be 32-bit for 32-bit hypervisor. For 64-bit
hypervisor, it will be 64-bit.

Per the ABI, each argument only fit a register. So you could not use
XEN_GUEST_HANDLE() as now an argument will be held in 2 registers on 32-bit.

We also want the structure layout to be the same for 32-bit and 64-bit. So
using XEN_GUEST_HANDLE_PARAM() everywhere is not the solution as the virtual
address is not the same.

Right, you hide the 'padding' inside XEN_GUEST_HANDLE by making it
have a fixed size on all bitnesses, I can see how that's not
desirable for hypercall params though.

Iff we ever switch to an ABI that uses physical addresses instead of
linear ones we would have to switch everything to be a 64bit integer,
or else 32bit PAE won't work correctly. Or come up with a completely
different ABI (ie: use a pre-allocated set of buffer pages, IIRC as
suggested by Juergen).

I would go further here and request the arguments to always be the same size regardless the bitness.



We could possibly convert internally XEN_GUEST_HANDLE_PARAM() to
XEN_GUEST_HANDLE(), but I am not sure how this would be beneficial. We would
have to use 2 registers for arm 32-bit everytime.

Hm, we could maybe expand hypercall parameters to 64bit using some
kind of translation layer between the entry point and the actual
handler, but anyway, I get now there's a need to keep this difference.

This can be done today using guest_handle_from_param manually.

Cheers,

--
Julien Grall



 


Rackspace

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