xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Julien Grall <julien@xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 4/4] x86: adjustments to guest handle treatment
Date: Wed, 22 Apr 2020 09:56:14 +0200	[thread overview]
Message-ID: <20200422075614.GZ28601@Air-de-Roger> (raw)
In-Reply-To: <524885c7-5189-7215-41e6-1652a8bd08a2@xen.org>

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

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

Thanks, Roger.


  reply	other threads:[~2020-04-22  7:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21  9:08 [PATCH v2 0/4] x86: mm (mainly shadow) adjustments Jan Beulich
2020-04-21  9:11 ` [PATCH v2 1/4] x86/mm: no-one passes a NULL domain to init_xen_l4_slots() Jan Beulich
2020-04-21 16:40   ` Roger Pau Monné
2020-05-05  6:31     ` Jan Beulich
2020-05-07 17:26       ` Andrew Cooper
2020-05-08  7:45         ` Jan Beulich
2020-04-21  9:11 ` [PATCH v2 2/4] x86/shadow: sh_update_linear_entries() is a no-op for PV Jan Beulich
2020-04-22  6:47   ` Tim Deegan
2020-04-21  9:12 ` [PATCH v2 3/4] x86/mm: monitor table is HVM-only Jan Beulich
2020-04-21  9:13 ` [PATCH v2 4/4] x86: adjustments to guest handle treatment Jan Beulich
2020-04-21 17:30   ` Roger Pau Monné
2020-04-21 18:44     ` Julien Grall
2020-04-22  7:56       ` Roger Pau Monné [this message]
2020-04-22  8:06         ` Julien Grall
2020-04-22  8:17   ` Julien Grall
2020-04-22  9:32     ` Jan Beulich
2020-04-29 13:22       ` Julien Grall
2020-04-22  8:26   ` Roger Pau Monné
2020-04-22  9:27     ` Jan Beulich
2020-05-05  6:26     ` Jan Beulich
2020-05-06  9:45       ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200422075614.GZ28601@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).