Re: [Qemu-devel] [PATCH v2 05/14] target/arm/helper: zcr: Add build bug next to value range assumption

Hi Drew, On 6/21/19 6:34 PM, Andrew Jones wrote: > Suggested-by: Dave Martin > Signed-off-by: Andrew Jones > --- > target/arm/helper.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/arm/helper.c b/target/arm/helper.c > index df4276f5f6ca..edba94004e0b 100644 > --- a/target/arm

Re: [Qemu-devel] [PATCH v2 02/14] target/arm/cpu: Ensure we can use the pmu with kvm

On 6/21/19 6:34 PM, Andrew Jones wrote: > We first convert the pmu property from a static property to one with > its own accessors. Then we use the set accessor to check if the PMU is > supported when using KVM. Indeed a 32-bit KVM host does not support > the PMU, so this check will catch an attemp

Re: [Qemu-devel] [PATCH] virtio-pci: fix missing device properties

Hi On Wed, Jun 26, 2019 at 3:56 AM Eduardo Habkost wrote: > > On Wed, Jun 26, 2019 at 01:23:33AM +0200, Marc-André Lureau wrote: > > Since commit a4ee4c8baa37154 ("virtio: Helper for registering virtio > > device types"), virtio-gpu-pci, virtio-vga, and virtio-crypto-pci lost > > some properties:

Re: [Qemu-devel] [PATCH v5 1/2] s390/kvm: header sync for diag318

On 25.06.19 17:17, Collin Walling wrote: > Signed-off-by: Collin Walling > --- > linux-headers/asm-s390/kvm.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h > index 03ab596..4a857bb 100644 > --- a/linux-headers/asm-s390/kv

Re: [Qemu-devel] [PATCH v5 2/2] s390: diagnose 318 info reset and migration support

On 25.06.19 17:17, Collin Walling wrote: > index a606547..4c26754 100644 > --- a/target/s390x/cpu.h > +++ b/target/s390x/cpu.h > @@ -39,7 +39,13 @@ > > #define MMU_USER_IDX 0 > > -#define S390_MAX_CPUS 248 > +/* > + * HACK: The introduction of additional facility bytes in the Read Info > +

Re: [Qemu-devel] [PATCH v8 03/10] dp8393x: manage big endian bus

On 6/25/19 7:09 PM, Laurent Vivier wrote: > Le 25/06/2019 à 17:57, Philippe Mathieu-Daudé a écrit : >> On 6/24/19 10:07 PM, Laurent Vivier wrote: >>> Hi, >>> >>> Jason, Can I have an Acked-by from you (as network devices maintainer)? >> >> Hmm something seems odd here indeed... >> >> What a stable

Re: [Qemu-devel] [PATCH] target/i386: HAX: Enable ROM/ROM device memory region support

Patchew URL: https://patchew.org/QEMU/1561528815-4912-1-git-send-email-hang.y...@linux.intel.com/ Hi, This series seems to have some coding style problems. See output below for more information: Message-id: 1561528815-4912-1-git-send-email-hang.y...@linux.intel.com Type: series Subject: [Qemu

Re: [Qemu-devel] [PATCH] qemu-nbd: Permit TLS with Unix sockets

On Tue, Jun 25, 2019 at 09:49:42PM -0500, Eric Blake wrote: > Although you generally won't use encryption with a Unix socket (after > all, everything is local, so why waste the CPU power), there are > situations in testsuites where Unix sockets are much nicer than TCP > sockets. Since nbdkit allow

[Qemu-devel] [PATCH] target/i386: HAX: Enable ROM/ROM device memory region support

From: Hang Yuan Add ROM and ROM device memory region support in HAX. Their memory region is read only and write access will generate EPT violation. The violation will be handled in the HAX kernel with the following patch. https://github.com/intel/haxm/commit/33ceea09a1655fca12c47f1e112b1d269357f

Re: [Qemu-devel] [Qemu-block] [PATCH] blk: postpone request execution on a context protected with "drained section"

On 24.06.2019 12:46, Denis Plotnikov wrote: > > > On 21.06.2019 12:59, Vladimir Sementsov-Ogievskiy wrote: >> 21.06.2019 12:16, Kevin Wolf wrote: >>> Am 09.04.2019 um 12:01 hat Kevin Wolf geschrieben: Am 02.04.2019 um 10:35 hat Denis Plotnikov geschrieben: > On 13.03.2019 19:04, Kevin

Re: [Qemu-devel] [PATCH] atomic failures on qemu-system-riscv64

On Wed, 26 Jun 2019 01:30:35 PDT (-0700), richard.hender...@linaro.org wrote: On 6/26/19 10:25 AM, Palmer Dabbelt wrote: You misunderstand.  The code is exactly correct as-is.  The alignment check happens implicitly as a part of the softmmu tlb resolution. Sorry, I thought you said it wasn't h

Re: [Qemu-devel] [PATCH] atomic failures on qemu-system-riscv64

On 6/26/19 10:25 AM, Palmer Dabbelt wrote: >> You misunderstand.  The code is exactly correct as-is.  The alignment check >> happens implicitly as a part of the softmmu tlb resolution. > > Sorry, I thought you said it wasn't happening for linux-user?  If it happens > for both then we're good. Oh,

Re: [Qemu-devel] [PATCH for 4.1 v3] target/riscv: Expose time CSRs when allowed by [m|s]counteren

On Tue, 25 Jun 2019 23:54:06 PDT (-0700), bmeng...@gmail.com wrote: Hi Palmer, On Tue, Jun 25, 2019 at 5:57 PM Palmer Dabbelt wrote: On Mon, 24 Jun 2019 16:03:20 PDT (-0700), finte...@gmail.com wrote: > Apparently my previous message didn't make it out onto the list (sorry > about all these e

Re: [Qemu-devel] [PATCH] atomic failures on qemu-system-riscv64

On Wed, 26 Jun 2019 00:48:51 PDT (-0700), richard.hender...@linaro.org wrote: On 6/26/19 8:07 AM, Palmer Dabbelt wrote: On Tue, 25 Jun 2019 08:36:28 PDT (-0700), richard.hender...@linaro.org wrote: On 6/24/19 8:08 PM, Joel Sing wrote: Regarding the alignment for reservations, the specification

Re: [Qemu-devel] [PATCH for 4.1 v3] target/riscv: Expose time CSRs when allowed by [m|s]counteren

On Tue, 25 Jun 2019 23:58:34 PDT (-0700), bmeng...@gmail.com wrote: On Wed, Jun 26, 2019 at 4:23 AM Jonathan Behrens wrote: I just did some testing on a HiFive Unleashed board and can confirm what you are saying. The low 5 bits of both mcounteren and scounteren are writable (if you try to writ

Re: [Qemu-devel] [PATCH] qemu-nbd: Permit TLS with Unix sockets

On Tue, Jun 25, 2019 at 09:49:42PM -0500, Eric Blake wrote: > Although you generally won't use encryption with a Unix socket (after > all, everything is local, so why waste the CPU power), there are > situations in testsuites where Unix sockets are much nicer than TCP > sockets. Since nbdkit allow

Re: [Qemu-devel] [PATCH] riscv: virt: Correct pci "bus-range" encoding

On Tue, 25 Jun 2019 18:47:33 PDT (-0700), bmeng...@gmail.com wrote: Hi, On Fri, Jun 7, 2019 at 2:46 AM Alistair Francis wrote: On Thu, Jun 6, 2019 at 5:55 AM Bin Meng wrote: > > On Thu, May 30, 2019 at 11:36 AM Bin Meng wrote: > > > > Hi Alistair, > > > > On Thu, May 30, 2019 at 11:14 AM Al

Re: [Qemu-devel] [PATCH 1/2] riscv: sifive_u: Do not create hard-coded phandles in DT

On Tue, 25 Jun 2019 18:47:15 PDT (-0700), bmeng...@gmail.com wrote: Hi, On Sat, May 18, 2019 at 5:34 AM Alistair Francis wrote: On Fri, 2019-05-17 at 08:51 -0700, Bin Meng wrote: > At present the cpu, plic and ethclk nodes' phandles are hard-coded > to 1/2/3 in DT. If we configure more than 1

Re: [Qemu-devel] [PATCH 2/2] riscv: sifive_u: Update the plic hart config to support multicore

On Fri, 17 May 2019 14:35:56 PDT (-0700), Alistair Francis wrote: On Fri, 2019-05-17 at 08:51 -0700, Bin Meng wrote: At present the PLIC is instantiated to support only one hart, while the machine allows at most 4 harts to be created. When more than 1 hart is configured, PLIC needs to instantiat

Re: [Qemu-devel] [PATCH v12 5/5] linux-user: Fix flock structure for MIPS O64 ABI

Le 26/06/2019 à 09:54, Aleksandar Markovic a écrit : > > On Jun 19, 2019 6:34 PM, "Laurent Vivier" > wrote: >> >> Le 19/06/2019 à 16:17, Aleksandar Markovic a écrit : >> > From: Aleksandar Markovic > >> > >> > Only MIPS O32 and N32 have sp

Re: [Qemu-devel] [PATCH v12 5/5] linux-user: Fix flock structure for MIPS O64 ABI

On Jun 19, 2019 6:34 PM, "Laurent Vivier" wrote: > > Le 19/06/2019 à 16:17, Aleksandar Markovic a écrit : > > From: Aleksandar Markovic > > > > Only MIPS O32 and N32 have special (different than other > > architectures) definition of structure flock in kernel. > > > > Bring flock definition for M

[Qemu-devel] [PATCH v2 1/4] libvhost-user: add vmsg_set_reply_u64() helper

The VhostUserMsg request is reused as the reply by message processing functions. This is risky since request fields may corrupt the reply if the vhost-user message handler function forgets to re-initialize them. Changing this practice would be very invasive but we can introduce a helper function

[Qemu-devel] [PATCH v2 4/4] docs: avoid vhost-user-net specifics in multiqueue section

The "Multiple queue support" section makes references to vhost-user-net "queue pairs". This is confusing for two reasons: 1. This actually applies to all device types, not just vhost-user-net. 2. VHOST_USER_GET_QUEUE_NUM returns the number of virtqueues, not the number of queue pairs. Reword t

[Qemu-devel] [PATCH v2 0/4] libvhost-user: VHOST_USER_PROTOCOL_F_MQ support

v2: * Add missing dev->max_queues = max_queues assignment in vu_init() [dgilbert] * Folded in Marc-André's Reviewed-By Sebastien Boeuf pointed out that libvhost-user doesn't advertise VHOST_USER_PROTOCOL_F_MQ. Today this prevents vhost-user-net multiqueue from working. In virtio-fs we also wa

[Qemu-devel] [PATCH v2 2/4] libvhost-user: support many virtqueues

Currently libvhost-user is hardcoded to at most 8 virtqueues. The device backend should decide the number of virtqueues, not libvhost-user. This is important for multiqueue device backends where the guest driver needs an accurate number of virtqueues. This change breaks libvhost-user and libvhos

[Qemu-devel] [PATCH v2 3/4] libvhost-user: implement VHOST_USER_PROTOCOL_F_MQ

Existing vhost-user device backends, including vhost-user-scsi and vhost-user-blk, support multiqueue but libvhost-user currently does not advertise this. VHOST_USER_PROTOCOL_F_MQ enables the VHOST_USER_GET_QUEUE_NUM request needed for a vhost-user master to query the number of queues. For exampl

Re: [Qemu-devel] [PATCH v2] block/rbd: add preallocation support

On Tue, Jun 25, 2019 at 06:06:02PM +0200, Max Reitz wrote: > On 06.05.19 14:23, Stefano Garzarella wrote: > > This patch adds the support of preallocation (off/full) for the RBD > > block driver. > > If available, we use rbd_writesame() to quickly fill the image when > > full preallocation is requi

Re: [Qemu-devel] [PATCH] atomic failures on qemu-system-riscv64

On 6/26/19 8:07 AM, Palmer Dabbelt wrote: > On Tue, 25 Jun 2019 08:36:28 PDT (-0700), richard.hender...@linaro.org wrote: >> On 6/24/19 8:08 PM, Joel Sing wrote: >>> Regarding the alignment for reservations, the >>> specification does require this, although I do not recall seeing any >>> enforcemen

Re: [Qemu-devel] [PATCH v4 0/7] tcg/ppc: Add vector opcodes

On 6/25/19 7:55 PM, Mark Cave-Ayland wrote: > And here's where we are blowing up according to -d in_asm,op_out_asm: > > IN: > 0x00f22ca0: 101ffc84 vor v0, v31, v31 > > OP: > ld_i32 tmp0,env,$0xfff8 > movi_i32 tmp1,$0x0 > brcond_i32 tmp0,tmp1,lt,$L0 > > 00f22ca0 > ld_vec v128

Re: [Qemu-devel] [PATCH v2 03/14] target/arm/monitor: Introduce qmp_query_cpu_model_expansion

Hi Drew, On 6/21/19 6:34 PM, Andrew Jones wrote: > Add support for the query-cpu-model-expansion QMP command to Arm. We > do this selectively, only exposing CPU properties which represent > optional CPU features which the user may want to enable/disable. Also, > for simplicity, we restrict the lis

[Qemu-devel] [PATCH v3] deprecate -mem-path fallback to anonymous RAM

Fallback might affect guest or worse whole host performance or functionality if backing file were used to share guest RAM with another process. Patch deprecates fallback so that we could remove it in future and ensure that QEMU will provide expected behavior and fail if it can't use user provided

<    1   2   3