Re: [Qemu-devel] kvm_intel fails to load on Conroe CPUs running Linux 4.12

On 10.11.2017 17:29, Paolo Bonzini wrote: On 10/11/2017 16:33, Gerhard Wiesinger wrote: Hello Paolo, Any update for a new patch? Yes, https://marc.info/?l=kvm=150997149623548=2 Paolo Works also for Fedora 26: https://koji.fedoraproject.org/koji/buildinfo?buildID=996781

Re: [Qemu-devel] [PATCH] linux-user: Support explicit targets for PowerPC

Hi, This series failed build test on s390x host. Please find the details below. Message-id: 492245211.936616.1510023015797.javamail.zim...@xes-inc.com Type: series Subject: [Qemu-devel] [PATCH] linux-user: Support explicit targets for PowerPC === TEST SCRIPT BEGIN === #!/bin/bash # Testing

[Qemu-devel] [PATCH 1/2] tpm_tis: Return TPM_VERSION_UNSPEC in case of BE failure

In case the backend has a failure, such as the tpm_emulator's CMD_INIT failing, the TIS goes into failure mode and does not respond to reads or writes to MMIO registers. In this case we need to prevent the ACPI table from being added and the straight-forward way is to indicate that there's no

[Qemu-devel] [PATCH 2/2] tpm_tis: Return 0 for every register in case of failure mode

Rather than returning ~0, return 0 for every register in case of failure mode. The '0' is better to indicate that there's no device there. Signed-off-by: Stefan Berger --- hw/tpm/tpm_tis.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Qemu-devel] [PATCH 0/2] tpm: Handle failure mode of backend device better

The following two patches fix the case that the backend device, e.g., tpm_emulator, could not be initialized and the TIS frontend needs to go into failure mode. Stefan Stefan Berger (2): tpm_tis: Return TPM_VERSION_UNSPEC in case of BE failure tpm_tis: Return 0 for every register in case

Re: [Qemu-devel] [Qemu-block] [PATCH] block: all I/O should be completed before removing throttle timers.

ok，thanks ！ On 2017/11/10 23:33, Stefan Hajnoczi wrote: On Sat, Oct 21, 2017 at 01:34:00PM +0800, Zhengui Li wrote: From: Zhengui In blk_remove_bs, all I/O should be completed before removing throttle timers. If there has inflight I/O, removing throttle timers here

Re: [Qemu-devel] [PATCH v2] linux-user: fix is_proc_myself to check the paths via realpath

I wrote up a quick example to show that this should work specifically for /proc/self/exe: #define _GNU_SOURCE #include #include #include #include int main(int argc, char** argv) { int fd = open("/proc/self/exe", O_NOFOLLOW | O_PATH); system("ls -la /proc/$PPID/fd/"); } *Zach Riggle*

Re: [Qemu-devel] [PATCH v2] linux-user: fix is_proc_myself to check the paths via realpath

Good catch. Relying on realpath() for *exe* does cause issues. A better general solution (which handles the "exe" case) is to use open(2) with O_PATH | O_NOFOLLOW for the candidate path (e.g. /proc/self/exe) and to do the same for the path we're testing along with readlink(). If, in the process

Re: [Qemu-devel] Yet another git submodule rant

On 11/11/17 01:22, Daniel P. Berrange wrote: > On Sat, Nov 11, 2017 at 12:46:36AM +1100, Alexey Kardashevskiy wrote: >> On 10/11/17 21:41, Daniel P. Berrange wrote: >>> On Fri, Nov 10, 2017 at 09:35:54PM +1100, Alexey Kardashevskiy wrote: On 09/11/17 00:01, Daniel P. Berrange wrote: > On

[Qemu-devel] [Bug 1731588] [NEW] qemu-system-arm black screen and keyboard not detected

Public bug reported: Hi guys, I try to emulate FreeRTOS with this guide : http://wiki.csie.ncku.edu.tw/embedded/Lab32 But, the keys on my keyboard are not taken into account. - Command line : qemu_stm32/arm-softmmu/qemu-system-arm -M stm32-p103 -monitor stdio -kernel build/main.bin

Re: [Qemu-devel] Yet another git submodule rant

On 11/11/17 01:01, Peter Maydell wrote: > On 10 November 2017 at 13:46, Alexey Kardashevskiy wrote: >> And it will still be >> better than changing the $SRC_PATH when a user specifically asked not to do >> that by calling "./configure --source-path='. > > I'm not terribly happy

Re: [Qemu-devel] [PATCH v2 for-2.11] block: Make bdrv_next() keep strong references

On 10/11/2017 18:25, Max Reitz wrote: > if (bs) { > +bdrv_ref(bs); > +bdrv_unref(old_bs); > return bs; > } Maybe instead goto... > it->phase = BDRV_NEXT_MONITOR_OWNED; > +} else { > +old_bs = it->bs; > } > >

[Qemu-devel] UT Austin Virtualization project

Hi all, My name is William Lin. I am an undergrad student at UT Austin and for our virtualization class we have to contribute to a open source repo related to virtualization. I am working in a group of two with about a month of time. We are both comfortable with virtualization concepts and

Re: [Qemu-devel] [PATCH v2] linux-user: fix is_proc_myself to check the paths via realpath

Le 25/10/2017 à 05:34, Zach Riggle a écrit : > Previously, it was possible to get a handle to the "real" /proc/self/mem > by creating a symlink to it and opening the symlink, or opening e.g. > "./mem" after chdir'ing to "/proc/self". > > $ ln -s /proc/self self > $ cat self/maps >

[Qemu-devel] [Bug 1563887] Re: qemu-system-ppc64 freezes on starting image on ppc64le

TL;DR: pass '-vga none' with -nographic, or redirect the screen somewhere! I ended up digging into this after it was mentioned by smoser. The bug is invalid because of a bad assumption in the QEMU inputs. smoser's workaround of usb=off removes USB as a workaround. The kernel, OpenFirmware, and

Re: [Qemu-devel] [PATCH for 2.11 5/5] hw: add .min_cpus and .default_cpus fields to machine_class

On Fri, Nov 10, 2017 at 11:53 AM, Emilio G. Cota wrote: > max_cpus needs to be an upper bound on the number of vCPUs > initialized; otherwise TCG region initialization breaks. > > Some boards initialize a hard-coded number of vCPUs, which is not > captured by the global max_cpus

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/1] Add 8-byte wide AMD flash support, partial interleaving

On 10/11/2017 21:25, Mike Nawrocki wrote: > This patch set does a few things. First, it switches the AMD CFI flash MMIO > operations from the old MMIO API to the new one. Second, it enables 8-byte > wide > flash arrays. Finally, it adds flash interleaving using the "device-width" and >

Re: [Qemu-devel] [PATCH for 2.11 1/5] qom: move CPUClass.tcg_initialize to a global

On Fri, Nov 10, 2017 at 12:23 PM, Eduardo Habkost wrote: > On Fri, Nov 10, 2017 at 02:53:42PM -0500, Emilio G. Cota wrote: >> 55c3cee ("qom: Introduce CPUClass.tcg_initialize", 2017-10-24) >> introduces a per-CPUClass bool that we check so that the target CPU >> is

Re: [Qemu-devel] [PATCH for 2.11 4/5] xlnx-zcu102: Specify the max number of CPUs for the EP108

On Fri, Nov 10, 2017 at 11:53 AM, Emilio G. Cota wrote: > Just like the zcu102, the ep108 can instantiate several CPUs. > > Signed-off-by: Emilio G. Cota I completely missed this, thanks for the patch. Reviewed-by: Alistair Francis

Re: [Qemu-devel] [PATCH v8 02/14] block/dirty-bitmap: add locked version of bdrv_release_dirty_bitmap

On 10/30/2017 12:32 PM, Vladimir Sementsov-Ogievskiy wrote: > It is needed to realize bdrv_dirty_bitmap_release_successor in > the following patch. > OK, but... > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > block/dirty-bitmap.c | 25

[Qemu-devel] [PATCH for-2.12 4/4] blockdev: Mark BD-{remove, insert}-medium stable

Now that iotest 093 test proves that the throttling configuration survives a blockdev-remove-medium/blockdev-insert-medium pair, the original reason for declaring these commands experimental is gone (see commit 6e0abc251dd4f8eba1f53656dfede12e5840e83b). Signed-off-by: Max Reitz

[Qemu-devel] [PATCH for-2.12 1/4] iotests: Make BD-{remove, insert}-medium use @id

In some cases, these commands still use the deprecated @device parameter. Fix that so we can later drop that parameter from their interface. Signed-off-by: Max Reitz --- tests/qemu-iotests/118 | 184 +++-- tests/qemu-iotests/155 |

[Qemu-devel] [PATCH for-2.12 3/4] blockdev: Drop BD-{remove, insert}-medium's @device

This is an incompatible change, which is fine as the commands are experimental. Signed-off-by: Max Reitz --- qapi/block-core.json | 10 ++ blockdev.c | 30 +++--- 2 files changed, 25 insertions(+), 15 deletions(-) diff --git

[Qemu-devel] [PATCH for-2.12 2/4] tests/ahci: Switch tray and medium commands to @id

Currently, the tray and medium commands in the AHCI test use the deprecated @device parameter. This patch switches all invocations over to use @id. Signed-off-by: Max Reitz --- tests/ahci-test.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

[Qemu-devel] [PATCH for-2.12 0/4] blockdev: Mark BD-{remove, insert}-medium stable

Berto's "Test I/O limits with removable media" patch proves that throttling survives a blockdev-remove-medium/blockdev-insert-medium pair now, so let's mark them stable (because that was the reason they were considered experimental, see commit 6e0abc251dd4f8eba1f53656dfede12e5840e83b for more).

Re: [Qemu-devel] [PATCH 2/3] block: Leave valid throttle timers when removing a BDS from a backend

On Fri 10 Nov 2017 11:08:20 PM CET, Max Reitz wrote: >> I just noticed a typo in the commit message: >> >>> There'a a couple of problems with this: >> >> "There's a couple" >> >> If there's no v2 of this series you can correct this when committing. > > Well, the issue is

Re: [Qemu-devel] [PATCH for-2.12 2/3] block: Handle null backing link

On 2017-11-10 23:22, Eric Blake wrote: > On 11/10/2017 04:13 PM, Max Reitz wrote: >> Instead of converting all "backing": null instances into "backing": "", >> handle a null value directly in bdrv_open_inherit(). >> >> This enables explicitly null backing links for json:{} filenames. >> >>

Re: [Qemu-devel] [PATCH for-2.12 2/3] block: Handle null backing link

On 11/10/2017 04:13 PM, Max Reitz wrote: > Instead of converting all "backing": null instances into "backing": "", > handle a null value directly in bdrv_open_inherit(). > > This enables explicitly null backing links for json:{} filenames. > > Signed-off-by: Max Reitz > --- >

Re: [Qemu-devel] [PATCH 3/3] qemu-iotests: Test I/O limits with removable media

On 2017-11-10 19:54, Alberto Garcia wrote: > This test hotplugs a CD drive to a VM and checks that I/O limits can > be set only when the drive has media inserted and that they are kept > when the media is replaced. > > This also tests the removal of a device with valid I/O limits set but > no

Re: [Qemu-devel] [PATCH for-2.12 1/3] qapi: Add qdict_is_null()

On 11/10/2017 04:13 PM, Max Reitz wrote: > Signed-off-by: Max Reitz > --- > include/qapi/qmp/qdict.h | 1 + > qobject/qdict.c | 10 ++ > 2 files changed, 11 insertions(+) > Reviewed-by: Eric Blake -- Eric Blake, Principal Software

Re: [Qemu-devel] [PATCH for-2.12 3/3] block: Deprecate "backing": ""

On 11/10/2017 04:13 PM, Max Reitz wrote: > We have a clear replacement, so let's deprecate it. > > Signed-off-by: Max Reitz > --- > qapi/block-core.json | 4 ++-- > block.c | 4 > qemu-doc.texi| 7 +++ > qemu-options.hx | 4 ++-- > 4 files

Re: [Qemu-devel] [PATCH for-2.11 5/5] qcow2: Refuse to get unaligned offsets from cache

On 2017-11-10 23:15, Eric Blake wrote: > On 11/10/2017 04:00 PM, Max Reitz wrote: >>> Trying to understand this: we have a double corruption, because we >>> encountered a refblock that points outside of the image, but fixing the >>> refblock in turn encounters a second refblock that points within

Re: [Qemu-devel] [PATCH for-2.11 5/5] qcow2: Refuse to get unaligned offsets from cache

On 11/10/2017 04:00 PM, Max Reitz wrote: >> Trying to understand this: we have a double corruption, because we >> encountered a refblock that points outside of the image, but fixing the >> refblock in turn encounters a second refblock that points within the >> image but to an unaligned area. > >

[Qemu-devel] [PATCH for-2.12 2/3] block: Handle null backing link

Instead of converting all "backing": null instances into "backing": "", handle a null value directly in bdrv_open_inherit(). This enables explicitly null backing links for json:{} filenames. Signed-off-by: Max Reitz --- block.c| 2 +- blockdev.c

[Qemu-devel] [PATCH for-2.12 1/3] qapi: Add qdict_is_null()

Signed-off-by: Max Reitz --- include/qapi/qmp/qdict.h | 1 + qobject/qdict.c | 10 ++ 2 files changed, 11 insertions(+) diff --git a/include/qapi/qmp/qdict.h b/include/qapi/qmp/qdict.h index fc218e7be6..c65ebfc748 100644 --- a/include/qapi/qmp/qdict.h +++

[Qemu-devel] [PATCH for-2.12 3/3] block: Deprecate "backing": ""

We have a clear replacement, so let's deprecate it. Signed-off-by: Max Reitz --- qapi/block-core.json | 4 ++-- block.c | 4 qemu-doc.texi| 7 +++ qemu-options.hx | 4 ++-- 4 files changed, 15 insertions(+), 4 deletions(-) diff --git

[Qemu-devel] [PATCH for-2.12 0/3] block: Handle null backing link

Currently, we try to rewrite every occurrence of "backing": null into "backing": "" in qmp_blockdev_add(). However, that breaks using the same "backing": null construction in json:{} file names (which do not go through qmp_blockdev_add()). Currently, these then just behave as if the option has

Re: [Qemu-devel] [PATCH 2/3] block: Leave valid throttle timers when removing a BDS from a backend

On 2017-11-10 23:06, Alberto Garcia wrote: > On Fri 10 Nov 2017 07:54:47 PM CET, Alberto Garcia wrote: > > I just noticed a typo in the commit message: > >> There'a a couple of problems with this: > > "There's a couple" > > If there's no v2 of this series you can correct

Re: [Qemu-devel] [PATCH 2/3] block: Leave valid throttle timers when removing a BDS from a backend

On Fri 10 Nov 2017 07:54:47 PM CET, Alberto Garcia wrote: I just noticed a typo in the commit message: > There'a a couple of problems with this: "There's a couple" If there's no v2 of this series you can correct this when committing. Berto

Re: [Qemu-devel] [PATCH for-2.11 5/5] qcow2: Refuse to get unaligned offsets from cache

On 2017-11-10 22:54, Eric Blake wrote: > On 11/10/2017 02:31 PM, Max Reitz wrote: >> Instead of using an assertion, it is better to emit a corruption event >> here. Checking all offsets for correct alignment can be tedious and it >> is easily possible to forget to do so. qcow2_cache_do_get() is

Re: [Qemu-devel] [PATCH for-2.11 5/5] qcow2: Refuse to get unaligned offsets from cache

On 11/10/2017 02:31 PM, Max Reitz wrote: > Instead of using an assertion, it is better to emit a corruption event > here. Checking all offsets for correct alignment can be tedious and it > is easily possible to forget to do so. qcow2_cache_do_get() is a > function every L2 and refblock access

Re: [Qemu-devel] [PATCH for-2.11 4/5] qcow2: Add bounds check to get_refblock_offset()

On 11/10/2017 02:31 PM, Max Reitz wrote: > Reported-by: R. Nageswara Sastry > Buglink: https://bugs.launchpad.net/qemu/+bug/1728661 > Signed-off-by: Max Reitz > --- > block/qcow2.h | 6 -- > block/qcow2-refcount.c | 26

Re: [Qemu-devel] [PATCH for-2.11 3/5] block: Guard against NULL bs->drv

On 11/10/2017 02:31 PM, Max Reitz wrote: > We currently do not guard everywhere against a NULL bs->drv where we > should be doing so. Most of the places fixed here just do not care > about that case at all. > > Some care implicitly, e.g. through a prior function call to > bdrv_getlength() which

Re: [Qemu-devel] [PATCH v2] linux-user: fix is_proc_myself to check the paths via realpath

Day 17 Ping :) *Zach Riggle* On Tue, Nov 7, 2017 at 2:06 PM, Riku Voipio wrote: > Hi, > > On Mon, Nov 06, 2017 at 08:17:44PM +, Zach Riggle wrote: > > Ping! What needs to be done to move this forward? My current > implementation > > is compatible with musl. > > I'll

Re: [Qemu-devel] [PATCH] iotests: Add test for failing qemu-img commit

On 2017-06-16 15:58, Max Reitz wrote: > Signed-off-by: Max Reitz > --- > In order to pass, this depends on "fix: avoid an infinite loop or a > dangling pointer problem in img_commit" > (http://lists.nongnu.org/archive/html/qemu-block/2017-06/msg00443.html) > and on the "block:

Re: [Qemu-devel] [PATCH for-2.11 2/5] qcow2: Unaligned zero cluster in handle_alloc()

On 11/10/2017 02:31 PM, Max Reitz wrote: > We should check whether the cluster offset we are about to use is > actually valid; that is, whether it is aligned to cluster boundaries. > > Reported-by: R. Nageswara Sastry > Buglink: https://bugs.launchpad.net/qemu/+bug/1728643 >

Re: [Qemu-devel] [PATCH for-2.11 1/5] qcow2: check_errors are fatal

On 11/10/2017 02:31 PM, Max Reitz wrote: > When trying to repair a dirty image, qcow2_check() may apparently > succeed (no really fatal error occurred that would prevent the check > from continuing), but if check_errors in the result object is non-zero, > we cannot trust the image to be usable. >

Re: [Qemu-devel] [PATCH for-2.12 1/1] qcow2: Repair unaligned preallocated zero clusters

On 11/10/2017 02:37 PM, Max Reitz wrote: > We can easily repair unaligned preallocated zero clusters by discarding > them, so why not do it? > > Signed-off-by: Max Reitz > --- > block/qcow2-refcount.c | 70 > ++ >

Re: [Qemu-devel] [PATCH for-2.11 0/5] qcow2: Fixes for corrupted images

On 2017-11-10 21:31, Max Reitz wrote: > This series contains fixes for another batch of qcow2-related crashes > reported on Launchpad by Nageswara (the first batch was > http://lists.nongnu.org/archive/html/qemu-block/2017-11/msg00082.html by > Berto). > > Patch 4 fixes an out-of-bounds array

[Qemu-devel] [PATCH for-2.12 0/1] qcow2: Repair unaligned preallocated zero clusters

This is a follow-up to patch 2 of my "qcow2: Unaligned zero cluster in handle_alloc()" series. That patch adds a way to correctly deal with such clusters, this patch here adds a way to repair them. Naturally, this patch is therefore based on that series: Based-on:

Re: [Qemu-devel] [PATCH] virtio: fix descriptor counting in virtqueue_pop

On Fri, Nov 10, 2017 at 03:41:37PM +, Stefan Hajnoczi wrote: > On Thu, Oct 05, 2017 at 08:03:35PM +0200, Alexandre DERUMIER wrote: > > Hi, > > > > has somebody reviewed this patch ? > > > > I'm also able de reproduce the vm crash like the proxmox user. > > This patch is fixing it for me too.

[Qemu-devel] [PATCH for-2.12 1/1] qcow2: Repair unaligned preallocated zero clusters

We can easily repair unaligned preallocated zero clusters by discarding them, so why not do it? Signed-off-by: Max Reitz --- block/qcow2-refcount.c | 70 ++ tests/qemu-iotests/060 | 3 +- tests/qemu-iotests/060.out | 9

[Qemu-devel] [PATCH for-2.11 3/5] block: Guard against NULL bs->drv

We currently do not guard everywhere against a NULL bs->drv where we should be doing so. Most of the places fixed here just do not care about that case at all. Some care implicitly, e.g. through a prior function call to bdrv_getlength() which would always fail for an ejected BDS. Add an assert

[Qemu-devel] [PATCH v1] migration/ram.c: do not set 'postcopy_running' in POSTCOPY_INCOMING_END

When migrating a VM with 'migrate_set_capability postcopy-ram on' a postcopy_state is set during the process, ending up with the state POSTCOPY_INCOMING_END when the migration is over. This postcopy_state is taken into account inside ram_load to check how it will load the memory pages. This same

Re: [Qemu-devel] [PATCH 3/3] qemu-iotests: Test I/O limits with removable media

On 2017-11-10 19:54, Alberto Garcia wrote: > This test hotplugs a CD drive to a VM and checks that I/O limits can > be set only when the drive has media inserted and that they are kept > when the media is replaced. > > This also tests the removal of a device with valid I/O limits set but > no

Re: [Qemu-devel] [PATCH for 2.11 5/5] hw: add .min_cpus and .default_cpus fields to machine_class

On Fri, Nov 10, 2017 at 02:53:46PM -0500, Emilio G. Cota wrote: > max_cpus needs to be an upper bound on the number of vCPUs > initialized; otherwise TCG region initialization breaks. > > Some boards initialize a hard-coded number of vCPUs, which is not > captured by the global max_cpus and

[Qemu-devel] [PATCH for-2.11 2/5] qcow2: Unaligned zero cluster in handle_alloc()

We should check whether the cluster offset we are about to use is actually valid; that is, whether it is aligned to cluster boundaries. Reported-by: R. Nageswara Sastry Buglink: https://bugs.launchpad.net/qemu/+bug/1728643 Buglink:

[Qemu-devel] [PATCH for-2.11 4/5] qcow2: Add bounds check to get_refblock_offset()

Reported-by: R. Nageswara Sastry Buglink: https://bugs.launchpad.net/qemu/+bug/1728661 Signed-off-by: Max Reitz --- block/qcow2.h | 6 -- block/qcow2-refcount.c | 26 +- tests/qemu-iotests/060 | 46

[Qemu-devel] [PATCH for-2.11 1/5] qcow2: check_errors are fatal

When trying to repair a dirty image, qcow2_check() may apparently succeed (no really fatal error occurred that would prevent the check from continuing), but if check_errors in the result object is non-zero, we cannot trust the image to be usable. Reported-by: R. Nageswara Sastry

[Qemu-devel] [PATCH for-2.11 0/5] qcow2: Fixes for corrupted images

This series contains fixes for another batch of qcow2-related crashes reported on Launchpad by Nageswara (the first batch was http://lists.nongnu.org/archive/html/qemu-block/2017-11/msg00082.html by Berto). Patch 4 fixes an out-of-bounds array access in memory which is not really a security issue

[Qemu-devel] [PATCH for-2.11 5/5] qcow2: Refuse to get unaligned offsets from cache

Instead of using an assertion, it is better to emit a corruption event here. Checking all offsets for correct alignment can be tedious and it is easily possible to forget to do so. qcow2_cache_do_get() is a function every L2 and refblock access has to go through, so this is a good central point

Re: [Qemu-devel] [PATCH 2/3] block: Leave valid throttle timers when removing a BDS from a backend

On 2017-11-10 19:54, Alberto Garcia wrote: > If a BlockBackend has I/O limits set then its ThrottleGroupMember > structure uses the AioContext from its attached BlockDriverState. > Those two contexts must be kept in sync manually. This is not > ideal and will be fixed in the future by removing the

[Qemu-devel] [PATCH v2 1/1] Add 8-byte access, interleaving to AMD CFI devices

This adds 8-byte wide access support to AMD CFI flash devices. Additionally, it migrates the MMIO operations from old_mmio to the new API. Finally, it mirrors the interleaving support already in place in pflash_cfi01.c, using the max_device_width and device_width properties. Signed-off-by: Mike

[Qemu-devel] [PATCH v2 0/1] Add 8-byte wide AMD flash support, partial interleaving

This patch set does a few things. First, it switches the AMD CFI flash MMIO operations from the old MMIO API to the new one. Second, it enables 8-byte wide flash arrays. Finally, it adds flash interleaving using the "device-width" and "max-device-width" properties, using the same interface as

Re: [Qemu-devel] [PATCH for 2.11 1/5] qom: move CPUClass.tcg_initialize to a global

On Fri, Nov 10, 2017 at 02:53:42PM -0500, Emilio G. Cota wrote: > 55c3cee ("qom: Introduce CPUClass.tcg_initialize", 2017-10-24) > introduces a per-CPUClass bool that we check so that the target CPU > is initialized for TCG only once. This works well except when > we end up creating more than one

Re: [Qemu-devel] [PATCH 1/3] block: Check for inserted BlockDriverState in blk_io_limits_disable()

On 2017-11-10 19:54, Alberto Garcia wrote: > When you set I/O limits using block_set_io_throttle or the command > line throttling.* options they are kept in the BlockBackend regardless > of whether a BlockDriverState is attached to the backend or not. > > Therefore when removing the limits using

Re: [Qemu-devel] [PATCH 1/3] ivshmem: Don't update non-existent MSI routes

Thanks Ladi, I had not yet had time to dig into these, this patch set resolves all issues I was aware of. Tested-by: Geoffrey McRae On 2017-11-11 04:34, Ladi Prosek wrote: As of commit 660c97eef6f8 ("ivshmem: use kvm irqfd for msi notifications"), QEMU crashes with:

Re: [Qemu-devel] [PATCH] iotests: test clearing unknown autoclear_features by qcow2

Am 10.11.2017 um 18:54 hat Vladimir Sementsov-Ogievskiy geschrieben: > Test clearing unknown autoclear_features by qcow2 on incoming > migration. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > > Hi all! > > This patch shows degradation, added in 2.10 in

[Qemu-devel] [PATCH for 2.11 3/5] xlnx-zcu102: Add an info message deprecating the EP108

From: Alistair Francis The EP108 was an early access development board that is no longer used. Add an info message to convert any users to the ZCU102 instead. On QEMU they are both identical. This patch also updated the qemu-doc.texi file to indicate that the EP108

[Qemu-devel] [PATCH for 2.11 1/5] qom: move CPUClass.tcg_initialize to a global

55c3cee ("qom: Introduce CPUClass.tcg_initialize", 2017-10-24) introduces a per-CPUClass bool that we check so that the target CPU is initialized for TCG only once. This works well except when we end up creating more than one CPUClass, in which case we end up incorrectly initializing TCG more than

[Qemu-devel] [PATCH for 2.11 4/5] xlnx-zcu102: Specify the max number of CPUs for the EP108

Just like the zcu102, the ep108 can instantiate several CPUs. Signed-off-by: Emilio G. Cota --- hw/arm/xlnx-zcu102.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c index a23..190eb69 100644 --- a/hw/arm/xlnx-zcu102.c +++

[Qemu-devel] [PATCH for 2.11 0/5] TCG/ARM fixes for 2.11

Some MachineClass changes to fix TCG initialization of some ARM boards for 2.11. This was originally reported by Thomas Huth in [1], where Peter suggested a way to fix it. Further discussion in another thread [2] followed up on this. As a result of that follow-up discussion we also got some Zynq

[Qemu-devel] [PATCH for 2.11 5/5] hw: add .min_cpus and .default_cpus fields to machine_class

max_cpus needs to be an upper bound on the number of vCPUs initialized; otherwise TCG region initialization breaks. Some boards initialize a hard-coded number of vCPUs, which is not captured by the global max_cpus and therefore breaks TCG initialization. Fix it by adding the .min_cpus field to

[Qemu-devel] [PATCH for 2.11 2/5] xlnx-zynqmp: Properly support the smp command line option

From: Alistair Francis Allow the -smp command line option to control the number of CPUs we create. Signed-off-by: Alistair Francis Reviewed-by: Eduardo Habkost Reviewed-by: Emilio G. Cota

Re: [Qemu-devel] [PATCH] linux-user, s390x: ignore OS ABI value in ELF header

Hi, This series seems to have some coding style problems. See output below for more information: Subject: [Qemu-devel] [PATCH] linux-user, s390x: ignore OS ABI value in ELF header Type: series Message-id: 20171110194935.17541-1-laur...@vivier.eu === TEST SCRIPT BEGIN === #!/bin/bash BASE=base

[Qemu-devel] [PATCH] linux-user, s390x: ignore OS ABI value in ELF header

I have this error: bash: /sbin/ldconfig: cannot execute binary file: Exec format error because /sbin/ldconfig is: ELF 64-bit MSB executable, IBM S/390, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=90b64604014aafac9c1a0623b1cf447281d1a382, stripped OS ABI is

Re: [Qemu-devel] [PATCH] hw: add .min_cpus and .default_cpus fields to machine_class

On Tue, Nov 07, 2017 at 18:15:45 -0200, Eduardo Habkost wrote: > On Fri, Nov 03, 2017 at 02:47:33PM -0400, Emilio G. Cota wrote: > > @@ -4330,12 +4330,34 @@ int main(int argc, char **argv, char **envp) > > smp_parse(qemu_opts_find(qemu_find_opts("smp-opts"), NULL)); > > > >

Re: [Qemu-devel] [PATCH V4] hw/pci-host: Fix x86 Host Bridges 64bit PCI hole

On 10/11/2017 11:26, Laszlo Ersek wrote: Hi Marcel, On 11/09/17 18:27, Marcel Apfelbaum wrote: Currently there is no MMIO range over 4G reserved for PCI hotplug. Since the 32bit PCI hole depends on the number of cold-plugged PCI devices and other factors, it is very possible is too small to

[Qemu-devel] [PATCH 3/3] qemu-iotests: Test I/O limits with removable media

This test hotplugs a CD drive to a VM and checks that I/O limits can be set only when the drive has media inserted and that they are kept when the media is replaced. This also tests the removal of a device with valid I/O limits set but no media inserted. This involves deleting and disabling the

[Qemu-devel] [PATCH 2/3] block: Leave valid throttle timers when removing a BDS from a backend

If a BlockBackend has I/O limits set then its ThrottleGroupMember structure uses the AioContext from its attached BlockDriverState. Those two contexts must be kept in sync manually. This is not ideal and will be fixed in the future by removing the throttling configuration from the BlockBackend and

[Qemu-devel] [PATCH 1/3] block: Check for inserted BlockDriverState in blk_io_limits_disable()

When you set I/O limits using block_set_io_throttle or the command line throttling.* options they are kept in the BlockBackend regardless of whether a BlockDriverState is attached to the backend or not. Therefore when removing the limits using blk_io_limits_disable() we need to check if there's a

[Qemu-devel] [PATCH 0/3] Fix throttling crashes in BlockBackend with no BlockDriverState

Hi, this series fixes the problems reported by Sochin Jiang in BlockBackend when there's a valid throttling configuration but the BDS has been removed. The patches apply on top of Li Zhengui's "all I/O should be completed before removing throttle timers" and I tested this on top of Stefan's

Re: [Qemu-devel] [PATCH for 2.11 v2 0/2] Xilinx ZCU102 fixes for 2.11

On Thu, Nov 09, 2017 at 13:49:30 -0800, Alistair Francis wrote: > These are two small fixes for 2.11. > > V2: > - Update qemu-doc.texi > > Alistair Francis (2): > xlnx-zynqmp: Properly support the smp command line option > xlnx-zcu102: Add an info message deprecating the EP108 Peter:

Re: [Qemu-devel] [PATCH for 2.11 v2 2/2] xlnx-zcu102: Add an info message deprecating the EP108

On Fri, Nov 10, 2017 at 13:07:22 -0500, Emilio G. Cota wrote: > On Thu, Nov 09, 2017 at 13:49:35 -0800, Alistair Francis wrote: > > The EP108 was an early access development board that is no longer used. > > Add an info message to convert any users to the ZCU102 instead. On QEMU > > they are both

Re: [Qemu-devel] [Qemu-block] [PATCH v2 4/5] iotests: Make 083 less flaky

On 11/10/2017 11:29 AM, Max Reitz wrote: It seems that in this patch you're indenting with spaces but this file uses tabs. >>> >>> Yes, but tabs are wrong. :-) >> >> I actually agree with you, but don't mix them in the file :-) > > I can whistle and say here, too, that Eric liked it.

Re: [Qemu-devel] [PATCH 0/1] qcow2: Check that corrupted images can be repaired in iotest 060

On 2017-11-08 13:13, Alberto Garcia wrote: > Hi, > > I sent the 'Misc qcow2 corruption checks' series the other day, and > Kevin suggested that we check that the corrupted images can be > repaired using qemu-img. > > This patch extends the tests that I wrote in order to do just > that. Since the

Re: [Qemu-devel] [PATCH for 2.11 v2 1/2] xlnx-zynqmp: Properly support the smp command line option

On Thu, Nov 09, 2017 at 13:49:33 -0800, Alistair Francis wrote: > Allow the -smp command line option to control the number of CPUs we > create. > > Signed-off-by: Alistair Francis > Reviewed-by: Eduardo Habkost Reviewed-by: Emilio G. Cota

Re: [Qemu-devel] [PATCH 1/3] ivshmem: Don't update non-existent MSI routes

- Original Message - > As of commit 660c97eef6f8 ("ivshmem: use kvm irqfd for msi notifications"), > QEMU crashes with: > > kvm_irqchip_commit_routes: Assertion `ret == 0' failed. > > if the ivshmem device is configured with more vectors than what the server > supports. This is

Re: [Qemu-devel] [PATCH for 2.11 v2 2/2] xlnx-zcu102: Add an info message deprecating the EP108

On Thu, Nov 09, 2017 at 13:49:35 -0800, Alistair Francis wrote: > The EP108 was an early access development board that is no longer used. > Add an info message to convert any users to the ZCU102 instead. On QEMU > they are both identical. > > This patch also updated the qemu-doc.texi file to

Re: [Qemu-devel] [PATCH v6 0/6] block: Don't compare strings in bdrv_reopen_prepare()

On 2017-11-10 18:47, Kevin Wolf wrote: > Am 10.11.2017 um 18:36 hat Max Reitz geschrieben: >> On 2017-11-10 10:16, Markus Armbruster wrote: >>> Max Reitz writes: >>> bdrv_reopen_prepare() assumes that all BDS options are strings, which is not necessarily correct. This

[Qemu-devel] [PATCH] iotests: test clearing unknown autoclear_features by qcow2

Test clearing unknown autoclear_features by qcow2 on incoming migration. Signed-off-by: Vladimir Sementsov-Ogievskiy --- Hi all! This patch shows degradation, added in 2.10 in commit commit 9c5e6594f15b7364624a3ad40306c396c93a2145 Author: Kevin Wolf

Re: [Qemu-devel] Intermittent hang of iotest 194 (bdrv_drain_all after non-shared storage migration)

On 2017-11-10 03:36, Fam Zheng wrote: > On Thu, 11/09 20:31, Max Reitz wrote: >> On 2017-11-09 16:30, Fam Zheng wrote: >>> On Thu, 11/09 16:14, Max Reitz wrote: [...] *sigh* OK, I'll look into it... >>> >>> OK, I'll let you.. Just one more thing: could it relate to the >>>

Re: [Qemu-devel] [PATCH v6 0/6] block: Don't compare strings in bdrv_reopen_prepare()

Am 10.11.2017 um 18:36 hat Max Reitz geschrieben: > On 2017-11-10 10:16, Markus Armbruster wrote: > > Max Reitz writes: > > > >> bdrv_reopen_prepare() assumes that all BDS options are strings, which is > >> not necessarily correct. This series introduces a new

Re: [Qemu-devel] [PATCH v6 0/6] block: Don't compare strings in bdrv_reopen_prepare()

On 2017-11-10 10:16, Markus Armbruster wrote: > Max Reitz writes: > >> bdrv_reopen_prepare() assumes that all BDS options are strings, which is >> not necessarily correct. This series introduces a new qobject_is_equal() >> function which can be used to test whether any options

Re: [Qemu-devel] [U-Boot] Support of latest qemux86-64

Hooray, changing SYS_CAR_ADDR to 0x1 in arch/x86/cpu/qemu/Kconfig does the trick. Bin, what do you think about it? Best regards, Anton Gerasimov On 11/10/2017 06:25 PM, Anton Gerasimov wrote: > Yes, apparently 0xdfffc is in ROM area for QEMU (0xc -- 0xe, > defined in

[Qemu-devel] [PATCH 2/3] ivshmem: Always remove irqfd notifiers

As of commit 660c97eef6f8 ("ivshmem: use kvm irqfd for msi notifications"), QEMU crashes with: ivshmem: msix_set_vector_notifiers failed msix_unset_vector_notifiers: Assertion `dev->msix_vector_use_notifier && dev->msix_vector_release_notifier' failed. if MSI-X is repeatedly enabled and

[Qemu-devel] [PATCH 3/3] ivshmem: Improve MSI irqfd error handling

Adds a rollback path to ivshmem_enable_irqfd() and fixes ivshmem_disable_irqfd() to bail if irqfd has not been enabled. Signed-off-by: Ladi Prosek --- hw/misc/ivshmem.c | 37 - 1 file changed, 24 insertions(+), 13 deletions(-) diff --git

[Qemu-devel] [PATCH 0/3] ivshmem: MSI bug fixes

Fixes bugs in the ivshmem device implementation uncovered with the new Windows ivshmem driver: https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/ivshmem Ladi Prosek (3): ivshmem: Don't update non-existent MSI routes ivshmem: Always remove irqfd notifiers ivshmem: Improve

[Qemu-devel] [PATCH 1/3] ivshmem: Don't update non-existent MSI routes

As of commit 660c97eef6f8 ("ivshmem: use kvm irqfd for msi notifications"), QEMU crashes with: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. if the ivshmem device is configured with more vectors than what the server supports. This is caused by the ivshmem_vector_unmask() being called

Re: [Qemu-devel] [Qemu-block] [PATCH v2 4/5] iotests: Make 083 less flaky

On 2017-11-10 16:51, Alberto Garcia wrote: > On Fri 10 Nov 2017 04:18:15 PM CET, Max Reitz wrote: >> On 2017-11-10 11:02, Alberto Garcia wrote: >>> On Thu 09 Nov 2017 09:30:24 PM CET, Max Reitz wrote: +echo > "$TEST_DIR/nbd-fault-injector.out" $PYTHON nbd-fault-injector.py

  1   2   3   >