Re: [Xen-devel] [PATCH] tools: fix python install with "xentoollog"

[Ian Campbell]

On Tue, 2016-01-12 at 22:16 -0500, Konrad Rzeszutek Wilk wrote:
> commit 5d3dc8671521ea4a4f753e77d3e7fb3a3a6f5f80
> "tools: Refactor "xentoollog" into its own library"
> with older python versions (2.6.4) will fail to
> the build if attempted to be done twice (which
> happens due to pygrub dependencies).
> 
> make -C python DESTDIR=/tmp
> make -C python DESTDIR=/tmp
> 
> The second one will fail with:
> error: -Wl, -rpath-link=../../tools/libs/toollog: No such file or
> directory
> 
> even thought the directory is there (with the libs).

"though"

> 
> Andrew pointed out that the linker additions should be in
> the "extra_link_args" rather than "depends".
> 
> And true enough - with that modification it builds.
> 
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Boris Ostrovsky 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Konrad Rzeszutek Wilk 

Acked + applied, with typo fixed.


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

Re: [Xen-devel] [PATCH v2 1/2] libxl: fix _SC_GETPW_R_SIZE_MAX usage

[Ian Campbell]

On Thu, 2016-01-14 at 16:06 +0100, Roger Pau Monne wrote:
> If sysconf(_SC_GETPW_R_SIZE_MAX) fails for any reason just use an initial
> buffer size of 2048. This is not a critical failure, and the code that
> makes use of this buffer is able to expand it later if required.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Ian Campbell 
> Cc: Wei Liu 

Acked-by: Ian Campbell 

Well done on your prescience on fixing all my comments on v1 before you'd
even seen them!

Applied.

> ---
> Changes since v1:
>  - Use a default buffer size if sysconf(_SC_GETPW_R_SIZE_MAX) fails for
> any
>    reason, this should not be a critical failure.
> ---
>  tools/libxl/libxl_dm.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 0aaefd9..a088d71 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -730,9 +730,10 @@ static int libxl__dm_runas_helper(libxl__gc *gc,
> const char *username)
>  
>  buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
>  if (buf_size < 0) {
> -LOGE(ERROR, "sysconf(_SC_GETPW_R_SIZE_MAX) returned error %ld",
> -buf_size);
> -return ERROR_FAIL;
> +buf_size = 2048;
> +LOG(DEBUG,
> +"sysconf(_SC_GETPW_R_SIZE_MAX) failed, setting the initial buffer size
> to %ld",
> +buf_size);
>  }
>  
>  while (1) {

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

Re: [Xen-devel] [PATCH v4 1/2] memory-hotplug: add automatic onlining policy for the newly added memory

[Vitaly Kuznetsov]

David Rientjes  writes:

> On Thu, 14 Jan 2016, Vitaly Kuznetsov wrote:
>
>> > My suggestion is to just simply document that auto-onlining can add the 
>> > memory but fail to online it and the failure is silent to userspace.  If 
>> > userspace cares, it can check the online status of the added memory blocks 
>> > itself.
>> 
>> The problem is not only that it's silent, but also that
>> /sys/devices/system/memory/*/state will lie as we create all memory
>> blocks in MEM_ONLINE state and from online_pages() error we can't figure
>> out which particular block failed. 'v5' which I sent yesterday is
>> supposed to fix the issue (blocks are onlined with
>> memory_block_change_state() which handles failures.
>> 
>
> Would you mind documenting that in the memory-hotplug.txt as an add-on 
> patch to your v5, which appears ready to go?

Sure,

I'll mention possible failures diring automatic onlining. It seems v5
wasn't picked by Andrew and I also have one nitpick in PATCH 2 to
address so I'll send v6.

Thanks,

-- 
  Vitaly

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

[Xen-devel] [PATCH XEN v8 12/29] tools/libs/foreignmemory: provide xenforeignmemory_unmap.

[Ian Campbell]

And require it be used instead of direct munmap.

This will allow e.g. Valgrind hooks to help track incorrect use of
foreign mappings.

Switch all uses of xenforeignmemory_map to use
xenforeignmemory_unmap, not that foreign mappings via the libxc compat
xc_map_foreign_* interface will not take advantage of this and will
need converting.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---
v4: xenforeignmemory_unmap takes pages not bytes, adjust callers.
v6: Document error behaviour
Use an osdep layer, although there is no current need for common
code on _unmap there is for _map so use this indirection for
consistency.
---
 tools/libs/foreignmemory/freebsd.c  |  6 ++
 tools/libs/foreignmemory/include/xenforeignmemory.h | 11 +--
 tools/libs/foreignmemory/libxenforeignmemory.map|  1 +
 tools/libs/foreignmemory/linux.c|  6 ++
 tools/libs/foreignmemory/minios.c   |  6 ++
 tools/libs/foreignmemory/netbsd.c   |  6 ++
 tools/libs/foreignmemory/solaris.c  |  6 ++
 tools/libxc/xc_sr_restore.c |  2 +-
 tools/libxc/xc_sr_save.c|  2 +-
 tools/libxc/xc_vm_event.c   |  2 +-
 10 files changed, 43 insertions(+), 5 deletions(-)

diff --git a/tools/libs/foreignmemory/freebsd.c 
b/tools/libs/foreignmemory/freebsd.c
index 4b2815d..3c3ad09 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -118,6 +118,12 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 return addr;
 }
 
+int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+ void *addr, unsigned int num)
+{
+   return munmap(addr, num << PAGE_SHIFT);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 5b3fa7a..b783af3 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -44,8 +44,8 @@ int xenforeignmemory_close(xenforeignmemory_handle *fmem);
 
 /*
  * Maps a range within one domain to a local address range.  Mappings
- * should be unmapped with munmap and should follow the same rules as mmap
- * regarding page alignment.
+ * must be unmapped with xenforeignmemory_unmap and should follow the
+ * same rules as mmap regarding page alignment.
  *
  * prot is as for mmap(2).
  *
@@ -57,6 +57,13 @@ int xenforeignmemory_close(xenforeignmemory_handle *fmem);
 void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
int prot, const xen_pfn_t *arr, int *err,
unsigned int num);
+/*
+ * Unmap a mapping previous created with xenforeignmemory_map().
+ *
+ * Returns 0 on success on failure sets errno and returns -1.
+ */
+int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+   void *addr, unsigned int num);
 
 #endif
 
diff --git a/tools/libs/foreignmemory/libxenforeignmemory.map 
b/tools/libs/foreignmemory/libxenforeignmemory.map
index 11f0d2b..df206b3 100644
--- a/tools/libs/foreignmemory/libxenforeignmemory.map
+++ b/tools/libs/foreignmemory/libxenforeignmemory.map
@@ -3,5 +3,6 @@ VERS_1.0 {
xenforeignmemory_open;
xenforeignmemory_close;
xenforeignmemory_map;
+   xenforeignmemory_unmap;
local: *; /* Do not expose anything by default */
 };
diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index b403ca7..40ecd41 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -282,6 +282,12 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 return addr;
 }
 
+int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+ void *addr, unsigned int num)
+{
+return munmap(addr, (unsigned long)num << PAGE_SHIFT);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/minios.c 
b/tools/libs/foreignmemory/minios.c
index a542e3d..5fcb861 100644
--- a/tools/libs/foreignmemory/minios.c
+++ b/tools/libs/foreignmemory/minios.c
@@ -51,6 +51,12 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
 }
 
+int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
+ void *addr, unsigned int num)
+{
+   return munmap(addr, num << PAGE_SHIFT);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/netbsd.c 
b/tools/libs/foreignmemory/netbsd.c
index 704a096..740c26f 100644
--- a/tools/libs/foreignmemory/netbsd.c
+++ b/tools/libs/foreignmemory/netbsd.c
@@ -94,6 +94,12 @@ 

[Xen-devel] [PATCH XEN v8 01/29] tools/libxc: Remove osdep indirection for xc_evtchn

[Ian Campbell]

The alternative backend (a xen-api/xapi shim) is no longer around and
so this stuff is now just baggage which is getting in the way of
refactoring libxenctrl.

Note that the intention is to move this into a separate library
shortly.

Nested virt probably suffices for this use case now.

One incorrect instance of using xc_interface where xc_evtchn (in ocaml
stubs) is removed, this used to work because they were typedefs to the
same struct, but is no longer permitted.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---
 tools/libxc/include/xenctrl.h |  2 +-
 tools/libxc/include/xenctrlosdep.h| 16 -
 tools/libxc/xc_evtchn.c   | 45 --
 tools/libxc/xc_freebsd_osdep.c| 79 
 tools/libxc/xc_linux_osdep.c  | 76 +--
 tools/libxc/xc_minios.c   | 63 ---
 tools/libxc/xc_netbsd.c   | 72 --
 tools/libxc/xc_private.c  | 37 +---
 tools/libxc/xc_private.h  | 17 ++
 tools/libxc/xc_solaris.c  | 71 --
 tools/libxc/xenctrl_osdep_ENOSYS.c| 87 ---
 tools/ocaml/libs/eventchn/xeneventchn_stubs.c |  4 +-
 12 files changed, 180 insertions(+), 389 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 01a6dda..881dcd5 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -117,7 +117,7 @@
  */
 
 typedef struct xc_interface_core xc_interface;
-typedef struct xc_interface_core xc_evtchn;
+typedef struct xenevtchn_handle xc_evtchn;
 typedef struct xc_interface_core xc_gnttab;
 typedef struct xc_interface_core xc_gntshr;
 
diff --git a/tools/libxc/include/xenctrlosdep.h 
b/tools/libxc/include/xenctrlosdep.h
index 5121d9b..89564e1 100644
--- a/tools/libxc/include/xenctrlosdep.h
+++ b/tools/libxc/include/xenctrlosdep.h
@@ -51,7 +51,6 @@
 
 enum xc_osdep_type {
 XC_OSDEP_PRIVCMD,
-XC_OSDEP_EVTCHN,
 XC_OSDEP_GNTTAB,
 XC_OSDEP_GNTSHR,
 };
@@ -90,21 +89,6 @@ struct xc_osdep_ops
 int nentries);
 } privcmd;
 struct {
-int (*fd)(xc_evtchn *xce, xc_osdep_handle h);
-
-int (*notify)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t 
port);
-
-evtchn_port_or_error_t (*bind_unbound_port)(xc_evtchn *xce, 
xc_osdep_handle h, int domid);
-evtchn_port_or_error_t (*bind_interdomain)(xc_evtchn *xce, 
xc_osdep_handle h, int domid,
-   evtchn_port_t 
remote_port);
-evtchn_port_or_error_t (*bind_virq)(xc_evtchn *xce, 
xc_osdep_handle h, unsigned int virq);
-
-int (*unbind)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t 
port);
-
-evtchn_port_or_error_t (*pending)(xc_evtchn *xce, xc_osdep_handle 
h);
-int (*unmask)(xc_evtchn *xce, xc_osdep_handle h, evtchn_port_t 
port);
-} evtchn;
-struct {
 #define XC_GRANT_MAP_SINGLE_DOMAIN 0x1
 void *(*grant_map)(xc_gnttab *xcg, xc_osdep_handle h,
uint32_t count, int flags, int prot,
diff --git a/tools/libxc/xc_evtchn.c b/tools/libxc/xc_evtchn.c
index 15f0580..ae2fe1a 100644
--- a/tools/libxc/xc_evtchn.c
+++ b/tools/libxc/xc_evtchn.c
@@ -77,51 +77,6 @@ int xc_evtchn_status(xc_interface *xch, xc_evtchn_status_t 
*status)
 sizeof(*status), 1);
 }
 
-int xc_evtchn_fd(xc_evtchn *xce)
-{
-return xce->ops->u.evtchn.fd(xce, xce->ops_handle);
-}
-
-int xc_evtchn_notify(xc_evtchn *xce, evtchn_port_t port)
-{
-return xce->ops->u.evtchn.notify(xce, xce->ops_handle, port);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_bind_unbound_port(xc_evtchn *xce, int domid)
-{
-return xce->ops->u.evtchn.bind_unbound_port(xce, xce->ops_handle, domid);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_bind_interdomain(xc_evtchn *xce, int domid,
-   evtchn_port_t remote_port)
-{
-return xce->ops->u.evtchn.bind_interdomain(xce, xce->ops_handle, domid, 
remote_port);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_bind_virq(xc_evtchn *xce, unsigned int virq)
-{
-return xce->ops->u.evtchn.bind_virq(xce, xce->ops_handle, virq);
-}
-
-int xc_evtchn_unbind(xc_evtchn *xce, evtchn_port_t port)
-{
-return xce->ops->u.evtchn.unbind(xce, xce->ops_handle, port);
-}
-
-evtchn_port_or_error_t
-xc_evtchn_pending(xc_evtchn *xce)
-{
-return xce->ops->u.evtchn.pending(xce, xce->ops_handle);
-}
-
-int xc_evtchn_unmask(xc_evtchn *xce, evtchn_port_t port)
-{
-return xce->ops->u.evtchn.unmask(xce, xce->ops_handle, port);
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_freebsd_osdep.c b/tools/libxc/xc_freebsd_osdep.c
index 4d31a1e..4323e16 100644
--- 

[Xen-devel] [PATCH XEN v8 03/29] tools: Arrange to check public headers for ANSI compatiblity

[Ian Campbell]

Using the same rune as we use for the Xen public headers, except we do
not need stdint.h here.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---
v7: Drop -pendantic: Some library headers include parts of
xen/include/public, which in turn are not -pedantic clean
Retained ack, hope that's ok.
---
 .gitignore  | 2 ++
 tools/Rules.mk  | 8 
 tools/libs/evtchn/Makefile  | 4 +++-
 tools/libs/toollog/Makefile | 5 -
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index f79a7b3..aa92d78 100644
--- a/.gitignore
+++ b/.gitignore
@@ -87,6 +87,8 @@ tools/config.cache
 config/Tools.mk
 config/Stubdom.mk
 config/Docs.mk
+tools/libs/toollog/headers.chk
+tools/libs/evtchn/headers.chk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow
 tools/blktap2/drivers/lock-util
diff --git a/tools/Rules.mk b/tools/Rules.mk
index 75d02c4..0c83e22 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -176,6 +176,14 @@ INSTALL_PYTHON_PROG = \
 %.opic: %.S
$(CC) $(CPPFLAGS) -DPIC $(CFLAGS) $(CFLAGS.opic) -fPIC -c -o $@ $< 
$(APPEND_CFLAGS)
 
+headers.chk:
+   for i in $(filter %.h,$^); do \
+   $(CC) -x c -ansi -Wall -Werror $(CFLAGS_xeninclude) \
+ -S -o /dev/null $$i || exit 1; \
+   echo $$i; \
+   done >$@.new
+   mv $@.new $@
+
 subdirs-all subdirs-clean subdirs-install subdirs-distclean: .phony
@set -e; for subdir in $(SUBDIRS) $(SUBDIRS-y); do \
$(MAKE) subdir-$(patsubst subdirs-%,%,$@)-$$subdir; \
diff --git a/tools/libs/evtchn/Makefile b/tools/libs/evtchn/Makefile
index 46a807f..9917864 100644
--- a/tools/libs/evtchn/Makefile
+++ b/tools/libs/evtchn/Makefile
@@ -32,8 +32,9 @@ build:
$(MAKE) libs
 
 .PHONY: libs
-libs: $(LIB)
+libs: headers.chk $(LIB)
 
+headers.chk: $(wildcard include/*.h)
 
 libxenevtchn.a: $(LIB_OBJS)
$(AR) rc $@ $^
@@ -64,6 +65,7 @@ TAGS:
 clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
rm -f libxenevtchn.so.$(MAJOR).$(MINOR) libxenevtchn.so.$(MAJOR)
+   rm -f headers.chk
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/libs/toollog/Makefile b/tools/libs/toollog/Makefile
index 9bfd179..fb701be 100644
--- a/tools/libs/toollog/Makefile
+++ b/tools/libs/toollog/Makefile
@@ -27,7 +27,9 @@ build:
$(MAKE) libs
 
 .PHONY: libs
-libs: $(LIB)
+libs: headers.chk $(LIB)
+
+headers.chk: $(wildcard include/*.h)
 
 libxentoollog.a: $(LIB_OBJS)
$(AR) rc $@ $^
@@ -58,6 +60,7 @@ TAGS:
 clean:
rm -rf *.rpm $(LIB) *~ $(DEPS) $(LIB_OBJS) $(PIC_OBJS)
rm -f libxentoollog.so.$(MAJOR).$(MINOR) libxentoollog.so.$(MAJOR)
+   rm -f headers.chk
 
 .PHONY: distclean
 distclean: clean
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 10/29] tools: Implement xc_map_foreign_range(s) in terms of common helper

[Ian Campbell]

Both Linux and FreeBSD already implemented these functions using
identical helpers based on xc_map_foreign_pages. Make one copy of
these common helpers and switch all OSes to use them, even those which
previously had a specific lower level implementation of this
functionality.

This is makes two fewer low level interfaces to think about.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---
 tools/libxc/xc_foreign_memory.c | 50 +
 tools/libxc/xc_freebsd_osdep.c  | 50 -
 tools/libxc/xc_linux_osdep.c| 49 -
 tools/libxc/xc_minios.c | 43 -
 tools/libxc/xc_netbsd.c | 70 -
 tools/libxc/xc_solaris.c| 67 ---
 6 files changed, 50 insertions(+), 279 deletions(-)

diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 2413e75..d1130e6 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -50,6 +50,56 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, 
int prot,
 return res;
 }
 
+void *xc_map_foreign_range(xc_interface *xch,
+   uint32_t dom, int size, int prot,
+   unsigned long mfn)
+{
+xen_pfn_t *arr;
+int num;
+int i;
+void *ret;
+
+num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
+arr = calloc(num, sizeof(xen_pfn_t));
+if ( arr == NULL )
+return NULL;
+
+for ( i = 0; i < num; i++ )
+arr[i] = mfn + i;
+
+ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
+free(arr);
+return ret;
+}
+
+void *xc_map_foreign_ranges(xc_interface *xch,
+uint32_t dom, size_t size,
+int prot, size_t chunksize,
+privcmd_mmap_entry_t entries[],
+int nentries)
+{
+xen_pfn_t *arr;
+int num_per_entry;
+int num;
+int i;
+int j;
+void *ret;
+
+num_per_entry = chunksize >> XC_PAGE_SHIFT;
+num = num_per_entry * nentries;
+arr = calloc(num, sizeof(xen_pfn_t));
+if ( arr == NULL )
+return NULL;
+
+for ( i = 0; i < nentries; i++ )
+for ( j = 0; j < num_per_entry; j++ )
+arr[i * num_per_entry + j] = entries[i].mfn + j;
+
+ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
+free(arr);
+return ret;
+}
+
 /*
  * stub for all not yet converted OSes (NetBSD and Solaris). New OSes should
  * just implement xc_map_foreign_bulk.
diff --git a/tools/libxc/xc_freebsd_osdep.c b/tools/libxc/xc_freebsd_osdep.c
index 6b440ee..7745d28 100644
--- a/tools/libxc/xc_freebsd_osdep.c
+++ b/tools/libxc/xc_freebsd_osdep.c
@@ -125,56 +125,6 @@ void *xc_map_foreign_bulk(xc_interface *xch,
 return addr;
 }
 
-void *xc_map_foreign_range(xc_interface *xch,
-   uint32_t dom, int size, int prot,
-   unsigned long mfn)
-{
-xen_pfn_t *arr;
-int num;
-int i;
-void *ret;
-
-num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
-arr = calloc(num, sizeof(xen_pfn_t));
-if ( arr == NULL )
-return NULL;
-
-for ( i = 0; i < num; i++ )
-arr[i] = mfn + i;
-
-ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
-free(arr);
-return ret;
-}
-
-void *xc_map_foreign_ranges(xc_interface *xch,
-uint32_t dom, size_t size,
-int prot, size_t chunksize,
-privcmd_mmap_entry_t entries[],
-int nentries)
-{
-xen_pfn_t *arr;
-int num_per_entry;
-int num;
-int i;
-int j;
-void *ret;
-
-num_per_entry = chunksize >> XC_PAGE_SHIFT;
-num = num_per_entry * nentries;
-arr = calloc(num, sizeof(xen_pfn_t));
-if ( arr == NULL )
-return NULL;
-
-for ( i = 0; i < nentries; i++ )
-for ( j = 0; j < num_per_entry; j++ )
-arr[i * num_per_entry + j] = entries[i].mfn + j;
-
-ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
-free(arr);
-return ret;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index 39c88ce..acf44ce 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -290,55 +290,6 @@ void *xc_map_foreign_bulk(xc_interface *xch,
 return addr;
 }
 
-void *xc_map_foreign_range(xc_interface *xch,
-   uint32_t dom, int size, int prot,
-   unsigned long mfn)
-{
-xen_pfn_t *arr;
-int num;
-int i;
-void *ret;
-
-num = (size + XC_PAGE_SIZE - 1) >> XC_PAGE_SHIFT;
-arr = calloc(num, sizeof(xen_pfn_t));
-if ( arr == NULL )
-return NULL;
-
-for ( i = 0; i < num; i++ )
-arr[i] = mfn + i;
-
-ret = 

[Xen-devel] [PATCH XEN v8 04/29] tools/libxc: Remove osdep indirection for xc_gnt{shr, tab}

[Ian Campbell]

The alternative backend (a xen-api/xapi shim) is no longer around and
so this stuff is now just baggage which is getting in the way of
refactoring libxenctrl.

Nested virt probably suffices for this use case now.

It is now necessary to provide explicit versions of things for
platforms which do not implement this functionality, since the osdep
dispatcher cannot fulfil this need any more. These are provided by
appropriate xc_nognt???.c files which are compiled and linked on the
appropriate platforms. In them open and close return failure and
everything else aborts, since if open fails they should never be
called.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---
 tools/libxc/Makefile   |  10 ++--
 tools/libxc/include/xenctrl.h  |   4 +-
 tools/libxc/include/xenctrlosdep.h |  23 ---
 tools/libxc/xc_gnttab.c|  57 --
 tools/libxc/xc_linux_osdep.c   | 119 +++--
 tools/libxc/xc_minios.c|  51 ++--
 tools/libxc/xc_nogntshr.c  |  46 ++
 tools/libxc/xc_nognttab.c  |  50 
 tools/libxc/xc_private.c   |  83 +-
 tools/libxc/xc_private.h   |  24 
 10 files changed, 274 insertions(+), 193 deletions(-)
 create mode 100644 tools/libxc/xc_nogntshr.c
 create mode 100644 tools/libxc/xc_nognttab.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index b8fc6a5..184cbb7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -43,11 +43,11 @@ CTRL_SRCS-y   += xc_resource.c
 CTRL_SRCS-$(CONFIG_X86) += xc_psr.c
 CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
 CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
-CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
-CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
-CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
+CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c xc_nognttab.c 
xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c xc_nognttab.c xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c xc_nognttab.c xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_netbsd.c xc_nognttab.c xc_nogntshr.c
+CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_nogntshr.c
 CTRL_SRCS-y   += xc_evtchn_compat.c
 
 GUEST_SRCS-y :=
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 8f31c4d..0fc2a11 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -117,8 +117,8 @@
  */
 
 typedef struct xc_interface_core xc_interface;
-typedef struct xc_interface_core xc_gnttab;
-typedef struct xc_interface_core xc_gntshr;
+typedef struct xengntdev_handle xc_gnttab;
+typedef struct xengntdev_handle xc_gntshr;
 
 enum xc_error_code {
   XC_ERROR_NONE = 0,
diff --git a/tools/libxc/include/xenctrlosdep.h 
b/tools/libxc/include/xenctrlosdep.h
index 89564e1..423660d 100644
--- a/tools/libxc/include/xenctrlosdep.h
+++ b/tools/libxc/include/xenctrlosdep.h
@@ -51,8 +51,6 @@
 
 enum xc_osdep_type {
 XC_OSDEP_PRIVCMD,
-XC_OSDEP_GNTTAB,
-XC_OSDEP_GNTSHR,
 };
 
 /* Opaque handle internal to the backend */
@@ -88,27 +86,6 @@ struct xc_osdep_ops
 size_t chunksize, privcmd_mmap_entry_t 
entries[],
 int nentries);
 } privcmd;
-struct {
-#define XC_GRANT_MAP_SINGLE_DOMAIN 0x1
-void *(*grant_map)(xc_gnttab *xcg, xc_osdep_handle h,
-   uint32_t count, int flags, int prot,
-   uint32_t *domids, uint32_t *refs,
-   uint32_t notify_offset,
-   evtchn_port_t notify_port);
-int (*munmap)(xc_gnttab *xcg, xc_osdep_handle h,
-  void *start_address,
-  uint32_t count);
-int (*set_max_grants)(xc_gnttab *xcg, xc_osdep_handle h, uint32_t 
count);
-} gnttab;
-struct {
-void *(*share_pages)(xc_gntshr *xcg, xc_osdep_handle h,
- uint32_t domid, int count,
- uint32_t *refs, int writable,
- uint32_t notify_offset,
- evtchn_port_t notify_port);
-int (*munmap)(xc_gntshr *xcg, xc_osdep_handle h,
-  void *start_address, uint32_t count);
-} gntshr;
 } u;
 };
 typedef struct xc_osdep_ops xc_osdep_ops;
diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c
index 60335d8..a51f405 100644
--- a/tools/libxc/xc_gnttab.c
+++ b/tools/libxc/xc_gnttab.c
@@ -143,68 +143,48 @@ grant_entry_v2_t *xc_gnttab_map_table_v2(xc_interface 
*xch, int domid,
 return _gnttab_map_table(xch, domid, gnt_num);
 }
 
-void 

[Xen-devel] [PATCH XEN v8 00/29] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell]

We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.

This is the xen part of the first phase of that change.

This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.

Ian Campbell (29):
  tools/libxc: Remove osdep indirection for xc_evtchn
  tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.
  tools: Arrange to check public headers for ANSI compatiblity
  tools/libxc: Remove osdep indirection for xc_gnt{shr,tab}
  tools: Refactor /dev/xen/gnt{dev,shr} wrappers into libxengnttab.
  tools/libxc: Remove osdep indirection for privcmd
  tools: Refactor hypercall calling wrappers into libxencall.
  tools/libxc: drop xc_map_foreign_bulk_compat wrappers
  tools: Remove xc_map_foreign_batch
  tools: Implement xc_map_foreign_range(s) in terms of common helper
  tools: Refactor foreign memory mapping into libxenforeignmemory
  tools/libs/foreignmemory: provide xenforeignmemory_unmap.
  tools/libs/foreignmemory: use size_t for size arguments.
  tools/libs/foreignmemory: Mention restrictions on fork in docs.
  tools/libs/foreignmemory: Support err == NULL to map.
  tools/libs/foreignmemory: pull array length argument to map forward
  tools/libs/evtchn: Review and update doc comments.
  tools/libs/evtchn: Use uint32_t for domid arguments
  tools/libs: Clean up hard tabs.
  tools/libs/gnttab: Extensive updates to API documentation.
  tools/libs/call: Update some log messages to not refer to xc.
  tools/libs/call: Describe return values and error semantics for
xencall*
  tools/libs/call: Avoid xc_memalign in netbsd and solaris backends
  tools/libs/call: linux: touch newly allocated pages after madvise
lockdown
  tools/libs/{call,evtchn}: Document requirements around forking.
  tools/libs/*: Use O_CLOEXEC on Linux and FreeBSD
  tools: Update CFLAGS for qemu-xen to allow it to use new libraries
  tools/libs/*: Introduce APIs to restrict handles to a specific domain.
  HACK: Update Config.mk to pull all the right bits from my xenbits
trees

 .gitignore |   9 +
 Config.mk  |  22 +-
 config/FreeBSD.mk  |   2 -
 config/NetBSD.mk   |   3 -
 config/NetBSDRump.mk   |   1 -
 config/StdGNU.mk   |   1 -
 config/SunOS.mk|   1 -
 stubdom/Makefile   |  62 +-
 tools/Makefile |  15 +-
 tools/Rules.mk |  44 +-
 tools/console/Makefile |   3 +-
 tools/console/daemon/io.c  |  64 +-
 tools/console/daemon/utils.c   |   1 -
 tools/console/daemon/utils.h   |   1 +
 tools/libs/Makefile|   4 +
 tools/libs/call/Makefile   |  71 ++
 tools/libs/call/buffer.c   | 192 +
 tools/libs/call/core.c | 154 
 tools/libs/call/freebsd.c  | 126 +++
 tools/libs/call/include/xencall.h  | 161 
 tools/libs/call/libxencall.map |  21 +
 tools/libs/call/linux.c| 134 +++
 tools/libs/call/minios.c   |  81 ++
 tools/libs/call/netbsd.c   | 121 +++
 tools/libs/call/private.h  |  68 ++
 tools/libs/call/solaris.c  |  97 +++
 tools/libs/evtchn/Makefile |  71 ++
 tools/libs/evtchn/core.c   |  79 ++
 tools/libs/evtchn/freebsd.c| 138 
 tools/libs/evtchn/include/xenevtchn.h  | 199 +
 tools/libs/evtchn/libxenevtchn.map |  21 +
 tools/libs/evtchn/linux.c  | 140 
 tools/libs/evtchn/minios.c | 266 ++
 tools/libs/evtchn/netbsd.c | 147 
 tools/libs/evtchn/private.h|  25 +
 tools/libs/evtchn/solaris.c| 135 +++
 tools/libs/foreignmemory/Makefile  |  71 ++
 tools/libs/foreignmemory/compat.c  |  72 ++
 tools/libs/foreignmemory/core.c| 123 +++
 tools/libs/foreignmemory/freebsd.c | 115 +++
 .../libs/foreignmemory/include/xenforeignmemory.h  | 150 
 tools/libs/foreignmemory/libxenforeignmemory.map   |  11 +
 tools/libs/foreignmemory/linux.c   | 283 +++
 tools/libs/foreignmemory/minios.c  |  69 ++
 tools/libs/foreignmemory/netbsd.c  | 111 +++
 tools/libs/foreignmemory/private.h |  54 ++
 

[Xen-devel] [Minios-devel] [PATCH v8 0/] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell]

In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
parts of the libxenctrl API/ABI by disaggregating into separate
libraries.

This is v8 of that set of series against:
xen
qemu-xen
qemu-xen-traditional
mini-os

NB: Samuel+minios-devel will only get the mini-os side and Stefano+qemu
-devel the qemu-xen side.

The code for all repos can be found in:

git://xenbits.xen.org/people/ianc/libxenctrl-split/xen.git  v8
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen.git v8
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen-traditional.git v8
git://xenbits.xen.org/people/ianc/libxenctrl-split/mini-os.git  v8

The tip of the xen.git branch contains an extra patch hacking Config.mk
to point to all the others above, which should get the correct things for
the HEAD of the branch, but not further back in time.

The new libraries here are:

 * libxentoollog: Common logging infrastructure (already in tree)
 * libxenevtchn: Userspace access to evtchns (via /dev/xen/evtchn etc)
 * libxengnttab: Userspace access to grant tables (via /dev/xen/gnt??? etc)
 * libxencall: Making hypercalls (i.e. the IOCTL_PRIVCMD_HYPERCALL type
   functionality)
 * libxenforeignmemory: Privileged mappings of foreign memory
   (IOCTL_PRIVCMD_MMAP et al)

The first three were actually pretty distinct within libxenctrl already and
have not changed in quite some time.

Although the other two are somewhat new they are based on top of long
standing stable ioctls, which gives me some confidence.

Nonetheless I would appreciate extra review of at least the interface
headers of all of these with a particular eye to the suitability of these
interfaces being maintained in an ABI (_B_, not _P_) stable way going
forward.

Still to come would be libraries for specific out of tree purposes
(device model, kexec), which would be adding new library at the same
level as libxc I think, rather than underneath, i.e. also using the
libraries split out here, but hopefully not libxenctrl itself.

The new libraries use linker version-scripts to hopefully make future
ABI changes be possible in a compatible way.

Since last time:

 * Some early bits went in.
 * Rebased
 * Clean up the *.so in clean, added distclean targets to each lib
 * On the QEMU side use CONFIG_XEN_CTRL_INTERFACE_VERSION == 471 as the
   gate for this new setup (dropped a Reviewed-by).

Even with the dropped acks mini-os and qemu-xen-trad are fully acked (by
Samuel+Wei and Ian J respectively), while qemu-xen and xen are mostly acked
(but had a few dropped acks since last time).

Summary for qemu-xen.git:
 R  xen_console: correctly cleanup primary console on teardown.
 R  xen: Switch to libxenevtchn interface for compat shims.
 R  xen: Switch to libxengnttab interface for compat shims.
 R  xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages
  M xen: Switch uses of xc_map_foreign_{pages,bulk} to use 
libxenforeignmemory API.
  M xen: Use stable library interfaces when they are available.
A   xen: domainbuild: reopen libxenctrl interface after forking for domain 
watcher.
 R  xen: make it possible to build without the Xen PV domain builder

(A == Acked by Stefano, R == Reviewed by Stefano, M == Modified in v8)

NB: qemu-xen-traditional.git, mini-os.git and xen.git are intertwined, but
the qemu-xen.git part is independent and should be applied after all the
rest of these series.

Summary for xen.git:

 W  tools/libxc: Remove osdep indirection for xc_evtchn
MWI tools: Refactor /dev/xen/evtchn wrappers into libxenevtchn.
 W  tools: Arrange to check public headers for ANSI compatiblity
 W  tools/libxc: Remove osdep indirection for xc_gnt{shr,tab}
MW  tools: Refactor /dev/xen/gnt{dev,shr} wrappers into libxengnttab.
 WS tools/libxc: Remove osdep indirection for privcmd
MW  tools: Refactor hypercall calling wrappers into libxencall.
 W  tools/libxc: drop xc_map_foreign_bulk_compat wrappers
 W   G  tools: Remove xc_map_foreign_batch
 W  tools: Implement xc_map_foreign_range(s) in terms of common helper
MWI tools: Refactor foreign memory mapping into libxenforeignmemory
 WI tools/libs/foreignmemory: provide xenforeignmemory_unmap.
 WI tools/libs/foreignmemory: use size_t for size arguments.
tools/libs/foreignmemory: Mention restrictions on fork in docs.
 WI tools/libs/foreignmemory: Support err == NULL to map.
 WI tools/libs/foreignmemory: pull array length argument to map forward
 WI tools/libs/evtchn: Review and update doc comments.
N   tools/libs/evtchn: Use uint32_t for domid arguments
 W  tools/libs: Clean up hard tabs.
D   tools/libs/gnttab: Extensive updates to API documentation.
 W  tools/libs/call: Update some log messages to not refer to xc.
 WIRtools/libs/call: Describe return values and error semantics for xencall*
 W  tools/libs/call: Avoid xc_memalign in netbsd and 

[Xen-devel] [PATCH XEN v8 08/29] tools/libxc: drop xc_map_foreign_bulk_compat wrappers

[Ian Campbell]

On Solaris and NetBSD xc_map_foreign_bulk is implemented by calling
xc_map_foreign_bulk_compat and xc_map_foreign_bulk_compat is exposed
as a symbol by libxenctrl.so.

Remove these wrappers and turn the compat function into the real thing
surrounded by the appropriate ifdef.

As this is a compat function all new ports should instead implement
xc_map_foreign_bulk properly, hence the ifdef should never be
expanded.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---
 tools/libxc/xc_foreign_memory.c | 13 +
 tools/libxc/xc_netbsd.c |  7 ---
 tools/libxc/xc_private.h|  5 -
 tools/libxc/xc_solaris.c|  7 ---
 4 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 9c705b6..b205bca 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -50,10 +50,14 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, 
int prot,
 return res;
 }
 
-/* stub for all not yet converted OSes */
-void *xc_map_foreign_bulk_compat(xc_interface *xch,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int 
num)
+/*
+ * stub for all not yet converted OSes (NetBSD and Solaris). New OSes should
+ * just implement xc_map_foreign_bulk.
+ */
+#if defined(__NetBSD__) || defined(__sun__)
+void *xc_map_foreign_bulk(xc_interface *xch,
+  uint32_t dom, int prot,
+  const xen_pfn_t *arr, int *err, unsigned int num)
 {
 xen_pfn_t *pfn;
 unsigned int i;
@@ -90,6 +94,7 @@ void *xc_map_foreign_bulk_compat(xc_interface *xch,
 
 return ret;
 }
+#endif
 
 /*
  * Local variables:
diff --git a/tools/libxc/xc_netbsd.c b/tools/libxc/xc_netbsd.c
index 5e3b343..d7f7f31 100644
--- a/tools/libxc/xc_netbsd.c
+++ b/tools/libxc/xc_netbsd.c
@@ -67,13 +67,6 @@ int osdep_privcmd_close(xc_interface *xch)
 return close(fd);
 }
 
-void *xc_map_foreign_bulk(xc_interface *xch,
-  uint32_t dom, int prot,
-  const xen_pfn_t *arr, int *err, unsigned int num)
-{
-return xc_map_foreign_bulk_compat(xch, dom, prot, arr, err, num);
-}
-
 void *xc_map_foreign_batch(xc_interface *xch,
uint32_t dom, int prot,
xen_pfn_t *arr, int num)
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index c93df7f..ecf2451 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -107,11 +107,6 @@ int osdep_privcmd_close(xc_interface *xch);
 void *osdep_alloc_hypercall_buffer(xc_interface *xch, int npages);
 void osdep_free_hypercall_buffer(xc_interface *xch, void *ptr, int npages);
 
-/* Stub for not yet converted OSes */
-void *xc_map_foreign_bulk_compat(xc_interface *xch,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int 
num);
-
 void xc_report_error(xc_interface *xch, int code, const char *fmt, ...)
 __attribute__((format(printf,3,4)));
 void xc_reportv(xc_interface *xch, xentoollog_logger *lg, xentoollog_level,
diff --git a/tools/libxc/xc_solaris.c b/tools/libxc/xc_solaris.c
index 18622fa..5e72dee 100644
--- a/tools/libxc/xc_solaris.c
+++ b/tools/libxc/xc_solaris.c
@@ -94,13 +94,6 @@ void *xc_map_foreign_batch(xc_interface *xch,
 
 }
 
-void *xc_map_foreign_bulk(xc_interface *xch,
-  uint32_t dom, int prot,
-  const xen_pfn_t *arr, int *err, unsigned int num)
-{
-return xc_map_foreign_bulk_compat(xch, dom, prot, arr, err, num);
-}
-
 void *xc_map_foreign_range(xc_interface *xch,
uint32_t dom,
int size, int prot,
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 09/29] tools: Remove xc_map_foreign_batch

[Ian Campbell]

It can trivially be replaced by xc_map_foreign_pages which is the
interface I want to move to going forward (by standardising on _bulk
but handling err=NULL as _pages does).

The callers of _batch are checking a mixture of a NULL return or
looking to see if the top nibble of the (usually sole) mfn they pass
has been modified to be non-zero to detect errors. _pages never
modifies the mfn it was given (it's const) and returns NULL on
failure, so adjust the error handling where necessary. Some callers
use a copy of the mfn array, for reuse on failure with _batch, which
is no longer necessary as _pages doesn't modify the array, however I
haven't cleaned that up here.

This reduces the twist maze of xc_map_foreign_* by one, which will be
useful when trying to come up with an underlying stable interface.

NetBSD and Solaris implemented xc_map_foreign_bulk in terms of
xc_map_foreign_batch via a compat layer, so xc_map_foreign_batch
becomes an internal osdep for them.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
Acked-by: George Dunlap 
Cc: George Dunlap 
---
v7: Don't mention new ports implementing _bulk, which is confusing and
will be obsolete a couple of patches later.
v6: Switch to xc_map_foreign_pages not xc_map_foreign_bulk, since the
former has more similar error handling semantics to the current
usage.

Dropped acks.
---
 tools/libxc/include/xenctrl.h   | 10 ---
 tools/libxc/xc_foreign_memory.c |  4 ++-
 tools/libxc/xc_linux_osdep.c| 59 +++--
 tools/libxc/xc_minios.c | 22 ---
 tools/libxc/xc_netbsd.c | 10 +++
 tools/libxc/xc_solaris.c|  6 ++---
 tools/libxc/xc_vm_event.c   | 18 ++---
 tools/xenmon/xenbaked.c | 12 -
 tools/xenpaging/xenpaging.c | 14 +-
 tools/xentrace/xentrace.c   |  3 ++-
 10 files changed, 48 insertions(+), 110 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 78400d3..cb41c07 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1387,16 +1387,6 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t 
dom, int prot,
const xen_pfn_t *arr, int num );
 
 /**
- * DEPRECATED - use xc_map_foreign_bulk() instead.
- *
- * Like xc_map_foreign_pages(), except it can succeeed partially.
- * When a page cannot be mapped, its PFN in @arr is or'ed with
- * 0xF000 to indicate the error.
- */
-void *xc_map_foreign_batch(xc_interface *xch, uint32_t dom, int prot,
-   xen_pfn_t *arr, int num );
-
-/**
  * Like xc_map_foreign_pages(), except it can succeed partially.
  * When a page cannot be mapped, its respective field in @err is
  * set to the corresponding errno value.
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index b205bca..2413e75 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -55,6 +55,8 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, 
int prot,
  * just implement xc_map_foreign_bulk.
  */
 #if defined(__NetBSD__) || defined(__sun__)
+void *osdep_map_foreign_batch(xc_interface *xch, uint32_t dom, int prot,
+  xen_pfn_t *arr, int num );
 void *xc_map_foreign_bulk(xc_interface *xch,
   uint32_t dom, int prot,
   const xen_pfn_t *arr, int *err, unsigned int num)
@@ -75,7 +77,7 @@ void *xc_map_foreign_bulk(xc_interface *xch,
 }
 
 memcpy(pfn, arr, num * sizeof(*arr));
-ret = xc_map_foreign_batch(xch, dom, prot, pfn, num);
+ret = osdep_map_foreign_batch(xch, dom, prot, pfn, num);
 
 if (ret) {
 for (i = 0; i < num; ++i)
diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
index e68c495..39c88ce 100644
--- a/tools/libxc/xc_linux_osdep.c
+++ b/tools/libxc/xc_linux_osdep.c
@@ -91,8 +91,8 @@ int osdep_privcmd_close(xc_interface *xch)
 return close(fd);
 }
 
-static int xc_map_foreign_batch_single(int fd, uint32_t dom,
-   xen_pfn_t *mfn, unsigned long addr)
+static int map_foreign_batch_single(int fd, uint32_t dom,
+xen_pfn_t *mfn, unsigned long addr)
 {
 privcmd_mmapbatch_t ioctlx;
 int rc;
@@ -113,59 +113,6 @@ static int xc_map_foreign_batch_single(int fd, uint32_t 
dom,
 return rc;
 }
 
-void *xc_map_foreign_batch(xc_interface *xch,
-   uint32_t dom, int prot,
-   xen_pfn_t *arr, int num)
-{
-int fd = xch->privcmdfd;
-privcmd_mmapbatch_t ioctlx;
-void *addr;
-int rc;
-
-addr = mmap(NULL, num << XC_PAGE_SHIFT, prot, MAP_SHARED, fd, 0);
-if ( addr == MAP_FAILED )
-{
-PERROR("xc_map_foreign_batch: mmap failed");
-return NULL;
-}
-
-

[Xen-devel] [PATCH XEN v8 17/29] tools/libs/evtchn: Review and update doc comments.

[Ian Campbell]

Remove the reference to pre-4.1, since this is now a new library.

Fixup references to xc.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libs/evtchn/include/xenevtchn.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/libs/evtchn/include/xenevtchn.h 
b/tools/libs/evtchn/include/xenevtchn.h
index 3380fa3..60da2a3 100644
--- a/tools/libs/evtchn/include/xenevtchn.h
+++ b/tools/libs/evtchn/include/xenevtchn.h
@@ -46,11 +46,9 @@ typedef struct xentoollog_logger xentoollog_logger;
  * which case errno will be set appropriately.
  *
  * Note:
- * After fork a child process must not use any opened xc evtchn
+ * After fork a child process must not use any opened evtchn
  * handle inherited from their parent. They must open a new handle if
- * they want to interact with xc.
- *
- * Before Xen pre-4.1 this function would sometimes report errors with perror.
+ * they want to interact with evtchn.
  */
 /* Currently no flags are defined */
 xenevtchn_handle *xenevtchn_open(xentoollog_logger *logger, unsigned 
open_flags);
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 16/29] tools/libs/foreignmemory: pull array length argument to map forward

[Ian Campbell]

By having the "num" argument before the page and error arrays we can
potentially use a variable-length-array argument ("int pages[num]") in
the function prototype.

However VLAs are a C99 feature and we are currently targetting C89 and
later, so we don't actually make use of this here, merely arrange that
we can switch to VLAs in the future without changing the function ABI.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---
v6: New
---
 tools/libs/foreignmemory/compat.c   | 4 ++--
 tools/libs/foreignmemory/core.c | 5 +++--
 tools/libs/foreignmemory/freebsd.c  | 4 ++--
 tools/libs/foreignmemory/include/xenforeignmemory.h | 4 ++--
 tools/libs/foreignmemory/linux.c| 3 ++-
 tools/libs/foreignmemory/minios.c   | 3 ++-
 tools/libs/foreignmemory/private.h  | 3 ++-
 tools/libxc/xc_foreign_memory.c | 4 ++--
 tools/libxc/xc_sr_restore.c | 2 +-
 tools/libxc/xc_sr_save.c| 2 +-
 10 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/tools/libs/foreignmemory/compat.c 
b/tools/libs/foreignmemory/compat.c
index 039297c..b79ec1a 100644
--- a/tools/libs/foreignmemory/compat.c
+++ b/tools/libs/foreignmemory/compat.c
@@ -22,8 +22,8 @@
 #include "private.h"
 
 void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, size_t num)
+ uint32_t dom, int prot, size_t num,
+ const xen_pfn_t arr[/*num*/], int 
err[/*num*/])
 {
 xen_pfn_t *pfn;
 unsigned int i;
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index 4e0541f..cfb0a73 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -64,7 +64,8 @@ int xenforeignmemory_close(xenforeignmemory_handle *fmem)
 
 void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, int prot,
-   const xen_pfn_t *arr, int *err, size_t num)
+   size_t num,
+   const xen_pfn_t arr[/*num*/], int err[/*num*/])
 {
 void *ret;
 int *err_to_free = NULL;
@@ -75,7 +76,7 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
 if ( err == NULL )
 return NULL;
 
-ret = osdep_xenforeignmemory_map(fmem, dom, prot, arr, err, num);
+ret = osdep_xenforeignmemory_map(fmem, dom, prot, num, arr, err);
 
 if ( ret == 0 && err_to_free )
 {
diff --git a/tools/libs/foreignmemory/freebsd.c 
b/tools/libs/foreignmemory/freebsd.c
index ed26ebb..703754f 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -84,8 +84,8 @@ int osdep_xenforeignmemory_close(xenforeignmemory_handle 
*fmem)
 
 void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
  uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err,
- size_t num)
+ size_t num,
+ const xen_pfn_t arr[/*num*/], int 
err[/*num*/])
 {
 int fd = fmem->fd;
 privcmd_mmapbatch_t ioctlx;
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 0ec6325..3724c63 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -104,8 +104,8 @@ int xenforeignmemory_close(xenforeignmemory_handle *fmem);
  * of @err indicating failure to map every page.
  */
 void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
-   int prot, const xen_pfn_t *arr, int *err,
-   size_t pages);
+   int prot, size_t pages,
+   const xen_pfn_t arr[/*pages*/], int err[/*pages*/]);
 
 /*
  * Unmap a mapping previous created with xenforeignmemory_map().
diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index 6620391..32b6def 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -161,7 +161,8 @@ out:
 
 void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
  uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, size_t num)
+ size_t num,
+ const xen_pfn_t arr[/*num*/], int 
err[/*num*/])
 {
 int fd = fmem->fd;
 privcmd_mmapbatch_v2_t ioctlx;
diff --git a/tools/libs/foreignmemory/minios.c 
b/tools/libs/foreignmemory/minios.c
index bdc1239..ca5ba71 100644
--- 

[Xen-devel] [PATCH XEN v8 13/29] tools/libs/foreignmemory: use size_t for size arguments.

[Ian Campbell]

Surprisingly it appears no callers need updating.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---
v4: New patch
---
 tools/libs/foreignmemory/compat.c  |  2 +-
 tools/libs/foreignmemory/freebsd.c |  4 ++--
 .../libs/foreignmemory/include/xenforeignmemory.h  |  5 +++--
 tools/libs/foreignmemory/linux.c   | 23 +++---
 tools/libs/foreignmemory/minios.c  |  4 ++--
 tools/libs/foreignmemory/netbsd.c  |  2 +-
 tools/libs/foreignmemory/solaris.c |  2 +-
 7 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/tools/libs/foreignmemory/compat.c 
b/tools/libs/foreignmemory/compat.c
index b8c6fc6..039297c 100644
--- a/tools/libs/foreignmemory/compat.c
+++ b/tools/libs/foreignmemory/compat.c
@@ -23,7 +23,7 @@
 
 void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
  uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, unsigned int 
num)
+ const xen_pfn_t *arr, int *err, size_t num)
 {
 xen_pfn_t *pfn;
 unsigned int i;
diff --git a/tools/libs/foreignmemory/freebsd.c 
b/tools/libs/foreignmemory/freebsd.c
index 3c3ad09..ed26ebb 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -85,7 +85,7 @@ int osdep_xenforeignmemory_close(xenforeignmemory_handle 
*fmem)
 void *osdep_xenforeignmemory_map(xenforeignmemory_handle *fmem,
  uint32_t dom, int prot,
  const xen_pfn_t *arr, int *err,
- unsigned int num)
+ size_t num)
 {
 int fd = fmem->fd;
 privcmd_mmapbatch_t ioctlx;
@@ -119,7 +119,7 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 }
 
 int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
- void *addr, unsigned int num)
+ void *addr, size_t num)
 {
return munmap(addr, num << PAGE_SHIFT);
 }
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index b783af3..04ff548 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -56,14 +56,15 @@ int xenforeignmemory_close(xenforeignmemory_handle *fmem);
  */
 void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
int prot, const xen_pfn_t *arr, int *err,
-   unsigned int num);
+   size_t pages);
+
 /*
  * Unmap a mapping previous created with xenforeignmemory_map().
  *
  * Returns 0 on success on failure sets errno and returns -1.
  */
 int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
-   void *addr, unsigned int num);
+   void *addr, size_t pages);
 
 #endif
 
diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index 40ecd41..6620391 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -115,10 +115,11 @@ static int map_foreign_batch_single(int fd, uint32_t dom,
  * This will keep the request ring full and avoids delays.
  */
 static int retry_paged(int fd, uint32_t dom, void *addr,
-   const xen_pfn_t *arr, int *err, unsigned int num)
+   const xen_pfn_t *arr, int *err, size_t num)
 {
 privcmd_mmapbatch_v2_t ioctlx;
-int rc, paged = 0, i = 0;
+int rc, paged = 0;
+size_t i = 0;
 
 do
 {
@@ -134,7 +135,7 @@ static int retry_paged(int fd, uint32_t dom, void *addr,
 /* At least one gfn is still in paging state */
 ioctlx.num = 1;
 ioctlx.dom = dom;
-ioctlx.addr = (unsigned long)addr + ((unsigned long)i<fd;
 privcmd_mmapbatch_v2_t ioctlx;
 void *addr;
-unsigned int i;
+size_t i;
 int rc;
 
-addr = mmap(NULL, (unsigned long)num << PAGE_SHIFT, prot, MAP_SHARED,
+addr = mmap(NULL, num << PAGE_SHIFT, prot, MAP_SHARED,
 fd, 0);
 if ( addr == MAP_FAILED )
 {
@@ -212,7 +213,7 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 if ( pfn == MAP_FAILED )
 {
 PERROR("mmap 

[Xen-devel] [PATCH XEN v8 29/29] HACK: Update Config.mk to pull all the right bits from my xenbits trees

[Ian Campbell]

v4: Config.mk instead of .config
---
 Config.mk | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/Config.mk b/Config.mk
index d654af8..364e790 100644
--- a/Config.mk
+++ b/Config.mk
@@ -238,22 +238,22 @@ endif
 
 ifeq ($(GIT_HTTP),y)
 OVMF_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/ovmf.git
-QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-xen.git
-QEMU_TRADITIONAL_URL ?= 
http://xenbits.xen.org/git-http/qemu-xen-traditional.git
+QEMU_UPSTREAM_URL ?= 
http://xenbits.xen.org/git-http/people/ianc/libxenctrl-split/qemu-xen.git
+QEMU_TRADITIONAL_URL ?= 
http://xenbits.xen.org/git-http/people/ianc/libxenctrl-split/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
-MINIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/mini-os.git
+MINIOS_UPSTREAM_URL ?= 
http://xenbits.xen.org/git-http/people/ianc/libxenctrl-split/mini-os.git
 else
 OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git
-QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-xen.git
-QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-traditional.git
+QEMU_UPSTREAM_URL ?= 
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen.git
+QEMU_TRADITIONAL_URL ?= 
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen-traditional.git
 SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
-MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
+MINIOS_UPSTREAM_URL ?= 
git://xenbits.xen.org/people/ianc/libxenctrl-split/mini-os.git
 endif
 OVMF_UPSTREAM_REVISION ?= 52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d
-QEMU_UPSTREAM_REVISION ?= master
-MINIOS_UPSTREAM_REVISION ?= d25773c8afa2f4dbbb466116daeb60159ddd22bd
-# Thu Dec 3 11:23:25 2015 +
-# mini-os: Include libxentoollog with libxc
+QEMU_UPSTREAM_REVISION ?= origin/v8
+MINIOS_UPSTREAM_REVISION ?= origin/v8
+# Mon Nov 23 16:34:31 2015 +
+# Add a .gitignore
 
 SEABIOS_UPSTREAM_REVISION ?= 3403ac4313812752be6e6aac35239ca6888a8cab
 # Mon Dec 28 13:50:41 2015 +0100
@@ -262,7 +262,7 @@ SEABIOS_UPSTREAM_REVISION ?= 
3403ac4313812752be6e6aac35239ca6888a8cab
 ETHERBOOT_NICS ?= rtl8139 8086100e
 
 
-QEMU_TRADITIONAL_REVISION ?= 569eac99e8ddccd15fe78e8a3af5622afe780e3b
+QEMU_TRADITIONAL_REVISION ?= origin/v8
 # Mon Jan 4 15:34:29 2016 +
 # MSI-X: avoid array overrun upon MSI-X table writes
 
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v8 0/8] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell]

We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.

This is the qemu-xen part of the first phase of that change.

This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.

Ian Campbell (8):
  xen_console: correctly cleanup primary console on teardown.
  xen: Switch to libxenevtchn interface for compat shims.
  xen: Switch to libxengnttab interface for compat shims.
  xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages
  xen: Switch uses of xc_map_foreign_{pages,bulk} to use
libxenforeignmemory API.
  xen: Use stable library interfaces when they are available.
  xen: domainbuild: reopen libxenctrl interface after forking for domain
watcher.
  xen: make it possible to build without the Xen PV domain builder

 configure|  70 
 hw/block/xen_disk.c  |  38 +--
 hw/char/xen_console.c|  19 +++---
 hw/display/xenfb.c   |  28 
 hw/net/xen_nic.c |  18 +++---
 hw/xen/xen_backend.c |  44 +++--
 hw/xenpv/Makefile.objs   |   4 +-
 hw/xenpv/xen_domainbuild.c   |   9 ++-
 hw/xenpv/xen_machine_pv.c|  15 +++--
 include/hw/xen/xen_backend.h |   5 +-
 include/hw/xen/xen_common.h  | 149 ++-
 xen-common.c |   6 ++
 xen-hvm.c|  39 +--
 xen-mapcache.c   |   6 +-
 14 files changed, 315 insertions(+), 135 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 19/29] tools/libs: Clean up hard tabs.

[Ian Campbell]

These were wrong in the context of libxc before this code was
extracted, clean them up.

Also add some emacs magic blocks

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---
 tools/libs/call/buffer.c  |  4 ++--
 tools/libs/call/core.c|  2 +-
 tools/libs/call/minios.c  |  4 ++--
 tools/libs/evtchn/minios.c| 28 ++--
 tools/libs/evtchn/netbsd.c| 12 ++--
 tools/libs/foreignmemory/freebsd.c|  2 +-
 tools/libs/foreignmemory/minios.c |  6 +++---
 tools/libs/foreignmemory/netbsd.c |  2 +-
 tools/libs/foreignmemory/private.h|  2 +-
 tools/libs/foreignmemory/solaris.c| 12 +++-
 tools/libs/gnttab/include/xengnttab.h |  4 ++--
 tools/libs/gnttab/linux.c |  6 +++---
 tools/libs/toollog/xtl_logger_stdio.c |  2 +-
 13 files changed, 48 insertions(+), 38 deletions(-)

diff --git a/tools/libs/call/buffer.c b/tools/libs/call/buffer.c
index 1a1b27a..2d8fc29 100644
--- a/tools/libs/call/buffer.c
+++ b/tools/libs/call/buffer.c
@@ -20,7 +20,7 @@
 #include "private.h"
 
 #define DBGPRINTF(_m...) \
-   xtl_log(xcall->logger, XTL_DEBUG, -1, "xencall:buffer", _m)
+xtl_log(xcall->logger, XTL_DEBUG, -1, "xencall:buffer", _m)
 
 #define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 
@@ -86,7 +86,7 @@ static int cache_free(xencall_handle *xcall, void *p, size_t 
nr_pages)
 xcall->buffer_current_allocations--;
 
 if ( nr_pages == 1 &&
-xcall->buffer_cache_nr < BUFFER_CACHE_SIZE )
+ xcall->buffer_cache_nr < BUFFER_CACHE_SIZE )
 {
 xcall->buffer_cache[xcall->buffer_cache_nr++] = p;
 rc = 1;
diff --git a/tools/libs/call/core.c b/tools/libs/call/core.c
index a342871..bbf88de 100644
--- a/tools/libs/call/core.c
+++ b/tools/libs/call/core.c
@@ -19,7 +19,7 @@
 
 xencall_handle *xencall_open(xentoollog_logger *logger, unsigned open_flags)
 {
-   xencall_handle *xcall = malloc(sizeof(*xcall));
+xencall_handle *xcall = malloc(sizeof(*xcall));
 int rc;
 
 if (!xcall) return NULL;
diff --git a/tools/libs/call/minios.c b/tools/libs/call/minios.c
index 3bee7be..f04688f 100644
--- a/tools/libs/call/minios.c
+++ b/tools/libs/call/minios.c
@@ -50,8 +50,8 @@ int osdep_hypercall(xencall_handle *xcall, 
privcmd_hypercall_t *hypercall)
 ret = HYPERVISOR_multicall(, 1);
 
 if (ret < 0) {
-   errno = -ret;
-   return -1;
+errno = -ret;
+return -1;
 }
 if ((long) call.result < 0) {
 errno = - (long) call.result;
diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c
index 773942d..2c89952 100644
--- a/tools/libs/evtchn/minios.c
+++ b/tools/libs/evtchn/minios.c
@@ -103,8 +103,8 @@ int xenevtchn_notify(xenevtchn_handle *xce, evtchn_port_t 
port)
 ret = notify_remote_via_evtchn(port);
 
 if (ret < 0) {
-   errno = -ret;
-   ret = -1;
+errno = -ret;
+ret = -1;
 }
 return ret;
 }
@@ -138,16 +138,16 @@ evtchn_port_or_error_t 
xenevtchn_bind_unbound_port(xenevtchn_handle *xce, uint32
 assert(get_current() == main_thread);
 port_info = port_alloc(fd);
 if (port_info == NULL)
-   return -1;
+return -1;
 
 printf("xenevtchn_bind_unbound_port(%d)", domid);
 ret = evtchn_alloc_unbound(domid, evtchn_handler, (void*)(intptr_t)fd, 
);
 printf(" = %d\n", ret);
 
 if (ret < 0) {
-   port_dealloc(port_info);
-   errno = -ret;
-   return -1;
+port_dealloc(port_info);
+errno = -ret;
+return -1;
 }
 port_info->bound = 1;
 port_info->port = port;
@@ -166,16 +166,16 @@ evtchn_port_or_error_t 
xenevtchn_bind_interdomain(xenevtchn_handle *xce, uint32_
 assert(get_current() == main_thread);
 port_info = port_alloc(fd);
 if (port_info == NULL)
-   return -1;
+return -1;
 
 printf("xenevtchn_bind_interdomain(%d, %"PRId32")", domid, remote_port);
 ret = evtchn_bind_interdomain(domid, remote_port, evtchn_handler, 
(void*)(intptr_t)fd, _port);
 printf(" = %d\n", ret);
 
 if (ret < 0) {
-   port_dealloc(port_info);
-   errno = -ret;
-   return -1;
+port_dealloc(port_info);
+errno = -ret;
+return -1;
 }
 port_info->bound = 1;
 port_info->port = local_port;
@@ -208,15 +208,15 @@ evtchn_port_or_error_t 
xenevtchn_bind_virq(xenevtchn_handle *xce, unsigned int v
 assert(get_current() == main_thread);
 port_info = port_alloc(fd);
 if (port_info == NULL)
-   return -1;
+return -1;
 
 printf("xenevtchn_bind_virq(%d)", virq);
 port = bind_virq(virq, evtchn_handler, (void*)(intptr_t)fd);
 
 if (port < 0) {
-   port_dealloc(port_info);
-   errno = -port;
-   return -1;
+port_dealloc(port_info);
+errno = -port;
+return -1;
 }
 port_info->bound = 1;
 port_info->port = port;

Re: [Xen-devel] [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163

[Andrew Cooper]

On 15/01/16 10:58, Håkon Alstadheim wrote:
> This is just a preliminary report, mostly just for the record.
>
> I will report again if this keeps happening after 4.7 is out, or upon
> request. Anyone working on this, please mail me and request more
> information. I have available logs from dom0 boot (I dump dmesg and xl
> dmesg to disk after every boot, and log dom0 serial console to disk).
> I will send boot logs if requested. I will turn on maximum verbosity
> and provide all output. My serial console is very slow, so I can not
> keep running at max verbosity all the time.
>
> At the end of this mail there is "xl info" and output from dom0 serial
> console.
>
> CPUINFO:
> vendor_id: GenuineIntel
> cpu family: 6
> model: 63
> model name: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
>
> # smbios-sys-info
> Libsmbios version:  2.2.28
> Product Name:   Z10PE-D8 WS
> Vendor: ASUSTeK COMPUTER INC.
> BIOS Version:   3101
>
> Dom0 OS:
> Linux gentoo 4.1.12-gentoo #1 SMP Sat Jan 2 09:36:31 CET 2016 x86_64
> Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz GenuineIntel GNU/Linux.
> Kernel is gentoo-sources, with experimental use-flag. Cpu type set to
> Haswell. Issue also happened without experimental.
> # cat /proc/cmdline
> placeholder root=LABEL=ssdroot ro
> xen-pciback.hide=(02:00.*)(08:00.*)(00:1b.*)(81:00.*)(82:00.*)(83:00.*) 
> console=hvc0
> console=vga domodules domdadm dolvm intel_iommu=on earlyprintk=xen
> usbcore.autosuspend=-1
>
> The system is mostly built with stable packages, xen and xen-tools
> keyworded to ~amd64.
>
> I have been experiencing issues with domains with passed through PCIe
> devices since I first installed xen. Then at version 4.5.x , I'm now
> at 4.6.0 with gentoo patches. Crashes SEEM mostly related to this pci
> pass through and interrupts (usb-cards, sound cards).
>
> Recently the system has been more stable, whether it is because I pass
> through as few things as possible, or because of improvements in Xen I
> do not know. I have also taken to building with debug, which leads to
> more abrupt but less mysterious failures. Earlier (w/o debug and under
> xen 4.5 ) stuff would just gradually stop working and end up in total
> hang of everything. So, hey, things are improving :-b

This isn't the first time we have seen this on Haswell processors. Do
you have microcode loading set up?

~Andrew

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

Re: [Xen-devel] [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163

[Håkon Alstadheim]

On 01/15/2016 12:05 PM, Andrew Cooper wrote:

On 15/01/16 10:58, Håkon Alstadheim wrote:

This is just a preliminary report, mostly just for the record.

I will report again if this keeps happening after 4.7 is out, or upon
request. Anyone working on this, please mail me and request more
information. I have available logs from dom0 boot (I dump dmesg and xl
dmesg to disk after every boot, and log dom0 serial console to disk).
I will send boot logs if requested. I will turn on maximum verbosity
and provide all output. My serial console is very slow, so I can not
keep running at max verbosity all the time.

At the end of this mail there is "xl info" and output from dom0 serial
console.

CPUINFO:
vendor_id: GenuineIntel
cpu family: 6
model: 63
model name: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

# smbios-sys-info
Libsmbios version:  2.2.28
Product Name:   Z10PE-D8 WS
Vendor: ASUSTeK COMPUTER INC.
BIOS Version:   3101

Dom0 OS:
Linux gentoo 4.1.12-gentoo #1 SMP Sat Jan 2 09:36:31 CET 2016 x86_64
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz GenuineIntel GNU/Linux.
Kernel is gentoo-sources, with experimental use-flag. Cpu type set to
Haswell. Issue also happened without experimental.
# cat /proc/cmdline
placeholder root=LABEL=ssdroot ro
xen-pciback.hide=(02:00.*)(08:00.*)(00:1b.*)(81:00.*)(82:00.*)(83:00.*) 
console=hvc0
console=vga domodules domdadm dolvm intel_iommu=on earlyprintk=xen
usbcore.autosuspend=-1

The system is mostly built with stable packages, xen and xen-tools
keyworded to ~amd64.

I have been experiencing issues with domains with passed through PCIe
devices since I first installed xen. Then at version 4.5.x , I'm now
at 4.6.0 with gentoo patches. Crashes SEEM mostly related to this pci
pass through and interrupts (usb-cards, sound cards).

Recently the system has been more stable, whether it is because I pass
through as few things as possible, or because of improvements in Xen I
do not know. I have also taken to building with debug, which leads to
more abrupt but less mysterious failures. Earlier (w/o debug and under
xen 4.5 ) stuff would just gradually stop working and end up in total
hang of everything. So, hey, things are improving :-b

This isn't the first time we have seen this on Haswell processors. Do
you have microcode loading set up?

Not entirely sure to be honest. Is microcode: 0x31 the newest?

I AM running the very latest bios from Asus, but I do not have 
confidence in my microcode loading setup, so I have not had one in place.


Trying now.

Downloading microcode.dat from Intel
Installing iucode_tool, which in its --help states:
  -w, --write-to=fileWrite selected microcodes to a file in binary
 format.  The binary format is suitable to be
 uploaded to the kernel

Ran "iucode_tool microcode.dat -w microcode.bin"

# ls -l micro*
-rwxr-xr-x 1 root root  693248 Jan 15 12:40 microcode.bin
-rwxr-xr-x 1 root root 2081807 Nov  6 04:04 microcode.dat

placed microcode.bin in /boot/microcode.bin

 booted with :
---
xen_commandline: ssd-xen-debug-marker console_timestamps=date 
loglvl=all guest_loglvl=all sync_console iommu=1,verbose,debug 
iommu_inclusive_mapping=1 com1=115200,8n1 console=com1 dom0_max_vcpus=4 
dom0_vcpus_pin=1 dom0_mem=8G,max:8G cpufreq=xen:performance,verbose 
tmem=1 sched_smt_power_savings=1 apic_verbosity=debug e820-verbose=1 
core_parking=power ucode=microcode.bin

---

#cat /proc/cpuinfo | grep micro
says: microcode: 0x31

This is no change from previous boot.
Now: How do I know wheter 0x31 is the newest?

Grepping the console output reveals no reference to ucode or microcode 
other than the Xen command-line.

---
Håkon


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

Re: [Xen-devel] [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163

[Håkon Alstadheim]

On 01/15/2016 01:42 PM, Jan Beulich wrote:

On 15.01.16 at 13:32,  wrote:

placed microcode.bin in /boot/microcode.bin

   booted with :
---
xen_commandline: ssd-xen-debug-marker console_timestamps=date
loglvl=all guest_loglvl=all sync_console iommu=1,verbose,debug
iommu_inclusive_mapping=1 com1=115200,8n1 console=com1 dom0_max_vcpus=4
dom0_vcpus_pin=1 dom0_mem=8G,max:8G cpufreq=xen:performance,verbose
tmem=1 sched_smt_power_savings=1 apic_verbosity=debug e820-verbose=1
core_parking=power ucode=microcode.bin
---

This can't work - did you look at the command line documentation?
You can't specify a file name here - there's no file system driver
inside the hypervisor, and hence it can't read files (it instead has
to rely on the boot loader bringing those into memory for it).
Get with the times :-) . Under EFI it most definitely wants a file-name. 
Not entirely sure about the file FORMAT though.


From xen-command-line.html
 "Note further that use of this option has an unspecified effect when 
used with xen.efi (there the concept of modules doesn't exist, and the 
blob gets specified via the ucode= config file/section entry; 
see EFI configuration file description).


From efi.html

 "ucode=

Specifies a CPU microcode blob to load. (x86 only)



#cat /proc/cpuinfo | grep micro
says: microcode: 0x31

This is no change from previous boot.
Now: How do I know wheter 0x31 is the newest?

By checking - for the precise model and stepping of your CPU(s) -
the information in the blob (which admittedly is a little cumbersome,
but without knowing model and stepping I also can't try to help).

Jan





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

[Xen-devel] [PATCH XEN v8 26/29] tools/libs/*: Use O_CLOEXEC on Linux and FreeBSD

[Ian Campbell]

In some cases this replaces an FD_CLOEXEC dance, in others it is new.

Linux has had O_CLOEXEC since 2.6.23 (October 2007), so we can rely on
it from Xen 4.7 I think. Some libc headers may still lack the
definition, so we take care of that if need be by defining to 0 (on
the premise that such an old glibc might barf on O_CLOEXEC even if the
kernel may or may not be so old).

All stable versions of FreeBSD support O_CLOEXEC (10.2, 9.3 and 8.4),
and we assume the libc there does too.

Remove various comments about having to take responsibility for this
(since really it is just hygiene, politeness, not a requirement) and
the reasons for using O_CLOEXEC seem pretty straightforward.

Backends for other OSes are untouched.

Signed-off-by: Ian Campbell 
Acked-by: Roger Pau Monné 
Cc: roger@citrix.com
Cc: jbeul...@suse.com
---
v6: New

v7: New, replaces "tools/libs/call: Use O_CLOEXEC when opening
/dev/xen/privcmd on Linux"

v8: Define compat O_CLOEXEC of 0.
---
 tools/libs/call/freebsd.c  | 30 --
 tools/libs/call/linux.c| 38 +++---
 tools/libs/evtchn/freebsd.c|  2 +-
 tools/libs/evtchn/linux.c  |  6 +-
 tools/libs/foreignmemory/freebsd.c | 24 ++--
 tools/libs/foreignmemory/linux.c   | 36 +---
 tools/libs/gnttab/linux.c  |  6 +-
 7 files changed, 41 insertions(+), 101 deletions(-)

diff --git a/tools/libs/call/freebsd.c b/tools/libs/call/freebsd.c
index 2413966..b3cbccd 100644
--- a/tools/libs/call/freebsd.c
+++ b/tools/libs/call/freebsd.c
@@ -35,8 +35,14 @@
 
 int osdep_xencall_open(xencall_handle *xcall)
 {
-int flags, saved_errno;
-int fd = open(PRIVCMD_DEV, O_RDWR);
+int saved_errno;
+int fd = open(PRIVCMD_DEV, O_RDWR|O_CLOEXEC);
+
+/*
+ * This file descriptor is opaque to the caller, thus we are
+ * polite and try and ensure it doesn't propagate (ie leak)
+ * outside the process, by using O_CLOEXEC.
+ */
 
 if ( fd == -1 )
 {
@@ -45,26 +51,6 @@ int osdep_xencall_open(xencall_handle *xcall)
 return -1;
 }
 
-/*
- * Although we return the file handle as the 'xc handle' the API
- * does not specify / guarentee that this integer is in fact
- * a file handle. Thus we must take responsiblity to ensure
- * it doesn't propagate (ie leak) outside the process.
- */
-if ( (flags = fcntl(fd, F_GETFD)) < 0 )
-{
-PERROR("Could not get file handle flags");
-goto error;
-}
-
-flags |= FD_CLOEXEC;
-
-if ( fcntl(fd, F_SETFD, flags) < 0 )
-{
-PERROR("Could not set file handle flags");
-goto error;
-}
-
 xcall->fd = fd;
 return 0;
 
diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
index 651f380..e8e0311 100644
--- a/tools/libs/call/linux.c
+++ b/tools/libs/call/linux.c
@@ -26,15 +26,23 @@
 
 #include "private.h"
 
+#ifndef O_CLOEXEC
+#define O_CLOEXEC 0
+#endif
+
 int osdep_xencall_open(xencall_handle *xcall)
 {
-int flags, saved_errno;
-int fd = open("/dev/xen/privcmd", O_RDWR); /* prefer this newer interface 
*/
+int fd;
+
+/*
+ * Prefer the newer interface.
+ */
+fd = open("/dev/xen/privcmd", O_RDWR|O_CLOEXEC);
 
 if ( fd == -1 && ( errno == ENOENT || errno == ENXIO || errno == ENODEV ))
 {
 /* Fallback to /proc/xen/privcmd */
-fd = open("/proc/xen/privcmd", O_RDWR);
+fd = open("/proc/xen/privcmd", O_RDWR|O_CLOEXEC);
 }
 
 if ( fd == -1 )
@@ -43,32 +51,8 @@ int osdep_xencall_open(xencall_handle *xcall)
 return -1;
 }
 
-/* Although we return the file handle as the 'xc handle' the API
-   does not specify / guarentee that this integer is in fact
-   a file handle. Thus we must take responsiblity to ensure
-   it doesn't propagate (ie leak) outside the process */
-if ( (flags = fcntl(fd, F_GETFD)) < 0 )
-{
-PERROR("Could not get file handle flags");
-goto error;
-}
-
-flags |= FD_CLOEXEC;
-
-if ( fcntl(fd, F_SETFD, flags) < 0 )
-{
-PERROR("Could not set file handle flags");
-goto error;
-}
-
 xcall->fd = fd;
 return 0;
-
- error:
-saved_errno = errno;
-close(fd);
-errno = saved_errno;
-return -1;
 }
 
 int osdep_xencall_close(xencall_handle *xcall)
diff --git a/tools/libs/evtchn/freebsd.c b/tools/libs/evtchn/freebsd.c
index 6479f7c..ddf221d 100644
--- a/tools/libs/evtchn/freebsd.c
+++ b/tools/libs/evtchn/freebsd.c
@@ -32,7 +32,7 @@
 
 int osdep_evtchn_open(xenevtchn_handle *xce)
 {
-int fd = open(EVTCHN_DEV, O_RDWR);
+int fd = open(EVTCHN_DEV, O_RDWR|O_CLOEXEC);
 if ( fd == -1 )
 return -1;
 xce->fd = fd;
diff --git a/tools/libs/evtchn/linux.c b/tools/libs/evtchn/linux.c
index 76cf0ac..0a3c6e1 100644
--- a/tools/libs/evtchn/linux.c
+++ 

[Xen-devel] [PATCH XEN v8 23/29] tools/libs/call: Avoid xc_memalign in netbsd and solaris backends

[Ian Campbell]

These are already arch specific, so just use the appropriate
interfaces (as determined by looking at the xc_memalign backend).

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---
 tools/libs/call/netbsd.c  | 4 ++--
 tools/libs/call/solaris.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libs/call/netbsd.c b/tools/libs/call/netbsd.c
index 2aa02f1..e96fbf1 100644
--- a/tools/libs/call/netbsd.c
+++ b/tools/libs/call/netbsd.c
@@ -74,8 +74,8 @@ void *osdep_alloc_hypercall_buffer(xencall_handle *xcall, 
size_t npages)
 size_t size = npages * XC_PAGE_SIZE;
 void *p;
 
-p = xc_memalign(xcall, XC_PAGE_SIZE, size);
-if (!p)
+ret = posix_memalign(, XC_PAGE_SIZE, size);
+if ( ret != 0 || !p )
 return NULL;
 
 if ( mlock(p, size) < 0 )
diff --git a/tools/libs/call/solaris.c b/tools/libs/call/solaris.c
index 945d867..5aa330e 100644
--- a/tools/libs/call/solaris.c
+++ b/tools/libs/call/solaris.c
@@ -71,7 +71,7 @@ int osdep_xencall_close(xencall_handle *xcall)
 
 void *osdep_alloc_hypercall_buffer(xencall_handle *xcall, size_t npages)
 {
-return xc_memalign(xcall, XC_PAGE_SIZE, npages * XC_PAGE_SIZE);
+return memalign(XC_PAGE_SIZE, npages * XC_PAGE_SIZE);
 }
 
 void osdep_free_hypercall_buffer(xencall_handle *xcall, void *ptr,
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 28/29] tools/libs/*: Introduce APIs to restrict handles to a specific domain.

[Ian Campbell]

These are intended to allow user space processes (in particular QEMU)
to lock down all the handles at start of day and then drop the
privileges which would allow them to open any new unrestricted handles
(e.g. setuid or similar). This will reduce the privileges which taking
over such a process would gain an attacker wrt other domains in the
system.

These are currently unimplemented on all platforms, however the API
semantics are defined as the basis for discussion, and so that
consumers can rely on this interface always having been present rather
than requiring compile time API checks.

It is expected that these will be implemented by adding new ioctl
calls on the underlying driver and that the restrictions will be
enforced at the kernel interface layer (most likely by the kernel
itself).

For evtchn, foreignmemory, gnttab and gntshr this is hopefully
reasonably straightforward.

For call it is not so clear cut. Clearly the kernel cannot enforce
these restrictions for hypercalls which are not stable (domctl et al)
so they can never be on the whitelist. It may also be that potential
users would like to restrict the handle further than just a given
target domain, i.e. to a specific set of functionality (e.g. "things a
device model might reasonably do"). I think we will also need some way
to discover whether a given set of interfaces is available to a
restricted handle, in order to support the addition of new
functionality.

Notes:

- On many (all?) platforms libxencall and libxenforeignmemory are
  implemented by the same underlying privcmd driver. The platform
  level ioctl interface should support restricting the handle to only
  one or the other.
- On platforms with multiple privilege mapping ioctl variants should
  consider only allowing the newest/currently preferred one on a
  restricted handle. e.g. on Linux this would allow
  IOCTL_PRIVCMD_MMAPBATCH_V2 but not IOCTL_PRIVCMD_MMAPBATCH. (Of
  course any subsequently introduced _V3 would be subject to
  compatibility concerns)

Signed-off-by: Ian Campbell 
---
v8: New

This applies on top of the Xen portion of "Begin to disentangle
libxenctrl and provide some stable libraries", v7, plus a couple of
minor fixes which will be in v8. All of this can be found in the
"vwip" branch of the tree referenced by that series at
git://xenbits.xen.org/people/ianc/libxenctrl-split/xen.git.
---
 tools/libs/call/core.c |  7 +++
 tools/libs/call/include/xencall.h  | 34 ++
 tools/libs/call/libxencall.map |  2 +
 tools/libs/evtchn/core.c   |  7 +++
 tools/libs/evtchn/include/xenevtchn.h  | 36 +++
 tools/libs/evtchn/libxenevtchn.map |  2 +
 tools/libs/foreignmemory/core.c|  7 +++
 .../libs/foreignmemory/include/xenforeignmemory.h  | 22 +
 tools/libs/foreignmemory/libxenforeignmemory.map   |  3 ++
 tools/libs/gnttab/gntshr_core.c|  8 
 tools/libs/gnttab/gnttab_core.c|  7 +++
 tools/libs/gnttab/include/xengnttab.h  | 52 ++
 tools/libs/gnttab/libxengnttab.map |  8 +++-
 13 files changed, 193 insertions(+), 2 deletions(-)

diff --git a/tools/libs/call/core.c b/tools/libs/call/core.c
index bbf88de..07283da 100644
--- a/tools/libs/call/core.c
+++ b/tools/libs/call/core.c
@@ -14,6 +14,7 @@
  */
 
 #include 
+#include 
 
 #include "private.h"
 
@@ -70,6 +71,12 @@ int xencall_close(xencall_handle *xcall)
 return rc;
 }
 
+int xencall_restrict_target(xencall_handle *xcall, uint32_t domid)
+{
+errno = ENOSYS;
+return -1;
+}
+
 int xencall0(xencall_handle *xcall, unsigned int op)
 {
 privcmd_hypercall_t call = {
diff --git a/tools/libs/call/include/xencall.h 
b/tools/libs/call/include/xencall.h
index 559624a..47c394d 100644
--- a/tools/libs/call/include/xencall.h
+++ b/tools/libs/call/include/xencall.h
@@ -73,6 +73,40 @@ xencall_handle *xencall_open(xentoollog_logger *logger, 
unsigned open_flags);
 int xencall_close(xencall_handle *xcall);
 
 /*
+ * Attempt to restrict the given xcall handle to only be able to
+ * target the given domain.
+ *
+ * On success returns 0, after which only hypercalls which are on a
+ * platform specific whitelist can be called and the arguments will be
+ * audited by the platform to ensure that the target domain is
+ * domid.
+ *
+ * Subsequent attempts to call any hypercall not on the platform
+ * specific whitelist will return -1 setting errno to ENOSYS.
+ *
+ * Subsequent attempts to call any hypercall on the platform specific
+ * whitelist with any other target domain return -1 setting errno to
+ * EPERM.
+ *
+ * These restrictions will be implemented by the platform in a way
+ * which cannot be circumvented by a userspace process. Further
+ * privilege drops (such as using setuid(2) etc) may also be required
+ * to prevent a compromised process from 

[Xen-devel] [PATCH XEN v8 21/29] tools/libs/call: Update some log messages to not refer to xc.

[Ian Campbell]

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---
 tools/libs/call/linux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
index 55e1e83..3641e41 100644
--- a/tools/libs/call/linux.c
+++ b/tools/libs/call/linux.c
@@ -94,7 +94,7 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t npages)
 p = mmap(NULL, size, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
 if ( p == MAP_FAILED )
 {
-PERROR("xc_alloc_hypercall_buffer: mmap failed");
+PERROR("alloc_pages: mmap failed");
 return NULL;
 }
 
@@ -103,7 +103,7 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t 
npages)
 rc = madvise(p, npages * PAGE_SIZE, MADV_DONTFORK);
 if ( rc < 0 )
 {
-PERROR("xc_alloc_hypercall_buffer: madvise failed");
+PERROR("alloc_pages: madvise failed");
 goto out;
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 05/29] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.

[Ian Campbell]

libxengnttab will provide a stable API and ABI for accessing the
grant table devices.

The functions are moved into the xengnt{tab,shr} namespace to make a
clean break from libxc and avoid ambiguity regarding which interfaces
are stable.

All in-tree users are updated to use the new names.

Upon request (via #define XC_WANT_COMPAT_GNTTAB_API) libxenctrl will
provide a compat API for the old names. This is used by qemu-xen for
the time being. qemu-xen-traditional is updated in lockstep.

This leaves a few grant table related functions which go via privcmd
(GNTTABOP) rather than ioctls on the /dev/xen/gnt* devices in
libxenctrl. Specifically:

  - xc_gnttab_get_version
  - xc_gnttab_map_table_v1
  - xc_gnttab_map_table_v2
  - xc_gnttab_op

These functions do not appear to be needed by qemu-dm, qemu-pv
(provision of device model to HVM guests and PV backends respectively)
or by libvchan suggesting they are not needed by non-toolstack uses of
event channels.

The new library uses a version script to ensure that only expected
symbols are exported and to version them such that ABI guarantees can
be kept in the future.

After this change libxenvchan no longer needs to link against
libxenctrl. It still needs xenctrl.h in one file for xen_mb and
friends.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---

Must be applied with:

 - "qemu-xen-traditional: Use libxengnttab" and a corresponding
   QEMU_TAG update folded here.
 - "mini-os: Include libxengnttab with libxc"" and a corresponding
   bump to MINIOS_UPSTREAM_REVISION folded in here.

v3:
 - Remove SHLIB_libxenctrl from SHDEPS_libxenvchan, and replace with
   SHLIB_libxentoollog.
 - Move to tools/libs/gnttab
 - Adjust for rebase over 31cf2ca75181 "tools/libxc: linux: Don't use
   getpagesize() when unmapping the grants"

v5: Allow _close(NULL).

v6: The extensive API document updates from the previous round of
review have been implemented in "tools/libs/gnttab: Extensive
updates to API documentation." later in the series, so as not to
add further functional changes than already required to this
refactoring patch.

v7: Added mk-headers-$(XEN_TARGET_ARCH) build dependency instead of
open coding the recursion.
s/gnttab_munmap/gnttab_unmap/ and s/gntshr_munmap/gntshr_unshare/
in the API and equivalents in the internals/osdeps etc.

v8: s/EVTCHNOP/GNTTABOP/ cut-&-paste error in commit log.
Remove *.so on clean, add distclean target.
---
 .gitignore |   2 +
 stubdom/Makefile   |  17 +-
 tools/Makefile |   3 +
 tools/Rules.mk |  14 +-
 tools/console/Makefile |   5 +-
 tools/console/daemon/io.c  |  21 +-
 tools/libs/Makefile|   1 +
 tools/libs/evtchn/minios.c |   5 +-
 tools/libs/gnttab/Makefile |  73 +
 tools/libs/gnttab/gntshr_core.c|  95 ++
 .../xc_nognttab.c => libs/gnttab/gntshr_unimp.c}   |  34 ++-
 tools/libs/gnttab/gnttab_core.c| 124 
 tools/libs/gnttab/gnttab_unimp.c   |  89 ++
 tools/libs/gnttab/include/xengnttab.h  | 216 ++
 tools/libs/gnttab/libxengnttab.map |  23 ++
 tools/libs/gnttab/linux.c  | 329 +
 tools/libs/gnttab/minios.c | 117 
 tools/libs/gnttab/private.h|  47 +++
 tools/libvchan/Makefile|   8 +-
 tools/libvchan/init.c  |  26 +-
 tools/libvchan/io.c|   8 +-
 tools/libvchan/libxenvchan.h   |   6 +-
 tools/libxc/Makefile   |  15 +-
 tools/libxc/include/xenctrl.h  | 168 ---
 tools/libxc/include/xenctrl_compat.h   |  48 +++
 tools/libxc/xc_gnttab.c|  53 
 tools/libxc/xc_gnttab_compat.c | 111 +++
 tools/libxc/xc_linux_osdep.c   | 280 --
 tools/libxc/xc_minios.c|  73 -
 tools/libxc/xc_nogntshr.c  |  46 ---
 tools/libxc/xc_private.c   |  80 -
 tools/libxc/xc_private.h   |  24 --
 tools/xenstore/Makefile|   4 +-
 tools/xenstore/xenstored_core.h|   4 +-
 tools/xenstore/xenstored_domain.c  |  24 +-
 tools/xenstore/xenstored_minios.c  |   5 +-
 36 files changed, 1397 insertions(+), 801 deletions(-)
 create mode 100644 tools/libs/gnttab/Makefile
 create mode 100644 tools/libs/gnttab/gntshr_core.c
 rename tools/{libxc/xc_nognttab.c => 

[Xen-devel] [PATCH XEN v8 22/29] tools/libs/call: Describe return values and error semantics for xencall*

[Ian Campbell]

This behaviour has been confirmed by inspection on:

 - Linux
 - NetBSD & FreeBSD (NB: hcall->retval is the hypercall return value
   only for values >= 0. For negative values the underlying privcmd
   driver translates the value from Xen to {Net,Free}BSD errno space
   and returns it as the result of the ioctl, which becomes
   ret=-1/errno=EFOO in userspace)
 - MiniOS (which takes care of errno in this library)

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
Acked-by: Roger Pau Monné 
Cc: Roger Pau Monné 
---
v7: Noted NetBSD behaviour
v6: New patch
---
 tools/libs/call/include/xencall.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tools/libs/call/include/xencall.h 
b/tools/libs/call/include/xencall.h
index 0d91aa8..3f325f0 100644
--- a/tools/libs/call/include/xencall.h
+++ b/tools/libs/call/include/xencall.h
@@ -46,6 +46,21 @@ int xencall_close(xencall_handle *xcall);
 
 /*
  * Call hypercalls with varying numbers of arguments.
+ *
+ * On success the return value of the hypercall is the return value of
+ * the xencall function.  On error these functions set errno and
+ * return -1.
+ *
+ * The errno values will be either:
+ * - The Xen hypercall error return (from xen/include/public/errno.h)
+ *   translated into the corresponding local value for that POSIX error.
+ * - An errno value produced by the OS driver or the library
+ *   implementation. Such values may be defined by POSIX or by the OS.
+ *
+ * Note that under some circumstances it will not be possible to tell
+ * whether an error came from Xen or from the OS/library.
+ *
+ * These functions never log.
  */
 int xencall0(xencall_handle *xcall, unsigned int op);
 int xencall1(xencall_handle *xcall, unsigned int op,
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 07/29] tools: Refactor hypercall calling wrappers into libxencall.

[Ian Campbell]

libxencall will provide a stable API and ABI for calling hypercalls
(although those hypercalls themselves may not have a stable API). As
well as the hypercall buffer infrastructure needed in order to safely
provide pointer arguments to hypercalls.

libxenctrl encapsulates a instance of this interface, so users of that
library are not currently subjected to any actual changes. However all
hypercalls made internally by libxc now use the correct interface. It
is expected that most users of this library will be other libraries
providing a higher level interface, rather than applications directly.

Only the basic functionality to allocate hypercall safe memory is
moved, the type safe stuff and bounce buffers remain in libxc.

Note that the functionality to map foreign pages using privcmd is not
yet moved, meaning that an xc_interface will now contain two open
privcmd file descriptors. Foreign memory mapping is logically separate
functionality and will be moved into its own library.

The new library uses a version script to ensure that only expected
symbols are exported and to version them such that ABI guarantees can
be kept in the future.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---

Must be applied with:
  - "qemu-xen-traditional: Add libxencall to rpath-link" and a
corresponding QEMU_TAG update folded here.
  - "mini-os: Include libxencall with libxc" and a corresponding bump
to MINIOS_UPSTREAM_REVISION folded in here.

v3: Moved to tools/libs/call
Ported new wrappers (altp2m)

v5: Allow _close(NULL).

v6: Use size_t for nr_pages throughout.
Rebase over "libxc: prefer using privcmd character device"

v7: Added mk-headers-$(XEN_TARGET_ARCH) build dependency instead of
open coding the recursion.
Remove incorrect/spurious APP_LDLIBS (which anyway was removed by
a later patch)

v8: Remove *.so on clean, add distclean target.
---
 .gitignore|   2 +
 stubdom/Makefile  |  17 +++-
 tools/Makefile|   1 +
 tools/Rules.mk|   7 +-
 tools/libs/Makefile   |   1 +
 tools/libs/call/Makefile  |  71 ++
 tools/libs/call/buffer.c  | 192 ++
 tools/libs/call/core.c| 147 +
 tools/libs/call/freebsd.c | 140 +++
 tools/libs/call/include/xencall.h |  84 +
 tools/libs/call/libxencall.map|  19 
 tools/libs/call/linux.c   | 138 +++
 tools/libs/call/minios.c  |  81 
 tools/libs/call/netbsd.c  | 121 
 tools/libs/call/private.h |  68 ++
 tools/libs/call/solaris.c |  97 +++
 tools/libxc/Makefile  |   7 +-
 tools/libxc/xc_altp2m.c   |  64 -
 tools/libxc/xc_domain.c   | 105 +++--
 tools/libxc/xc_evtchn.c   |   9 +-
 tools/libxc/xc_flask.c|   8 +-
 tools/libxc/xc_freebsd_osdep.c|  47 --
 tools/libxc/xc_gnttab.c   |   9 +-
 tools/libxc/xc_hcall_buf.c| 138 ++-
 tools/libxc/xc_kexec.c|  36 +++
 tools/libxc/xc_linux_osdep.c  |  49 --
 tools/libxc/xc_minios.c   |  32 ---
 tools/libxc/xc_misc.c |  79 ++--
 tools/libxc/xc_netbsd.c   |  40 
 tools/libxc/xc_private.c  |  64 +
 tools/libxc/xc_private.h  |  76 +--
 tools/libxc/xc_solaris.c  |  16 
 tools/libxc/xc_tmem.c |   7 +-
 tools/misc/Makefile   |   4 +-
 tools/xcutils/Makefile|   2 +-
 tools/xenpaging/Makefile  |   2 +-
 36 files changed, 1348 insertions(+), 632 deletions(-)
 create mode 100644 tools/libs/call/Makefile
 create mode 100644 tools/libs/call/buffer.c
 create mode 100644 tools/libs/call/core.c
 create mode 100644 tools/libs/call/freebsd.c
 create mode 100644 tools/libs/call/include/xencall.h
 create mode 100644 tools/libs/call/libxencall.map
 create mode 100644 tools/libs/call/linux.c
 create mode 100644 tools/libs/call/minios.c
 create mode 100644 tools/libs/call/netbsd.c
 create mode 100644 tools/libs/call/private.h
 create mode 100644 tools/libs/call/solaris.c

diff --git a/.gitignore b/.gitignore
index a117161..55ecfb7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -62,6 +62,7 @@ stubdom/ioemu
 stubdom/ioemu/
 stubdom/libs-*
 stubdom/libxc-*
+stubdom/libxencall-*
 stubdom/libxenevtchn-*
 stubdom/libxengnttab-*
 stubdom/libxentoollog-*
@@ -91,6 +92,7 @@ config/Docs.mk
 tools/libs/toollog/headers.chk
 tools/libs/evtchn/headers.chk
 tools/libs/gnttab/headers.chk
+tools/libs/call/headers.chk
 tools/blktap2/daemon/blktapctrl
 tools/blktap2/drivers/img2qcow
 tools/blktap2/drivers/lock-util
diff --git a/stubdom/Makefile 

[Xen-devel] [PATCH XEN v8 06/29] tools/libxc: Remove osdep indirection for privcmd

[Ian Campbell]

The alternative backend (a xen-api/xapi shim) is no longer around and
so this stuff is now just baggage which is getting in the way of
refactoring libxenctrl.

Nested virt probably suffices for this use case now.

This was the last component of the osdep infrastructure, so all the
dynamic loading etc stuff all falls away too.

As part of this I was forced to investigate the twisty
xc_map_foreign_* maze, which I have added to the
toolstack-library-apis doc in the hopes of doing something sensible.

NetBSD and Solaris now call xc_map_foreign_bulk_compat directly from
their xc_map_foreign_bulk, which could have been achieved by using
some ifdefs around a renamed function. This will fall out in the wash
when these functions move to their own library.

Signed-off-by: Ian Campbell 
Acked-by: David Scott 
Acked-by: Wei Liu 
---
v7: Stop CCing Dave's dead citrix address.
---
 config/FreeBSD.mk   |   2 -
 config/NetBSD.mk|   3 -
 config/NetBSDRump.mk|   1 -
 config/StdGNU.mk|   1 -
 config/SunOS.mk |   1 -
 tools/libxc/Makefile|  27 ++
 tools/libxc/include/xenctrl.h   |   9 --
 tools/libxc/include/xenctrlosdep.h  | 133 ---
 tools/libxc/xc_foreign_memory.c |  31 +--
 tools/libxc/xc_freebsd_osdep.c  | 100 ++---
 tools/libxc/xc_hcall_buf.c  |   6 +-
 tools/libxc/xc_linux_osdep.c|  88 ++
 tools/libxc/xc_minios.c |  82 +
 tools/libxc/xc_netbsd.c |  90 +++
 tools/libxc/xc_private.c| 174 ++--
 tools/libxc/xc_private.h|  19 ++--
 tools/libxc/xc_solaris.c|  90 +++
 tools/libxc/xenctrl_osdep_ENOSYS.c  | 123 -
 tools/ocaml/libs/xc/xenctrl.ml  |   2 -
 tools/ocaml/libs/xc/xenctrl.mli |   1 -
 tools/ocaml/libs/xc/xenctrl_stubs.c |   7 --
 tools/ocaml/xenstored/domains.ml|   6 +-
 tools/ocaml/xenstored/xenstored.ml  |   5 +-
 23 files changed, 178 insertions(+), 823 deletions(-)
 delete mode 100644 tools/libxc/include/xenctrlosdep.h
 delete mode 100644 tools/libxc/xenctrl_osdep_ENOSYS.c

diff --git a/config/FreeBSD.mk b/config/FreeBSD.mk
index 5a13d607..bb3a5d0 100644
--- a/config/FreeBSD.mk
+++ b/config/FreeBSD.mk
@@ -1,6 +1,4 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
-DLOPEN_LIBS =
-
 # No wget on FreeBSD base system
 WGET = ftp
diff --git a/config/NetBSD.mk b/config/NetBSD.mk
index 21318d6..cf766e5 100644
--- a/config/NetBSD.mk
+++ b/config/NetBSD.mk
@@ -1,6 +1,3 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
-# Override settings for this OS
-DLOPEN_LIBS =
-
 WGET = ftp
diff --git a/config/NetBSDRump.mk b/config/NetBSDRump.mk
index 2a87218..74755a1 100644
--- a/config/NetBSDRump.mk
+++ b/config/NetBSDRump.mk
@@ -1,6 +1,5 @@
 include $(XEN_ROOT)/config/StdGNU.mk
 
-DLOPEN_LIBS =
 PTHREAD_LIBS =
 
 WGET = ftp
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 129d5c8..39d36b2 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -31,7 +31,6 @@ DEBUG_DIR ?= /usr/lib/debug
 
 SOCKET_LIBS =
 UTIL_LIBS = -lutil
-DLOPEN_LIBS = -ldl
 
 SONAME_LDFLAG = -soname
 SHLIB_LDFLAGS = -shared
diff --git a/config/SunOS.mk b/config/SunOS.mk
index db5e898..86a384d 100644
--- a/config/SunOS.mk
+++ b/config/SunOS.mk
@@ -27,7 +27,6 @@ SunOS_LIBDIR_x86_64 = /usr/sfw/lib/amd64
 SOCKET_LIBS = -lsocket
 PTHREAD_LIBS = -lpthread
 UTIL_LIBS =
-DLOPEN_LIBS = -ldl
 
 SONAME_LDFLAG = -h
 SHLIB_LDFLAGS = -R $(SunOS_LIBDIR) -shared
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 33d18db..3305fdd 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -101,8 +101,6 @@ GUEST_SRCS-y += 
xc_dom_decompress_unsafe_lzo1x.c
 GUEST_SRCS-y += xc_dom_decompress_unsafe_xz.c
 endif
 
-OSDEP_SRCS-y += xenctrl_osdep_ENOSYS.c
-
 -include $(XEN_TARGET_ARCH)/Makefile
 
 CFLAGS   += -Werror -Wmissing-prototypes
@@ -121,11 +119,8 @@ CTRL_PIC_OBJS := $(patsubst %.c,%.opic,$(CTRL_SRCS-y))
 GUEST_LIB_OBJS := $(patsubst %.c,%.o,$(GUEST_SRCS-y))
 GUEST_PIC_OBJS := $(patsubst %.c,%.opic,$(GUEST_SRCS-y))
 
-OSDEP_LIB_OBJS := $(patsubst %.c,%.o,$(OSDEP_SRCS-y))
-OSDEP_PIC_OBJS := $(patsubst %.c,%.opic,$(OSDEP_SRCS-y))
-
-$(CTRL_LIB_OBJS) $(GUEST_LIB_OBJS) $(OSDEP_LIB_OBJS) \
-$(CTRL_PIC_OBJS) $(GUEST_PIC_OBJS) $(OSDEP_PIC_OBJS) : CFLAGS += -include 
$(XEN_ROOT)/tools/config.h
+$(CTRL_LIB_OBJS) $(GUEST_LIB_OBJS) \
+$(CTRL_PIC_OBJS) $(GUEST_PIC_OBJS): CFLAGS += -include 
$(XEN_ROOT)/tools/config.h
 
 $(CTRL_LIB_OBJS) $(CTRL_PIC_OBJS): CFLAGS += $(CFLAGS_libxengnttab) 
$(CFLAGS_libxengntshr)
 
@@ -139,17 +134,13 @@ ifneq ($(nosharedlibs),y)
 LIB += libxenguest.so libxenguest.so.$(MAJOR) libxenguest.so.$(MAJOR).$(MINOR)
 endif
 
-ifneq ($(nosharedlibs),y)
-LIB += 

[Xen-devel] [PATCH XEN v8 24/29] tools/libs/call: linux: touch newly allocated pages after madvise lockdown

[Ian Campbell]

This avoids a potential issue with a fork after allocation but before
madvise.

Signed-off-by: Ian Campbell 
---
v7: New, replacing "tools/libs/call: linux: avoid forking between mmap
and madvise".
---
 tools/libs/call/linux.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
index 3641e41..651f380 100644
--- a/tools/libs/call/linux.c
+++ b/tools/libs/call/linux.c
@@ -88,7 +88,7 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t npages)
 {
 size_t size = npages * PAGE_SIZE;
 void *p;
-int rc, saved_errno;
+int rc, i, saved_errno;
 
 /* Address returned by mmap is page aligned. */
 p = mmap(NULL, size, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
@@ -107,6 +107,18 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t 
npages)
 goto out;
 }
 
+/*
+ * Touch each page in turn to force them to be un-CoWed, in case a
+ * fork happened in another thread at an inopportune moment
+ * above. The madvise() will prevent any subsequent fork calls from
+ * causing the same problem.
+ */
+for ( i = 0; i < npages ; i++ )
+{
+char *c = (char *)p + (i*PAGE_SIZE);
+*c = 0;
+}
+
 return p;
 
 out:
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v8 5/8] xen: Switch uses of xc_map_foreign_{pages, bulk} to use libxenforeignmemory API.

[Ian Campbell]

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_{pages,bulk}.

The new xenforeignmemory_map() function behaves like
xc_map_foreign_pages() when the err argument is NULL and like
xc_map_foreign_bulk() when err is non-NULL, which maps into the shim
here onto checking err == NULL and calling the appropriate old
function.

Note that xenforeignmemory_map() takes the number of pages before the
arrays themselves, in order to support potentially future use of
variable-length-arrays in the prototype (in the future, when Xen's
baseline toolchain requirements are new enough to ensure VLAs are
supported).

In preparation for adding support for libxenforeignmemory add support
to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
switch to using the new API. These shims will disappear for versions
of Xen which include libxenforeignmemory.

Since libxenforeignmemory will have its own handle type but for <= 4.6
the functionality is provided by using a libxenctrl handle we
introduce a new global xen_fmem alongside the existing xen_xc. In fact
we make xen_fmem a pointer to the existing xen_xc, which then works
correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
is a pointer). In the latter case xen_fmem is actually a double
indirect pointer, but it all falls out in the wash.

Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
rather than just specifying that munmap should be used, so the unmap
paths are updated to use xenforeignmemory_unmap, which is a shim for
munmap on these versions of xen. The mappings in xen-hvm.c do not
appear to be unmapped (which makes sense for a qemu-dm process)

In fb_disconnect this results in a change from simply mmap over the
existing mapping (with an implicit munmap) to expliclty unmapping with
xenforeignmemory_unmap and then mapping the required anonymous memory
in the same hole. I don't think this is a problem since any other
thread which was racily touching this region would already be running
the risk of hitting the mapping halfway through the call. If this is
thought to be a problem then we could consider adding an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.

Signed-off-by: Ian Campbell 
---
v8: Move two copies of compat xenforeignmemory_{open,unmap} to the
common location. Guard with version 471 (which will be added in
the next patch)
v7: Move two copies of compat xenforeignmemory_map to a common location.
Note that the existing xen_domain_create #ifdef will be covered by
a CONFIG_XEN_PV_DOMAIN_BUILD in a later patch, and so is not a
suitable place to put this function.
v6: Handle _pages as well as _bulk, due to changes in the previous
patches, including the dropping of "xen: Switch uses of
xc_map_foreign_pages into xc_map_foreign_bulk" which previous preceded
this patch and the change of "xen: Switch uses of
xc_map_foreign_range into xc_map_foreign_bulk" into "xen: Switch
uses of xc_map_foreign_range into xc_map_foreign_pages".

Handle reordering of arguments to xenforeignmemory_map().

Dropped Stefano's Reviewed-by due to these changes.

v4: Rebase onto "xen_console: correctly cleanup primary console on
teardown."

xenforeignmemory_unmap takes pages not bytes

Compat wrapper for xenforeignmemory_open instead of ifdef in code.

Run check patch and fix most issues. I did not fix:

ERROR: do not initialise globals to 0 or NULL
+xenforeignmemory_handle *xen_fmem = NULL;

=> This is consistent with all of the existing declarations.

ERROR: need consistent spacing around '*' (ctx:WxV)
+typedef xc_interface *xenforeignmemory_handle;

=> I think this is a false +ve since this is a pointer "*" not a multiple "*".

reorder args to xenforeignmemory_map
---
 hw/char/xen_console.c|  8 
 hw/display/xenfb.c   | 17 +
 hw/xen/xen_backend.c |  3 ++-
 include/hw/xen/xen_backend.h |  1 +
 include/hw/xen/xen_common.h  | 25 +
 xen-common.c |  6 ++
 xen-hvm.c| 12 ++--
 xen-mapcache.c   |  6 +++---
 8 files changed, 56 insertions(+), 22 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 3e8a57b..b92d0c6 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -229,9 +229,9 @@ static int con_initialise(struct XenDevice *xendev)
 
 if (!xendev->dev) {
 xen_pfn_t mfn = con->ring_ref;
-con->sring = xc_map_foreign_pages(xen_xc, con->xendev.dom,
- PROT_READ|PROT_WRITE,
- 

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v8 3/4] qemu-xen-traditional: Add libxencall to rpath-link

[Ian Campbell]

libxenctrl links against this library

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 
---
v3: Library moved to tools/libs
---
 xen-hooks.mak | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen-hooks.mak b/xen-hooks.mak
index 179a6b7..229d642 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -25,6 +25,7 @@ LIBS += -L$(XEN_ROOT)/tools/libs/gnttab -lxengnttab
 LIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguest
 LIBS += -L$(XEN_ROOT)/tools/xenstore -lxenstore
 LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog
+LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/call
 
 LDFLAGS := $(CFLAGS) $(LDFLAGS)
 
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 11/29] tools: Refactor foreign memory mapping into libxenforeignmemory

[Ian Campbell]

libxenforeignmemory will provide a stable API and ABI for mapping
foreign domain memory (subject to appropriate privileges).

The new library exposes an interface equivalent to
xc_map_foreign_memory_bulk, which all the other
xc_map_foreign_memory_* functions (which remain in libxc) are
implemented in terms of.

Upon request (via #define XC_WANT_COMPAT_MAP_FOREIGN_API) libxenctrl
will provide a compat API for the old names. This is used by qemu-xen
and qemu-trad as well as various in tree things (which required
de-dupping various #includes in some too to get the #define before the
first).

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---
Must be applied with:
  - "qemu-xen-traditional: qemu-xen-traditional: Add
libxenforeignmemory to rpath-link" and a corresponding QEMU_TAG
update folded here.
  - "mini-os: mini-os: Include libxenforeignmemory with libxc" and a
corresponding bump to MINIOS_UPSTREAM_REVISION folded in here.

v5: Allow close(NULL)

v6: Define XC_WANT_COMPAT_MAP_FOREIGN_API for xen-mceinj.c and memshrtool.c
Fix typo in type name in compat.c, and get the functions names to
match.
Use an osdep layer for _map, to allow for future common code.

v7: Correct comment in compat.h #error due to switch to osdep layer
for map in v6
Added mk-headers-$(XEN_TARGET_ARCH) build dependency instead of
open coding the recursion.

v8: Remove *.so on clean, add distclean target.
---
 .gitignore |   2 +
 stubdom/Makefile   |  17 +++-
 tools/Makefile |   2 +
 tools/Rules.mk |  11 ++-
 tools/console/daemon/utils.c   |   1 -
 tools/console/daemon/utils.h   |   1 +
 tools/libs/Makefile|   1 +
 tools/libs/foreignmemory/Makefile  |  71 ++
 tools/libs/foreignmemory/compat.c  |  72 ++
 tools/libs/foreignmemory/core.c|  84 +
 .../foreignmemory/freebsd.c}   |  33 +++
 .../libs/foreignmemory/include/xenforeignmemory.h  |  71 ++
 tools/libs/foreignmemory/libxenforeignmemory.map   |   7 ++
 .../foreignmemory/linux.c} |  70 ++
 tools/libs/foreignmemory/minios.c  |  62 
 tools/libs/foreignmemory/netbsd.c  | 105 +
 tools/libs/foreignmemory/private.h |  53 +++
 tools/libs/foreignmemory/solaris.c |  93 ++
 tools/libxc/Makefile   |   8 +-
 tools/libxc/include/xenctrl.h  |  26 -
 tools/libxc/include/xenctrl_compat.h   |  36 +++
 tools/libxc/xc_foreign_memory.c|  49 +-
 tools/libxc/xc_minios.c|  29 --
 tools/libxc/xc_netbsd.c|  73 --
 tools/libxc/xc_private.c   |  13 +--
 tools/libxc/xc_private.h   |  11 ++-
 tools/libxc/xc_solaris.c   |  73 --
 tools/libxc/xc_sr_restore.c|   4 +-
 tools/libxc/xc_sr_save.c   |   4 +-
 tools/libxc/xg_private.h   |   3 +-
 tools/libxl/libxl_internal.h   |   1 +
 tools/misc/xen-mfndump.c   |   1 +
 tools/ocaml/libs/xc/xenctrl_stubs.c|   1 +
 tools/python/xen/lowlevel/xc/xc.c  |   2 +
 tools/tests/mce-test/tools/xen-mceinj.c|   1 +
 tools/tests/mem-sharing/memshrtool.c   |   1 +
 tools/xenmon/xenbaked.c|   1 +
 tools/xenpaging/pagein.c   |   1 -
 tools/xenpaging/xenpaging.c|   1 -
 tools/xenpaging/xenpaging.h|   2 +
 tools/xenstore/xenstored_core.c|   1 -
 tools/xenstore/xenstored_core.h|   1 +
 tools/xentrace/xenctx.c|   3 +-
 tools/xentrace/xentrace.c  |   1 +
 44 files changed, 770 insertions(+), 333 deletions(-)
 create mode 100644 tools/libs/foreignmemory/Makefile
 create mode 100644 tools/libs/foreignmemory/compat.c
 create mode 100644 tools/libs/foreignmemory/core.c
 rename tools/{libxc/xc_freebsd_osdep.c => libs/foreignmemory/freebsd.c} (76%)
 create mode 100644 tools/libs/foreignmemory/include/xenforeignmemory.h
 create mode 100644 tools/libs/foreignmemory/libxenforeignmemory.map
 rename tools/{libxc/xc_linux_osdep.c => libs/foreignmemory/linux.c} (83%)
 create mode 100644 tools/libs/foreignmemory/minios.c
 create mode 100644 tools/libs/foreignmemory/netbsd.c
 create 

[Xen-devel] [PATCH XEN v8 20/29] tools/libs/gnttab: Extensive updates to API documentation.

[Ian Campbell]

In particular around error handling, behaviour on fork and the unmap
notification mechanism.

Behaviour of xengnttab_map_*grant_refs and xengntshr_share_pages on
partial failure has been confirmed/inferred (by inspection) on Linux
and Mini-os (the only two known implementations. Likewise the
behaviour of the notification mechanism has been confirmed/inferred
(by inspection) of the Linux implementation (currently the only
implementation) and libvchan (primary known user).

These updates are not folded into "tools: Refactor
/dev/xen/gnt{dev,shr} wrappers into libxengnttab." to try and reduce
the amount of non-movement changes in that patch.

While I'm not convinced by javadoc/doxygen cause the existing comments
which appear to use that syntax to have the appropriate /** marker.

Also fix a typo in a code comment.

Signed-off-by: Ian Campbell 
Reviewed-by: Daniel De Graaf 
Cc: Daniel De Graaf 
---

v7: Typo.
Updates based on Ian Jackson's review.
Even more updates to the discussion of forking based on ML
discussion.
v6: Rewrapped a comment.
Incorported much review from Ian on the API, retitled (was:
"tools/libs/gnttab: Review and update doc comments.") and dropped
acks
---
 tools/libs/gnttab/include/xengnttab.h | 201 +-
 tools/libs/gnttab/linux.c |  12 +-
 2 files changed, 181 insertions(+), 32 deletions(-)

diff --git a/tools/libs/gnttab/include/xengnttab.h 
b/tools/libs/gnttab/include/xengnttab.h
index 1e07672..7bf8462 100644
--- a/tools/libs/gnttab/include/xengnttab.h
+++ b/tools/libs/gnttab/include/xengnttab.h
@@ -31,28 +31,124 @@
 typedef struct xentoollog_logger xentoollog_logger;
 
 /*
+ * PRODUCING AND CONSUMING GRANT REFERENCES
+ * 
+ *
+ * The xengnttab library contains two distinct interfaces, each with
+ * their own distinct handle type and entry points. The represent the
+ * two sides of the grant table interface, producer (gntshr) and
+ * consumer (gnttab).
+ *
+ * The xengnttab_* interfaces take a xengnttab_handle and provide
+ * mechanisms for consuming (i.e. mapping or copying to/from) grant
+ * references provided by a peer.
+ *
+ * The xengntshr_* interfaces take a xengntshr_handle and provide a
+ * mechanism to produce grantable memory and grant references to that
+ * memory, which can be handed to some peer.
+ *
+ * UNMAP NOTIFICATION
+ * ==
+ *
+ * The xengnt{tab,shr}_*_notify interfaces implement a cooperative
+ * interface which is intended to allow the underlying kernel
+ * interfaces to attempt to notify the peer to perform graceful
+ * teardown upon failure (i.e. crash or exit) of the process on their
+ * end.
+ *
+ * These interfaces operate on a single page only and are intended for
+ * use on the main shared-ring page of a protocol. It is assumed that
+ * on teardown both ends would automatically teardown all grants
+ * associated with the protocol in addition to the shared ring itself.
+ *
+ * Each end is able to optionally nominate a byte offset within the
+ * shared page or an event channel or both. On exit of the process the
+ * underlying kernel driver will zero the byte at the given offset and
+ * signal the event channel.
+ *
+ * The event channel can be the same event channel used for regular
+ * ring progress notifications, or may be a dedicated event channel.
+ *
+ * Both ends may share the same notification byte offset within the
+ * shared page, or may have dedicated "client" and "server" status
+ * bytes.
+ *
+ * Since the byte is cleared on shutdown the protocol must use 0 as
+ * the "closed/dead" status, but is permitted to use any other non-0
+ * values to indicate various other "live" states (waiting for
+ * connection, connected, etc).
+ *
+ * Both ends are permitted to modify (including clear) their
+ * respective status bytes and to signal the event channel themselves
+ * from userspace.
+ *
+ * Depending on the mechanisms which have been registered an
+ * the peer may receive a shutdown notification as:
+ *
+ *   - An event channel notification on a dedicated event channel
+ *   - Observation of the other ends's status byte being cleared
+ * (whether in response to an explicit notification or in the
+ * course of normal operation).
+ *
+ * The mechanism should be defined as part of the specific ring
+ * protocol.
+ *
+ * Upon receiving notification of the peer is expected to teardown any
+ * resources (and in particular any grant mappings) in a timely
+ * manner.
+ *
+ * NOTE: this protocol is intended to allow for better error behaviour
+ * and recovery between two cooperating peers. It does not cover the
+ * case of a malivious peer who may continue to hold resources open.
+ */
+
+/*
  * Grant Table Interface (making use of grants from other domains)
  */
 
 typedef struct xengntdev_handle xengnttab_handle;
 
 /*
- * Note:
- * After fork a child process 

[Xen-devel] [PATCH MINI-OS v8 0/4] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell]

We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.

This is the mini-os part of the first phase of that change.

This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.

Ian Campbell (4):
  mini-os: Include libxenevtchn with libxc
  mini-os: Include libxengnttab with libxc
  mini-os: Include libxencall with libxc
  mini-os: Include libxenforeignmemory with libxc

 Makefile | 4 
 1 file changed, 4 insertions(+)

-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v8 2/8] xen: Switch to libxenevtchn interface for compat shims.

[Ian Campbell]

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenevtchn which provides access to event
channels.

In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the evtchn shim will disappear
for versions of Xen which include libxenevtchn.

To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.

Note that this patch does not add any support for actually using
libxenevtchn, it just adjusts the existing shims.

Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.

Signed-off-by: Ian Campbell 
Reviewed-by: Stefano Stabellini 
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not size of the ptr)
---
 hw/xen/xen_backend.c | 31 ---
 include/hw/xen/xen_backend.h |  2 +-
 include/hw/xen/xen_common.h  | 44 ++--
 xen-hvm.c| 25 +
 4 files changed, 64 insertions(+), 38 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 2510e2e..ae2a1f0 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -243,19 +243,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 xendev->debug  = debug;
 xendev->local_port = -1;
 
-xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
-if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
+xendev->evtchndev = xenevtchn_open(NULL, 0);
+if (xendev->evtchndev == NULL) {
 xen_be_printf(NULL, 0, "can't open evtchn device\n");
 g_free(xendev);
 return NULL;
 }
-fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
 
 if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
 xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
 if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
 xen_be_printf(NULL, 0, "can't open gnttab device\n");
-xc_evtchn_close(xendev->evtchndev);
+xenevtchn_close(xendev->evtchndev);
 g_free(xendev);
 return NULL;
 }
@@ -306,8 +306,8 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
 g_free(xendev->fe);
 }
 
-if (xendev->evtchndev != XC_HANDLER_INITIAL_VALUE) {
-xc_evtchn_close(xendev->evtchndev);
+if (xendev->evtchndev != NULL) {
+xenevtchn_close(xendev->evtchndev);
 }
 if (xendev->gnttabdev != XC_HANDLER_INITIAL_VALUE) {
 xc_gnttab_close(xendev->gnttabdev);
@@ -691,13 +691,14 @@ static void xen_be_evtchn_event(void *opaque)
 struct XenDevice *xendev = opaque;
 evtchn_port_t port;
 
-port = xc_evtchn_pending(xendev->evtchndev);
+port = xenevtchn_pending(xendev->evtchndev);
 if (port != xendev->local_port) {
-xen_be_printf(xendev, 0, "xc_evtchn_pending returned %d (expected 
%d)\n",
+xen_be_printf(xendev, 0,
+  "xenevtchn_pending returned %d (expected %d)\n",
   port, xendev->local_port);
 return;
 }
-xc_evtchn_unmask(xendev->evtchndev, port);
+xenevtchn_unmask(xendev->evtchndev, port);
 
 if (xendev->ops->event) {
 xendev->ops->event(xendev);
@@ -740,14 +741,14 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 if (xendev->local_port != -1) {
 return 0;
 }
-xendev->local_port = xc_evtchn_bind_interdomain
+xendev->local_port = xenevtchn_bind_interdomain
 (xendev->evtchndev, xendev->dom, xendev->remote_port);
 if (xendev->local_port == -1) {
-xen_be_printf(xendev, 0, "xc_evtchn_bind_interdomain failed\n");
+xen_be_printf(xendev, 0, "xenevtchn_bind_interdomain failed\n");
 return -1;
 }
 xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev),
 xen_be_evtchn_event, NULL, xendev);
 return 0;
 }
@@ -757,15 +758,15 @@ void xen_be_unbind_evtchn(struct XenDevice *xendev)
 if (xendev->local_port == -1) {
 return;
 }
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
-xc_evtchn_unbind(xendev->evtchndev, xendev->local_port);
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
+xenevtchn_unbind(xendev->evtchndev, 

[Xen-devel] [PATCH QEMU-XEN v8 8/8] xen: make it possible to build without the Xen PV domain builder

[Ian Campbell]

Until the previous patch this relied on xc_fd(), which was only
implemented for Xen 4.0 and earlier.

Given this wasn't working since Xen 4.0 I have marked this as disabled
by default.

Removing this support drops the use of a bunch of symbols from
libxenctrl, specifically:

  - xc_domain_create
  - xc_domain_destroy
  - xc_domain_getinfo
  - xc_domain_max_vcpus
  - xc_domain_setmaxmem
  - xc_domain_unpause
  - xc_evtchn_alloc_unbound
  - xc_linux_build

This is another step towards only using Xen libraries which provide a
stable inteface.

Signed-off-by: Ian Campbell 
Reviewed-by: Stefano Stabellini 
---
v6: Rebase onto "xen: fix usage of xc_domain_create in domain
builder" (trivial, Reviewed-by retained)

v5: XEN_CREATE entirely wihtin CONFIG_XEN_PV_DOMAIN_BUILD ifdef.
Simplify configure'ry.

v4: Fixed all checkpatch errors.
Disabled by default.
---
 configure   | 15 +++
 hw/xenpv/Makefile.objs  |  4 +++-
 hw/xenpv/xen_machine_pv.c   | 15 +++
 include/hw/xen/xen_common.h |  2 ++
 4 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 9ead31d..3506e44 100755
--- a/configure
+++ b/configure
@@ -250,6 +250,7 @@ vnc_jpeg=""
 vnc_png=""
 xen=""
 xen_ctrl_version=""
+xen_pv_domain_build="no"
 xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
@@ -927,6 +928,10 @@ for opt do
   ;;
   --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
   ;;
+  --disable-xen-pv-domain-build) xen_pv_domain_build="no"
+  ;;
+  --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -2229,6 +2234,12 @@ if test "$xen_pci_passthrough" != "no"; then
   fi
 fi
 
+if test "$xen_pv_domain_build" = "yes" &&
+   test "$xen" != "yes"; then
+error_exit "User requested Xen PV domain builder support" \
+  "which requires Xen support."
+fi
+
 ##
 # libtool probe
 
@@ -4848,6 +4859,7 @@ fi
 echo "xen support   $xen"
 if test "$xen" = "yes" ; then
   echo "xen ctrl version  $xen_ctrl_version"
+  echo "pv dom build  $xen_pv_domain_build"
 fi
 echo "brlapi support$brlapi"
 echo "bluez  support$bluez"
@@ -5219,6 +5231,9 @@ fi
 if test "$xen" = "yes" ; then
   echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
   echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> 
$config_host_mak
+  if test "$xen_pv_domain_build" = "yes" ; then
+echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
+  fi
 fi
 if test "$linux_aio" = "yes" ; then
   echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
diff --git a/hw/xenpv/Makefile.objs b/hw/xenpv/Makefile.objs
index 49f6e9e..bbf5873 100644
--- a/hw/xenpv/Makefile.objs
+++ b/hw/xenpv/Makefile.objs
@@ -1,2 +1,4 @@
 # Xen PV machine support
-obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o
+obj-$(CONFIG_XEN) += xen_machine_pv.o
+# Xen PV machine builder support
+obj-$(CONFIG_XEN_PV_DOMAIN_BUILD) += xen_domainbuild.o
diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 23d6ef0..3250b94 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -30,9 +30,6 @@
 
 static void xen_init_pv(MachineState *machine)
 {
-const char *kernel_filename = machine->kernel_filename;
-const char *kernel_cmdline = machine->kernel_cmdline;
-const char *initrd_filename = machine->initrd_filename;
 DriveInfo *dinfo;
 int i;
 
@@ -46,17 +43,27 @@ static void xen_init_pv(MachineState *machine)
 case XEN_ATTACH:
 /* nothing to do, xend handles everything */
 break;
-case XEN_CREATE:
+#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
+case XEN_CREATE: {
+const char *kernel_filename = machine->kernel_filename;
+const char *kernel_cmdline = machine->kernel_cmdline;
+const char *initrd_filename = machine->initrd_filename;
 if (xen_domain_build_pv(kernel_filename, initrd_filename,
 kernel_cmdline) < 0) {
 fprintf(stderr, "xen pv domain creation failed\n");
 exit(1);
 }
 break;
+}
+#endif
 case XEN_EMULATE:
 fprintf(stderr, "xen emulation not implemented (yet)\n");
 exit(1);
 break;
+default:
+fprintf(stderr, "unhandled xen_mode %d\n", xen_mode);
+exit(1);
+break;
 }
 
 xen_be_register("console", _console_ops);
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index be7a915..0d83891 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -505,6 +505,7 @@ static inline int xen_xc_domain_add_to_physmap(XenXC xch, 
uint32_t domid,
 }
 #endif
 
+#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 470
 static inline int xen_domain_create(XenXC xc, uint32_t ssidref,
 xen_domain_handle_t handle, uint32_t 

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v8 4/4] qemu-xen-traditional: Add libxenforeignmemory to rpath-link

[Ian Campbell]

libxenctrl links against this library.

Also, request the compat xc_map_foreign API from libxc.

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 
---
v3: Library moved to tools/libs/
---
 xen-hooks.mak | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen-hooks.mak b/xen-hooks.mak
index 229d642..c1ea4be 100644
--- a/xen-hooks.mak
+++ b/xen-hooks.mak
@@ -1,6 +1,7 @@
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/toollog/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/evtchn/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libs/gnttab/include
+CPPFLAGS+= -DXC_WANT_COMPAT_MAP_FOREIGN_API
 CPPFLAGS+= -I$(XEN_ROOT)/tools/libxc/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/xenstore/include
 CPPFLAGS+= -I$(XEN_ROOT)/tools/include
@@ -26,6 +27,7 @@ LIBS += -L$(XEN_ROOT)/tools/libxc -lxenctrl -lxenguest
 LIBS += -L$(XEN_ROOT)/tools/xenstore -lxenstore
 LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog
 LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/call
+LIBS += -Wl,-rpath-link=$(XEN_ROOT)/tools/libs/foreignmemory
 
 LDFLAGS := $(CFLAGS) $(LDFLAGS)
 
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 25/29] tools/libs/{call, evtchn}: Document requirements around forking.

[Ian Campbell]

Much like for gnttab and foreignmemory xencall hypercall buffers need
care.

Evtchn is a bit simpler (no magic mappings) but may not work from
parent + child simultaneously, document "parent only" since it is
consistent with the others.

Signed-off-by: Ian Campbell 
---
v7: New
---
 tools/libs/call/include/xencall.h | 28 
 tools/libs/evtchn/include/xenevtchn.h | 23 +++
 2 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/tools/libs/call/include/xencall.h 
b/tools/libs/call/include/xencall.h
index 3f325f0..559624a 100644
--- a/tools/libs/call/include/xencall.h
+++ b/tools/libs/call/include/xencall.h
@@ -36,11 +36,39 @@ typedef struct xencall_handle xencall_handle;
 
 /*
  * Return a handle onto the hypercall driver.  Logs errors.
+ * *
+ * Note: After fork(2) a child process must not use any opened
+ * xencall handle inherited from their parent, nor access any
+ * hypercall argument buffers associated with that handle.
+ *
+ * The child must open a new handle if they want to interact with
+ * xencall.
+ *
+ * Calling exec(2) in a child will safely (and reliably) reclaim any
+ * resources which were allocated via a xencall_handle in the parent.
+ *
+ * A child which does not call exec(2) may safely call xencall_close()
+ * on a xencall_handle inherited from their parent. This will attempt
+ * to reclaim any resources associated with that handle. Note that in
+ * some implementations this reclamation may not be completely
+ * effective, in this case any affected resources remain allocated.
+ *
+ * Calling xencall_close() is the only safe operation on a
+ * xencall_handle which has been inherited.
  */
 xencall_handle *xencall_open(xentoollog_logger *logger, unsigned open_flags);
 
 /*
  * Close a handle previously allocated with xencall_open().
+ *
+ * Under normal circumstances (i.e. not in the child after a fork) any
+ * allocated hypercall argument buffers should be freed using the
+ * appropriate xencall_free_*() prior to closing the handle in order
+ * to free up resources associated with those mappings.
+ *
+ * This is the only function which may be safely called on a
+ * xencall_handle in a child after a fork. xencall_free_*() must not
+ * be called under such circumstances.
  */
 int xencall_close(xencall_handle *xcall);
 
diff --git a/tools/libs/evtchn/include/xenevtchn.h 
b/tools/libs/evtchn/include/xenevtchn.h
index 428d54c..4d26161 100644
--- a/tools/libs/evtchn/include/xenevtchn.h
+++ b/tools/libs/evtchn/include/xenevtchn.h
@@ -45,10 +45,25 @@ typedef struct xentoollog_logger xentoollog_logger;
  * Return a handle to the event channel driver, or NULL on failure, in
  * which case errno will be set appropriately.
  *
- * Note:
- * After fork a child process must not use any opened evtchn
- * handle inherited from their parent. They must open a new handle if
- * they want to interact with evtchn.
+ * Note: After fork(2) a child process must not use any opened evtchn
+ * handle inherited from their parent, nor access any grant mapped
+ * areas associated with that handle.
+ *
+ * The child must open a new handle if they want to interact with
+ * evtchn.
+ *
+ * Calling exec(2) in a child will safely (and reliably) reclaim any
+ * allocated resources via a xenevtchn_handle in the parent.
+ *
+ * A child which does not call exec(2) may safely call
+ * xenevtchn_close() on a xenevtchn_handle inherited from their
+ * parent. This will attempt to reclaim any resources associated with
+ * that handle. Note that in some implementations this reclamation may
+ * not be completely effective, in this case any affected resources
+ * remain allocated.
+ *
+ * Calling xenevtchn_close() is the only safe operation on a
+ * xenevtchn_handle which has been inherited.
  */
 /* Currently no flags are defined */
 xenevtchn_handle *xenevtchn_open(xentoollog_logger *logger, unsigned 
open_flags);
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 15/29] tools/libs/foreignmemory: Support err == NULL to map.

[Ian Campbell]

The existing xc_map_foreign_bulk-like interface encourages callers to
miss error checking for partial failure (by forgetting to scan the err
array).

Add support for passing err==NULL which behaves in a
xc_map_foreign_pages-like manner and returns a global error for any
failure.

While documenting this also clarify the overall behaviour and the
behaviour with err!=NULL.

With this the compat wrapper of xc_map_foreign_pages() can be
simplified.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---
v7: Check for NULL when allocating err.

v6: New
---
 tools/libs/foreignmemory/core.c| 33 +-
 .../libs/foreignmemory/include/xenforeignmemory.h  | 24 ++--
 tools/libxc/xc_foreign_memory.c| 22 +--
 3 files changed, 54 insertions(+), 25 deletions(-)

diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index 21dc7ee..4e0541f 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -14,6 +14,8 @@
  */
 
 #include 
+#include 
+#include 
 
 #include "private.h"
 
@@ -64,7 +66,36 @@ void *xenforeignmemory_map(xenforeignmemory_handle *fmem,
uint32_t dom, int prot,
const xen_pfn_t *arr, int *err, size_t num)
 {
-return osdep_xenforeignmemory_map(fmem, dom, prot, arr, err, num);
+void *ret;
+int *err_to_free = NULL;
+
+if ( err == NULL )
+err = err_to_free = malloc(num * sizeof(int));
+
+if ( err == NULL )
+return NULL;
+
+ret = osdep_xenforeignmemory_map(fmem, dom, prot, arr, err, num);
+
+if ( ret == 0 && err_to_free )
+{
+int i;
+
+for ( i = 0 ; i < num ; i++ )
+{
+if ( err[i] )
+{
+errno = -err[i];
+(void)osdep_xenforeignmemory_unmap(fmem, ret, num);
+ret = NULL;
+break;
+}
+}
+}
+
+free(err_to_free);
+
+return ret;
 }
 
 int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index a6d1bdb..0ec6325 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -80,10 +80,28 @@ int xenforeignmemory_close(xenforeignmemory_handle *fmem);
  *
  * prot is as for mmap(2).
  *
- * Can partially succeed. When a page cannot be mapped, its respective
- * field in @err is set to the corresponding errno value.
+ * @arr is an array of @pages gfns to be mapped linearly in the local
+ * address range. @err is an (optional) output array used to report
+ * per-page errors, as errno values.
  *
- * Returns NULL if no pages can be mapped.
+ * If @err is given (is non-NULL) then the mapping may partially
+ * succeed and return a valid pointer while also using @err to
+ * indicate the success (0) or failure (errno value) of the individual
+ * pages. The global errno thread local variable is not valid in this
+ * case.
+ *
+ * If @err is not given (is NULL) then on failure to map any page any
+ * successful mappings will be undone and NULL will be returned. errno
+ * will be set to correspond to the first failure (which may not be
+ * the most critical).
+ *
+ * It is also possible to return NULL due to a complete failure,
+ * i.e. failure to even attempt the mapping, in this case the global
+ * errno will have been set and the contents of @err (if given) is
+ * invalid.
+ *
+ * Note that it is also possible to return non-NULL with the contents
+ * of @err indicating failure to map every page.
  */
 void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
int prot, const xen_pfn_t *arr, int *err,
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 1737c10..4b24388 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -23,32 +23,12 @@
 void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, int prot,
const xen_pfn_t *arr, int num)
 {
-void *res;
-int i, *err;
-
 if (num < 0) {
 errno = EINVAL;
 return NULL;
 }
 
-err = malloc(num * sizeof(*err));
-if (!err)
-return NULL;
-
-res = xenforeignmemory_map(xch->fmem, dom, prot, arr, err, num);
-if (res) {
-for (i = 0; i < num; i++) {
-if (err[i]) {
-errno = -err[i];
-munmap(res, num * PAGE_SIZE);
-res = NULL;
-break;
-}
-}
-}
-
-free(err);
-return res;
+return xenforeignmemory_map(xch->fmem, dom, prot, arr, NULL, num);
 }
 
 void *xc_map_foreign_range(xc_interface *xch,
-- 
2.1.4


___

[Xen-devel] [PATCH XEN v8 27/29] tools: Update CFLAGS for qemu-xen to allow it to use new libraries

[Ian Campbell]

This means adding -L for libxen{evtchn,gnttab,foreignmemory} so that
it can link them directly (rather than using the libxenctrl compat
layer exposed via -rpath-link). Also add -I for libxenforeignmemory.

Signed-off-by: Ian Campbell 
Acked-by: Wei Liu 
---
 tools/Makefile | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/Makefile b/tools/Makefile
index c03f6db..3575f16 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -255,12 +255,16 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
-I$(XEN_ROOT)/tools/libs/toollog/include \
-I$(XEN_ROOT)/tools/libs/evtchn/include \
-I$(XEN_ROOT)/tools/libs/gnttab/include \
+   -I$(XEN_ROOT)/tools/libs/foreignmemory/include \
-I$(XEN_ROOT)/tools/libxc/include \
-I$(XEN_ROOT)/tools/xenstore/include \
-I$(XEN_ROOT)/tools/xenstore/compat/include \
$(EXTRA_CFLAGS_QEMU_XEN)" \
--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
-L$(XEN_ROOT)/tools/xenstore \
+   -L$(XEN_ROOT)/tools/libs/evtchn \
+   -L$(XEN_ROOT)/tools/libs/gnttab \
+   -L$(XEN_ROOT)/tools/libs/foreignmemory \
-Wl,-rpath-link=$(XEN_ROOT)/tools/libs/toollog \
-Wl,-rpath-link=$(XEN_ROOT)/tools/libs/evtchn \
-Wl,-rpath-link=$(XEN_ROOT)/tools/libs/gnttab \
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v8 6/8] xen: Use stable library interfaces when they are available.

[Ian Campbell]

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

Specifically libxenevtchn, libxengnttab and libxenforeignmemory.

Previous patches have already laid the groundwork for using these by
switching the existing compatibility shims to reflect the intefaces to
these libraries.

So all which remains is to update configure to detect the libraries
and enable their use. Although they are notionally independent we take
an all or nothing approach to the three libraries since they were
added at the same time.

The only non-obvious bit is that we now open a proper xenforeignmemory
handle for xen_fmem instead of reusing the xen_xc handle.

Build tested with 4.0 .. 4.6 (inclusive) and the patches targetting
4.7 which adds these libraries.

This uses CONFIG_XEN_CTRL_INTERFACE_VERSION == 471 to cover the
introduction of these new interfaces.

Signed-off-by: Ian Campbell 
---

v8: Use CONFIG_XEN_CTRL_INTERFACE_VERSION == 471 for new interfaces.
Dropped Reviewed-by.

v6: Two minor formatting things.
Rebase onto "xen: fix usage of xc_domain_create in domain
builder", required adjusting the configure script changes.

The rebase wasn't entirely trivial (semantically), so dropped
Stefano's reviwed by.

v5: Remove ifdef check when undeffing the compat stuff.
s/now way/no way/

v4: xenforeignmemory_open is now a compat wrapper, so no ifdef.

Simplify configury by asserting that interface version 470 will
always have the libraries (lack of them makes it 460).

Ran checkpatch and fixed everything except:

ERROR: need consistent spacing around '*' (ctx:WxV)
+typedef xc_interface *XenXC;

Which I think is a false +ve.

Simpler configure stuff
---
 configure   | 55 +
 include/hw/xen/xen_common.h | 35 +++--
 2 files changed, 88 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 44ac9ab..9ead31d 100755
--- a/configure
+++ b/configure
@@ -1938,6 +1938,7 @@ fi
 
 if test "$xen" != "no" ; then
   xen_libs="-lxenstore -lxenctrl -lxenguest"
+  xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"
 
   # First we test whether Xen headers and libraries are available.
   # If no, we are done and there is no Xen support.
@@ -1960,6 +1961,57 @@ EOF
   # Xen unstable
   elif
   cat > $TMPC <
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+  xc_interface *xc = NULL;
+  xenforeignmemory_handle *xfmem;
+  xenevtchn_handle *xe;
+  xengnttab_handle *xg;
+  xen_domain_handle_t handle;
+
+  xs_daemon_open();
+
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
+  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
+  xc_domain_create(xc, 0, handle, 0, NULL, NULL);
+
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
+
+  xe = xenevtchn_open(0, 0);
+  xenevtchn_fd(xe);
+
+  xg = xengnttab_open(0, 0);
+  xengnttab_map_grant_ref(xg, 0, 0, 0);
+
+  return 0;
+}
+EOF
+  compile_prog "" "$xen_libs $xen_stable_libs"
+then
+xen_ctrl_version=471
+xen=yes
+  elif
+  cat > $TMPC <
 #include 
 int main(void) {
@@ -2153,6 +2205,9 @@ EOF
   fi
 
   if test "$xen" = yes; then
+if test $xen_ctrl_version -ge 471  ; then
+  libs_softmmu="$xen_stable_libs $libs_softmmu"
+fi
 libs_softmmu="$xen_libs $libs_softmmu"
   fi
 fi
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 95275b3..19f1577 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -6,6 +6,15 @@
 #include 
 #include 
 
+/*
+ * If we have new enough libxenctrl then we do not want/need these compat
+ * interfaces, despite what the user supplied cflags might say. They
+ * must be undefined before including xenctrl.h
+ */
+#undef XC_WANT_COMPAT_EVTCHN_API
+#undef XC_WANT_COMPAT_GNTTAB_API
+#undef XC_WANT_COMPAT_MAP_FOREIGN_API
+
 #include 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
 #  include 
@@ -148,8 +157,8 @@ static inline void xs_close(struct xs_handle *xsh)
 }
 
 
-/* Xen 4.1 */
-#else
+/* Xen 4.1 thru 4.6 */
+#elif CONFIG_XEN_CTRL_INTERFACE_VERSION < 471
 
 typedef xc_interface *XenXC;
 typedef xc_interface *xenforeignmemory_handle;
@@ -184,6 +193,28 @@ static inline XenXC xen_xc_interface_open(void *logger, 
void *dombuild_logger,
 
 /* See below for xenforeignmemory_* APIs */
 
+/* FIXME There is no way to have the xen fd */
+static inline int xc_fd(xc_interface *xen_xc)
+{
+return -1;
+}
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 471 */
+
+typedef xc_interface *XenXC;
+
+#  define XC_INTERFACE_FMT "%p"
+#  define 

[Xen-devel] [PATCH XEN v8 14/29] tools/libs/foreignmemory: Mention restrictions on fork in docs.

[Ian Campbell]

Signed-off-by: Ian Campbell 
---
v6: Also discuss recovering the memory.

v7: Further clarifications regarding forking based on ML discussions.
(Dropped Wei's ack)
---
 .../libs/foreignmemory/include/xenforeignmemory.h  | 33 +-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index 04ff548..a6d1bdb 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -32,13 +32,44 @@ typedef struct xentoollog_logger xentoollog_logger;
 typedef struct xenforeignmemory_handle xenforeignmemory_handle;
 
 /*
- * Return a handle onto the hypercall driver.  Logs errors.
+ * Return a handle onto the foreign memory mapping driver.  Logs errors.
+ *
+ * Note: After fork(2) a child process must not use any opened
+ * foreignmemory handle inherited from their parent, nor access any
+ * grant mapped areas associated with that handle.
+ *
+ * The child must open a new handle if they want to interact with
+ * foreignmemory.
+ *
+ * Calling exec(2) in a child will safely (and reliably) reclaim any
+ * resources which were allocated via a xenforeignmemory_handle in the
+ * parent.
+ *
+ * A child which does not call exec(2) may safely call
+ * xenforeignmemory_close() on a xenforeignmemory_handle inherited
+ * from their parent. This will attempt to reclaim any resources
+ * associated with that handle. Note that in some implementations this
+ * reclamation may not be completely effective, in this case any
+ * affected resources remain allocated.
+ *
+ * Calling xenforeignmemory_close() is the only safe operation on a
+ * xenforeignmemory_handle which has been inherited.
  */
 xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger,
unsigned open_flags);
 
 /*
  * Close a handle previously allocated with xenforeignmemory_open().
+ *
+ * Under normal circumstances (i.e. not in the child after a fork)
+ * xenforeignmemory_unmap() should be used on all mappings allocated
+ * by xenforeignmemory_map() prior to closing the handle in order to
+ * free up resources associated with those mappings.
+ *
+ * This is the only function which may be safely called on a
+ * xenforeignmemory_handle in a child after a
+ * fork. xenforeignmemory_unmap() must not be called under such
+ * circumstances.
  */
 int xenforeignmemory_close(xenforeignmemory_handle *fmem);
 
-- 
2.1.4


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

[Xen-devel] [PATCH XEN v8 18/29] tools/libs/evtchn: Use uint32_t for domid arguments

[Ian Campbell]

Signed-off-by: Ian Campbell 
---
v8: New
---
 tools/libs/evtchn/freebsd.c   | 4 ++--
 tools/libs/evtchn/include/xenevtchn.h | 4 ++--
 tools/libs/evtchn/linux.c | 4 ++--
 tools/libs/evtchn/minios.c| 4 ++--
 tools/libs/evtchn/netbsd.c| 4 ++--
 tools/libs/evtchn/solaris.c   | 4 ++--
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/tools/libs/evtchn/freebsd.c b/tools/libs/evtchn/freebsd.c
index 636f052..6479f7c 100644
--- a/tools/libs/evtchn/freebsd.c
+++ b/tools/libs/evtchn/freebsd.c
@@ -62,7 +62,7 @@ int xenevtchn_notify(xenevtchn_handle *xce, evtchn_port_t 
port)
 return ioctl(fd, IOCTL_EVTCHN_NOTIFY, );
 }
 
-evtchn_port_or_error_t xenevtchn_bind_unbound_port(xenevtchn_handle *xce, int 
domid)
+evtchn_port_or_error_t xenevtchn_bind_unbound_port(xenevtchn_handle *xce, 
uint32_t domid)
 {
 int ret, fd = xce->fd;
 struct ioctl_evtchn_bind_unbound_port bind;
@@ -74,7 +74,7 @@ evtchn_port_or_error_t 
xenevtchn_bind_unbound_port(xenevtchn_handle *xce, int do
 }
 
 evtchn_port_or_error_t
-xenevtchn_bind_interdomain(xenevtchn_handle *xce, int domid, evtchn_port_t 
remote_port)
+xenevtchn_bind_interdomain(xenevtchn_handle *xce, uint_32 domid, evtchn_port_t 
remote_port)
 {
 int ret, fd = xce->fd;
 struct ioctl_evtchn_bind_interdomain bind;
diff --git a/tools/libs/evtchn/include/xenevtchn.h 
b/tools/libs/evtchn/include/xenevtchn.h
index 60da2a3..428d54c 100644
--- a/tools/libs/evtchn/include/xenevtchn.h
+++ b/tools/libs/evtchn/include/xenevtchn.h
@@ -86,14 +86,14 @@ int xenevtchn_notify(xenevtchn_handle *xce, evtchn_port_t 
port);
  * domain ID, or -1 on failure, in which case errno will be set appropriately.
  */
 evtchn_port_or_error_t
-xenevtchn_bind_unbound_port(xenevtchn_handle *xce, int domid);
+xenevtchn_bind_unbound_port(xenevtchn_handle *xce, uint32_t domid);
 
 /*
  * Returns a new event port bound to the remote port for the given domain ID,
  * or -1 on failure, in which case errno will be set appropriately.
  */
 evtchn_port_or_error_t
-xenevtchn_bind_interdomain(xenevtchn_handle *xce, int domid,
+xenevtchn_bind_interdomain(xenevtchn_handle *xce, uint32_t domid,
evtchn_port_t remote_port);
 
 /*
diff --git a/tools/libs/evtchn/linux.c b/tools/libs/evtchn/linux.c
index 27fd6e9..76cf0ac 100644
--- a/tools/libs/evtchn/linux.c
+++ b/tools/libs/evtchn/linux.c
@@ -61,7 +61,7 @@ int xenevtchn_notify(xenevtchn_handle *xce, evtchn_port_t 
port)
 }
 
 evtchn_port_or_error_t xenevtchn_bind_unbound_port(xenevtchn_handle *xce,
-   int domid)
+   uint32_t domid)
 {
 int fd = xce->fd;
 struct ioctl_evtchn_bind_unbound_port bind;
@@ -72,7 +72,7 @@ evtchn_port_or_error_t 
xenevtchn_bind_unbound_port(xenevtchn_handle *xce,
 }
 
 evtchn_port_or_error_t xenevtchn_bind_interdomain(xenevtchn_handle *xce,
-  int domid,
+  uint32_t domid,
   evtchn_port_t remote_port)
 {
 int fd = xce->fd;
diff --git a/tools/libs/evtchn/minios.c b/tools/libs/evtchn/minios.c
index b839cd0..773942d 100644
--- a/tools/libs/evtchn/minios.c
+++ b/tools/libs/evtchn/minios.c
@@ -128,7 +128,7 @@ static void evtchn_handler(evtchn_port_t port, struct 
pt_regs *regs, void *data)
 wake_up(_queue);
 }
 
-evtchn_port_or_error_t xenevtchn_bind_unbound_port(xenevtchn_handle *xce, int 
domid)
+evtchn_port_or_error_t xenevtchn_bind_unbound_port(xenevtchn_handle *xce, 
uint32_t domid)
 {
 int fd = xce->fd;
 struct evtchn_port_info *port_info;
@@ -155,7 +155,7 @@ evtchn_port_or_error_t 
xenevtchn_bind_unbound_port(xenevtchn_handle *xce, int do
 return port;
 }
 
-evtchn_port_or_error_t xenevtchn_bind_interdomain(xenevtchn_handle *xce, int 
domid,
+evtchn_port_or_error_t xenevtchn_bind_interdomain(xenevtchn_handle *xce, 
uint32_t domid,
   evtchn_port_t remote_port)
 {
 int fd = xce->fd;
diff --git a/tools/libs/evtchn/netbsd.c b/tools/libs/evtchn/netbsd.c
index c4123fe..1472ca6 100644
--- a/tools/libs/evtchn/netbsd.c
+++ b/tools/libs/evtchn/netbsd.c
@@ -62,7 +62,7 @@ int xenevtchn_notify(xenevtchn_handle *xce, evtchn_port_t 
port)
 return ioctl(fd, IOCTL_EVTCHN_NOTIFY, );
 }
 
-evtchn_port_or_error_t xenevtchn_bind_unbound_port(xenevtchn_handle * xce, int 
domid)
+evtchn_port_or_error_t xenevtchn_bind_unbound_port(xenevtchn_handle * xce, 
uint32_t domid)
 {
 int fd = xce->fd;
 struct ioctl_evtchn_bind_unbound_port bind;
@@ -77,7 +77,7 @@ evtchn_port_or_error_t 
xenevtchn_bind_unbound_port(xenevtchn_handle * xce, int d
return -1;
 }
 
-evtchn_port_or_error_t xenevtchn_bind_interdomain(xenevtchn_handle *xce, int 
domid,
+evtchn_port_or_error_t xenevtchn_bind_interdomain(xenevtchn_handle *xce, 

[Xen-devel] [PATCH MINI-OS v8 4/4] mini-os: Include libxenforeignmemory with libxc

[Ian Campbell]

libxenforeignmemory has just been split out from libxc. From mini-os's
point of view we don't care about the distinction, so keep things
simple by just including libxenforeignmemory if libxc is enabled.

Signed-off-by: Ian Campbell 
Acked-by: Samuel Thibault 
Acked-by: Wei Liu 
---
v2: Adjust for libs/$lib layout.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index c900540..cfe015a 100644
--- a/Makefile
+++ b/Makefile
@@ -169,6 +169,7 @@ APP_LDLIBS += 
-L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog -whole-ar
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn 
-whole-archive -lxenevtchn -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab 
-whole-archive -lxengnttab -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call 
-whole-archive -lxencall -no-whole-archive
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/foreignmemory 
-whole-archive -lxenforeignmemory -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 endif
 APP_LDLIBS += -lpci
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v3] x86/p2m: use large pages for MMIO mappings

[Ian Campbell]

On Thu, 2016-01-14 at 03:04 -0700, Jan Beulich wrote:
> - ARM side unimplemented (and hence libxc for now made cope with both
>   models),

So, one model is the one described in the commit message:

> - zero (success, everything done)
> - positive (success, this many done, more to do: re-invoke)
> - negative (error)

What is the other one? I'd expect ARM to already implement a subset of this
(i.e. 0 or negative, perhaps with a subset of the possible errno values), which 
I'd then expect libxc to just cope with without it constituting a second model.

IOW I don't think there should be (or indeed is) any special casing of ARM
vs x86 here or one model vs another, just a case of one arch only using a
subset of the expressibility of the interface.

What have I missed?


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

Re: [Xen-devel] [PATCH v1] xen/arm: Add r1p12 to the list of supported Cadence UARTs

[Edgar E. Iglesias]

On Fri, Jan 15, 2016 at 04:20:18AM -0700, Jan Beulich wrote:
> >>> On 14.01.16 at 19:44,  wrote:
> > --- a/xen/drivers/char/cadence-uart.c
> > +++ b/xen/drivers/char/cadence-uart.c
> 
> Considering the wider than expected Cc list - is there an entry missing
> from the ARM section in ./MAINTAINERS here?
>

Yes, that seems to be the case. I've just sent a patch to MAINTAINERS to fix 
that.

Cheers,
Edgar

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

[Xen-devel] [PATCH OSSTEST] Allow longer timeout when creating backing file for a raw disk.

[Ian Campbell]

I noticed this dd timiung out when recommissioning the 3 cubietrucks
(picasso, metzinger, gleizes) but looking at the log shows this has
been happening on braque too.

The current code assumes 65MB/s arriving at a timeout of 153s for the
10G file. On arndale-* the logs indicate that it is achieving 95MB/s
and taking 105-107s which results in a warning but not a failure:

   execution took 105 seconds [**>153.846153846154/2**]

In experiments on a local cubietruck I observed it achieving a much
lower throughput of 40MB/s, which seems to be consistent with what
others are seeing:
https://groups.google.com/forum/#!category-topic/cubieboard/troubleshooting/7R4HlCDNCTU

Therefore calculate the timeout assuming a throughput of 20MB/s, in
practice for a 10GB file this will result in a 500s timeout.

Signed-off-by: Ian Campbell 
---
 Osstest/TestSupport.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 28ac572..962d773 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1747,9 +1747,9 @@ sub make_qcow2 ($$$) {
 }
 sub make_raw ($$$) {
 my ($ho, $gho, $disk_mb) = @_;
-# In local tests this reported 130MB/s, so calculate a timeout assuming 
65MB/s.
+# In local tests this reported 40MB/s, so calculate a timeout assuming 
20MB/s.
 target_cmd_root($ho, "dd if=/dev/zero of=$gho->{Rootimg} bs=1MB 
count=${disk_mb}",
-   ${disk_mb} / 65);
+   ${disk_mb} / 20);
 }
 
 sub prepareguest_part_diskimg ($$$) {
-- 
2.6.1


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

Re: [Xen-devel] [PATCH v1] xen/arm: Add r1p12 to the list of supported Cadence UARTs

[Ian Campbell]

On Thu, 2016-01-14 at 19:44 +0100, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 

Where are the bindings for cdns,uart-r1p12 defined? I don't see it
mentioned in the Documentation/devicetree/bindings/serial/cdns,uart.txt in
mainline Linux.

Does the driver need to differ at all compared with what is needed for
r1p8? Normally if there is no (practical/visible) difference then in DT-
world there is no need for a new compatible string, since the device is
still compatible.

If there are differences in the h/w but they are not relevant to our
particular driven then please say so in the commit log.

Ian.

> 
> Signed-off-by: Edgar E. Iglesias 
> ---
>  xen/drivers/char/cadence-uart.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/drivers/char/cadence-uart.c b/xen/drivers/char/cadence-
> uart.c
> index 933672f..7f90f8d 100644
> --- a/xen/drivers/char/cadence-uart.c
> +++ b/xen/drivers/char/cadence-uart.c
> @@ -206,6 +206,7 @@ static int __init cuart_init(struct dt_device_node
> *dev, const void *data)
>  static const struct dt_device_match cuart_dt_match[] __initconst =
>  {
>  DT_MATCH_COMPATIBLE("cdns,uart-r1p8"),
> +DT_MATCH_COMPATIBLE("cdns,uart-r1p12"),
>  { /* sentinel */ },
>  };
>  

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

Re: [Xen-devel] [PATCH v1 1/1] MAINTAINERS: Add xen/drivers/char/cadence-uart.c

[Ian Campbell]

On Fri, 2016-01-15 at 13:14 +0100, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> Add xen/drivers/char/cadence-uart.c to the ARM section.
> 
> Signed-off-by: Edgar E. Iglesias 

Acked-by: Ian Campbell 

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 09fe823..0e8af01 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -133,6 +133,7 @@ S:Supported
>  L:   xen-devel@lists.xen.org
>  F:   xen/arch/arm/
>  F:   xen/include/asm-arm/
> +F:   xen/drivers/char/cadence-uart.c
>  F:   xen/drivers/char/dt-uart.c
>  F:   xen/drivers/char/exynos4210-uart.c
>  F:   xen/drivers/char/omap-uart.c

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

[Xen-devel] [xen-unstable-smoke test] 78168: tolerable all pass - PUSHED

[osstest service owner]

flight 78168 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78168/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  2f3b2f4aa242759826bbc61513ea06b2d124c9a7
baseline version:
 xen  7167222b15dc661ff0b44cc93d558f6bb4ff6492

Last test of basis78074  2016-01-14 10:01:37 Z1 days
Testing same since78168  2016-01-15 11:02:27 Z0 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Konrad Rzeszutek Wilk 
  Roger Pau Monne 
  Roger Pau Monné 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=2f3b2f4aa242759826bbc61513ea06b2d124c9a7
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
2f3b2f4aa242759826bbc61513ea06b2d124c9a7
+ branch=xen-unstable-smoke
+ revision=2f3b2f4aa242759826bbc61513ea06b2d124c9a7
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-unstable
+ '[' x2f3b2f4aa242759826bbc61513ea06b2d124c9a7 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or 

[Xen-devel] [PATCH] libxl: create 'drivers', 'feature' and 'attr' xenstore paths

[Paul Durrant]

My recent patch series 'docs: Document xenstore paths' included 3
patches documenting new xenstore paths to allow PV drivers/agents in
guests to advertise version information, significant features and
attributes (such as assigned IP addresses).

This patch adds the necessary code to libxl to create these paths in
xenstore when a domain is created.

Signed-off-by: Paul Durrant 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl_create.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 261816a..e491d83 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -628,6 +628,15 @@ retry_transaction:
 libxl__xs_mknod(gc, t,
 GCSPRINTF("%s/data", dom_path),
 rwperm, ARRAY_SIZE(rwperm));
+libxl__xs_mknod(gc, t,
+GCSPRINTF("%s/drivers", dom_path),
+rwperm, ARRAY_SIZE(rwperm));
+libxl__xs_mknod(gc, t,
+GCSPRINTF("%s/feature", dom_path),
+rwperm, ARRAY_SIZE(rwperm));
+libxl__xs_mknod(gc, t,
+GCSPRINTF("%s/attr", dom_path),
+rwperm, ARRAY_SIZE(rwperm));
 
 if (libxl_defbool_val(info->driver_domain)) {
 /*
-- 
2.1.4


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

Re: [Xen-devel] [PATCHv1 net] xen-netback: use skb to determine number of required guest Rx requests

[David Vrabel]

On 14/01/16 21:54, David Miller wrote:
> From: David Vrabel 
> Date: Thu, 14 Jan 2016 15:18:30 +
> 
>> -needed = xenvif_rx_ring_slots_needed(queue->vif);
>> +skb = skb_peek(>rx_queue);
>> +if (!skb)
>> +return false;
>> +
>> +needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
>> +if (skb_is_gso(skb))
>> +needed++;
> 
> If I am not mistaken, we moved away from this kind of test exactly because
> it is inaccurate and may under-estimate the needs.
> 
> It is possible for an N byte SKB to require N segments.  Therefore, the:
> 
>   DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
> 
> calculation doesn't cut it.

After 1650d5455bd2dc6b5ee134bd6fc1a3236c266b5b (xen-netback: always
fully coalesce guest Rx packets) we always fully pack a packet into its
guest Rx slots.  Each slot has space for XEN_PAGE_SIZE bytes so this
calculation for the number of slots is correct.

Shall I resend with a more description changelog?

David

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

Re: [Xen-devel] [PATCH v3] x86/p2m: use large pages for MMIO mappings

[Jan Beulich]

>>> On 15.01.16 at 11:09,  wrote:
> On Thu, 2016-01-14 at 03:04 -0700, Jan Beulich wrote:
>> - ARM side unimplemented (and hence libxc for now made cope with both
>>   models),
> 
> So, one model is the one described in the commit message:
> 
>> - zero (success, everything done)
>> - positive (success, this many done, more to do: re-invoke)
>> - negative (error)
> 
> What is the other one? I'd expect ARM to already implement a subset of this
> (i.e. 0 or negative, perhaps with a subset of the possible errno values), 
> which I'd then expect libxc to just cope with without it constituting a 
> second model.

Well, first of all ARM doesn't get switched away from the current
model (yet), i.e. returning -E2BIG out of do_domctl(). And then
the difference between what the patch implements and what the
non-commit message comment describes is how errors get handled:
The patch makes a negative error value returned upon error, with
the caller having no way to tell at what point the error occurred
(and with a best effort undo in the case of "map"). The described
alternative would return the number of succeeded entries unless
an error occurred on the very first MFN, without any attempt to
undo the part that was done successfully. I.e. it would leave it
to the caller to decide what to do, and whether/when to roll back.

Jan


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

Re: [Xen-devel] [PATCH] gitignore: update stubdom entries

[Ian Campbell]

On Thu, 2016-01-14 at 16:17 +, Wei Liu wrote:
> Add stubdom/libs-* to gitignore, then sort stubdom/* entries
> alphabetically.
> 
> Signed-off-by: Wei Liu 

Acked + applied.

I have discarded the previous "gitignore: ignore stubdom/libs-*".


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

[Xen-devel] [qemu-mainline test] 78136: tolerable FAIL - PUSHED

[osstest service owner]

flight 78136 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78136/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  9 debian-install   fail   like 78082

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuf02ccf53693758b65843264e077f90cf295e7d98
baseline version:
 qemuu91728bda76c1bfe49ac680af763154ec51988732

Last test of basis78082  2016-01-14 11:55:24 Z0 days
Testing same since78136  2016-01-15 01:47:34 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Amit Shah 
  Bharata B Rao 
  Cao jin 
  Christian Borntraeger 
  Cornelia Huck 
  David Hildenbrand 
  Fam Zheng 
  Halil Pasic 
  Jason J. Herne 
  Markus Armbruster 
  Markus Armbruster 
  Peter Maydell 
  Pierre Morel 
  Shmulik Ladkani 
  Yi Min Zhao 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl   

Re: [Xen-devel] [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163

[Jan Beulich]

>>> On 15.01.16 at 13:32,  wrote:
> placed microcode.bin in /boot/microcode.bin
> 
>   booted with :
> ---
> xen_commandline: ssd-xen-debug-marker console_timestamps=date 
> loglvl=all guest_loglvl=all sync_console iommu=1,verbose,debug 
> iommu_inclusive_mapping=1 com1=115200,8n1 console=com1 dom0_max_vcpus=4 
> dom0_vcpus_pin=1 dom0_mem=8G,max:8G cpufreq=xen:performance,verbose 
> tmem=1 sched_smt_power_savings=1 apic_verbosity=debug e820-verbose=1 
> core_parking=power ucode=microcode.bin
> ---

This can't work - did you look at the command line documentation?
You can't specify a file name here - there's no file system driver
inside the hypervisor, and hence it can't read files (it instead has
to rely on the boot loader bringing those into memory for it).

> #cat /proc/cpuinfo | grep micro
> says: microcode: 0x31
> 
> This is no change from previous boot.
> Now: How do I know wheter 0x31 is the newest?

By checking - for the precise model and stepping of your CPU(s) -
the information in the blob (which admittedly is a little cumbersome,
but without knowing model and stepping I also can't try to help).

Jan


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

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v8 1/4] qemu-xen-traditional: Use libxenevtchn

[Ian Campbell]

/dev/xen/evtchn related wrappers have been moved out of libxenctrl
into their own library.

Note that i386-dm/helper2.c's xc_interface * was always really an
xc_evtchn *, it's just they used to be typedefs to the same thing...

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 
---
v3: Library moved to tools/libs/
---
 hw/xen_backend.c  | 26 +-
 hw/xen_backend.h  |  2 +-
 hw/xen_common.h   |  1 +
 i386-dm/helper2.c | 19 ++-
 xen-hooks.mak |  2 ++
 5 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/hw/xen_backend.c b/hw/xen_backend.c
index 92b3506..40f6887 100644
--- a/hw/xen_backend.c
+++ b/hw/xen_backend.c
@@ -208,19 +208,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 xendev->debug  = debug;
 xendev->local_port = -1;
 
-xendev->evtchndev = xc_evtchn_open(NULL, 0);
+xendev->evtchndev = xenevtchn_open(NULL, 0);
 if (xendev->evtchndev == NULL) {
xen_be_printf(NULL, 0, "can't open evtchn device\n");
qemu_free(xendev);
return NULL;
 }
-fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
 
 if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
xendev->gnttabdev = xc_gnttab_open(NULL, 0);
if (xendev->gnttabdev == NULL) {
xen_be_printf(NULL, 0, "can't open gnttab device\n");
-   xc_evtchn_close(xendev->evtchndev);
+   xenevtchn_close(xendev->evtchndev);
qemu_free(xendev);
return NULL;
}
@@ -268,7 +268,7 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
}
 
if (xendev->evtchndev != NULL)
-   xc_evtchn_close(xendev->evtchndev);
+   xenevtchn_close(xendev->evtchndev);
if (xendev->gnttabdev != NULL)
xc_gnttab_close(xendev->gnttabdev);
 
@@ -630,13 +630,13 @@ static void xen_be_evtchn_event(void *opaque)
 struct XenDevice *xendev = opaque;
 evtchn_port_t port;
 
-port = xc_evtchn_pending(xendev->evtchndev);
+port = xenevtchn_pending(xendev->evtchndev);
 if (port != xendev->local_port) {
-   xen_be_printf(xendev, 0, "xc_evtchn_pending returned %d (expected 
%d)\n",
+   xen_be_printf(xendev, 0, "xenevtchn_pending returned %d (expected 
%d)\n",
  port, xendev->local_port);
return;
 }
-xc_evtchn_unmask(xendev->evtchndev, port);
+xenevtchn_unmask(xendev->evtchndev, port);
 
 if (xendev->ops->event)
xendev->ops->event(xendev);
@@ -683,14 +683,14 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 {
 if (xendev->local_port != -1)
return 0;
-xendev->local_port = xc_evtchn_bind_interdomain
+xendev->local_port = xenevtchn_bind_interdomain
(xendev->evtchndev, xendev->dom, xendev->remote_port);
 if (xendev->local_port == -1) {
-   xen_be_printf(xendev, 0, "xc_evtchn_bind_interdomain failed\n");
+   xen_be_printf(xendev, 0, "xenevtchn_bind_interdomain failed\n");
return -1;
 }
 xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev),
xen_be_evtchn_event, NULL, xendev);
 return 0;
 }
@@ -699,15 +699,15 @@ void xen_be_unbind_evtchn(struct XenDevice *xendev)
 {
 if (xendev->local_port == -1)
return;
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
-xc_evtchn_unbind(xendev->evtchndev, xendev->local_port);
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
+xenevtchn_unbind(xendev->evtchndev, xendev->local_port);
 xen_be_printf(xendev, 2, "unbind evtchn port %d\n", xendev->local_port);
 xendev->local_port = -1;
 }
 
 int xen_be_send_notify(struct XenDevice *xendev)
 {
-return xc_evtchn_notify(xendev->evtchndev, xendev->local_port);
+return xenevtchn_notify(xendev->evtchndev, xendev->local_port);
 }
 
 /*
diff --git a/hw/xen_backend.h b/hw/xen_backend.h
index e421391..60f18f8 100644
--- a/hw/xen_backend.h
+++ b/hw/xen_backend.h
@@ -44,7 +44,7 @@ struct XenDevice {
 intremote_port;
 intlocal_port;
 
-xc_evtchn  *evtchndev;
+xenevtchn_handle   *evtchndev;
 xc_gnttab  *gnttabdev;
 
 struct XenDevOps   *ops;
diff --git a/hw/xen_common.h b/hw/xen_common.h
index a615052..cee908f 100644
--- a/hw/xen_common.h
+++ b/hw/xen_common.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
diff --git a/i386-dm/helper2.c b/i386-dm/helper2.c
index ede3105..2706f2e 100644
--- a/i386-dm/helper2.c
+++ b/i386-dm/helper2.c
@@ -48,6 +48,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -104,7 +105,7 @@ buffered_iopage_t *buffered_io_page = 

[Xen-devel] [PATCH QEMU-XEN v8 4/8] xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages

[Ian Campbell]

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_{pages,bulk}.

In preparation for this switch all uses of xc_map_foreign_range to
xc_map_foreign_pages. This is trivial because size was always
XC_PAGE_SIZE so the necessary adjustments are trivial:

  * Pass  (an array of length 1) instead of mfn. The function
takes a pointer to const, so there is no possibily of mfn changing
due to this change.
  * Pass nr_pages=1 instead of size=XC_PAGE_SIZE

There is one wrinkle in xen_console.c:con_initialise() where
con->ring_ref is an int but can in some code paths (when !xendev->dev)
be treated as an mfn. I think this is an existing latent truncation
hazard on platforms where xen_pfn_t is 64-bit and int is 32-bit (e.g.
amd64, both arm* variants). I'm unsure under what circumstances
xendev->dev can be NULL or if anything elsewhere ensures the value
fits into an int. For now I just use a temporary xen_pfn_t to in
effect upcast the pointer from int* to xen_pfn_t*.

In xenfb.c:common_bind we now explicitly launder the mfn into a
xen_pfn_t, so it has the correct type to be passed to
xc_map_foreign_pages and doesn't provoke warnings on 32-bit x86.

Signed-off-by: Ian Campbell 
Reviewed-by: Stefano Stabellini 
---
v7: Correct type mismatch (int64 vs xen_pfn_t) on 32 bit x86 in
xenfb.c, by explicitly laundering via a xen_pfn_t variable.

v6: Switch to xc_map_foreign_pages rather than _bulk. Switching to
_bulk without checking the value of err[0] risked missing errors.
The new xenforeignmemory_map coming later in this series will
DTRT with err==NULL.

Dropped Stefano's Reviewed-by due to this change.

v4: Ran checkpatch, fixed all errors
Mention the const-ness of the mfn array in the commit log

fixup!xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages
---
 hw/char/xen_console.c |  8 
 hw/display/xenfb.c| 15 ---
 xen-hvm.c | 14 +++---
 3 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index ac1b324..3e8a57b 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -228,10 +228,10 @@ static int con_initialise(struct XenDevice *xendev)
con->buffer.max_capacity = limit;
 
 if (!xendev->dev) {
-con->sring = xc_map_foreign_range(xen_xc, con->xendev.dom,
-  XC_PAGE_SIZE,
-  PROT_READ|PROT_WRITE,
-  con->ring_ref);
+xen_pfn_t mfn = con->ring_ref;
+con->sring = xc_map_foreign_pages(xen_xc, con->xendev.dom,
+ PROT_READ|PROT_WRITE,
+ , 1);
 } else {
 con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
  con->ring_ref,
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 4e2a27a..bb8f6b3 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -95,23 +95,24 @@ struct XenFB {
 
 static int common_bind(struct common *c)
 {
-uint64_t mfn;
+uint64_t val;
+xen_pfn_t mfn;
 
-if (xenstore_read_fe_uint64(>xendev, "page-ref", ) == -1)
+if (xenstore_read_fe_uint64(>xendev, "page-ref", ) == -1)
return -1;
-assert(mfn == (xen_pfn_t)mfn);
+mfn = (xen_pfn_t)val;
+assert(val == mfn);
 
 if (xenstore_read_fe_int(>xendev, "event-channel", 
>xendev.remote_port) == -1)
return -1;
 
-c->page = xc_map_foreign_range(xen_xc, c->xendev.dom,
-  XC_PAGE_SIZE,
-  PROT_READ | PROT_WRITE, mfn);
+c->page = xc_map_foreign_pages(xen_xc, c->xendev.dom,
+   PROT_READ | PROT_WRITE, , 1);
 if (c->page == NULL)
return -1;
 
 xen_be_bind_evtchn(>xendev);
-xen_be_printf(>xendev, 1, "ring mfn %"PRIx64", remote-port %d, 
local-port %d\n",
+xen_be_printf(>xendev, 1, "ring mfn %"PRI_xen_pfn", remote-port %d, 
local-port %d\n",
  mfn, c->xendev.remote_port, c->xendev.local_port);
 
 return 0;
diff --git a/xen-hvm.c b/xen-hvm.c
index 6227e17..1f729f6 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1247,8 +1247,9 @@ int xen_hvm_init(PCMachineState *pcms,
 DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
 DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
 
-state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
-  PROT_READ|PROT_WRITE, ioreq_pfn);
+state->shared_page = xc_map_foreign_pages(xen_xc, xen_domid,

[Xen-devel] [PATCH MINI-OS v8 1/4] mini-os: Include libxenevtchn with libxc

[Ian Campbell]

libxenevtchn has just been split out from libxc. From mini-os's point
of view we don't care about the distinction, so keep things simple by
just including libxenevtchn if libxc is enabled.

Signed-off-by: Ian Campbell 
Acked-by: Samuel Thibault 
Acked-by: Wei Liu 
---
v2: Adjust for libs/$lib layout.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index daee46c..d1d8dc4 100644
--- a/Makefile
+++ b/Makefile
@@ -166,6 +166,7 @@ OBJS := $(filter-out $(OBJ_DIR)/lwip%.o $(LWO), $(OBJS))
 ifeq ($(libc),y)
 ifeq ($(CONFIG_XC),y)
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
-whole-archive -lxentoollog -no-whole-archive
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn 
-whole-archive -lxenevtchn -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 endif
 APP_LDLIBS += -lpci
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v8 7/8] xen: domainbuild: reopen libxenctrl interface after forking for domain watcher.

[Ian Campbell]

Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.

Reopen the handle after fork and therefore do away with xc_fd().

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
The fact that xc_fd hasn't been useful since at least Xen 4.1 makes me
question the utility of this domainbuild in QEMU. Perhaps we should
just nuke it?
---
 hw/xenpv/xen_domainbuild.c  |  9 ++---
 include/hw/xen/xen_common.h | 17 -
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/hw/xenpv/xen_domainbuild.c b/hw/xenpv/xen_domainbuild.c
index ac0e5ac..f9be029 100644
--- a/hw/xenpv/xen_domainbuild.c
+++ b/hw/xenpv/xen_domainbuild.c
@@ -174,12 +174,15 @@ static int xen_domain_watcher(void)
 for (i = 3; i < n; i++) {
 if (i == fd[0])
 continue;
-if (i == xc_fd(xen_xc)) {
-continue;
-}
 close(i);
 }
 
+/*
+ * Reopen xc interface, since the original is unsafe after fork
+ * and was closed above.
+ */
+xen_xc = xc_interface_open(0, 0, 0);
+
 /* ignore term signals */
 signal(SIGINT,  SIG_IGN);
 signal(SIGTERM, SIG_IGN);
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 19f1577..be7a915 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -116,12 +116,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
void *dombuild_logger,
 
 /* See below for xenforeignmemory_* APIs */
 
-static inline int xc_fd(int xen_xc)
-{
-return xen_xc;
-}
-
-
 static inline int xc_domain_populate_physmap_exact
 (XenXC xc_handle, uint32_t domid, unsigned long nr_extents,
  unsigned int extent_order, unsigned int mem_flags, xen_pfn_t 
*extent_start)
@@ -193,11 +187,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
void *dombuild_logger,
 
 /* See below for xenforeignmemory_* APIs */
 
-/* FIXME There is no way to have the xen fd */
-static inline int xc_fd(xc_interface *xen_xc)
-{
-return -1;
-}
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 471 */
 
 typedef xc_interface *XenXC;
@@ -214,12 +203,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
void *dombuild_logger,
 {
 return xc_interface_open(logger, dombuild_logger, open_flags);
 }
-
-/* FIXME There is now way to have the xen fd */
-static inline int xc_fd(xc_interface *xen_xc)
-{
-return -1;
-}
 #endif
 
 /* Xen before 4.2 */
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN v8 3/8] xen: Switch to libxengnttab interface for compat shims.

[Ian Campbell]

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxengnttab which provides access to grant
tables.

In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the gnttab shim will disappear
for versions of Xen which include libxengnttab.

To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.

Note that this patch does not add any support for actually using
libxengnttab, it just adjusts the existing shims.

Signed-off-by: Ian Campbell 
Reviewed-by: Stefano Stabellini 
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not size of the ptr)
Rebase onto "xen_console: correctly cleanup primary console on
teardown."

v5: Rebase over b4f72e31b924 "hw/net/xen_nic.c: Free 'netdev->txs'
when map 'netdev->rxs' fails" which added a new gnttab_munmap.

v7: s/gnttab_munmap/gnttab_unmap/ to reflect change in the library.
---
 hw/block/xen_disk.c  | 38 --
 hw/char/xen_console.c|  4 ++--
 hw/net/xen_nic.c | 18 +-
 hw/xen/xen_backend.c | 10 +-
 include/hw/xen/xen_backend.h |  2 +-
 include/hw/xen/xen_common.h  | 42 --
 6 files changed, 69 insertions(+), 45 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index a48e726..326c948 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -171,11 +171,11 @@ static gint int_cmp(gconstpointer a, gconstpointer b, 
gpointer user_data)
 static void destroy_grant(gpointer pgnt)
 {
 PersistentGrant *grant = pgnt;
-XenGnttab gnt = grant->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
 
-if (xc_gnttab_munmap(gnt, grant->page, 1) != 0) {
+if (xengnttab_unmap(gnt, grant->page, 1) != 0) {
 xen_be_printf(>blkdev->xendev, 0,
-  "xc_gnttab_munmap failed: %s\n",
+  "xengnttab_unmap failed: %s\n",
   strerror(errno));
 }
 grant->blkdev->persistent_gnt_count--;
@@ -188,11 +188,11 @@ static void remove_persistent_region(gpointer data, 
gpointer dev)
 {
 PersistentRegion *region = data;
 struct XenBlkDev *blkdev = dev;
-XenGnttab gnt = blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
 
-if (xc_gnttab_munmap(gnt, region->addr, region->num) != 0) {
+if (xengnttab_unmap(gnt, region->addr, region->num) != 0) {
 xen_be_printf(>xendev, 0,
-  "xc_gnttab_munmap region %p failed: %s\n",
+  "xengnttab_unmap region %p failed: %s\n",
   region->addr, strerror(errno));
 }
 xen_be_printf(>xendev, 3,
@@ -327,7 +327,7 @@ err:
 
 static void ioreq_unmap(struct ioreq *ioreq)
 {
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
 int i;
 
 if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
@@ -337,8 +337,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->pages) {
 return;
 }
-if (xc_gnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
-xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap failed: 
%s\n",
+if (xengnttab_unmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
+xen_be_printf(>blkdev->xendev, 0,
+  "xengnttab_unmap failed: %s\n",
   strerror(errno));
 }
 ioreq->blkdev->cnt_map -= ioreq->num_unmap;
@@ -348,8 +349,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->page[i]) {
 continue;
 }
-if (xc_gnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
-xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap 
failed: %s\n",
+if (xengnttab_unmap(gnt, ioreq->page[i], 1) != 0) {
+xen_be_printf(>blkdev->xendev, 0,
+  "xengnttab_unmap failed: %s\n",
   strerror(errno));
 }
 ioreq->blkdev->cnt_map--;
@@ -361,7 +363,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 
 static int ioreq_map(struct ioreq *ioreq)
 {
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
 uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
@@ -412,7 +414,7 @@ 

[Xen-devel] [PATCH QEMU-XEN v8 1/8] xen_console: correctly cleanup primary console on teardown.

[Ian Campbell]

All of the work in con_disconnect applies to the primary console case
(when xendev->dev is NULL). Therefore remove the early check and bail
and allow it to fall through. All of the existing code is correctly
conditional already.

The ->dev and ->gnttabdev handles are either both set or neither. For
consistency with con_initialise() with to the former here too.

With this con_initialise and con_disconnect now mirror each other.

Fix up a hard tab in the function while editing.

Signed-off-by: Ian Campbell 
Reviewed-by: Stefano Stabellini 

---
v4: New patch based on feedback to "xen: Switch uses of
xc_map_foreign_bulk to use libxenforeignmemory API."
---
 hw/char/xen_console.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index eb7f450..63ade33 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -265,9 +265,6 @@ static void con_disconnect(struct XenDevice *xendev)
 {
 struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
 
-if (!xendev->dev) {
-return;
-}
 if (con->chr) {
 qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
 qemu_chr_fe_release(con->chr);
@@ -275,12 +272,12 @@ static void con_disconnect(struct XenDevice *xendev)
 xen_be_unbind_evtchn(>xendev);
 
 if (con->sring) {
-if (!xendev->gnttabdev) {
+if (!xendev->dev) {
 munmap(con->sring, XC_PAGE_SIZE);
 } else {
 xc_gnttab_munmap(xendev->gnttabdev, con->sring, 1);
 }
-   con->sring = NULL;
+con->sring = NULL;
 }
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH QEMU-XEN-TRADITIONAL v8 0/4] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell]

We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.

This is the qemu-xen-traditional part of the first phase of that change.

This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.

Ian Campbell (4):
  qemu-xen-traditional: Use libxenevtchn
  qemu-xen-traditional: Use libxengnttab
  qemu-xen-traditional: Add libxencall to rpath-link
  qemu-xen-traditional: Add libxenforeignmemory to rpath-link

 hw/xen_backend.c  | 30 +++---
 hw/xen_backend.h  |  4 ++--
 hw/xen_common.h   |  2 ++
 hw/xen_console.c  |  4 ++--
 hw/xen_disk.c | 24 
 i386-dm/helper2.c | 19 ++-
 xen-hooks.mak |  7 +++
 7 files changed, 50 insertions(+), 40 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH MINI-OS v8 2/4] mini-os: Include libxengnttab with libxc

[Ian Campbell]

libxengnttab has just been split out from libxc. From mini-os's point
of view we don't care about the distinction, so keep things simple by
just including libxengnttab if libxc is enabled.

Signed-off-by: Ian Campbell 
Acked-by: Samuel Thibault 
Acked-by: Wei Liu 
---
v2: Adjust for libs/$lib layout.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index d1d8dc4..521f647 100644
--- a/Makefile
+++ b/Makefile
@@ -167,6 +167,7 @@ ifeq ($(libc),y)
 ifeq ($(CONFIG_XC),y)
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
-whole-archive -lxentoollog -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn 
-whole-archive -lxenevtchn -no-whole-archive
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab 
-whole-archive -lxengnttab -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 endif
 APP_LDLIBS += -lpci
-- 
2.1.4


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

[Xen-devel] [PATCH MINI-OS v8 3/4] mini-os: Include libxencall with libxc

[Ian Campbell]

libxencall has just been split out from libxc. From mini-os's point
of view we don't care about the distinction, so keep things simple by
just including libxencall if libxc is enabled.

Signed-off-by: Ian Campbell 
Acked-by: Samuel Thibault 
Acked-by: Wei Liu 
---
v2: Adjust for libs/$lib layout.
---
 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index 521f647..c900540 100644
--- a/Makefile
+++ b/Makefile
@@ -168,6 +168,7 @@ ifeq ($(CONFIG_XC),y)
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/toollog 
-whole-archive -lxentoollog -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/evtchn 
-whole-archive -lxenevtchn -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/gnttab 
-whole-archive -lxengnttab -no-whole-archive
+APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libs-$(MINIOS_TARGET_ARCH)/call 
-whole-archive -lxencall -no-whole-archive
 APP_LDLIBS += -L$(XEN_ROOT)/stubdom/libxc-$(MINIOS_TARGET_ARCH) -whole-archive 
-lxenguest -lxenctrl -no-whole-archive
 endif
 APP_LDLIBS += -lpci
-- 
2.1.4


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

[Xen-devel] [seabios baseline-only test] 38639: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38639 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38639/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 38631
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38631

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 seabios  3e8d75f3bef0f36a807303d58523ef5eba4a386f
baseline version:
 seabios  44250252eeaefd5e81bae2f73639bd323682217b

Last test of basis38631  2016-01-13 07:57:35 Z2 days
Testing same since38639  2016-01-15 01:55:58 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   fail
 test-amd64-i386-xl-qemuu-winxpsp3pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit 3e8d75f3bef0f36a807303d58523ef5eba4a386f
Author: Kevin O'Connor 
Date:   Tue Jan 12 13:36:50 2016 -0500

coreboot: Check for unaligned cbfs header

If the CBFS header is invalid and points to 0x it could cause
SeaBIOS to read past the 4GB boundary and cause an exception.  Check
the alignment of the header pointer before attempting to access fields
within the header.

Reported-by: "Alex G." 
Signed-off-by: Kevin O'Connor 

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

[Xen-devel] [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163

[Håkon Alstadheim]

This is just a preliminary report, mostly just for the record.

I will report again if this keeps happening after 4.7 is out, or upon 
request. Anyone working on this, please mail me and request more 
information. I have available logs from dom0 boot (I dump dmesg and xl 
dmesg to disk after every boot, and log dom0 serial console to disk). I 
will send boot logs if requested. I will turn on maximum verbosity and 
provide all output. My serial console is very slow, so I can not keep 
running at max verbosity all the time.


At the end of this mail there is "xl info" and output from dom0 serial 
console.


CPUINFO:
vendor_id: GenuineIntel
cpu family: 6
model: 63
model name: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

# smbios-sys-info
Libsmbios version:  2.2.28
Product Name:   Z10PE-D8 WS
Vendor: ASUSTeK COMPUTER INC.
BIOS Version:   3101

Dom0 OS:
Linux gentoo 4.1.12-gentoo #1 SMP Sat Jan 2 09:36:31 CET 2016 x86_64 
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz GenuineIntel GNU/Linux.
Kernel is gentoo-sources, with experimental use-flag. Cpu type set to 
Haswell. Issue also happened without experimental.

# cat /proc/cmdline
placeholder root=LABEL=ssdroot ro 
xen-pciback.hide=(02:00.*)(08:00.*)(00:1b.*)(81:00.*)(82:00.*)(83:00.*) 
console=hvc0 console=vga domodules domdadm dolvm intel_iommu=on 
earlyprintk=xen usbcore.autosuspend=-1


The system is mostly built with stable packages, xen and xen-tools 
keyworded to ~amd64.


I have been experiencing issues with domains with passed through PCIe 
devices since I first installed xen. Then at version 4.5.x , I'm now at 
4.6.0 with gentoo patches. Crashes SEEM mostly related to this pci pass 
through and interrupts (usb-cards, sound cards).


Recently the system has been more stable, whether it is because I pass 
through as few things as possible, or because of improvements in Xen I 
do not know. I have also taken to building with debug, which leads to 
more abrupt but less mysterious failures. Earlier (w/o debug and under 
xen 4.5 ) stuff would just gradually stop working and end up in total 
hang of everything. So, hey, things are improving :-b


---xl info: 
host   : gentoo
release: 4.1.12-gentoo
version: #1 SMP Sat Jan 2 09:36:31 CET 2016
machine: x86_64
nr_cpus: 24
max_cpu_id : 23
nr_nodes   : 2
cores_per_socket   : 6
threads_per_core   : 2
cpu_mhz: 2394
hw_caps: 
bfebfbff:2c100800::7f00:77fefbff::0021:37ab

virt_caps  : hvm hvm_directio
total_memory   : 65379
free_memory: 20123
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 6
xen_extra  : .0
xen_version: 4.6.0
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64

xen_scheduler  : credit
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  :
xen_commandline: ssd-xen-marker console_timestamps=date 
loglvl=warn/warn guest_loglvl=warn/warn iommu=1 
iommu_inclusive_mapping=1 com1=115200,8n1 console=com1 dom0_max_vcpus=4 
dom0_vcpus_pin=1 dom0_mem=8G,max:8G cpufreq=xen:performance,verbose 
tmem=1 sched_smt_power_savings=1 e820-verbose=1 core_parking=power
cc_compiler: x86_64-pc-linux-gnu-gcc (Gentoo 4.9.3 p1.4, 
pie-0.6.4) 4.9.3

cc_compile_by  :
cc_compile_domain  : alstadheim.priv.no
cc_compile_date: Tue Jan 12 22:19:05 CET 2016
xend_config_format : 4
-
 serial console output from time dom0 finished booting until crash: 
(I have more of these) 

(XEN) [2016-01-13 08:46:25] tmem: flushing tmem pools for domid=4
(XEN) [2016-01-13 08:54:27] tmem: flushing tmem pools for domid=5
(XEN) [2016-01-13 09:01:53] tmem: flushing tmem pools for domid=6
(XEN) [2016-01-13 09:04:41] tmem: flushing tmem pools for domid=7
(XEN) [2016-01-13 09:19:46] tmem: flushing tmem pools for domid=8
(XEN) [2016-01-13 09:22:42] tmem: flushing tmem pools for domid=9
(XEN) [2016-01-13 09:40:37] tmem: flushing tmem pools for domid=10
(XEN) [2016-01-13 20:59:46] [VT-D] It's risky to assign :81:00.0 
with shared RMRR at 7db92000 for Dom12.

(XEN) [2016-01-13 22:21:06] tmem: flushing tmem pools for domid=3
(XEN) [2016-01-14 19:31:12] tmem: flushing tmem pools for domid=11
(XEN) [2016-01-15 07:02:56] Assertion '(sp == 0) || (peoi[sp-1].vector < 
vector)' failed at irq.c:1163
(XEN) [2016-01-15 07:02:56] [ Xen-4.6.0  x86_64  debug=y  Not 
tainted ]

(XEN) [2016-01-15 07:02:56] CPU:19
(XEN) [2016-01-15 07:02:56] RIP:e008:[] 
do_IRQ+0x3ca/0x63b

(XEN) [2016-01-15 07:02:56] RFLAGS: 00010046   CONTEXT: hypervisor
(XEN) [2016-01-15 07:02:56] 

Re: [Xen-devel] [PATCH] Config.mk: Update SEABIOS_UPSTREAM_TAG to 442502

[Ian Campbell]

On Thu, 2016-01-14 at 17:56 +0100, Roger Pau Monné wrote:
> 
> > commit a661f70a8aad3fe7b2c828632714785a04b1d96b
> > Author: Ian Campbell 
> > Date:   Thu Jan 14 16:43:42 2016 +
> > 
> > SEABIOS_UPSTREAM_REVISION Update
> > 
> > Signed-off-by: Ian Campbell 
> 
> Acked-by: Roger Pau Monné 

Applied.

> 
> > diff --git a/Config.mk b/Config.mk
> > index 62f8209..d654af8 100644
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -255,9 +255,9 @@ MINIOS_UPSTREAM_REVISION ?=
> > d25773c8afa2f4dbbb466116daeb60159ddd22bd
> >  # Thu Dec 3 11:23:25 2015 +
> >  # mini-os: Include libxentoollog with libxc
> >  
> > -SEABIOS_UPSTREAM_REVISION ?= rel-1.9.0
> > -# Tue Nov 17 09:18:44 2015 -0500
> > -# docs: Note v1.9.0 release
> > +SEABIOS_UPSTREAM_REVISION ?= 3403ac4313812752be6e6aac35239ca6888a8cab
> > +# Mon Dec 28 13:50:41 2015 +0100
> > +# build: fix typo in buildversion.py
> >  
> >  ETHERBOOT_NICS ?= rtl8139 8086100e
> >  
> > 
> 

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

[Xen-devel] [PATCH v1 1/1] MAINTAINERS: Add xen/drivers/char/cadence-uart.c

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Add xen/drivers/char/cadence-uart.c to the ARM section.

Signed-off-by: Edgar E. Iglesias 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 09fe823..0e8af01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -133,6 +133,7 @@ S:  Supported
 L: xen-devel@lists.xen.org
 F: xen/arch/arm/
 F: xen/include/asm-arm/
+F: xen/drivers/char/cadence-uart.c
 F: xen/drivers/char/dt-uart.c
 F: xen/drivers/char/exynos4210-uart.c
 F: xen/drivers/char/omap-uart.c
-- 
1.9.1


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

Re: [Xen-devel] [PATCH 1/2] libxl: fix _SC_GETPW_R_SIZE_MAX usage

[Ian Campbell]

On Wed, 2016-01-13 at 10:08 +0100, Roger Pau Monné wrote:
> El 13/01/16 a les 4.19, Doug Goldstein ha escrit:
> > On 1/12/16 7:14 AM, Roger Pau Monne wrote:
> > > According to the FreeBSD sysconf man page [0] if the variable is
> > > associated
> > > with functionality that is not supported, -1 is returned and errno is
> > > not
> > > modified. Modify libxl__dm_runas_helper so it's able to correctly
> > > deal with this situation by setting the initial buffer value to 2048.
> > > 
> > > [0] https://www.freebsd.org/cgi/man.cgi?query=sysconf

http://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html (whi
ch IMHO is the more canonical documentation) describes a similar error
behaviour, although for a subtly different case (no limit for the given
variable).

> > > 
> > > Signed-off-by: Roger Pau Monné 
> > > ---
> > >  tools/libxl/libxl_dm.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > > index 0aaefd9..ec8fb51 100644
> > > --- a/tools/libxl/libxl_dm.c
> > > +++ b/tools/libxl/libxl_dm.c
> > > @@ -728,7 +728,14 @@ static int libxl__dm_runas_helper(libxl__gc *gc,
> > > const char *username)
> > >  long buf_size;
> > >  int ret;
> > >  
> > > +errno = 0;
> > >  buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
> > > +if (buf_size < 0 && errno == 0) {
> > > +buf_size = 2048;
> > > +LOG(DEBUG,
> > > +"sysconf(_SC_GETPW_R_SIZE_MAX) is not supported, using a buffer size of 
> > > %ld",

"... an initial buffer size of ..."

> > > +buf_size);
> > > +}
> > >  if (buf_size < 0) {
> > >  LOGE(ERROR, "sysconf(_SC_GETPW_R_SIZE_MAX) returned error
> > > %ld",
> > >  buf_size);
> > > 
> > 
> > So on Linux the behavior is somewhat similar [1]. But I took a peek at
> > the libvirt code for doing the similar thing and I notice that they
> > just
> > default if the value is returned as less than 0 [2]. Reading both man
> > pages it seems like that would be the better bet instead of failing how
> > the current code is. Your fix probably makes it fail less but it could
> > still error out senselessly. Just a suggestion for an improvement
> > overall.
> 
> Ack, it doesn't make much sense to error out if we cannot find an
> initial value for the buffer, the code below is able to adapt and expand
> the buffer as needed anyway. I'm going to resend with that fixed.

Sounds good.

Don't forget to CC all the tools maintainers next time.

Ian.

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

Re: [Xen-devel] [PATCH v1] xen/arm: Add r1p12 to the list of supported Cadence UARTs

[Jan Beulich]

>>> On 14.01.16 at 19:44,  wrote:
> --- a/xen/drivers/char/cadence-uart.c
> +++ b/xen/drivers/char/cadence-uart.c

Considering the wider than expected Cc list - is there an entry missing
from the ARM section in ./MAINTAINERS here?

Jan


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

[Xen-devel] [PATCHv1 net] xen-netfront: request Tx response events more often

[David Vrabel]

From: Malcolm Crossley 

Trying to batch Tx response events results in poor performance because
this delays freeing the transmitted skbs.

Instead use the standard RING_FINAL_CHECK_FOR_RESPONSES() macro to be
notified once the next Tx response is placed on the ring.

Signed-off-by: Malcolm Crossley 
Signed-off-by: David Vrabel 
---
 drivers/net/xen-netfront.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d6abf19..9cb45be 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -364,6 +364,7 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue)
RING_IDX cons, prod;
unsigned short id;
struct sk_buff *skb;
+   int more_to_do;
 
BUG_ON(!netif_carrier_ok(queue->info->netdev));
 
@@ -398,18 +399,8 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue)
 
queue->tx.rsp_cons = prod;
 
-   /*
-* Set a new event, then check for race with update of tx_cons.
-* Note that it is essential to schedule a callback, no matter
-* how few buffers are pending. Even if there is space in the
-* transmit ring, higher layers may be blocked because too much
-* data is outstanding: in such cases notification from Xen is
-* likely to be the only kick that we'll get.
-*/
-   queue->tx.sring->rsp_event =
-   prod + ((queue->tx.sring->req_prod - prod) >> 1) + 1;
-   mb();   /* update shared area */
-   } while ((cons == prod) && (prod != queue->tx.sring->rsp_prod));
+   RING_FINAL_CHECK_FOR_RESPONSES(>tx, more_to_do);
+   } while (more_to_do);
 
xennet_maybe_wake_tx(queue);
 }
-- 
2.1.4


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

Re: [Xen-devel] [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163

[Håkon Alstadheim]

On 01/15/2016 02:09 PM, Ian Campbell wrote:

On Fri, 2016-01-15 at 13:49 +0100, Håkon Alstadheim wrote:

On 01/15/2016 01:42 PM, Jan Beulich wrote:

On 15.01.16 at 13:32,  wrote:

placed microcode.bin in /boot/microcode.bin

booted with :
---
xen_commandline: ssd-xen-debug-marker console_timestamps=date
loglvl=all guest_loglvl=all sync_console iommu=1,verbose,debug
iommu_inclusive_mapping=1 com1=115200,8n1 console=com1
dom0_max_vcpus=4
dom0_vcpus_pin=1 dom0_mem=8G,max:8G cpufreq=xen:performance,verbose
tmem=1 sched_smt_power_savings=1 apic_verbosity=debug e820-verbose=1
core_parking=power ucode=microcode.bin
---

This can't work - did you look at the command line documentation?
You can't specify a file name here - there's no file system driver
inside the hypervisor, and hence it can't read files (it instead has
to rely on the boot loader bringing those into memory for it).

Get with the times :-) . Under EFI it most definitely wants a file-name.
Not entirely sure about the file FORMAT though.

  From xen-command-line.html
   "Note further that use of this option has an unspecified effect when
used with xen.efi (there the concept of modules doesn't exist, and the
blob gets specified via the ucode= config file/section entry;
see EFI configuration file description).

  From efi.html

   "ucode=

  Specifies a CPU microcode blob to load. (x86 only)

This needs to go in your xen.cfg file (alongside kernel= ramdisk= etc), not
on the xen command line.

Ian.



Ahh (face + palm) .  It dawned on me right after I sent my previous. Now 
I DO get some acknowledgement of microcode.bin in the console-log, but 
/proc/cpuinfo still reports microcode: 0x31, so it seems stale 
microcode is not the issue :-/




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

Re: [Xen-devel] [PATCH v4 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue.

[Jan Beulich]

>>> On 23.12.15 at 09:25,  wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -190,9 +190,19 @@ static int queue_invalidate_wait(struct iommu *iommu,
>  static int invalidate_sync(struct iommu *iommu)
>  {
>  struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
> +int rc;
>  
>  if ( qi_ctrl->qinval_maddr )
> -return queue_invalidate_wait(iommu, 0, 1, 1);
> +{
> +rc = queue_invalidate_wait(iommu, 0, 1, 1);
> +if ( rc )
> +{
> +if ( rc == -ETIMEDOUT )
> +panic("Queue invalidate wait descriptor was timeout.\n");

Unless I'm overlooking something this doesn't replace and existing
panic(), and I think I had indicated quite clearly that this series
shouldn't add any new ones, unless the alternative of crashing
the owning domain is completely unfeasible.

> +panic("Queue invalidate wait descriptor was timeout.\n");
> +return rc;
> +}
> +}
> +
>  return 0;
>  }

Please avoid introducing multiple return points when this can be
trivially avoided.

> @@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
>  return 0;
>  }
>  
> +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
> + u16 seg, u8 bus, u8 devfn)
> +{
> +struct domain *d;
> +struct pci_dev *pdev;
> +
> +d = rcu_lock_domain_by_id(iommu->domid_map[did]);
> +ASSERT(d);

Don't you need to acquire some lock in order to safely assert this?
Also note that unused slots hold zero, i.e. there's at least a
theoretical risk of problems here when you don't also look at
iommu->domid_bitmap.

> +for_each_pdev(d, pdev)
> +{
> +if ( (pdev->seg == seg) &&
> + (pdev->bus == bus) &&
> + (pdev->devfn == devfn) )
> +{
> +if ( pdev->domain )

If the device is on the domain's list, can this reasonably be false?
I.e. don't you rather mean ASSERT() here?

> +{
> +list_del(>domain_list);

This should happen under pcidevs_lock - you need to either acquire
it or ASSERT() it being held.

> +pdev->domain = NULL;
> +}
> +
> +if ( pci_hide_device(bus, devfn) )
> +{
> +printk(XENLOG_ERR
> +   "IOMMU hide device %04x:%02x:%02x error.",
> +   seg, bus, devfn);
> +break;
> +}
> +
> +break;
> +}

Redundant breaks.

> +}
> +
> +if ( !is_hardware_domain(d) )
> +domain_crash(d);

I wonder whether the device hiding shouldn't also be avoided if
the device is owned by hwdom.

> @@ -349,9 +416,18 @@ static int flush_iotlb_qi(
>  queue_invalidate_iotlb(iommu,
> type >> DMA_TLB_FLUSH_GRANU_OFFSET, dr,
> dw, did, size_order, 0, addr);
> +
> +/*
> + * Synchronize with hardware for invalidation request descriptors
> + * submitted before Device-TLB invalidate descriptor.
> + */
> +rc = invalidate_sync(iommu);
> +if ( rc )
> + return rc;
> +
>  if ( flush_dev_iotlb )
>  ret = dev_invalidate_iotlb(iommu, did, addr, size_order, type);
> -rc = invalidate_sync(iommu);
> +
>  if ( !ret )
>  ret = rc;
>  }

This change is because of ...?

> --- a/xen/drivers/passthrough/vtd/x86/ats.c
> +++ b/xen/drivers/passthrough/vtd/x86/ats.c
> @@ -162,6 +162,19 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
>  return -EOPNOTSUPP;
>  }
>  
> +/*
> + * Synchronize with hardware for Device-TLB invalidate
> + * descriptor.
> + */
> +ret = dev_invalidate_iotlb_sync(iommu, did, pdev->seg,
> +pdev->bus, pdev->devfn);
> +if ( ret )
> +{
> +dprintk(XENLOG_WARNING VTDPREFIX,
> +"Device-TLB flush timeout.\n");

Are you aware that dprintk() compiles to nothing in non-debug builds?
Plus logging the error code and device coordinates might turn out
helpful in such cases. But first of all - if there was a timeout, we'd
make it here only for Dom0. Perhaps the printing should move into
an else to the domain_crash()? And if there was another error, the
message would be outright wrong.

Jan

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

[Xen-devel] [PATCH OSSTEST] ts-debian-install: increase time allowed for xen-create-image

[Ian Campbell]

This step is consistently timing out when run on cubietruck-*. Judging
from the logs it appears to be completing during the 30s slack added
by tcmdex (i.e. after the timeout message the rest of the output
appears in the test step log).

Looking at the results on arndale-* (which looks to pass reasonably
reliably) I see that the regular test-armhf-armhf-xl job takes around
550s to do the xen-create-image while test-armhf-armhf-xl-rtds
typically takes around 1100s (twice as long).

On cubietruck-braque test-armhf-armhf-xl uses 900s. One could
therefore extrapolate that test-armhf-armhf-xl-rtds might need more
than 1800s and not be too surprised that it appears to need something
a bit more than 2000s in practice. 2500s seems like sufficient
headroom.

For comparisson with arm on x86 godello takes around 210s in the
normal case and 680s with RTDS (>3x slower) while nocera takes 265s
and 640s (2.4x). (Those are from nearby but not identical flights in
order to match up the host).

Signed-off-by: Ian Campbell 
---
Cc: Dario Faggioli 
Cc: Meng Xu 

Dario, Meng, I suppose a 2-3x slow down with RTDS on a dom0 operation
(with no domains running) such as xen-create-image is not unexpected?
---
 ts-debian-install | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-debian-install b/ts-debian-install
index f42edbf..2a7331d 100755
--- a/ts-debian-install
+++ b/ts-debian-install
@@ -95,7 +95,7 @@ END
 $initrd_opt \\
 $archarg
 END
-target_cmd_root($ho, $cmd, 2000);
+target_cmd_root($ho, $cmd, 2500);
 
 my $cfg= "/etc/xen/$gho->{Name}.cfg";
 store_runvar("$gho->{Guest}_cfgpath", $cfg);
-- 
2.6.1


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

Re: [Xen-devel] [PATCH v1] xen/arm: Add r1p12 to the list of supported Cadence UARTs

[Ian Campbell]

On Fri, 2016-01-15 at 14:30 +0100, Edgar E. Iglesias wrote:
> On Fri, Jan 15, 2016 at 12:30:27PM +, Ian Campbell wrote:
> > On Thu, 2016-01-14 at 19:44 +0100, Edgar E. Iglesias wrote:
> > > From: "Edgar E. Iglesias" 
> > 
> > Where are the bindings for cdns,uart-r1p12 defined? I don't see it
> > mentioned in the Documentation/devicetree/bindings/serial/cdns,uart.txt
> > in
> > mainline Linux.
> 
> Hi Ian,
> 
> The bindings are currently in our queue:
> https://github.com/Xilinx/linux-
> xlnx/blob/master/Documentation/devicetree/bindings/serial/cdns%2Cuart.txt

Great, thanks.
> 
> > Does the driver need to differ at all compared with what is needed for
> > r1p8? Normally if there is no (practical/visible) difference then in
> > DT-
> > world there is no need for a new compatible string, since the device is
> > still compatible.
> > 
> > If there are differences in the h/w but they are not relevant to our
> > particular driven then please say so in the commit log.
> 
> Right, there are SW visible differences (the Linux driver uses them) but
> none affecting XEN. I'll note that in the commit message.

If you want to just supply some words here I'll fold them in upon commit.
Or feel free to send a v2 if you prefer.

Ian.

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

[Xen-devel] [PATCHv2 3/3] xen-netback: free queues after freeing the net device

[David Vrabel]

If a queue still has a NAPI instance added to the net device, freeing
the queues early results in a use-after-free.

The shouldn't ever happen because we disconnect and tear down all queues
before freeing the net device, but doing this makes it obviously safe.

Signed-off-by: David Vrabel 
---
 drivers/net/xen-netback/interface.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 3bba6ce..f5231a2 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -685,22 +685,16 @@ void xenvif_deinit_queue(struct xenvif_queue *queue)
 
 void xenvif_free(struct xenvif *vif)
 {
-   struct xenvif_queue *queue = NULL;
+   struct xenvif_queue *queues = vif->queues;
unsigned int num_queues = vif->num_queues;
unsigned int queue_index;
 
unregister_netdev(vif->dev);
-
-   for (queue_index = 0; queue_index < num_queues; ++queue_index) {
-   queue = >queues[queue_index];
-   xenvif_deinit_queue(queue);
-   }
-
-   vfree(vif->queues);
-   vif->queues = NULL;
-   vif->num_queues = 0;
-
free_netdev(vif->dev);
 
+   for (queue_index = 0; queue_index < num_queues; ++queue_index)
+   xenvif_deinit_queue([queue_index]);
+   vfree(queues);
+
module_put(THIS_MODULE);
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 0/3] tools: remove 1024 domain limit at some places

[Juergen Gross]

On 04/01/16 15:55, Juergen Gross wrote:
> There are some places in Xen tools which will work for only up to
> 1024 domains. Remove this limit.
> 
> Changes in V2:
> - corrected a little error in patch 1 at end of loop (index -1 used
>   in array)
> - added patches 2 and 3
> 
> Juergen Gross (3):
>   libxl: remove the xl list limit of 1024 domains
>   libxl: base libxl_list_vm() on libxl_list_domain()
>   xenstat: handle more than 1024 domains
> 
>  tools/libxl/libxl.c| 46 ++--
>  tools/xenstat/libxenstat/src/xenstat_qmp.c | 67 
> +-
>  2 files changed, 51 insertions(+), 62 deletions(-)
> 

All patches have Reviewed-by tags since 11 days now. Any reason not to
take them?


Juergen

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

[Xen-devel] [PATCH v2] xen/arm64: correctly emulate the {w, x}zr registers

[Ian Campbell]

From: Julien Grall 

On AArch64, encoding 31 for an R in the HSR is used to represent
either {w,x}sp or {w,x}zr (See C1.2.4 in ARM DDI 0486A.d) depending on
how the register field is interpreted by the instruction.

All the instructions trapped by Xen (either via a sysreg access or
data abort) interpret encoding 31 as {w,x}zr. Therefore we don't have
to worry about the possibility that a trap could refer to sp or about
decoding the instruction.

For example AArch64 LDR and STR can have zr in the source/target
register , but never sp. sp can be present in the destination
pointer( i.e.  "[sp]"), but that would be represented by the value of
FAR_EL2, not in the HSR.

For AArch32 it is possible for a LDR to target the PC, but this would
not result in a valid ISS in the HSR register. However this could only
occur if loading or storing the PC to MMIO, which we simply choose not
to support for now.

Finally, features such as xenaccess can lead to us trapping on
arbitrary instructions accessing RAM and not just for MMIO. However in
many such cases HSR.ISS is not valid and in general features such as
xenaccess do not rely on the nature of the specific instruction, they
resolve the fault (via information found elsewhere e.g. FAR_EL2)
without needing to know anything about the instruction which triggered
the trap.

The register zr represents the zero register, i.e it will always
return 0 and write to it is ignored. To properly handle this property,
2 new helpers have been introduced {get,set}_user_reg to read/write a
value from/to a register. All the calls to select_user_reg have been
replaced by these 2 helpers.

Furthermore, the code to emulate encoding 31 in select_user_reg has been
dropped because it was invalid. For Aarch64 context, the encoding is
used for sp or zr. For AArch32 context, the ISS won't be valid for data
abort from AArch32 using r15 (i.e pc) as source/destination (See D7-1881
ARM DDI 0487A.d, note the validity is more restrictive than on ARMv7).
It's also not possible to use r15 in co-processor instructions.

This patch fixes setting MMIO register and sysreg to a random value
(actually PC) instead of zero by something like:

*((volatile int*)reg) = 0;

compilers tend to generate "str wzr, [xx]" here.

Reported-by: Marc Zyngier 
Signed-off-by: Julien Grall 

Added BUG_ON to select_user_reg for {w,x}zr case.

Clarified bits of the commit message by attempting to enumerate some
of the cases which might be a concern in order to show why they are
not.

Signed-off-by: Ian Campbell 
---
v2: ijc: Took over the series, changes above.
---
 xen/arch/arm/io.c  |  34 +
 xen/arch/arm/traps.c   | 122 +
 xen/arch/arm/vgic-v3.c |   3 +-
 xen/arch/arm/vtimer.c  |  59 +-
 xen/include/asm-arm/regs.h |   7 +--
 5 files changed, 154 insertions(+), 71 deletions(-)

diff --git a/xen/arch/arm/io.c b/xen/arch/arm/io.c
index 7e29943..0156755 100644
--- a/xen/arch/arm/io.c
+++ b/xen/arch/arm/io.c
@@ -24,12 +24,19 @@
 #include 
 
 static int handle_read(const struct mmio_handler *handler, struct vcpu *v,
-   mmio_info_t *info, register_t *r)
+   mmio_info_t *info)
 {
 const struct hsr_dabt dabt = info->dabt;
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+/*
+ * Initialize to zero to avoid leaking data if there is an
+ * implementation error in the emulation (such as not correctly
+ * setting r).
+ */
+register_t r = 0;
 uint8_t size = (1 << dabt.size) * 8;
 
-if ( !handler->ops->read(v, info, r, handler->priv) )
+if ( !handler->ops->read(v, info, , handler->priv) )
 return 0;
 
 /*
@@ -37,7 +44,7 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
  * Note that we expect the read handler to have zeroed the bits
  * outside the requested access size.
  */
-if ( dabt.sign && (*r & (1UL << (size - 1))) )
+if ( dabt.sign && (r & (1UL << (size - 1))) )
 {
 /*
  * We are relying on register_t using the same as
@@ -45,21 +52,30 @@ static int handle_read(const struct mmio_handler *handler, 
struct vcpu *v,
  * code smaller.
  */
 BUILD_BUG_ON(sizeof(register_t) != sizeof(unsigned long));
-*r |= (~0UL) << size;
+r |= (~0UL) << size;
 }
 
+set_user_reg(regs, dabt.reg, r);
+
 return 1;
 }
 
+static int handle_write(const struct mmio_handler *handler, struct vcpu *v,
+mmio_info_t *info)
+{
+const struct hsr_dabt dabt = info->dabt;
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+
+return handler->ops->write(v, info, get_user_reg(regs, dabt.reg),
+   handler->priv);
+}
+
 int handle_mmio(mmio_info_t *info)
 {
 struct vcpu *v = current;
 int i;
 const 

[Xen-devel] [PATCHv2 0/3 net] xen-netback: use skb to determine number of required (etc.)

[David Vrabel]

"xen-netback: use skb to determine number of required" plus two other
minor fixes I found down the back of the sofa.

David


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

[Xen-devel] [PATCHv2 1/3] xen-netback: use skb to determine number of required guest Rx requests

[David Vrabel]

Using the MTU or GSO size to determine the number of required guest Rx
requests for an skb was subtly broken since these value may change at
runtime.

After 1650d5455bd2dc6b5ee134bd6fc1a3236c266b5b (xen-netback: always
fully coalesce guest Rx packets) we always fully pack a packet into
its guest Rx slots.  Calculating the number of required slots from the
packet length is then easy.

Signed-off-by: David Vrabel 
---
 drivers/net/xen-netback/netback.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 1049c34..61b97c3 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -149,20 +149,19 @@ static inline pending_ring_idx_t pending_index(unsigned i)
return i & (MAX_PENDING_REQS-1);
 }
 
-static int xenvif_rx_ring_slots_needed(struct xenvif *vif)
-{
-   if (vif->gso_mask)
-   return DIV_ROUND_UP(vif->dev->gso_max_size, XEN_PAGE_SIZE) + 1;
-   else
-   return DIV_ROUND_UP(vif->dev->mtu, XEN_PAGE_SIZE);
-}
-
 static bool xenvif_rx_ring_slots_available(struct xenvif_queue *queue)
 {
RING_IDX prod, cons;
+   struct sk_buff *skb;
int needed;
 
-   needed = xenvif_rx_ring_slots_needed(queue->vif);
+   skb = skb_peek(>rx_queue);
+   if (!skb)
+   return false;
+
+   needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
+   if (skb_is_gso(skb))
+   needed++;
 
do {
prod = queue->rx.sring->req_prod;
@@ -2005,8 +2004,7 @@ static bool xenvif_rx_queue_ready(struct xenvif_queue 
*queue)
 
 static bool xenvif_have_rx_work(struct xenvif_queue *queue)
 {
-   return (!skb_queue_empty(>rx_queue)
-   && xenvif_rx_ring_slots_available(queue))
+   return xenvif_rx_ring_slots_available(queue)
|| (queue->vif->stall_timeout &&
(xenvif_rx_queue_stalled(queue)
 || xenvif_rx_queue_ready(queue)))
-- 
2.1.4


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

Re: [Xen-devel] [PATCH QEMU-XEN v8 0/8] Begin to disentangle libxenctrl and provide some stable libraries

[Ian Campbell]

On Fri, 2016-01-15 at 14:44 +, Stefano Stabellini wrote:
> What's the status of the libxc side changes? Is the interface stable
> enough for me to commit this series?

I'd recommend waiting. I'll ping you when it looks appropriate to apply
this series.

Thanks for the final acks on this sub-series!

Ian.

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

Re: [Xen-devel] [PATCH 2/2] libxl: fix UUID usage on FreeBSD

[Ian Campbell]

On Fri, 2016-01-15 at 16:11 +0100, Roger Pau Monné wrote:
> El 15/01/16 a les 11.26, Ian Campbell ha escrit:
> > On Tue, 2016-01-12 at 14:14 +0100, Roger Pau Monne wrote:
> > > libxl makes the assumtion that libxl_uuid == uuid_t,
> > 
> > ("assumption")
> > 
> > >  and that uuid_t can be
> > > freely used as a byte array. This is not true on FreeBSD (and NetBSD
> > > too, not sure about other BSD UUID implementations), where the
> > > internals
> > > of
> > > uuid don't match what libxl expects as a byte array because of
> > > endianness
> > > issues.
> > > 
> > > Fix this by converting the libxl_uuid type to a struct with an
> > > internal
> > > uuid_t field and a byte-array. Also introduce a new function that
> > > should
> > > be
> > > used in order to load a byte array into a uuid_t struct.
> > 
> > Do we really need to keep both the uuid_t and the byte-array
> > representation
> > around? It looks to me as if we only really need the byte-array form,
> > which
> > might then involve changing various uses of uuid_* internally to just
> > be
> > mem*.
> 
> Yes, we can remove the uuid_t from libxl_uuid, but this is AFAICT a
> structure that belongs to the stable API.

Oh b*m, so it is.

>  My current change keeps the
> same layout by turning the union into a struct, but without changing the
> fields.

The danger with your change is that the two halves can now get out of sync.

Neither xl nor libvirt actually poke into the contents of the struct at
all. So I wonder if we can get away with deprecating it?

Or can we get rid of uuid_raw (which is not touched, and is less likely to
be given that it is only on a subset of platforms) and have libxl
_internal_ stuff convert to a byte array.

The problem there I guess is that would involve changing the semantics of
libxl_uuid_bytearray{,_const} (since the result would now need to be freed,
since both returns a static buffer, so who knows what the const distinction
was supposed to be for!).

Hrm, we've certainly painted ourselves into a corner with this one :-/

If we do go with keeping both the uuid_t and the raw array then we should
clearly mark the uuid_t one as the canonical copy (the raw one essentially
becomes a scratch space used to facilitate the provision of the broken
libxl_uuid_bytearray* interfaces).

Ian.

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

Re: [Xen-devel] [PATCH v3] x86/p2m: use large pages for MMIO mappings

[Ian Campbell]

On Fri, 2016-01-15 at 03:47 -0700, Jan Beulich wrote:
> > > > On 15.01.16 at 11:09,  wrote:
> > On Thu, 2016-01-14 at 03:04 -0700, Jan Beulich wrote:
> > > - ARM side unimplemented (and hence libxc for now made cope with both
> > >   models),
> > 
> > So, one model is the one described in the commit message:
> > 
> > > - zero (success, everything done)
> > > - positive (success, this many done, more to do: re-invoke)
> > > - negative (error)
> > 
> > What is the other one? I'd expect ARM to already implement a subset of
> > this
> > (i.e. 0 or negative, perhaps with a subset of the possible errno
> > values), 
> > which I'd then expect libxc to just cope with without it constituting a
> > second model.
> 
> Well, first of all ARM doesn't get switched away from the current
> model (yet), i.e. returning -E2BIG out of do_domctl().

Which AFAICT is a valid behaviour under the new model described in the
commit message specifically the "negative (error)" case.

I think the core of my objection/confusion here is describing this as two
different models when what is being introduced is a single API which can
fail either partially or entirely, with that being at the discretion of the
internals. In any case libxc needs to cope with the complete gamut of
behaviours of the interface.

IOW rather than describing a new API and referring obliquely to ARM only
supporting an old model I think this needs a complete description of the
interface covering the full possibilities of the API.

>  And then
> the difference between what the patch implements and what the
> non-commit message comment describes is how errors get handled:
> The patch makes a negative error value returned upon error, with
> the caller having no way to tell at what point the error occurred
> (and with a best effort undo in the case of "map"). The described
> alternative would return the number of succeeded entries unless
> an error occurred on the very first MFN, without any attempt to
> undo the part that was done successfully. I.e. it would leave it
> to the caller to decide what to do, and whether/when to roll back.

That's (probably, I don't quite follow all the details as written) fine,
but the interface should be described as a single API with the possible
failure cases each spelled out, i.e. not described as a split/contrast
between old vs. new or x86 vs. arm behaviour. The fact that x86 and arm
might currently exhibit different subsets of the possibilities offered by
the API is of at best secondary interest.

Ian.

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

Re: [Xen-devel] [PATCH] QEMU as non-root and PCI passthrough do not mix

[Stefano Stabellini]

On Thu, 14 Jan 2016, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH] QEMU as non-root and PCI passthrough 
> do not mix"):
> > On Thu, 14 Jan 2016, Ian Campbell wrote:
> > > What if b_info->device_model_user is NULL or == "root"? Doesn't this warn
> > > even then?
> > 
> > I meant to warn even if device_model_user is NULL because it is the
> > default and I think it is fair to inform the user about this. But I
> > think you are right that we don't want to warn if device_model_user is
> > specified as "root".
> 
> Much of the logic here is upended by what is now my qemu privsep
> series.  Is it really worth fine-tuning the default handling here ?

Fair enough.

Do you prefer the PCI passthrough case to be fixed now or after your
series? In other words, do you prefer this patch to go in now, or after
your series?

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

Re: [Xen-devel] [Qemu-devel] [PATCH 2/2] xen-hvm: Clean up xen_ram_alloc() error handling

[Stefano Stabellini]

On Fri, 15 Jan 2016, Markus Armbruster wrote:
> Stefano Stabellini  writes:
> 
> > On Thu, 14 Jan 2016, Markus Armbruster wrote:
> >> xen_ram_alloc() dies with hw_error() on error, even though its caller
> >> ram_block_add() handles errors just fine.  Add an Error **errp
> >> parameter and use it.
> >> 
> >> Leave case RUN_STATE_INMIGRATE alone, because that looks like some
> >> kind of warning.
> 
> Did you double-check this is okay?

Yes, that's right: it is more of a debug message than a warning. Memory
is migrated by Xen, rather than by QEMU, so RUN_STATE_INMIGRATE we avoid
allocating any ram.


> >> Signed-off-by: Markus Armbruster 
> >
> > Reviewed-by: Stefano Stabellini 
> >
> > I am happy to queue both patches up in my next branch.
> 
> Please do, thanks!
> 

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

Re: [Xen-devel] [BUG] Assertion '(sp == 0) || (peoi[sp-1].vector < vector)' failed at irq.c:1163

[Håkon Alstadheim]

On 01/15/2016 01:49 PM, Håkon Alstadheim wrote:



On 01/15/2016 01:42 PM, Jan Beulich wrote:

On 15.01.16 at 13:32,  wrote:

placed microcode.bin in /boot/microcode.bin

   booted with :
---
xen_commandline: ssd-xen-debug-marker console_timestamps=date
loglvl=all guest_loglvl=all sync_console iommu=1,verbose,debug
iommu_inclusive_mapping=1 com1=115200,8n1 console=com1 dom0_max_vcpus=4
dom0_vcpus_pin=1 dom0_mem=8G,max:8G cpufreq=xen:performance,verbose
tmem=1 sched_smt_power_savings=1 apic_verbosity=debug e820-verbose=1
core_parking=power ucode=microcode.bin
---

This can't work - did you look at the command line documentation?
You can't specify a file name here - there's no file system driver
inside the hypervisor, and hence it can't read files (it instead has
to rely on the boot loader bringing those into memory for it).
Get with the times :-) . Under EFI it most definitely wants a 
file-name. Not entirely sure about the file FORMAT though.


From xen-command-line.html
 "Note further that use of this option has an unspecified effect when 
used with xen.efi (there the concept of modules doesn't exist, and the 
blob gets specified via the ucode= config file/section 
entry; see EFI configuration file description).


From efi.html

 "ucode=

Specifies a CPU microcode blob to load. (x86 only)



#cat /proc/cpuinfo | grep micro
says: microcode: 0x31

This is no change from previous boot.
Now: How do I know wheter 0x31 is the newest?

By checking - for the precise model and stepping of your CPU(s) -
the information in the blob (which admittedly is a little cumbersome,
but without knowing model and stepping I also can't try to help).

Jan


My fingers running faster than my head here. Managed to generate a blob 
that Xen accepts with command "iucode_tool microcode.dat -S -w 
microcode.bin"  (missed the -S before).

ucode=microcode.bin on a line by itself in the config.

Now the file actually loads, there is indeed an update, to 0x36 in my case.

If the error at irq.c:1163 keeps happening, I'll be sure to report 
again. :-~


Humbly, thanks Håkon. Sorry for all the noise.


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

Re: [Xen-devel] [PATCH v3] x86/p2m: use large pages for MMIO mappings

[Jan Beulich]

>>> On 15.01.16 at 14:57,  wrote:
> On Fri, 2016-01-15 at 03:47 -0700, Jan Beulich wrote:
>> > > > On 15.01.16 at 11:09,  wrote:
>> > On Thu, 2016-01-14 at 03:04 -0700, Jan Beulich wrote:
>> > > - ARM side unimplemented (and hence libxc for now made cope with both
>> > >   models),
>> > 
>> > So, one model is the one described in the commit message:
>> > 
>> > > - zero (success, everything done)
>> > > - positive (success, this many done, more to do: re-invoke)
>> > > - negative (error)
>> > 
>> > What is the other one? I'd expect ARM to already implement a subset of
>> > this
>> > (i.e. 0 or negative, perhaps with a subset of the possible errno
>> > values), 
>> > which I'd then expect libxc to just cope with without it constituting a
>> > second model.
>> 
>> Well, first of all ARM doesn't get switched away from the current
>> model (yet), i.e. returning -E2BIG out of do_domctl().
> 
> Which AFAICT is a valid behaviour under the new model described in the
> commit message specifically the "negative (error)" case.
> 
> I think the core of my objection/confusion here is describing this as two
> different models when what is being introduced is a single API which can
> fail either partially or entirely, with that being at the discretion of the
> internals. In any case libxc needs to cope with the complete gamut of
> behaviours of the interface.
> 
> IOW rather than describing a new API and referring obliquely to ARM only
> supporting an old model I think this needs a complete description of the
> interface covering the full possibilities of the API.
> 
>>  And then
>> the difference between what the patch implements and what the
>> non-commit message comment describes is how errors get handled:
>> The patch makes a negative error value returned upon error, with
>> the caller having no way to tell at what point the error occurred
>> (and with a best effort undo in the case of "map"). The described
>> alternative would return the number of succeeded entries unless
>> an error occurred on the very first MFN, without any attempt to
>> undo the part that was done successfully. I.e. it would leave it
>> to the caller to decide what to do, and whether/when to roll back.
> 
> That's (probably, I don't quite follow all the details as written) fine,
> but the interface should be described as a single API with the possible
> failure cases each spelled out, i.e. not described as a split/contrast
> between old vs. new or x86 vs. arm behaviour. The fact that x86 and arm
> might currently exhibit different subsets of the possibilities offered by
> the API is of at best secondary interest.

I don't think I agree - there are two models. The meaning of
-E2BIG for the caller to retry with a smaller amount doesn't exist in
the new model anymore, and hence libxc wouldn't need to deal
with that case anymore if the ARM side got updated too. Whereas
positive return values don't exist in the present (prior to the patch)
model.

Jan


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

Re: [Xen-devel] [PATCH v1] xen/arm: Add r1p12 to the list of supported Cadence UARTs

[Ian Campbell]

On Fri, 2016-01-15 at 15:36 +0100, Edgar E. Iglesias wrote:
> On Fri, Jan 15, 2016 at 01:46:05PM +, Ian Campbell wrote:
> > On Fri, 2016-01-15 at 14:30 +0100, Edgar E. Iglesias wrote:
> > > On Fri, Jan 15, 2016 at 12:30:27PM +, Ian Campbell wrote:
> > > > On Thu, 2016-01-14 at 19:44 +0100, Edgar E. Iglesias wrote:
> > > > > From: "Edgar E. Iglesias" 
> > > > 
> > > > Where are the bindings for cdns,uart-r1p12 defined? I don't see it
> > > > mentioned in the
> > > > Documentation/devicetree/bindings/serial/cdns,uart.txt
> > > > in
> > > > mainline Linux.
> > > 
> > > Hi Ian,
> > > 
> > > The bindings are currently in our queue:
> > > https://github.com/Xilinx/linux-
> > > xlnx/blob/master/Documentation/devicetree/bindings/serial/cdns%2Cuart
> > > .txt
> > 
> > Great, thanks.
> > >  
> > > > Does the driver need to differ at all compared with what is needed
> > > > for
> > > > r1p8? Normally if there is no (practical/visible) difference then
> > > > in
> > > > DT-
> > > > world there is no need for a new compatible string, since the
> > > > device is
> > > > still compatible.
> > > > 
> > > > If there are differences in the h/w but they are not relevant to
> > > > our
> > > > particular driven then please say so in the commit log.
> > > 
> > > Right, there are SW visible differences (the Linux driver uses them)
> > > but
> > > none affecting XEN. I'll note that in the commit message.
> > 
> > If you want to just supply some words here I'll fold them in upon
> > commit.
> > Or feel free to send a v2 if you prefer.
> 
> Thanks Ian, I've inlined something here.
> BTW, what is the policy for getting patches into -stable?

Please see http://wiki.xen.org/wiki/Xen_Maintenance_Releases and the
MAINTAIENRS file in the stable branches.

TL;DR: I think this is fine and I have added to my list of things to
backport.

> It would be great if this patch could be taken in to have
> XEN 4.6.x work out of the box on ZynqMPSoC with updated
> DTBs.
> 
> Best regards,
> Edgar
> 
> New commit message:
> xen/arm: Add r1p12 to the list of supported Cadence UARTs
> 
> Add r1p12 to the list of supported Cadence UARTs. XEN only
> uses the subset of features available in r1p8, so we don't
> need to differentiate between r1p8 and r1p12 yet.
> 
> Signed-off-by: Edgar E. Iglesias 

Acked-by: Ian Campbell 

It's spelled "Xen" or "xen", not "XEN"



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

[Xen-devel] [PATCH RFC] xen/Kconfig: Use olddefconfig not silentoldconfig to update .config

[Ian Campbell]

RFC RFC RFC RFC RFC RFC RFC RFC RFC RFC RFC
BECAUSE THIS BREAKS CLEAN BUILDS WITH:
In file included from :0:0:
/local/scratch/ianc/devel/arm/xen.git/xen/include/xen/config.h:10:32: fatal 
error: generated/autoconf.h: No such file or directory
 #include 

I'm not sure why given the descriptions of olddefconfig and
silentoldconfig below.

DO NOT APPLY (OF COURSE!)

RFC RFC RFC RFC RFC RFC RFC RFC RFC RFC RFC

When pulling my git tree over a commit which adds new Kconfig
questions the incremental build still stops and asks me the new
questions:

+ make -C xen XEN_TARGET_ARCH=arm64 DESTDIR=/tmp/tmprg7d63   debug=y 
CROSS_COMPILE=aarch64-linux-gnu- -j12 CONFIG_EARLY_PRINTK=fastmodel install
make: Entering directory '/local/scratch/ianc/devel/arm/xen.git/xen'
make -f 
/local/scratch/ianc/devel/arm/xen.git/xen/tools/kconfig/Makefile.kconfig 
ARCH=arm64 silentoldconfig
make[1]: Entering directory '/local/scratch/ianc/devel/arm/xen.git/xen'
gcc -Wp,-MD,tools/kconfig/.conf.o.d-I/usr/include/ncursesw 
-DCURSES_LOC="" -DNCURSES_WIDECHAR=1 -DLOCALE   -c -o 
tools/kconfig/conf.o tools/kconfig/conf.c
gcc -Wp,-MD,tools/kconfig/.zconf.tab.o.d-I/usr/include/ncursesw 
-DCURSES_LOC="" -DNCURSES_WIDECHAR=1 -DLOCALE -Itools/kconfig -c -o 
tools/kconfig/zconf.tab.o tools/kconfig/zconf.tab.c
gcc  -o tools/kconfig/conf tools/kconfig/conf.o tools/kconfig/zconf.tab.o
tools/kconfig/conf -s --silentoldconfig Kconfig
*
* Restart config...
*
*
* Architecture Features
*
Maximum number of physical CPUs (NR_CPUS) [128] (NEW)

This is in contrast to a fully clean build which just gets on with
using the defconfig. According to "make -C xen/tools/kconfig/ help" it seems
like we want olddefconfig rather than silentoldconfig:

  oldconfig   - Update current config utilising a provided .config as base
[...]
  silentoldconfig - Same as oldconfig, but quietly, additionally update deps
[...]
  olddefconfig- Same as silentoldconfig but sets new symbols to their
default value

With this changed it now doesn't ask me any questions on an incremental build
when a new question is added.

Note however that AFAICT in no case would this pickup a change to the default
of an existing option (how could it know?). I think we can live with this.

Signed-off-by: Ian Campbell 
Cc: Doug Goldstein 
---
 xen/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/Makefile b/xen/Makefile
index 3699b20..f8f3bb4 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -239,7 +239,7 @@ $(kconfig):
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(XEN_TARGET_ARCH) $@
 
 include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
-   $(Q)$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(XEN_TARGET_ARCH) silentoldconfig
+   $(Q)$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
ARCH=$(XEN_TARGET_ARCH) olddefconfig
 
 # Allow people to just run `make` as before and not force them to configure
 $(KCONFIG_CONFIG):
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 03/28] libxl: Provide libxl__dm_support_*

[Jim Fehlig]

On 01/15/2016 02:56 AM, Ian Campbell wrote:
> On Thu, 2016-01-14 at 11:31 -0700, Jim Fehlig wrote:
>> Ian Campbell wrote:
>>> On Mon, 2016-01-11 at 10:00 -0700, Jim Fehlig wrote:
 On 01/07/2016 10:13 AM, Ian Campbell wrote:
> On Tue, 2015-12-22 at 18:44 +, Ian Jackson wrote:
>> This allows code elsewhere in libxl to find out what options a
>> device
>> model executable supports.  This is done by searching the usage
>> message for fixed strings.
> Has anyone (ever, not necessarily a Xen person nor in this context)
> approached upstream QEMU about a machine readable output of some
> sort?
>
> I know libvirt does something similar to this, but they want to
> support
> older versions, whereas we at least have the luxury of not caring
> about
> versions before the point this code lands.
 Since qemu 1.2.0, libvirt has been using the various QMP commands to
 probe for
 qemu capabilities, instead of parsing help output.
>>> As in it spawns a qemu specifically to ask the questions and then kills
>>> it
>>> and starts what it needs _or_ it starts the qemu with minimal command
>>> line
>>> cfg and then dynamically pokes in the full config via qmp?
>> The latter.
> From the description I think you meant former?

Yes :-). Brain thought one way, fingers typed another...

Regards,
Jim

>
>>  When the qemu driver loads, it starts qemu, pokes it for
>> capabilities via qmp, caches what it finds, then terminates it. The cached
>> capabilities are used until the associated qemu binary is changed/updated.
>>
>> If interested in peeking at the code, see virQEMUCapsInitQMP() and the 
>> functions
>> it calls in $libvirt_src/src/qemu/qemu_capabilities.c. E.g.
>>
>> virQEMUCapsInitQMP()
>>   -> virQEMUCapsInitQMPMonitor()
>> -> virQEMUCapsInitQMPBasic()
> Thanks.
>
> When I spoke to Ian J yesterday we decided doing this properly (via QMP as
> above) would be nice it was out of scope for this series for now. It would
> make a nice future bit of cleanup though for sure.
>
> Ian.
>
>> Regards,
>> Jim
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel


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

[Xen-devel] [PATCH v2 2/4] libelf: rewrite symtab/strtab loading for Dom0

[Roger Pau Monne]

Current implementation of elf_load_bsdsyms is broken when loading inside of
a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
memory space, which it is not.

Take the oportunity to do some cleanup and properly document how
elf_{parse/load}_bsdsyms works. The new implementation uses elf_load_image
when dealing with data that needs to be copied to the guest memory space.
Also reduce the number of section headers copied to the minimum necessary.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/common/libelf/libelf-loader.c | 213 --
 1 file changed, 158 insertions(+), 55 deletions(-)

diff --git a/xen/common/libelf/libelf-loader.c 
b/xen/common/libelf/libelf-loader.c
index 6f42bea..9552d4c 100644
--- a/xen/common/libelf/libelf-loader.c
+++ b/xen/common/libelf/libelf-loader.c
@@ -153,7 +153,7 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t 
pstart)
 {
 uint64_t sz;
 ELF_HANDLE_DECL(elf_shdr) shdr;
-unsigned i, type;
+unsigned int i;
 
 if ( !ELF_HANDLE_VALID(elf->sym_tab) )
 return;
@@ -164,20 +164,33 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t 
pstart)
 sz = sizeof(uint32_t);
 
 /* Space for the elf and elf section headers */
-sz += (elf_uval(elf, elf->ehdr, e_ehsize) +
-   elf_shdr_count(elf) * elf_uval(elf, elf->ehdr, e_shentsize));
+sz += elf_uval(elf, elf->ehdr, e_ehsize) +
+  3 * elf_uval(elf, elf->ehdr, e_shentsize);
 sz = elf_round_up(elf, sz);
 
-/* Space for the symbol and string tables. */
+/* Space for the symbol and string table. */
 for ( i = 0; i < elf_shdr_count(elf); i++ )
 {
 shdr = elf_shdr_by_index(elf, i);
 if ( !elf_access_ok(elf, ELF_HANDLE_PTRVAL(shdr), 1) )
 /* input has an insane section header count field */
 break;
-type = elf_uval(elf, shdr, sh_type);
-if ( (type == SHT_STRTAB) || (type == SHT_SYMTAB) )
-sz = elf_round_up(elf, sz + elf_uval(elf, shdr, sh_size));
+
+if ( elf_uval(elf, shdr, sh_type) != SHT_SYMTAB )
+continue;
+
+sz = elf_round_up(elf, sz + elf_uval(elf, shdr, sh_size));
+shdr = elf_shdr_by_index(elf, elf_uval(elf, shdr, sh_link));
+
+if ( !elf_access_ok(elf, ELF_HANDLE_PTRVAL(shdr), 1) )
+/* input has an insane section header count field */
+break;
+
+if ( elf_uval(elf, shdr, sh_type) != SHT_STRTAB )
+/* Invalid symtab -> strtab link */
+break;
+
+sz = elf_round_up(elf, sz + elf_uval(elf, shdr, sh_size));
 }
 
 elf->bsd_symtab_pstart = pstart;
@@ -186,13 +199,31 @@ void elf_parse_bsdsyms(struct elf_binary *elf, uint64_t 
pstart)
 
 static void elf_load_bsdsyms(struct elf_binary *elf)
 {
-ELF_HANDLE_DECL(elf_ehdr) sym_ehdr;
-unsigned long sz;
-elf_ptrval maxva;
-elf_ptrval symbase;
-elf_ptrval symtab_addr;
-ELF_HANDLE_DECL(elf_shdr) shdr;
-unsigned i, type;
+/*
+ * Header that is placed at the end of the kernel and allows
+ * the OS to find where the symtab and strtab have been loaded.
+ * It mimics a valid ELF file header, although it only contains
+ * a symtab and a strtab section.
+ *
+ * NB: according to the ELF spec there's only ONE symtab per ELF
+ * file, and accordingly we will only load the corresponding
+ * strtab, so we only need three section headers in our fake ELF
+ * header (first section header is always a dummy).
+ */
+struct __packed {
+elf_ehdr header;
+elf_shdr section[3];
+} symbol_header;
+
+ELF_HANDLE_DECL(elf_ehdr) header_handle;
+unsigned long shdr_size;
+uint32_t symsize;
+ELF_HANDLE_DECL(elf_shdr) section_handle;
+ELF_HANDLE_DECL(elf_shdr) image_handle;
+unsigned int i, link;
+elf_ptrval header_base;
+elf_ptrval symtab_base;
+elf_ptrval strtab_base;
 
 if ( !elf->bsd_symtab_pstart )
 return;
@@ -200,64 +231,136 @@ static void elf_load_bsdsyms(struct elf_binary *elf)
 #define elf_hdr_elm(_elf, _hdr, _elm, _val) \
 do {\
 if ( elf_64bit(_elf) )  \
-elf_store_field(_elf, _hdr, e64._elm, _val);  \
+(_hdr).e64._elm = _val; \
 else\
-elf_store_field(_elf, _hdr, e32._elm, _val);  \
+(_hdr).e32._elm = _val; \
 } while ( 0 )
 
-symbase = elf_get_ptr(elf, elf->bsd_symtab_pstart);
-symtab_addr = maxva = symbase + sizeof(uint32_t);
+#define SYMTAB_INDEX1
+#define STRTAB_INDEX2
 
-/* Set up Elf header. */
-sym_ehdr = ELF_MAKE_HANDLE(elf_ehdr, symtab_addr);
-sz = 

[Xen-devel] [PATCH v2 0/4] HVMlite: minor fixes and Dom0 preparatory patches

[Roger Pau Monne]

Hello,

This series contains some bug fixes for HVMlite DomU and a preparatory 
patch for HVMlite Dom0 support (2/4).

Thanks, Roger.


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

[Xen-devel] [PATCH v2 4/4] x86/PV: enable the emulated PIT

[Roger Pau Monne]

The HVMlite series removed the initialization of the emulated PIT for PV
guests, this patch re-enables it.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
NB: Since it's not clear why an emulated PIT is needed, it won't be enabled
by default for HVMlite guests until we can figure out if/why it's needed.
---
Changes since v1:
 - New in this version.
---
 tools/libxl/libxl_x86.c | 8 +++-
 xen/arch/x86/domain.c   | 5 +++--
 xen/arch/x86/setup.c| 4 +++-
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 46cfafb..7f47cc5 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -13,8 +13,14 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
 LIBXL_DEVICE_MODEL_VERSION_NONE) {
 /* HVM domains with a device model. */
 xc_config->emulation_flags = XEN_X86_EMU_ALL;
+} else if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_PV) {
+/* PV domains. */
+xc_config->emulation_flags = XEN_X86_EMU_PIT;
 } else {
-/* PV or HVM domains without a device model. */
+assert(d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM);
+assert(d_config->b_info.device_model_version ==
+   LIBXL_DEVICE_MODEL_VERSION_NONE);
+/* HVMlite domains. */
 xc_config->emulation_flags = 0;
 }
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 159d960..8ee5d76 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -542,8 +542,9 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
d->domain_id, config->emulation_flags);
 return -EINVAL;
 }
-if ( config->emulation_flags != 0 &&
- (!is_hvm_domain(d) || config->emulation_flags != XEN_X86_EMU_ALL) 
)
+if ( (is_hvm_domain(d) && config->emulation_flags != XEN_X86_EMU_ALL &&
+ config->emulation_flags != 0) ||
+ (!is_hvm_domain(d) && config->emulation_flags != XEN_X86_EMU_PIT) 
)
 {
 printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 76c7b0f..08bd3fb 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -582,7 +582,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 .parity= 'n',
 .stop_bits = 1
 };
-struct xen_arch_domainconfig config = { .emulation_flags = 0 };
+struct xen_arch_domainconfig config = {
+.emulation_flags = XEN_X86_EMU_PIT,
+};
 
 /* Critical region without IDT or TSS.  Any fault is deadly! */
 
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v2 3/4] x86/hvm: don't set the BSP as initialised in hvm_vcpu_initialise

[Roger Pau Monne]

The BSP will be marked as initialised after hvm_load_cpu_ctxt has loaded the
initial state, which is called from the toolstack during domain creation.

Previous to my HVMlite series HVM guests were started without setting any
explicit CPU state (in fact we placed that horrible jmp at 0x0, because the
IP was by default set to 0x0). This is no longer true, and now HVM guests
require that a proper CPU context is loaded before starting. This change
helps enforce this policy.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v1:
 - Expand commit description.
---
 xen/arch/x86/hvm/hvm.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 787b7de..05c3ca1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2474,10 +2474,6 @@ int hvm_vcpu_initialise(struct vcpu *v)
  
 /* Init guest TSC to start from zero. */
 hvm_set_guest_tsc(v, 0);
-
-/* Can start up without SIPI-SIPI or setvcpucontext domctl. */
-v->is_initialised = 1;
-clear_bit(_VPF_down, >pause_flags);
 }
 
 return 0;
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [PATCH v2 1/4] xen/elfnotes: check phys_entry against UNSET_ADDR32

[Roger Pau Monne]

And introduce UNSET_ADDR32.

Signed-off-by: Roger Pau Monné 
Acked-by: Jan Beulich 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
Changes since v1:
 - Fix commit title.
---
 tools/libxc/xc_dom_elfloader.c | 2 +-
 xen/common/libelf/libelf-dominfo.c | 1 +
 xen/include/xen/libelf.h   | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 2ae575e..5039f3f 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -57,7 +57,7 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
 uint64_t machine = elf_uval(elf, elf->ehdr, e_machine);
 
 if ( dom->container_type == XC_DOM_HVM_CONTAINER &&
- dom->parms.phys_entry != UNSET_ADDR )
+ dom->parms.phys_entry != UNSET_ADDR32 )
 return "hvm-3.0-x86_32";
 
 switch ( machine )
diff --git a/xen/common/libelf/libelf-dominfo.c 
b/xen/common/libelf/libelf-dominfo.c
index 02d6cfb..ec69449 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -503,6 +503,7 @@ elf_errorstatus elf_xen_parse(struct elf_binary *elf,
 parms->virt_hv_start_low = UNSET_ADDR;
 parms->p2m_base = UNSET_ADDR;
 parms->elf_paddr_offset = UNSET_ADDR;
+parms->phys_entry = UNSET_ADDR32;
 
 /* Find and parse elf notes. */
 count = elf_phdr_count(elf);
diff --git a/xen/include/xen/libelf.h b/xen/include/xen/libelf.h
index 6da4cc0..95b5370 100644
--- a/xen/include/xen/libelf.h
+++ b/xen/include/xen/libelf.h
@@ -386,6 +386,7 @@ elf_errorstatus elf_reloc(struct elf_binary *elf);
 /* xc_libelf_dominfo.c  */
 
 #define UNSET_ADDR  ((uint64_t)-1)
+#define UNSET_ADDR32((uint32_t)-1)
 
 enum xen_elfnote_type {
 XEN_ENT_NONE = 0,
-- 
1.9.5 (Apple Git-50.3)


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

Re: [Xen-devel] [PATCH v3 00/15] xenstore: make it easier to run xenstore in a domain

[Juergen Gross]

On 08/01/16 14:08, Juergen Gross wrote:
> Xen supports to run xenstore in a dedicated domain. It is, however, a
> setup which isn't easy to configure. Today flask is required for full
> functionality and the resulting xenstore domain is not configurable in
> the same way as the xenstore daemon.
> 
> This patch series enables running a xenstore domain without flask. The
> tool needed to start that domain is added to the installed binaries
> and it is modified to pass arbitrary options to the xenstore domain.
> 
> I didn't include a configuration option for starting xenstore as an
> own domain instead of the daemon, as this will require some major
> tweaking of especially the systemd configuration files. Support for
> this will be added later. The main issue is that running xenstore in
> a domain requires the xenstore sockets not to be created. I don't
> think this is possible with the current scheme of letting systemd
> create those sockets.
> 
> Changes in V3:
> - patch 1: changed comment as requested by Ian Campbell
> - patch 2: changed name of flag from "xs_domain" to "xenstore" as requested
>by Ian Campbell
> - patch 3: flag in dominfo instead function to get xenstore domid as requested
>by Ian Campbell
> - patch 4: don't adapt coding style as requested by Ian Campbell
>adjust .gitignore
> - new patch 5: adapt coding style of init-xenstore-domain.c
> - patch 6 (was 5): adjust .gitignore as requested by Ian Campbell
>use libxentoollog instead of libxc as requested by Ian Campbell
> - patch 10 (was 9): omit dom0 when checking for xenstore domain as suggested 
> by
>Ian Campbell
>log an error in case of an error when obtaining domain info as
>requested by Ian Campbell
> - patch 14 (was 13): xl shutdown modified to query the "never_stop" flag
>instead of the xenstore domain id as requested by Ian Campbell
>drop usage of xenstore-exists as requested by Ian Campbell
> - new patch 15: add xenstore domain xenstroe paths to docs as requested by
>Ian Campbell
> 
> Changes in V2:
> - add new patch 3 to get the xenstore domain id via libxl
> - move init-xenstore-domain to new directory tools/helpers in patch 4
>   (former patch 3) and modify it to use the standard tools coding style
> - add new patch 5 moving xen-init-dom0 to tools/helpers
> - split patch 6 (former patch 4) into 2 patches as requested by Ian Campbell
> - correct parameter parsing in patch 8 (former patch 5)
> - modified commit message of patch 9 (former patch 6) as requested by
>   Ian Campbell
> - add new patch 11 to split up xen-init-dom0
> - modify patch 12 (former patch 8) to create json object and more xenstore
>   entries, add error messages as requested by Ian Campbell
> - drop former patch 9
> - add new patch 13 to avoid stopping xenstore domain on dom0 shutdown
> 
> Juergen Gross (15):
>   xen: add xenstore domain flag to hypervisor
>   libxc: support new xenstore domain flag in libxc
>   libxl: provide a flag in dominfo to avoid stopping it
>   xenstore: move init-xenstore-domain to tools/helpers
>   xenstore: adjust coding style of init-xenstore-domain.c
>   libxl: move xen-init-dom0 to tools/helpers
>   xenstore: destroy xenstore domain in case of error after creating it
>   xenstore: add error messages to init-xenstore-domain
>   xenstore: modify init-xenstore-domain parameter syntax
>   xenstore: make use of the "xenstore domain" flag
>   xenstore: add init-xenstore-domain parameter to specify cmdline
>   tools: split up xen-init-dom0.c
>   xenstore: write xenstore domain data to xenstore
>   tools: don't stop xenstore domain when stopping dom0
>   docs: document xenstore domain xenstore paths
> 
>  .gitignore|   4 +-
>  docs/misc/xenstore-paths.markdown |  10 +
>  tools/Makefile|   1 +
>  tools/helpers/Makefile|  46 +
>  tools/helpers/init-dom-json.c |  59 ++
>  tools/helpers/init-dom-json.h |  18 ++
>  tools/helpers/init-xenstore-domain.c  | 343 
> ++
>  tools/helpers/xen-init-dom0.c |  67 +++
>  tools/hotplug/Linux/xendomains.in |  15 ++
>  tools/libxc/include/xenctrl.h |   2 +-
>  tools/libxc/xc_domain.c   |   1 +
>  tools/libxl/Makefile  |  14 +-
>  tools/libxl/libxl.c   |  11 +-
>  tools/libxl/libxl.h   |   9 +
>  tools/libxl/libxl_types.idl   |   1 +
>  tools/libxl/xen-init-dom0.c   | 120 
>  tools/libxl/xl_cmdimpl.c  |   8 +-
>  tools/xenstore/Makefile   |   9 -
>  tools/xenstore/init-xenstore-domain.c | 119 
>  xen/common/domain.c   |   6 +
>  xen/common/domctl.c   |  14 +-
>  xen/include/public/domctl.h   |   6 +
>  xen/include/xen/sched.h   |   5 +
>  xen/include/xsm/dummy.h  

[Xen-devel] [PATCH v6 0/2] memory-hotplug: add automatic onlining policy for the newly added memory

[Vitaly Kuznetsov]

Changes since v5:
Patch 1:
- Mention possible failures during automatic onlining in memory-hotplug.txt
  [David Rientjes]
- Add Daniel's Reviewed-by: (hope it stands)

Patch2:
- Change the last 'domU' -> 'target domain' in Kconfig [Daniel Kiper]
- Add Daniel's Reviewed-by:
- Add David's Acked-by:

Original description:

Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:

SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"

to make this happen automatically. This is not a great solution for virtual
machines where memory hotplug is being used to address high memory pressure
situations as such onlining is slow and a userspace process doing this
(udev) has a chance of being killed by the OOM killer as it will probably
require to allocate some memory.

Introduce default policy for the newly added memory blocks in
/sys/devices/system/memory/auto_online_blocks file with two possible
values: "offline" which preserves the current behavior and "online" which
causes all newly added memory blocks to go online as soon as they're added.
The default is "offline".

Vitaly Kuznetsov (2):
  memory-hotplug: add automatic onlining policy for the newly added
memory
  xen_balloon: support memory auto onlining policy

 Documentation/memory-hotplug.txt | 23 ---
 drivers/base/memory.c| 34 +-
 drivers/xen/Kconfig  | 23 +++
 drivers/xen/balloon.c| 11 ++-
 include/linux/memory.h   |  3 +++
 include/linux/memory_hotplug.h   |  4 +++-
 mm/memory_hotplug.c  | 17 +++--
 7 files changed, 99 insertions(+), 16 deletions(-)

-- 
2.5.0


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

Re: [Xen-devel] [PATCH v1] xen/arm: Add r1p12 to the list of supported Cadence UARTs

[Edgar E. Iglesias]

On Fri, Jan 15, 2016 at 12:30:27PM +, Ian Campbell wrote:
> On Thu, 2016-01-14 at 19:44 +0100, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias" 
> 
> Where are the bindings for cdns,uart-r1p12 defined? I don't see it
> mentioned in the Documentation/devicetree/bindings/serial/cdns,uart.txt in
> mainline Linux.

Hi Ian,

The bindings are currently in our queue:
https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/serial/cdns%2Cuart.txt


> Does the driver need to differ at all compared with what is needed for
> r1p8? Normally if there is no (practical/visible) difference then in DT-
> world there is no need for a new compatible string, since the device is
> still compatible.
> 
> If there are differences in the h/w but they are not relevant to our
> particular driven then please say so in the commit log.

Right, there are SW visible differences (the Linux driver uses them) but
none affecting XEN. I'll note that in the commit message.

Thanks,
Edgar


> 
> Ian.
> 
> > 
> > Signed-off-by: Edgar E. Iglesias 
> > ---
> >  xen/drivers/char/cadence-uart.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/xen/drivers/char/cadence-uart.c b/xen/drivers/char/cadence-
> > uart.c
> > index 933672f..7f90f8d 100644
> > --- a/xen/drivers/char/cadence-uart.c
> > +++ b/xen/drivers/char/cadence-uart.c
> > @@ -206,6 +206,7 @@ static int __init cuart_init(struct dt_device_node
> > *dev, const void *data)
> >  static const struct dt_device_match cuart_dt_match[] __initconst =
> >  {
> >  DT_MATCH_COMPATIBLE("cdns,uart-r1p8"),
> > +DT_MATCH_COMPATIBLE("cdns,uart-r1p12"),
> >  { /* sentinel */ },
> >  };
> >  

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