Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 2/2] tpm_spapr: Support suspend and resume

On Tue, Dec 12, 2017 at 03:44:03PM -0500, Stefan Berger wrote: > Signed-off-by: Stefan Berger > --- > hw/tpm/tpm_spapr.c | 61 > ++ > 1 file changed, 57 insertions(+), 4 deletions(-) > > diff --git a/hw/tpm/tpm_spapr.c b/hw/tpm/tpm_spapr.c >

Re: [Qemu-devel] [PATCH v2 3/8] migration: show the statistics of compression

On Wed, Jul 25, 2018 at 05:44:02PM +0100, Dr. David Alan Gilbert wrote: > * Peter Xu (pet...@redhat.com) wrote: > > On Mon, Jul 23, 2018 at 03:39:18PM +0800, Xiao Guangrong wrote: > > > > > > > > > On 07/23/2018 12:36 PM, Peter Xu wrote: > > > > On Thu, Jul 19, 2018 at 08:15:15PM +0800,

Re: [Qemu-devel] [Qemu-ppc] [PATCH v2 1/2] tpm_spapr: Support TPM for ppc64 using CRQ based interface

On Tue, Dec 12, 2017 at 03:44:02PM -0500, Stefan Berger wrote: > Implement support for TPM on ppc64 by implementing the vTPM CRQ > interface as a frontend. It can use the tpm_emulator driver > backend with the external swtpm. > > The Linux vTPM driver for ppc64 works with this emulation. > >

Re: [Qemu-devel] [PATCH] target/ppc: only save guest timebase once after stopping

On Thu, May 03, 2018 at 11:20:44PM -0500, Michael Roth wrote: > In some cases (e.g. spapr) we record guest timebase after qmp_stop() > via a runstate hook so we can restore it on qmp_cont(). If a migration > occurs in between those events we end up saving it again, this time > based on the current

Re: [Qemu-devel] [PATCH v3 0/3] arm: Add nRF51 SoC and micro:bit machine

Hi, This series failed docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. Type: series Message-id: 20180726023645.13927-1-j...@jms.id.au Subject: [Qemu-devel] [PATCH v3 0/3] arm: Add nRF51

Re: [Qemu-devel] [PATCH v3 0/3] arm: Add nRF51 SoC and micro:bit machine

On Thu, 07/26 12:06, Joel Stanley wrote: > v3: Rebase on Stefan's cortex-m0 series > Based-on: 20180725085944.11856-8-stefa...@redhat.com Correction: Based-on: 20180725085944.11856-1-stefa...@redhat.com (Point to the cover letter message) Fam

Re: [Qemu-devel] Virtual IOMMU + Virtio-net devices in a Windows VM doesn't work

Hi Peter, On Tue, Jul 24, 2018 at 1:55 AM Peter Xu wrote: > > On Mon, Jul 23, 2018 at 04:13:18PM -0400, Jintack Lim wrote: > > Hi, > > > > I'm running a Windows VM on top of KVM on x86, and one of virtio-net > > device in the Windows VM doesn't seem to work. I provided virtual > > IOMMU and two

Re: [Qemu-devel] [PATCH v3 0/3] arm: Add nRF51 SoC and micro:bit machine

Hi, This series failed docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. Type: series Message-id: 20180726023645.13927-1-j...@jms.id.au Subject: [Qemu-devel] [PATCH v3 0/3] arm: Add nRF51

[Qemu-devel] [PATCH v3 2/3] arm: Add Nordic Semiconductor nRF51 SoC

The nRF51 is a Cortex-M0 microcontroller with an on-board radio module, plus other common ARM SoC peripherals. http://infocenter.nordicsemi.com/pdf/nRF51_RM_v3.0.pdf This defines a basic model of the CPU and memory, with no peripherals implemented at this stage. Signed-off-by: Joel Stanley

[Qemu-devel] [PATCH v3 3/3] arm: Add BBC micro:bit machine

This adds the base for a machine model of the BBC micro:bit: https://en.wikipedia.org/wiki/Micro_Bit This is a system with a nRF51 SoC containing the main processor, with various peripherals on board. Reviewed-by: Stefan Hajnoczi Signed-off-by: Joel Stanley --- v2: - Instead of setting

[Qemu-devel] [PATCH v3 0/3] arm: Add nRF51 SoC and micro:bit machine

v3: Rebase on Stefan's cortex-m0 series Based-on: 20180725085944.11856-8-stefa...@redhat.com This short series implements a minimal definition of the Nordic Semiconductor nRF51, a Cortex-M0 ARM SoC, and the BBC micro:bit, a machine that will use this SoC. This work will serve as the base for our

[Qemu-devel] [PATCH v3 1/3] MAINTAINERS: Add NRF51 entry

This contains the NRF51, and the machine that uses it, the BBC micro:bit. Reviewed-by: Stefan Hajnoczi Signed-off-by: Joel Stanley --- v3: fix spelling of mailing list add stefan's reviewed-by --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS

Re: [Qemu-devel] [PATCH v2 1/3] arm: Add Nordic Semiconductor nRF51 SoC

On 2 July 2018 at 21:55, Stefan Hajnoczi wrote: > On Thu, Jun 28, 2018 at 12:08:13AM +0930, Joel Stanley wrote: >> +/* TODO: Flash size should be defined by the board. Microbit uses 256KB */ >> +#define FLASH_BASE 0x >> +#define FLASH_SIZE (256 * 1024) >> + >> +/* TODO: Flash

Re: [Qemu-devel] [PATCH] target/ppc: simplify bcdadd/sub functions

On Tue, Jul 24, 2018 at 12:13:04PM +, Yasmin Beatriz wrote: > After solving a corner case in bcdsub, this patch simplifies the logic > of both bcdadd/sub instructions by removing some unnecessary local flags. > > Signed-off-by: Yasmin Beatriz > --- > target/ppc/int_helper.c | 33

Re: [Qemu-devel] [PATCH qemu v2] vfio/spapr: Allow backing bigger guest IOMMU pages with smaller physical pages

On Tue, Jul 24, 2018 at 01:56:54PM +1000, Alexey Kardashevskiy wrote: > > > On 23/07/2018 13:11, David Gibson wrote: > > On Wed, Jun 20, 2018 at 07:10:12PM +1000, Alexey Kardashevskiy wrote: > >> At the moment the PPC64/pseries guest only supports 4K/64K/16M IOMMU > >> pages and POWER8 CPU

[Qemu-devel] [PATCH] slirp: fix ICMP handling on macOS hosts

From: Andrew Oates On Linux, SOCK_DGRAM+IPPROTO_ICMP sockets give only the ICMP packet when read from. On macOS, however, the socket acts like a SOCK_RAW socket and includes the IP header as well. This change strips the extra IP header from the received packet on macOS before sending it to the

[Qemu-devel] [Bug 1783422] Re: qemu_clock_get_ns does not take into account icount_time_shift

** Changed in: qemu Status: Incomplete => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1783422 Title: qemu_clock_get_ns does not take into account icount_time_shift Status in

[Qemu-devel] [PATCH v1 4/4] target/riscv: set mtval and stval support

Signed-off-by: Alistair Francis --- target/riscv/cpu.c | 4 1 file changed, 4 insertions(+) diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index d630e8fd6c..b33950a2d4 100644 --- a/target/riscv/cpu.c +++ b/target/riscv/cpu.c @@ -133,6 +133,8 @@ static void

[Qemu-devel] [PATCH v1 3/4] target/riscv: Implement the stval illegal instruction

The stval register can optionally contain the faulting instruction on an illegal instruction exception. This patch adds support for setting the stval register based on the CPU feature. Signed-off-by: Alistair Francis --- target/riscv/cpu.h| 3 ++- target/riscv/helper.c | 13 +++--

[Qemu-devel] [PATCH v1 2/4] target/riscv: Implement the mtval illegal instruction

The mtval register can optionally contain the faulting instruction on an illegal instruction exception. This patch adds support for setting the mtval register based on the CPU feature. Signed-off-by: Alistair Francis --- target/riscv/cpu.h | 4 +++- target/riscv/helper.c| 13

[Qemu-devel] [PATCH v1 0/4] RISC-V: Populate mtval and stval

Populate mtval and stval when taking an illegal instruction exception if the features are set for the CPU. Alistair Francis (4): target/riscv: Rename mbadaddr and sbadaddr target/riscv: Implement the mtval illegal instruction target/riscv: Implement the stval illegal instruction

[Qemu-devel] [PATCH v1 1/4] target/riscv: Rename mbadaddr and sbadaddr

Update to the latest spec (v1.10.0) and rename mbadaddr and sbadaddr to mtval and stval. Signed-off-by: Alistair Francis --- target/riscv/cpu.h | 3 +-- target/riscv/cpu_bits.h | 4 ++-- target/riscv/helper.c| 8 target/riscv/op_helper.c | 16 4 files

Re: [Qemu-devel] [PATCH v2] riscv: remove define cpu_init()

On Fri, May 18, 2018 at 8:02 PM, Igor Mammedov wrote: > On Fri, 18 May 2018 14:10:24 +1200 > Michael Clark wrote: > > > On Wed, May 16, 2018 at 4:00 AM, Igor Mammedov > wrote: > > > > > cpu_init() was removed since 2.12, so drop the define that is now > unused. > > > > > > Signed-off-by: Igor

Re: [Qemu-devel] [Qemu-block] [PATCH v5 1/4 for-3.0] qcow2: A grammar fix in conflicting cache sizing error message

On 07/25/2018 10:27 AM, Leonid Bloch wrote: > Signed-off-by: Leonid Bloch > --- > block/qcow2.c | 2 +- > tests/qemu-iotests/103.out | 4 ++-- > tests/qemu-iotests/137.out | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/block/qcow2.c b/block/qcow2.c >

Re: [Qemu-devel] qemu_clock_get_ns does not take into account icount_time_shift

Hello, Actually this is incorrect because cpu_get_icount() invokes cpu_icount_to_ns later on. i apologize for the spam. Best Regards, Humberto "SilverOne" Carvalho On Wed, Jul 25, 2018 at 8:25 PM Humberto "SilverOne" Carvalho < silveron...@gmail.com> wrote: > Hello, > > When using icount with

Re: [Qemu-devel] [PATCH v1] s390x/cpu_models: Add "-cpu max" support

On Wed, Jul 25, 2018 at 07:50:21PM +0200, David Hildenbrand wrote: > On 25.07.2018 19:09, Eduardo Habkost wrote: [...] > >> +if (local_err) { > >> +g_assert(kvm_enabled()); > >> +error_report_err(local_err); > >> +/* fallback to unsupported CPU models */ > >> +

Re: [Qemu-devel] [PATCH v0 0/7] Background snapshots

On Wed, Jul 25, 2018 at 08:17:37PM +0100, Dr. David Alan Gilbert wrote: > * Peter Xu (pet...@redhat.com) wrote: > > On Fri, Jun 29, 2018 at 12:53:59PM +0100, Dr. David Alan Gilbert wrote: > > > * Denis Plotnikov (dplotni...@virtuozzo.com) wrote: > > > > The patch set adds the ability to make

[Qemu-devel] [Bug 1738840] Re: qemu-img convert qcow2 to raw fails on OS X

*** This bug is a duplicate of bug 1776920 *** https://bugs.launchpad.net/bugs/1776920 ** This bug has been marked a duplicate of bug 1776920 qemu-img convert on Mac OSX creates corrupt images -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [Bug 1776920] Re: qemu-img convert on Mac OSX creates corrupt images

I marked https://bugs.launchpad.net/qemu/+bug/1738840 as a duplicate of this bug, even though that bug was older, this bug has a slightly more active thread. I'm still in need of either an APFS capable machine that I can reproduce on, or another mac dev willing to help a bit, though. -- You

Re: [Qemu-devel] [PATCH v3 18/40] target/mips: Add emulation of nanoMIPS 32-bit load and store instructions

On 20 July 2018 at 05:59, Richard Henderson wrote: > On 07/19/2018 05:54 AM, Stefan Markovic wrote: >> +/* SYNCI */ >> +/* Break the TB to be able to sync copied instructions >> + immediately */ >> +ctx->base.is_jmp = DISAS_STOP; >

[Qemu-devel] qemu_clock_get_ns does not take into account icount_time_shift

Hello, When using icount with shift, virtual time is defined as icount << N. However, qemu_clock_get_ns simply returns cpu_get_icount, thereby returning icount instead of icount << N. If you check the qemu/util/qemu-timer.c file you will find the following function: 597: int64_t

Re: [Qemu-devel] [PATCH v3 18/40] target/mips: Add emulation of nanoMIPS 32-bit load and store instructions

On 07/25/2018 08:46 AM, Aleksandar Markovic wrote: > Hello, Richard. Sorry for bothering you. One more question. > >> On 07/19/2018 05:54 AM, Stefan Markovic wrote: >>> +case NM_ADDIUGP_B: >>> +gen_arith_imm(ctx, OPC_ADDIU, rt, 28, u); >>> +break; >> >> Use

Re: [Qemu-devel] [PATCH v0 0/7] Background snapshots

* Peter Xu (pet...@redhat.com) wrote: > On Fri, Jun 29, 2018 at 12:53:59PM +0100, Dr. David Alan Gilbert wrote: > > * Denis Plotnikov (dplotni...@virtuozzo.com) wrote: > > > The patch set adds the ability to make external snapshots while VM is > > > running. > > > > cc'ing in Andrea since this

Re: [Qemu-devel] [PATCH v3 13/40] target/mips: Add emulation of misc nanoMIPS instructions (pool32a0)

On 07/25/2018 08:38 AM, Aleksandar Markovic wrote: > Hi, Richard. > >>> +case NM_SOV: >>> +{ >>> +TCGv t0 = tcg_temp_local_new(); >>> +TCGv t1 = tcg_temp_new(); >>> +TCGv t2 = tcg_temp_new(); >>> +TCGLabel *l1 = gen_new_label(); >>> + >>> +

[Qemu-devel] [PATCH for-3.0] qcow: fix a reference leak

Since 42a3e1ab367cdf38cce093de24eb406b99a4ef96 qemu asserts when using the vvfat driver: git clone git://qemu.org/qemu.git cd qemu ./configure --target-list=ppc-softmmu --enable-debug make -j8 mkdir foo touch foo/hello ./ppc-softmmu/qemu-system-ppc -M prep --nographic --monitor null \

[Qemu-devel] [PATCH for-3.1 12/10] hw/s390x: Move virtio-ccw-blk code to a separate file

The code should only be enabled if CONFIG_VIRTIO_BLK has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth --- hw/s390x/Makefile.objs| 1 + hw/s390x/virtio-ccw-blk.c | 67 +++ hw/s390x/virtio-ccw.c

[Qemu-devel] [PATCH for-3.1 11/10] hw/s390x: Move virtio-ccw-net code to a separate file

The code should only be enabled if CONFIG_VIRTIO_NET has been set. This can be done best if the code resides in a separate file. Signed-off-by: Thomas Huth --- hw/s390x/Makefile.objs| 1 + hw/s390x/virtio-ccw-net.c | 70 +++ hw/s390x/virtio-ccw.c

Re: [Qemu-devel] [PATCH v1] s390x/cpu_models: Add "-cpu max" support

On 25.07.2018 19:09, Eduardo Habkost wrote: > On Wed, Jul 25, 2018 at 11:12:33AM +0200, David Hildenbrand wrote: >> The "max" CPU model behaves like "-cpu host" when KVM is enabled, and like >> a CPU with the maximum possible feature set when TCG is enabled. >> >> While the "host" model can not be

[Qemu-devel] [Bug 1783362] Re: qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0

Following https://wiki.qemu.org/Contribute/SubmitAPatch#Make_code_motion_patches_easy_to_review: @@ -1,5 +1,5 @@ --- --- a/linux-user/mmap.c -if (len == 0) -goto the_end; -- +++ b/linux-user/mmap.c +if (len == 0) { +errno = EINVAL; +goto fail; +} -- You

Re: [Qemu-devel] [RFC PATCH] rbd: Don't convert keypairs to JSON and back

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20180725151011.25951-1-arm...@redhat.com Subject: [Qemu-devel] [RFC PATCH] rbd: Don't convert keypairs to JSON and back === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1

Re: [Qemu-devel] [Bug 1776478] Re: Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation

On 25 July 2018 at 18:11, guysoft wrote: > target: No such file or directory. > /tmp/mount/remote: No such file or directory. > (gdb) file DISTRHO-Ports/libs/lv2_ttl_generator > Reading symbols from DISTRHO-Ports/libs/lv2_ttl_generator...(no debugging > symbols found)...done. > (gdb) file

Re: [Qemu-devel] VCPU hotplug on KVM/ARM

Thanks everyone. It sounds like there is consensus around how best to proceed (at a high level at least). Since Igor has already gotten started, I'll coordinate with him offline to see where I can jump in. Thanks, -Maran On 7/25/2018 6:07 AM, Marc Zyngier wrote: On 25/07/18 13:28, Andrew

[Qemu-devel] [Bug 1776478] Re: Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation

target: No such file or directory. /tmp/mount/remote: No such file or directory. (gdb) file DISTRHO-Ports/libs/lv2_ttl_generator Reading symbols from DISTRHO-Ports/libs/lv2_ttl_generator...(no debugging symbols found)...done. (gdb) file DISTRHO-Ports/bin/lv2/TAL-Filter-2.lv2/TAL-Filter-2.so

Re: [Qemu-devel] [PATCH for-3.1 00/10] Move virtio-ccw devices to separate files

On 25.07.2018 15:48, Cornelia Huck wrote: > On Wed, 25 Jul 2018 14:20:14 +0200 > Thomas Huth wrote: > >> For more fine-grained control over the build process, it would be good >> to have the possibility to disable single virtio devices, too. We already >> have CONFIG_VIRTIO_* switches in the

Re: [Qemu-devel] [PATCH v4 07/55] target/mips: Add emulation of nanoMIPS 16-bit load and store instructions

> It might be handy to temporarily add > > target/mips/translate.o: QEMU_CFLAGS += -Wshadow=local > > to target/mips/Makefile.objs, but I don't know how prevalent that situation is > within the existing code base... Richard, thanks for this useful tip. I did similar checks utilizing gcc

Re: [Qemu-devel] [PATCH for-3.1 00/10] Move virtio-ccw devices to separate files

On 25.07.2018 18:21, Juan Quintela wrote: > Christian Borntraeger wrote: >> Are you planning to do a similar thing for virtio-pci? I think it would be >> good >> to keep virtio-ccw similar to virtio-pci when it makes sense. Somebody™ should do it, yes. For the context, see:

[Qemu-devel] [Bug 1783362] Re: qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0

** Summary changed: - qemu-user-aarch64: mmap returns success (NULL, 0) instead of failure (MAP_FAILED, -1) with len==0 + qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0 -- You received this bug notification because you are a member of qemu-

Re: [Qemu-devel] [PATCH v1] s390x/cpu_models: Add "-cpu max" support

On Wed, Jul 25, 2018 at 11:12:33AM +0200, David Hildenbrand wrote: > The "max" CPU model behaves like "-cpu host" when KVM is enabled, and like > a CPU with the maximum possible feature set when TCG is enabled. > > While the "host" model can not be used under TCG ("kvm_required"), the > "max"

[Qemu-devel] [Bug 1776478] Re: Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation

http://tinkering-is-fun.blogspot.com/2009/12/debugging-non-native- programs-with-qemu.html looks like a plausible tutorial for what you need to do with "file" (and has some other commands that might help for dynamically linked libraries). What you want to do when you get to the SIGABRT is tell gdb

[Qemu-devel] [Bug 1776478] Re: Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation

It wants debug symbols for the guest binary, not for QEMU. As it suggests, the "file" command pointed at the guest binary ought to help. This commandline isn't right, incidentally: gdb-multiarch target remote :1234 "target remote :1234" is a command for the gdb prompt, not a set of command

Re: [Qemu-devel] [PATCH v2 3/8] migration: show the statistics of compression

* Peter Xu (pet...@redhat.com) wrote: > On Mon, Jul 23, 2018 at 03:39:18PM +0800, Xiao Guangrong wrote: > > > > > > On 07/23/2018 12:36 PM, Peter Xu wrote: > > > On Thu, Jul 19, 2018 at 08:15:15PM +0800, guangrong.x...@gmail.com wrote: > > > > @@ -1597,6 +1608,24 @@ static void

[Qemu-devel] [Bug 1776478] Re: Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation

Hey, So all I got was this now: gdb-multiarch target remote :1234 Excess command line arguments ignored. (:1234) GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This

Re: [Qemu-devel] [RFC PATCH] rbd: Don't convert keypairs to JSON and back

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20180725151011.25951-1-arm...@redhat.com Subject: [Qemu-devel] [RFC PATCH] rbd: Don't convert keypairs to JSON and back === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1

Re: [Qemu-devel] [PATCH for-3.1 00/10] Move virtio-ccw devices to separate files

Christian Borntraeger wrote: > Are you planning to do a similar thing for virtio-pci? I think it would be > good > to keep virtio-ccw similar to virtio-pci when it makes sense. +1 to that. Later, Juan.

Re: [Qemu-devel] [PATCH v2 for-3.0] tests/libqtest: Improve kill_qemu()

Eric Blake writes: > On 07/24/2018 01:36 AM, Markus Armbruster wrote: >> Eric Blake writes: >> >>> In kill_qemu() we have an assert that checks that the QEMU process >>> didn't dump core: >>> assert(!WCOREDUMP(wstatus)); >>> >>> Unfortunately the WCOREDUMP macro here means the

Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type

On Wed, 25 Jul 2018 13:36:45 +0200 Andrew Jones wrote: > On Wed, Jul 25, 2018 at 11:50:41AM +0100, Dr. David Alan Gilbert wrote: > > * Andrew Jones (drjo...@redhat.com) wrote: > > > On Wed, Jul 25, 2018 at 01:30:52PM +0800, Hongbo Zhang wrote: > > > > For the Aarch64, there is one machine

Re: [Qemu-devel] [RFC PATCH] rbd: Don't convert keypairs to JSON and back

On Wed, Jul 25, 2018 at 10:56:48AM -0500, Eric Blake wrote: > On 07/25/2018 10:10 AM, Markus Armbruster wrote: > > qemu_rbd_parse_filename() builds a keypairs QList, converts it to JSON, and > > stores the resulting QString in a QDict. > > > > qemu_rbd_co_create_opts() and qemu_rbd_open() get the

Re: [Qemu-devel] [PATCH v5 00/24] Fixing record/replay and adding reverse debugging

Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20180725121311.12867.21729.stgit@pasha-VirtualBox Subject: [Qemu-devel] [PATCH v5 00/24] Fixing record/replay and adding reverse debugging === TEST SCRIPT BEGIN ===

Re: [Qemu-devel] [PATCH v3 3/5] qcow2: Introduce an option for sufficient L2 cache for the entire image

On Wed, Jul 25, 2018 at 06:23:45PM +0300, Leonid Bloch wrote: > On 07/25/2018 04:32 PM, Kevin Wolf wrote: > > > Another interesting question is whether 'full' shouldn't keep > > > meaning > > > full throughout the lifetime of the BlockDriverState, i.e. > > > should it > > >

Re: [Qemu-devel] [RFC PATCH] rbd: Don't convert keypairs to JSON and back

On 07/25/2018 10:10 AM, Markus Armbruster wrote: qemu_rbd_parse_filename() builds a keypairs QList, converts it to JSON, and stores the resulting QString in a QDict. qemu_rbd_co_create_opts() and qemu_rbd_open() get the QString from the QDict, pass it to qemu_rbd_set_keypairs(), which converts

Re: [Qemu-devel] [PATCH hack dontapply v2 0/7] Dynamic _CST generation

On Wed, 25 Jul 2018 15:44:37 +0300 "Michael S. Tsirkin" wrote: > On Wed, Jul 25, 2018 at 02:32:11PM +0200, Igor Mammedov wrote: > > On Tue, 10 Jul 2018 03:01:30 +0300 > > "Michael S. Tsirkin" wrote: > > > > > Now that basic support for guest CPU PM is upstream, I started looking > > > for

Re: [Qemu-devel] [PATCH v3 3/5] qcow2: Introduce an option for sufficient L2 cache for the entire image

Am 25.07.2018 um 17:23 hat Leonid Bloch geschrieben: > On 07/25/2018 04:32 PM, Kevin Wolf wrote: > > Am 25.07.2018 um 14:32 hat Leonid Bloch geschrieben: > > > On 07/25/2018 03:22 PM, Eric Blake wrote: > > > > > > On 07/25/2018 03:26 AM, Kevin Wolf wrote: > > > > > > Only looking

Re: [Qemu-devel] [PATCH v3 18/40] target/mips: Add emulation of nanoMIPS 32-bit load and store instructions

Hello, Richard. Sorry for bothering you. One more question. > On 07/19/2018 05:54 AM, Stefan Markovic wrote: > > +case NM_ADDIUGP_B: > > +gen_arith_imm(ctx, OPC_ADDIU, rt, 28, u); > > +break; > > Use gen_op_addr_add, since behaves_like('DADDIU[GP.B]'). Did you

Re: [Qemu-devel] [PATCH v3 13/40] target/mips: Add emulation of misc nanoMIPS instructions (pool32a0)

Hi, Richard. > > +case NM_SOV: > > +{ > > +TCGv t0 = tcg_temp_local_new(); > > +TCGv t1 = tcg_temp_new(); > > +TCGv t2 = tcg_temp_new(); > > +TCGLabel *l1 = gen_new_label(); > > + > > +gen_load_gpr(t1, rs); > > +gen_load_gpr(t2, rt); > > +

Re: [Qemu-devel] [qemu-s390x] [PATCH] s390x/cpumodel: enum type S390FeatGroup now gets generated

Acked-by Christian Borntraeger A quick test seems to indicate that everything is good. On 07/25/2018 04:36 PM, Michael Mueller wrote: > The enumeration type S390FeatGroup is now generated as well. > This shall simplify the definition of new feature groups > without the requirement to modify

[Qemu-devel] [Bug 1783362] Re: qemu-user-aarch64: mmap returns success (NULL, 0) instead of failure (MAP_FAILED, -1) with len==0

I did some research and found that this bug is present since 2003: - 2003/05/13: https://github.com/qemu/qemu/commit/54936004fddc52c321cb3f9a9a51140e782bed5d#diff-2bf4728e0473404c39c97190bd02b2f8 -

Re: [Qemu-devel] [PATCH v3 3/5] qcow2: Introduce an option for sufficient L2 cache for the entire image

On 07/25/2018 04:32 PM, Kevin Wolf wrote: Am 25.07.2018 um 14:32 hat Leonid Bloch geschrieben: On 07/25/2018 03:22 PM, Eric Blake wrote: On 07/25/2018 03:26 AM, Kevin Wolf wrote: Only looking at the external interface for now, I wonder whether it would be nicer not to

[Qemu-devel] [RFC PATCH] rbd: Don't convert keypairs to JSON and back

qemu_rbd_parse_filename() builds a keypairs QList, converts it to JSON, and stores the resulting QString in a QDict. qemu_rbd_co_create_opts() and qemu_rbd_open() get the QString from the QDict, pass it to qemu_rbd_set_keypairs(), which converts it back into a QList. Drop both conversions, store

Re: [Qemu-devel] [PATCH v4 23/55] target/mips: Add emulation of DSP ASE for nanoMIPS - part 3

> From: Aleksandar Markovic > Sent: Tuesday, July 24, 2018 7:31 PM > From: Stefan Markovic > > Add emulation of DSP ASE instructions for nanoMIPS - part 3. This patch should be further split into four or so patches - each dealing with a single instruction pool. Also, DSP instruction pools

Re: [Qemu-devel] [PATCH v4 48/55] linux-user: Add target_syscall.h header for nanoMIPS

> From: Aleksandar Markovic > Sent: Tuesday, July 24, 2018 7:32 PM > From: Aleksandar Rikalo > > Add target_syscall.h header for nanoMIPS. > target_syscall.h is missing #ifndef NANOMIPS_TARGET_SYSCALL_H #define NANOMIPS_TARGET_SYSCALL_H ... #endif Aleksandar M.

Re: [Qemu-devel] [PATCH v5 08/24] replay: introduce info hmp/qmp command

* Pavel Dovgalyuk (pavel.dovga...@ispras.ru) wrote: > This patch introduces 'info replay' monitor command and > corresponding qmp request. > These commands request the current record/replay mode, replay log file name, > and the execution step (number or recorded/replayed instructions). > >

Re: [Qemu-devel] [PATCH v4 52/55] linux-user: Add signal.c for nanoMIPS

> From: Aleksandar Markovic > Sent: Tuesday, July 24, 2018 7:32 PM > From: Dimitrije Nikolic > > Add signal.c as a dredirection of regular mips' signal.c, but also > amend regular mips' signal.c. this is done to avoid the duplication > of large pieces of code. dredirection of -> redirection to

[Qemu-devel] [PATCH] s390x/cpumodel: enum type S390FeatGroup now gets generated

The enumeration type S390FeatGroup is now generated as well. This shall simplify the definition of new feature groups without the requirement to modify existing code. Signed-off-by: Michael Mueller --- target/s390x/cpu_features.c | 1 - target/s390x/cpu_features.h | 19 +--

[Qemu-devel] [PATCH for-3.1] tests/cpu-plug-test: check CPU hotplug on ppc64 with KVM

Commit b585395b655 fixed a regression introduced by some recent changes in the XICS code, that was causing QEMU to crash instantly during CPU hotplug with KVM. This is typically the kind of bug we'd like our test suite to detect before it gets merged. Unfortunately, the current tests run with

Re: [Qemu-devel] [PATCH hack dontapply v2 7/7] pc: HACK: acpi: tie in _CST object to Processor

On Wed, 25 Jul 2018 15:50:09 +0300 "Michael S. Tsirkin" wrote: > On Wed, Jul 25, 2018 at 02:37:24PM +0200, Igor Mammedov wrote: > > On Tue, 10 Jul 2018 03:01:34 +0300 > > "Michael S. Tsirkin" wrote: > > > > > Based on patch by Igor Mammedov. > > > > > > This is a hack: we definitely

Re: [Qemu-devel] [PATCH] s390x/cpumodel: enum type S390FeatGroup now gets generated

On 25.07.2018 16:36, Michael Mueller wrote: > The enumeration type S390FeatGroup is now generated as well. > This shall simplify the definition of new feature groups > without the requirement to modify existing code. > > Signed-off-by: Michael Mueller > --- > target/s390x/cpu_features.c | 1 -

Re: [Qemu-devel] [PATCH hack dontapply v2 6/7] acpi: aml generation for _CST

On Wed, 25 Jul 2018 15:54:26 +0300 "Michael S. Tsirkin" wrote: > On Wed, Jul 25, 2018 at 02:42:05PM +0200, Igor Mammedov wrote: > > On Tue, 10 Jul 2018 03:01:33 +0300 > > "Michael S. Tsirkin" wrote: > > > > > This adds a method called CCST under CPUS. > > > Each CPU will add _CST calling in

[Qemu-devel] [PATCH v3 2/4] hw/arm/sysbus-fdt: Allow device matching with DT compatible value

From: Auger Eric Up to now we have relied on the device type to identify a device tree node creation function. Since we would like the vfio-platform device to be instantiatable with different compatible strings we introduce the capability to specialize the node creation depending on actual

[Qemu-devel] [PATCH v3 0/4] hw/arm/sysbus-fdt: Generic DT Pass-Through

Hi all, This patch series allows to export generic devices in DT using vfio-platform, providing direct access from a QEMU+KVM guest to the exported devices. - Patches 1-2 (submitted before by Eric Auger) make the vfio-platform device non-abstract, incl. matching using a compatible

Re: [Qemu-devel] [PATCH for-3.1] s390x: introduce 3.1 compat machine

On Mon, 23 Jul 2018 15:10:16 +0200 Cornelia Huck wrote: > Signed-off-by: Cornelia Huck > --- > hw/s390x/s390-virtio-ccw.c | 17 - > include/hw/compat.h| 3 +++ > 2 files changed, 19 insertions(+), 1 deletion(-) Queued to s390-next.

[Qemu-devel] [PATCH v3 1/4] vfio/platform: Make the vfio-platform device non-abstract

From: Auger Eric Up to now the vfio-platform device has been abstract and could not be instantiated. The integration of a new vfio platform device required creating a dummy derived device which only set the compatible string. Following the few vfio-platform device integrations we have seen the

[Qemu-devel] [PATCH v3 4/4] hw/arm/sysbus-fdt: Add support for instantiating generic devices

Add a fallback for instantiating generic devices without a type-specific or compatible-specific instantation method. This will be used when no other match is found. The generic instantation method creates a device node with "reg" and (optional) "interrupts" properties, and copies the

[Qemu-devel] [PATCH v3 3/4] hw/arm/virt: Allow dynamic sysbus devices again

Allow the instantation of generic dynamic sysbus devices again, without the need to create a new device-specific vfio type. This is more or less a partial revert of commit 6f2062b9758ebc64 ("hw/arm/virt: Allow only supported dynamic sysbus devices"). Signed-off-by: Geert Uytterhoeven --- v3:

[Qemu-devel] [PATCH v5 3/4] qcow2: Introduce an option for sufficient L2 cache for the entire image

An option "l2-cache-full" is introduced to automatically set the qcow2 L2 cache to a sufficient value for covering the entire image. The memory overhead when using this option is not big (1 MB for each 8 GB of virtual image size with the default cluster size) and it can noticeably improve

[Qemu-devel] [PATCH v5 1/4 for-3.0] qcow2: A grammar fix in conflicting cache sizing error message

Signed-off-by: Leonid Bloch --- block/qcow2.c | 2 +- tests/qemu-iotests/103.out | 4 ++-- tests/qemu-iotests/137.out | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/block/qcow2.c b/block/qcow2.c index 6162ed8be2..ec9e6238a0 100644 --- a/block/qcow2.c +++

[Qemu-devel] [PATCH v5 4/4] iotests: Add tests for the new l2-cache-full option

Signed-off-by: Leonid Bloch --- tests/qemu-iotests/103 | 6 ++ tests/qemu-iotests/103.out | 2 ++ tests/qemu-iotests/137 | 2 ++ tests/qemu-iotests/137.out | 2 ++ 4 files changed, 12 insertions(+) diff --git a/tests/qemu-iotests/103 b/tests/qemu-iotests/103 index

[Qemu-devel] [PATCH v5 2/4 for-3.0] qcow2: Options' documentation fixes

Signed-off-by: Leonid Bloch --- docs/qcow2-cache.txt | 3 +++ qemu-options.hx | 10 ++ 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/docs/qcow2-cache.txt b/docs/qcow2-cache.txt index 8a09a5cc5f..3673f2be0e 100644 --- a/docs/qcow2-cache.txt +++

[Qemu-devel] [PATCH v5 0/4] Introduction of l2-cache-full option for qcow2 images

This series introduces an option to calculate and allocate automatically enough qcow2 L2 cache to cover the entire image. Using cache that covers the entire image can benefit performance, while having only a small memory overhead (just 1 MB for every 8 GB of virtual image size with the default

[Qemu-devel] [PULL 0/2] seccomp branch queue

The following changes since commit 18a398f6a39df4b08ff86ac0d38384193ca5f4cc: Update version for v3.0.0-rc2 release (2018-07-24 22:06:31 +0100) are available in the Git repository at: https://github.com/otubo/qemu.git tags/pull-seccomp-20180725 for you to fetch changes up

[Qemu-devel] [PULL 2/2] RFC: seccomp: prefer SCMP_ACT_KILL_PROCESS if available

From: Marc-André Lureau The upcoming libseccomp release should have SCMP_ACT_KILL_PROCESS action (https://github.com/seccomp/libseccomp/issues/96). SCMP_ACT_KILL_PROCESS is preferable to immediately terminate the offending process, rather than having the SIGSYS handler running. Use

[Qemu-devel] [PULL 1/2] seccomp: use SIGSYS signal instead of killing the thread

From: Marc-André Lureau The seccomp action SCMP_ACT_KILL results in immediate termination of the thread that made the bad system call. However, qemu being multi-threaded, it keeps running. There is no easy way for parent process / management layer (libvirt) to know about that situation.

Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type

On Wed, Jul 25, 2018 at 03:46:01PM +0200, Ard Biesheuvel wrote: > On 25 July 2018 at 15:38, Andrew Jones wrote: > > On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel wrote: > >> On 25 July 2018 at 14:59, Andrew Jones wrote: > >> > On Wed, Jul 25, 2018 at 01:47:00PM +0100, Daniel P.

Re: [Qemu-devel] [PATCH for-3.1 00/10] Move virtio-ccw devices to separate files

Are you planning to do a similar thing for virtio-pci? I think it would be good to keep virtio-ccw similar to virtio-pci when it makes sense. On 07/25/2018 02:20 PM, Thomas Huth wrote: > For more fine-grained control over the build process, it would be good > to have the possibility to disable

Re: [Qemu-devel] [PATCH for-3.1 00/10] Move virtio-ccw devices to separate files

On Wed, 25 Jul 2018 14:20:14 +0200 Thomas Huth wrote: > For more fine-grained control over the build process, it would be good > to have the possibility to disable single virtio devices, too. We already > have CONFIG_VIRTIO_* switches in the Makefiles, but currently all > virtio-ccw devices are

Re: [Qemu-devel] [PATCH for-3.1 2/2] acpi: Decouple ACPI hotplug callbacks from HotplugHandler

On Wed, Jul 25, 2018 at 08:57:20AM +0200, Igor Mammedov wrote: > On Tue, 24 Jul 2018 21:14:48 +0300 > "Michael S. Tsirkin" wrote: > > > On Tue, Jul 24, 2018 at 05:28:44PM +0200, Igor Mammedov wrote: > > > On Tue, 24 Jul 2018 09:39:16 -0300 > > > Eduardo Habkost wrote: > > > > > > > On Tue,

Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type

On 25 July 2018 at 15:38, Andrew Jones wrote: > On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel wrote: >> On 25 July 2018 at 14:59, Andrew Jones wrote: >> > On Wed, Jul 25, 2018 at 01:47:00PM +0100, Daniel P. Berrangé wrote: >> >> Would iut make any sense to call the machine

Re: [Qemu-devel] [PATCH v5 24/24] slirp: fix ipv6 timers

Pavel Dovgalyuk, le mer. 25 juil. 2018 15:17:06 +0300, a ecrit: > ICMP implementation for IPv6 uses timers based on virtual clock. > This is incorrect because this service is not related to the guest state. ? Why not? The RAs are seen by the guest. As documented: * @QEMU_CLOCK_REALTIME: Real

Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type

On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel wrote: > On 25 July 2018 at 14:59, Andrew Jones wrote: > > On Wed, Jul 25, 2018 at 01:47:00PM +0100, Daniel P. Berrangé wrote: > >> Would iut make any sense to call the machine "refplatform" or "refboard" > >> to indicate it is a generic

Re: [Qemu-devel] [PATCH v3 3/5] qcow2: Introduce an option for sufficient L2 cache for the entire image

Am 25.07.2018 um 14:32 hat Leonid Bloch geschrieben: > On 07/25/2018 03:22 PM, Eric Blake wrote: > > On 07/25/2018 03:26 AM, Kevin Wolf wrote: > > Only looking at the external interface for now, I wonder whether it > would be nicer not to have two mutually exclusive options,

Re: [Qemu-devel] [PATCH v1] s390x/cpu_models: Add "-cpu max" support

On Wed, 25 Jul 2018 14:49:45 +0200 David Hildenbrand wrote: > >> > >>> Maybe add a comment that for kvm we try the host model, and only that > >>> can fail (i.e., for tcg this will always work)? > >> > >> "we expect only errors under KVM, when we actually query the kernel" > > > > "We

  1   2   3   >