Re: [PATCH v2 1/5] libxc: remove allocate member from struct xc_dom_image

[Juergen Gross <jgross@suse.com>]

On 10/02/2015 03:01 PM, Ian Campbell wrote:
> On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:
>> The allocate() callback in struct xc_dom_image is never set. Remove it.
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> This breaks the stubdom build:
>
> kexec.c: In function ‘kexec’:
> kexec.c:221:78: warning: taking address of expression of type ‘void’
>       xen_pfn_t boot_page_mfn = virt_to_mfn(&_boot_page);
>                                                                                ^
> kexec.c:230:8: error: ‘struct xc_dom_image’ has no member named ‘allocate’
>       dom->allocate = kexec_allocate;
>          ^
> kexec.c:318:60: warning: taking address of expression of type ‘void’
>               virt_to_mfn(&_boot_page));
>                                                              ^
> Makefile:79: recipe for target '/local/scratch/ianc/devel/committer-amd64.git/stubdom/grub-x86_64/kexec.o' failed
>
> On i386 too.
>
> And in fact that hook looks useful in that context, so either it needs to
> stay of stubdom kexec needs changing to work some other way.

Too bad.

I wanted to remove the allocate callback as it will conflict with the
allocations of memory outside the initial default mapping.

Just to make sure I understand this correctly:

stubdom is used in this context to support grub running as a pv domain
capable to start another pv domain.

So as long as stubdom doesn't support mapping the p2m list outside the
default mapping it makes no sense to support this feature for any domain
started via stubdom/grub (the main reason to use this feature is the
support of huge memory causing the p2m list to exceed the available
virtual address space of the default mapping).

So the easy solution would be to not support initrd and p2m outside the
default mapping when the allocate callback is set. Do you think this
solution is okay?


Juergen

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