Re: [suspend/resume] memory_op hypercall failure: XENMEM_maximum_gpfn

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, May 18, 2008 at 09:19:32PM +0200, Jean-Yves Migeon wrote:
> Jean-Yves Migeon wrote:
> >...
> ># xm dump-core 2 /root/core
> >Error: Failed to dump core: (1, 'Internal error', 'p2m_size < nr_pages 
> >-1 (0 < 1fff')
> >....
> >Questions are:
> >- hypercall APIs speak of "-ve errcode" on failure, but I can not 
> >manage to find which errcode they are referring to. Are they the same 
> >as the ones given in the mini-os from xentools? 
> >(extras/mini-os/include/errno-base.h). If yes, -1 indicates an EPERM 
> >error, which is weird for dom0.
> >- do the XENMEM_maximum_gpfn memory operation require some cooperation 
> >from the guest to obtain the proper value? I would say no, hypervisor 
> >should do it by itself alone. Am I missing something here?
> I investigated this matter a bit further: looks like the architecture 
> dependent part of shared_info struct from Xen should be "updated" by 
> guest upon start up, by completing the 
> shared_info->arch.pfn_to_mfn_frame_list_list element with the list of 
> frames that specifies the list of frames which makes up the entire p2m 
> table (I would say it mimics the PD => PT mechanisms).

That's strange as the hypervisor already has this info, which it gives us
from xen_start_info.mfn_list. Anyway it shouldn't be hard to fill in this.

There is also machine_to_phys_mapping[] which is the opposite; this
one is also provided by Xen.

> 
> I did not find any part in NetBSD kernel which uses such kind of 
> translation tables (relevant parts of pmap dealing with machine frames 

see the xpmap_phys_to_machine_mapping[] array, and xpmap_ptom().
in pmap.c this is used mainly by pmap_pa2pte().

xpmap_phys_to_machine_mapping[] is keept up to date by the NetBSD kernel,
machine_to_phys_mapping[] is updated though xpq_queue_machphys_update().

> 
> What troubles me is the errno returned by the hypercall I was talking 
> about in my previous mail (EPERM). IMHO, it has nothing to do with 
> permissions.

The hypervisor may use its own error codes in some case. I don't know
about this specific hypercall.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--