[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 c

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: Emili

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 > --- > hw/i

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

Am 17.09.18 um 18:31 schrieb Emilio G. Cota: > From: Paolo Bonzini > > cpu->do_interrupt can now be called with BQL held (from > cpu->cpu_exec_interrupt) or without (from cpu_handle_exception). > > Only a few targets rely on global device state in cc->do_interrupt; > add checks to those targets

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] 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 > --- > accel/tcg/translate-all.c

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 Memory

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 --g

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: Don't

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 block

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(-) > > diff

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] 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" #inclu

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 mu

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 > +++ b/target/i386/hvf

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 F

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 m

[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 @@ S:

[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 t

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 virti

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

Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic

17.09.2018 21:33, John Snow wrote: On 09/17/2018 11:51 AM, Vladimir Sementsov-Ogievskiy wrote: Hmm, ping, anybody here ?) Was preparing to stage on Friday, working on it now. I never understood why you forbid the transfer of read only bitmaps though, can you point that out for me? --js re

Re: [Qemu-devel] [libvirt] [PATCH 2/2] hw/vfio/display: add ramfb support

On Fri, Sep 14, 2018 at 09:16:33AM -0600, Alex Williamson wrote: > On Fri, 14 Sep 2018 16:19:07 +0200 > Erik Skultety wrote: > > > On Fri, Sep 14, 2018 at 12:50:09PM +0200, Gerd Hoffmann wrote: > > > Hi, > > > > > > > > Also libvirt manages hotpluggability per device *class*, not per > > > > >

Re: [Qemu-devel] [PATCH 1/3] Improve xen_disk batching behaviour

Hi Tim, I'll reply here for the series (since there are no cover-letter). Thanks, the patches looks good. There are just details that needs to be fixed. When resubmitting the patches, could you CC the relevant maintainers, with the help of the script get_maintainer.pl, and add a cover-letter as

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

Public bug reported: On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant mode), floating-point emulation does not produce the same results as real hardware (e.g., Raspberry Pi 3 with AArch64 Linux). I attached a sample that reproduces the issue. It divides `x` by `y` and puts t

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

I don't think we should see a vmexit on a guest user<->kernel switch. You could try a kvm trace: trace-cmd record -b 2 -e kvm run your test, then ctrl-c then trace-cmd report and you can see all the reasons for exit and see if there are any major differences. Yes, it would be good to know

Re: [Qemu-devel] [Qemu-block] [PATCH v2 11/17] block-backend: Decrease in_flight only after callback

Am 17.09.2018 um 19:08 hat Paolo Bonzini geschrieben: > On 17/09/2018 18:51, Kevin Wolf wrote: > > Am 17.09.2018 um 17:59 hat Paolo Bonzini geschrieben: > >> On 17/09/2018 14:53, Kevin Wolf wrote: > > I think I can drop the ref/unref pair, but not the whole patch (whose > > main point is re

Re: [Qemu-devel] [PATCH v3 0/5] qga: report serial number and disk node

Gentle reminder. This feature is fairly important for oVirt and I'd rather not miss another release. On Fri, 7 Sep 2018 13:42:08 +0200 Tomáš Golembiovský wrote: > Note that PCI controller reporting on Windows was and still is broken. > Unfortunately I don't know how to fix it at the momemnt. S

[Qemu-devel] [Bug 1793016] Re: vmdk to cqow2 invalid VMDK image descriptor

Found a work around by removing the option "-f vmd" Still a bug though. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1793016 Title: vmdk to cqow2 invalid VMDK image descriptor Status in QEMU: N

[Qemu-devel] [Bug 1793016] Re: vmdk to cqow2 invalid VMDK image descriptor

meant "vmdk" of course. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1793016 Title: vmdk to cqow2 invalid VMDK image descriptor Status in QEMU: New Bug description: Greetings, CentOS 7.5.

Re: [Qemu-devel] Cluster doesn't truncate after commit to backing file

On 9/18/18 12:05 AM, lampahome wrote: I have two image A and B, and A is the backing file of B I write data in address addr in A. Then create B and set A as backing file of B. Then I discard the same addr in B. So the entry of addr in l2 table should be 1( also is QCOW2_CLUSTER_ZERO_PLAIN) , ri

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

Hi, I noticed two x86_64 CPU features were removed from QEMU in 3.0.0: - ospke removed by 9ccb9784b57 - osxsave removed by f1a23522b03 More precisely, the CPUID bits are still there (and for example Icelake CPU model has the ospke bit set), but the string representations were removed. Thu

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

On Tue, Sep 18, 2018 at 03:07:35PM +0200, Jiri Denemark wrote: > Hi, > > I noticed two x86_64 CPU features were removed from QEMU in 3.0.0: > - ospke removed by 9ccb9784b57 > - osxsave removed by f1a23522b03 > > More precisely, the CPUID bits are still there (and for example Icelake > CPU

[Qemu-devel] [PATCH] qapi/misc.json: Clarify about usage of QMP 'cpu-add'

Eduardo Habkost mentioned on IRC that the intended functionality of QMP 'cpu-add' is replaced with a combination of 'query-hotpluggable-cpus' and 'device_add'. And 'cpu-add' is likely to be deprecated in the future. Add a note in the QAPI schema to reflect that. Suggested-by: Eduardo Habkost --

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

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)\ > > > +type name(const type *ptr) \ > >

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

On Tue, Sep 18, 2018 at 10:14:45 -0300, Eduardo Habkost wrote: > On Tue, Sep 18, 2018 at 03:07:35PM +0200, Jiri Denemark wrote: > > Sure, libvirt could just avoid passing feature=off for any feature which > > is not supported by the QEMU binary it is about to start since such > > feature should be

Re: [Qemu-devel] qemu-nbd performance

On 9/18/18 2:06 AM, lampahome wrote: 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 f

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

Cc Laine, Eric for an opinion about the management interface. On Mon, Sep 17, 2018 at 10:57:31PM +0800, Zihan Yang wrote: > Hi all > > Here is a minimal working version of supporting multiple pci domains. > The next a few paragraphs will illustrate the purpose and use example. > Current issue and

Re: [Qemu-devel] Different type of qcow2_get_cluster_type

On 9/18/18 3:45 AM, lampahome wrote: 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

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

On Tue, Sep 18, 2018 at 03:26:18PM +0200, Jiri Denemark wrote: > On Tue, Sep 18, 2018 at 10:14:45 -0300, Eduardo Habkost wrote: > > On Tue, Sep 18, 2018 at 03:07:35PM +0200, Jiri Denemark wrote: > > > Sure, libvirt could just avoid passing feature=off for any feature which > > > is not supported by

Re: [Qemu-devel] [PATCH] qapi/misc.json: Clarify about usage of QMP 'cpu-add'

[...] If it looks OK to merge, when merging, please remove the needless word 'about': s/Clarify about/Clarify/ in the commit message summary line. -- /kashyap

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

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 okay to add them back as no-ops, especially we'd actually want them to be customizable for user-mode emulation. Paolo

Re: [Qemu-devel] [Qemu-block] [PATCH v2 11/17] block-backend: Decrease in_flight only after callback

On 18/09/2018 13:34, Kevin Wolf wrote: >> But then basically the main issue is mirror.c's call to >> bdrv_drained_begin/end. There are no other calls to >> bdrv_drained_begin/end inside coroutines IIRC. > > Coroutine or not doesn't matter. What matters is that you drain inside > some (high-level)

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

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 starting an active commit job, other callbacks can run before >

Re: [Qemu-devel] [PATCH] qapi/misc.json: Clarify about usage of QMP 'cpu-add'

On Tue, Sep 18, 2018 at 03:23:03PM +0200, Kashyap Chamarthy wrote: > Eduardo Habkost mentioned on IRC that the intended functionality of QMP > 'cpu-add' is replaced with a combination of 'query-hotpluggable-cpus' > and 'device_add'. And 'cpu-add' is likely to be deprecated in the > future. > > Ad

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

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 okay to add them back as no-ops, > especially we'd

Re: [Qemu-devel] [PATCH 0/3] i386: improve output from "-cpu help" argument

On Mon, Jun 11, 2018 at 06:23:11PM -0300, Eduardo Habkost wrote: > On Wed, Jun 06, 2018 at 05:55:24PM +0100, Daniel P. Berrangé wrote: > > This short series is a set of improvements to the "-cpu help" output for > > the x86 emulator. The patches describe what's change in each step, but > > it is be

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

* Thomas Huth (th...@redhat.com) 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 "boot-comm

Re: [Qemu-devel] [PATCH 0/3] i386: improve output from "-cpu help" argument

On Tue, Sep 18, 2018 at 04:23:19PM +0200, Kashyap Chamarthy wrote: > On Mon, Jun 11, 2018 at 06:23:11PM -0300, Eduardo Habkost wrote: > > On Wed, Jun 06, 2018 at 05:55:24PM +0100, Daniel P. Berrangé wrote: > > > This short series is a set of improvements to the "-cpu help" output for > > > the x86

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

> On Sep 17, 2018, at 7:46 PM, Peter Maydell wrote: > > On 18 September 2018 at 00:18, Programmingkid > wrote: >> >>> On Sep 17, 2018, at 5:25 PM, Peter Maydell wrote: >>> >>> On 17 September 2018 at 22:18, John Arbuckle >>> wrote: https://www.nxp.com/files-static/product/doc/MPCFPE

[Qemu-devel] [Bug 1793016] Re: vmdk to cqow2 invalid VMDK image descriptor

Hi, Judging from the "file" output and the fact that you say the result is correct when removing "-f vmdk", it appears as if the input is in fact not in vmdk format but just a raw image. I don't know too much about vmdk, but I suppose that there is a descriptor file that goes aloing with that s

[Qemu-devel] [Bug 1791947] Re: isochronous usb device forwarding with windows 10 and xhci freezes

The same bug also occurs with Windows 7 Enterprise SP1. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1791947 Title: isochronous usb device forwarding with windows 10 and xhci freezes Status in QE

Re: [Qemu-devel] [Qemu-block] [PATCH v2 11/17] block-backend: Decrease in_flight only after callback

Am 18.09.2018 um 16:12 hat Paolo Bonzini geschrieben: > On 18/09/2018 13:34, Kevin Wolf wrote: > >> But then basically the main issue is mirror.c's call to > >> bdrv_drained_begin/end. There are no other calls to > >> bdrv_drained_begin/end inside coroutines IIRC. > > > > Coroutine or not doesn't

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

Michael S. Tsirkin 于2018年9月18日周二 下午9:41写道： > > Cc Laine, Eric for an opinion about the management interface. > > On Mon, Sep 17, 2018 at 10:57:31PM +0800, Zihan Yang wrote: > > Hi all > > > > Here is a minimal working version of supporting multiple pci domains. > > The next a few paragraphs will i

[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 0x0

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 woul

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 s

[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, esp

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: > > > https://github.com/qemu/qemu/commit/ce3a9eaff4e5f29514dba35a001894cb7a238e0

[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 --- block/qcow

[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 for

[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 i

[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 coroutine_f

[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 +++ b/do

[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 delet

[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 ++--

[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 +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 awar

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 j

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 ok

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. Thu

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 ($p

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] [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 inf

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 ove

[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: https://lists.gn

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 instruction

[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 QE

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

in the git 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) -

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 "boot-comm

[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. https://bugs.launchpad.net/bug

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, flags)

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 sourc

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 SM

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

[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 notific

[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 mist

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 > --- > h

[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 no

[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 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 for

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, Fra

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 ea

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 slightl

  1   2   >