Re: [Xen-devel] [PATCH v3 05/19] libxl: add vmemrange to libxl__domain_build_state

2015-01-13 Thread Ian Jackson 
Wei Liu writes ([PATCH v3 05/19] libxl: add vmemrange to 
libxl__domain_build_state):
 A vnode consists of one or more vmemranges (virtual memory range).  One
 example of multiple vmemranges is that there is a hole in one vnode.

I'm finding this series a bit oddly structured.  This patch, for
example, just introduces some new fields to an internal state struct -
but these fields are not initialised, set, or read.

Ian.

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

Re: [Xen-devel] [PATCH v3 05/19] libxl: add vmemrange to libxl__domain_build_state

2015-01-13 Thread Wei Liu 
On Tue, Jan 13, 2015 at 05:02:10PM +, Ian Jackson wrote:
 Wei Liu writes ([PATCH v3 05/19] libxl: add vmemrange to 
 libxl__domain_build_state):
  A vnode consists of one or more vmemranges (virtual memory range).  One
  example of multiple vmemranges is that there is a hole in one vnode.
 
 I'm finding this series a bit oddly structured.  This patch, for
 example, just introduces some new fields to an internal state struct -
 but these fields are not initialised, set, or read.
 

The new fields (and other existing fields) are initialised to zero in
initiate_domain_create, that's why it doesn't need to be explicitly
initialised.

These new fields are accessed in the next patch. I can either explicitly
say so in commit log or squash this patch with the next one. Which way
do you prefer?

TBH I don't think this patch and next one should be squashed into one
patch.

Wei.

 Ian.

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

[Xen-devel] [PATCH v3 05/19] libxl: add vmemrange to libxl__domain_build_state

2015-01-13 Thread Wei Liu 
A vnode consists of one or more vmemranges (virtual memory range).  One
example of multiple vmemranges is that there is a hole in one vnode.

Currently we haven't exported vmemrange interface to libxl user.
Vmemranges are generated during domain build, so we have relevant
structures in domain build state.

Later if we discover we need to export the interface, those structures
can be moved to libxl_domain_build_info as well.

Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Dario Faggioli dario.faggi...@citrix.com
Cc: Elena Ufimtseva ufimts...@gmail.com
---
Changes in v3:
1. Rewrite commit message.
---
 tools/libxl/libxl_internal.h |3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 934465a..6d3ac58 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -973,6 +973,9 @@ typedef struct {
 libxl__file_reference pv_ramdisk;
 const char * pv_cmdline;
 bool pvh_enabled;
+
+xen_vmemrange_t *vmemranges;
+uint32_t num_vmemranges;
 } libxl__domain_build_state;
 
 _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
-- 
1.7.10.4


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