[Qemu-devel] [Bug 1838703] Re: Makefile BUG in edk2 firmware install 4.1.0-rc3

The same issue was reported and patched on qemu-devel by Olaf Hering two months ago. The patch received three Reviewed-by tags, but nobody bothered to queue it. [Qemu-devel] [PATCH v1] Makefile: remove DESTDIR from firmware file cont The thread is split over two months, hence two links below,

Re: [Qemu-devel] [PATCH v3 03/15] target/arm/monitor: Introduce qmp_query_cpu_model_expansion

On 8/2/19 9:27 AM, Richard Henderson wrote: > On 8/2/19 5:25 AM, Andrew Jones wrote: >> Note, certainly more features may be added to the list of >> advertised features, e.g. 'vfp' and 'neon'. The only requirement >> is that their property set accessors fail when invalid >> configurations are

[Qemu-devel] [PATCH] riscv: sifive_e: Correct various SoC IP block sizes

Some of the SoC IP block sizes are wrong. Correct them according to the FE310 manual. Signed-off-by: Bin Meng --- hw/riscv/sifive_e.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c index 2a499d8..9655847 100644 ---

[Qemu-devel] [Bug 1838703] Re: Makefile BUG in edk2 firmware install 4.1.0-rc3

I'm on Arch, but that shouldn't matter. It's a clear bug in the Makefile. I note that Fedora doesn't ship these blobs as they're provide by separate edk2 package. Attached patch fixes it for me. ** Patch added: "edk2 Makefile fix"

Re: [Qemu-devel] [RFC] virtio-mmio: implement modern (v2) personality (virtio-1)

On 08/02/19 11:20, Peter Maydell wrote: > On Fri, 2 Aug 2019 at 01:26, Laszlo Ersek wrote: >> But it's extra work, not entirely risk-free (regressions), and I can't >> tell if someone out there still uses virtio-mmio (despite me thinking >> that would be unreasonable). I wouldn't like to see more

Re: [Qemu-devel] [PATCH-for-3.1.1 1/1] Fix heap overflow in ip_reass on big packet input

On Fri, Aug 2, 2019 at 10:09 PM Philippe Mathieu-Daudé wrote: > > From: Samuel Thibault > > When the first fragment does not fit in the preallocated buffer, q will > already be pointing to the ext buffer, so we mustn't try to update it. > > Signed-off-by: Samuel Thibault > (cherry picked from

Re: [Qemu-devel] [PATCH] hmp/info_migration: formatting migration capability output

On Fri, Aug 02, 2019 at 11:02:20AM +0100, Dr. David Alan Gilbert wrote: >* Wei Yang (richardw.y...@linux.intel.com) wrote: >> On Fri, Aug 02, 2019 at 07:24:34AM +0200, Markus Armbruster wrote: >> >Subject doesn't quite conform to conventions. Suggest >> > >> >hmp: Improve how "info migrate"

Re: [Qemu-devel] [PATCH] util/hbitmap: fix unaligned reset

On 02.08.19 20:58, Vladimir Sementsov-Ogievskiy wrote: > hbitmap_reset is broken: it rounds up the requested region. It leads to > the following bug, which is shown by fixed test: > > assume granularity = 2 > set(0, 3) # count becomes 4 > reset(0, 1) # count becomes 2 > > But user of the

Re: [Qemu-devel] [PATCH 27/28] sysemu: Move the VMChangeStateEntry typedef to qemu/typedefs.h

Markus Armbruster writes: > Paolo Bonzini writes: > >> On 26/07/19 14:05, Markus Armbruster wrote: >>> +typedef struct VMChangeStateEntry VMChangeStateEntry; >>> typedef struct VMStateDescription VMStateDescription; >>> >> >> This is a bit borderline; I'd rather split sysemu/sysemu.h, e.g.

Re: [Qemu-devel] [ANNOUNCE] QEMU 3.1.1 Stable released

Quoting Philippe Mathieu-Daudé (2019-08-02 12:59:08) > On 8/2/19 7:50 PM, Michael Roth wrote: > > Hi everyone, > > > > I am pleased to announce that the QEMU v3.1.1 stable release is now > > available: > > > > You can grab the tarball from our download page here: > > > >

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

> So looks like there's some further variable involved beyond just the > glib update - perhaps something about the host OS is combining with > the glib update to trigger it. Agreed - I just retested using a Fedora 30 instance on EC2, with glib2-2.60.1-2.fc30.x86_64, and was also unable to

Re: [Qemu-devel] [PATCH] util/hbitmap: fix unaligned reset

On 8/2/19 2:58 PM, Vladimir Sementsov-Ogievskiy wrote: > hbitmap_reset is broken: it rounds up the requested region. It leads to > the following bug, which is shown by fixed test: > > assume granularity = 2 > set(0, 3) # count becomes 4 > reset(0, 1) # count becomes 2 > > But user of the

[Qemu-devel] [PATCH] util/hbitmap: fix unaligned reset

hbitmap_reset is broken: it rounds up the requested region. It leads to the following bug, which is shown by fixed test: assume granularity = 2 set(0, 3) # count becomes 4 reset(0, 1) # count becomes 2 But user of the interface assume that virtual bit 1 should be still dirty, so hbitmap should

Re: [Qemu-devel] [PATCH] riscv: hmp: Add a command to show virtual memory mappings

* Bin Meng (bmeng...@gmail.com) wrote: > This adds 'info mem' command for RISC-V, to show virtual memory > mappings that aids debugging. > > Rather than showing every valid PTE, the command compacts the > output by merging all contiguous physical address mappings into > one block and only shows

Re: [Qemu-devel] [PATCH v4 13/54] plugin: add user-facing API

One thing I would find useful is the ability to access register values during an execution-time callback. I think the easiest way to do that generically would be to expose them via the gdb functionality (like Pavel's earlier patchset did [1]), though that (currently) limits you to the

Re: [Qemu-devel] [PATCH v3 12/15] target/arm/kvm64: max cpu: Enable SVE when available

On 8/2/19 5:25 AM, Andrew Jones wrote: > Enable SVE in the KVM guest when the 'max' cpu type is configured > and KVM supports it. KVM SVE requires use of the new finalize > vcpu ioctl, so we add that now too. For starters SVE can only be > turned on or off, getting all vector lengths the host CPU

Re: [Qemu-devel] [PATCH v3 11/15] target/arm/kvm64: Add kvm_arch_get/put_sve

On 8/2/19 5:25 AM, Andrew Jones wrote: > +/* > + * SVE registers are encoded in KVM's memory in an endianness-invariant > format. > + * The byte at offset i from the start of the in-memory representation > contains > + * the bits [(7 + 8 * i) : (8 * i)] of the register value. As this means the >

[Qemu-devel] [Bug 1790460] Re: -icount, sleep=off mode is broken (target slows down or hangs)

I think we fixed this bug in commit 013aabdc665e4256b38d which would have been in the 3.1.0 release (this is why we closed #1774677, which as you say is the same issue). ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of

[Qemu-devel] [Bug 1653063] Re: qemu-system-arm hangs with -icount and -nodefaults

I think we fixed this bug in commit 013aabdc665e4256b38d which would have been in the 3.1.0 release (this is why we closed #1774677, which is the same issue). ** Changed in: qemu Status: Confirmed => Fix Released -- You received this bug notification because you are a member of qemu-

[Qemu-devel] [PATCH-for-3.1.1 1/1] Fix heap overflow in ip_reass on big packet input

From: Samuel Thibault When the first fragment does not fit in the preallocated buffer, q will already be pointing to the ext buffer, so we mustn't try to update it. Signed-off-by: Samuel Thibault (cherry picked from libslirp commit 126c04acbabd7ad32c2b018fe10dfac2a3bc1210) Fixes:

[Qemu-devel] [PATCH-for-3.1.1 0/1] Backport of CVE-2019-14378 fix

Trivial backport from the libslirp repository. Samuel Thibault (1): Fix heap overflow in ip_reass on big packet input slirp/ip_input.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.20.1

[Qemu-devel] [Bug 1830864] Re: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); isar_feature_arm_div(_->isar); })' failed

Fix for this is in git and will be in 4.1.0. ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1830864 Title: Assertion `no_aa32 || ({

[Qemu-devel] [Bug 1838277] Re: qemu-system-aarch64: regression in 3.1: breakpoint instructions always routed to EL_D even when current EL is higher

The fix for this is now in git and will be in the 4.1.0 release. ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838277 Title:

[Qemu-devel] [Bug 1817345] Re: configure script breaks when $source_path contains white spaces

Antonio's patches are in git and will be in the upcoming 4.1.0 release. ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1817345 Title:

[Qemu-devel] [Bug 1838763] Re: Bugs in SSH module (ssh.c)

$ uname -smrv Linux 5.1.17 #7 SMP Wed Jul 10 08:35:08 UTC 2019 aarch64 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.04.2 LTS Release:18.04 Codename: bionic $ dpkg -l|fgrep libssh ii libssh-4:arm64

Re: [Qemu-devel] [ANNOUNCE] QEMU 3.1.1 Stable released

On 8/2/19 7:50 PM, Michael Roth wrote: > Hi everyone, > > I am pleased to announce that the QEMU v3.1.1 stable release is now > available: > > You can grab the tarball from our download page here: > > https://www.qemu.org/download/#source > > v3.1.1 is now tagged in the official qemu.git

Re: [Qemu-devel] [Qemu-stable] [PATCH 00/36] Patch Round-up for stable 3.1.1, freeze on 2019-07-29

On 7/23/19 8:50 PM, Michael Roth wrote: > Quoting Michael Roth (2019-07-23 12:00:28) >> Hi everyone, >> >> >> The following new patches are queued for QEMU stable v3.1.1: >> >>

[Qemu-devel] [ANNOUNCE] QEMU 3.1.1 Stable released

Hi everyone, I am pleased to announce that the QEMU v3.1.1 stable release is now available: You can grab the tarball from our download page here: https://www.qemu.org/download/#source v3.1.1 is now tagged in the official qemu.git repository, and the stable-3.1 branch has been updated

[Qemu-devel] [Bug 1763536] Re: go build fails under qemu-ppc64le-static (qemu-user)

We recently fixed bug #1696773 which was a cause of various crashes or other problems when trying to run go binaries under linux-user, including "go build hello.go". So I strongly suspect this is a duplicate of that bug. Could you test with the QEMU v4.1.0 rc3 or later, please? -- You received

Re: [Qemu-devel] [PATCH] ehci: Ensure that device is not NULL before calling usb_ep_get

On Fri, Aug 02, 2019 at 09:46:26AM -0700, Guenter Roeck wrote: > On Fri, Aug 02, 2019 at 04:11:49PM +0200, Gerd Hoffmann wrote: > > On Wed, Jul 31, 2019 at 01:08:50PM +0200, Philippe Mathieu-Daudé wrote: > > > On 7/30/19 7:45 PM, Guenter Roeck wrote: > > > > The following assert is seen once in a

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

Doh, sorry for my comment earlier where I mistakenly used sparc instead of sparc64. I've now tested QEMU git master with that sparc64 ISO and qemu-system- sparc64. I still can't reproduce it though - it boots past the disk probing, and into the installer, where it asks for the terminal type.

Re: [Qemu-devel] [PATCH] ehci: Ensure that device is not NULL before calling usb_ep_get

On Fri, Aug 02, 2019 at 04:11:49PM +0200, Gerd Hoffmann wrote: > On Wed, Jul 31, 2019 at 01:08:50PM +0200, Philippe Mathieu-Daudé wrote: > > On 7/30/19 7:45 PM, Guenter Roeck wrote: > > > The following assert is seen once in a while while resetting the > > > Linux kernel. > > > > > >

[Qemu-devel] [Bug 1838475] Re: qemu-system-arm exits when cortex-m4 floating point used and irq occurs

Now fixed in git master; will be in the imminent 4.1 release. ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838475 Title:

Re: [Qemu-devel] [PATCH v3 1/9] block: add .bdrv_need_rw_file_child_during_reopen_rw handler

02.08.2019 19:23, Vladimir Sementsov-Ogievskiy wrote: > 02.08.2019 18:42, Kevin Wolf wrote: >> Am 31.07.2019 um 14:09 hat Max Reitz geschrieben: >>> On 25.07.19 11:18, Vladimir Sementsov-Ogievskiy wrote: On reopen to rw parent may need rw access to child in .prepare, for example qcow2

Re: [Qemu-devel] [PATCH for-4.1] target/arm: Avoid bogus NSACR traps on M-profile without Security Extension

On Fri, 2 Aug 2019 at 08:51, Damien Hedde wrote: > > > On 8/1/19 4:38 PM, Peter Maydell wrote: > > On Thu, 1 Aug 2019 at 15:20, Damien Hedde > > wrote: > >> > >> > >> On 8/1/19 12:57 PM, Peter Maydell wrote: > >>> In Arm v8.0 M-profile CPUs without the Security Extension and also in > >>> v7M

Re: [Qemu-devel] [PATCH v3 07/15] target/arm: Allow SVE to be disabled via a CPU property

On 8/2/19 5:25 AM, Andrew Jones wrote: > Since 97a28b0eeac14 ("target/arm: Allow VFP and Neon to be disabled via > a CPU property") we can disable the 'max' cpu model's VFP and neon > features, but there's no way to disable SVE. Add the 'sve=on|off' > property to give it that flexibility. We also

Re: [Qemu-devel] [PATCH v3 06/15] target/arm/cpu: Use div-round-up to determine predicate register array size

On 8/2/19 5:25 AM, Andrew Jones wrote: > Unless we're guaranteed to always increase ARM_MAX_VQ by a multiple of > four, then we should use DIV_ROUND_UP to ensure we get an appropriate > array size. > > Signed-off-by: Andrew Jones > --- > target/arm/cpu.h | 2 +- > 1 file changed, 1

Re: [Qemu-devel] [PATCH 3/3] hw/mips/mips_jazz: Remove no-longer-necessary override of do_unassigned_access

On 8/2/19 6:04 PM, Peter Maydell wrote: > Now that the MIPS CPU implementation uses the new > do_transaction_failed hook, we can remove the old code that handled > the do_unassigned_access hook. > > Signed-off-by: Peter Maydell > --- > hw/mips/mips_jazz.c | 27 --- > 1

Re: [Qemu-devel] [PATCH 2/3] target/mips: Switch to do_transaction_failed() hook

Cc'ing James Hogan. On 8/2/19 6:04 PM, Peter Maydell wrote: > Switch the MIPS target from the old unassigned_access hook to the new > do_transaction_failed hook. > > Unlike the old hook, do_transaction_failed is only ever called from > the TCG memory access paths, so there is no need for the

Re: [Qemu-devel] [PATCH 0/3] target/mips: Convert to do_transaction_failed hook

Cc'ing broader MIPS audience. On 8/2/19 6:04 PM, Peter Maydell wrote: > This patchset converts the MIPS target away from the > old broken do_unassigned_access hook to the new (added in > 2017...) do_transaction_failed hook. > > The motivation here is: > * do_unassigned_access is broken because:

Re: [Qemu-devel] [PATCH v3 03/15] target/arm/monitor: Introduce qmp_query_cpu_model_expansion

On 8/2/19 5:25 AM, Andrew Jones wrote: > Note, certainly more features may be added to the list of > advertised features, e.g. 'vfp' and 'neon'. The only requirement > is that their property set accessors fail when invalid > configurations are detected. For vfp we would need something like > >

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

> The test image that the netbsd bug points to no longer exists. Please try this one instead: https://www.gson.org/bugs/qemu/NetBSD-8.99.47-sparc64.iso I just verified that this image works for reproducing the bug. -- You received this bug notification because you are a member of qemu-

Re: [Qemu-devel] [PATCH v3 1/9] block: add .bdrv_need_rw_file_child_during_reopen_rw handler

02.08.2019 18:42, Kevin Wolf wrote: > Am 31.07.2019 um 14:09 hat Max Reitz geschrieben: >> On 25.07.19 11:18, Vladimir Sementsov-Ogievskiy wrote: >>> On reopen to rw parent may need rw access to child in .prepare, for >>> example qcow2 needs to write IN_USE flags into stored bitmaps >>> (currently

Re: [Qemu-devel] [PATCH 1/3] hw/mips/mips_jazz: Override do_transaction_failed hook

On 8/2/19 6:04 PM, Peter Maydell wrote: > The MIPS Jazz ('magnum' and 'pica61') boards have some code which > overrides the CPU's do_unassigned_access hook, so they can intercept > it and not raise exceptions on data accesses to invalid addresses, > only for instruction fetches. > > We want to

Re: [Qemu-devel] [PATCH v2 0/9] add failover feature for assigned network devices

Patchew URL: https://patchew.org/QEMU/20190802150605.5880-1-jfreim...@redhat.com/ Hi, This series failed the asan build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash

Re: [Qemu-devel] [PATCH for 4.2 v5 10/12] target/mips: Style improvements in machine.c

On 8/1/19 6:45 PM, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fixes mostly errors and warings reported by 'checkpatch.pl -f'. "warnings" > > Signed-off-by: Aleksandar Markovic Reviewed-by: Philippe Mathieu-Daudé > --- > target/mips/machine.c | 4 ++-- > 1 file changed, 2

Re: [Qemu-devel] [PATCH for 4.2 v5 09/12] target/mips: Style improvements in internal.h

On 8/1/19 6:45 PM, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fixes mostly errors and warings reported by 'checkpatch.pl -f'. "warnings" > > Signed-off-by: Aleksandar Markovic Reviewed-by: Philippe Mathieu-Daudé > --- > target/mips/internal.h | 57 >

Re: [Qemu-devel] [PATCH for 4.2 v5 07/12] target/mips: Style improvements in cpu.c

On 8/1/19 6:45 PM, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fixes mostly errors and warings reported by 'checkpatch.pl -f'. "warnings" > > Signed-off-by: Aleksandar Markovic Reviewed-by: Philippe Mathieu-Daudé > --- > target/mips/cpu.c | 17 +++-- > 1 file

Re: [Qemu-devel] [PATCH for 4.2 v5 06/12] target/mips: Style improvements in cp0_timer.c

On 8/1/19 6:45 PM, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > Fixes mostly errors and warings reported by 'checkpatch.pl -f'. "warnings" > > Signed-off-by: Aleksandar Markovic Reviewed-by: Philippe Mathieu-Daudé > --- > target/mips/cp0_timer.c | 42

Re: [Qemu-devel] [PATCH v4 1/4] block: introducing 'bdrv_co_delete_file' interface

Am 28.06.2019 um 21:45 hat Daniel Henrique Barboza geschrieben: > Adding to Block Drivers the capability of being able to clean up > its created files can be useful in certain situations. For the > LUKS driver, for instance, a failure in one of its authentication > steps can leave files in the

Re: [Qemu-devel] [PATCH v7] qemu-io: add pattern file for write command

On 05.07.19 12:21, Denis Plotnikov wrote: > The patch allows to provide a pattern file for write > command. There was no similar ability before. > > Signed-off-by: Denis Plotnikov > --- > v7: > * fix variable naming > * make code more readable > * extend help for write command > > v6: >

[Qemu-devel] [Bug 1838658] Re: qemu 4.0.0 broken by glib update

> From the netbsd bug report it looks like the reproducer was demoed > using the sparc emulator - is that the only QEMU arch that is affected ? Only one arch is affected, but it's sparc64, not sparc. -- You received this bug notification because you are a member of qemu- devel-ml, which is

[Qemu-devel] [PATCH 2/3] target/mips: Switch to do_transaction_failed() hook

Switch the MIPS target from the old unassigned_access hook to the new do_transaction_failed hook. Unlike the old hook, do_transaction_failed is only ever called from the TCG memory access paths, so there is no need for the "ignore this if we're using KVM" hack that we were previously using to

[Qemu-devel] [PATCH 3/3] hw/mips/mips_jazz: Remove no-longer-necessary override of do_unassigned_access

Now that the MIPS CPU implementation uses the new do_transaction_failed hook, we can remove the old code that handled the do_unassigned_access hook. Signed-off-by: Peter Maydell --- hw/mips/mips_jazz.c | 27 --- 1 file changed, 4 insertions(+), 23 deletions(-) diff

[Qemu-devel] [PATCH 1/3] hw/mips/mips_jazz: Override do_transaction_failed hook

The MIPS Jazz ('magnum' and 'pica61') boards have some code which overrides the CPU's do_unassigned_access hook, so they can intercept it and not raise exceptions on data accesses to invalid addresses, only for instruction fetches. We want to switch MIPS over to using the do_transaction_failed

[Qemu-devel] [PATCH 0/3] target/mips: Convert to do_transaction_failed hook

This patchset converts the MIPS target away from the old broken do_unassigned_access hook to the new (added in 2017...) do_transaction_failed hook. The motivation here is: * do_unassigned_access is broken because: + it will be called for any kind of access to physical addresses where

Re: [Qemu-devel] [PATCH 1/2] tests/acceptance: Refactor and improve reporting in linux_ssh_mips_malta.py

On 8/2/19 5:35 PM, Aleksandar Markovic wrote: > From: Aleksandar Markovic > > This patch restructures code organization around the test case > executions. At the same time, rather than outputing a cryptic message: > > FAIL: True not found in [False], > > the following will be reported too, if

Re: [Qemu-devel] [PATCH v3 1/9] block: add .bdrv_need_rw_file_child_during_reopen_rw handler

Am 31.07.2019 um 14:09 hat Max Reitz geschrieben: > On 25.07.19 11:18, Vladimir Sementsov-Ogievskiy wrote: > > On reopen to rw parent may need rw access to child in .prepare, for > > example qcow2 needs to write IN_USE flags into stored bitmaps > > (currently it is done in a hacky way after commit

[Qemu-devel] [PATCH 2/2] tests/acceptance: Add new test cases in linux_ssh_mips_malta.py

From: Aleksandar Markovic Add 15 new tests cases. They all rely on simple commands used for detecting hardware configuration information. Signed-off-by: Aleksandar Markovic --- tests/acceptance/linux_ssh_mips_malta.py | 45 1 file changed, 45 insertions(+)

[Qemu-devel] [PATCH 0/2] tests/acceptance: Update MIPS Malta ssh test

From: Aleksandar Markovic This little series improves linux_ssh_mips_malta.py, both in the sense of code organization and in the sense of quantity of executed tests. Aleksandar Markovic (2): tests/acceptance: Refactor and improve reporting in linux_ssh_mips_malta.py tests/acceptance:

[Qemu-devel] [PATCH 1/2] tests/acceptance: Refactor and improve reporting in linux_ssh_mips_malta.py

From: Aleksandar Markovic This patch restructures code organization around the test case executions. At the same time, rather than outputing a cryptic message: FAIL: True not found in [False], the following will be reported too, if the command output does not meet specified expectations:

Re: [Qemu-devel] [PATCH v2 0/9] add failover feature for assigned network devices

Patchew URL: https://patchew.org/QEMU/20190802150605.5880-1-jfreim...@redhat.com/ Hi, This series seems to have some coding style problems. See output below for more information: Type: series Subject: [Qemu-devel] [PATCH v2 0/9] add failover feature for assigned network devices Message-id:

Re: [Qemu-devel] [PATCH v2 0/9] add failover feature for assigned network devices

On Fri, Aug 02, 2019 at 05:05:56PM +0200, Jens Freimann wrote: > This is implementing the host side of the net_failover concept > (https://www.kernel.org/doc/html/latest/networking/net_failover.html) > > Changes since v1: > - add new QMP events, >- one is send when the primary device is

[Qemu-devel] [PATCH 7/9] migration: Add new migration state wait-unplug

This patch is not ready for inclusion yet, I'm looking for feedback/ideas on a particular problem. See below. This patch adds a new migration state called wait-unplug. It is entered after the SETUP state and will transition into ACTIVE once all devices were succesfully unplugged from the guest.

[Qemu-devel] [PATCH 4/9] migration: allow unplug during migration for failover devices

In "b06424de62 migration: Disable hotplug/unplug during migration" we added a check to disable unplug for all devices until we have figured out what works. For failover primary devices qdev_unplug() is called from the migration handler, i.e. during migration. This patch adds a flag to DeviceState

[Qemu-devel] [PATCH 6/9] qapi: Add failover negotiated event

This event is sent to let libvirt know that VIRTIO_NET_F_STANDBY feature was not negotiated during virtio feature negotiation. If this event is received it means any primary devices hotplugged before this were were never really added to QEMU devices. Signed-off-by: Jens Freimann ---

[Qemu-devel] [PATCH 8/9] pci: mark devices partially unplugged

Only the guest unplug request was triggered. This is needed for the failover feature. In case of a failed migration we need to plug the device back to the guest. Signed-off-by: Jens Freimann --- hw/pci/pci.c | 2 ++ hw/pci/pcie.c| 3 +++ include/hw/pci/pci.h | 1 + 3 files

[Qemu-devel] [PATCH 3/9] vfio: unplug failover primary device before migration

As usual block all vfio-pci devices from being migrated, but make an exception for failover primary devices. This is achieved by setting unmigratable to 0 but also add a migration blocker for all vfio-pci devices except failover primary devices. These will be unplugged before migration happens by

[Qemu-devel] [PATCH 9/9] pci: mark device having guest unplug request pending

Set pending_deleted_event before triggering the unplug request and reset it in the unplug handler when the device is marked as partially hotplugged. This is required to be able to plug it back in in case of a migration failure. Signed-off-by: Jens Freimann --- hw/pci/pcie.c | 3 +++ 1 file

[Qemu-devel] [PATCH 5/9] qapi: add unplug primary event

Add new qmp event to send the device id of a device that was requested to be unplugged by the guest OS. Signed-off-by: Jens Freimann --- qapi/migration.json | 19 +++ 1 file changed, 19 insertions(+) diff --git a/qapi/migration.json b/qapi/migration.json index

[Qemu-devel] [PATCH 2/9] net/virtio: add failover support

This patch adds support to handle failover device pairs of a virtio-net device and a vfio-pci device, where the virtio-net acts as the standby device and the vfio-pci device as the primary. The general idea is that we have a pair of devices, a vfio-pci and a emulated (virtio-net) device. Before

[Qemu-devel] [PATCH v2 0/9] add failover feature for assigned network devices

This is implementing the host side of the net_failover concept (https://www.kernel.org/doc/html/latest/networking/net_failover.html) Changes since v1: - add new QMP events, - one is send when the primary device is unplugged - one is send when VIRTIO_NET_F_STANDBY is not negotiated.

[Qemu-devel] [PATCH 1/9] qdev/qbus: Add hidden device support

This adds support for hiding a device to the qbus and qdev APIs. qdev_device_add() is modified to check for a standby argument in the option string. A DeviceListener callback should_be_hidden() is added. It can be used by a standby device to inform qdev that this device should not be added now.

Re: [Qemu-devel] [PATCH for-4.2 v3 0/2] s390: stop abusing memory_region_allocate_system_memory()

On 02.08.19 16:59, Christian Borntraeger wrote: > > > On 02.08.19 16:42, Christian Borntraeger wrote: >> On 02.08.19 15:32, Igor Mammedov wrote: >>> Changelog: >>> since v2: >>> - break migration from old QEMU (since 2.12-4.1) for guest with >8TB RAM >>> and drop migratable

Re: [Qemu-devel] [PATCH for-4.2 v3 0/2] s390: stop abusing memory_region_allocate_system_memory()

On 02.08.19 16:42, Christian Borntraeger wrote: > On 02.08.19 15:32, Igor Mammedov wrote: >> Changelog: >> since v2: >> - break migration from old QEMU (since 2.12-4.1) for guest with >8TB RAM >> and drop migratable aliases patch as was agreed during v2 review >> - drop 4.2

Re: [Qemu-devel] make vm-build-openbsd (was: Re: [PATCH v2 22/23] tests: Run the iotests during "make check" again)

On 8/2/19 4:28 PM, Gerd Hoffmann wrote: > On Tue, Jul 23, 2019 at 09:20:43AM +0200, Thomas Huth wrote: >> On 22/07/2019 21.53, Philippe Mathieu-Daudé wrote: >> [...] >>> Since Gerd updated the OpenBSD image, do you know if we can run vm-test >>> again? >> >> I just tried it, but the OpenBSD build

Re: [Qemu-devel] [PATCH for-4.2 v3 0/2] s390: stop abusing memory_region_allocate_system_memory()

On 02.08.19 15:32, Igor Mammedov wrote: > Changelog: > since v2: > - break migration from old QEMU (since 2.12-4.1) for guest with >8TB RAM > and drop migratable aliases patch as was agreed during v2 review > - drop 4.2 machines patch as it's not prerequisite anymore > since v1:

Re: [Qemu-devel] [PATCH 22/28] Include hw/boards.h a bit less

Markus Armbruster writes: > Eduardo Habkost writes: > >> On Fri, Jul 26, 2019 at 02:05:36PM +0200, Markus Armbruster wrote: >>> hw/boards.h pulls in almost 60 headers. The less we include it into >>> headers, the better. As a first step, drop superfluous inclusions, >>> and downgrade some

Re: [Qemu-devel] [PATCH] block: Simplify bdrv_filter_default_perms()

On 8/2/19 9:03 AM, Kevin Wolf wrote: > The same change as commit 2b23f28639 ('block/copy-on-read: Fix > permissions for inactive node') made for the copy-on-read driver can be > made for bdrv_filter_default_perms(): Retaining the old permissions from > the BdrvChild if it is given complicates

Re: [Qemu-devel] make vm-build-openbsd (was: Re: [PATCH v2 22/23] tests: Run the iotests during "make check" again)

On Tue, Jul 23, 2019 at 09:20:43AM +0200, Thomas Huth wrote: > On 22/07/2019 21.53, Philippe Mathieu-Daudé wrote: > [...] > > Since Gerd updated the OpenBSD image, do you know if we can run vm-test > > again? > > I just tried it, but the OpenBSD build seems to be completely broken right > now: >

Re: [Qemu-devel] [RFC PATCH v1 22/22] target/i386: reimplement (V)P(EQ, CMP)(B, W, D)

> > > Functions whose address are passed as a callback, as these are, are > always forced out of line. > > OK, Richard. However, on a much higher level than this single patch, I am really curious about this: what would be the rationale beyond the use of callbacks in TCG vector support interface?

Re: [Qemu-devel] [PATCH for-4.2 v3 0/2] s390: stop abusing memory_region_allocate_system_memory()

Patchew URL: https://patchew.org/QEMU/20190802133241.29298-1-imamm...@redhat.com/ Hi, This series failed build test on s390x host. Please find the details below. === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be invoked under the git checkout with # HEAD pointing to a commit

Re: [Qemu-devel] [PATCH] ehci: Ensure that device is not NULL before calling usb_ep_get

On Wed, Jul 31, 2019 at 01:08:50PM +0200, Philippe Mathieu-Daudé wrote: > On 7/30/19 7:45 PM, Guenter Roeck wrote: > > The following assert is seen once in a while while resetting the > > Linux kernel. > > > > qemu-system-x86_64: hw/usb/core.c:734: usb_ep_get: > > Assertion `dev != NULL'

Re: [Qemu-devel] [PULL 0/1] Slirp cve 2019 14378 patches

On Fri, 2 Aug 2019 at 12:18, Marc-André Lureau wrote: > > The following changes since commit 3bd6cbbb181b6ae60a1d1f33ccd325b45f71aa2a: > > Update version for v4.1.0-rc3 release (2019-07-30 22:02:05 +0100) > > are available in the Git repository at: > > https://github.com/elmarco/qemu.git

Re: [Qemu-devel] [PATCH 2/3] iotests: Enable -d for Python non-unittest tests

Am 01.08.2019 um 19:57 hat Max Reitz geschrieben: > On 01.08.19 17:17, Kevin Wolf wrote: > > The part of iotests.main() that is related to the implementation of the > > debug option -d and enables QEMU and QMP logging is not only useful in > > tests that use the Python unittest framework, but also

Re: [Qemu-devel] [PULL 0/2] pci: bugfix

On Tue, 30 Jul 2019 at 20:45, Michael S. Tsirkin wrote: > > The following changes since commit 22235bb609c18547cf6b215bad1f9d2ec56ad371: > > pc-dimm: fix crash when invalid slot number is used (2019-07-29 16:57:27 > -0400) > > are available in the Git repository at: > >

Re: [Qemu-devel] [RFC PATCH v1 22/22] target/i386: reimplement (V)P(EQ, CMP)(B, W, D)

On 7/31/19 5:31 PM, Richard Henderson wrote: > On 7/31/19 1:09 PM, Aleksandar Markovic wrote: >> >> >> On Wed, Jul 31, 2019 at 9:51 PM Richard Henderson >> > > wrote: >> >> On 7/31/19 10:57 AM, Jan Bobek wrote: >> > +static inline void

[Qemu-devel] [PATCH] block: Simplify bdrv_filter_default_perms()

The same change as commit 2b23f28639 ('block/copy-on-read: Fix permissions for inactive node') made for the copy-on-read driver can be made for bdrv_filter_default_perms(): Retaining the old permissions from the BdrvChild if it is given complicates things unnecessary when in the end this only

Re: [Qemu-devel] [RFC PATCH v1 08/22] target/i386: reimplement (V)PAND, (V)ANDPS, (V)ANDPD

On 7/31/19 3:35 PM, Richard Henderson wrote: > On 7/31/19 10:56 AM, Jan Bobek wrote: >> +#define gen_pand_mm(env, s, modrm) gen_gvec_ld_modrm_mm ((env), (s), >> (modrm), MO_64, tcg_gen_gvec_and, 0112) >> +#define gen_pand_xmm(env, s, modrm) gen_gvec_ld_modrm_xmm ((env), (s), >> (modrm),

Re: [Qemu-devel] [PATCH for-4.2 v3 1/2] kvm: s390: split too big memory section on several memslots

On 02.08.19 15:32, Igor Mammedov wrote: > Max memslot size supported by kvm on s390 is 8Tb, > move logic of splitting RAM in chunks upto 8T to KVM code. > > This way it will hide KVM specific restrictions in KVM code > and won't affect baord level design decisions. Which would allow > us to

Re: [Qemu-devel] [PATCH v2 for-4.1 0/2] backup: Copy only dirty areas

On 02.08.19 15:34, Kevin Wolf wrote: > Am 01.08.2019 um 19:38 hat Max Reitz geschrieben: >> Hi, >> >> In a discussion with Vladimir today, we noticed that the backup job >> currently is pretty broken when using copy offloading. I don’t know >> about you, but my local filesystem (XFS) supports

Re: [Qemu-devel] [PATCH for-4.2 v3 2/2] s390: do not call memory_region_allocate_system_memory() multiple times

On 02.08.19 15:41, Christian Borntraeger wrote: > > > On 02.08.19 15:36, David Hildenbrand wrote: >> On 02.08.19 15:32, Igor Mammedov wrote: >>> s390 was trying to solve limited KVM memslot size issue by abusing >>> memory_region_allocate_system_memory(), which breaks API contract >>> where the

Re: [Qemu-devel] [PATCH for-4.2 v3 2/2] s390: do not call memory_region_allocate_system_memory() multiple times

On 02.08.19 15:36, David Hildenbrand wrote: > On 02.08.19 15:32, Igor Mammedov wrote: >> s390 was trying to solve limited KVM memslot size issue by abusing >> memory_region_allocate_system_memory(), which breaks API contract >> where the function might be called only once. >> >> Beside an

Re: [Qemu-devel] [PATCH for-4.2 v3 2/2] s390: do not call memory_region_allocate_system_memory() multiple times

On 02.08.19 15:32, Igor Mammedov wrote: > s390 was trying to solve limited KVM memslot size issue by abusing > memory_region_allocate_system_memory(), which breaks API contract > where the function might be called only once. > > Beside an invalid use of API, the approach also introduced migration

Re: [Qemu-devel] [PATCH v2 for-4.1 0/2] backup: Copy only dirty areas

Am 01.08.2019 um 19:38 hat Max Reitz geschrieben: > Hi, > > In a discussion with Vladimir today, we noticed that the backup job > currently is pretty broken when using copy offloading. I don’t know > about you, but my local filesystem (XFS) supports copy offloading, so > the job uses it

Re: [Qemu-devel] [RFC PATCH v1 06/22] target/i386: introduce gen_gvec_ld_modrm_* helpers

On 7/31/19 6:47 PM, Richard Henderson wrote: > I suppose there aren't so many different combinations, but did you consider > separate callbacks per operand? If you have > > typedef unsigned (*gen_offset)(CPUX86State *, DisasContext *, int); > > static unsigned offset_Pq(CPUX86State *env,

[Qemu-devel] [PATCH for-4.2 v3 2/2] s390: do not call memory_region_allocate_system_memory() multiple times

s390 was trying to solve limited KVM memslot size issue by abusing memory_region_allocate_system_memory(), which breaks API contract where the function might be called only once. Beside an invalid use of API, the approach also introduced migration issue, since RAM chunks for each

[Qemu-devel] [PATCH for-4.2 v3 1/2] kvm: s390: split too big memory section on several memslots

Max memslot size supported by kvm on s390 is 8Tb, move logic of splitting RAM in chunks upto 8T to KVM code. This way it will hide KVM specific restrictions in KVM code and won't affect baord level design decisions. Which would allow us to avoid misusing memory_region_allocate_system_memory() API

[Qemu-devel] [PATCH for-4.2 v3 0/2] s390: stop abusing memory_region_allocate_system_memory()

Changelog: since v2: - break migration from old QEMU (since 2.12-4.1) for guest with >8TB RAM and drop migratable aliases patch as was agreed during v2 review - drop 4.2 machines patch as it's not prerequisite anymore since v1: - include 4.2 machines patch for adding compat

Re: [Qemu-devel] [RFC PATCH v1 05/22] target/i386: introduce gen_ld_modrm_* helpers

On 7/31/19 3:08 PM, Richard Henderson wrote: > On 7/31/19 10:56 AM, Jan Bobek wrote: >> These help with decoding/loading ModR/M vector operands; the operand's >> register offset is returned, which is suitable for use with gvec >> infrastructure. >> >> Signed-off-by: Jan Bobek >> --- >>

  1   2   >