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

2015-10-02 Thread Juergen Gross

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 
Acked-by: Ian Jackson 


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


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

2015-10-02 Thread Ian Campbell
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 
> Acked-by: Ian Jackson 

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.

Ian.


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


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

2015-10-02 Thread Juergen Gross

On 10/02/2015 04:47 PM, Ian Campbell wrote:

On Fri, 2015-10-02 at 16:25 +0200, Juergen Gross wrote:

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 
Acked-by: Ian Jackson 


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.


Correct.


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).


By "default mapping" you mean the mapping established by the domain builder
which made the domain, as distinct from any mapping which the guest kernel
might establish by itself later, right?


Yes.


I'm not sure that there is any link between the stubdomain's own p2m and
the default mapping of that and the p2m which it is building for use of the
domain it is going to kexec and the default mappings of that p2m-to-be from
the PoV of the to-be-kexec'd guest kernel.


I just checked it again. Initially I thought stubdom would have the same
limitations as Linux regarding the p2m size. But this is not true, as
stubdom's virt_base is 0, while Linux is using 8000.


I'm not sure how kexec operates in this regard.


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?


Irrespective of the above just not supporting this mode would be one way to
avoid the issue. It would make domains using pvgrub1 have different
limitations than domains built directly. IOW users will have to trade off
the security benefits of pvgrub vs the size of the domain they wish to
build, which is a shame.


Hmm, maybe it's possible to add the support to stubdom. With the limit
of the p2m size not hitting stubdom it might be rather easy. I'll try
it.


On the other hand pvgrub2 now exists as a separate (out of tree, it's in
grub.git) thing anyway which doesn't use this domain builder at all AFAIK
and that's the one I expect people are using going forward anyway.


Hmm, another place where huge domain support is to be added, I guess.


Juergen


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


[Xen-devel] [PATCH v2 1/5] libxc: remove allocate member from struct xc_dom_image

2015-10-01 Thread Juergen Gross
The allocate() callback in struct xc_dom_image is never set. Remove it.

Signed-off-by: Juergen Gross 
Acked-by: Ian Jackson 
---
 tools/libxc/include/xc_dom.h | 2 --
 tools/libxc/xc_dom_core.c| 4 
 2 files changed, 6 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 602c5cd..5eeff15 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -175,8 +175,6 @@ struct xc_dom_image {
 
 /* kernel loader */
 struct xc_dom_arch *arch_hooks;
-/* allocate up to virt_alloc_end */
-int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
 };
 
 /* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index fbe4464..b510bbd 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -579,8 +579,6 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
 
 seg->vend = start + pages * page_size;
 dom->virt_alloc_end = seg->vend;
-if (dom->allocate)
-dom->allocate(dom, dom->virt_alloc_end);
 
 DOMPRINTF("%-20s:   %-12s : 0x%" PRIx64 " -> 0x%" PRIx64
   "  (pfn 0x%" PRIpfn " + 0x%" PRIpfn " pages)",
@@ -603,8 +601,6 @@ int xc_dom_alloc_page(struct xc_dom_image *dom, char *name)
 
 start = dom->virt_alloc_end;
 dom->virt_alloc_end += page_size;
-if (dom->allocate)
-dom->allocate(dom, dom->virt_alloc_end);
 pfn = (start - dom->parms.virt_base) / page_size;
 
 DOMPRINTF("%-20s:   %-12s : 0x%" PRIx64 " (pfn 0x%" PRIpfn ")",
-- 
2.1.4


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