[Qemu-devel] [PATCH 2/8] xen: introduce the header file for the Xen 9pfs transport protocol
It uses the new ring.h macros to declare rings and interfaces. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC: jgr...@suse.com --- hw/9pfs/xen_9pfs.h | 20 1 file changed, 20 insertions(+) create mode 100644 hw/9pfs/xen_9pfs.h diff --git a/hw/9pfs/xen_9pfs.h b/hw/9pfs/xen_9pfs.h new file mode 100644 index 000..c4e8901 --- /dev/null +++ b/hw/9pfs/xen_9pfs.h @@ -0,0 +1,20 @@ +#ifndef XEN_9PFS_H +#define XEN_9PFS_H + +#include "hw/xen/io/ring.h" +#include + +struct xen_9pfs_header { + uint32_t size; + uint8_t id; + uint16_t tag; + + /* uint8_t sdata[]; */ +} __attribute__((packed)); + +#define PAGE_SHIFT XC_PAGE_SHIFT +#define XEN_9PFS_RING_ORDER 6 +#define XEN_9PFS_RING_SIZE XEN_FLEX_RING_SIZE(XEN_9PFS_RING_ORDER) +DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs); + +#endif -- 1.9.1
[Qemu-devel] [PATCH 1/8] xen: import ring.h from xen
Do not use the ring.h header installed on the system. Instead, import the header into the QEMU codebase. This avoids problems when QEMU is built against a Xen version too old to provide all the ring macros. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC: jgr...@suse.com --- NB: The new macros have not been committed to Xen yet. Do not apply this patch until they do. --- --- hw/block/xen_blkif.h | 2 +- hw/usb/xen-usb.c | 2 +- include/hw/xen/io/ring.h | 455 +++ 3 files changed, 457 insertions(+), 2 deletions(-) create mode 100644 include/hw/xen/io/ring.h diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h index 3300b6f..3e6e1ea 100644 --- a/hw/block/xen_blkif.h +++ b/hw/block/xen_blkif.h @@ -1,7 +1,7 @@ #ifndef XEN_BLKIF_H #define XEN_BLKIF_H -#include +#include "hw/xen/io/ring.h" #include #include diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c index 8e676e6..370b3d9 100644 --- a/hw/usb/xen-usb.c +++ b/hw/usb/xen-usb.c @@ -33,7 +33,7 @@ #include "qapi/qmp/qint.h" #include "qapi/qmp/qstring.h" -#include +#include "hw/xen/io/ring.h" #include /* diff --git a/include/hw/xen/io/ring.h b/include/hw/xen/io/ring.h new file mode 100644 index 000..cf01fc3 --- /dev/null +++ b/include/hw/xen/io/ring.h @@ -0,0 +1,455 @@ +/** + * ring.h + * + * Shared producer-consumer ring macros. + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this software and associated documentation files (the "Software"), to + * deal in the Software without restriction, including without limitation the + * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the Software is + * furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Tim Deegan and Andrew Warfield November 2004. + */ + +#ifndef __XEN_PUBLIC_IO_RING_H__ +#define __XEN_PUBLIC_IO_RING_H__ + +#if __XEN_INTERFACE_VERSION__ < 0x00030208 +#define xen_mb() mb() +#define xen_rmb() rmb() +#define xen_wmb() wmb() +#endif + +typedef unsigned int RING_IDX; + +/* Round a 32-bit unsigned constant down to the nearest power of two. */ +#define __RD2(_x) (((_x) & 0x0002) ? 0x2 : ((_x) & 0x1)) +#define __RD4(_x) (((_x) & 0x000c) ? __RD2((_x)>>2)<<2: __RD2(_x)) +#define __RD8(_x) (((_x) & 0x00f0) ? __RD4((_x)>>4)<<4: __RD4(_x)) +#define __RD16(_x) (((_x) & 0xff00) ? __RD8((_x)>>8)<<8: __RD8(_x)) +#define __RD32(_x) (((_x) & 0x) ? __RD16((_x)>>16)<<16 : __RD16(_x)) + +/* + * Calculate size of a shared ring, given the total available space for the + * ring and indexes (_sz), and the name tag of the request/response structure. + * A ring contains as many entries as will fit, rounded down to the nearest + * power of two (so we can mask with (size-1) to loop around). + */ +#define __CONST_RING_SIZE(_s, _sz) \ +(__RD32(((_sz) - offsetof(struct _s##_sring, ring)) / \ + sizeof(((struct _s##_sring *)0)->ring[0]))) +/* + * The same for passing in an actual pointer instead of a name tag. + */ +#define __RING_SIZE(_s, _sz) \ +(__RD32(((_sz) - (long)(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0]))) + +/* + * Macros to make the correct C datatypes for a new kind of ring. + * + * To make a new ring datatype, you need to have two message structures, + * let's say request_t, and response_t already defined. + * + * In a header where you want the ring datatype declared, you then do: + * + * DEFINE_RING_TYPES(mytag, request_t, response_t); + * + * These expand out to give you a set of types, as you can see below. + * The most important of these are: + * + * mytag_sring_t - The shared ring. + * mytag_front_ring_t - The 'front' half of the ring. + * mytag_back_ring_t - The 'back' half of the ring. + * + * To initialize a ring in your code you need to know the location and size + * of the shared memory area (PAGE_SIZE, for instance). To initialise + * the front half: + * + * mytag_front_ring_t front_r
[Qemu-devel] [PATCH 3/8] xen/9pfs: introduce Xen 9pfs backend
Introduce the Xen 9pfs backend: add struct XenDevOps to register as a Xen backend and add struct V9fsTransport to register as v9fs transport. All functions are empty stubs for now. Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Aneesh Kumar K.V CC: Greg Kurz --- hw/9pfs/xen-9p-backend.c | 96 1 file changed, 96 insertions(+) create mode 100644 hw/9pfs/xen-9p-backend.c diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c new file mode 100644 index 000..924fb64 --- /dev/null +++ b/hw/9pfs/xen-9p-backend.c @@ -0,0 +1,96 @@ +/* + * Xen 9p backend + * + * Copyright Aporeto 2017 + * + * Authors: + * Stefano Stabellini + * + */ + +#include "qemu/osdep.h" + +#include "hw/hw.h" +#include "hw/9pfs/9p.h" +#include "hw/xen/xen_backend.h" +#include "xen_9pfs.h" +#include "qemu/config-file.h" +#include "fsdev/qemu-fsdev.h" + +struct Xen9pfsDev { +struct XenDevice xendev; /* must be first */ +}; + +static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu, + size_t offset, + const char *fmt, + va_list ap) +{ +return 0; +} + +static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu, + size_t offset, + const char *fmt, + va_list ap) +{ +return 0; +} + +static void xen_9pfs_init_out_iov_from_pdu(V9fsPDU *pdu, + struct iovec **piov, + unsigned int *pniov) +{ +} + +static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu, + struct iovec **piov, + unsigned int *pniov, + size_t size) +{ +} + +static void xen_9pfs_push_and_notify(V9fsPDU *pdu) +{ +} + +static const struct V9fsTransport xen_9p_transport = { +.pdu_vmarshal = xen_9pfs_pdu_vmarshal, +.pdu_vunmarshal = xen_9pfs_pdu_vunmarshal, +.init_in_iov_from_pdu = xen_9pfs_init_in_iov_from_pdu, +.init_out_iov_from_pdu = xen_9pfs_init_out_iov_from_pdu, +.push_and_notify = xen_9pfs_push_and_notify, +}; + +static int xen_9pfs_init(struct XenDevice *xendev) +{ +return 0; +} + +static int xen_9pfs_free(struct XenDevice *xendev) +{ +return -1; +} + +static int xen_9pfs_connect(struct XenDevice *xendev) +{ +return 0; +} + +static void xen_9pfs_alloc(struct XenDevice *xendev) +{ +} + +static void xen_9pfs_disconnect(struct XenDevice *xendev) +{ +} + +struct XenDevOps xen_9pfs_ops = { +.size = sizeof(struct Xen9pfsDev), +.flags = DEVOPS_FLAG_NEED_GNTDEV, +.alloc = xen_9pfs_alloc, +.init = xen_9pfs_init, +.initialise= xen_9pfs_connect, +.disconnect = xen_9pfs_disconnect, +.free = xen_9pfs_free, +}; -- 1.9.1
[Qemu-devel] [PATCH 8/8] xen/9pfs: build and register Xen 9pfs backend
Signed-off-by: Stefano Stabellini CC: anthony.per...@citrix.com CC: jgr...@suse.com CC: Aneesh Kumar K.V CC: Greg Kurz --- hw/9pfs/Makefile.objs| 1 + hw/xen/xen_backend.c | 1 + include/hw/xen/xen_backend.h | 1 + 3 files changed, 3 insertions(+) diff --git a/hw/9pfs/Makefile.objs b/hw/9pfs/Makefile.objs index da0ae0c..76a81c3 100644 --- a/hw/9pfs/Makefile.objs +++ b/hw/9pfs/Makefile.objs @@ -7,3 +7,4 @@ common-obj-$(CONFIG_OPEN_BY_HANDLE) += 9p-handle.o common-obj-y += 9p-proxy.o obj-y += virtio-9p-device.o +obj-y += xen-9p-backend.o diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 6c21c37..7aa347d 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -585,6 +585,7 @@ void xen_be_register_common(void) xen_be_register("console", &xen_console_ops); xen_be_register("vkbd", &xen_kbdmouse_ops); xen_be_register("qdisk", &xen_blkdev_ops); +xen_be_register("9pfs", &xen_9pfs_ops); #ifdef CONFIG_USB_LIBUSB xen_be_register("qusb", &xen_usb_ops); #endif diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h index 4f4799a..84e686c 100644 --- a/include/hw/xen/xen_backend.h +++ b/include/hw/xen/xen_backend.h @@ -49,6 +49,7 @@ extern struct XenDevOps xen_console_ops; /* xen_console.c */ extern struct XenDevOps xen_kbdmouse_ops; /* xen_framebuffer.c */ extern struct XenDevOps xen_framebuffer_ops; /* xen_framebuffer.c */ extern struct XenDevOps xen_blkdev_ops; /* xen_disk.c*/ +extern struct XenDevOps xen_9pfs_ops; /* xen-9p-backend.c*/ extern struct XenDevOps xen_netdev_ops; /* xen_nic.c */ #ifdef CONFIG_USB_LIBUSB extern struct XenDevOps xen_usb_ops; /* xen-usb.c */ -- 1.9.1
[Qemu-devel] [PATCH 0/8] xen/9pfs: introduce the Xen 9pfs backend
Hi all, This patch series implements a new transport for 9pfs, aimed at Xen systems. The transport is based on a traditional Xen frontend and backend drivers pair. This patch series implements the backend, which typically runs in Dom0. I sent another series to implement the frontend in Linux (http://marc.info/?l=linux-kernel&m=148883047125960&w=2). The backend complies to the Xen transport for 9pfs specification version 1, available here: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=docs/misc/9pfs.markdown;hb=HEAD Stefano Stabellini (8): xen: import ring.h from xen xen: introduce the header file for the Xen 9pfs transport protocol xen/9pfs: introduce Xen 9pfs backend xen/9pfs: connect to the frontend xen/9pfs: receive requests from the frontend xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal xen/9pfs: send responses back to the frontend xen/9pfs: build and register Xen 9pfs backend hw/9pfs/Makefile.objs| 1 + hw/9pfs/xen-9p-backend.c | 403 ++ hw/9pfs/xen_9pfs.h | 20 ++ hw/block/xen_blkif.h | 2 +- hw/usb/xen-usb.c | 2 +- hw/xen/xen_backend.c | 1 + include/hw/xen/io/ring.h | 455 +++ include/hw/xen/xen_backend.h | 1 + 8 files changed, 883 insertions(+), 2 deletions(-) create mode 100644 hw/9pfs/xen-9p-backend.c create mode 100644 hw/9pfs/xen_9pfs.h create mode 100644 include/hw/xen/io/ring.h
Re: [Qemu-devel] [PATCH v2 5/5] xen: use libxendevicemodel when available
On Mon, 6 Mar 2017, Paul Durrant wrote: > > -Original Message- > > From: Qemu-devel [mailto:qemu-devel- > > bounces+paul.durrant=citrix@nongnu.org] On Behalf Of Paul Durrant > > Sent: 06 March 2017 09:15 > > To: 'Stefano Stabellini' > > Cc: Anthony Perard ; xen- > > de...@lists.xenproject.org; qemu-devel@nongnu.org > > Subject: Re: [Qemu-devel] [PATCH v2 5/5] xen: use libxendevicemodel when > > available > > > > > -Original Message- > > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > > Sent: 03 March 2017 20:43 > > > To: Stefano Stabellini > > > Cc: Paul Durrant ; xen- > > de...@lists.xenproject.org; > > > qemu-devel@nongnu.org; Anthony Perard > > > Subject: RE: [PATCH v2 5/5] xen: use libxendevicemodel when available > > > > > > On Fri, 3 Mar 2017, Stefano Stabellini wrote: > > > > On Fri, 3 Mar 2017, Paul Durrant wrote: > > > > > > -Original Message- > > > > > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > > > > > Sent: 02 March 2017 22:50 > > > > > > To: Paul Durrant > > > > > > Cc: xen-de...@lists.xenproject.org; qemu-devel@nongnu.org; > > Stefano > > > > > > Stabellini ; Anthony Perard > > > > > > > > > > > > Subject: Re: [PATCH v2 5/5] xen: use libxendevicemodel when > > available > > > > > > > > > > > > On Thu, 2 Mar 2017, Paul Durrant wrote: > > > > > > > This patch modifies the wrapper functions in xen_common.h to use > > > the > > > > > > > new xendevicemodel interface if it is available along with > > > compatibility > > > > > > > code to use the old libxenctrl interface if it is not. > > > > > > > > > > > > > > Signed-off-by: Paul Durrant > > > > > > > --- > > > > > > > Cc: Stefano Stabellini > > > > > > > Cc: Anthony Perard > > > > > > > > > > > > > > v2: > > > > > > > - Add a compat define for xenforeignmemory_close() since this is > > > now > > > > > > > used. > > > > > > > --- > > > > > > > include/hw/xen/xen_common.h | 115 > > > > > > +++- > > > > > > > xen-common.c| 8 +++ > > > > > > > 2 files changed, 90 insertions(+), 33 deletions(-) > > > > > > > > > > > > > > diff --git a/include/hw/xen/xen_common.h > > > > > > b/include/hw/xen/xen_common.h > > > > > > > index 31cf25f..48444e5 100644 > > > > > > > --- a/include/hw/xen/xen_common.h > > > > > > > +++ b/include/hw/xen/xen_common.h > > > > > > > @@ -9,6 +9,7 @@ > > > > > > > #undef XC_WANT_COMPAT_EVTCHN_API > > > > > > > #undef XC_WANT_COMPAT_GNTTAB_API > > > > > > > #undef XC_WANT_COMPAT_MAP_FOREIGN_API > > > > > > > +#undef XC_WANT_COMPAT_DEVICEMODEL_API > > > > > > > > > > > > > > #include > > > > > > > #include > > > > > > > @@ -26,48 +27,95 @@ extern xc_interface *xen_xc; > > > > > > > * We don't support Xen prior to 4.2.0. > > > > > > > */ > > > > > > > > > > > > > > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490 > > > > > > > + > > > > > > > +typedef xc_interface xendevicemodel_handle; > > > > > > > + > > > > > > > +#define xendevicemodel_open(l, f) xen_xc > > > > > > > + > > > > > > > +#define xendevicemodel_map_io_range_to_ioreq_server \ > > > > > > > +xc_hvm_map_io_range_to_ioreq_server > > > > > > > +#define xendevicemodel_unmap_io_range_from_ioreq_server \ > > > > > > > +xc_hvm_unmap_io_range_from_ioreq_server > > > > > > > +#define xendevicemodel_map_pcidev_to_ioreq_server \ > > > > > > > +xc_hvm_map_pcidev_to_ioreq_server > > > > > > > +#define xendevicemodel_unmap_pcidev_from_ioreq_server \ > > > > > > > +xc_hvm_unmap_pcidev_from_ioreq_server > > > > > &
Re: [Qemu-devel] [PATCH v2 5/5] xen: use libxendevicemodel when available
On Fri, 3 Mar 2017, Stefano Stabellini wrote: > On Fri, 3 Mar 2017, Paul Durrant wrote: > > > -Original Message- > > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > > Sent: 02 March 2017 22:50 > > > To: Paul Durrant > > > Cc: xen-de...@lists.xenproject.org; qemu-devel@nongnu.org; Stefano > > > Stabellini ; Anthony Perard > > > > > > Subject: Re: [PATCH v2 5/5] xen: use libxendevicemodel when available > > > > > > On Thu, 2 Mar 2017, Paul Durrant wrote: > > > > This patch modifies the wrapper functions in xen_common.h to use the > > > > new xendevicemodel interface if it is available along with compatibility > > > > code to use the old libxenctrl interface if it is not. > > > > > > > > Signed-off-by: Paul Durrant > > > > --- > > > > Cc: Stefano Stabellini > > > > Cc: Anthony Perard > > > > > > > > v2: > > > > - Add a compat define for xenforeignmemory_close() since this is now > > > > used. > > > > --- > > > > include/hw/xen/xen_common.h | 115 > > > +++- > > > > xen-common.c| 8 +++ > > > > 2 files changed, 90 insertions(+), 33 deletions(-) > > > > > > > > diff --git a/include/hw/xen/xen_common.h > > > b/include/hw/xen/xen_common.h > > > > index 31cf25f..48444e5 100644 > > > > --- a/include/hw/xen/xen_common.h > > > > +++ b/include/hw/xen/xen_common.h > > > > @@ -9,6 +9,7 @@ > > > > #undef XC_WANT_COMPAT_EVTCHN_API > > > > #undef XC_WANT_COMPAT_GNTTAB_API > > > > #undef XC_WANT_COMPAT_MAP_FOREIGN_API > > > > +#undef XC_WANT_COMPAT_DEVICEMODEL_API > > > > > > > > #include > > > > #include > > > > @@ -26,48 +27,95 @@ extern xc_interface *xen_xc; > > > > * We don't support Xen prior to 4.2.0. > > > > */ > > > > > > > > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490 > > > > + > > > > +typedef xc_interface xendevicemodel_handle; > > > > + > > > > +#define xendevicemodel_open(l, f) xen_xc > > > > + > > > > +#define xendevicemodel_map_io_range_to_ioreq_server \ > > > > +xc_hvm_map_io_range_to_ioreq_server > > > > +#define xendevicemodel_unmap_io_range_from_ioreq_server \ > > > > +xc_hvm_unmap_io_range_from_ioreq_server > > > > +#define xendevicemodel_map_pcidev_to_ioreq_server \ > > > > +xc_hvm_map_pcidev_to_ioreq_server > > > > +#define xendevicemodel_unmap_pcidev_from_ioreq_server \ > > > > +xc_hvm_unmap_pcidev_from_ioreq_server > > > > +#define xendevicemodel_create_ioreq_server \ > > > > +xc_hvm_create_ioreq_server > > > > +#define xendevicemodel_destroy_ioreq_server \ > > > > +xc_hvm_destroy_ioreq_server > > > > +#define xendevicemodel_get_ioreq_server_info \ > > > > +xc_hvm_get_ioreq_server_info > > > > +#define xendevicemodel_set_ioreq_server_state \ > > > > +xc_hvm_set_ioreq_server_state > > > > +#define xendevicemodel_set_pci_intx_level \ > > > > +xc_hvm_set_pci_intx_level > > > > +#define xendevicemodel_set_pci_link_route \ > > > > +xc_hvm_set_pci_link_route > > > > +#define xendevicemodel_set_isa_irq_level \ > > > > +xc_hvm_set_isa_irq_level > > > > +#define xendevicemodel_inject_msi \ > > > > +xc_hvm_inject_msi > > > > +#define xendevicemodel_set_mem_type \ > > > > +xc_hvm_set_mem_type > > > > +#define xendevicemodel_track_dirty_vram \ > > > > +xc_hvm_track_dirty_vram > > > > +#define xendevicemodel_modified_memory \ > > > > +xc_hvm_modified_memory > > > > > > It does build correctly now for Xen < 4.9, however it breaks against > > > xen-unstable: > > > > > > ERROR: configure test passed without -Werror but failed with -Werror. > > > This is probably a bug in the configure script. The failing > > > command > > > will be at the bottom of config.log. > > > You can run configure with --disable-werror to bypass this check. > > > > > > and config.log says: > > > > > > config-temp/qemu-conf.c: In function 'main': > > > config-temp/qemu-c
Re: [Qemu-devel] [PATCH v2 5/5] xen: use libxendevicemodel when available
On Fri, 3 Mar 2017, Paul Durrant wrote: > > -Original Message- > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > Sent: 02 March 2017 22:50 > > To: Paul Durrant > > Cc: xen-de...@lists.xenproject.org; qemu-devel@nongnu.org; Stefano > > Stabellini ; Anthony Perard > > > > Subject: Re: [PATCH v2 5/5] xen: use libxendevicemodel when available > > > > On Thu, 2 Mar 2017, Paul Durrant wrote: > > > This patch modifies the wrapper functions in xen_common.h to use the > > > new xendevicemodel interface if it is available along with compatibility > > > code to use the old libxenctrl interface if it is not. > > > > > > Signed-off-by: Paul Durrant > > > --- > > > Cc: Stefano Stabellini > > > Cc: Anthony Perard > > > > > > v2: > > > - Add a compat define for xenforeignmemory_close() since this is now > > > used. > > > --- > > > include/hw/xen/xen_common.h | 115 > > +++- > > > xen-common.c| 8 +++ > > > 2 files changed, 90 insertions(+), 33 deletions(-) > > > > > > diff --git a/include/hw/xen/xen_common.h > > b/include/hw/xen/xen_common.h > > > index 31cf25f..48444e5 100644 > > > --- a/include/hw/xen/xen_common.h > > > +++ b/include/hw/xen/xen_common.h > > > @@ -9,6 +9,7 @@ > > > #undef XC_WANT_COMPAT_EVTCHN_API > > > #undef XC_WANT_COMPAT_GNTTAB_API > > > #undef XC_WANT_COMPAT_MAP_FOREIGN_API > > > +#undef XC_WANT_COMPAT_DEVICEMODEL_API > > > > > > #include > > > #include > > > @@ -26,48 +27,95 @@ extern xc_interface *xen_xc; > > > * We don't support Xen prior to 4.2.0. > > > */ > > > > > > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490 > > > + > > > +typedef xc_interface xendevicemodel_handle; > > > + > > > +#define xendevicemodel_open(l, f) xen_xc > > > + > > > +#define xendevicemodel_map_io_range_to_ioreq_server \ > > > +xc_hvm_map_io_range_to_ioreq_server > > > +#define xendevicemodel_unmap_io_range_from_ioreq_server \ > > > +xc_hvm_unmap_io_range_from_ioreq_server > > > +#define xendevicemodel_map_pcidev_to_ioreq_server \ > > > +xc_hvm_map_pcidev_to_ioreq_server > > > +#define xendevicemodel_unmap_pcidev_from_ioreq_server \ > > > +xc_hvm_unmap_pcidev_from_ioreq_server > > > +#define xendevicemodel_create_ioreq_server \ > > > +xc_hvm_create_ioreq_server > > > +#define xendevicemodel_destroy_ioreq_server \ > > > +xc_hvm_destroy_ioreq_server > > > +#define xendevicemodel_get_ioreq_server_info \ > > > +xc_hvm_get_ioreq_server_info > > > +#define xendevicemodel_set_ioreq_server_state \ > > > +xc_hvm_set_ioreq_server_state > > > +#define xendevicemodel_set_pci_intx_level \ > > > +xc_hvm_set_pci_intx_level > > > +#define xendevicemodel_set_pci_link_route \ > > > +xc_hvm_set_pci_link_route > > > +#define xendevicemodel_set_isa_irq_level \ > > > +xc_hvm_set_isa_irq_level > > > +#define xendevicemodel_inject_msi \ > > > +xc_hvm_inject_msi > > > +#define xendevicemodel_set_mem_type \ > > > +xc_hvm_set_mem_type > > > +#define xendevicemodel_track_dirty_vram \ > > > +xc_hvm_track_dirty_vram > > > +#define xendevicemodel_modified_memory \ > > > +xc_hvm_modified_memory > > > > It does build correctly now for Xen < 4.9, however it breaks against > > xen-unstable: > > > > ERROR: configure test passed without -Werror but failed with -Werror. > > This is probably a bug in the configure script. The failing command > > will be at the bottom of config.log. > > You can run configure with --disable-werror to bypass this check. > > > > and config.log says: > > > > config-temp/qemu-conf.c: In function 'main': > > config-temp/qemu-conf.c:32:3: error: implicit declaration of function > > 'xc_hvm_set_mem_type' [-Werror=implicit-function-declaration] > > config-temp/qemu-conf.c:32:3: error: nested extern declaration of > > 'xc_hvm_set_mem_type' [-Werror=nested-externs] > > config-temp/qemu-conf.c:34:3: error: implicit declaration of function > > 'xc_hvm_inject_msi' [-Werror=implicit-function-declaration] > > config-temp/qemu-conf.c:34:3: error: nested extern declaration of > > 'xc_hvm_inj
Re: [Qemu-devel] [PATCH v2 5/5] xen: use libxendevicemodel when available
On Thu, 2 Mar 2017, Paul Durrant wrote: > This patch modifies the wrapper functions in xen_common.h to use the > new xendevicemodel interface if it is available along with compatibility > code to use the old libxenctrl interface if it is not. > > Signed-off-by: Paul Durrant > --- > Cc: Stefano Stabellini > Cc: Anthony Perard > > v2: > - Add a compat define for xenforeignmemory_close() since this is now > used. > --- > include/hw/xen/xen_common.h | 115 > +++- > xen-common.c| 8 +++ > 2 files changed, 90 insertions(+), 33 deletions(-) > > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h > index 31cf25f..48444e5 100644 > --- a/include/hw/xen/xen_common.h > +++ b/include/hw/xen/xen_common.h > @@ -9,6 +9,7 @@ > #undef XC_WANT_COMPAT_EVTCHN_API > #undef XC_WANT_COMPAT_GNTTAB_API > #undef XC_WANT_COMPAT_MAP_FOREIGN_API > +#undef XC_WANT_COMPAT_DEVICEMODEL_API > > #include > #include > @@ -26,48 +27,95 @@ extern xc_interface *xen_xc; > * We don't support Xen prior to 4.2.0. > */ > > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490 > + > +typedef xc_interface xendevicemodel_handle; > + > +#define xendevicemodel_open(l, f) xen_xc > + > +#define xendevicemodel_map_io_range_to_ioreq_server \ > +xc_hvm_map_io_range_to_ioreq_server > +#define xendevicemodel_unmap_io_range_from_ioreq_server \ > +xc_hvm_unmap_io_range_from_ioreq_server > +#define xendevicemodel_map_pcidev_to_ioreq_server \ > +xc_hvm_map_pcidev_to_ioreq_server > +#define xendevicemodel_unmap_pcidev_from_ioreq_server \ > +xc_hvm_unmap_pcidev_from_ioreq_server > +#define xendevicemodel_create_ioreq_server \ > +xc_hvm_create_ioreq_server > +#define xendevicemodel_destroy_ioreq_server \ > +xc_hvm_destroy_ioreq_server > +#define xendevicemodel_get_ioreq_server_info \ > +xc_hvm_get_ioreq_server_info > +#define xendevicemodel_set_ioreq_server_state \ > +xc_hvm_set_ioreq_server_state > +#define xendevicemodel_set_pci_intx_level \ > +xc_hvm_set_pci_intx_level > +#define xendevicemodel_set_pci_link_route \ > +xc_hvm_set_pci_link_route > +#define xendevicemodel_set_isa_irq_level \ > +xc_hvm_set_isa_irq_level > +#define xendevicemodel_inject_msi \ > +xc_hvm_inject_msi > +#define xendevicemodel_set_mem_type \ > +xc_hvm_set_mem_type > +#define xendevicemodel_track_dirty_vram \ > +xc_hvm_track_dirty_vram > +#define xendevicemodel_modified_memory \ > +xc_hvm_modified_memory It does build correctly now for Xen < 4.9, however it breaks against xen-unstable: ERROR: configure test passed without -Werror but failed with -Werror. This is probably a bug in the configure script. The failing command will be at the bottom of config.log. You can run configure with --disable-werror to bypass this check. and config.log says: config-temp/qemu-conf.c: In function 'main': config-temp/qemu-conf.c:32:3: error: implicit declaration of function 'xc_hvm_set_mem_type' [-Werror=implicit-function-declaration] config-temp/qemu-conf.c:32:3: error: nested extern declaration of 'xc_hvm_set_mem_type' [-Werror=nested-externs] config-temp/qemu-conf.c:34:3: error: implicit declaration of function 'xc_hvm_inject_msi' [-Werror=implicit-function-declaration] config-temp/qemu-conf.c:34:3: error: nested extern declaration of 'xc_hvm_inject_msi' [-Werror=nested-externs] config-temp/qemu-conf.c:35:3: error: implicit declaration of function 'xc_hvm_create_ioreq_server' [-Werror=implicit-function-declaration] config-temp/qemu-conf.c:35:3: error: nested extern declaration of 'xc_hvm_create_ioreq_server' [-Werror=nested-externs] With -DXC_WANT_COMPAT_DEVICEMODEL_API=1: In file included from /local/qemu-upstream/include/hw/xen/xen_backend.h:4:0, from hw/block/xen_disk.c:27: /local/qemu-upstream/include/hw/xen/xen_common.h: In function 'xen_set_mem_type': /local/qemu-upstream/include/hw/xen/xen_common.h:78:5: error: implicit declaration of function 'xc_hvm_set_mem_type' [-Werror=implicit-function-declaration] Only another comment (I guess you didn't see in my previous email): could you please use static inline functions for compatibility rather than macros? That way we are going to have some more compile time checks. Or at least macros with parameters. > +#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 490 */ > + > +#include > + > +#endif > + > +extern xendevicemodel_handle *xen_dmod; > + > static inline int xen_set_mem_type(domid_t domid, hvmmem_type_t type, > uint64_t first_pfn, uint
Re: [Qemu-devel] [PATCH 5/5] xen: use libxendevicemodel when available
On Thu, 23 Feb 2017, Paul Durrant wrote: > This patch modifies the wrapper functions in xen_common.h to use the > new xendevicemodel interface if it is available along with compatibility > code to use the old libxenctrl interface if it is not. > > Signed-off-by: Paul Durrant Hi Paul, Sorry for the late reply, I am flooded with patches over here. Aside from Anthony's comments, the other patches of this series look good to me. The Xen side patches are not in, are they? Do you have a Xen git branch with them so that I can test this patch properly? This patch breaks the build against Xen >= 4.3, with: /local/qemu-upstream/xen-common.c: In function 'xen_init': /local/qemu-upstream/xen-common.c:135:9: error: implicit declaration of function 'xenforeignmemory_close' [-Werror=implicit-function-declaration] /local/qemu-upstream/xen-common.c:135:9: error: nested extern declaration of 'xenforeignmemory_close' [-Werror=nested-externs] cc1: all warnings being treated as errors > Cc: Stefano Stabellini > Cc: Anthony Perard > --- > include/hw/xen/xen_common.h | 114 > +++- > xen-common.c| 8 > 2 files changed, 89 insertions(+), 33 deletions(-) > > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h > index 31cf25f..2c2a61b 100644 > --- a/include/hw/xen/xen_common.h > +++ b/include/hw/xen/xen_common.h > @@ -9,6 +9,7 @@ > #undef XC_WANT_COMPAT_EVTCHN_API > #undef XC_WANT_COMPAT_GNTTAB_API > #undef XC_WANT_COMPAT_MAP_FOREIGN_API > +#undef XC_WANT_COMPAT_DEVICEMODEL_API > > #include > #include > @@ -26,48 +27,95 @@ extern xc_interface *xen_xc; > * We don't support Xen prior to 4.2.0. > */ > > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490 > + > +typedef xc_interface xendevicemodel_handle; > + > +#define xendevicemodel_open(l, f) xen_xc > + > +#define xendevicemodel_map_io_range_to_ioreq_server \ Could you please use static inline functions for compatibility rather than macros? That way we are going to have some more compile time checks. Or at least macros with parameters. > +xc_hvm_map_io_range_to_ioreq_server > +#define xendevicemodel_unmap_io_range_from_ioreq_server \ > +xc_hvm_unmap_io_range_from_ioreq_server > +#define xendevicemodel_map_pcidev_to_ioreq_server \ > +xc_hvm_map_pcidev_to_ioreq_server > +#define xendevicemodel_unmap_pcidev_from_ioreq_server \ > +xc_hvm_unmap_pcidev_from_ioreq_server > +#define xendevicemodel_create_ioreq_server \ > +xc_hvm_create_ioreq_server > +#define xendevicemodel_destroy_ioreq_server \ > +xc_hvm_destroy_ioreq_server > +#define xendevicemodel_get_ioreq_server_info \ > +xc_hvm_get_ioreq_server_info > +#define xendevicemodel_set_ioreq_server_state \ > +xc_hvm_set_ioreq_server_state > +#define xendevicemodel_set_pci_intx_level \ > +xc_hvm_set_pci_intx_level > +#define xendevicemodel_set_pci_link_route \ > +xc_hvm_set_pci_link_route > +#define xendevicemodel_set_isa_irq_level \ > +xc_hvm_set_isa_irq_level > +#define xendevicemodel_inject_msi \ > +xc_hvm_inject_msi > +#define xendevicemodel_set_mem_type \ > +xc_hvm_set_mem_type > +#define xendevicemodel_track_dirty_vram \ > +xc_hvm_track_dirty_vram > +#define xendevicemodel_modified_memory \ > +xc_hvm_modified_memory > + > +#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 490 */ > + > +#include > + > +#endif > + > +extern xendevicemodel_handle *xen_dmod; > + > static inline int xen_set_mem_type(domid_t domid, hvmmem_type_t type, > uint64_t first_pfn, uint32_t nr) > { > -return xc_hvm_set_mem_type(xen_xc, domid, type, first_pfn, nr); > +return xendevicemodel_set_mem_type(xen_dmod, domid, type, first_pfn, > + nr); > } > > static inline int xen_set_pci_intx_level(domid_t domid, uint16_t segment, > uint8_t bus, uint8_t device, > uint8_t intx, unsigned int level) > { > -return xc_hvm_set_pci_intx_level(xen_xc, domid, segment, bus, device, > - intx, level); > +return xendevicemodel_set_pci_intx_level(xen_dmod, domid, segment, bus, > + device, intx, level); > } > > static inline int xen_set_pci_link_route(domid_t domid, uint8_t link, > uint8_t irq) > { > -return xc_hvm_set_pci_link_route(xen_xc, domid, link, irq); > +return xendevicemodel_set_pci_link_route(xen_dmod, domid, link, irq); > } > > st
[Qemu-devel] [PULL 0/2] tags/xen-20170228-tag
The following changes since commit 7d1730b7d9d8272a13245adfc9b0405e5a4bd0c2: Merge remote-tracking branch 'remotes/mjt/tags/trivial-patches-fetch' into staging (2017-02-28 16:22:41 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170228-tag for you to fetch changes up to daa33c52153df48ef0a7d06013f8ca6f24eff92f: Add a new qmp command to do checkpoint, query xen replication status (2017-02-28 11:02:12 -0800) Xen 2017/02/28 Zhang Chen (2): Add a new qmp command to start/stop replication Add a new qmp command to do checkpoint, query xen replication status migration/colo.c | 49 + qapi-schema.json | 73 2 files changed, 122 insertions(+)
[Qemu-devel] [PULL 1/2] Add a new qmp command to start/stop replication
From: Zhang Chen We can call this qmp command to start/stop replication outside of qemu. Like Xen colo need this function. Signed-off-by: Zhang Chen Signed-off-by: Wen Congyang Reviewed-by: Eric Blake Reviewed-by: Stefano Stabellini Reviewed-by: zhanghailiang Signed-off-by: Stefano Stabellini --- migration/colo.c | 26 ++ qapi-schema.json | 25 + 2 files changed, 51 insertions(+) diff --git a/migration/colo.c b/migration/colo.c index 712308e..46bc84d 100644 --- a/migration/colo.c +++ b/migration/colo.c @@ -19,6 +19,8 @@ #include "qemu/error-report.h" #include "qapi/error.h" #include "migration/failover.h" +#include "replication.h" +#include "qmp-commands.h" static bool vmstate_loading; @@ -147,6 +149,30 @@ void colo_do_failover(MigrationState *s) } } +void qmp_xen_set_replication(bool enable, bool primary, + bool has_failover, bool failover, + Error **errp) +{ +ReplicationMode mode = primary ? + REPLICATION_MODE_PRIMARY : + REPLICATION_MODE_SECONDARY; + +if (has_failover && enable) { +error_setg(errp, "Parameter 'failover' is only for" + " stopping replication"); +return; +} + +if (enable) { +replication_start_all(mode, errp); +} else { +if (!has_failover) { +failover = NULL; +} +replication_stop_all(failover, failover ? NULL : errp); +} +} + static void colo_send_message(QEMUFile *f, COLOMessage msg, Error **errp) { diff --git a/qapi-schema.json b/qapi-schema.json index 150ee98..dbc1ebc 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -5990,6 +5990,31 @@ { 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} } ## +# @xen-set-replication: +# +# Enable or disable replication. +# +# @enable: true to enable, false to disable. +# +# @primary: true for primary or false for secondary. +# +# @failover: #optional true to do failover, false to stop. but cannot be +#specified if 'enable' is true. default value is false. +# +# Returns: nothing. +# +# Example: +# +# -> { "execute": "xen-set-replication", +# "arguments": {"enable": true, "primary": false} } +# <- { "return": {} } +# +# Since: 2.9 +## +{ 'command': 'xen-set-replication', + 'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } } + +## # @GICCapability: # # The struct describes capability for a specific GIC (Generic -- 1.9.1
[Qemu-devel] [PULL 2/2] Add a new qmp command to do checkpoint, query xen replication status
From: Zhang Chen We can call this qmp command to do checkpoint outside of qemu. Xen colo will need this function. Signed-off-by: Zhang Chen Signed-off-by: Wen Congyang Reviewed-by: Eric Blake Signed-off-by: Stefano Stabellini --- migration/colo.c | 23 +++ qapi-schema.json | 48 2 files changed, 71 insertions(+) diff --git a/migration/colo.c b/migration/colo.c index 46bc84d..c19eb3f 100644 --- a/migration/colo.c +++ b/migration/colo.c @@ -173,6 +173,29 @@ void qmp_xen_set_replication(bool enable, bool primary, } } +ReplicationStatus *qmp_query_xen_replication_status(Error **errp) +{ +Error *err = NULL; +ReplicationStatus *s = g_new0(ReplicationStatus, 1); + +replication_get_error_all(&err); +if (err) { +s->error = true; +s->has_desc = true; +s->desc = g_strdup(error_get_pretty(err)); +} else { +s->error = false; +} + +error_free(err); +return s; +} + +void qmp_xen_colo_do_checkpoint(Error **errp) +{ +replication_do_checkpoint_all(errp); +} + static void colo_send_message(QEMUFile *f, COLOMessage msg, Error **errp) { diff --git a/qapi-schema.json b/qapi-schema.json index dbc1ebc..d6186d4 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -6015,6 +6015,54 @@ 'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } } ## +# @ReplicationStatus: +# +# The result format for 'query-xen-replication-status'. +# +# @error: true if an error happened, false if replication is normal. +# +# @desc: #optional the human readable error description string, when +#@error is 'true'. +# +# Since: 2.9 +## +{ 'struct': 'ReplicationStatus', + 'data': { 'error': 'bool', '*desc': 'str' } } + +## +# @query-xen-replication-status: +# +# Query replication status while the vm is running. +# +# Returns: A @ReplicationResult object showing the status. +# +# Example: +# +# -> { "execute": "query-xen-replication-status" } +# <- { "return": { "error": false } } +# +# Since: 2.9 +## +{ 'command': 'query-xen-replication-status', + 'returns': 'ReplicationStatus' } + +## +# @xen-colo-do-checkpoint: +# +# Xen uses this command to notify replication to trigger a checkpoint. +# +# Returns: nothing. +# +# Example: +# +# -> { "execute": "xen-colo-do-checkpoint" } +# <- { "return": {} } +# +# Since: 2.9 +## +{ 'command': 'xen-colo-do-checkpoint' } + +## # @GICCapability: # # The struct describes capability for a specific GIC (Generic -- 1.9.1
Re: [Qemu-devel] [PATCH V10 0/2] Add new qmp commands to suppurt Xen COLO
On Mon, 27 Feb 2017, Eric Blake wrote: > On 02/27/2017 04:31 PM, Stefano Stabellini wrote: > > Eric, are you OK with this series going upstream? If so, do you want me > > to send the pull request for it or are you going to handle it? > > Both patches have my R-b, but MAINTAINERS suggests the pull request > should go through COLO Framework (zhanghailiang) or maybe Xen (you). I am fine either way. zhanghailiang?
Re: [Qemu-devel] [PATCH V10 0/2] Add new qmp commands to suppurt Xen COLO
Eric, are you OK with this series going upstream? If so, do you want me to send the pull request for it or are you going to handle it? On Sat, 25 Feb 2017, Zhang Chen wrote: > Xen COLO depend on qemu COLO replication function. > So, We need new qmp commands for Xen to use qemu replication. > > Corresponding libxl patches already in xen.git. > Commit ID: > > ed37ef1f91c20f0ab162ce60f8c38400b917fa64 > COLO: introduce new API to prepare/start/do/get_error/stop replication > > a0ddc0b359375b2418213966dfbdbfab593ecc6f > tools/libxl: introduction of libxl__qmp_restore to load qemu state > > V10: >- Fix ReplicationStatus error comments. >- Fix query-xen-replication-status example. > > Zhang Chen (2): > Add a new qmp command to start/stop replication > Add a new qmp command to do checkpoint, query xen replication status > > migration/colo.c | 49 + > qapi-schema.json | 73 > > 2 files changed, 122 insertions(+) > > -- > 2.7.4 > > >
Re: [Qemu-devel] [PATCH V7 2/2] Add a new qmp command to do checkpoint, query xen replication status
On Wed, 8 Feb 2017, Eric Blake wrote: > On 02/07/2017 11:24 PM, Zhang Chen wrote: > > We can call this qmp command to do checkpoint outside of qemu. > > Xen colo will need this function. > > > > Signed-off-by: Zhang Chen > > Signed-off-by: Wen Congyang > > --- > > migration/colo.c | 17 > > qapi-schema.json | 60 > > > > 2 files changed, 77 insertions(+) > > > > Reviewed-by: Eric Blake Given that the series is all acked, are you going to take care of the pull request?
[Qemu-devel] [PULL 2/5] xen-platform: add support for unplugging NVMe disks...
From: Paul Durrant ...not just IDE and SCSI. This patch allows the Xen tool-stack to fully support of NVMe as an emulated disk type. See [1] for the relevant tool-stack patch discussion. [1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg01225.html Signed-off-by: Paul Durrant Reviewed-by: Stefano Stabellini --- hw/i386/xen/xen_platform.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c index f50915f..7d41ebb 100644 --- a/hw/i386/xen/xen_platform.c +++ b/hw/i386/xen/xen_platform.c @@ -120,6 +120,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) break; case PCI_CLASS_STORAGE_SCSI: +case PCI_CLASS_STORAGE_EXPRESS: object_unparent(OBJECT(d)); break; -- 1.9.1
[Qemu-devel] [PULL 4/5] MAINTAINERS: Update xen-devel mailing list address
From: Anthony PERARD Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a428cb2..baea7c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -323,7 +323,7 @@ Guest CPU Cores (Xen): X86 M: Stefano Stabellini M: Anthony Perard -L: xen-de...@lists.xensource.com +L: xen-de...@lists.xenproject.org S: Supported F: xen-* F: */xen* -- 1.9.1
[Qemu-devel] [PULL 1/5] xen-platform: re-structure unplug_disks
From: Paul Durrant The current code is poorly structured and potentially leads to multiple config space reads when one is sufficient. Also the UNPLUG_ALL_IDE_DISKS flag is mis-named since it also results in SCSI disks being unplugged. This patch renames the flag and re-structures the code to be more efficient, and readable. Signed-off-by: Paul Durrant Reviewed-by: Stefano Stabellini --- hw/i386/xen/xen_platform.c | 25 - 1 file changed, 16 insertions(+), 9 deletions(-) diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c index 2e1e543..f50915f 100644 --- a/hw/i386/xen/xen_platform.c +++ b/hw/i386/xen/xen_platform.c @@ -88,7 +88,7 @@ static void log_writeb(PCIXenPlatformState *s, char val) } /* Xen Platform, Fixed IOPort */ -#define UNPLUG_ALL_IDE_DISKS 1 +#define UNPLUG_ALL_DISKS 1 #define UNPLUG_ALL_NICS 2 #define UNPLUG_AUX_IDE_DISKS 4 @@ -110,14 +110,21 @@ static void pci_unplug_nics(PCIBus *bus) static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) { /* We have to ignore passthrough devices */ -if (pci_get_word(d->config + PCI_CLASS_DEVICE) == -PCI_CLASS_STORAGE_IDE -&& strcmp(d->name, "xen-pci-passthrough") != 0) { +if (!strcmp(d->name, "xen-pci-passthrough")) { +return; +} + +switch (pci_get_word(d->config + PCI_CLASS_DEVICE)) { +case PCI_CLASS_STORAGE_IDE: pci_piix3_xen_ide_unplug(DEVICE(d)); -} else if (pci_get_word(d->config + PCI_CLASS_DEVICE) == -PCI_CLASS_STORAGE_SCSI -&& strcmp(d->name, "xen-pci-passthrough") != 0) { +break; + +case PCI_CLASS_STORAGE_SCSI: object_unparent(OBJECT(d)); +break; + +default: +break; } } @@ -134,9 +141,9 @@ static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t v case 0: { PCIDevice *pci_dev = PCI_DEVICE(s); /* Unplug devices. Value is a bitmask of which devices to - unplug, with bit 0 the IDE devices, bit 1 the network + unplug, with bit 0 the disk devices, bit 1 the network devices, and bit 2 the non-primary-master IDE devices. */ -if (val & UNPLUG_ALL_IDE_DISKS) { +if (val & UNPLUG_ALL_DISKS) { DPRINTF("unplug disks\n"); pci_unplug_disks(pci_dev->bus); } -- 1.9.1
[Qemu-devel] [PULL 5/5] xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev()
From: Juergen Gross The error exits of xen_pv_find_xendev() free the new xen-device via g_free() which is wrong. As the xen-device has been initialized as qdev it must be removed via qdev_unplug(). This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6 ("xen: create qdev for each backend device"). Reported-by: Roger Pau Monné Tested-by: Roger Pau Monné Signed-off-by: Juergen Gross Reviewed-by: Stefano Stabellini --- hw/xen/xen_backend.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index d119004..6c21c37 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -124,10 +124,11 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev, /* init new xendev */ xendev = g_malloc0(ops->size); object_initialize(&xendev->qdev, ops->size, TYPE_XENBACKEND); -qdev_set_parent_bus(&xendev->qdev, xen_sysbus); -qdev_set_id(&xendev->qdev, g_strdup_printf("xen-%s-%d", type, dev)); -qdev_init_nofail(&xendev->qdev); -object_unref(OBJECT(&xendev->qdev)); +OBJECT(xendev)->free = g_free; +qdev_set_parent_bus(DEVICE(xendev), xen_sysbus); +qdev_set_id(DEVICE(xendev), g_strdup_printf("xen-%s-%d", type, dev)); +qdev_init_nofail(DEVICE(xendev)); +object_unref(OBJECT(xendev)); xendev->type = type; xendev->dom = dom; @@ -145,7 +146,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev, xendev->evtchndev = xenevtchn_open(NULL, 0); if (xendev->evtchndev == NULL) { xen_pv_printf(NULL, 0, "can't open evtchn device\n"); -g_free(xendev); +qdev_unplug(DEVICE(xendev), NULL); return NULL; } fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC); @@ -155,7 +156,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev, if (xendev->gnttabdev == NULL) { xen_pv_printf(NULL, 0, "can't open gnttab device\n"); xenevtchn_close(xendev->evtchndev); -g_free(xendev); +qdev_unplug(DEVICE(xendev), NULL); return NULL; } } else { -- 1.9.1
[Qemu-devel] [PULL 3/5] xen-platform: add missing disk unplug option
From: Paul Durrant The Xen HVM unplug protocol [1] specifies a mechanism to allow guests to request unplug of 'aux' disks (which is stated to mean all IDE disks, except the primary master). This patch adds support for that unplug request. NOTE: The semantics of what happens if unplug of all disks and 'aux' disks is simultaneously requests is not clear. The patch makes that assumption that an 'all' request overrides an 'aux' request. [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/hvm-emulated-unplug.markdown Signed-off-by: Paul Durrant Reviewed-by: Stefano Stabellini Cc: Stefano Stabellini Cc: Anthony Perard Cc: Paolo Bonzini Cc: Richard Henderson Cc: Eduardo Habkost Cc: "Michael S. Tsirkin" Cc: John Snow --- hw/i386/xen/xen_platform.c | 27 +++ hw/ide/piix.c | 4 ++-- include/hw/ide.h | 2 +- 3 files changed, 18 insertions(+), 15 deletions(-) diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c index 7d41ebb..6010f35 100644 --- a/hw/i386/xen/xen_platform.c +++ b/hw/i386/xen/xen_platform.c @@ -107,8 +107,12 @@ static void pci_unplug_nics(PCIBus *bus) pci_for_each_device(bus, 0, unplug_nic, NULL); } -static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) +static void unplug_disks(PCIBus *b, PCIDevice *d, void *opaque) { +uint32_t flags = *(uint32_t *)opaque; +bool aux = (flags & UNPLUG_AUX_IDE_DISKS) && +!(flags & UNPLUG_ALL_DISKS); + /* We have to ignore passthrough devices */ if (!strcmp(d->name, "xen-pci-passthrough")) { return; @@ -116,12 +120,14 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) switch (pci_get_word(d->config + PCI_CLASS_DEVICE)) { case PCI_CLASS_STORAGE_IDE: -pci_piix3_xen_ide_unplug(DEVICE(d)); +pci_piix3_xen_ide_unplug(DEVICE(d), aux); break; case PCI_CLASS_STORAGE_SCSI: case PCI_CLASS_STORAGE_EXPRESS: -object_unparent(OBJECT(d)); +if (!aux) { +object_unparent(OBJECT(d)); +} break; default: @@ -129,9 +135,9 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) } } -static void pci_unplug_disks(PCIBus *bus) +static void pci_unplug_disks(PCIBus *bus, uint32_t flags) { -pci_for_each_device(bus, 0, unplug_disks, NULL); +pci_for_each_device(bus, 0, unplug_disks, &flags); } static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t val) @@ -144,17 +150,14 @@ static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, uint32_t v /* Unplug devices. Value is a bitmask of which devices to unplug, with bit 0 the disk devices, bit 1 the network devices, and bit 2 the non-primary-master IDE devices. */ -if (val & UNPLUG_ALL_DISKS) { +if (val & (UNPLUG_ALL_DISKS | UNPLUG_AUX_IDE_DISKS)) { DPRINTF("unplug disks\n"); -pci_unplug_disks(pci_dev->bus); +pci_unplug_disks(pci_dev->bus, val); } if (val & UNPLUG_ALL_NICS) { DPRINTF("unplug nics\n"); pci_unplug_nics(pci_dev->bus); } -if (val & UNPLUG_AUX_IDE_DISKS) { -DPRINTF("unplug auxiliary disks not supported\n"); -} break; } case 2: @@ -335,14 +338,14 @@ static void xen_platform_ioport_writeb(void *opaque, hwaddr addr, * If VMDP was to control both disk and LAN it would use 4. * If it controlled just disk or just LAN, it would use 8 below. */ -pci_unplug_disks(pci_dev->bus); +pci_unplug_disks(pci_dev->bus, UNPLUG_ALL_DISKS); pci_unplug_nics(pci_dev->bus); } break; case 8: switch (val) { case 1: -pci_unplug_disks(pci_dev->bus); +pci_unplug_disks(pci_dev->bus, UNPLUG_ALL_DISKS); break; case 2: pci_unplug_nics(pci_dev->bus); diff --git a/hw/ide/piix.c b/hw/ide/piix.c index d5777fd..7e2d767 100644 --- a/hw/ide/piix.c +++ b/hw/ide/piix.c @@ -165,7 +165,7 @@ static void pci_piix_ide_realize(PCIDevice *dev, Error **errp) pci_piix_init_ports(d); } -int pci_piix3_xen_ide_unplug(DeviceState *dev) +int pci_piix3_xen_ide_unplug(DeviceState *dev, bool aux) { PCIIDEState *pci_ide; DriveInfo *di; @@ -174,7 +174,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev) pci_ide = PCI_IDE(dev); -for (i = 0; i < 4; i++) { +for (i = aux ? 1 : 0; i < 4; i++) { di = drive_get_by_index(IF_IDE, i); if (di != NULL && !di->media_cd) { BlockBackend *blk = blk_by_legacy_dinfo(di); diff --git a/include/hw/ide.h b/include/hw/ide.h index bc8bd32..3ae087c 1
[Qemu-devel] [PULL 0/5] xen-20170202
The following changes since commit 3aca12f841fcd6f3a7477076dad0d564360500de: Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20170127' into staging (2017-01-27 16:59:17 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170202 for you to fetch changes up to e9dcbc86d614018923e26e31319b0a54c9e5abac: xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev() (2017-02-02 10:23:53 -0800) Xen 2017/02/02 Anthony PERARD (1): MAINTAINERS: Update xen-devel mailing list address Juergen Gross (1): xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev() Paul Durrant (3): xen-platform: re-structure unplug_disks xen-platform: add support for unplugging NVMe disks... xen-platform: add missing disk unplug option MAINTAINERS| 2 +- hw/i386/xen/xen_platform.c | 51 -- hw/ide/piix.c | 4 ++-- hw/xen/xen_backend.c | 13 ++-- include/hw/ide.h | 2 +- 5 files changed, 42 insertions(+), 30 deletions(-)
Re: [Qemu-devel] [PATCH v2] xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev()
On Thu, 2 Feb 2017, Juergen Gross wrote: > On 01/02/17 21:20, Peter Maydell wrote: > > On 1 February 2017 at 19:37, Stefano Stabellini > > wrote: > >> Hi Peter, > >> > >> do you think this is acceptable? > > > > The set of operations here is basically what I suggested > > in review of v1, so I think it is the right thing. > > OTOH this is a bit of an odd corner of the QOM model > > so it might be worth doing some testing to make sure > > the reference counts are doing what you (I) expect and > > that the object does get correctly freed both in the > > error-handling path here and when the device is > > unplugged via xen_pv_del_xendev(). > > I've used my_g_free() printing a log message when called instead of > g_free() in a test. I could verify it has been called when the > device was unplugged. This test covered xen_pv_del_xendev() and > an error handling path. Thanks Juergen for testing. I'll commit shortly.
Re: [Qemu-devel] [PATCH v2] xen: use qdev_unplug() instead of g_free() in xen_pv_find_xendev()
Hi Peter, do you think this is acceptable? Thanks, Stefano On Wed, 1 Feb 2017, Juergen Gross wrote: > The error exits of xen_pv_find_xendev() free the new xen-device via > g_free() which is wrong. > > As the xen-device has been initialized as qdev it must be removed > via qdev_unplug(). > > This bug has been introduced with commit 3a6c9172ac5951e6dac2b3f6 > ("xen: create qdev for each backend device"). > > Reported-by: Roger Pau Monné > Tested-by: Roger Pau Monné > Signed-off-by: Juergen Gross > --- > V2: set free method to avoid memory leak (Peter Maydell) > use DEVICE(xendev) instead of &xendev->qdev (Peter Maydell) > --- > hw/xen/xen_backend.c | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c > index d119004..6c21c37 100644 > --- a/hw/xen/xen_backend.c > +++ b/hw/xen/xen_backend.c > @@ -124,10 +124,11 @@ static struct XenDevice *xen_be_get_xendev(const char > *type, int dom, int dev, > /* init new xendev */ > xendev = g_malloc0(ops->size); > object_initialize(&xendev->qdev, ops->size, TYPE_XENBACKEND); > -qdev_set_parent_bus(&xendev->qdev, xen_sysbus); > -qdev_set_id(&xendev->qdev, g_strdup_printf("xen-%s-%d", type, dev)); > -qdev_init_nofail(&xendev->qdev); > -object_unref(OBJECT(&xendev->qdev)); > +OBJECT(xendev)->free = g_free; > +qdev_set_parent_bus(DEVICE(xendev), xen_sysbus); > +qdev_set_id(DEVICE(xendev), g_strdup_printf("xen-%s-%d", type, dev)); > +qdev_init_nofail(DEVICE(xendev)); > +object_unref(OBJECT(xendev)); > > xendev->type = type; > xendev->dom = dom; > @@ -145,7 +146,7 @@ static struct XenDevice *xen_be_get_xendev(const char > *type, int dom, int dev, > xendev->evtchndev = xenevtchn_open(NULL, 0); > if (xendev->evtchndev == NULL) { > xen_pv_printf(NULL, 0, "can't open evtchn device\n"); > -g_free(xendev); > +qdev_unplug(DEVICE(xendev), NULL); > return NULL; > } > fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC); > @@ -155,7 +156,7 @@ static struct XenDevice *xen_be_get_xendev(const char > *type, int dom, int dev, > if (xendev->gnttabdev == NULL) { > xen_pv_printf(NULL, 0, "can't open gnttab device\n"); > xenevtchn_close(xendev->evtchndev); > -g_free(xendev); > +qdev_unplug(DEVICE(xendev), NULL); > return NULL; > } > } else { > -- > 2.10.2 >
Re: [Qemu-devel] [PATCH v3 2/3] xen-platform: add support for unplugging NVMe disks...
On Thu, 26 Jan 2017, Paul Durrant wrote: > ...not just IDE and SCSI. > > This patch allows the Xen tool-stack to fully support of NVMe as an > emulated disk type. See [1] for the relevant tool-stack patch discussion. > > [1] https://lists.xen.org/archives/html/xen-devel/2017-01/msg01225.html > > Signed-off-by: Paul Durrant Reviewed-by: Stefano Stabellini I queued the whole series. FYI I am waiting for another patch to fix a regression before sending a pull request. > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: "Michael S. Tsirkin" > Cc: Paolo Bonzini > Cc: Richard Henderson > Cc: Eduardo Habkost > > v3: > - Add reference to xen-devel patch discussion in commit message as > requested by Stefano. > --- > hw/i386/xen/xen_platform.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c > index f50915f..7d41ebb 100644 > --- a/hw/i386/xen/xen_platform.c > +++ b/hw/i386/xen/xen_platform.c > @@ -120,6 +120,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) > break; > > case PCI_CLASS_STORAGE_SCSI: > +case PCI_CLASS_STORAGE_EXPRESS: > object_unparent(OBJECT(d)); > break; > > -- > 2.1.4 >
Re: [Qemu-devel] [PATCH] MAINTAINERS: Update xen-devel mailing list address
On Wed, 25 Jan 2017, Anthony PERARD wrote: > On Mon, Nov 28, 2016 at 10:14:00AM -0800, Stefano Stabellini wrote: > > On Fri, 25 Nov 2016, Anthony PERARD wrote: > > > Signed-off-by: Anthony PERARD > > > > Acked-by: Stefano Stabellini > > Hi, > > This patch has never been applied. Sorry, it's on my queue now. > > > > MAINTAINERS | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 4a60579..1379317 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -309,7 +309,7 @@ Guest CPU Cores (Xen): > > > X86 > > > M: Stefano Stabellini > > > M: Anthony Perard > > > -L: xen-de...@lists.xensource.com > > > +L: xen-de...@lists.xenproject.org > > > S: Supported > > > F: xen-* > > > F: */xen* > > > -- > > > Anthony PERARD > > > > > -- > Anthony PERARD >
Re: [Qemu-devel] [Xen-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen
On Thu, 26 Jan 2017, Roger Pau Monné wrote: > On Wed, Jan 25, 2017 at 11:05:29AM +, Roger Pau Monné wrote: > > On Tue, Jan 24, 2017 at 01:30:02PM -0800, Stefano Stabellini wrote: > > > On Tue, 24 Jan 2017, Stefano Stabellini wrote: > > > > On Tue, 24 Jan 2017, Roger Pau Monné wrote: > > > > > Hello, > > > > > > > > > > The following commit: > > > > > > > > > > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894 > > > > > Author: Juergen Gross > > > > > Date: Tue Nov 22 07:10:58 2016 +0100 > > > > > > > > > > xen: create qdev for each backend device > > > > > > > > > > Prevents me from running QEMU on FreeBSD/Xen, the following is > > > > > printed on the > > > > > QEMU log: > > > > > > > > > > char device redirected to /dev/pts/2 (label serial0) > > > > > xen be core: xen be core: can't open gnttab device > > > > > can't open gnttab device > > > > > xen be core: xen be core: can't open gnttab device > > > > > can't open gnttab device > > > > > > > > > > # xl create -c ~/domain.cfg > > > > > Parsing config from /root/domain.cfg > > > > > libxl: error: libxl_dm.c:2201:device_model_spawn_outcome: Domain > > > > > 32:domain 32 device model: spawn failed (rc=-3) > > > > > libxl: error: libxl_create.c:1506:domcreate_devmodel_started: Domain > > > > > 32:device model did not start: -3 > > > > > libxl: error: libxl_dm.c:2315:kill_device_model: Device Model already > > > > > exited > > > > > libxl: error: libxl.c:1572:libxl__destroy_domid: Domain > > > > > 32:Non-existant domain > > > > > libxl: error: libxl.c:1531:domain_destroy_callback: Domain 32:Unable > > > > > to destroy guest > > > > > libxl: error: libxl.c:1458:domain_destroy_cb: Domain 32:Destruction > > > > > of domain failed > > > > > # cat /var/log/xen/qemu-dm-domain.log > > > > > char device redirected to /dev/pts/2 (label serial0) > > > > > xen be core: xen be core: can't open gnttab device > > > > > can't open gnttab device > > > > > xen be core: xen be core: can't open gnttab device > > > > > can't open gnttab device > > > > > > > > > > I'm not really familiar with any of that code, but I think that using > > > > > qdev_init_nofail is wrong, since on FreeBSD/Xen for example we don't > > > > > yet > > > > > support the gnttab device, so initialization of the Xen Qdisk backend > > > > > can fail > > > > > (and possibly the same applies to Linux if someone decides to compile > > > > > a kernel > > > > > without the gnttab device). Yet QEMU can be used without the Qdisk > > > > > backend. > > > > > > > > How did you manage to configure QEMU before? The configure script had > > > > xc_gnttab_open calls in it up to Xen 4.6. > > > > > > I know the answer! Because the configure script only compiles the code, > > > doesn't try to run it. xc_gnttab_open compiled correctly but returned > > > error when executed. Is that right? > > > > Yes, I'm quite that's right. FreeBSD is using gnttab_unimp.c, which > > implements > > xengnttab_open, so compilation will not fail. > > > > > > > > > > > > I am happy to support a use case where the kernel doesn't have gntdev, > > > > but it needs to be explicit: we need to detect it in the configure > > > > script, then avoid the initialization of devices which require it. > > > > > > I would still prefer configure to be able to detect this case. If it > > > cannot be made to detect it, then we can try to figure out a way to > > > catch the initialization errors at run time. > > > > I think it's better to simply fail to initialize Xen Qdisk at runtime, or > > else > > a xen-tools/QEMU compiled on a non-Xen environment won't get gnttab and as a > > consequence Xen Qdisk support enabled, and I think it's quite common for > > distros to compile Xen packages on non-Xen environments (where > > /dev/xen/gnttab > > is not available). > > Ping? Sorry for the delay. Obviously, you are correct. > I'm not really sure how to solve this because I have zero experience with QEMU > internals (all this qdev stuff). Can we restore the previous behavior, where > the failure to initialize a device wouldn't prevent QEMU from starting? I am convinced that we need to be able to handle the initialization errors at run time, but I would prefer not to revert 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894. It should be just a matter of replacing qdev_init_nofail with something that can fail. I couldn't find a regular qdev_init that can return error, so maybe we would need to add it. Juergen, would you be up for coming up with a patch?
Re: [Qemu-devel] [PATCH v2 2/3] xen-platform: add support for unplugging NVMe disks...
On Wed, 25 Jan 2017, Paul Durrant wrote: > On 25 January 2017, at 17:54, Stefano Stabellini > wrote: > > > > > > >On Wed, 25 Jan 2017, Paul Durrant wrote: > >> > -Original Message- > >> > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > >> > Sent: 24 January 2017 23:49 > >> > To: Paul Durrant > >> > Cc: qemu-devel@nongnu.org; xen-de...@lists.xenproject.org; Stefano > >> > Stabellini ; Anthony Perard > >> > ; Michael S. Tsirkin ; Paolo > >> > Bonzini ; Richard Henderson ; > >> > Eduardo Habkost ; o...@aepfle.de > >> > Subject: Re: [PATCH v2 2/3] xen-platform: add support for unplugging NVMe > >> > disks... > >> > > >> > On Tue, 24 Jan 2017, Paul Durrant wrote: > >> > > ...not just IDE and SCSI. > >> > > > >> > > This patch allows the Xen tool-stack to fully support of NVMe as an > >> > > emulated disk type. > >> > > > >> > > Signed-off-by: Paul Durrant > >> > > >> > Please update docs/misc/hvm-emulated-unplug.markdown in the Xen > >> > repository first. It might be also worth clarifying that `1` actually > >> > means all disks, not just IDE disks. Then, please add a reference to > >> > that commit in the description of this patch. > >> > > >> > >> Patch posted to remove 'IDE' from the documentation for value '1'. > >> Awaiting ack. > >Done. > >When you repost this patch, could you also add to the description a > >reference to the commit that enables NVMe in QEMU with Xen? I guess it > >is a libxl commit? > > I think there is a chicken and egg issue here. Wei wanted to ensure that QEMU > is able to unplug > NVMe drives before accepting my patch to libxl. No problems. In that case, please add a link to the xen-devel email thread. > >> > > --- > >> > > Cc: Stefano Stabellini > >> > > Cc: Anthony Perard > >> > > Cc: "Michael S. Tsirkin" > >> > > Cc: Paolo Bonzini > >> > > Cc: Richard Henderson > >> > > Cc: Eduardo Habkost > >> > > --- > >> > >Â hw/i386/xen/xen_platform.c | 1 + > >> > >Â 1 file changed, 1 insertion(+) > >> > > > >> > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c > >> > > index f50915f..7d41ebb 100644 > >> > > --- a/hw/i386/xen/xen_platform.c > >> > > +++ b/hw/i386/xen/xen_platform.c > >> > > @@ -120,6 +120,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, > >> > void *o) > >> > >Â break; > >> > > > >> > >Â case PCI_CLASS_STORAGE_SCSI: > >> > > +Â Â Â case PCI_CLASS_STORAGE_EXPRESS: > >> > >Â object_unparent(OBJECT(d)); > >> > >Â break; > >> > > > >> > > -- > >> > > 2.1.4 > >> > > > >> > > > > >
Re: [Qemu-devel] [PATCH v2 2/3] xen-platform: add support for unplugging NVMe disks...
On Wed, 25 Jan 2017, Paul Durrant wrote: > > -Original Message- > > From: Stefano Stabellini [mailto:sstabell...@kernel.org] > > Sent: 24 January 2017 23:49 > > To: Paul Durrant > > Cc: qemu-devel@nongnu.org; xen-de...@lists.xenproject.org; Stefano > > Stabellini ; Anthony Perard > > ; Michael S. Tsirkin ; Paolo > > Bonzini ; Richard Henderson ; > > Eduardo Habkost ; o...@aepfle.de > > Subject: Re: [PATCH v2 2/3] xen-platform: add support for unplugging NVMe > > disks... > > > > On Tue, 24 Jan 2017, Paul Durrant wrote: > > > ...not just IDE and SCSI. > > > > > > This patch allows the Xen tool-stack to fully support of NVMe as an > > > emulated disk type. > > > > > > Signed-off-by: Paul Durrant > > > > Please update docs/misc/hvm-emulated-unplug.markdown in the Xen > > repository first. It might be also worth clarifying that `1` actually > > means all disks, not just IDE disks. Then, please add a reference to > > that commit in the description of this patch. > > > > Patch posted to remove 'IDE' from the documentation for value '1'. Awaiting > ack. Done. When you repost this patch, could you also add to the description a reference to the commit that enables NVMe in QEMU with Xen? I guess it is a libxl commit? > > > --- > > > Cc: Stefano Stabellini > > > Cc: Anthony Perard > > > Cc: "Michael S. Tsirkin" > > > Cc: Paolo Bonzini > > > Cc: Richard Henderson > > > Cc: Eduardo Habkost > > > --- > > > hw/i386/xen/xen_platform.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c > > > index f50915f..7d41ebb 100644 > > > --- a/hw/i386/xen/xen_platform.c > > > +++ b/hw/i386/xen/xen_platform.c > > > @@ -120,6 +120,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, > > void *o) > > > break; > > > > > > case PCI_CLASS_STORAGE_SCSI: > > > +case PCI_CLASS_STORAGE_EXPRESS: > > > object_unparent(OBJECT(d)); > > > break; > > > > > > -- > > > 2.1.4 > > > >
Re: [Qemu-devel] [PATCH v2] 9pfs: fix offset error in v9fs_xattr_read()
On Wed, 25 Jan 2017, Greg Kurz wrote: > The current code tries to copy `read_count' bytes starting at offset > `offset' from a `read_count`-sized iovec. This causes v9fs_pack() to > fail with ENOBUFS. > > Since the PDU iovec is already partially filled with `offset' bytes, > let's skip them when creating `qiov_full' and have v9fs_pack() to > copy the whole of it. Moreover, this is consistent with the other > places where v9fs_init_qiov_from_pdu() is called. > > This fixes commit "bcb8998fac16 9pfs: call v9fs_init_qiov_from_pdu > before v9fs_pack". > > Signed-off-by: Greg Kurz Reviewed-by: Stefano Stabellini > v2: - pass size + skip to the init_in_iov_from_pdu callback > --- > hw/9pfs/9p.c |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > index fa58877570f6..f22d39064f6b 100644 > --- a/hw/9pfs/9p.c > +++ b/hw/9pfs/9p.c > @@ -1655,7 +1655,7 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, > V9fsPDU *pdu, > if (is_write) { > pdu->s->transport->init_out_iov_from_pdu(pdu, &iov, &niov); > } else { > -pdu->s->transport->init_in_iov_from_pdu(pdu, &iov, &niov, size); > +pdu->s->transport->init_in_iov_from_pdu(pdu, &iov, &niov, size + > skip); > } > > qemu_iovec_init_external(&elem, iov, niov); > @@ -1685,8 +1685,8 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, > V9fsFidState *fidp, > } > offset += err; > > -v9fs_init_qiov_from_pdu(&qiov_full, pdu, 0, read_count, false); > -err = v9fs_pack(qiov_full.iov, qiov_full.niov, offset, > +v9fs_init_qiov_from_pdu(&qiov_full, pdu, offset, read_count, false); > +err = v9fs_pack(qiov_full.iov, qiov_full.niov, 0, > ((char *)fidp->fs.xattr.value) + off, > read_count); > qemu_iovec_destroy(&qiov_full); >
Re: [Qemu-devel] [PATCH v2 3/3] xen-platform: add missing disk unplug option
On Tue, 24 Jan 2017, Paul Durrant wrote: > The Xen HVM unplug protocol [1] specifies a mechanism to allow guests to > request unplug of 'aux' disks (which is stated to mean all IDE disks, > except the primary master). This patch adds support for that unplug request. > > NOTE: The semantics of what happens if unplug of all disks and 'aux' disks > is simultaneously requests is not clear. The patch makes that > assumption that an 'all' request overrides an 'aux' request. > > [1] > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/hvm-emulated-unplug.markdown > > Signed-off-by: Paul Durrant Reviewed-by: Stefano Stabellini > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: Paolo Bonzini > Cc: Richard Henderson > Cc: Eduardo Habkost > Cc: "Michael S. Tsirkin" > Cc: John Snow > --- > hw/i386/xen/xen_platform.c | 27 +++ > hw/ide/piix.c | 4 ++-- > include/hw/ide.h | 2 +- > 3 files changed, 18 insertions(+), 15 deletions(-) > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c > index 7d41ebb..6010f35 100644 > --- a/hw/i386/xen/xen_platform.c > +++ b/hw/i386/xen/xen_platform.c > @@ -107,8 +107,12 @@ static void pci_unplug_nics(PCIBus *bus) > pci_for_each_device(bus, 0, unplug_nic, NULL); > } > > -static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) > +static void unplug_disks(PCIBus *b, PCIDevice *d, void *opaque) > { > +uint32_t flags = *(uint32_t *)opaque; > +bool aux = (flags & UNPLUG_AUX_IDE_DISKS) && > +!(flags & UNPLUG_ALL_DISKS); > + > /* We have to ignore passthrough devices */ > if (!strcmp(d->name, "xen-pci-passthrough")) { > return; > @@ -116,12 +120,14 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void > *o) > > switch (pci_get_word(d->config + PCI_CLASS_DEVICE)) { > case PCI_CLASS_STORAGE_IDE: > -pci_piix3_xen_ide_unplug(DEVICE(d)); > +pci_piix3_xen_ide_unplug(DEVICE(d), aux); > break; > > case PCI_CLASS_STORAGE_SCSI: > case PCI_CLASS_STORAGE_EXPRESS: > -object_unparent(OBJECT(d)); > +if (!aux) { > +object_unparent(OBJECT(d)); > +} > break; > > default: > @@ -129,9 +135,9 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) > } > } > > -static void pci_unplug_disks(PCIBus *bus) > +static void pci_unplug_disks(PCIBus *bus, uint32_t flags) > { > -pci_for_each_device(bus, 0, unplug_disks, NULL); > +pci_for_each_device(bus, 0, unplug_disks, &flags); > } > > static void platform_fixed_ioport_writew(void *opaque, uint32_t addr, > uint32_t val) > @@ -144,17 +150,14 @@ static void platform_fixed_ioport_writew(void *opaque, > uint32_t addr, uint32_t v > /* Unplug devices. Value is a bitmask of which devices to > unplug, with bit 0 the disk devices, bit 1 the network > devices, and bit 2 the non-primary-master IDE devices. */ > -if (val & UNPLUG_ALL_DISKS) { > +if (val & (UNPLUG_ALL_DISKS | UNPLUG_AUX_IDE_DISKS)) { > DPRINTF("unplug disks\n"); > -pci_unplug_disks(pci_dev->bus); > +pci_unplug_disks(pci_dev->bus, val); > } > if (val & UNPLUG_ALL_NICS) { > DPRINTF("unplug nics\n"); > pci_unplug_nics(pci_dev->bus); > } > -if (val & UNPLUG_AUX_IDE_DISKS) { > -DPRINTF("unplug auxiliary disks not supported\n"); > -} > break; > } > case 2: > @@ -335,14 +338,14 @@ static void xen_platform_ioport_writeb(void *opaque, > hwaddr addr, > * If VMDP was to control both disk and LAN it would use 4. > * If it controlled just disk or just LAN, it would use 8 below. > */ > -pci_unplug_disks(pci_dev->bus); > +pci_unplug_disks(pci_dev->bus, UNPLUG_ALL_DISKS); > pci_unplug_nics(pci_dev->bus); > } > break; > case 8: > switch (val) { > case 1: > -pci_unplug_disks(pci_dev->bus); > +pci_unplug_disks(pci_dev->bus, UNPLUG_ALL_DISKS); > break; > case 2: > pci_unplug_nics(pci_dev->bus); > diff --git a/hw/ide/piix.c b/hw/ide/piix.c > index d5777fd..7e2d767 100644 > --- a/hw/ide/piix.c > +++ b/hw/ide/piix.c > @@ -165,7 +165,7 @@ static void pci_piix_ide_realize
Re: [Qemu-devel] [PATCH v2 2/3] xen-platform: add support for unplugging NVMe disks...
On Tue, 24 Jan 2017, Paul Durrant wrote: > ...not just IDE and SCSI. > > This patch allows the Xen tool-stack to fully support of NVMe as an > emulated disk type. > > Signed-off-by: Paul Durrant Please update docs/misc/hvm-emulated-unplug.markdown in the Xen repository first. It might be also worth clarifying that `1` actually means all disks, not just IDE disks. Then, please add a reference to that commit in the description of this patch. > --- > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: "Michael S. Tsirkin" > Cc: Paolo Bonzini > Cc: Richard Henderson > Cc: Eduardo Habkost > --- > hw/i386/xen/xen_platform.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c > index f50915f..7d41ebb 100644 > --- a/hw/i386/xen/xen_platform.c > +++ b/hw/i386/xen/xen_platform.c > @@ -120,6 +120,7 @@ static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) > break; > > case PCI_CLASS_STORAGE_SCSI: > +case PCI_CLASS_STORAGE_EXPRESS: > object_unparent(OBJECT(d)); > break; > > -- > 2.1.4 >
Re: [Qemu-devel] [PATCH v2 1/3] xen-platform: re-structure unplug_disks
On Tue, 24 Jan 2017, Paul Durrant wrote: > The current code is poorly structured and potentially leads to multiple > config space reads when one is sufficient. Also the UNPLUG_ALL_IDE_DISKS > flag is mis-named since it also results in SCSI disks being unplugged. > > This patch renames the flag and re-structures the code to be more > efficient, and readable. > > Signed-off-by: Paul Durrant Reviewed-by: Stefano Stabellini > --- > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: Paolo Bonzini > Cc: Richard Henderson > Cc: Eduardo Habkost > Cc: "Michael S. Tsirkin" > > v2: > - Fix style issue > --- > hw/i386/xen/xen_platform.c | 25 - > 1 file changed, 16 insertions(+), 9 deletions(-) > > diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c > index 2e1e543..f50915f 100644 > --- a/hw/i386/xen/xen_platform.c > +++ b/hw/i386/xen/xen_platform.c > @@ -88,7 +88,7 @@ static void log_writeb(PCIXenPlatformState *s, char val) > } > > /* Xen Platform, Fixed IOPort */ > -#define UNPLUG_ALL_IDE_DISKS 1 > +#define UNPLUG_ALL_DISKS 1 > #define UNPLUG_ALL_NICS 2 > #define UNPLUG_AUX_IDE_DISKS 4 > > @@ -110,14 +110,21 @@ static void pci_unplug_nics(PCIBus *bus) > static void unplug_disks(PCIBus *b, PCIDevice *d, void *o) > { > /* We have to ignore passthrough devices */ > -if (pci_get_word(d->config + PCI_CLASS_DEVICE) == > -PCI_CLASS_STORAGE_IDE > -&& strcmp(d->name, "xen-pci-passthrough") != 0) { > +if (!strcmp(d->name, "xen-pci-passthrough")) { > +return; > +} > + > +switch (pci_get_word(d->config + PCI_CLASS_DEVICE)) { > +case PCI_CLASS_STORAGE_IDE: > pci_piix3_xen_ide_unplug(DEVICE(d)); > -} else if (pci_get_word(d->config + PCI_CLASS_DEVICE) == > -PCI_CLASS_STORAGE_SCSI > -&& strcmp(d->name, "xen-pci-passthrough") != 0) { > +break; > + > +case PCI_CLASS_STORAGE_SCSI: > object_unparent(OBJECT(d)); > +break; > + > +default: > +break; > } > } > > @@ -134,9 +141,9 @@ static void platform_fixed_ioport_writew(void *opaque, > uint32_t addr, uint32_t v > case 0: { > PCIDevice *pci_dev = PCI_DEVICE(s); > /* Unplug devices. Value is a bitmask of which devices to > - unplug, with bit 0 the IDE devices, bit 1 the network > + unplug, with bit 0 the disk devices, bit 1 the network > devices, and bit 2 the non-primary-master IDE devices. */ > -if (val & UNPLUG_ALL_IDE_DISKS) { > +if (val & UNPLUG_ALL_DISKS) { > DPRINTF("unplug disks\n"); > pci_unplug_disks(pci_dev->bus); > } > -- > 2.1.4 >
Re: [Qemu-devel] [PATCH] 9pfs: fix offset error in v9fs_xattr_read()
On Tue, 24 Jan 2017, Greg Kurz wrote: > On Mon, 23 Jan 2017 12:20:57 -0800 (PST) > Stefano Stabellini wrote: > > > On Sat, 21 Jan 2017, Greg Kurz wrote: > > > The current code tries to copy `read_count' bytes starting at offset > > > `offset' from a `read_count`-sized iovec. This causes v9fs_pack() to > > > fail with ENOBUFS. > > > > > > Since the PDU iovec is already partially filled with `offset' bytes, > > > let's skip them when creating `qiov_full' and have v9fs_pack() to > > > copy the whole of it. Moreover, this is consistent with the other > > > places where v9fs_init_qiov_from_pdu() is called. > > > > > > This fixes commit "bcb8998fac16 9pfs: call v9fs_init_qiov_from_pdu > > > before v9fs_pack". > > > > Sorry about that! > > > > > > > Signed-off-by: Greg Kurz > > > --- > > > hw/9pfs/9p.c |4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > > index fa58877570f6..f0eef1a3ef53 100644 > > > --- a/hw/9pfs/9p.c > > > +++ b/hw/9pfs/9p.c > > > @@ -1685,8 +1685,8 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU > > > *pdu, V9fsFidState *fidp, > > > } > > > offset += err; > > > > > > -v9fs_init_qiov_from_pdu(&qiov_full, pdu, 0, read_count, false); > > > -err = v9fs_pack(qiov_full.iov, qiov_full.niov, offset, > > > +v9fs_init_qiov_from_pdu(&qiov_full, pdu, offset, read_count, false); > > > > > > > v9fs_init_qiov_from_pdu calls init_in_iov_from_pdu passing read_count as > > size argument. offset is not passed to init_in_iov_from_pdu, it is only > > used to initialized qiov_full. > > > > In other words, don't we need to: > > > > v9fs_init_qiov_from_pdu(&qiov_full, pdu, offset, read_count + offset, > > false); > > > > To make sure that qiov_full has "read_count + offset" bytes in it, and > > qiov_full is initialized skipping the first "offset" bytes? > > > > If we do that then qemu_iovec_concat() will skip offset bytes and then copy > read_count + offset bytes or am I missing something ? You are right, sorry. qemu_iovec_concat didn't do what I thought it would. In that case, I think we need to change v9fs_init_qiov_from_pdu (in addition to the changes already in this patch): @@ -1659,12 +1659,14 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, if (is_write) { pdu->s->transport->init_out_iov_from_pdu(pdu, &iov, &niov); } else { -pdu->s->transport->init_in_iov_from_pdu(pdu, &iov, &niov, size); +pdu->s->transport->init_in_iov_from_pdu(pdu, &iov, &niov, size + skip); } The reason is the same as before: iov needs to have offset+read_count bytes in it, for qemu_iovec_concat to skip offset and iov still have read_count bytes left. > > > +err = v9fs_pack(qiov_full.iov, qiov_full.niov, 0, > > > ((char *)fidp->fs.xattr.value) + off, > > > read_count); > > > qemu_iovec_destroy(&qiov_full); > > > > >
Re: [Qemu-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen
On Tue, 24 Jan 2017, Stefano Stabellini wrote: > On Tue, 24 Jan 2017, Roger Pau Monné wrote: > > Hello, > > > > The following commit: > > > > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894 > > Author: Juergen Gross > > Date: Tue Nov 22 07:10:58 2016 +0100 > > > > xen: create qdev for each backend device > > > > Prevents me from running QEMU on FreeBSD/Xen, the following is printed on > > the > > QEMU log: > > > > char device redirected to /dev/pts/2 (label serial0) > > xen be core: xen be core: can't open gnttab device > > can't open gnttab device > > xen be core: xen be core: can't open gnttab device > > can't open gnttab device > > > > # xl create -c ~/domain.cfg > > Parsing config from /root/domain.cfg > > libxl: error: libxl_dm.c:2201:device_model_spawn_outcome: Domain 32:domain > > 32 device model: spawn failed (rc=-3) > > libxl: error: libxl_create.c:1506:domcreate_devmodel_started: Domain > > 32:device model did not start: -3 > > libxl: error: libxl_dm.c:2315:kill_device_model: Device Model already exited > > libxl: error: libxl.c:1572:libxl__destroy_domid: Domain 32:Non-existant > > domain > > libxl: error: libxl.c:1531:domain_destroy_callback: Domain 32:Unable to > > destroy guest > > libxl: error: libxl.c:1458:domain_destroy_cb: Domain 32:Destruction of > > domain failed > > # cat /var/log/xen/qemu-dm-domain.log > > char device redirected to /dev/pts/2 (label serial0) > > xen be core: xen be core: can't open gnttab device > > can't open gnttab device > > xen be core: xen be core: can't open gnttab device > > can't open gnttab device > > > > I'm not really familiar with any of that code, but I think that using > > qdev_init_nofail is wrong, since on FreeBSD/Xen for example we don't yet > > support the gnttab device, so initialization of the Xen Qdisk backend can > > fail > > (and possibly the same applies to Linux if someone decides to compile a > > kernel > > without the gnttab device). Yet QEMU can be used without the Qdisk backend. > > How did you manage to configure QEMU before? The configure script had > xc_gnttab_open calls in it up to Xen 4.6. I know the answer! Because the configure script only compiles the code, doesn't try to run it. xc_gnttab_open compiled correctly but returned error when executed. Is that right? > I am happy to support a use case where the kernel doesn't have gntdev, > but it needs to be explicit: we need to detect it in the configure > script, then avoid the initialization of devices which require it. I would still prefer configure to be able to detect this case. If it cannot be made to detect it, then we can try to figure out a way to catch the initialization errors at run time.
Re: [Qemu-devel] Commit 3a6c9 breaks QEMU on FreeBSD/Xen
On Tue, 24 Jan 2017, Roger Pau Monné wrote: > Hello, > > The following commit: > > commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894 > Author: Juergen Gross > Date: Tue Nov 22 07:10:58 2016 +0100 > > xen: create qdev for each backend device > > Prevents me from running QEMU on FreeBSD/Xen, the following is printed on the > QEMU log: > > char device redirected to /dev/pts/2 (label serial0) > xen be core: xen be core: can't open gnttab device > can't open gnttab device > xen be core: xen be core: can't open gnttab device > can't open gnttab device > > # xl create -c ~/domain.cfg > Parsing config from /root/domain.cfg > libxl: error: libxl_dm.c:2201:device_model_spawn_outcome: Domain 32:domain 32 > device model: spawn failed (rc=-3) > libxl: error: libxl_create.c:1506:domcreate_devmodel_started: Domain > 32:device model did not start: -3 > libxl: error: libxl_dm.c:2315:kill_device_model: Device Model already exited > libxl: error: libxl.c:1572:libxl__destroy_domid: Domain 32:Non-existant domain > libxl: error: libxl.c:1531:domain_destroy_callback: Domain 32:Unable to > destroy guest > libxl: error: libxl.c:1458:domain_destroy_cb: Domain 32:Destruction of domain > failed > # cat /var/log/xen/qemu-dm-domain.log > char device redirected to /dev/pts/2 (label serial0) > xen be core: xen be core: can't open gnttab device > can't open gnttab device > xen be core: xen be core: can't open gnttab device > can't open gnttab device > > I'm not really familiar with any of that code, but I think that using > qdev_init_nofail is wrong, since on FreeBSD/Xen for example we don't yet > support the gnttab device, so initialization of the Xen Qdisk backend can fail > (and possibly the same applies to Linux if someone decides to compile a kernel > without the gnttab device). Yet QEMU can be used without the Qdisk backend. How did you manage to configure QEMU before? The configure script had xc_gnttab_open calls in it up to Xen 4.6. I am happy to support a use case where the kernel doesn't have gntdev, but it needs to be explicit: we need to detect it in the configure script, then avoid the initialization of devices which require it.
Re: [Qemu-devel] [PATCH] 9pfs: fix offset error in v9fs_xattr_read()
On Sat, 21 Jan 2017, Greg Kurz wrote: > The current code tries to copy `read_count' bytes starting at offset > `offset' from a `read_count`-sized iovec. This causes v9fs_pack() to > fail with ENOBUFS. > > Since the PDU iovec is already partially filled with `offset' bytes, > let's skip them when creating `qiov_full' and have v9fs_pack() to > copy the whole of it. Moreover, this is consistent with the other > places where v9fs_init_qiov_from_pdu() is called. > > This fixes commit "bcb8998fac16 9pfs: call v9fs_init_qiov_from_pdu > before v9fs_pack". Sorry about that! > Signed-off-by: Greg Kurz > --- > hw/9pfs/9p.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > index fa58877570f6..f0eef1a3ef53 100644 > --- a/hw/9pfs/9p.c > +++ b/hw/9pfs/9p.c > @@ -1685,8 +1685,8 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, > V9fsFidState *fidp, > } > offset += err; > > -v9fs_init_qiov_from_pdu(&qiov_full, pdu, 0, read_count, false); > -err = v9fs_pack(qiov_full.iov, qiov_full.niov, offset, > +v9fs_init_qiov_from_pdu(&qiov_full, pdu, offset, read_count, false); v9fs_init_qiov_from_pdu calls init_in_iov_from_pdu passing read_count as size argument. offset is not passed to init_in_iov_from_pdu, it is only used to initialized qiov_full. In other words, don't we need to: v9fs_init_qiov_from_pdu(&qiov_full, pdu, offset, read_count + offset, false); To make sure that qiov_full has "read_count + offset" bytes in it, and qiov_full is initialized skipping the first "offset" bytes? > +err = v9fs_pack(qiov_full.iov, qiov_full.niov, 0, > ((char *)fidp->fs.xattr.value) + off, > read_count); > qemu_iovec_destroy(&qiov_full); >
Re: [Qemu-devel] [PATCH V5 1/2] Add a new qmp command to start/stop replication
On Tue, 27 Dec 2016, Zhang Chen wrote: > We can call this qmp command to start/stop replication outside of qemu. > Like Xen colo need this function. > > Signed-off-by: Zhang Chen > Signed-off-by: Wen Congyang > Reviewed-by: Eric Blake Reviewed-by: Stefano Stabellini > --- > docs/qmp-commands.txt | 18 ++ > migration/colo.c | 23 +++ > qapi-schema.json | 19 +++ > 3 files changed, 60 insertions(+) > > diff --git a/docs/qmp-commands.txt b/docs/qmp-commands.txt > index abf210a..d182147 100644 > --- a/docs/qmp-commands.txt > +++ b/docs/qmp-commands.txt > @@ -432,6 +432,24 @@ Example: > "arguments": { "enable": true } } > <- { "return": {} } > > +xen-set-replication > +--- > + > +Enable or disable replication. > + > +Arguments: > + > +- "enable": Enable it or disable it. > +- "primary": True for primary or false for secondary. > +- "failover": Enable failover when stopping replication, but cannot be > + specified if 'enable' is true (optional, default false). > + > +Example: > + > +-> { "execute": "xen-set-replication", > + "arguments": {"enable": true, "primary": false} } > +<- { "return": {} } > + > migrate > --- > > diff --git a/migration/colo.c b/migration/colo.c > index 93c85c5..6fc2ade 100644 > --- a/migration/colo.c > +++ b/migration/colo.c > @@ -19,6 +19,8 @@ > #include "qemu/error-report.h" > #include "qapi/error.h" > #include "migration/failover.h" > +#include "replication.h" > +#include "qmp-commands.h" > > #define COLO_BUFFER_BASE_SIZE (4 * 1024 * 1024) > > @@ -104,6 +106,27 @@ void colo_do_failover(MigrationState *s) > } > } > > +void qmp_xen_set_replication(bool enable, bool primary, > + bool has_failover, bool failover, > + Error **errp) > +{ > +ReplicationMode mode = primary ? > + REPLICATION_MODE_PRIMARY : > + REPLICATION_MODE_SECONDARY; > + > +if (has_failover && enable) { > +error_setg(errp, "Parameter 'failover' is only for" > + " stopping replication"); > +return; > +} > + > +if (enable) { > +replication_start_all(mode, errp); > +} else { > +replication_stop_all(failover, failover ? NULL : errp); > +} > +} > + > static void colo_send_message(QEMUFile *f, COLOMessage msg, >Error **errp) > { > diff --git a/qapi-schema.json b/qapi-schema.json > index f3e9bfc..78802f4 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -4676,6 +4676,25 @@ > { 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} } > > ## > +# @xen-set-replication > +# > +# Enable or disable replication. > +# > +# @enable: true to enable, false to disable. > +# > +# @primary: true for primary or false for secondary. > +# > +# @failover: #optional true to do failover, false to stop. but cannot be > +#specified if 'enable' is true. default value is false. > +# > +# Returns: nothing. > +# > +# Since: 2.9 > +## > +{ 'command': 'xen-set-replication', > + 'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } } > + > +## > # @GICCapability: > # > # The struct describes capability for a specific GIC (Generic > -- > 2.7.4 > > > >
Re: [Qemu-devel] [RFC 0/7] Move accel, KVM, Xen, qtest files to accel/ subdir
On Tue, 20 Dec 2016, Eduardo Habkost wrote: > This moves the KVM and Xen files to the an accel/ subdir. > > Instead of moving the *-stubs.c file to accel/ as-is, I tried to > move most of the stub code to libqemustub.a. This way the obj-y > logic for accel/ is simpler: obj-y includes accel/ only if > CONFIG_SOFTMMU is set. > > The Xen stubs could be moved completely to stubs/, but some of > the KVM stubs depend on cpu.h. So most of the kvm-stub.c code was > moved to stubs/kvm.c, but some of that code was kept in > accel/kvm-stub.c. Fine by me. My build test succeeded. > About TCG: > -- > > It is not obvious to me which TCG-related files could be moved to > accel/, so this series don't move any of them yet. > > About other CONFIG_SOFTMMU top-level files: > --- > > I would like to know what we should do with the top-level > CONFIG_SOFTMMU-only files that don't belong to hw/. Some > candidates: arch_init.c cpus.c monitor.c gdbstub.c balloon.c > ioport.c bootdevice.c memory.c cputlb.c memory_mapping.c dump.c. > > Maybe a sysemu/ subdir? In that case, should we still create an > accel/ subdir, or move xen-*, kvm-* and friends to sysemu/ too? > > Cc: Paolo Bonzini > Cc: k...@vger.kernel.org > Cc: Christoffer Dall > Cc: Anthony Perard > Cc: Stefano Stabellini > Cc: xen-de...@lists.xensource.com > > Eduardo Habkost (7): > xen: Move xen-*-stub.c to stubs/ > xen: Move xen files to accel/ > kvm: Move some kvm-stub.c code to stubs/kvm.c > kvm: Include kvm-stub.o only on CONFIG_SOFTMMU > kvm: Move kvm*.c files to accel/ > accel: Move accel.c to accel/ > accel: Move qtest.c to accel/ > > Makefile.objs | 2 +- > Makefile.target| 10 ++ > accel.c => accel/accel.c | 0 > kvm-all.c => accel/kvm-common.c| 0 > kvm-stub.c => accel/kvm-stub.c | 51 -- > qtest.c => accel/qtest.c | 0 > xen-common.c => accel/xen-common.c | 0 > xen-hvm.c => accel/xen-hvm.c | 0 > xen-mapcache.c => accel/xen-mapcache.c | 0 > stubs/kvm.c| 65 > ++ > xen-hvm-stub.c => stubs/xen-hvm.c | 0 > xen-common-stub.c => stubs/xen.c | 0 > MAINTAINERS| 4 +-- > accel/Makefile.objs| 9 + > stubs/Makefile.objs| 2 ++ > 15 files changed, 80 insertions(+), 63 deletions(-) > rename accel.c => accel/accel.c (100%) > rename kvm-all.c => accel/kvm-common.c (100%) > rename kvm-stub.c => accel/kvm-stub.c (71%) > rename qtest.c => accel/qtest.c (100%) > rename xen-common.c => accel/xen-common.c (100%) > rename xen-hvm.c => accel/xen-hvm.c (100%) > rename xen-mapcache.c => accel/xen-mapcache.c (100%) > rename xen-hvm-stub.c => stubs/xen-hvm.c (100%) > rename xen-common-stub.c => stubs/xen.c (100%) > create mode 100644 accel/Makefile.objs > > -- > 2.7.4 >
Re: [Qemu-devel] [PATCH for-2.9 V4 2/2] Add a new qmp command to do checkpoint, get replication error
On Fri, 16 Dec 2016, Zhang Chen wrote: > We can call this qmp command to do checkpoint outside of qemu. > Like Xen colo need this function. > > Signed-off-by: Zhang Chen > Signed-off-by: Wen Congyang > --- > docs/qmp-commands.txt | 24 > migration/colo.c | 10 ++ > qapi-schema.json | 22 ++ > 3 files changed, 56 insertions(+) > > diff --git a/docs/qmp-commands.txt b/docs/qmp-commands.txt > index a8e9eb6..093b7eb 100644 > --- a/docs/qmp-commands.txt > +++ b/docs/qmp-commands.txt > @@ -450,6 +450,30 @@ Example: > "arguments": {"enable": true, "primary": false} } > <- { "return": {} } > > +xen-get-replication-error > +- > + > +Get replication error that occurs when vm is running. > + > +Arguments: None. > + > +Example: > + > +-> { "execute": "xen-get-replication-error" } > +<- { "return": {} } > + > +xen-do-checkpoint > +- > + > +Do checkpoint. > + > +Arguments: None. > + > +Example: > + > +-> { "execute": "xen-do-checkpoint" } > +<- { "return": {} } I don't know much about QMP, but shouldn't these two functions return a success or failure at least? Especially xen-get-replication-error? How does xen-get-replication-error actually return the error? Please also write this info on the description of the commands (docs/qmp-commands.txt, qapi-schema.json). > migrate > --- > > diff --git a/migration/colo.c b/migration/colo.c > index 6fc2ade..1e962f6 100644 > --- a/migration/colo.c > +++ b/migration/colo.c > @@ -127,6 +127,16 @@ void qmp_xen_set_replication(bool enable, bool primary, > } > } > > +void qmp_xen_get_replication_error(Error **errp) > +{ > +replication_get_error_all(errp); > +} > + > +void qmp_xen_do_checkpoint(Error **errp) > +{ > +replication_do_checkpoint_all(errp); > +} > + > static void colo_send_message(QEMUFile *f, COLOMessage msg, >Error **errp) > { > diff --git a/qapi-schema.json b/qapi-schema.json > index 78802f4..79fe4dd 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -4695,6 +4695,28 @@ >'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } } > > ## > +# @xen-get-replication-error > +# > +# Get replication error that occurs when the vm is running. > +# > +# Returns: nothing. > +# > +# Since: 2.9 > +## > +{ 'command': 'xen-get-replication-error' } > + > +## > +# @xen-do-checkpoint > +# > +# Do checkpoint. > +# > +# Returns: nothing. > +# > +# Since: 2.9 > +## > +{ 'command': 'xen-do-checkpoint' } > + > +## > # @GICCapability: > # > # The struct describes capability for a specific GIC (Generic > -- > 2.7.4 > > > >
Re: [Qemu-devel] [PATCH for-2.9 V4 1/2] Add a new qmp command to start/stop replication
On Fri, 16 Dec 2016, Zhang Chen wrote: > We can call this qmp command to start/stop replication outside of qemu. > Like Xen colo need this function. > > Signed-off-by: Zhang Chen > Signed-off-by: Wen Congyang > --- > docs/qmp-commands.txt | 18 ++ > migration/colo.c | 23 +++ > qapi-schema.json | 19 +++ > 3 files changed, 60 insertions(+) > > diff --git a/docs/qmp-commands.txt b/docs/qmp-commands.txt > index abf210a..a8e9eb6 100644 > --- a/docs/qmp-commands.txt > +++ b/docs/qmp-commands.txt > @@ -432,6 +432,24 @@ Example: > "arguments": { "enable": true } } > <- { "return": {} } > > +xen-set-replication > +--- > + > +Enable or disable replication. > + > +Arguments: > + > +- "enable": Enable it or disable it. > +- "primary": True for primary or false for secondary. > +- "failover": Enable failover when stopping replication, but cannot be > + specified if 'enable' is true (optional, default false). > + > +Example: > + > +-> { "execute": "xen-set-replicate", Shouldn't this be "xen-set-replication" ? > + "arguments": {"enable": true, "primary": false} } > +<- { "return": {} } > + > migrate > --- > > diff --git a/migration/colo.c b/migration/colo.c > index 93c85c5..6fc2ade 100644 > --- a/migration/colo.c > +++ b/migration/colo.c > @@ -19,6 +19,8 @@ > #include "qemu/error-report.h" > #include "qapi/error.h" > #include "migration/failover.h" > +#include "replication.h" > +#include "qmp-commands.h" > > #define COLO_BUFFER_BASE_SIZE (4 * 1024 * 1024) > > @@ -104,6 +106,27 @@ void colo_do_failover(MigrationState *s) > } > } > > +void qmp_xen_set_replication(bool enable, bool primary, > + bool has_failover, bool failover, > + Error **errp) > +{ > +ReplicationMode mode = primary ? > + REPLICATION_MODE_PRIMARY : > + REPLICATION_MODE_SECONDARY; > + > +if (has_failover && enable) { > +error_setg(errp, "Parameter 'failover' is only for" > + " stopping replication"); > +return; > +} > + > +if (enable) { > +replication_start_all(mode, errp); > +} else { > +replication_stop_all(failover, failover ? NULL : errp); > +} > +} > + > static void colo_send_message(QEMUFile *f, COLOMessage msg, >Error **errp) > { > diff --git a/qapi-schema.json b/qapi-schema.json > index f3e9bfc..78802f4 100644 > --- a/qapi-schema.json > +++ b/qapi-schema.json > @@ -4676,6 +4676,25 @@ > { 'command': 'xen-load-devices-state', 'data': {'filename': 'str'} } > > ## > +# @xen-set-replication > +# > +# Enable or disable replication. > +# > +# @enable: true to enable, false to disable. > +# > +# @primary: true for primary or false for secondary. > +# > +# @failover: #optional true to do failover, false to stop. but cannot be > +#specified if 'enable' is true. default value is false. > +# > +# Returns: nothing. > +# > +# Since: 2.9 > +## > +{ 'command': 'xen-set-replication', > + 'data': { 'enable': 'bool', 'primary': 'bool', '*failover' : 'bool' } } > + > +## > # @GICCapability: > # > # The struct describes capability for a specific GIC (Generic > -- > 2.7.4 > > > >
Re: [Qemu-devel] [PATCH for-2.9 V4 0/2] Add new qmp commands to suppurt Xen COLO
I am OK with this, if the relevant maintainers (Migration, QMP) ack the patches. On Fri, 16 Dec 2016, Zhang Chen wrote: > Xen COLO depend on qemu COLO replication function. > So, We need new qmp commands for Xen to use qemu replication. > > Corresponding libxl patches already in xen.git. > Commit ID: > > ed37ef1f91c20f0ab162ce60f8c38400b917fa64 > COLO: introduce new API to prepare/start/do/get_error/stop replication > > a0ddc0b359375b2418213966dfbdbfab593ecc6f > tools/libxl: introduction of libxl__qmp_restore to load qemu state > > > Zhang Chen (2): > Add a new qmp command to start/stop replication > Add a new qmp command to do checkpoint, get replication error > > docs/qmp-commands.txt | 42 ++ > migration/colo.c | 33 + > qapi-schema.json | 41 + > 3 files changed, 116 insertions(+) > > -- > 2.7.4 > > > >
Re: [Qemu-devel] [PATCH for-2.9 V3 1/3] Migration: Don't load vmdesc when xen is enabled
On Fri, 9 Dec 2016, Zhang Chen wrote: > Xen doesn't need this. Could you please elaborate a bit more on what is the problem exactly, and why we don't have any issues with migration with Xen today (COLO use-case aside)? > Signed-off-by: Zhang Chen > --- > migration/savevm.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/migration/savevm.c b/migration/savevm.c > index 0363372..bec6c7e 100644 > --- a/migration/savevm.c > +++ b/migration/savevm.c > @@ -1973,6 +1973,10 @@ int qemu_loadvm_state(QEMUFile *f) > ret = qemu_file_get_error(f); > } > > +if (xen_enabled()) { > +return ret; > +} > + > /* > * Try to read in the VMDESC section as well, so that dumping tools that > * intercept our migration stream have the chance to see it. > -- > 2.7.4 > > > >
Re: [Qemu-devel] [PATCH 0/3] Add new qmp commands to suppurt Xen COLO
Hello Zhang, Are the corresponding libxl patches already in xen.git? If so, could you please mention the commits; if not, could you please add a link to the corresponding patches? Thanks! - Stefano On Thu, 1 Dec 2016, Zhang Chen wrote: > Xen COLO depend on qemu COLO replication function. > So, We need new qmp commands for Xen to use qemu replication. > > Zhang Chen (3): > Migration: Don't load vmdesc when xen is enabled > Add a new qmp command to start/stop replication > Add a new qmp command to do checkpoint, get replication error > > docs/qmp-commands.txt | 41 + > migration/colo.c | 32 > migration/savevm.c| 4 > qapi-schema.json | 40 > 4 files changed, 117 insertions(+) > > -- > 2.7.4 > > > >
Re: [Qemu-devel] [PATCH v4 3/7] fw-cfg: expose "file_slots" parameter in fw_cfg_init_io_dma()
On Tue, 6 Dec 2016, Igor Mammedov wrote: > > First, to my knowledge, Xen does not use fw_cfg. The following call > > chains depend on (!xen_enabled()): > maybe not, it's just grep gave me: > xen_load_linux() -> fw_cfg_init_io() > maybe it's dead code now [...] > > > > pc_init1() | pc_q35_init() > > if (!xen_enabled()): > > pc_memory_init() > > bochs_bios_init() > > fw_cfg_init_io_dma() We have a couple of idiosyncrasies with Xen support in QEMU; this is one of them. Xen doesn't use fw_cfg, because hvmloader [1][2] runs in guest context before SeaBios setting things up, including ACPI tables. So usually we don't need it. However direct kernel boot is done via xen_load_linux which is based on fw_cfg. So when kernel= and ramdisk= are specified in a Xen HVM config file (which is not common), they are passed to QEMU as -kernel and -initrd, then QEMU ends up using fw_cfg to load the kernel in the guest. That's the only use case we have for it at the moment. Direct kernel boot with Xen HVM guests is not tested by OSSTest (Xen Project CI loop), as a consequence it broke in the past without anybody noticing. [1]: http://xenbits.xenproject.org/gitweb/?p=xen.git;a=tree;f=tools/firmware/hvmloader;h=069e29fa3820364c69c95798d56ef097148fddd2;hb=HEAD [2]: https://wiki.xenproject.org/wiki/Hvmloader
Re: [Qemu-devel] [Xen-devel] [PATCH v2 4/4] 9pfs: introduce init_out/in_iov_from_pdu
On Fri, 2 Dec 2016, Greg Kurz wrote: > On Mon, 28 Nov 2016 13:27:24 -0800 > Stefano Stabellini wrote: > > > Not all 9pfs transports share memory between request and response. For > > those who don't, it is necessary to know how much memory is required in > > the response. > > > > Split the existing init_iov_from_pdu function in two: > > init_out_iov_from_pdu (for writes) and init_in_iov_from_pdu (for reads). > > init_in_iov_from_pdu takes an additional size parameter to specify the > > memory required for the response message. > > > > Signed-off-by: Stefano Stabellini > > --- > > Reviewed-by: Greg Kurz Thanks Greg! I assume you are going to apply them to your tree, right? Thanks again, Stefano > > hw/9pfs/9p.c | 6 +- > > hw/9pfs/9p.h | 6 -- > > hw/9pfs/virtio-9p-device.c | 28 ++-- > > 3 files changed, 27 insertions(+), 13 deletions(-) > > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > index 79d7201..ce1f9d9 100644 > > --- a/hw/9pfs/9p.c > > +++ b/hw/9pfs/9p.c > > @@ -1652,7 +1652,11 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector > > *qiov, V9fsPDU *pdu, > > struct iovec *iov; > > unsigned int niov; > > > > -pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); > > +if (is_write) { > > +pdu->s->transport->init_out_iov_from_pdu(pdu, &iov, &niov); > > +} else { > > +pdu->s->transport->init_in_iov_from_pdu(pdu, &iov, &niov, size); > > +} > > > > qemu_iovec_init_external(&elem, iov, niov); > > qemu_iovec_init(qiov, niov); > > diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h > > index c8c9aa8..4c4feaf 100644 > > --- a/hw/9pfs/9p.h > > +++ b/hw/9pfs/9p.h > > @@ -349,8 +349,10 @@ struct V9fsTransport { > > va_list ap); > > ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char > > *fmt, > >va_list ap); > > -void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, > > - unsigned int *pniov, bool is_write); > > +void(*init_in_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, > > +unsigned int *pniov, size_t size); > > +void(*init_out_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, > > + unsigned int *pniov); > > void(*push_and_notify)(V9fsPDU *pdu); > > }; > > > > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c > > index 273425b..27a4a32 100644 > > --- a/hw/9pfs/virtio-9p-device.c > > +++ b/hw/9pfs/virtio-9p-device.c > > @@ -171,26 +171,34 @@ static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, > > size_t offset, > > return v9fs_iov_vunmarshal(elem->out_sg, elem->out_num, offset, 1, > > fmt, ap); > > } > > > > -static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, > > - unsigned int *pniov, bool is_write) > > +/* The size parameter is used by other transports. Do not drop it. */ > > +static void virtio_init_in_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, > > +unsigned int *pniov, size_t size) > > { > > V9fsState *s = pdu->s; > > V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); > > VirtQueueElement *elem = v->elems[pdu->idx]; > > > > -if (is_write) { > > -*piov = elem->out_sg; > > -*pniov = elem->out_num; > > -} else { > > -*piov = elem->in_sg; > > -*pniov = elem->in_num; > > -} > > +*piov = elem->in_sg; > > +*pniov = elem->in_num; > > +} > > + > > +static void virtio_init_out_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, > > + unsigned int *pniov) > > +{ > > +V9fsState *s = pdu->s; > > +V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); > > +VirtQueueElement *elem = v->elems[pdu->idx]; > > + > > +*piov = elem->out_sg; > > +*pniov = elem->out_num; > > } > > > > static const struct V9fsTransport virtio_9p_transport = { > > .pdu_vmarshal = virtio_pdu_vmarshal, > > .pdu_vunmarshal = virtio_pdu_vunmarshal, > > -.init_iov_from_pdu = virtio_init_iov_from_pdu, > > +.init_in_iov_from_pdu = virtio_init_in_iov_from_pdu, > > +.init_out_iov_from_pdu = virtio_init_out_iov_from_pdu, > > .push_and_notify = virtio_9p_push_and_notify, > > }; > > > > > ___ > Xen-devel mailing list > xen-de...@lists.xen.org > https://lists.xen.org/xen-devel >
[Qemu-devel] [PATCH v2 2/4] 9pfs: introduce transport specific callbacks
Don't call virtio functions from 9pfs generic code, use generic function callbacks instead. Signed-off-by: Stefano Stabellini --- Changes in v2: - constify virtio_9p_transport and V9fsTransport - assert !s->transport. - code style --- hw/9pfs/9p.c | 8 hw/9pfs/9p.h | 19 +++ hw/9pfs/virtio-9p-device.c | 24 +--- hw/9pfs/virtio-9p.h| 9 - 4 files changed, 40 insertions(+), 20 deletions(-) diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index 05e950f..5a20a13 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -47,7 +47,7 @@ ssize_t pdu_marshal(V9fsPDU *pdu, size_t offset, const char *fmt, ...) va_list ap; va_start(ap, fmt); -ret = virtio_pdu_vmarshal(pdu, offset, fmt, ap); +ret = pdu->s->transport->pdu_vmarshal(pdu, offset, fmt, ap); va_end(ap); return ret; @@ -59,7 +59,7 @@ ssize_t pdu_unmarshal(V9fsPDU *pdu, size_t offset, const char *fmt, ...) va_list ap; va_start(ap, fmt); -ret = virtio_pdu_vunmarshal(pdu, offset, fmt, ap); +ret = pdu->s->transport->pdu_vunmarshal(pdu, offset, fmt, ap); va_end(ap); return ret; @@ -67,7 +67,7 @@ ssize_t pdu_unmarshal(V9fsPDU *pdu, size_t offset, const char *fmt, ...) static void pdu_push_and_notify(V9fsPDU *pdu) { -virtio_9p_push_and_notify(pdu); +pdu->s->transport->push_and_notify(pdu); } static int omode_to_uflags(int8_t mode) @@ -1751,7 +1751,7 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, struct iovec *iov; unsigned int niov; -virtio_init_iov_from_pdu(pdu, &iov, &niov, is_write); +pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); qemu_iovec_init_external(&elem, iov, niov); qemu_iovec_init(qiov, niov); diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h index 07cee01..c8c9aa8 100644 --- a/hw/9pfs/9p.h +++ b/hw/9pfs/9p.h @@ -230,6 +230,7 @@ typedef struct V9fsState enum p9_proto_version proto_version; int32_t msize; V9fsPDU pdus[MAX_REQ]; +const struct V9fsTransport *transport; /* * lock ensuring atomic path update * on rename. @@ -343,4 +344,22 @@ void pdu_free(V9fsPDU *pdu); void pdu_submit(V9fsPDU *pdu); void v9fs_reset(V9fsState *s); +struct V9fsTransport { +ssize_t (*pdu_vmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt, +va_list ap); +ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt, + va_list ap); +void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, + unsigned int *pniov, bool is_write); +void(*push_and_notify)(V9fsPDU *pdu); +}; + +static inline int v9fs_register_transport(V9fsState *s, +const struct V9fsTransport *t) +{ +assert(!s->transport); +s->transport = t; +return 0; +} + #endif diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index 1782e4a..273425b 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -20,7 +20,9 @@ #include "hw/virtio/virtio-access.h" #include "qemu/iov.h" -void virtio_9p_push_and_notify(V9fsPDU *pdu) +static const struct V9fsTransport virtio_9p_transport; + +static void virtio_9p_push_and_notify(V9fsPDU *pdu) { V9fsState *s = pdu->s; V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); @@ -126,6 +128,7 @@ static void virtio_9p_device_realize(DeviceState *dev, Error **errp) v->config_size = sizeof(struct virtio_9p_config) + strlen(s->fsconf.tag); virtio_init(vdev, "virtio-9p", VIRTIO_ID_9P, v->config_size); v->vq = virtio_add_queue(vdev, MAX_REQ, handle_9p_output); +v9fs_register_transport(s, &virtio_9p_transport); out: return; @@ -148,8 +151,8 @@ static void virtio_9p_reset(VirtIODevice *vdev) v9fs_reset(&v->state); } -ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset, -const char *fmt, va_list ap) +static ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset, + const char *fmt, va_list ap) { V9fsState *s = pdu->s; V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); @@ -158,8 +161,8 @@ ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset, return v9fs_iov_vmarshal(elem->in_sg, elem->in_num, offset, 1, fmt, ap); } -ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset, - const char *fmt, va_list ap) +static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset, + const char *fmt, va_list ap) { V9fsState *s = pdu->s; V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); @@ -168,8 +171,8 @@ ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset,
[Qemu-devel] [PATCH v2 3/4] 9pfs: call v9fs_init_qiov_from_pdu before v9fs_pack
v9fs_xattr_read should not access VirtQueueElement elems directly. Move v9fs_init_qiov_from_pdu up in the file and call v9fs_init_qiov_from_pdu before v9fs_pack. Use v9fs_pack on the new iovec. Signed-off-by: Stefano Stabellini --- Changes in v2: - add a call to qemu_iovec_destroy - fix commit description --- hw/9pfs/9p.c | 59 ++- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index 5a20a13..79d7201 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -1633,14 +1633,39 @@ out_nofid: pdu_complete(pdu, err); } +/* + * Create a QEMUIOVector for a sub-region of PDU iovecs + * + * @qiov: uninitialized QEMUIOVector + * @skip: number of bytes to skip from beginning of PDU + * @size: number of bytes to include + * @is_write: true - write, false - read + * + * The resulting QEMUIOVector has heap-allocated iovecs and must be cleaned up + * with qemu_iovec_destroy(). + */ +static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, +size_t skip, size_t size, +bool is_write) +{ +QEMUIOVector elem; +struct iovec *iov; +unsigned int niov; + +pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); + +qemu_iovec_init_external(&elem, iov, niov); +qemu_iovec_init(qiov, niov); +qemu_iovec_concat(qiov, &elem, skip, size); +} + static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp, uint64_t off, uint32_t max_count) { ssize_t err; size_t offset = 7; uint64_t read_count; -V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); -VirtQueueElement *elem = v->elems[pdu->idx]; +QEMUIOVector qiov_full; if (fidp->fs.xattr.len < off) { read_count = 0; @@ -1656,9 +1681,11 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp, } offset += err; -err = v9fs_pack(elem->in_sg, elem->in_num, offset, +v9fs_init_qiov_from_pdu(&qiov_full, pdu, 0, read_count, false); +err = v9fs_pack(qiov_full.iov, qiov_full.niov, offset, ((char *)fidp->fs.xattr.value) + off, read_count); +qemu_iovec_destroy(&qiov_full); if (err < 0) { return err; } @@ -1732,32 +1759,6 @@ static int coroutine_fn v9fs_do_readdir_with_stat(V9fsPDU *pdu, return count; } -/* - * Create a QEMUIOVector for a sub-region of PDU iovecs - * - * @qiov: uninitialized QEMUIOVector - * @skip: number of bytes to skip from beginning of PDU - * @size: number of bytes to include - * @is_write: true - write, false - read - * - * The resulting QEMUIOVector has heap-allocated iovecs and must be cleaned up - * with qemu_iovec_destroy(). - */ -static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, -size_t skip, size_t size, -bool is_write) -{ -QEMUIOVector elem; -struct iovec *iov; -unsigned int niov; - -pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); - -qemu_iovec_init_external(&elem, iov, niov); -qemu_iovec_init(qiov, niov); -qemu_iovec_concat(qiov, &elem, skip, size); -} - static void coroutine_fn v9fs_read(void *opaque) { int32_t fid; -- 1.9.1
[Qemu-devel] [PATCH v2 1/4] 9pfs: move pdus to V9fsState
pdus are initialized and used in 9pfs common code. Move the array from V9fsVirtioState to V9fsState. Signed-off-by: Stefano Stabellini Reviewed-by: Greg Kurz --- hw/9pfs/9p.c| 7 +++ hw/9pfs/9p.h| 1 + hw/9pfs/virtio-9p.h | 1 - 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index aea7e9d..05e950f 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -3440,7 +3440,6 @@ void pdu_submit(V9fsPDU *pdu) /* Returns 0 on success, 1 on failure. */ int v9fs_device_realize_common(V9fsState *s, Error **errp) { -V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); int i, len; struct stat stat; FsDriverEntry *fse; @@ -3451,9 +3450,9 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp) QLIST_INIT(&s->free_list); QLIST_INIT(&s->active_list); for (i = 0; i < (MAX_REQ - 1); i++) { -QLIST_INSERT_HEAD(&s->free_list, &v->pdus[i], next); -v->pdus[i].s = s; -v->pdus[i].idx = i; +QLIST_INSERT_HEAD(&s->free_list, &s->pdus[i], next); +s->pdus[i].s = s; +s->pdus[i].idx = i; } v9fs_path_init(&path); diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h index 3976b7f..07cee01 100644 --- a/hw/9pfs/9p.h +++ b/hw/9pfs/9p.h @@ -229,6 +229,7 @@ typedef struct V9fsState char *tag; enum p9_proto_version proto_version; int32_t msize; +V9fsPDU pdus[MAX_REQ]; /* * lock ensuring atomic path update * on rename. diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h index 25c47c7..52c4b9d 100644 --- a/hw/9pfs/virtio-9p.h +++ b/hw/9pfs/virtio-9p.h @@ -10,7 +10,6 @@ typedef struct V9fsVirtioState VirtIODevice parent_obj; VirtQueue *vq; size_t config_size; -V9fsPDU pdus[MAX_REQ]; VirtQueueElement *elems[MAX_REQ]; V9fsState state; } V9fsVirtioState; -- 1.9.1
[Qemu-devel] [PATCH v2 4/4] 9pfs: introduce init_out/in_iov_from_pdu
Not all 9pfs transports share memory between request and response. For those who don't, it is necessary to know how much memory is required in the response. Split the existing init_iov_from_pdu function in two: init_out_iov_from_pdu (for writes) and init_in_iov_from_pdu (for reads). init_in_iov_from_pdu takes an additional size parameter to specify the memory required for the response message. Signed-off-by: Stefano Stabellini --- hw/9pfs/9p.c | 6 +- hw/9pfs/9p.h | 6 -- hw/9pfs/virtio-9p-device.c | 28 ++-- 3 files changed, 27 insertions(+), 13 deletions(-) diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index 79d7201..ce1f9d9 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -1652,7 +1652,11 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, struct iovec *iov; unsigned int niov; -pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); +if (is_write) { +pdu->s->transport->init_out_iov_from_pdu(pdu, &iov, &niov); +} else { +pdu->s->transport->init_in_iov_from_pdu(pdu, &iov, &niov, size); +} qemu_iovec_init_external(&elem, iov, niov); qemu_iovec_init(qiov, niov); diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h index c8c9aa8..4c4feaf 100644 --- a/hw/9pfs/9p.h +++ b/hw/9pfs/9p.h @@ -349,8 +349,10 @@ struct V9fsTransport { va_list ap); ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt, va_list ap); -void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, - unsigned int *pniov, bool is_write); +void(*init_in_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, +unsigned int *pniov, size_t size); +void(*init_out_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, + unsigned int *pniov); void(*push_and_notify)(V9fsPDU *pdu); }; diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index 273425b..27a4a32 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -171,26 +171,34 @@ static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset, return v9fs_iov_vunmarshal(elem->out_sg, elem->out_num, offset, 1, fmt, ap); } -static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, - unsigned int *pniov, bool is_write) +/* The size parameter is used by other transports. Do not drop it. */ +static void virtio_init_in_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, +unsigned int *pniov, size_t size) { V9fsState *s = pdu->s; V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); VirtQueueElement *elem = v->elems[pdu->idx]; -if (is_write) { -*piov = elem->out_sg; -*pniov = elem->out_num; -} else { -*piov = elem->in_sg; -*pniov = elem->in_num; -} +*piov = elem->in_sg; +*pniov = elem->in_num; +} + +static void virtio_init_out_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, + unsigned int *pniov) +{ +V9fsState *s = pdu->s; +V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); +VirtQueueElement *elem = v->elems[pdu->idx]; + +*piov = elem->out_sg; +*pniov = elem->out_num; } static const struct V9fsTransport virtio_9p_transport = { .pdu_vmarshal = virtio_pdu_vmarshal, .pdu_vunmarshal = virtio_pdu_vunmarshal, -.init_iov_from_pdu = virtio_init_iov_from_pdu, +.init_in_iov_from_pdu = virtio_init_in_iov_from_pdu, +.init_out_iov_from_pdu = virtio_init_out_iov_from_pdu, .push_and_notify = virtio_9p_push_and_notify, }; -- 1.9.1
[Qemu-devel] [PATCH v2 0/4] 9pfs: clean-up for multiple transports
Hi all, this small patch series provides a few fixes and clean-ups in preparation for the introduction of a 9pfs Xen transport. Changes in v2: - constify virtio_9p_transport and V9fsTransport - assert !s->transport. - code style - add a call to qemu_iovec_destroy - fix commit description of patch #3 - introduce init_out/in_iov_from_pdu Stefano Stabellini (4): 9pfs: move pdus to V9fsState 9pfs: introduce transport specific callbacks 9pfs: use v9fs_init_qiov_from_pdu instead of v9fs_pack 9pfs: introduce init_out/in_iov_from_pdu hw/9pfs/9p.c | 76 -- hw/9pfs/9p.h | 22 ++ hw/9pfs/virtio-9p-device.c | 46 +++- hw/9pfs/virtio-9p.h| 10 -- 4 files changed, 94 insertions(+), 60 deletions(-)
Re: [Qemu-devel] [PATCH 4/4] 9pfs: add a size parameter to init_iov_from_pdu
On Thu, 24 Nov 2016, Greg Kurz wrote: > On Mon, 21 Nov 2016 13:39:32 -0800 > Stefano Stabellini wrote: > > > Not all 9pfs transports share memory between request and response. For > > those who don't, it is necessary to know how much memory is required in > > the response. > > > > Signed-off-by: Stefano Stabellini > > --- > > IIUC the transport used in Xen requires you pass the size when sending a > P9_RREAD message back to the guest, i.e. only in the case when is_write is > false, correct ? That's right > If so, for better clarity, what about having two distinct init_in_iov_from_pdu > and init_out_iov_from_pdu ops, with an explicit comment in the virtio-9p > implementation of init_in_iov_from_pdu so that someone isn't tempted to drop > the apparently unused size argument ? Would this be ok for you on the Xen > side ? Sure, that's fine by me. I'll do that. > Cheers. > > -- > Greg > > > hw/9pfs/9p.c | 2 +- > > hw/9pfs/9p.h | 2 +- > > hw/9pfs/virtio-9p-device.c | 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > index b6ec042..b82212b 100644 > > --- a/hw/9pfs/9p.c > > +++ b/hw/9pfs/9p.c > > @@ -1652,7 +1652,7 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector > > *qiov, V9fsPDU *pdu, > > struct iovec *iov; > > unsigned int niov; > > > > -pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); > > +pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write, skip > > + size); > > > > qemu_iovec_init_external(&elem, iov, niov); > > qemu_iovec_init(qiov, niov); > > diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h > > index ab398d0..c830188 100644 > > --- a/hw/9pfs/9p.h > > +++ b/hw/9pfs/9p.h > > @@ -348,7 +348,7 @@ struct V9fsTransport { > > ssize_t (*pdu_vmarshal)(V9fsPDU *pdu, size_t offset, const char > > *fmt, va_list ap); > > ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char > > *fmt, va_list ap); > > void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, > > - unsigned int *pniov, bool is_write); > > + unsigned int *pniov, bool is_write, size_t > > size); > > void(*push_and_notify)(V9fsPDU *pdu); > > }; > > > > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c > > index e1a37a4..e2b27e8 100644 > > --- a/hw/9pfs/virtio-9p-device.c > > +++ b/hw/9pfs/virtio-9p-device.c > > @@ -172,7 +172,7 @@ static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, > > size_t offset, > > } > > > > static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, > > - unsigned int *pniov, bool is_write) > > + unsigned int *pniov, bool is_write, size_t > > size) > > { > > V9fsState *s = pdu->s; > > V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); >
Re: [Qemu-devel] [PATCH 3/4] 9pfs: use v9fs_init_qiov_from_pdu instead of v9fs_pack
On Thu, 24 Nov 2016, Greg Kurz wrote: > On Mon, 21 Nov 2016 13:39:31 -0800 > Stefano Stabellini wrote: > > > v9fs_xattr_read should not access VirtQueueElement elems directly. > > Move v9fs_init_qiov_from_pdu up in the file and call > > v9fs_init_qiov_from_pdu instead of v9fs_pack. > > > > instead of ? I see v9fs_init_qiov_from_pdu() gets called before calling > v9fs_pack(). Sorry wrong description. I'll fix it. > Also, I don't see the corresponding call to qemu_iovec_destroy() to free the > allocated iovec. Good point! I'll add a call. > > Signed-off-by: Stefano Stabellini > > --- > > hw/9pfs/9p.c | 58 > > +- > > 1 file changed, 29 insertions(+), 29 deletions(-) > > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > index 5a20a13..b6ec042 100644 > > --- a/hw/9pfs/9p.c > > +++ b/hw/9pfs/9p.c > > @@ -1633,14 +1633,39 @@ out_nofid: > > pdu_complete(pdu, err); > > } > > > > +/* > > + * Create a QEMUIOVector for a sub-region of PDU iovecs > > + * > > + * @qiov: uninitialized QEMUIOVector > > + * @skip: number of bytes to skip from beginning of PDU > > + * @size: number of bytes to include > > + * @is_write: true - write, false - read > > + * > > + * The resulting QEMUIOVector has heap-allocated iovecs and must be > > cleaned up > > + * with qemu_iovec_destroy(). > > + */ > > +static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, > > +size_t skip, size_t size, > > +bool is_write) > > +{ > > +QEMUIOVector elem; > > +struct iovec *iov; > > +unsigned int niov; > > + > > +pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); > > + > > +qemu_iovec_init_external(&elem, iov, niov); > > +qemu_iovec_init(qiov, niov); > > +qemu_iovec_concat(qiov, &elem, skip, size); > > +} > > + > > static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp, > > uint64_t off, uint32_t max_count) > > { > > ssize_t err; > > size_t offset = 7; > > uint64_t read_count; > > -V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); > > -VirtQueueElement *elem = v->elems[pdu->idx]; > > +QEMUIOVector qiov_full; > > > > if (fidp->fs.xattr.len < off) { > > read_count = 0; > > @@ -1656,7 +1681,8 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU > > *pdu, V9fsFidState *fidp, > > } > > offset += err; > > > > -err = v9fs_pack(elem->in_sg, elem->in_num, offset, > > +v9fs_init_qiov_from_pdu(&qiov_full, pdu, 0, read_count, false); > > +err = v9fs_pack(qiov_full.iov, qiov_full.niov, offset, > > ((char *)fidp->fs.xattr.value) + off, > > read_count); > > if (err < 0) { > > @@ -1732,32 +1758,6 @@ static int coroutine_fn > > v9fs_do_readdir_with_stat(V9fsPDU *pdu, > > return count; > > } > > > > -/* > > - * Create a QEMUIOVector for a sub-region of PDU iovecs > > - * > > - * @qiov: uninitialized QEMUIOVector > > - * @skip: number of bytes to skip from beginning of PDU > > - * @size: number of bytes to include > > - * @is_write: true - write, false - read > > - * > > - * The resulting QEMUIOVector has heap-allocated iovecs and must be > > cleaned up > > - * with qemu_iovec_destroy(). > > - */ > > -static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, > > -size_t skip, size_t size, > > -bool is_write) > > -{ > > -QEMUIOVector elem; > > -struct iovec *iov; > > -unsigned int niov; > > - > > -pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); > > - > > -qemu_iovec_init_external(&elem, iov, niov); > > -qemu_iovec_init(qiov, niov); > > -qemu_iovec_concat(qiov, &elem, skip, size); > > -} > > - > > static void coroutine_fn v9fs_read(void *opaque) > > { > > int32_t fid; >
Re: [Qemu-devel] [Xen-devel] [PATCH 2/4] 9pfs: introduce transport specific callbacks
On Thu, 24 Nov 2016, Greg Kurz wrote: > On Thu, 24 Nov 2016 15:23:10 +0100 > Greg Kurz wrote: > > > On Thu, 24 Nov 2016 09:31:52 +0100 > > Greg Kurz wrote: > > > > > On Mon, 21 Nov 2016 13:39:30 -0800 > > > Stefano Stabellini wrote: > > > > > > > Don't call virtio functions from 9pfs generic code, use generic function > > > > callbacks instead. > > > > > > > > Signed-off-by: Stefano Stabellini > > > > --- > > > > > > Just a couple of indentation and line over 80 characters nits. I'll fix > > > them > > > before pushing to 9p-next. > > > > > > Reviewed-by: Greg Kurz > > > > > > > Hmm... second thought... > > > > [...] > > > > > + > > > > +static inline int v9fs_register_transport(V9fsState *s, struct > > > > V9fsTransport *t) > > > > +{ > > > > +if (s->transport) { > > > > +return -EINVAL; > > > > +} > > Calling v9fs_register_transport() several times for the same V9fsState looks > more like a bug than an error... Yes, you are right. I can turn this into an assert. > also, is it possible to have several 9pfs > shares with different transports ? I think, at least theoretically, is possible. For example Xen HVM guests, the ones most similar to KVM guests, already support virtio as a transport. Additionally they will be able to support the Xen based transport too. (Xen PV guests will only support the Xen based transport as they don't support virtio in general.)
Re: [Qemu-devel] [Xen-devel] [PATCH 2/4] 9pfs: introduce transport specific callbacks
On Thu, 24 Nov 2016, Greg Kurz wrote: > > > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c > > > index 1782e4a..e1a37a4 100644 > > > --- a/hw/9pfs/virtio-9p-device.c > > > +++ b/hw/9pfs/virtio-9p-device.c > > > @@ -20,7 +20,9 @@ > > > #include "hw/virtio/virtio-access.h" > > > #include "qemu/iov.h" > > > > > > -void virtio_9p_push_and_notify(V9fsPDU *pdu) > > > +static struct V9fsTransport virtio_9p_transport; > > ... shouldn't this be const ? Yes, makes sense.
[Qemu-devel] [PULL 3/4] xen: slightly simplify bufioreq handling
From: Jan Beulich There's no point setting fields always receiving the same value on each iteration, as handle_ioreq() doesn't alter them anyway. Set state and count once ahead of the loop, drop the redundant clearing of data_is_ptr, and avoid the meaningless (because count is 1) setting of df altogether. Also avoid doing an unsigned long calculation of size when the field to be initialized is only 32 bits wide (and the shift value in the range 0...3). Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Reviewed-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- xen-hvm.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/xen-hvm.c b/xen-hvm.c index d74e233..124ae10 100644 --- a/xen-hvm.c +++ b/xen-hvm.c @@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOState *state) } memset(&req, 0x00, sizeof(req)); +req.state = STATE_IOREQ_READY; +req.count = 1; for (;;) { uint32_t rdptr = buf_page->read_pointer, wrptr; @@ -1009,15 +1011,11 @@ static int handle_buffered_iopage(XenIOState *state) break; } buf_req = &buf_page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM]; -req.size = 1UL << buf_req->size; -req.count = 1; +req.size = 1U << buf_req->size; req.addr = buf_req->addr; req.data = buf_req->data; -req.state = STATE_IOREQ_READY; req.dir = buf_req->dir; -req.df = 1; req.type = buf_req->type; -req.data_is_ptr = 0; xen_rmb(); qw = (req.size == 8); if (qw) { @@ -1032,6 +1030,13 @@ static int handle_buffered_iopage(XenIOState *state) handle_ioreq(state, &req); +/* Only req.data may get updated by handle_ioreq(), albeit even that + * should not happen as such data would never make it to the guest. + */ +assert(req.state == STATE_IOREQ_READY); +assert(req.count == 1); +assert(!req.data_is_ptr); + atomic_add(&buf_page->read_pointer, qw + 1); } -- 1.9.1
[Qemu-devel] [PULL 4/4] xen: ignore direction in bufioreq handling
From: Jan Beulich There's no way to communicate back read data, so only writes can ever be usefully specified. Ignore the field, paving the road for eventually re-using the bit for something else in a few (many?) years time. Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Acked-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- xen-hvm.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen-hvm.c b/xen-hvm.c index 124ae10..0892361 100644 --- a/xen-hvm.c +++ b/xen-hvm.c @@ -997,6 +997,7 @@ static int handle_buffered_iopage(XenIOState *state) memset(&req, 0x00, sizeof(req)); req.state = STATE_IOREQ_READY; req.count = 1; +req.dir = IOREQ_WRITE; for (;;) { uint32_t rdptr = buf_page->read_pointer, wrptr; @@ -1014,7 +1015,6 @@ static int handle_buffered_iopage(XenIOState *state) req.size = 1U << buf_req->size; req.addr = buf_req->addr; req.data = buf_req->data; -req.dir = buf_req->dir; req.type = buf_req->type; xen_rmb(); qw = (req.size == 8); @@ -1031,10 +1031,12 @@ static int handle_buffered_iopage(XenIOState *state) handle_ioreq(state, &req); /* Only req.data may get updated by handle_ioreq(), albeit even that - * should not happen as such data would never make it to the guest. + * should not happen as such data would never make it to the guest (we + * can only usefully see writes here after all). */ assert(req.state == STATE_IOREQ_READY); assert(req.count == 1); +assert(req.dir == IOREQ_WRITE); assert(!req.data_is_ptr); atomic_add(&buf_page->read_pointer, qw + 1); -- 1.9.1
[Qemu-devel] [PULL 1/4] xen_disk: split discard input to match internal representation
From: Olaf Hering The guest sends discard requests as u64 sector/count pairs, but the block layer operates internally with s64/s32 pairs. The conversion leads to IO errors in the guest, the discard request is not processed. domU.cfg: 'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2' domU: mkfs.ext4 -F /dev/xvda Discarding device blocks: failed - Input/output error Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. Add input range checking to avoid overflow. Fixes f313520 ("xen_disk: add discard support") Signed-off-by: Olaf Hering Reviewed-by: Eric Blake Reviewed-by: Stefano Stabellini --- hw/block/xen_disk.c | 42 -- 1 file changed, 36 insertions(+), 6 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 3a7dc19..456a2d5 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -660,6 +660,38 @@ static void qemu_aio_complete(void *opaque, int ret) qemu_bh_schedule(ioreq->blkdev->bh); } +static bool blk_split_discard(struct ioreq *ioreq, blkif_sector_t sector_number, + uint64_t nr_sectors) +{ +struct XenBlkDev *blkdev = ioreq->blkdev; +int64_t byte_offset; +int byte_chunk; +uint64_t byte_remaining, limit; +uint64_t sec_start = sector_number; +uint64_t sec_count = nr_sectors; + +/* Wrap around, or overflowing byte limit? */ +if (sec_start + sec_count < sec_count || +sec_start + sec_count > INT64_MAX >> BDRV_SECTOR_BITS) { +return false; +} + +limit = BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS; +byte_offset = sec_start << BDRV_SECTOR_BITS; +byte_remaining = sec_count << BDRV_SECTOR_BITS; + +do { +byte_chunk = byte_remaining > limit ? limit : byte_remaining; +ioreq->aio_inflight++; +blk_aio_pdiscard(blkdev->blk, byte_offset, byte_chunk, + qemu_aio_complete, ioreq); +byte_remaining -= byte_chunk; +byte_offset += byte_chunk; +} while (byte_remaining > 0); + +return true; +} + static int ioreq_runio_qemu_aio(struct ioreq *ioreq) { struct XenBlkDev *blkdev = ioreq->blkdev; @@ -708,12 +740,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) break; case BLKIF_OP_DISCARD: { -struct blkif_request_discard *discard_req = (void *)&ioreq->req; -ioreq->aio_inflight++; -blk_aio_pdiscard(blkdev->blk, - discard_req->sector_number << BDRV_SECTOR_BITS, - discard_req->nr_sectors << BDRV_SECTOR_BITS, - qemu_aio_complete, ioreq); +struct blkif_request_discard *req = (void *)&ioreq->req; +if (!blk_split_discard(ioreq, req->sector_number, req->nr_sectors)) { +goto err; +} break; } default: -- 1.9.1
[Qemu-devel] [PULL 2/4] xen: fix quad word bufioreq handling
From: Jan Beulich We should not consume the second slot if it didn't get written yet. Normal writers - i.e. Xen - would not update write_pointer between the two writes, but the page may get fiddled with by the guest itself, and we're better off avoiding to enter an infinite loop in that case. Reported-by: yanghongke Signed-off-by: Jan Beulich Reviewed-by: Paul Durrant Reviewed-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- xen-hvm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen-hvm.c b/xen-hvm.c index 99b8ee8..d74e233 100644 --- a/xen-hvm.c +++ b/xen-hvm.c @@ -1021,6 +1021,9 @@ static int handle_buffered_iopage(XenIOState *state) xen_rmb(); qw = (req.size == 8); if (qw) { +if (rdptr + 1 == wrptr) { +hw_error("Incomplete quad word buffered ioreq"); +} buf_req = &buf_page->buf_ioreq[(rdptr + 1) % IOREQ_BUFFER_SLOT_NUM]; req.data |= ((uint64_t)buf_req->data) << 32; -- 1.9.1
[Qemu-devel] [PULL for-2.8 0/4] tags/xen-20161128-tag
The following changes since commit 00227fefd2059464cd2f59aed29944874c630e2f: Update version for v2.8.0-rc1 release (2016-11-22 22:29:08 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161128-tag for you to fetch changes up to e514379de52573131ccc47441787e5fab6dbfc08: xen: ignore direction in bufioreq handling (2016-11-28 11:26:29 -0800) Xen 2016/11/28 Jan Beulich (3): xen: fix quad word bufioreq handling xen: slightly simplify bufioreq handling xen: ignore direction in bufioreq handling Olaf Hering (1): xen_disk: split discard input to match internal representation hw/block/xen_disk.c | 42 -- xen-hvm.c | 22 -- 2 files changed, 52 insertions(+), 12 deletions(-)
Re: [Qemu-devel] [PATCH v2 2/3] xen: slightly simplify bufioreq handling
On Fri, 25 Nov 2016, Jan Beulich wrote: > There's no point setting fields always receiving the same value on each > iteration, as handle_ioreq() doesn't alter them anyway. Set state and > count once ahead of the loop, drop the redundant clearing of > data_is_ptr, and avoid the meaningless setting of df altogether. > > Also avoid doing an unsigned long calculation of size when the field to > be initialized is only 32 bits wide (and the shift value in the range > 0...3). > > Signed-off-by: Jan Beulich > Reviewed-by: Paul Durrant Reviewed-by: Stefano Stabellini > --- a/xen-hvm.c > +++ b/xen-hvm.c > @@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOS > } > > memset(&req, 0x00, sizeof(req)); > +req.state = STATE_IOREQ_READY; > +req.count = 1; > > for (;;) { > uint32_t rdptr = buf_page->read_pointer, wrptr; > @@ -1009,15 +1011,11 @@ static int handle_buffered_iopage(XenIOS > break; > } > buf_req = &buf_page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM]; > -req.size = 1UL << buf_req->size; > -req.count = 1; > +req.size = 1U << buf_req->size; > req.addr = buf_req->addr; > req.data = buf_req->data; > -req.state = STATE_IOREQ_READY; > req.dir = buf_req->dir; > -req.df = 1; > req.type = buf_req->type; > -req.data_is_ptr = 0; > xen_rmb(); > qw = (req.size == 8); > if (qw) { > @@ -1032,6 +1030,13 @@ static int handle_buffered_iopage(XenIOS > > handle_ioreq(state, &req); > > +/* Only req.data may get updated by handle_ioreq(), albeit even that > + * should not happen as such data would never make it to the guest. > + */ > +assert(req.state == STATE_IOREQ_READY); > +assert(req.count == 1); > +assert(!req.data_is_ptr); > + > atomic_add(&buf_page->read_pointer, qw + 1); > } > > > >
Re: [Qemu-devel] [PATCH v2 1/3] xen: fix quad word bufioreq handling
On Fri, 25 Nov 2016, Jan Beulich wrote: > We should not consume the second slot if it didn't get written yet. > Normal writers - i.e. Xen - would not update write_pointer between the > two writes, but the page may get fiddled with by the guest itself, and > we're better off avoiding to enter an infinite loop in that case. > > Reported-by: yanghongke > Signed-off-by: Jan Beulich Reviewed-by: Stefano Stabellini > v2: Bail (using hw_error()) instead of just breaking the loop. > > --- a/xen-hvm.c > +++ b/xen-hvm.c > @@ -1021,6 +1021,9 @@ static int handle_buffered_iopage(XenIOS > xen_rmb(); > qw = (req.size == 8); > if (qw) { > +if (rdptr + 1 == wrptr) { > +hw_error("Incomplete quad word buffered ioreq"); > +} > buf_req = &buf_page->buf_ioreq[(rdptr + 1) % > IOREQ_BUFFER_SLOT_NUM]; > req.data |= ((uint64_t)buf_req->data) << 32; > > >
Re: [Qemu-devel] [PATCH] MAINTAINERS: Update xen-devel mailing list address
On Fri, 25 Nov 2016, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD Acked-by: Stefano Stabellini > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4a60579..1379317 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -309,7 +309,7 @@ Guest CPU Cores (Xen): > X86 > M: Stefano Stabellini > M: Anthony Perard > -L: xen-de...@lists.xensource.com > +L: xen-de...@lists.xenproject.org > S: Supported > F: xen-* > F: */xen* > -- > Anthony PERARD >
Re: [Qemu-devel] [PATCH] xen_disk: convert discard input to byte ranges
On Wed, 23 Nov 2016, Olaf Hering wrote: > On Wed, Nov 23, Olaf Hering wrote: > > > > > +if (!blk_split_discard(ioreq, req->sector_number, > > > > req->nr_sectors)) { > > > > +goto err; > > > How is error handling supposed to work here? > > In the guest the cmd is stuck, instead of getting an IO error: > > [ 91.966404] mkfs.ext4 D 0 2878 2831 > 0x > [ 91.966406] 88002204bc48 880030530480 88002fae5800 > 88002204c000 > [ 91.966407] 7fff 8000 > 024000c0 > [ 91.966409] 88002204bc60 815dd985 880038815c00 > 88002204bd08 > [ 91.966409] Call Trace: > [ 91.966413] [] schedule+0x35/0x80 > [ 91.966416] [] schedule_timeout+0x237/0x2d0 > [ 91.966419] [] io_schedule_timeout+0xa6/0x110 > [ 91.966421] [] wait_for_completion_io+0xa3/0x110 > [ 91.966425] [] submit_bio_wait+0x50/0x60 > [ 91.966430] [] blkdev_issue_discard+0x78/0xb0 > [ 91.966433] [] blk_ioctl_discard+0x7b/0xa0 > [ 91.966436] [] blkdev_ioctl+0x730/0x920 > [ 91.966440] [] block_ioctl+0x3d/0x40 > [ 91.966444] [] do_vfs_ioctl+0x2cd/0x4a0 > [ 91.966453] [] SyS_ioctl+0x74/0x80 > [ 91.966456] [] entry_SYSCALL_64_fastpath+0x12/0x6d The error should be sent back to the frontend via the status field. Not sure why blkfront is not hanlding it correctly.
Re: [Qemu-devel] [PATCH for-2.8 v3] xen_disk: split discard input to match internal representation
On Wed, 23 Nov 2016, Kevin Wolf wrote: > Am 23.11.2016 um 12:40 hat Eric Blake geschrieben: > > On 11/23/2016 04:39 AM, Olaf Hering wrote: > > > The guest sends discard requests as u64 sector/count pairs, but the > > > block layer operates internally with s64/s32 pairs. The conversion > > > leads to IO errors in the guest, the discard request is not processed. > > > > > > domU.cfg: > > > 'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2' > > > domU: > > > mkfs.ext4 -F /dev/xvda > > > Discarding device blocks: failed - Input/output error > > > > > > Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. > > > Add input range checking to avoid overflow. > > > > > > Fixes f313520 ("xen_disk: add discard support") > > > > > > Signed-off-by: Olaf Hering > > > --- > > > > Qualifies as a bug fix, so requesting 2.8 inclusion. > > Reviewed-by: Eric Blake > > Stefano, are you going to merge this or should I take a look? I can merge it. Cheers, Stefano
Re: [Qemu-devel] [PATCH v3] xen_disk: split discard input to match internal representation
On Wed, 23 Nov 2016, Olaf Hering wrote: > The guest sends discard requests as u64 sector/count pairs, but the > block layer operates internally with s64/s32 pairs. The conversion > leads to IO errors in the guest, the discard request is not processed. > > domU.cfg: > 'vdev=xvda, format=qcow2, backendtype=qdisk, target=/x.qcow2' > domU: > mkfs.ext4 -F /dev/xvda > Discarding device blocks: failed - Input/output error > > Fix this by splitting the request into chunks of BDRV_REQUEST_MAX_SECTORS. > Add input range checking to avoid overflow. > > Fixes f313520 ("xen_disk: add discard support") > > Signed-off-by: Olaf Hering Reviewed-by: Stefano Stabellini > v3: > turn tab into spaces to fix checkpatch warning > v2: > adjust overflow check > add Fixes revspec because the initial commit also failed to convert u64 to > s32 > adjust summary > > hw/block/xen_disk.c | 42 -- > 1 file changed, 36 insertions(+), 6 deletions(-) > > diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c > index 3a7dc19..456a2d5 100644 > --- a/hw/block/xen_disk.c > +++ b/hw/block/xen_disk.c > @@ -660,6 +660,38 @@ static void qemu_aio_complete(void *opaque, int ret) > qemu_bh_schedule(ioreq->blkdev->bh); > } > > +static bool blk_split_discard(struct ioreq *ioreq, blkif_sector_t > sector_number, > + uint64_t nr_sectors) > +{ > +struct XenBlkDev *blkdev = ioreq->blkdev; > +int64_t byte_offset; > +int byte_chunk; > +uint64_t byte_remaining, limit; > +uint64_t sec_start = sector_number; > +uint64_t sec_count = nr_sectors; > + > +/* Wrap around, or overflowing byte limit? */ > +if (sec_start + sec_count < sec_count || > +sec_start + sec_count > INT64_MAX >> BDRV_SECTOR_BITS) { > +return false; > +} > + > +limit = BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS; > +byte_offset = sec_start << BDRV_SECTOR_BITS; > +byte_remaining = sec_count << BDRV_SECTOR_BITS; > + > +do { > +byte_chunk = byte_remaining > limit ? limit : byte_remaining; > +ioreq->aio_inflight++; > +blk_aio_pdiscard(blkdev->blk, byte_offset, byte_chunk, > + qemu_aio_complete, ioreq); > +byte_remaining -= byte_chunk; > +byte_offset += byte_chunk; > +} while (byte_remaining > 0); > + > +return true; > +} > + > static int ioreq_runio_qemu_aio(struct ioreq *ioreq) > { > struct XenBlkDev *blkdev = ioreq->blkdev; > @@ -708,12 +740,10 @@ static int ioreq_runio_qemu_aio(struct ioreq *ioreq) > break; > case BLKIF_OP_DISCARD: > { > -struct blkif_request_discard *discard_req = (void *)&ioreq->req; > -ioreq->aio_inflight++; > -blk_aio_pdiscard(blkdev->blk, > - discard_req->sector_number << BDRV_SECTOR_BITS, > - discard_req->nr_sectors << BDRV_SECTOR_BITS, > - qemu_aio_complete, ioreq); > +struct blkif_request_discard *req = (void *)&ioreq->req; > +if (!blk_split_discard(ioreq, req->sector_number, req->nr_sectors)) { > +goto err; > +} > break; > } > default: >
Re: [Qemu-devel] [PATCH 3/3] xen: ignore direction in bufioreq handling
On Wed, 23 Nov 2016, Paul Durrant wrote: > > -Original Message- > > From: Jan Beulich [mailto:jbeul...@suse.com] > > Sent: 23 November 2016 09:25 > > To: qemu-devel@nongnu.org > > Cc: Anthony Perard ; Paul Durrant > > ; Stefano Stabellini ; xen- > > devel > > Subject: [PATCH 3/3] xen: ignore direction in bufioreq handling > > > > There's no way to communicate back read data, so only writes can ever > > be usefully specified. Ignore the field, paving the road for eventually > > re-using the bit for something else in a few (many?) years time. > > > > Signed-off-by: Jan Beulich > > Reviewed-by: Paul Durrant Acked-by: Stefano Stabellini > > > > --- a/xen-hvm.c > > +++ b/xen-hvm.c > > @@ -997,6 +997,7 @@ static int handle_buffered_iopage(XenIOS > > memset(&req, 0x00, sizeof(req)); > > req.state = STATE_IOREQ_READY; > > req.count = 1; > > +req.dir = IOREQ_WRITE; > > > > for (;;) { > > uint32_t rdptr = buf_page->read_pointer, wrptr; > > @@ -1014,7 +1015,6 @@ static int handle_buffered_iopage(XenIOS > > req.size = 1U << buf_req->size; > > req.addr = buf_req->addr; > > req.data = buf_req->data; > > -req.dir = buf_req->dir; > > req.type = buf_req->type; > > xen_rmb(); > > qw = (req.size == 8); > > @@ -1031,10 +1031,12 @@ static int handle_buffered_iopage(XenIOS > > handle_ioreq(state, &req); > > > > /* Only req.data may get updated by handle_ioreq(), albeit even > > that > > - * should not happen as such data would never make it to the guest. > > + * should not happen as such data would never make it to the guest > > (we > > + * can only usefully see writes here after all). > > */ > > assert(req.state == STATE_IOREQ_READY); > > assert(req.count == 1); > > +assert(req.dir == IOREQ_WRITE); > > assert(!req.data_is_ptr); > > > > atomic_add(&buf_page->read_pointer, qw + 1); > > > > >
Re: [Qemu-devel] [PATCH 1/3] xen: fix quad word bufioreq handling
On Wed, 23 Nov 2016, Jan Beulich wrote: > >>> On 23.11.16 at 11:45, wrote: > > No, if QEMU is using a default ioreq server (i.e. the legacy way of doing > > things) then it's vulnerable to the guest messing with the rings and I'd > > forgotten that migrated-in guests from old QEMUs also end up using the > > default > > server, so I guess this is a worthy checkt to make... although maybe it's > > best to just bail if the check fails, since it would indicate a malicious > > guest. > > Okay, that's basically the TBD note I have in the patch; I'll wait for > at least one of the qemu maintainers to voice their preference. I think we should just print an error and destroy_hvm_domain(false) or hw_error if the check fails.
Re: [Qemu-devel] [PATCH 2/3] xen: slightly simplify bufioreq handling
On Wed, 23 Nov 2016, Jan Beulich wrote: > There's no point setting fields always receiving the same value on each > iteration, as handle_ioreq() doesn't alter them anyway. Set state and > count once ahead of the loop, drop the redundant clearing of > data_is_ptr, and avoid the meaningless setting of df altogether. Why setting df is meaningless? > Also avoid doing an unsigned long calculation of size when the field to > be initialized is only 32 bits wide (and the shift value in the range > 0...3). > > Signed-off-by: Jan Beulich > > --- a/xen-hvm.c > +++ b/xen-hvm.c > @@ -995,6 +995,8 @@ static int handle_buffered_iopage(XenIOS > } > > memset(&req, 0x00, sizeof(req)); > +req.state = STATE_IOREQ_READY; > +req.count = 1; > > for (;;) { > uint32_t rdptr = buf_page->read_pointer, wrptr; > @@ -1009,15 +1011,11 @@ static int handle_buffered_iopage(XenIOS > break; > } > buf_req = &buf_page->buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM]; > -req.size = 1UL << buf_req->size; > -req.count = 1; > +req.size = 1U << buf_req->size; > req.addr = buf_req->addr; > req.data = buf_req->data; > -req.state = STATE_IOREQ_READY; > req.dir = buf_req->dir; > -req.df = 1; > req.type = buf_req->type; > -req.data_is_ptr = 0; > xen_rmb(); > qw = (req.size == 8); > if (qw) { > @@ -1032,6 +1030,13 @@ static int handle_buffered_iopage(XenIOS > > handle_ioreq(state, &req); > > +/* Only req.data may get updated by handle_ioreq(), albeit even that > + * should not happen as such data would never make it to the guest. > + */ > +assert(req.state == STATE_IOREQ_READY); > +assert(req.count == 1); > +assert(!req.data_is_ptr); > + > atomic_add(&buf_page->read_pointer, qw + 1); > } > > > >
[Qemu-devel] [PULL 5/5] xen: attach pvusb usb bus to backend qdev
From: Juergen Gross Attach the usb bus of a new pvusb controller to the qdev associated with the Xen backend. Any device connected to that controller can now specify the bus and port directly via its properties. Signed-off-by: Juergen Gross Reviewed-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- hw/usb/xen-usb.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c index 1b3c2fb..8e676e6 100644 --- a/hw/usb/xen-usb.c +++ b/hw/usb/xen-usb.c @@ -712,15 +712,10 @@ static void usbback_portid_detach(struct usbback_info *usbif, unsigned port) static void usbback_portid_remove(struct usbback_info *usbif, unsigned port) { -USBPort *p; - if (!usbif->ports[port - 1].dev) { return; } -p = &(usbif->ports[port - 1].port); -snprintf(p->path, sizeof(p->path), "%d", 99); - object_unparent(OBJECT(usbif->ports[port - 1].dev)); usbif->ports[port - 1].dev = NULL; usbback_portid_detach(usbif, port); @@ -733,10 +728,10 @@ static void usbback_portid_add(struct usbback_info *usbif, unsigned port, { unsigned speed; char *portname; -USBPort *p; Error *local_err = NULL; QDict *qdict; QemuOpts *opts; +char *tmp; if (usbif->ports[port - 1].dev) { return; @@ -749,11 +744,16 @@ static void usbback_portid_add(struct usbback_info *usbif, unsigned port, return; } portname++; -p = &(usbif->ports[port - 1].port); -snprintf(p->path, sizeof(p->path), "%s", portname); qdict = qdict_new(); qdict_put(qdict, "driver", qstring_from_str("usb-host")); +tmp = g_strdup_printf("%s.0", usbif->xendev.qdev.id); +qdict_put(qdict, "bus", qstring_from_str(tmp)); +g_free(tmp); +tmp = g_strdup_printf("%s-%u", usbif->xendev.qdev.id, port); +qdict_put(qdict, "id", qstring_from_str(tmp)); +g_free(tmp); +qdict_put(qdict, "port", qint_from_int(port)); qdict_put(qdict, "hostbus", qint_from_int(atoi(busid))); qdict_put(qdict, "hostport", qstring_from_str(portname)); opts = qemu_opts_from_qdict(qemu_find_opts("device"), qdict, &local_err); @@ -765,7 +765,6 @@ static void usbback_portid_add(struct usbback_info *usbif, unsigned port, goto err; } QDECREF(qdict); -snprintf(p->path, sizeof(p->path), "%d", port); speed = usbif->ports[port - 1].dev->speed; switch (speed) { case USB_SPEED_LOW: @@ -799,7 +798,6 @@ static void usbback_portid_add(struct usbback_info *usbif, unsigned port, err: QDECREF(qdict); -snprintf(p->path, sizeof(p->path), "%d", 99); xen_pv_printf(&usbif->xendev, 0, "device %s could not be opened\n", busid); } @@ -1012,13 +1010,13 @@ static void usbback_alloc(struct XenDevice *xendev) usbif = container_of(xendev, struct usbback_info, xendev); -usb_bus_new(&usbif->bus, sizeof(usbif->bus), &xen_usb_bus_ops, xen_sysdev); +usb_bus_new(&usbif->bus, sizeof(usbif->bus), &xen_usb_bus_ops, +DEVICE(&xendev->qdev)); for (i = 0; i < USBBACK_MAXPORTS; i++) { p = &(usbif->ports[i].port); usb_register_port(&usbif->bus, p, usbif, i, &xen_usb_port_ops, USB_SPEED_MASK_LOW | USB_SPEED_MASK_FULL | USB_SPEED_MASK_HIGH); -snprintf(p->path, sizeof(p->path), "%d", 99); } QTAILQ_INIT(&usbif->req_free_q); @@ -1066,7 +1064,6 @@ static int usbback_free(struct XenDevice *xendev) } usb_bus_release(&usbif->bus); -object_unparent(OBJECT(&usbif->bus)); TR_BUS(xendev, "finished\n"); -- 1.9.1
[Qemu-devel] [PULL 3/5] qdev: add function qdev_set_id()
From: Juergen Gross In order to have an easy way to add a new qdev with a specific id carve out the needed functionality from qdev_device_add() into a new function qdev_set_id(). Signed-off-by: Juergen Gross Reviewed-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- include/monitor/qdev.h | 1 + qdev-monitor.c | 36 2 files changed, 21 insertions(+), 16 deletions(-) diff --git a/include/monitor/qdev.h b/include/monitor/qdev.h index 8e504bc..0ff3331 100644 --- a/include/monitor/qdev.h +++ b/include/monitor/qdev.h @@ -12,5 +12,6 @@ void qmp_device_add(QDict *qdict, QObject **ret_data, Error **errp); int qdev_device_help(QemuOpts *opts); DeviceState *qdev_device_add(QemuOpts *opts, Error **errp); +void qdev_set_id(DeviceState *dev, const char *id); #endif diff --git a/qdev-monitor.c b/qdev-monitor.c index 4f78ecb..c73410c 100644 --- a/qdev-monitor.c +++ b/qdev-monitor.c @@ -539,10 +539,28 @@ static BusState *qbus_find(const char *path, Error **errp) return bus; } +void qdev_set_id(DeviceState *dev, const char *id) +{ +if (id) { +dev->id = id; +} + +if (dev->id) { +object_property_add_child(qdev_get_peripheral(), dev->id, + OBJECT(dev), NULL); +} else { +static int anon_count; +gchar *name = g_strdup_printf("device[%d]", anon_count++); +object_property_add_child(qdev_get_peripheral_anon(), name, + OBJECT(dev), NULL); +g_free(name); +} +} + DeviceState *qdev_device_add(QemuOpts *opts, Error **errp) { DeviceClass *dc; -const char *driver, *path, *id; +const char *driver, *path; DeviceState *dev; BusState *bus = NULL; Error *err = NULL; @@ -591,21 +609,7 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp) qdev_set_parent_bus(dev, bus); } -id = qemu_opts_id(opts); -if (id) { -dev->id = id; -} - -if (dev->id) { -object_property_add_child(qdev_get_peripheral(), dev->id, - OBJECT(dev), NULL); -} else { -static int anon_count; -gchar *name = g_strdup_printf("device[%d]", anon_count++); -object_property_add_child(qdev_get_peripheral_anon(), name, - OBJECT(dev), NULL); -g_free(name); -} +qdev_set_id(dev, qemu_opts_id(opts)); /* set properties */ if (qemu_opt_foreach(opts, set_property, dev, &err)) { -- 1.9.1
[Qemu-devel] [PULL 4/5] xen: create qdev for each backend device
From: Juergen Gross Create a qdev plugged to the xen-sysbus for each new backend device. This device can be used as a parent for all needed devices of that backend. The id of the new device will be "xen--" with being the xen backend type (e.g. "qdisk") and the xen backend number of the type under which it is to be found in xenstore. Signed-off-by: Juergen Gross Reviewed-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- hw/xen/xen_backend.c | 47 hw/xen/xen_pvdev.c | 4 +++- include/hw/xen/xen_backend.h | 4 include/hw/xen/xen_pvdev.h | 1 + 4 files changed, 55 insertions(+), 1 deletion(-) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 5ad3caa..d119004 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -27,11 +27,13 @@ #include "hw/hw.h" #include "hw/sysbus.h" +#include "hw/boards.h" #include "sysemu/char.h" #include "qemu/log.h" #include "qapi/error.h" #include "hw/xen/xen_backend.h" #include "hw/xen/xen_pvdev.h" +#include "monitor/qdev.h" #include @@ -121,6 +123,12 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev, /* init new xendev */ xendev = g_malloc0(ops->size); +object_initialize(&xendev->qdev, ops->size, TYPE_XENBACKEND); +qdev_set_parent_bus(&xendev->qdev, xen_sysbus); +qdev_set_id(&xendev->qdev, g_strdup_printf("xen-%s-%d", type, dev)); +qdev_init_nofail(&xendev->qdev); +object_unref(OBJECT(&xendev->qdev)); + xendev->type = type; xendev->dom = dom; xendev->dev = dev; @@ -541,6 +549,15 @@ err: return -1; } +static void xen_set_dynamic_sysbus(void) +{ +Object *machine = qdev_get_machine(); +ObjectClass *oc = object_get_class(machine); +MachineClass *mc = MACHINE_CLASS(oc); + +mc->has_dynamic_sysbus = true; +} + int xen_be_register(const char *type, struct XenDevOps *ops) { char path[50]; @@ -562,6 +579,8 @@ int xen_be_register(const char *type, struct XenDevOps *ops) void xen_be_register_common(void) { +xen_set_dynamic_sysbus(); + xen_be_register("console", &xen_console_ops); xen_be_register("vkbd", &xen_kbdmouse_ops); xen_be_register("qdisk", &xen_blkdev_ops); @@ -588,9 +607,36 @@ int xen_be_bind_evtchn(struct XenDevice *xendev) } +static Property xendev_properties[] = { +DEFINE_PROP_END_OF_LIST(), +}; + +static void xendev_class_init(ObjectClass *klass, void *data) +{ +DeviceClass *dc = DEVICE_CLASS(klass); + +dc->props = xendev_properties; +set_bit(DEVICE_CATEGORY_MISC, dc->categories); +} + +static const TypeInfo xendev_type_info = { +.name = TYPE_XENBACKEND, +.parent= TYPE_XENSYSDEV, +.class_init= xendev_class_init, +.instance_size = sizeof(struct XenDevice), +}; + +static void xen_sysbus_class_init(ObjectClass *klass, void *data) +{ +HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass); + +hc->unplug = qdev_simple_device_unplug_cb; +} + static const TypeInfo xensysbus_info = { .name = TYPE_XENSYSBUS, .parent = TYPE_BUS, +.class_init = xen_sysbus_class_init, .interfaces = (InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } @@ -627,6 +673,7 @@ static void xenbe_register_types(void) { type_register_static(&xensysbus_info); type_register_static(&xensysdev_info); +type_register_static(&xendev_type_info); } type_init(xenbe_register_types) diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c index 5212bc6..aed783e 100644 --- a/hw/xen/xen_pvdev.c +++ b/hw/xen/xen_pvdev.c @@ -19,6 +19,7 @@ #include "qemu/osdep.h" #include "qemu/log.h" +#include "hw/qdev-core.h" #include "hw/xen/xen_backend.h" #include "hw/xen/xen_pvdev.h" @@ -307,7 +308,8 @@ void xen_pv_del_xendev(struct XenDevice *xendev) } QTAILQ_REMOVE(&xendevs, xendev, next); -g_free(xendev); + +qdev_unplug(&xendev->qdev, NULL); } void xen_pv_insert_xendev(struct XenDevice *xendev) diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h index 38f730e..4f4799a 100644 --- a/include/hw/xen/xen_backend.h +++ b/include/hw/xen/xen_backend.h @@ -8,6 +8,10 @@ #define TYPE_XENSYSDEV "xen-sysdev" #define TYPE_XENSYSBUS "xen-sysbus" +#define TYPE_XENBACKEND "xen-backend" + +#define XENBACKEND_DEVICE(obj) \ +OBJECT_CHECK(XenDevice, (obj), TYPE_XENBACKEND) /* variables */ extern xc_interface *xen_xc; diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h index 083f0a9..d473e9b 100644 --- a/include/hw/xen/xen_pvdev.h +++ b/include/hw/xen/xen_pvdev.h @@ -29,6 +29,7 @@ struct XenDevOps { }; struct XenDevice { +DeviceStateqdev; const char *type; intdom; intdev; -- 1.9.1
[Qemu-devel] [PULL 1/5] xen: fix ioreq handling
From: Jan Beulich Avoid double fetches and bounds check size to avoid overflowing internal variables. This is CVE-2016-9381 / XSA-197. Reported-by: yanghongke Signed-off-by: Jan Beulich Reviewed-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- xen-hvm.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/xen-hvm.c b/xen-hvm.c index 150c7e7..99b8ee8 100644 --- a/xen-hvm.c +++ b/xen-hvm.c @@ -810,6 +810,10 @@ static void cpu_ioreq_pio(ioreq_t *req) trace_cpu_ioreq_pio(req, req->dir, req->df, req->data_is_ptr, req->addr, req->data, req->count, req->size); +if (req->size > sizeof(uint32_t)) { +hw_error("PIO: bad size (%u)", req->size); +} + if (req->dir == IOREQ_READ) { if (!req->data_is_ptr) { req->data = do_inp(req->addr, req->size); @@ -846,6 +850,10 @@ static void cpu_ioreq_move(ioreq_t *req) trace_cpu_ioreq_move(req, req->dir, req->df, req->data_is_ptr, req->addr, req->data, req->count, req->size); +if (req->size > sizeof(req->data)) { +hw_error("MMIO: bad size (%u)", req->size); +} + if (!req->data_is_ptr) { if (req->dir == IOREQ_READ) { for (i = 0; i < req->count; i++) { @@ -1010,11 +1018,13 @@ static int handle_buffered_iopage(XenIOState *state) req.df = 1; req.type = buf_req->type; req.data_is_ptr = 0; +xen_rmb(); qw = (req.size == 8); if (qw) { buf_req = &buf_page->buf_ioreq[(rdptr + 1) % IOREQ_BUFFER_SLOT_NUM]; req.data |= ((uint64_t)buf_req->data) << 32; +xen_rmb(); } handle_ioreq(state, &req); @@ -1045,7 +1055,11 @@ static void cpu_handle_ioreq(void *opaque) handle_buffered_iopage(state); if (req) { -handle_ioreq(state, req); +ioreq_t copy = *req; + +xen_rmb(); +handle_ioreq(state, ©); +req->data = copy.data; if (req->state != STATE_IOREQ_INPROCESS) { fprintf(stderr, "Badness in I/O request ... not in service?!: " -- 1.9.1
[Qemu-devel] [PULL 2/5] xen: add an own bus for xen backend devices
From: Juergen Gross Add a bus for Xen backend devices in order to be able to establish a dedicated device path for pluggable devices. Signed-off-by: Juergen Gross Reviewed-by: Stefano Stabellini Signed-off-by: Stefano Stabellini --- hw/xen/xen_backend.c | 19 --- include/hw/xen/xen_backend.h | 4 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 41ba5c5..5ad3caa 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -29,14 +29,14 @@ #include "hw/sysbus.h" #include "sysemu/char.h" #include "qemu/log.h" +#include "qapi/error.h" #include "hw/xen/xen_backend.h" #include "hw/xen/xen_pvdev.h" #include -#define TYPE_XENSYSDEV "xensysdev" - DeviceState *xen_sysdev; +BusState *xen_sysbus; /* - */ @@ -528,6 +528,8 @@ int xen_be_init(void) xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV); qdev_init_nofail(xen_sysdev); +xen_sysbus = qbus_create(TYPE_XENSYSBUS, DEVICE(xen_sysdev), "xen-sysbus"); +qbus_set_bus_hotplug_handler(xen_sysbus, &error_abort); return 0; @@ -586,6 +588,15 @@ int xen_be_bind_evtchn(struct XenDevice *xendev) } +static const TypeInfo xensysbus_info = { +.name = TYPE_XENSYSBUS, +.parent = TYPE_BUS, +.interfaces = (InterfaceInfo[]) { +{ TYPE_HOTPLUG_HANDLER }, +{ } +} +}; + static int xen_sysdev_init(SysBusDevice *dev) { return 0; @@ -602,6 +613,7 @@ static void xen_sysdev_class_init(ObjectClass *klass, void *data) k->init = xen_sysdev_init; dc->props = xen_sysdev_properties; +dc->bus_type = TYPE_XENSYSBUS; } static const TypeInfo xensysdev_info = { @@ -613,7 +625,8 @@ static const TypeInfo xensysdev_info = { static void xenbe_register_types(void) { +type_register_static(&xensysbus_info); type_register_static(&xensysdev_info); } -type_init(xenbe_register_types); +type_init(xenbe_register_types) diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h index cbda40e..38f730e 100644 --- a/include/hw/xen/xen_backend.h +++ b/include/hw/xen/xen_backend.h @@ -6,12 +6,16 @@ #include "sysemu/sysemu.h" #include "net/net.h" +#define TYPE_XENSYSDEV "xen-sysdev" +#define TYPE_XENSYSBUS "xen-sysbus" + /* variables */ extern xc_interface *xen_xc; extern xenforeignmemory_handle *xen_fmem; extern struct xs_handle *xenstore; extern const char *xen_protocol; extern DeviceState *xen_sysdev; +extern BusState *xen_sysbus; int xenstore_mkdir(char *path, int p); int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const char *val); -- 1.9.1
[Qemu-devel] [PULL 0/5] xen-20161122-tag
Hi Stefan, this pull request contains an XSA ("fix ioreq handling") and xen-usb bug fixes and cleanups. Please note that "qdev: add function qdev_set_id()" touches generic qdev code: I was the only one to review the patch but it is just code movement. The following changes since commit a7764f1548ef9946af30a8f96be9cef10761f0c1: Fix FreeBSD (10.x) build after 7dc9ae43 (2016-11-22 10:56:01 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161122-tag for you to fetch changes up to f1784a222eed213ce3213f431bc2f9c570f20c3e: xen: attach pvusb usb bus to backend qdev (2016-11-22 10:29:41 -0800) Xen 2016/11/22 Jan Beulich (1): xen: fix ioreq handling Juergen Gross (4): xen: add an own bus for xen backend devices qdev: add function qdev_set_id() xen: create qdev for each backend device xen: attach pvusb usb bus to backend qdev hw/usb/xen-usb.c | 23 +++ hw/xen/xen_backend.c | 66 ++-- hw/xen/xen_pvdev.c | 4 ++- include/hw/xen/xen_backend.h | 8 ++ include/hw/xen/xen_pvdev.h | 1 + include/monitor/qdev.h | 1 + qdev-monitor.c | 36 +--- xen-hvm.c| 16 ++- 8 files changed, 121 insertions(+), 34 deletions(-)
[Qemu-devel] [PATCH 4/4] 9pfs: add a size parameter to init_iov_from_pdu
Not all 9pfs transports share memory between request and response. For those who don't, it is necessary to know how much memory is required in the response. Signed-off-by: Stefano Stabellini --- hw/9pfs/9p.c | 2 +- hw/9pfs/9p.h | 2 +- hw/9pfs/virtio-9p-device.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index b6ec042..b82212b 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -1652,7 +1652,7 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, struct iovec *iov; unsigned int niov; -pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); +pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write, skip + size); qemu_iovec_init_external(&elem, iov, niov); qemu_iovec_init(qiov, niov); diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h index ab398d0..c830188 100644 --- a/hw/9pfs/9p.h +++ b/hw/9pfs/9p.h @@ -348,7 +348,7 @@ struct V9fsTransport { ssize_t (*pdu_vmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt, va_list ap); ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt, va_list ap); void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, - unsigned int *pniov, bool is_write); + unsigned int *pniov, bool is_write, size_t size); void(*push_and_notify)(V9fsPDU *pdu); }; diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index e1a37a4..e2b27e8 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -172,7 +172,7 @@ static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset, } static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, - unsigned int *pniov, bool is_write) + unsigned int *pniov, bool is_write, size_t size) { V9fsState *s = pdu->s; V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); -- 1.9.1
[Qemu-devel] [PATCH 1/4] 9pfs: move pdus to V9fsState
pdus are initialized and used in 9pfs common code. Move the array from V9fsVirtioState to V9fsState. Signed-off-by: Stefano Stabellini --- hw/9pfs/9p.c| 7 +++ hw/9pfs/9p.h| 1 + hw/9pfs/virtio-9p.h | 1 - 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index aea7e9d..05e950f 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -3440,7 +3440,6 @@ void pdu_submit(V9fsPDU *pdu) /* Returns 0 on success, 1 on failure. */ int v9fs_device_realize_common(V9fsState *s, Error **errp) { -V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); int i, len; struct stat stat; FsDriverEntry *fse; @@ -3451,9 +3450,9 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp) QLIST_INIT(&s->free_list); QLIST_INIT(&s->active_list); for (i = 0; i < (MAX_REQ - 1); i++) { -QLIST_INSERT_HEAD(&s->free_list, &v->pdus[i], next); -v->pdus[i].s = s; -v->pdus[i].idx = i; +QLIST_INSERT_HEAD(&s->free_list, &s->pdus[i], next); +s->pdus[i].s = s; +s->pdus[i].idx = i; } v9fs_path_init(&path); diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h index 3976b7f..07cee01 100644 --- a/hw/9pfs/9p.h +++ b/hw/9pfs/9p.h @@ -229,6 +229,7 @@ typedef struct V9fsState char *tag; enum p9_proto_version proto_version; int32_t msize; +V9fsPDU pdus[MAX_REQ]; /* * lock ensuring atomic path update * on rename. diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h index 25c47c7..52c4b9d 100644 --- a/hw/9pfs/virtio-9p.h +++ b/hw/9pfs/virtio-9p.h @@ -10,7 +10,6 @@ typedef struct V9fsVirtioState VirtIODevice parent_obj; VirtQueue *vq; size_t config_size; -V9fsPDU pdus[MAX_REQ]; VirtQueueElement *elems[MAX_REQ]; V9fsState state; } V9fsVirtioState; -- 1.9.1
[Qemu-devel] [PATCH 2/4] 9pfs: introduce transport specific callbacks
Don't call virtio functions from 9pfs generic code, use generic function callbacks instead. Signed-off-by: Stefano Stabellini --- hw/9pfs/9p.c | 8 hw/9pfs/9p.h | 18 ++ hw/9pfs/virtio-9p-device.c | 18 ++ hw/9pfs/virtio-9p.h| 9 - 4 files changed, 36 insertions(+), 17 deletions(-) diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index 05e950f..5a20a13 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -47,7 +47,7 @@ ssize_t pdu_marshal(V9fsPDU *pdu, size_t offset, const char *fmt, ...) va_list ap; va_start(ap, fmt); -ret = virtio_pdu_vmarshal(pdu, offset, fmt, ap); +ret = pdu->s->transport->pdu_vmarshal(pdu, offset, fmt, ap); va_end(ap); return ret; @@ -59,7 +59,7 @@ ssize_t pdu_unmarshal(V9fsPDU *pdu, size_t offset, const char *fmt, ...) va_list ap; va_start(ap, fmt); -ret = virtio_pdu_vunmarshal(pdu, offset, fmt, ap); +ret = pdu->s->transport->pdu_vunmarshal(pdu, offset, fmt, ap); va_end(ap); return ret; @@ -67,7 +67,7 @@ ssize_t pdu_unmarshal(V9fsPDU *pdu, size_t offset, const char *fmt, ...) static void pdu_push_and_notify(V9fsPDU *pdu) { -virtio_9p_push_and_notify(pdu); +pdu->s->transport->push_and_notify(pdu); } static int omode_to_uflags(int8_t mode) @@ -1751,7 +1751,7 @@ static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, struct iovec *iov; unsigned int niov; -virtio_init_iov_from_pdu(pdu, &iov, &niov, is_write); +pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); qemu_iovec_init_external(&elem, iov, niov); qemu_iovec_init(qiov, niov); diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h index 07cee01..ab398d0 100644 --- a/hw/9pfs/9p.h +++ b/hw/9pfs/9p.h @@ -230,6 +230,7 @@ typedef struct V9fsState enum p9_proto_version proto_version; int32_t msize; V9fsPDU pdus[MAX_REQ]; +struct V9fsTransport *transport; /* * lock ensuring atomic path update * on rename. @@ -343,4 +344,21 @@ void pdu_free(V9fsPDU *pdu); void pdu_submit(V9fsPDU *pdu); void v9fs_reset(V9fsState *s); +struct V9fsTransport { +ssize_t (*pdu_vmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt, va_list ap); +ssize_t (*pdu_vunmarshal)(V9fsPDU *pdu, size_t offset, const char *fmt, va_list ap); +void(*init_iov_from_pdu)(V9fsPDU *pdu, struct iovec **piov, + unsigned int *pniov, bool is_write); +void(*push_and_notify)(V9fsPDU *pdu); +}; + +static inline int v9fs_register_transport(V9fsState *s, struct V9fsTransport *t) +{ +if (s->transport) { +return -EINVAL; +} +s->transport = t; +return 0; +} + #endif diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index 1782e4a..e1a37a4 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -20,7 +20,9 @@ #include "hw/virtio/virtio-access.h" #include "qemu/iov.h" -void virtio_9p_push_and_notify(V9fsPDU *pdu) +static struct V9fsTransport virtio_9p_transport; + +static void virtio_9p_push_and_notify(V9fsPDU *pdu) { V9fsState *s = pdu->s; V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); @@ -126,6 +128,7 @@ static void virtio_9p_device_realize(DeviceState *dev, Error **errp) v->config_size = sizeof(struct virtio_9p_config) + strlen(s->fsconf.tag); virtio_init(vdev, "virtio-9p", VIRTIO_ID_9P, v->config_size); v->vq = virtio_add_queue(vdev, MAX_REQ, handle_9p_output); +v9fs_register_transport(s, &virtio_9p_transport); out: return; @@ -148,7 +151,7 @@ static void virtio_9p_reset(VirtIODevice *vdev) v9fs_reset(&v->state); } -ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset, +static ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset, const char *fmt, va_list ap) { V9fsState *s = pdu->s; @@ -158,7 +161,7 @@ ssize_t virtio_pdu_vmarshal(V9fsPDU *pdu, size_t offset, return v9fs_iov_vmarshal(elem->in_sg, elem->in_num, offset, 1, fmt, ap); } -ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset, +static ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset, const char *fmt, va_list ap) { V9fsState *s = pdu->s; @@ -168,7 +171,7 @@ ssize_t virtio_pdu_vunmarshal(V9fsPDU *pdu, size_t offset, return v9fs_iov_vunmarshal(elem->out_sg, elem->out_num, offset, 1, fmt, ap); } -void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, +static void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, unsigned int *pniov, bool is_write) { V9fsState *s = pdu->s; @@ -184,6 +187,13 @@ void virtio_init_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, } } +static struct V9fsT
[Qemu-devel] [PATCH 3/4] 9pfs: use v9fs_init_qiov_from_pdu instead of v9fs_pack
v9fs_xattr_read should not access VirtQueueElement elems directly. Move v9fs_init_qiov_from_pdu up in the file and call v9fs_init_qiov_from_pdu instead of v9fs_pack. Signed-off-by: Stefano Stabellini --- hw/9pfs/9p.c | 58 +- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index 5a20a13..b6ec042 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -1633,14 +1633,39 @@ out_nofid: pdu_complete(pdu, err); } +/* + * Create a QEMUIOVector for a sub-region of PDU iovecs + * + * @qiov: uninitialized QEMUIOVector + * @skip: number of bytes to skip from beginning of PDU + * @size: number of bytes to include + * @is_write: true - write, false - read + * + * The resulting QEMUIOVector has heap-allocated iovecs and must be cleaned up + * with qemu_iovec_destroy(). + */ +static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, +size_t skip, size_t size, +bool is_write) +{ +QEMUIOVector elem; +struct iovec *iov; +unsigned int niov; + +pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); + +qemu_iovec_init_external(&elem, iov, niov); +qemu_iovec_init(qiov, niov); +qemu_iovec_concat(qiov, &elem, skip, size); +} + static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp, uint64_t off, uint32_t max_count) { ssize_t err; size_t offset = 7; uint64_t read_count; -V9fsVirtioState *v = container_of(s, V9fsVirtioState, state); -VirtQueueElement *elem = v->elems[pdu->idx]; +QEMUIOVector qiov_full; if (fidp->fs.xattr.len < off) { read_count = 0; @@ -1656,7 +1681,8 @@ static int v9fs_xattr_read(V9fsState *s, V9fsPDU *pdu, V9fsFidState *fidp, } offset += err; -err = v9fs_pack(elem->in_sg, elem->in_num, offset, +v9fs_init_qiov_from_pdu(&qiov_full, pdu, 0, read_count, false); +err = v9fs_pack(qiov_full.iov, qiov_full.niov, offset, ((char *)fidp->fs.xattr.value) + off, read_count); if (err < 0) { @@ -1732,32 +1758,6 @@ static int coroutine_fn v9fs_do_readdir_with_stat(V9fsPDU *pdu, return count; } -/* - * Create a QEMUIOVector for a sub-region of PDU iovecs - * - * @qiov: uninitialized QEMUIOVector - * @skip: number of bytes to skip from beginning of PDU - * @size: number of bytes to include - * @is_write: true - write, false - read - * - * The resulting QEMUIOVector has heap-allocated iovecs and must be cleaned up - * with qemu_iovec_destroy(). - */ -static void v9fs_init_qiov_from_pdu(QEMUIOVector *qiov, V9fsPDU *pdu, -size_t skip, size_t size, -bool is_write) -{ -QEMUIOVector elem; -struct iovec *iov; -unsigned int niov; - -pdu->s->transport->init_iov_from_pdu(pdu, &iov, &niov, is_write); - -qemu_iovec_init_external(&elem, iov, niov); -qemu_iovec_init(qiov, niov); -qemu_iovec_concat(qiov, &elem, skip, size); -} - static void coroutine_fn v9fs_read(void *opaque) { int32_t fid; -- 1.9.1
[Qemu-devel] [PATCH 0/4] 9pfs: clean-up for multiple transports
Hi all, this small patch series provides a few fixes and clean-ups in preparation for the introduction of a 9pfs Xen transport. Stefano Stabellini (4): 9pfs: move pdus to V9fsState 9pfs: introduce transport specific callbacks 9pfs: use v9fs_init_qiov_from_pdu instead of v9fs_pack 9pfs: add a size parameter to init_iov_from_pdu hw/9pfs/9p.c | 71 +++--- hw/9pfs/9p.h | 19 + hw/9pfs/virtio-9p-device.c | 20 + hw/9pfs/virtio-9p.h| 10 --- 4 files changed, 69 insertions(+), 51 deletions(-)
Re: [Qemu-devel] [PATCH v2 0/4] xed: add qdevs for each backend, correct pvUSB
Hi Juergen, it would be helpful if you could resend this series with the small changes I requested. But if it is a problem for you, I can do that myself while committing. Cheers, Stefano On Wed, 2 Nov 2016, Juergen Gross wrote: > Trying to use pvUSB in a Xen guest with a qemu emulated USB controller > will crash qemu as it tries to attach a pvUSB device to the emulated > controller. > > This can be avoided by adding a unique id to each pvUSB controller which > can be used when attaching the pvUSB device. In order to make this > possible the pvUSB controller has to be a hotpluggable qemu device. > > This is achieved by adding a qdev for each Xen backend all attached to > a new Xen specific bus. > > Changes in V2: > - one qdev for each backend instead of pvUSB only > > Juergen Gross (4): > xen: add an own bus for xen backend devices > qdev: add function qdev_set_id() > xen: create qdev for each backend device > xen: attach pvusb usb bus to backend qdev > > hw/usb/xen-usb.c | 23 +++ > hw/xen/xen_backend.c | 67 > +--- > hw/xen/xen_pvdev.c | 5 +++- > include/hw/xen/xen_backend.h | 8 ++ > include/hw/xen/xen_pvdev.h | 1 + > include/monitor/qdev.h | 1 + > qdev-monitor.c | 36 +--- > 7 files changed, 107 insertions(+), 34 deletions(-)
Re: [Qemu-devel] [PATCH v2 3/4] xen: create qdev for each backend device
On Wed, 2 Nov 2016, Juergen Gross wrote: > Create a qdev plugged to the xen-sysbus for each new backend device. > This device can be used as a parent for all needed devices of that > backend. The id of the new device will be "xen--" with > being the xen backend type (e.g. "qdisk") and the xen > backend number of the type under which it is to be found in xenstore. > > Signed-off-by: Juergen Gross > --- > hw/xen/xen_backend.c | 48 > +++- > hw/xen/xen_pvdev.c | 5 - > include/hw/xen/xen_backend.h | 4 > include/hw/xen/xen_pvdev.h | 1 + > 4 files changed, 56 insertions(+), 2 deletions(-) > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c > index 5ad3caa..3cb40b2 100644 > --- a/hw/xen/xen_backend.c > +++ b/hw/xen/xen_backend.c > @@ -27,11 +27,13 @@ > > #include "hw/hw.h" > #include "hw/sysbus.h" > +#include "hw/boards.h" > #include "sysemu/char.h" > #include "qemu/log.h" > #include "qapi/error.h" > #include "hw/xen/xen_backend.h" > #include "hw/xen/xen_pvdev.h" > +#include "monitor/qdev.h" > > #include > > @@ -121,6 +123,12 @@ static struct XenDevice *xen_be_get_xendev(const char > *type, int dom, int dev, > > /* init new xendev */ > xendev = g_malloc0(ops->size); > +object_initialize(&xendev->qdev, ops->size, TYPE_XENBACKEND); > +qdev_set_parent_bus(&xendev->qdev, xen_sysbus); > +qdev_set_id(&xendev->qdev, g_strdup_printf("xen-%s-%d", type, dev)); > +qdev_init_nofail(&xendev->qdev); > +object_unref(OBJECT(&xendev->qdev)); > + > xendev->type = type; > xendev->dom = dom; > xendev->dev = dev; > @@ -163,7 +171,6 @@ static struct XenDevice *xen_be_get_xendev(const char > *type, int dom, int dev, > return xendev; > } > > - spurious change > /* > * Sync internal data structures on xenstore updates. > * Node specifies the changed field. node = NULL means > @@ -541,6 +548,15 @@ err: > return -1; > } > > +static void xen_set_dynamic_sysbus(void) > +{ > +Object *machine = qdev_get_machine(); > +ObjectClass *oc = object_get_class(machine); > +MachineClass *mc = MACHINE_CLASS(oc); > + > +mc->has_dynamic_sysbus = true; > +} > + > int xen_be_register(const char *type, struct XenDevOps *ops) > { > char path[50]; > @@ -562,6 +578,8 @@ int xen_be_register(const char *type, struct XenDevOps > *ops) > > void xen_be_register_common(void) > { > +xen_set_dynamic_sysbus(); > + > xen_be_register("console", &xen_console_ops); > xen_be_register("vkbd", &xen_kbdmouse_ops); > xen_be_register("qdisk", &xen_blkdev_ops); > @@ -588,9 +606,36 @@ int xen_be_bind_evtchn(struct XenDevice *xendev) > } > > > +static Property xendev_properties[] = { > +DEFINE_PROP_END_OF_LIST(), > +}; > + > +static void xendev_class_init(ObjectClass *klass, void *data) > +{ > +DeviceClass *dc = DEVICE_CLASS(klass); > + > +dc->props = xendev_properties; > +set_bit(DEVICE_CATEGORY_MISC, dc->categories); > +} > + > +static const TypeInfo xendev_type_info = { > +.name = TYPE_XENBACKEND, > +.parent= TYPE_XENSYSDEV, > +.class_init= xendev_class_init, > +.instance_size = sizeof(struct XenDevice), > +}; > + > +static void xen_sysbus_class_init(ObjectClass *klass, void *data) > +{ > +HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(klass); > + > +hc->unplug = qdev_simple_device_unplug_cb; > +} > + > static const TypeInfo xensysbus_info = { > .name = TYPE_XENSYSBUS, > .parent = TYPE_BUS, > +.class_init = xen_sysbus_class_init, > .interfaces = (InterfaceInfo[]) { > { TYPE_HOTPLUG_HANDLER }, > { } > @@ -627,6 +672,7 @@ static void xenbe_register_types(void) > { > type_register_static(&xensysbus_info); > type_register_static(&xensysdev_info); > +type_register_static(&xendev_type_info); > } > > type_init(xenbe_register_types) > diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c > index 405e154..773c278 100644 > --- a/hw/xen/xen_pvdev.c > +++ b/hw/xen/xen_pvdev.c > @@ -18,10 +18,12 @@ > */ > > #include "qemu/osdep.h" > +#include "hw/qdev-core.h" > > #include "hw/xen/xen_backend.h" > #include "hw/xen/xen_pvdev.h" > > +
Re: [Qemu-devel] [PATCH v2 2/4] qdev: add function qdev_set_id()
On Wed, 2 Nov 2016, Juergen Gross wrote: > In order to have an easy way to add a new qdev with a specific id > carve out the needed functionality from qdev_device_add() into a new > function qdev_set_id(). > > Signed-off-by: Juergen Gross Reviewed-by: Stefano Stabellini > include/monitor/qdev.h | 1 + > qdev-monitor.c | 36 > 2 files changed, 21 insertions(+), 16 deletions(-) > > diff --git a/include/monitor/qdev.h b/include/monitor/qdev.h > index 8e504bc..0ff3331 100644 > --- a/include/monitor/qdev.h > +++ b/include/monitor/qdev.h > @@ -12,5 +12,6 @@ void qmp_device_add(QDict *qdict, QObject **ret_data, Error > **errp); > > int qdev_device_help(QemuOpts *opts); > DeviceState *qdev_device_add(QemuOpts *opts, Error **errp); > +void qdev_set_id(DeviceState *dev, const char *id); > > #endif > diff --git a/qdev-monitor.c b/qdev-monitor.c > index 4f78ecb..c73410c 100644 > --- a/qdev-monitor.c > +++ b/qdev-monitor.c > @@ -539,10 +539,28 @@ static BusState *qbus_find(const char *path, Error > **errp) > return bus; > } > > +void qdev_set_id(DeviceState *dev, const char *id) > +{ > +if (id) { > +dev->id = id; > +} > + > +if (dev->id) { > +object_property_add_child(qdev_get_peripheral(), dev->id, > + OBJECT(dev), NULL); > +} else { > +static int anon_count; > +gchar *name = g_strdup_printf("device[%d]", anon_count++); > +object_property_add_child(qdev_get_peripheral_anon(), name, > + OBJECT(dev), NULL); > +g_free(name); > +} > +} > + > DeviceState *qdev_device_add(QemuOpts *opts, Error **errp) > { > DeviceClass *dc; > -const char *driver, *path, *id; > +const char *driver, *path; > DeviceState *dev; > BusState *bus = NULL; > Error *err = NULL; > @@ -591,21 +609,7 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error > **errp) > qdev_set_parent_bus(dev, bus); > } > > -id = qemu_opts_id(opts); > -if (id) { > -dev->id = id; > -} > - > -if (dev->id) { > -object_property_add_child(qdev_get_peripheral(), dev->id, > - OBJECT(dev), NULL); > -} else { > -static int anon_count; > -gchar *name = g_strdup_printf("device[%d]", anon_count++); > -object_property_add_child(qdev_get_peripheral_anon(), name, > - OBJECT(dev), NULL); > -g_free(name); > -} > +qdev_set_id(dev, qemu_opts_id(opts)); > > /* set properties */ > if (qemu_opt_foreach(opts, set_property, dev, &err)) { > -- > 2.6.6 >
Re: [Qemu-devel] [PATCH v2 4/4] xen: attach pvusb usb bus to backend qdev
On Wed, 2 Nov 2016, Juergen Gross wrote: > Attach the usb bus of a new pvusb controller to the qdev associated > with the Xen backend. Any device connected to that controller can now > specify the bus and port directly via its properties. > > Signed-off-by: Juergen Gross Reviewed-by: Stefano Stabellini > hw/usb/xen-usb.c | 23 ++- > 1 file changed, 10 insertions(+), 13 deletions(-) > > diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c > index 1b3c2fb..8e676e6 100644 > --- a/hw/usb/xen-usb.c > +++ b/hw/usb/xen-usb.c > @@ -712,15 +712,10 @@ static void usbback_portid_detach(struct usbback_info > *usbif, unsigned port) > > static void usbback_portid_remove(struct usbback_info *usbif, unsigned port) > { > -USBPort *p; > - > if (!usbif->ports[port - 1].dev) { > return; > } > > -p = &(usbif->ports[port - 1].port); > -snprintf(p->path, sizeof(p->path), "%d", 99); > - > object_unparent(OBJECT(usbif->ports[port - 1].dev)); > usbif->ports[port - 1].dev = NULL; > usbback_portid_detach(usbif, port); > @@ -733,10 +728,10 @@ static void usbback_portid_add(struct usbback_info > *usbif, unsigned port, > { > unsigned speed; > char *portname; > -USBPort *p; > Error *local_err = NULL; > QDict *qdict; > QemuOpts *opts; > +char *tmp; > > if (usbif->ports[port - 1].dev) { > return; > @@ -749,11 +744,16 @@ static void usbback_portid_add(struct usbback_info > *usbif, unsigned port, > return; > } > portname++; > -p = &(usbif->ports[port - 1].port); > -snprintf(p->path, sizeof(p->path), "%s", portname); > > qdict = qdict_new(); > qdict_put(qdict, "driver", qstring_from_str("usb-host")); > +tmp = g_strdup_printf("%s.0", usbif->xendev.qdev.id); > +qdict_put(qdict, "bus", qstring_from_str(tmp)); > +g_free(tmp); > +tmp = g_strdup_printf("%s-%u", usbif->xendev.qdev.id, port); > +qdict_put(qdict, "id", qstring_from_str(tmp)); > +g_free(tmp); > +qdict_put(qdict, "port", qint_from_int(port)); > qdict_put(qdict, "hostbus", qint_from_int(atoi(busid))); > qdict_put(qdict, "hostport", qstring_from_str(portname)); > opts = qemu_opts_from_qdict(qemu_find_opts("device"), qdict, &local_err); > @@ -765,7 +765,6 @@ static void usbback_portid_add(struct usbback_info > *usbif, unsigned port, > goto err; > } > QDECREF(qdict); > -snprintf(p->path, sizeof(p->path), "%d", port); > speed = usbif->ports[port - 1].dev->speed; > switch (speed) { > case USB_SPEED_LOW: > @@ -799,7 +798,6 @@ static void usbback_portid_add(struct usbback_info > *usbif, unsigned port, > > err: > QDECREF(qdict); > -snprintf(p->path, sizeof(p->path), "%d", 99); > xen_pv_printf(&usbif->xendev, 0, "device %s could not be opened\n", > busid); > } > > @@ -1012,13 +1010,13 @@ static void usbback_alloc(struct XenDevice *xendev) > > usbif = container_of(xendev, struct usbback_info, xendev); > > -usb_bus_new(&usbif->bus, sizeof(usbif->bus), &xen_usb_bus_ops, > xen_sysdev); > +usb_bus_new(&usbif->bus, sizeof(usbif->bus), &xen_usb_bus_ops, > +DEVICE(&xendev->qdev)); > for (i = 0; i < USBBACK_MAXPORTS; i++) { > p = &(usbif->ports[i].port); > usb_register_port(&usbif->bus, p, usbif, i, &xen_usb_port_ops, >USB_SPEED_MASK_LOW | USB_SPEED_MASK_FULL | >USB_SPEED_MASK_HIGH); > -snprintf(p->path, sizeof(p->path), "%d", 99); > } > > QTAILQ_INIT(&usbif->req_free_q); > @@ -1066,7 +1064,6 @@ static int usbback_free(struct XenDevice *xendev) > } > > usb_bus_release(&usbif->bus); > -object_unparent(OBJECT(&usbif->bus)); > > TR_BUS(xendev, "finished\n"); > > -- > 2.6.6 >
Re: [Qemu-devel] [PATCH v2 1/4] xen: add an own bus for xen backend devices
On Wed, 2 Nov 2016, Juergen Gross wrote: > Add a bus for Xen backend devices in order to be able to establish a > dedicated device path for pluggable devices. > > Signed-off-by: Juergen Gross Reviewed-by: Stefano Stabellini > hw/xen/xen_backend.c | 19 --- > include/hw/xen/xen_backend.h | 4 > 2 files changed, 20 insertions(+), 3 deletions(-) > > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c > index 41ba5c5..5ad3caa 100644 > --- a/hw/xen/xen_backend.c > +++ b/hw/xen/xen_backend.c > @@ -29,14 +29,14 @@ > #include "hw/sysbus.h" > #include "sysemu/char.h" > #include "qemu/log.h" > +#include "qapi/error.h" > #include "hw/xen/xen_backend.h" > #include "hw/xen/xen_pvdev.h" > > #include > > -#define TYPE_XENSYSDEV "xensysdev" > - > DeviceState *xen_sysdev; > +BusState *xen_sysbus; > > /* - */ > > @@ -528,6 +528,8 @@ int xen_be_init(void) > > xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV); > qdev_init_nofail(xen_sysdev); > +xen_sysbus = qbus_create(TYPE_XENSYSBUS, DEVICE(xen_sysdev), > "xen-sysbus"); > +qbus_set_bus_hotplug_handler(xen_sysbus, &error_abort); > > return 0; > > @@ -586,6 +588,15 @@ int xen_be_bind_evtchn(struct XenDevice *xendev) > } > > > +static const TypeInfo xensysbus_info = { > +.name = TYPE_XENSYSBUS, > +.parent = TYPE_BUS, > +.interfaces = (InterfaceInfo[]) { > +{ TYPE_HOTPLUG_HANDLER }, > +{ } > +} > +}; > + > static int xen_sysdev_init(SysBusDevice *dev) > { > return 0; > @@ -602,6 +613,7 @@ static void xen_sysdev_class_init(ObjectClass *klass, > void *data) > > k->init = xen_sysdev_init; > dc->props = xen_sysdev_properties; > +dc->bus_type = TYPE_XENSYSBUS; > } > > static const TypeInfo xensysdev_info = { > @@ -613,7 +625,8 @@ static const TypeInfo xensysdev_info = { > > static void xenbe_register_types(void) > { > +type_register_static(&xensysbus_info); > type_register_static(&xensysdev_info); > } > > -type_init(xenbe_register_types); > +type_init(xenbe_register_types) > diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h > index cbda40e..38f730e 100644 > --- a/include/hw/xen/xen_backend.h > +++ b/include/hw/xen/xen_backend.h > @@ -6,12 +6,16 @@ > #include "sysemu/sysemu.h" > #include "net/net.h" > > +#define TYPE_XENSYSDEV "xen-sysdev" > +#define TYPE_XENSYSBUS "xen-sysbus" > + > /* variables */ > extern xc_interface *xen_xc; > extern xenforeignmemory_handle *xen_fmem; > extern struct xs_handle *xenstore; > extern const char *xen_protocol; > extern DeviceState *xen_sysdev; > +extern BusState *xen_sysbus; > > int xenstore_mkdir(char *path, int p); > int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const > char *val); > -- > 2.6.6 >
[Qemu-devel] [PULL] xen: Fix xenpv machine initialisation
From: Anthony PERARD When using QEMU for Xen PV guest, QEMU abort with: xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type generic-pc-machine This is because the machine 'xenpv' also use accel=xen. Moving the code to xen_hvm_init() fix the issue. This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae. Signed-off-by: Anthony PERARD Signed-off-by: Stefano Stabellini Reviewed-by: Eduardo Habkost Reviewed-by: Stefano Stabellini --- xen-common.c | 6 -- xen-hvm.c| 4 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/xen-common.c b/xen-common.c index bacf962..9099760 100644 --- a/xen-common.c +++ b/xen-common.c @@ -9,7 +9,6 @@ */ #include "qemu/osdep.h" -#include "hw/i386/pc.h" #include "hw/xen/xen_backend.h" #include "qmp-commands.h" #include "sysemu/char.h" @@ -115,11 +114,6 @@ static void xen_change_state_handler(void *opaque, int running, static int xen_init(MachineState *ms) { -PCMachineState *pcms = PC_MACHINE(ms); - -/* Disable ACPI build because Xen handles it */ -pcms->acpi_build_enabled = false; - xen_xc = xc_interface_open(0, 0, 0); if (xen_xc == NULL) { xen_pv_printf(NULL, 0, "can't open xen interface\n"); diff --git a/xen-hvm.c b/xen-hvm.c index 2f348ed..150c7e7 100644 --- a/xen-hvm.c +++ b/xen-hvm.c @@ -1316,6 +1316,10 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory) } xen_be_register_common(); xen_read_physmap(state); + +/* Disable ACPI build because Xen handles it */ +pcms->acpi_build_enabled = false; + return; err: -- 1.9.1
[Qemu-devel] [PULL 0/1] tags/xen-20161108-tag
The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e: Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into staging (2016-11-07 14:02:15 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161108-tag for you to fetch changes up to 804ba7c10bbc66bb8a8aa73ecc60f620da7423d5: xen: Fix xenpv machine initialisation (2016-11-08 11:17:30 -0800) Xen 2016/11/08 Anthony PERARD (1): xen: Fix xenpv machine initialisation xen-common.c | 6 -- xen-hvm.c| 4 2 files changed, 4 insertions(+), 6 deletions(-)
Re: [Qemu-devel] [PATCH v2] xen: Fix xenpv machine initialisation
On Tue, 8 Nov 2016, Anthony PERARD wrote: > When using QEMU for Xen PV guest, QEMU abort with: > xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type > generic-pc-machine > > This is because the machine 'xenpv' also use accel=xen. Moving the code > to xen_hvm_init() fix the issue. > > This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae. > > Signed-off-by: Anthony PERARD Reviewed-by: Stefano Stabellini > CC: Wei Liu > CC: Eduardo Habkost > --- > xen-common.c | 6 -- > xen-hvm.c| 4 > 2 files changed, 4 insertions(+), 6 deletions(-) > > diff --git a/xen-common.c b/xen-common.c > index bacf962..9099760 100644 > --- a/xen-common.c > +++ b/xen-common.c > @@ -9,7 +9,6 @@ > */ > > #include "qemu/osdep.h" > -#include "hw/i386/pc.h" > #include "hw/xen/xen_backend.h" > #include "qmp-commands.h" > #include "sysemu/char.h" > @@ -115,11 +114,6 @@ static void xen_change_state_handler(void *opaque, int > running, > > static int xen_init(MachineState *ms) > { > -PCMachineState *pcms = PC_MACHINE(ms); > - > -/* Disable ACPI build because Xen handles it */ > -pcms->acpi_build_enabled = false; > - > xen_xc = xc_interface_open(0, 0, 0); > if (xen_xc == NULL) { > xen_pv_printf(NULL, 0, "can't open xen interface\n"); > diff --git a/xen-hvm.c b/xen-hvm.c > index 2f348ed..150c7e7 100644 > --- a/xen-hvm.c > +++ b/xen-hvm.c > @@ -1316,6 +1316,10 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion > **ram_memory) > } > xen_be_register_common(); > xen_read_physmap(state); > + > +/* Disable ACPI build because Xen handles it */ > +pcms->acpi_build_enabled = false; > + > return; > > err: > -- > Anthony PERARD >
Re: [Qemu-devel] [PATCH] xen: Fix xenpv machine initialisation
On Mon, 7 Nov 2016, Anthony PERARD wrote: > When using QEMU for Xen PV guest, QEMU abort with: > xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type > generic-pc-machine > > This is because the machine 'xenpv' also use accel=xen. > > This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae > > Signed-off-by: Anthony PERARD What about moving the acpi_build_enabled initialization to xen_hvm_init? > CC: Wei Liu > CC: Eduardo Habkost > --- > xen-common.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/xen-common.c b/xen-common.c > index bacf962..22683b0 100644 > --- a/xen-common.c > +++ b/xen-common.c > @@ -115,10 +115,12 @@ static void xen_change_state_handler(void *opaque, int > running, > > static int xen_init(MachineState *ms) > { > -PCMachineState *pcms = PC_MACHINE(ms); > +if (object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE)) { > +PCMachineState *pcms = PC_MACHINE(ms); > > -/* Disable ACPI build because Xen handles it */ > -pcms->acpi_build_enabled = false; > +/* Disable ACPI build because Xen handles it */ > +pcms->acpi_build_enabled = false; > +} > > xen_xc = xc_interface_open(0, 0, 0); > if (xen_xc == NULL) { > -- > Anthony PERARD >
[Qemu-devel] [PULL 0/2] tags/xen-20161102-tag
The following changes since commit 4eb28abd52d48657cff6ff45e8dbbbefe4dbb414: Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20161101-2' into staging (2016-11-01 16:53:05 +) are available in the git repository at: git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20161102-tag for you to fetch changes up to 021746c131cdfeab9d82ff918795a9f18d20d7ae: PCMachineState: introduce acpi_build_enabled field (2016-11-02 12:26:12 -0700) Xen 2016/11/02 Thomas Huth (1): hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf() Wei Liu (1): PCMachineState: introduce acpi_build_enabled field hw/i386/acpi-build.c | 2 +- hw/i386/pc.c | 2 ++ hw/xen/xen_pvdev.c | 2 +- include/hw/i386/pc.h | 2 ++ xen-common.c | 6 ++ 5 files changed, 12 insertions(+), 2 deletions(-)
[Qemu-devel] [PULL 2/2] PCMachineState: introduce acpi_build_enabled field
From: Wei Liu Introduce this field to control whether ACPI build is enabled by a particular machine or accelerator. It defaults to true if the machine itself supports ACPI build. Xen accelerator will disable it because Xen is in charge of building ACPI tables for the guest. Signed-off-by: Wei Liu Signed-off-by: Stefano Stabellini Reviewed-by: Stefano Stabellini Reviewed-by: Eduardo Habkost Tested-by: Sander Eikelenboom --- hw/i386/acpi-build.c | 2 +- hw/i386/pc.c | 2 ++ include/hw/i386/pc.h | 2 ++ xen-common.c | 6 ++ 4 files changed, 11 insertions(+), 1 deletion(-) diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index 5cd1da9..13cbbde 100644 --- a/hw/i386/acpi-build.c +++ b/hw/i386/acpi-build.c @@ -2953,7 +2953,7 @@ void acpi_setup(void) return; } -if (!pcmc->has_acpi_build) { +if (!pcms->acpi_build_enabled) { ACPI_BUILD_DPRINTF("ACPI build disabled. Bailing out.\n"); return; } diff --git a/hw/i386/pc.c b/hw/i386/pc.c index f56ea0f..fbd9aed 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -2159,6 +2159,8 @@ static void pc_machine_initfn(Object *obj) pcms->vmport = ON_OFF_AUTO_AUTO; /* nvdimm is disabled on default. */ pcms->acpi_nvdimm_state.is_enabled = false; +/* acpi build is enabled by default if machine supports it */ +pcms->acpi_build_enabled = PC_MACHINE_GET_CLASS(pcms)->has_acpi_build; } static void pc_machine_reset(void) diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h index 98dc772..8eb517f 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -62,6 +62,8 @@ struct PCMachineState { AcpiNVDIMMState acpi_nvdimm_state; +bool acpi_build_enabled; + /* RAM information (sizes, addresses, configuration): */ ram_addr_t below_4g_mem_size, above_4g_mem_size; diff --git a/xen-common.c b/xen-common.c index 9099760..bacf962 100644 --- a/xen-common.c +++ b/xen-common.c @@ -9,6 +9,7 @@ */ #include "qemu/osdep.h" +#include "hw/i386/pc.h" #include "hw/xen/xen_backend.h" #include "qmp-commands.h" #include "sysemu/char.h" @@ -114,6 +115,11 @@ static void xen_change_state_handler(void *opaque, int running, static int xen_init(MachineState *ms) { +PCMachineState *pcms = PC_MACHINE(ms); + +/* Disable ACPI build because Xen handles it */ +pcms->acpi_build_enabled = false; + xen_xc = xc_interface_open(0, 0, 0); if (xen_xc == NULL) { xen_pv_printf(NULL, 0, "can't open xen interface\n"); -- 1.9.1
[Qemu-devel] [PULL 1/2] hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf()
From: Thomas Huth Olaf Hering reported a build failure due to an undefined reference to 'qemu_log_vprintf'. Explicitely including qemu/log.h seems to fix the issue. Signed-off-by: Thomas Huth Signed-off-by: Stefano Stabellini Acked-by: Stefano Stabellini Tested-by: Olaf Hering --- hw/xen/xen_pvdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c index 405e154..5212bc6 100644 --- a/hw/xen/xen_pvdev.c +++ b/hw/xen/xen_pvdev.c @@ -18,7 +18,7 @@ */ #include "qemu/osdep.h" - +#include "qemu/log.h" #include "hw/xen/xen_backend.h" #include "hw/xen/xen_pvdev.h" -- 1.9.1
Re: [Qemu-devel] [PATCH] hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf()
On Wed, 2 Nov 2016, Peter Maydell wrote: > On 2 November 2016 at 17:34, Stefano Stabellini > wrote: > > On Wed, 2 Nov 2016, Thomas Huth wrote: > >> Olaf Hering reported a build failure due to an undefined reference > >> to 'qemu_log_vprintf'. Explicitely including qemu/log.h seems to > >> fix the issue. > >> > >> Signed-off-by: Thomas Huth > > > > The fix makes sense: > > > > Acked-by: Stefano Stabellini > > > > However I was unable to reproduce the build failure, so I would like a > > confirmation from Olaf that the fix is working. > > If you configure with the (default) simple trace > backend then trace.h will pull in qemu/log.h > (and in this case trace.h comes in via xen_common.h). > But if you're using a different backend then it won't > bring in that header, and you'll get the build failure. > > This is a fairly common "breaks but only with > some trace backends" compile failure, but I'm > not sure how best to try to make it more robust > (or at least into a 'fails-everywhere' bug). Personally what I can do is adding --enable-trace-backends=syslog to my test scripts. That is enough to repro the issue. Thanks for the explanation.
Re: [Qemu-devel] [PATCH] hw/xen/xen_pvdev: Include qemu/log.h for qemu_log_vprintf()
On Wed, 2 Nov 2016, Thomas Huth wrote: > Olaf Hering reported a build failure due to an undefined reference > to 'qemu_log_vprintf'. Explicitely including qemu/log.h seems to > fix the issue. > > Signed-off-by: Thomas Huth The fix makes sense: Acked-by: Stefano Stabellini However I was unable to reproduce the build failure, so I would like a confirmation from Olaf that the fix is working. > hw/xen/xen_pvdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c > index 405e154..5212bc6 100644 > --- a/hw/xen/xen_pvdev.c > +++ b/hw/xen/xen_pvdev.c > @@ -18,7 +18,7 @@ > */ > > #include "qemu/osdep.h" > - > +#include "qemu/log.h" > #include "hw/xen/xen_backend.h" > #include "hw/xen/xen_pvdev.h" > > -- > 1.8.3.1 >
Re: [Qemu-devel] [PATCH v2] PCMachineState: introduce acpi_build_enabled field
On Tue, 1 Nov 2016, Eduardo Habkost wrote: > On Tue, Nov 01, 2016 at 05:44:16PM +, Wei Liu wrote: > > Introduce this field to control whether ACPI build is enabled by a > > particular machine or accelerator. > > > > It defaults to true if the machine itself supports ACPI build. Xen > > accelerator will disable it because Xen is in charge of building ACPI > > tables for the guest. > > > > Signed-off-by: Wei Liu > > Reviewed-by: Eduardo Habkost Thank you Eduardo. I can queue it up unless you have other stuff in progress.
Re: [Qemu-devel] [PATCH v2] PCMachineState: introduce acpi_build_enabled field
On Tue, 1 Nov 2016, Wei Liu wrote: > Introduce this field to control whether ACPI build is enabled by a > particular machine or accelerator. > > It defaults to true if the machine itself supports ACPI build. Xen > accelerator will disable it because Xen is in charge of building ACPI > tables for the guest. > > Signed-off-by: Wei Liu Reviewed-by: Stefano Stabellini > Cc: Igor Mammedov > Cc: Eduardo Habkost > Cc: Anthony PERARD > Cc: Stefano Stabellini > Cc: Sander Eikelenboom > > v2: > 1. drop acpi-build property > 2. set acpi_build_enabled to acpi_has_build > 3. replace acpi_has_build check in acpi_build() > --- > hw/i386/acpi-build.c | 2 +- > hw/i386/pc.c | 2 ++ > include/hw/i386/pc.h | 2 ++ > xen-common.c | 6 ++ > 4 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c > index 5cd1da9..13cbbde 100644 > --- a/hw/i386/acpi-build.c > +++ b/hw/i386/acpi-build.c > @@ -2953,7 +2953,7 @@ void acpi_setup(void) > return; > } > > -if (!pcmc->has_acpi_build) { > +if (!pcms->acpi_build_enabled) { > ACPI_BUILD_DPRINTF("ACPI build disabled. Bailing out.\n"); > return; > } > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > index f56ea0f..fbd9aed 100644 > --- a/hw/i386/pc.c > +++ b/hw/i386/pc.c > @@ -2159,6 +2159,8 @@ static void pc_machine_initfn(Object *obj) > pcms->vmport = ON_OFF_AUTO_AUTO; > /* nvdimm is disabled on default. */ > pcms->acpi_nvdimm_state.is_enabled = false; > +/* acpi build is enabled by default if machine supports it */ > +pcms->acpi_build_enabled = PC_MACHINE_GET_CLASS(pcms)->has_acpi_build; > } > > static void pc_machine_reset(void) > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h > index 98dc772..8eb517f 100644 > --- a/include/hw/i386/pc.h > +++ b/include/hw/i386/pc.h > @@ -62,6 +62,8 @@ struct PCMachineState { > > AcpiNVDIMMState acpi_nvdimm_state; > > +bool acpi_build_enabled; > + > /* RAM information (sizes, addresses, configuration): */ > ram_addr_t below_4g_mem_size, above_4g_mem_size; > > diff --git a/xen-common.c b/xen-common.c > index 9099760..bacf962 100644 > --- a/xen-common.c > +++ b/xen-common.c > @@ -9,6 +9,7 @@ > */ > > #include "qemu/osdep.h" > +#include "hw/i386/pc.h" > #include "hw/xen/xen_backend.h" > #include "qmp-commands.h" > #include "sysemu/char.h" > @@ -114,6 +115,11 @@ static void xen_change_state_handler(void *opaque, int > running, > > static int xen_init(MachineState *ms) > { > +PCMachineState *pcms = PC_MACHINE(ms); > + > +/* Disable ACPI build because Xen handles it */ > +pcms->acpi_build_enabled = false; > + > xen_xc = xc_interface_open(0, 0, 0); > if (xen_xc == NULL) { > xen_pv_printf(NULL, 0, "can't open xen interface\n"); > -- > 2.1.4 >
[Qemu-devel] [PULL 12/13] xen: Rename xen_be_find_xendev
From: Emil Condrea Prepare xen_be_find_xendev to be shared with frontends: * xen_be_find_xendev -> xen_pv_find_xendev Signed-off-by: Emil Condrea Signed-off-by: Stefano Stabellini Signed-off-by: Quan Xu Acked-by: Anthony PERARD --- hw/display/xenfb.c | 4 ++-- hw/xen/xen_backend.c | 2 +- hw/xen/xen_pvdev.c | 2 +- include/hw/xen/xen_pvdev.h | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c index 184e735..7a8727a 100644 --- a/hw/display/xenfb.c +++ b/hw/display/xenfb.c @@ -988,8 +988,8 @@ void xen_init_display(int domid) wait_more: i++; main_loop_wait(true); -xfb = xen_be_find_xendev("vfb", domid, 0); -xin = xen_be_find_xendev("vkbd", domid, 0); +xfb = xen_pv_find_xendev("vfb", domid, 0); +xin = xen_pv_find_xendev("vkbd", domid, 0); if (!xfb || !xin) { if (i < 256) { usleep(1); diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index f594dba..98fcb77 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -114,7 +114,7 @@ static struct XenDevice *xen_be_get_xendev(const char *type, int dom, int dev, { struct XenDevice *xendev; -xendev = xen_be_find_xendev(type, dom, dev); +xendev = xen_pv_find_xendev(type, dom, dev); if (xendev) { return xendev; } diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c index 28acf61..af29150 100644 --- a/hw/xen/xen_pvdev.c +++ b/hw/xen/xen_pvdev.c @@ -264,7 +264,7 @@ int xen_pv_send_notify(struct XenDevice *xendev) /* - */ -struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev) +struct XenDevice *xen_pv_find_xendev(const char *type, int dom, int dev) { struct XenDevice *xendev; diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h index caf1edc..4b1cc60 100644 --- a/include/hw/xen/xen_pvdev.h +++ b/include/hw/xen/xen_pvdev.h @@ -67,7 +67,7 @@ const char *xenbus_strstate(enum xenbus_state state); void xen_pv_evtchn_event(void *opaque); void xen_pv_insert_xendev(struct XenDevice *xendev); void xen_be_del_xendev(struct XenDevice *xendev); -struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev); +struct XenDevice *xen_pv_find_xendev(const char *type, int dom, int dev); void xen_pv_unbind_evtchn(struct XenDevice *xendev); int xen_pv_send_notify(struct XenDevice *xendev); -- 1.9.1
[Qemu-devel] [PULL 08/13] xen: Rename xen_be_printf to xen_pv_printf
From: Emil Condrea Prepare xen_be_printf to be used by both backend and frontends: * xen_be_printf -> xen_pv_printf Signed-off-by: Emil Condrea Signed-off-by: Stefano Stabellini Signed-off-by: Quan Xu Acked-by: Anthony PERARD --- hw/block/xen_disk.c| 58 +++--- hw/char/xen_console.c | 8 +++ hw/display/xenfb.c | 42 - hw/net/xen_nic.c | 22 +- hw/usb/xen-usb.c | 38 +++--- hw/xen/xen_backend.c | 46 ++-- hw/xen/xen_devconfig.c | 4 ++-- hw/xen/xen_pvdev.c | 10 include/hw/xen/xen_pvdev.h | 2 +- xen-common.c | 4 ++-- 10 files changed, 117 insertions(+), 117 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 5b037e7..6145567 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -167,12 +167,12 @@ static void destroy_grant(gpointer pgnt) xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev; if (xengnttab_unmap(gnt, grant->page, 1) != 0) { -xen_be_printf(&grant->blkdev->xendev, 0, +xen_pv_printf(&grant->blkdev->xendev, 0, "xengnttab_unmap failed: %s\n", strerror(errno)); } grant->blkdev->persistent_gnt_count--; -xen_be_printf(&grant->blkdev->xendev, 3, +xen_pv_printf(&grant->blkdev->xendev, 3, "unmapped grant %p\n", grant->page); g_free(grant); } @@ -184,11 +184,11 @@ static void remove_persistent_region(gpointer data, gpointer dev) xengnttab_handle *gnt = blkdev->xendev.gnttabdev; if (xengnttab_unmap(gnt, region->addr, region->num) != 0) { -xen_be_printf(&blkdev->xendev, 0, +xen_pv_printf(&blkdev->xendev, 0, "xengnttab_unmap region %p failed: %s\n", region->addr, strerror(errno)); } -xen_be_printf(&blkdev->xendev, 3, +xen_pv_printf(&blkdev->xendev, 3, "unmapped grant region %p with %d pages\n", region->addr, region->num); g_free(region); @@ -255,7 +255,7 @@ static int ioreq_parse(struct ioreq *ioreq) size_t len; int i; -xen_be_printf(&blkdev->xendev, 3, +xen_pv_printf(&blkdev->xendev, 3, "op %d, nr %d, handle %d, id %" PRId64 ", sector %" PRId64 "\n", ioreq->req.operation, ioreq->req.nr_segments, ioreq->req.handle, ioreq->req.id, ioreq->req.sector_number); @@ -275,28 +275,28 @@ static int ioreq_parse(struct ioreq *ioreq) case BLKIF_OP_DISCARD: return 0; default: -xen_be_printf(&blkdev->xendev, 0, "error: unknown operation (%d)\n", +xen_pv_printf(&blkdev->xendev, 0, "error: unknown operation (%d)\n", ioreq->req.operation); goto err; }; if (ioreq->req.operation != BLKIF_OP_READ && blkdev->mode[0] != 'w') { -xen_be_printf(&blkdev->xendev, 0, "error: write req for ro device\n"); +xen_pv_printf(&blkdev->xendev, 0, "error: write req for ro device\n"); goto err; } ioreq->start = ioreq->req.sector_number * blkdev->file_blk; for (i = 0; i < ioreq->req.nr_segments; i++) { if (i == BLKIF_MAX_SEGMENTS_PER_REQUEST) { -xen_be_printf(&blkdev->xendev, 0, "error: nr_segments too big\n"); +xen_pv_printf(&blkdev->xendev, 0, "error: nr_segments too big\n"); goto err; } if (ioreq->req.seg[i].first_sect > ioreq->req.seg[i].last_sect) { -xen_be_printf(&blkdev->xendev, 0, "error: first > last sector\n"); +xen_pv_printf(&blkdev->xendev, 0, "error: first > last sector\n"); goto err; } if (ioreq->req.seg[i].last_sect * BLOCK_SIZE >= XC_PAGE_SIZE) { -xen_be_printf(&blkdev->xendev, 0, "error: page crossing\n"); +xen_pv_printf(&blkdev->xendev, 0, "error: page crossing\n"); goto err; } @@ -308,7 +308,7 @@ static int ioreq_parse(struct ioreq *ioreq) qemu_iovec_add(&ioreq->v, (void*)mem, len); } if (ioreq->start + ioreq->v.size > blkdev->file_size) { -xen_be_printf(&blkdev->xendev, 0, "error: access beyond end of file\n"); +xen_pv_printf(&blkdev->xendev, 0, "error: access beyond end of file\n"); goto err; } re
[Qemu-devel] [PULL 13/13] xen: Rename xen_be_del_xendev
From: Emil Condrea Prepare xen_be_del_xendev to be shared with frontends: * xen_be_del_xendev -> xen_pv_del_xendev Signed-off-by: Emil Condrea Signed-off-by: Stefano Stabellini Signed-off-by: Quan Xu Acked-by: Anthony PERARD --- hw/xen/xen_backend.c | 2 +- hw/xen/xen_pvdev.c | 2 +- include/hw/xen/xen_pvdev.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index 98fcb77..41ba5c5 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -483,7 +483,7 @@ void xenstore_update_be(char *watch, char *type, int dom, if (xendev != NULL) { bepath = xs_read(xenstore, 0, xendev->be, &len); if (bepath == NULL) { -xen_be_del_xendev(xendev); +xen_pv_del_xendev(xendev); } else { free(bepath); xen_be_backend_changed(xendev, path); diff --git a/hw/xen/xen_pvdev.c b/hw/xen/xen_pvdev.c index af29150..405e154 100644 --- a/hw/xen/xen_pvdev.c +++ b/hw/xen/xen_pvdev.c @@ -286,7 +286,7 @@ struct XenDevice *xen_pv_find_xendev(const char *type, int dom, int dev) /* * release xen backend device. */ -void xen_be_del_xendev(struct XenDevice *xendev) +void xen_pv_del_xendev(struct XenDevice *xendev) { if (xendev->ops->free) { xendev->ops->free(xendev); diff --git a/include/hw/xen/xen_pvdev.h b/include/hw/xen/xen_pvdev.h index 4b1cc60..083f0a9 100644 --- a/include/hw/xen/xen_pvdev.h +++ b/include/hw/xen/xen_pvdev.h @@ -66,7 +66,7 @@ const char *xenbus_strstate(enum xenbus_state state); void xen_pv_evtchn_event(void *opaque); void xen_pv_insert_xendev(struct XenDevice *xendev); -void xen_be_del_xendev(struct XenDevice *xendev); +void xen_pv_del_xendev(struct XenDevice *xendev); struct XenDevice *xen_pv_find_xendev(const char *type, int dom, int dev); void xen_pv_unbind_evtchn(struct XenDevice *xendev); -- 1.9.1
[Qemu-devel] [PULL 10/13] xen: Rename xen_be_send_notify
From: Emil Condrea Prepare xen_be_send_notify to be shared with frontends: * xen_be_send_notify -> xen_pv_send_notify Signed-off-by: Emil Condrea Signed-off-by: Stefano Stabellini Signed-off-by: Quan Xu Acked-by: Anthony PERARD --- hw/block/xen_disk.c| 4 ++-- hw/char/xen_console.c | 4 ++-- hw/display/xenfb.c | 8 hw/net/xen_nic.c | 4 ++-- hw/usb/xen-usb.c | 6 +++--- hw/xen/xen_pvdev.c | 2 +- include/hw/xen/xen_pvdev.h | 2 +- 7 files changed, 15 insertions(+), 15 deletions(-) diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index 8f7fe41..3a7dc19 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -796,7 +796,7 @@ static void blk_send_response_all(struct XenBlkDev *blkdev) ioreq_release(ioreq, true); } if (send_notify) { -xen_be_send_notify(&blkdev->xendev); +xen_pv_send_notify(&blkdev->xendev); } } @@ -866,7 +866,7 @@ static void blk_handle_requests(struct XenBlkDev *blkdev) }; if (blk_send_response_one(ioreq)) { -xen_be_send_notify(&blkdev->xendev); +xen_pv_send_notify(&blkdev->xendev); } ioreq_release(ioreq, false); continue; diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c index 15463dc..c01f410 100644 --- a/hw/char/xen_console.c +++ b/hw/char/xen_console.c @@ -74,7 +74,7 @@ static void buffer_append(struct XenConsole *con) xen_mb(); intf->out_cons = cons; -xen_be_send_notify(&con->xendev); +xen_pv_send_notify(&con->xendev); if (buffer->max_capacity && buffer->size > buffer->max_capacity) { @@ -142,7 +142,7 @@ static void xencons_receive(void *opaque, const uint8_t *buf, int len) } xen_wmb(); intf->in_prod = prod; -xen_be_send_notify(&con->xendev); +xen_pv_send_notify(&con->xendev); } static void xencons_send(struct XenConsole *con) diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c index 1077575..184e735 100644 --- a/hw/display/xenfb.c +++ b/hw/display/xenfb.c @@ -215,7 +215,7 @@ static int xenfb_kbd_event(struct XenInput *xenfb, XENKBD_IN_RING_REF(page, prod) = *event; xen_wmb(); /* ensure ring contents visible */ page->in_prod = prod + 1; -return xen_be_send_notify(&xenfb->c.xendev); +return xen_pv_send_notify(&xenfb->c.xendev); } /* Send a keyboard (or mouse button) event */ @@ -397,7 +397,7 @@ static void input_event(struct XenDevice *xendev) if (page->out_prod == page->out_cons) return; page->out_cons = page->out_prod; -xen_be_send_notify(&xenfb->c.xendev); +xen_pv_send_notify(&xenfb->c.xendev); } /* */ @@ -672,7 +672,7 @@ static void xenfb_send_event(struct XenFB *xenfb, union xenfb_in_event *event) xen_wmb(); /* ensure ring contents visible */ page->in_prod = prod + 1; -xen_be_send_notify(&xenfb->c.xendev); +xen_pv_send_notify(&xenfb->c.xendev); } static void xenfb_send_refresh_period(struct XenFB *xenfb, int period) @@ -945,7 +945,7 @@ static void fb_event(struct XenDevice *xendev) struct XenFB *xenfb = container_of(xendev, struct XenFB, c.xendev); xenfb_handle_events(xenfb); -xen_be_send_notify(&xenfb->c.xendev); +xen_pv_send_notify(&xenfb->c.xendev); } /* */ diff --git a/hw/net/xen_nic.c b/hw/net/xen_nic.c index c996684..20c43a6 100644 --- a/hw/net/xen_nic.c +++ b/hw/net/xen_nic.c @@ -69,7 +69,7 @@ static void net_tx_response(struct XenNetDev *netdev, netif_tx_request_t *txp, i netdev->tx_ring.rsp_prod_pvt = ++i; RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&netdev->tx_ring, notify); if (notify) { -xen_be_send_notify(&netdev->xendev); +xen_pv_send_notify(&netdev->xendev); } if (i == netdev->tx_ring.req_cons) { @@ -221,7 +221,7 @@ static void net_rx_response(struct XenNetDev *netdev, netdev->rx_ring.rsp_prod_pvt = ++i; RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&netdev->rx_ring, notify); if (notify) { -xen_be_send_notify(&netdev->xendev); +xen_pv_send_notify(&netdev->xendev); } } diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c index 4ae9b6a..1b3c2fb 100644 --- a/hw/usb/xen-usb.c +++ b/hw/usb/xen-usb.c @@ -314,7 +314,7 @@ static void usbback_do_response(struct usbback_req *usbback_req, int32_t status, RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&usbif->urb_ring, notify); if (notify) { -xen_be_send_notify(xendev); +xen_pv_send_notify(xendev); } } @@ -590,7 +590,7 @@ static void usbback_hotplu