All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Julien Grall <julien.grall@linaro.org>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org,
	ian.campbell@citrix.com, stefano.stabellini@citrix.com
Subject: Re: [PATCH] xen/arm: Implement domain_get_maximum_gpfn
Date: Tue, 1 Jul 2014 19:53:24 +0100	[thread overview]
Message-ID: <53B303A4.3010401@citrix.com> (raw)
In-Reply-To: <53B2FFA1.4050007@linaro.org>

On 01/07/14 19:36, Julien Grall wrote:
>
>
> On 01/07/14 17:57, Stefano Stabellini wrote:
>> On Tue, 1 Jul 2014, Julien Grall wrote:
>>> The function domain_get_maximum_gpfn is returning the maximum gpfn ever
>>> mapped in the guest. We can use d->arch.p2m.max_mapped_gfn for this
>>> purpose.
>>>
>>> Signed-off-by: Julien Grall <julien.grall@linaro.org>
>>
>> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> Thanks. Just a quick follow-up on your question on IRC.
>
> LPAE supports up to 48 bits on ARMv8 (40 bits on v7), so the MFN will
> just fit in 32 bits.
>
> I'm a bit worry about what happen if there is an error? The current
> hypercall doesn't look like to be safe for that. Indeed, the return
> value is used to store the higher gpfn. If the guest also use internal
> error, then we are screw.

All hypercalls should return a long (domains' natural width) in their
first parameter, allowing for -ERANGE for truncation cases.  Not all
hypercalls actually adhere to this currently, but retroactively
enforcing this in the ABI should be fine, as it just only changes the
cases where we couldn't represent the result correctly anyway and
effectively returned junk.

>
> This is mostly an issue when the toolstack is running in 32 bits guest
> on 64 bits hypervisor. How x86 support this case?

The 32bit compat layer in Xen does quite a lot of truncation detection,
and will fail with -ERANGE.

There are other issues, such as libxc truncating the return value of
this specific hypercall from a long to an int (although that is rather
more simple to fix).

>
> Stefano was suggesting to introduce a new hypercall
> XENMEM_maximum_gpfn_v2 which will take a pointer to a gpfn in parameter.
>
> Regards,
>

I am not sure this is actually needed.  A toolstack of thinner width
than Xen almost certainly won't be capable of constructing such a
domain; there are many other similar issues in the Xen/toolstack abi/api
at the point at which hypercalls like this would start truncating.

~Andrew

  reply	other threads:[~2014-07-01 18:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-01 14:57 [PATCH] xen/arm: Implement domain_get_maximum_gpfn Julien Grall
2014-07-01 16:57 ` Stefano Stabellini
2014-07-01 18:36   ` Julien Grall
2014-07-01 18:53     ` Andrew Cooper [this message]
2014-07-09 11:38   ` Julien Grall
2014-07-16 16:02     ` Ian Campbell
2014-07-16 18:17       ` Julien Grall
2014-09-01 21:32       ` Julien Grall
2014-09-03  8:44         ` Ian Campbell
2014-09-03  9:00           ` Tamas K Lengyel
2014-09-08 20:43             ` Julien Grall
2014-09-08 20:47               ` Tamas K Lengyel
2014-09-09 12:50                 ` Tamas K Lengyel
2014-09-09 13:09                   ` Andrew Cooper
2014-09-09 14:01                     ` Tamas K Lengyel
2014-09-10 11:21                 ` Tamas K Lengyel
2014-07-02  9:12 ` Ian Campbell
2014-07-02  9:19   ` Julien Grall
2014-07-02  9:22     ` Ian Campbell
2014-07-02  9:37       ` Julien Grall
2014-07-02  9:41         ` Ian Campbell
2014-07-02  9:50           ` Jan Beulich
2014-07-02  9:52             ` Ian Campbell
2014-07-02 10:19             ` Roger Pau Monné
2014-07-02 10:31               ` Jan Beulich
2014-07-02 10:51                 ` Roger Pau Monné
2014-07-02 10:52                   ` Ian Campbell
2014-07-02 10:58                     ` Andrew Cooper
2014-07-02 11:21                       ` Ian Campbell
2014-07-02 13:44                 ` Konrad Rzeszutek Wilk

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=53B303A4.3010401@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=julien.grall@linaro.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.