On 16.06.2021 17:12, Anthony PERARD wrote:
> On Wed, Jun 16, 2021 at 04:49:33PM +0200, Jan Beulich wrote:
>> I don't think it should. But I now notice I should have looked at the
>> logs of these tests:
>>
>> xc: info: Saving domain 2, type x86 HVM
>> xc: error: Unable to obtain the guest p2m size (1 = Operation not 
>> permitted): Internal error
>> xc: error: Save failed (1 = Operation not permitted): Internal error
>>
>> which looks suspiciously similar to the issue Jürgen's d21121685fac
>> ("tools/libs/guest: fix save and restore of pv domains after 32-bit
>> de-support") took care of, just that here we're dealing with a HVM
>> guest. I'll have to go inspect what exactly the library is doing there,
>> and hence where in Xen the -EPERM may be coming from all of the
>> sudden (and only for OVMF).
>>
>> Of course the behavior you describe above may play into this, since
>> aiui this might lead to an excessively large p2m (depending what
>> exactly you mean with "as high as possible").
> 
> The maximum physical address size as reported by cpuid 0x80000008
> (or 1<<48 if above that) minus 1 page, or 1<<36 - 1 page.

So this is very likely the problem, and not just for a 32-bit tool
stack right now. With ...

long do_memory_op(xc_interface *xch, int cmd, void *arg, size_t len)
{
    DECLARE_HYPERCALL_BOUNCE(arg, len, XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
    long ret = -1;
    ...
    ret = xencall2(xch->xcall, __HYPERVISOR_memory_op,
                   cmd, HYPERCALL_BUFFER_AS_ARG(arg));

... I'm disappointed to find:

int xencall0(xencall_handle *xcall, unsigned int op);
int xencall1(xencall_handle *xcall, unsigned int op,
             uint64_t arg1);
int xencall2(xencall_handle *xcall, unsigned int op,
             uint64_t arg1, uint64_t arg2);
...

I'm sure we had the problem of a truncated memory-op hypercall
result already in the past, so there definitely was a known problem
that got re-introduced. Or wait, no - I've found that commit
(a27f1fb69d13), and it didn't really have any effect afaict:
Adjusting do_memory_op()'s return type wasn't sufficient, when
do_xen_hypercall() was returning only int. Now on to figuring a
not overly intrusive way of addressing this.

Jan


Reply via email to