From: Julien Grall <julien.grall@linaro.org>
To: 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, 01 Jul 2014 19:36:17 +0100 [thread overview]
Message-ID: <53B2FFA1.4050007@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1407011756400.8923@kaball.uk.xensource.com>
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.
This is mostly an issue when the toolstack is running in 32 bits guest
on 64 bits hypervisor. How x86 support this case?
Stefano was suggesting to introduce a new hypercall
XENMEM_maximum_gpfn_v2 which will take a pointer to a gpfn in parameter.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2014-07-01 18:36 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 [this message]
2014-07-01 18:53 ` Andrew Cooper
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=53B2FFA1.4050007@linaro.org \
--to=julien.grall@linaro.org \
--cc=ian.campbell@citrix.com \
--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 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).