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

On 18/09/2018 22:12, Mark Cave-Ayland wrote: > Roman, can you reproduce this locally at all? My setup is nothing > special, just Debian Stretch on amd64. I've just realised that because this bug is still dependent upon queued patches, it would make sense for me to push a slightly modified versio

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

On 09/18/2018 08:44 PM, Peter Maydell wrote: > 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

Re: [Qemu-devel] qemu-nbd performance

> > All images are on the RAID0(3 SSD). >> Below is the performance: >> > image numberseq. read(MB/s)seq. write(MB/s) 11480 60 16 1453 36 32 1450 36 64

[Qemu-devel] [RFC v2 3/4] libvhost-user: support VFIO container message

This patch introduces the VFIO container message support in libvhost-user. A new API is added to support setting the VFIO container for the vhost device. Signed-off-by: Tiwei Bie --- contrib/libvhost-user/libvhost-user.c | 29 ++- contrib/libvhost-user/libvhost-user.h | 1

[Qemu-devel] [RFC v2 4/4] vhost-user-bridge: support VFIO container message

This patch introduces the VFIO container message support in vhost-user-bridge. A new option (-G) is added to set the VFIO container for the vhost device. This is mainly used to test the VFIO container message implementation in vhost user. Signed-off-by: Tiwei Bie --- tests/vhost-user-bridge.c |

[Qemu-devel] [RFC v2 1/4] vfio: support creating VFIOContainer directly

This patch introduces several APIs to support creating VFIOContainer from VFIO container fd and AddressSpace directly. These containers will be marked as external, and won't be used by the VFIO passthru code. This is useful when the container fd is opened and shared by another process and that proc

[Qemu-devel] [RFC v2 2/4] vhost-user: support programming VFIO container in master

This patch introduces a slave message to allow slave to share its VFIO container fd to master and do the IOMMU programming based on virtio device's DMA address space for the VFIO groups inside this VFIO container in QEMU. For the vhost backends which support vDPA, they can leverage this message to

[Qemu-devel] [RFC v2 0/4] Supporting programming IOMMU in QEMU (vDPA/vhost-user)

This patch set introduces a slave message in vhost-user to allow slave to share its VFIO container fd to master and do the IOMMU programming based on virtio device's DMA address space for the VFIO groups inside this container in QEMU. For the vhost-user backends which support vDPA, they could leve

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

On 09/18/2018 08:40 PM, Peter Maydell wrote: > 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/a

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

On 09/18/2018 08:47 PM, Peter Maydell wrote: > 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

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

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

[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

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

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 ad

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

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

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 13.09.18

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 lock

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 > --- > accel/tcg/translate-a

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

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

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 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(&cs->interrupt_request, sipi); > memcpy(&env->start_init_save, &save->start_init_save, Why does this need a memory barrier? Anyway, I think a bare mechanical conversion w

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

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 G

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

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 inter

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 tho

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

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

[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 /usr/include/x86_64-linux-gnu/bits/mman

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 tha

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

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

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 libatom

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

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

[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

[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

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

[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

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

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

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

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

[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

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

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

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

[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

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

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

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

[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

[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

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

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

  1   2   >