Re: [Xen-devel] [PATCH] xen/arm: Implement domain_get_maximum_gpfn

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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@xxxxxxxxxx>
>>
>> Acked-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
>
> 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

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