Re: [Qemu-devel] Different type of qcow2_get_cluster_type

> > > Both values correspond to L2 entries with bit 0 set. However, > QCOW2_CLUSTER_ZERO_ALLOC is an entry that has a non-zero value in bits 9-55 > (the cluster has an allocated host location, we guarantee that things read > as zero regardless of whether the host data actually contains zeroes at

[Qemu-devel] [PATCH] hvf: drop unused variable

Signed-off-by: Paolo Bonzini --- target/i386/hvf/hvf.c | 1 - 1 file changed, 1 deletion(-) diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c index 5db167df98..9f52bc413a 100644 --- a/target/i386/hvf/hvf.c +++ b/target/i386/hvf/hvf.c @@ -72,7 +72,6 @@ #include "sysemu/sysemu.h"

[Qemu-devel] [PATCH] MAINTAINERS: add myself as elf2dmp maintainer

Add myself as contrib/elf2dmp maintainer and elf2dmp as maintained. Signed-off-by: Viktor Prutyanov --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d12518c08f..e70ff1e009 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1888,6 +1888,11 @@

Re: [Qemu-devel] [PATCH 0/3] aio-posix: polling mode bug fixes

On Wed, 09/12 19:10, Paolo Bonzini wrote: > Patch 1 fixes a too-strict assertion that could fire when aio_poll > is called in parallel with aio_set_fd_handler. > > Patch 2 and 3 reinstate the performance benefits of polling, which were > essentially disabled by commit 70232b5253 ("aio-posix:

Re: [Qemu-devel] [PATCH v4 0/8] discard blockstats

ping do you think we might proceed with this? or is there any general doubt about the idea? thanks, On 21/8/2018 12:46 PM, Anton Nefedov wrote: new in v4: - patch 7: discard and write-zeroes code paths had been separated in 34fa110e: file-posix: Fix write_zeroes with unmap on

Re: [Qemu-devel] [PATCH v2] clean up callback when del virtqueue

On 2018年09月17日 21:48, liujunjie wrote: Before, we did not clear callback like handle_output when delete the virtqueue which may result be segmentfault. The scene is as follows: 1. Start a vm with multiqueue vhost-net, 2. then we write VIRTIO_PCI_GUEST_FEATURES in PCI configuration to triger

Re: [Qemu-devel] [PATCH] hvf: drop unused variable

On 2018-09-18 11:28, Paolo Bonzini wrote: > Signed-off-by: Paolo Bonzini > --- > target/i386/hvf/hvf.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c > index 5db167df98..9f52bc413a 100644 > --- a/target/i386/hvf/hvf.c > +++

Re: [Qemu-devel] [PATCH V12-fix-V2 01/19] filter-rewriter: Add TCP state machine and fix memory leak in connection_track_table

On 2018年09月14日 09:47, Zhang Chen wrote: We add almost full TCP state machine in filter-rewriter, except TCPS_LISTEN and some simplify in VM active close FIN states. The reason for this simplify job is because guest kernel will track the TCP status and wait 2MSL time too, if client resend the

[Qemu-devel] [PATCH 1/1] qmp, hmp: add PCI subsystem id and vendor id to PCI info

This is a long story. RedHat has relicensed Windows KVM device drivers in 2018 and there was an agreement that to avoid WHQL driver conflict software manufacturers should set proper PCI subsystem vendor ID in their distributions. Thus PCI subsystem vendor id becomes actively used. The problem is

Re: [Qemu-devel] [PATCH v2] vhost-user-blk: start vhost when guest kicks

Kindly ping... On Thu, 7 Jun 2018 at 20:50, Stefan Hajnoczi wrote: > > On Wed, Jun 06, 2018 at 09:24:48PM +0800, Yongji Xie wrote: > > Some old guests (before commit 7a11370e5: "virtio_blk: enable VQs early") > > kick virtqueue before setting VIRTIO_CONFIG_S_DRIVER_OK. This violates > > the

Re: [Qemu-devel] [PATCH] qom/object: add some interface asserts

On 12/09/2018 14:53, Marc-André Lureau wrote: > An interface can't have any instance size or callback, or itself > implement other interfaces (this is unsupported). > > Signed-off-by: Marc-André Lureau > --- > qom/object.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > >

Re: [Qemu-devel] [PATCH v5 3/3] target/s390x: implement CVB, CVBY and CVBG

Am 02.09.18 um 02:33 schrieb Pavel Zbitskiy: > Convert to Binary - counterparts of the already implemented Convert > to Decimal (CVD*) instructions. > Example from the Principles of Operation: 25594C becomes 63FA. > > Signed-off-by: Pavel Zbitskiy > --- > target/s390x/helper.h | 1 +

Re: [Qemu-devel] [PATCH 00/35] exec: drop BQL from interrupt handling

Am 17.09.18 um 18:30 schrieb Emilio G. Cota: > This series comes originally from a series of patches that Paolo > sent to me a long time ago. I have kept most of his S-o-b tags, > but I have done the forward port of the patches to the current > QEMU code base, so please blame all possible bugs on

Re: [Qemu-devel] [RFC v5 1/6] pci_expander_bridge: add type TYPE_PXB_PCIE_HOST

Gerd Hoffmann 于2018年9月18日周二 下午1:09写道： > > Hi, > > > +static void pxb_pcie_host_get_mmcfg_base(Object *obj, Visitor *v, const > > char *name, > > > +void *opaque, Error **errp) > > +{ > > +PCIExpressHost *e =

Re: [Qemu-devel] [PATCH 23/35] target/s390x: access cpu->interrupt_request with atomics

Am 17.09.18 um 18:30 schrieb Emilio G. Cota: > From: Paolo Bonzini > > Cc: Cornelia Huck > Cc: Christian Borntraeger > Cc: Alexander Graf > Cc: Richard Henderson > Cc: David Hildenbrand > Cc: qemu-s3...@nongnu.org > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio G. Cota > --- >

Re: [Qemu-devel] [PATCH 0/5] contrib: add elf2dmp tool

On 18/09/2018 07:44, Viktor Prutyanov wrote: > On Fri, 14 Sep 2018 17:22:14 +0200 > Paolo Bonzini wrote: > >> On 29/08/2018 14:41, Viktor Prutyanov wrote: >>> elf2dmp is a converter from ELF dump (produced by >>> 'dump-guest-memory') to Windows MEMORY.DMP format (also know as >>> 'Complete

[Qemu-devel] qemu-nbd performance

I test nbd performance when I divide image into multiple backing files. The image is 512GB, I divide it into 1, 16, 32, 64, and 128 backing files. Ex: If I divide it into 16 files, each backing file is 512/16=32GB. If I divide it into 64 files, each backing file is 512/64=8GB and so on. *Mount

Re: [Qemu-devel] [PATCH 05/35] target/s390x: use cpu_reset_interrupt

Am 17.09.18 um 18:30 schrieb Emilio G. Cota: > From: Paolo Bonzini > > It will be changed to an atomic operation soon. > > Cc: Cornelia Huck > Cc: Richard Henderson > Cc: Alexander Graf > Cc: David Hildenbrand > Cc: qemu-s3...@nongnu.org > Signed-off-by: Paolo Bonzini > Signed-off-by:

Re: [Qemu-devel] [PATCH 35/35] exec: push BQL down to cpu->cpu_exec_interrupt

> return false; > diff --git a/target/s390x/excp_helper.c b/target/s390x/excp_helper.c > index 931c0103c8..f2a93abf01 100644 > --- a/target/s390x/excp_helper.c > +++ b/target/s390x/excp_helper.c > @@ -480,10 +480,13 @@ bool s390_cpu_exec_interrupt(CPUState *cs, int > interrupt_request) >

Re: [Qemu-devel] [PATCH v5 2/3] target/s390x: exception on non-aligned LPSW(E)

Am 02.09.18 um 02:33 schrieb Pavel Zbitskiy: > Both LPSW and LPSWE should raise a specification exception when their > operand is not doubleword aligned. > > Signed-off-by: Pavel Zbitskiy > --- > target/s390x/translate.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff

Re: [Qemu-devel] [PATCH] accel/tcg: Remove dead code

On 17/09/2018 19:08, Thomas Huth wrote: > The global cpu_single_env variable has been removed more than 5 years > ago, so apparently nobody used this dead debug code in that timeframe > anymore. Thus let's remove it completely now. > > Signed-off-by: Thomas Huth > --- >

[Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero

Not yet. There should be a fix before 3.1 is released. Both 2.12 and 3.0 have this bug, so you might want to consider using 2.11 until the bug gets fixed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

Re: [Qemu-devel] [PATCH 04/11] hw/arm/aspeed: add a 'mmio-exec' property to boot from the FMC flash module

On 31 August 2018 at 11:38, Cédric Le Goater wrote: > Now that MMIO execution is supported, introduce a 'mmio-exec' property > to boot directly from CE0 of the FMC controller using a memory region > alias. The name of this property seems to be a reference to QEMU's internals: is there some other

Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64

On Tue, Sep 18, 2018 at 16:55:56 +0100, Peter Maydell wrote: > On 11 September 2018 at 21:43, Emilio G. Cota wrote: > > On Tue, Sep 11, 2018 at 05:43:38 -0700, Richard Henderson wrote: > >> Is this any better than using libatomic? > > > > I didn't think of using libatomic. I just checked the

Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64

On Tue, Sep 18, 2018 at 10:23:32 -0300, Murilo Opsfelder Araujo wrote: > On Tue, Sep 11, 2018 at 04:43:04PM -0400, Emilio G. Cota wrote: > > On Tue, Sep 11, 2018 at 05:43:38 -0700, Richard Henderson wrote: > > > On 09/10/2018 04:27 PM, Emilio G. Cota wrote: > > > > +#define GEN_READ(name, type)

Re: [Qemu-devel] [PATCH 07/11] aspeed/smc: add a 'sdram_base' and 'max-ram-size' properties

On 31 August 2018 at 11:38, Cédric Le Goater wrote: > The setting of the DRAM address of the DMA transaction depends on the > DRAM base address and the maximun DRAM size of the SoC. Let's add a > couple of properties to give this information to the SMC controller > model. In hardware, does the

[Qemu-devel] [PATCH v9 1/3] qmp: query-current-machine with wakeup-suspend-support

When issuing the qmp/hmp 'system_wakeup' command, what happens in a nutshell is: - qmp_system_wakeup_request set runstate to RUNNING, sets a wakeup_reason and notify the event - in the main_loop, all vcpus are paused, a system reset is issued, all subscribers of wakeup_notifiers receives a

Re: [Qemu-devel] [PATCH 09/11] aspeed/smc: add DMA calibration settings

On 31 August 2018 at 11:38, Cédric Le Goater wrote: > When doing calibration, the SPI clock rate in the CE0 Control Register > and the read delay cycles in the Read Timing Compensation Register are > replaced by bit[11:4] of the DMA Control Register. > > Signed-off-by: Cédric Le Goater > --- >

[Qemu-devel] [PATCH v9 0/3] wakeup-from-suspend and system_wakeup changes

changes in v9, all proposed by Mike Roth: - added a new 'qemu_register_wakeup_support' to be called by the wake-up implementations to register the support in vl.c (patch 1) - changed versions from 3.0.0 to 3.1.0 (patch 1) - added back the 'qemu_system_wakeup_request' call that was removed by

[Qemu-devel] [PATCH v9 3/3] qmp hmp: Make system_wakeup check wake-up support and run state

The qmp/hmp command 'system_wakeup' is simply a direct call to 'qemu_system_wakeup_request' from vl.c. This function verifies if runstate is SUSPENDED and if the wake up reason is valid before proceeding. However, no error or warning is thrown if any of those pre-requirements isn't met. There is

[Qemu-devel] [PATCH v9 2/3] qga: update guest-suspend-ram and guest-suspend-hybrid descriptions

This patch updates the descriptions of 'guest-suspend-ram' and 'guest-suspend-hybrid' to mention that both commands relies now on the proper support for wake up from suspend, retrieved by the 'wakeup-suspend-support' attribute of the 'query-current-machine' QMP command. Reported-by: Balamuruhan S

Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64

On 18 September 2018 at 19:42, Emilio G. Cota wrote: > We already have these. For instance: > > - sTLB lookups can happen concurrently with invalidations > to the same sTLB from another core (via tlb_reset_dirty) > > - icount_decr is written to by cpu_exit, and is read > at the beginning of

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

We also only get those reports from users with 4G RAM configured, so it could also have to do with overflow. On Tue, Sep 18, 2018 at 11:57 AM Frank Yang wrote: > That seems to be the case, since our 15 second detector is reset if the > main loop runs its timers again, so no main loop iterations

Re: [Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero

On 18 September 2018 at 19:18, Emilio G. Cota <1793...@bugs.launchpad.net> wrote: > Not yet. There should be a fix before 3.1 is released. > > Both 2.12 and 3.0 have this bug, so you might want to consider using > 2.11 until the bug gets fixed. On the other hand 2.11 has a different set of

Re: [Qemu-devel] [PATCH v4 5/8] target/mips: R5900 DMULT[U], DDIV[U], LL, SC, LLD and SCD are user only

Hi Fredrik, > I agree, that is important too. I will post an updated v5 soon. Another > alternative change is to define check_insn_opc_user_only as > > static inline void check_insn_opc_user_only(DisasContext *ctx, int flags) > { > #ifndef CONFIG_USER_ONLY > check_insn_opc_removed(ctx,

Re: [Qemu-devel] [PATCH 03/11] hw/arm/aspeed: Add an Aspeed machine class

On 31 August 2018 at 11:38, Cédric Le Goater wrote: > The code looks better, it removes duplicated lines and it will ease > the introduction of common properties for the Aspeed machines. > > Signed-off-by: Cédric Le Goater > --- > include/hw/arm/aspeed.h | 46 + > hw/arm/aspeed.c

Re: [Qemu-devel] [PATCH 08/11] aspeed/smc: add support for DMAs

On 31 August 2018 at 11:38, Cédric Le Goater wrote: > The FMC controller on the Aspeed SoCs support DMA to access the flash > modules. It can operate in a normal mode, to copy to or from the flash > module mapping window, or in a checksum calculation mode, to evaluate > the best clock settings

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

That seems to be the case, since our 15 second detector is reset if the main loop runs its timers again, so no main loop iterations happened since that aio_dispatch_handlers call (we use a looper abstraction for it). On Tue, Sep 18, 2018 at 8:56 AM Paolo Bonzini wrote: > On 15/09/2018 20:41,

Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64

On 9/18/18 12:04 PM, Peter Maydell wrote: > Does libatomic give us a firm guarantee that for 32-bit > types it will definitely produce an inline atomic access > insn that will interwork with what we're using? At the > moment our guard against this going wrong is that we don't > link against

[Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero

Neither will be sufficient in my use case. IEEE-754 conformance is essential. Thank you for the hints. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1793119 Title: Wrong floating-point emulation

Re: [Qemu-devel] [PATCH v3] hw/arm: Add arm SBSA reference machine

On 9 September 2018 at 03:23, Hongbo Zhang wrote: > For the Aarch64, there is one machine 'virt', it is primarily meant to > run on KVM and execute virtualization workloads, but we need an > environment as faithful as possible to physical hardware, for supporting > firmware and OS development for

Re: [Qemu-devel] [PATCH v3] hw/arm: Add arm SBSA reference machine

On 18 September 2018 at 12:44, Peter Maydell wrote: > On 9 September 2018 at 03:23, Hongbo Zhang wrote: >> +#include "hw/arm/primecell.h" >> +#include "hw/arm/virt.h"Please remove all the code you don't need, rather >> than > just copin Oops, please ignore this line, it is stray editor junk

[Qemu-devel] [Bug 1793183] [NEW] apt source --compile qemu-system-x86 fails on last ubuntu 18.04.1

Public bug reported: Error log: /tmp/qemu-2.10+dfsg/util/memfd.c:40:12: error: static declaration of ‘memfd_create’ follows non-static declaration static int memfd_create(const char *name, unsigned int flags) ^~~~ In file included from

[Qemu-devel] [Bug 1793183] Re: apt source --compile qemu-system-x86 fails on last ubuntu 18.04.1

** Patch added: "fix-memfd-conflict.patch" https://bugs.launchpad.net/qemu/+bug/1793183/+attachment/5190282/+files/fix-memfd-conflict.patch -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1793183

[Qemu-devel] [Bug 1793183] Re: apt source --compile qemu-system-x86 fails on last ubuntu 18.04.1

** Project changed: qemu => ubuntu ** Package changed: ubuntu => qemu (Ubuntu) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1793183 Title: apt source --compile qemu-system-x86 fails on last

[Qemu-devel] [PATCH v9 9/9] qcow2: Explicit number replaced by a constant

Signed-off-by: Leonid Bloch Reviewed-by: Alberto Garcia --- block/qcow2.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/qcow2.c b/block/qcow2.c index f885afa0ed..ffb4a9e4a1 100644 --- a/block/qcow2.c +++ b/block/qcow2.c @@ -1324,7 +1324,7 @@ static int

[Qemu-devel] [PATCH v9 1/9] qcow2: Options' documentation fixes

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

[Qemu-devel] [PATCH v9 3/9] qcow2: Make sizes more humanly readable

Signed-off-by: Leonid Bloch Reviewed-by: Alberto Garcia --- block/qcow2.c | 2 +- block/qcow2.h | 9 + 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/block/qcow2.c b/block/qcow2.c index ec9e6238a0..67cc82f0b9 100644 --- a/block/qcow2.c +++ b/block/qcow2.c @@ -830,7

[Qemu-devel] [PATCH v9 5/9] qcow2: Assign the L2 cache relatively to the image size

Sufficient L2 cache can noticeably improve the performance when using large images with frequent I/O. Previously, unless 'cache-size' was specified and was large enough, the L2 cache was set to a certain size without taking the virtual image size into account. Now, the L2 cache assignment is

Re: [Qemu-devel] [PATCH] fix setting the FPSCR[FR] bit

On 18 September 2018 at 15:34, Programmingkid wrote: > On Sep 17, 2018, at 7:46 PM, Peter Maydell wrote: >> See my previous email -- the spec suggests that "round" is >> "inexact but not overflow". > > I couldn't find anything in my pdf document about round being defined as > inexact but not

[Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero

Thanks for your report. This is a known regression on our implementation of f64_div, introduced by cf07323d49 ("fpu/softfloat: re-factor div", 2018-02-21). We are working on improving FP tests to limit regressions, e.g. see this thread, where the bug you report is first mentioned:

[Qemu-devel] [PATCH v9 0/9] Take the image size into account when allocating the L2 cache

Sorry for taking such a long pause after v8. I had several extremely urgent issues to attend to. This series makes the qcow2 L2 cache assignment aware of the image size, with the intention for it to cover the entire image. The importance of this change is in noticeable performance improvement,

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

And this one: https://github.com/qemu/qemu/commit/a411c84b561baa94b28165c52f21c33517ee8f59 On Sat, Sep 15, 2018 at 4:42 PM Frank Yang wrote: > I notice at least two commits in upstream QEMU that might impact this: > > >

[Qemu-devel] [PATCH v9 7/9] qcow2: Resize the cache upon image resizing

The caches are now recalculated upon image resizing. This is done because the new default behavior of assigning L2 cache relatively to the image size, implies that the cache will be adapted accordingly after an image resize. Signed-off-by: Leonid Bloch Reviewed-by: Alberto Garcia ---

[Qemu-devel] [PATCH v9 6/9] qcow2: Increase the default upper limit on the L2 cache size

The upper limit on the L2 cache size is increased from 1 MB to 32 MB on Linux platforms, and to 8 MB on other platforms (this difference is caused by the ability to set intervals for cache cleaning on Linux platforms only). This is done in order to allow default full coverage with the L2 cache

[Qemu-devel] [PATCH v9 8/9] qcow2: Set the default cache-clean-interval to 10 minutes

The default cache-clean-interval is set to 10 minutes, in order to lower the overhead of the qcow2 caches (before the default was 0, i.e. disabled). Signed-off-by: Leonid Bloch Reviewed-by: Alberto Garcia --- block/qcow2.c| 2 +- block/qcow2.h| 1 + docs/qcow2-cache.txt | 4

Re: [Qemu-devel] [PATCH v3] linux-user: do setrlimit selectively

Le 17/09/2018 à 20:13, Max Filippov a écrit : > setrlimit guest calls that affect memory resources > (RLIMIT_{AS,DATA,STACK}) may interfere with QEMU internal memory > management. They may result in QEMU lockup because mprotect call in > page_unprotect would fail with ENOMEM error code, causing

[Qemu-devel] [PATCH v9 2/9] include: Add a lookup table of sizes

Adding a lookup table for the powers of two, with the appropriate size prefixes. This is needed when a size has to be stringified, in which case something like '(1 * KiB)' would become a literal '(1 * (1L << 10))' string. Powers of two are used very often for sizes, so such a table will also make

[Qemu-devel] [PATCH v9 4/9] qcow2: Avoid duplication in setting the refcount cache size

The refcount cache size does not need to be set to its minimum value in read_cache_sizes(), as it is set to at least its minimum value in qcow2_update_options_prepare(). Signed-off-by: Leonid Bloch Reviewed-by: Alberto Garcia --- block/qcow2.c | 5 ++--- 1 file changed, 2 insertions(+), 3

Re: [Qemu-devel] [PATCH v10 6/6] tpm: add ACPI memory clear interface

Hi On Tue, Sep 11, 2018 at 6:19 PM Laszlo Ersek wrote: > > +Alex, due to mention of 21e00fa55f3fd > > On 09/10/18 15:03, Marc-André Lureau wrote: > > Hi > > > > On Mon, Sep 10, 2018 at 2:44 PM Dr. David Alan Gilbert > > wrote: > >> (I didn't know about guest_phys_block* and would have probably

Re: [Qemu-devel] [PATCH v10 6/6] tpm: add ACPI memory clear interface

* Marc-André Lureau (marcandre.lur...@gmail.com) wrote: > Hi > > On Tue, Sep 11, 2018 at 6:19 PM Laszlo Ersek wrote: > > > > +Alex, due to mention of 21e00fa55f3fd > > > > On 09/10/18 15:03, Marc-André Lureau wrote: > > > Hi > > > > > > On Mon, Sep 10, 2018 at 2:44 PM Dr. David Alan Gilbert > >

Re: [Qemu-devel] [PATCH 1/1] qmp, hmp: add PCI subsystem id and vendor id to PCI info

On 9/18/18 4:58 AM, Denis V. Lunev wrote: This is a long story. RedHat has relicensed Windows KVM device drivers s/RedHat/Red Hat/ in 2018 and there was an agreement that to avoid WHQL driver conflict software manufacturers should set proper PCI subsystem vendor ID in their distributions.

Re: [Qemu-devel] [PATCH v2 02/12] util: add atomic64

On 11 September 2018 at 21:43, Emilio G. Cota wrote: > On Tue, Sep 11, 2018 at 05:43:38 -0700, Richard Henderson wrote: >> Is this any better than using libatomic? > > I didn't think of using libatomic. I just checked the source > code and it's quite similar: > - It uses 64 locks instead of 16

[Qemu-devel] qemu 2.12: qemu_coroutine_switch crash on Windows in SwitchToFiber (null CoroutineWin32*?)

Hi qemu-devel, We've been having crash reports in QEMU 2.12 on the anroid emulator in SwitchToFiber that make it look like the coroutine or fiber getting switched to is null. Thread 16 (id: 0x13bc) CRASHED [EXCEPTION_ACCESS_VIOLATION_READ @ 0x0010 ] Stack Quality84%Show frame trust levels

Re: [Qemu-devel] qemu 2.12: qemu_coroutine_switch crash on Windows in SwitchToFiber (null CoroutineWin32*?)

BTW from https://bugs.launchpad.net/qemu/+bug/932487 that says gcc version is to blame, I don't think that's the case; we are using gcc 4.8 as well. Perhaps it regressed. It would be

Re: [Qemu-devel] [PATCH v2 12/17] mirror: Fix potential use-after-free in active commit

Am 18.09.2018 um 16:11 hat Max Reitz geschrieben: > On 17.09.18 13:37, Kevin Wolf wrote: > > Am 17.09.2018 um 00:05 hat Max Reitz geschrieben: > >> On 14.09.18 18:25, Kevin Wolf wrote: > >>> Am 13.09.2018 um 22:55 hat Max Reitz geschrieben: > On 13.09.18 14:52, Kevin Wolf wrote: > > When

Re: [Qemu-devel] Dropped CPU feature names and backward compatibility

On 18/09/2018 16:22, Eduardo Habkost wrote: > On Tue, Sep 18, 2018 at 04:02:54PM +0200, Paolo Bonzini wrote: >> On 18/09/2018 15:14, Eduardo Habkost wrote: >>> If it broke something, we should restore the option names and >>> declare them as deprecated. >> >> I think in this particular case it's

Re: [Qemu-devel] Freeze / spin in virtio blk...flatview do translate

On 15/09/2018 20:41, Frank Yang via Qemu-devel wrote: > We have not reproduced this hang so far, this is from user crash reports > that triggered our hang detector (where 15+ seconds pass without main loop > / VCPU threads being able to go back and ping their loopers in main loop / > vcpu threads.

Re: [Qemu-devel] [qemu-s390x] [PATCH v8 3/6] s390x/kvm: enable/disable AP instruction interpretation for guest

On 09/17/2018 04:43 AM, David Hildenbrand wrote: Am 12.09.18 um 22:08 schrieb Tony Krowiak: From: Tony Krowiak Let's use the KVM_SET_DEVICE_ATTR ioctl to enable or disable hardware interpretation of AP instructions executed on the guest. If the S390_FEAT_AP feature is installed, AP

[Qemu-devel] [Bug 1793119] Re: Wrong floating-point emulation on AArch64 with FPCR set to zero

Thanks for the update. Is there a fix/patch for the issue? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1793119 Title: Wrong floating-point emulation on AArch64 with FPCR set to zero Status in

Re: [Qemu-devel] [PATCH v4 5/8] target/mips: R5900 DMULT[U], DDIV[U], LL, SC, LLD and SCD are user only

Hi Maciej, Philippe -- thank you for your reviews, On Mon, Sep 17, 2018 at 06:10:27PM +0100, Maciej W. Rozycki wrote: > Nitpicking here, but I think it's what makes code clean and pleasant to > read. I agree, that is important too. I will post an updated v5 soon. Another alternative change is

Re: [Qemu-devel] [PATCH] tests/migration: Speed up the test on ppc64

On 17/09/2018 19:12, Thomas Huth wrote: > The SLOF boot process is always quite slow ... but we can speed it up > a little bit by specifying "-nodefaults" and by using the "nvramrc" > variable instead of "boot-command" (since "nvramrc" is evaluated earlier > in the SLOF boot process than

[Qemu-devel] [PATCH 00/10] target/xtensa updates

repository at: git://github.com/OSLL/qemu-xtensa.git tags/20180918-xtensa for you to fetch changes up to 5aa37f488fa22c07495edbc04aa63812fbcdb79c: target/xtensa: support input from chardev console (2018-09-17 11:09:04 -0700) target

Re: [Qemu-devel] [PATCH v2 5/8] x86_iommu/amd: Add interrupt remap support when VAPIC is not enabled

On 09/17/2018 10:53 PM, Peter Xu wrote: [...] >> IMHO we should not be using error_report_once() here. It's possible that >> guest OS have DTE[IV]=1 but has not programmed the interrupt >> remapping entries or have deactivated the remapping. I see that Linux >> OS does it all the time and in

Re: [Qemu-devel] [PATCH v2 5/8] x86_iommu/amd: Add interrupt remap support when VAPIC is not enabled

Small correction On 09/18/2018 03:27 PM, Singh, Brijesh wrote:> > So far non of the guests were enabling the interrupt remap features > even when it was available. As I explained in previous patches (see > patch 6), Linux guest looks for a special IOAPIC device in IVHD before > enabling the

Re: [Qemu-devel] [PATCH 01/35] tcg: access cpu->icount_decr.u16.high with atomics

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > Consistently access u16.high with atomics to avoid > undefined behaviour in MTTCG. > > Note that icount_decr.u16.low is only used in icount mode, > so regular accesses to it are OK. > > Cc: Peter Crosthwaite > Cc: Richard Henderson > Signed-off-by:

Re: [Qemu-devel] [PATCH 05/35] target/s390x: use cpu_reset_interrupt

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > It will be changed to an atomic operation soon. > > Cc: Cornelia Huck > Cc: Richard Henderson > Cc: Alexander Graf > Cc: David Hildenbrand > Cc: qemu-s3...@nongnu.org > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio

Re: [Qemu-devel] [PATCH 06/35] exec: use cpu_reset_interrupt

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > It will be changed to an atomic operation soon. > > Cc: Peter Crosthwaite > Cc: Richard Henderson > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio G. Cota > --- > accel/tcg/cpu-exec.c | 6 +++--- Reviewed-by: Richard

Re: [Qemu-devel] [PATCH 02/35] target/i386: use cpu_reset_interrupt

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > It will be changed to an atomic operation soon. > > Cc: Richard Henderson > Cc: Eduardo Habkost > Cc: Marcelo Tosatti > Cc: k...@vger.kernel.org > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio G. Cota > --- >

Re: [Qemu-devel] [PATCH 07/35] target/alpha: access cpu->interrupt_request with atomics

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > Cc: Richard Henderson > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio G. Cota > --- > target/alpha/cpu.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Richard Henderson r~

Re: [Qemu-devel] [PATCH 10/35] target/hppa: access cpu->interrupt_request with atomics

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > Cc: Richard Henderson > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio G. Cota > --- > target/hppa/cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~

Re: [Qemu-devel] [PATCH 10/35] target/hppa: access cpu->interrupt_request with atomics

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > Cc: Richard Henderson > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio G. Cota > --- > target/hppa/cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~

Re: [Qemu-devel] [Bug 1793183] [NEW] apt source --compile qemu-system-x86 fails on last ubuntu 18.04.1

On 18 September 2018 at 10:24, Dmitry Isaykin wrote: > Public bug reported: > > Error log: > > /tmp/qemu-2.10+dfsg/util/memfd.c:40:12: error: static declaration of > ‘memfd_create’ follows non-static declaration > static int memfd_create(const char *name, unsigned int flags) >

Re: [Qemu-devel] [PATCH 11/35] target/i386: access cpu->interrupt_request with atomics

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > cpu_reset(cs); > -cs->interrupt_request = sipi; > +atomic_mb_set(>interrupt_request, sipi); > memcpy(>start_init_save, >start_init_save, Why does this need a memory barrier? Anyway, I think a bare mechanical conversion would be best

Re: [Qemu-devel] [PATCH 28/35] exec: access cpu->interrupt_request with atomics

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > Cc: Peter Crosthwaite > Cc: Richard Henderson > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio G. Cota > --- > accel/tcg/cpu-exec.c | 6 +++--- > accel/tcg/tcg-all.c | 3 +-- > accel/tcg/translate-all.c | 2

Re: [Qemu-devel] [PATCH 29/35] exec: drop BQL from cpu_reset_interrupt

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > Now that cpu->interrupt_request is accessed with atomics, > we can drop the BQL around cpu_reset_interrupt, which is a > step towards not taking the BQL mandatorily in cpu_exec_interrupt. > > Cc: Peter Crosthwaite > Cc:

Re: [Qemu-devel] [PATCH 30/35] tcg: drop BQL assertion from tcg_handle_interrupt

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > Cc: Peter Crosthwaite > Cc: Richard Henderson > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio G. Cota > --- > accel/tcg/tcg-all.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Richard Henderson r~

Re: [Qemu-devel] [PATCH v3 0/2] 40p: fix PCI interrupt routing

On 17/09/2018 04:54, David Gibson wrote: > Mark, > > I think we have all the necessary acks to go ahead with this. > However, I'm afraid I've lost track of the various prereq patches that > were necessary here. Can you resend with all the necessary pieces > rebased against ppc-for-3.1 and the

Re: [Qemu-devel] [PATCH 32/35] target/i386/kvm: do not acquire the BQL to call cpu_reset_interrupt

On 9/17/18 9:31 AM, Emilio G. Cota wrote: > From: Paolo Bonzini > > It's not needed anymore. > > Cc: Marcelo Tosatti > Cc: Richard Henderson > Cc: Eduardo Habkost > Cc: k...@vger.kernel.org > Signed-off-by: Paolo Bonzini > Signed-off-by: Emilio G. Cota > --- > target/i386/kvm.c | 4 >

Re: [Qemu-devel] [PATCH 31/35] translate-all: drop BQL assertion from cpu_interrupt

On 9/17/18 9:30 AM, Emilio G. Cota wrote: > This patch explicitly drops the BQL assertion from > the user-mode version; previous patches have taken > care of softmmu's cpu_interrupt. > > Cc: Peter Crosthwaite > Cc: Richard Henderson > Signed-off-by: Emilio G. Cota > --- >

Re: [Qemu-devel] [qemu-s390x] [PATCH v8 3/6] s390x/kvm: enable/disable AP instruction interpretation for guest

On 09/18/2018 06:59 PM, Tony Krowiak wrote: > I've discussed this with Halil -- Pierre is out until next week. We > are in agreement that while these changes are viable, they result in > a slightly more complicated implementation compared to previous versions (e.g. > kernel v9 QEMU v7), and 

Re: [Qemu-devel] [PATCH v2 12/17] mirror: Fix potential use-after-free in active commit

On 18.09.18 17:04, Kevin Wolf wrote: > Am 18.09.2018 um 16:11 hat Max Reitz geschrieben: >> On 17.09.18 13:37, Kevin Wolf wrote: >>> Am 17.09.2018 um 00:05 hat Max Reitz geschrieben: On 14.09.18 18:25, Kevin Wolf wrote: > Am 13.09.2018 um 22:55 hat Max Reitz geschrieben: >> On

[Qemu-devel] [resend PATCH v2] qga-win: add support for qmp_guest_fsfreeze_freeze_list

From: Chen Hanxiao This patch add support for freeze specified fs. The valid mountpoints list member are [1]: The path of a mounted folder, for example, Y:\MountX\ A drive letter, for example, D:\ A volume GUID path of the form \\?\Volume{GUID}\, where GUID identifies the volume

[Qemu-devel] [PATCH 1/1] i386: Add new model of Cascadelake-Server

New CPU models mostly inherit features from ancestor Skylake-Server, while addin new features: AVX512_VNNI, Intel PT. SSBD support for speculative execution side channel mitigations. Note: On Cascadelake, some capabilities (RDCL_NO, IBRS_ALL, RSBA, SKIP_L1DFL_VMENTRY and SSB_NO) are enumerated

[Qemu-devel] [PATCH 0/1] Add new model of Cascadelake-Server

This patch defines the new guest CPU models of Cascadelake-Server. Tao Xu (1): i386: Add new model of Cascadelake-Server target/i386/cpu.c | 54 +++ 1 file changed, 54 insertions(+) -- 2.17.1

Re: [Qemu-devel] [PATCH v4 0/3] file-posix: Simplifications on image locking

On Tue, 08/21 08:58, Fam Zheng wrote: > v4: Fix test on systems without OFD. [Patchew] Ping? > > The first patch reduces chances of QEMU crash in unusual (but not unlikely) > cases especially when used by Libvirt (see commit message). > > The second patch halves fd for images. > > The third

[Qemu-devel] [Bug 1788665] Re: Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection

snapshot_2 showing the pattern of vmentries/vmexits from the previous comment ("zoom-in"). ** Attachment added: "snapshot_2.png" https://bugs.launchpad.net/qemu/+bug/1788665/+attachment/5190356/+files/snapshot_2.png -- You received this bug notification because you are a member of qemu-

[Qemu-devel] [Bug 1788665] Re: Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM using "Spectre" protection

David, your suggestion seemed helpful, at least there is a difference in the pattern of vmentries and vmexits. See the snapshot attached. Explanation of snapshot_1: Two windows of kernelshark with trace.dats obtained using the command from above; the left window (trace.dat) is with spec-ctrl

Re: [Qemu-devel] [RFC v5 0/6] pci_expander_brdige: support separate pci domain for pxb-pcie

> > > 2. Only 4x devices is supported, you need to be careful not to overuse > > > > Could you elaborate on this please? What happens if you are not careful? > > How does management know what the limits are? > > It means the user might use more space than 768MB for mmconfig, > which is

Re: [Qemu-devel] [PATCH 1/1] qmp, hmp: add PCI subsystem id and vendor id to PCI info

* Denis V. Lunev (d...@openvz.org) wrote: > This is a long story. RedHat has relicensed Windows KVM device drivers > in 2018 and there was an agreement that to avoid WHQL driver conflict > software manufacturers should set proper PCI subsystem vendor ID in > their distributions. Thus PCI subsystem

  1   2   >