Hello there Could you delete e-mail at the mailing list?
Best Regards Chicken~ -----Original Message----- From: qemu-devel-bounces+chickenjoon=gmail....@nongnu.org [mailto:qemu-devel-bounces+chickenjoon=gmail....@nongnu.org] On Behalf Of qemu-devel-requ...@nongnu.org Sent: Thursday, March 20, 2014 12:49 AM To: qemu-devel@nongnu.org Subject: Qemu-devel Digest, Vol 132, Issue 698 Send Qemu-devel mailing list submissions to qemu-devel@nongnu.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.nongnu.org/mailman/listinfo/qemu-devel or, via email, send a message with subject or body 'help' to qemu-devel-requ...@nongnu.org You can reach the person managing the list at qemu-devel-ow...@nongnu.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Qemu-devel digest..." Today's Topics: 1. Re: [PULL for-2.0 7/7] linux-user: Implement capget, capset (Laurent Desnogues) 2. Re: [Qemu-ppc] [PATCH] target-ppc: Fix overallocation of opcode tables (Tom Musta) 3. Re: [PATCH v2 3/4] tcg: Mask shift counts to avoid undefined behavior (Richard Henderson) 4. migrating instances from qemu-kvm to qemu (Serge E. Hallyn) 5. Re: [PATCH] target-ppc: Fix h_enter to loop correctly (Andreas F?rber) 6. [RFC 0/5] virtio: use alias properties in transport devices (Stefan Hajnoczi) 7. [RFC 1/5] qdev: add child alias properties (Stefan Hajnoczi) ---------------------------------------------------------------------- Message: 1 Date: Wed, 19 Mar 2014 16:10:59 +0100 From: Laurent Desnogues <laurent.desnog...@gmail.com> To: Riku Voipio <riku.voi...@linaro.org> Cc: Peter Maydell <peter.mayd...@linaro.org>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Anthony Liguori <aligu...@amazon.com> Subject: Re: [Qemu-devel] [PULL for-2.0 7/7] linux-user: Implement capget, capset Message-ID: <CABoDooMJoYCJBsu=84+xy2r5zyxwxy1pdayuoxy7ee0jue4...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hello, On Wed, Mar 19, 2014 at 3:03 PM, <riku.voi...@linaro.org> wrote: > From: Peter Maydell <peter.mayd...@linaro.org> > > Implement the capget and capset syscalls. This is useful because > simple programs like 'ls' try to use it in AArch64, and otherwise we > emit a lot of noise about it being unimplemented. > > Signed-off-by: Peter Maydell <peter.mayd...@linaro.org> > Signed-off-by: Riku Voipio <riku.voi...@linaro.org> > --- > linux-user/syscall.c | 75 +++++++++++++++++++++++++++++++++++++++++++++-- > linux-user/syscall_defs.h | 11 +++++++ > 2 files changed, 84 insertions(+), 2 deletions(-) > > diff --git a/linux-user/syscall.c b/linux-user/syscall.c index > e404a32..366b695 100644 > --- a/linux-user/syscall.c > +++ b/linux-user/syscall.c > @@ -43,6 +43,7 @@ > #include <sys/resource.h> > #include <sys/mman.h> > #include <sys/swap.h> > +#include <linux/capability.h> > #include <signal.h> > #include <sched.h> > #ifdef __ia64__ > @@ -243,6 +244,10 @@ _syscall3(int, sys_sched_setaffinity, pid_t, pid, unsigned int, len, > unsigned long *, user_mask_ptr); _syscall4(int, reboot, > int, magic1, int, magic2, unsigned int, cmd, > void *, arg); > +_syscall2(int, capget, struct __user_cap_header_struct *, header, > + struct __user_cap_data_struct *, data); _syscall2(int, > +capset, struct __user_cap_header_struct *, header, > + struct __user_cap_data_struct *, data); > > static bitmask_transtbl fcntl_flags_tbl[] = { > { TARGET_O_ACCMODE, TARGET_O_WRONLY, O_ACCMODE, O_WRONLY, }, > @@ -7677,9 +7682,75 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1, > unlock_user(p, arg1, ret); > break; > case TARGET_NR_capget: > - goto unimplemented; > case TARGET_NR_capset: > - goto unimplemented; > + { > + struct target_user_cap_header *target_header; > + struct target_user_cap_data *target_data = NULL; > + struct __user_cap_header_struct header; > + struct __user_cap_data_struct data[2]; > + struct __user_cap_data_struct *dataptr = NULL; > + int i, target_datalen; > + int data_items = 1; > + > + if (!lock_user_struct(VERIFY_WRITE, target_header, arg1, 1)) { > + goto efault; > + } > + header.version = tswap32(target_header->version); > + header.pid = tswap32(target_header->pid); > + > + if (header.version != _LINUX_CAPABILITY_VERSION_1) { Sorry for spotting this late, but older kernels (in my case 2.6.18-238.el5, CentOS 5.6) don't have _LINUX_CAPABILITY_VERSION_1 defined. I think _LINUX_CAPABILITY_VERSION should be used instead in that case. Thanks, Laurent > + /* Version 2 and up takes pointer to two user_data structs */ > + data_items = 2; > + } > + > + target_datalen = sizeof(*target_data) * data_items; > + > + if (arg2) { > + if (num == TARGET_NR_capget) { > + target_data = lock_user(VERIFY_WRITE, arg2, target_datalen, 0); > + } else { > + target_data = lock_user(VERIFY_READ, arg2, target_datalen, 1); > + } > + if (!target_data) { > + unlock_user_struct(target_header, arg1, 0); > + goto efault; > + } > + > + if (num == TARGET_NR_capset) { > + for (i = 0; i < data_items; i++) { > + data[i].effective = tswap32(target_data[i].effective); > + data[i].permitted = tswap32(target_data[i].permitted); > + data[i].inheritable = tswap32(target_data[i].inheritable); > + } > + } > + > + dataptr = data; > + } > + > + if (num == TARGET_NR_capget) { > + ret = get_errno(capget(&header, dataptr)); > + } else { > + ret = get_errno(capset(&header, dataptr)); > + } > + > + /* The kernel always updates version for both capget and capset */ > + target_header->version = tswap32(header.version); > + unlock_user_struct(target_header, arg1, 1); > + > + if (arg2) { > + if (num == TARGET_NR_capget) { > + for (i = 0; i < data_items; i++) { > + target_data[i].effective = tswap32(data[i].effective); > + target_data[i].permitted = tswap32(data[i].permitted); > + target_data[i].inheritable = tswap32(data[i].inheritable); > + } > + unlock_user(target_data, arg2, target_datalen); > + } else { > + unlock_user(target_data, arg2, 0); > + } > + } > + break; > + } > case TARGET_NR_sigaltstack: > #if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_MIPS) || \ > defined(TARGET_SPARC) || defined(TARGET_PPC) || > defined(TARGET_ALPHA) || \ diff --git a/linux-user/syscall_defs.h > b/linux-user/syscall_defs.h index 2a7d1db..fdf9a47 100644 > --- a/linux-user/syscall_defs.h > +++ b/linux-user/syscall_defs.h > @@ -2566,3 +2566,14 @@ struct target_sigevent { > } _sigev_thread; > } _sigev_un; > }; > + > +struct target_user_cap_header { > + uint32_t version; > + int pid; > +}; > + > +struct target_user_cap_data { > + uint32_t effective; > + uint32_t permitted; > + uint32_t inheritable; > +}; > -- > 1.8.1.2 > > ------------------------------ Message: 2 Date: Wed, 19 Mar 2014 10:14:00 -0500 From: Tom Musta <tommu...@gmail.com> To: Stuart Brady <s...@zubnet.me.uk>, qemu-triv...@nongnu.org Cc: qemu-...@nongnu.org, qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Fix overallocation of opcode tables Message-ID: <5329b438.7090...@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On 3/19/2014 9:07 AM, Stuart Brady wrote: > create_new_table() should allocate 0x20 opc_handler_t pointers, but > actually allocates 0x20 opc_handler_t structs. Fix this. > > Signed-off-by: Stuart Brady <s...@zubnet.me.uk> > --- > translate_init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c > index 6084f40..75f34c1 100644 > --- a/target-ppc/translate_init.c > +++ b/target-ppc/translate_init.c > @@ -7434,7 +7434,7 @@ static int create_new_table (opc_handler_t > **table, unsigned char idx) { > opc_handler_t **tmp; > > - tmp = g_malloc(0x20 * sizeof(opc_handler_t)); > + tmp = g_new(opc_handler_t *, 0x20); > fill_new_table(tmp, 0x20); > table[idx] = (opc_handler_t *)((uintptr_t)tmp | PPC_INDIRECT); > Reviewed-by: Tom Musta <tommu...@gmail.com> Tested-by: Tom Musta <tommu...@gmail.com> ------------------------------ Message: 3 Date: Wed, 19 Mar 2014 08:25:23 -0700 From: Richard Henderson <r...@twiddle.net> To: Stefan Weil <s...@weilnetz.de>, qemu-devel@nongnu.org Cc: peter.mayd...@linaro.org Subject: Re: [Qemu-devel] [PATCH v2 3/4] tcg: Mask shift counts to avoid undefined behavior Message-ID: <5329b6e3.5030...@twiddle.net> Content-Type: text/plain; charset=ISO-8859-15 On 03/18/2014 11:21 PM, Stefan Weil wrote: > Are there test cases which fail with the old code? Only when running under analysis tools looking for technical violations of the standard. Under normal circumstances it would never crash since, as with the native backends, the underlying cpu is going to treat this some rational way. But I sincerely doubt that we could measure any performance loss in TCI. The single extra arithmetic operation should be swallowed by the loop back to interpret the next opcode. r~ ------------------------------ Message: 4 Date: Wed, 19 Mar 2014 16:42:47 +0100 From: "Serge E. Hallyn" <se...@hallyn.com> To: qemu-devel@nongnu.org Subject: [Qemu-devel] migrating instances from qemu-kvm to qemu Message-ID: <20140319154247.ga31...@mail.hallyn.com> Content-Type: text/plain; charset=us-ascii Hi, at https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1291321 it was found that migrating running vms from a machine with qemu-kvm to one with qemu, migration fails due to some mismatches. The first one we usually hit is Length mismatch: vga.vram: 1000000 in != 800000 while the second one is network card (and I have not gone beyond that). The vga one can be handled on the command line by specifying the -global cirrus-vga.vrammem_mb=8. However that doesn't help with a libvirt migration. I guess this happens at ram_load() unfortunately - is there any good way that this could be detected at incoming migration time and the virtual hardware modified as needed for migration to continue? thanks, -serge ------------------------------ Message: 5 Date: Wed, 19 Mar 2014 16:46:25 +0100 From: Andreas F?rber <afaer...@suse.de> To: "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com>, ag...@suse.de, Paolo Bonzini <pbonz...@redhat.com> Cc: qemu-...@nongnu.org, pau...@samba.org, qemu-devel@nongnu.org Subject: Re: [Qemu-devel] [PATCH] target-ppc: Fix h_enter to loop correctly Message-ID: <5329bbd1.2010...@suse.de> Content-Type: text/plain; charset=ISO-8859-15 Am 14.03.2014 14:51, schrieb Aneesh Kumar K.V: > From: "Aneesh Kumar K.V" <aneesh.ku...@linux.vnet.ibm.com> > > We wanted to loop till index is 8. On 8 we return with H_PTEG_FULL. If > we are successful in loading hpte with any other index, we continue > with that index value. > > Reported-by: Paolo Bonzini <pbonz...@redhat.com> > Signed-off-by: Aneesh Kumar K.V <aneesh.ku...@linux.vnet.ibm.com> Thanks, applied to my ppc-next: https://github.com/afaerber/qemu-cpu/commits/ppc-next Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg ------------------------------ Message: 6 Date: Wed, 19 Mar 2014 16:48:53 +0100 From: Stefan Hajnoczi <stefa...@redhat.com> To: <qemu-devel@nongnu.org> Cc: Peter Maydell <peter.mayd...@linaro.org>, Andreas Faerber <afaer...@suse.de>, Stefan Hajnoczi <stefa...@redhat.com>, fred.kon...@greensocs.com Subject: [Qemu-devel] [RFC 0/5] virtio: use alias properties in transport devices Message-ID: <1395244138-8834-1-git-send-email-stefa...@redhat.com> This RFC is just the beginning. The same problem exists for virtio-net and other devices. I am looking for feedback before I convert all of virtio. The virtio transport/device split is broken as follows: 1. The virtio-blk device is never finalized because the transport devices (virtio-blk-pci and friends) leak the refcount. 2. If we fix the refcount leak then we double-free the 'serial' string property upon hot unplug since its char* is copied into the virtio-blk device which has an identical 'serial' qdev property. This series solves both of these problems as follows: 1. Introduce a qdev child alias property that lets the transport device forward qdev property accesses into the virtio device (the child). 2. Use qdev child alias properties in transport devices, instead of keeping a duplicate copy of the VirtIOBlkConf struct. 3. Fix the virtio-blk device refcount leak. It's now safe to do this since the double-free has been resolved. Note about the new qdev child alias property type: I haven't made the alias fully transparent yet. Perhaps we should hide the alias completely? $ qemu-system-x86_64 -device virtio-blk-pci,\? ... virtio-blk-pci.logical_block_size=ChildAlias <--- should be uint64 or similar Stefan Hajnoczi (5): qdev: add child alias properties virtio: add child alias properties for virtio-blk virtio: use child aliases for virtio-blk transport properties virtio-blk: drop virtio_blk_set_conf() virtio: fix virtio-blk child refcount in transports hw/block/virtio-blk.c | 6 ------ hw/core/qdev-properties.c | 28 ++++++++++++++++++++++++++++ hw/s390x/s390-virtio-bus.c | 4 ++-- hw/s390x/s390-virtio-bus.h | 1 - hw/s390x/virtio-ccw.c | 6 +++--- hw/s390x/virtio-ccw.h | 1 - hw/virtio/virtio-pci.c | 6 +++--- hw/virtio/virtio-pci.h | 1 - include/hw/block/block.h | 14 ++++++++++++++ include/hw/qdev-properties.h | 28 ++++++++++++++++++++++++++++ include/hw/virtio/virtio-blk.h | 17 ++++++++++++++++- 11 files changed, 94 insertions(+), 18 deletions(-) -- 1.8.5.3 ------------------------------ Message: 7 Date: Wed, 19 Mar 2014 16:48:54 +0100 From: Stefan Hajnoczi <stefa...@redhat.com> To: <qemu-devel@nongnu.org> Cc: Peter Maydell <peter.mayd...@linaro.org>, Andreas Faerber <afaer...@suse.de>, Stefan Hajnoczi <stefa...@redhat.com>, fred.kon...@greensocs.com Subject: [Qemu-devel] [RFC 1/5] qdev: add child alias properties Message-ID: <1395244138-8834-2-git-send-email-stefa...@redhat.com> Child alias properties allow a parent object to expose child object properties. This makes it possible for a parent object to forward all or a subset of a child's properties. Currently we achieve similar behavior by duplicating property definitions and copying the fields around. It turns out virtio has several double-frees since we didn't get the memory management right. Using child alias properties it will be much easier for a parent object to set a child's properties without fragile memory management issues since the actual field only exists once in the child object. Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> --- hw/core/qdev-properties.c | 28 ++++++++++++++++++++++++++++ include/hw/qdev-properties.h | 28 ++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+) diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c index 77d0c66..e62a4fd 100644 --- a/hw/core/qdev-properties.c +++ b/hw/core/qdev-properties.c @@ -1002,3 +1002,31 @@ PropertyInfo qdev_prop_size = { .get = get_size, .set = set_size, }; + +/* --- alias that forwards to a child object's property --- */ + +static void get_child_alias(Object *obj, Visitor *v, void *opaque, + const char *name, Error **errp) +{ + DeviceState *dev = DEVICE(obj); + Property *prop = opaque; + Object *child = OBJECT(qdev_get_prop_ptr(dev, prop)); + + object_property_get(child, v, name, errp); +} + +static void set_child_alias(Object *obj, Visitor *v, void *opaque, + const char *name, Error **errp) +{ + DeviceState *dev = DEVICE(obj); + Property *prop = opaque; + Object *child = OBJECT(qdev_get_prop_ptr(dev, prop)); + + object_property_set(child, v, name, errp); +} + +PropertyInfo qdev_prop_child_alias = { + .name = "ChildAlias", + .get = get_child_alias, + .set = set_child_alias, +}; diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h index 3c000ee..5ab1cac 100644 --- a/include/hw/qdev-properties.h +++ b/include/hw/qdev-properties.h @@ -13,6 +13,7 @@ extern PropertyInfo qdev_prop_uint32; extern PropertyInfo qdev_prop_int32; extern PropertyInfo qdev_prop_uint64; extern PropertyInfo qdev_prop_size; +extern PropertyInfo qdev_prop_child_alias; extern PropertyInfo qdev_prop_string; extern PropertyInfo qdev_prop_chr; extern PropertyInfo qdev_prop_ptr; @@ -61,6 +62,33 @@ extern PropertyInfo qdev_prop_arraylen; .defval = (bool)_defval, \ } +/** + * DEFINE_PROP_CHILD_ALIAS: + * @_name: property name + * @_state: name of the device state structure type + * @_field: name of field in @_state, must be Object subclass + * + * Define device properties that alias a child object's property. For example, + * use the following to forward the 'baz' property where Foo embeds a Bar + * object: + * + * typedef struct { + * Object parent_obj; + * + * Bar bar_obj; + * } Foo; + * + * DEFINE_PROP_CHILD_ALIAS("baz", Foo, bar_obj) + * + * Any access to Foo's 'baz' property actually accesses bar_obj's 'baz' + * property. + */ +#define DEFINE_PROP_CHILD_ALIAS(_name, _state, _field) { \ + .name = (_name), \ + .info = &(qdev_prop_child_alias), \ + .offset = offsetof(_state, _field), \ + } + #define PROP_ARRAY_LEN_PREFIX "len-" /** -- 1.8.5.3 ------------------------------ _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/qemu-devel End of Qemu-devel Digest, Vol 132, Issue 698 ********************************************
