Re: [Qemu-devel] [qemu-s390x] [PATCH v3 9/9] target/s390x: Check HAVE_ATOMIC128 and HAVE_CMPXCHG128 at translate

On 03/10/2018 21:39, Richard Henderson wrote: > Cc: qemu-s3...@nongnu.org > Signed-off-by: Richard Henderson > --- > target/s390x/mem_helper.c | 40 +++ > target/s390x/translate.c | 25 +--- > 2 files changed, 38 insertions(+), 27

Re: [Qemu-devel] [qemu-s390x] [PATCH v3 8/9] target/s390x: Skip wout, cout helpers if op helper does not return

On 03/10/2018 21:39, Richard Henderson wrote: > When op raises an exception, it may not have initialized the output > temps that would be written back by wout or cout. > > Cc: qemu-s3...@nongnu.org > Signed-off-by: Richard Henderson > --- > target/s390x/translate.c | 12 +++- > 1 file

Re: [Qemu-devel] [qemu-s390x] [PATCH v3 7/9] target/s390x: Split do_cdsg, do_lpq, do_stpq

On 03/10/2018 21:39, Richard Henderson wrote: > Cc: qemu-s3...@nongnu.org > Signed-off-by: Richard Henderson > --- > target/s390x/mem_helper.c | 128 ++ > 1 file changed, 61 insertions(+), 67 deletions(-) > > diff --git a/target/s390x/mem_helper.c

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

On Thu, Oct 11, 2018 at 07:59:59AM +0200, Andrea Bolognani wrote: > On Wed, 2018-10-10 at 10:57 -0700, Alistair wrote: > > I use this monolithic config: > > https://github.com/alistair23/meta-riscv/blob/7a950aa705b439b5ec19bb6f094930888335ba7b/recipes-kernel/linux/files/freedom-u540/defconfig > >

Re: [Qemu-devel] [PATCH v2 0/4] hw/pci-host/x86: extend the 64-bit PCI hole relative to the fw-assigned base

Michael, On 09/27/18 23:24, Laszlo Ersek wrote: > This is v2 of the series previously posted at > . > > Changes are noted on every patch. can you please merge this series? Please note that it depends on v2 of the following

Re: [Qemu-devel] [qemu-s390x] [PATCH v3 6/9] target/s390x: Convert to HAVE_CMPXCHG128 and HAVE_ATOMIC128

On 03/10/2018 21:39, Richard Henderson wrote: > Cc: qemu-s3...@nongnu.org > Signed-off-by: Richard Henderson > --- > target/s390x/mem_helper.c | 92 +-- > 1 file changed, 41 insertions(+), 51 deletions(-) > > diff --git a/target/s390x/mem_helper.c

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

On Thu, Oct 11, 2018 at 07:59:59AM +0200, Andrea Bolognani wrote: > On Wed, 2018-10-10 at 10:57 -0700, Alistair wrote: > > On 10/10/2018 05:26 AM, Andrea Bolognani wrote: > > > * what should libvirt look for to figure out whether or not a RISC-V > > >guest will have PCI support? For aarch64 we

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

Daniel Henrique Barboza writes: > 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

Re: [Qemu-devel] [PATCH] sdl2: Support all virtio-gpu formats

On Wed, Oct 10, 2018 at 07:35:06PM +0200, Max Reitz wrote: > On 10.10.18 12:10, Gerd Hoffmann wrote: > > On Mon, Oct 08, 2018 at 08:50:13PM +0200, Max Reitz wrote: > >> There are some 2D resource formats that can be used through virtio-gpu, > > > > Ahem, not really. XRGB is the only one which

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

Daniel Henrique Barboza writes: > 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

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

Daniel Henrique Barboza writes: > 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 >

[Qemu-devel] [PATCH v5 2/3] file-posix: Drop s->lock_fd

The lock_fd field is not strictly necessary because transferring locked bytes from old fd to the new one shouldn't fail anyway. This spares the user one fd per image. Signed-off-by: Fam Zheng Reviewed-by: Max Reitz --- block/file-posix.c | 37 + 1 file

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

v5: Address Max's comments (Thanks for reviewing): - Clean up after test done. - Add rev-by to patch 1 and 2. v4: Fix test on systems without OFD. [Patchew] The first patch reduces chances of QEMU crash in unusual (but not unlikely) cases especially when used by Libvirt (see commit

[Qemu-devel] [PATCH v5 1/3] file-posix: Skip effectiveless OFD lock operations

If we know we've already locked the bytes, don't do it again; similarly don't unlock a byte if we haven't locked it. This doesn't change the behavior, but fixes a corner case explained below. Libvirt had an error handling bug that an image can get its (ownership, file mode, SELinux) permissions

[Qemu-devel] [PATCH v5 3/3] tests: Add unit tests for image locking

Signed-off-by: Fam Zheng --- tests/Makefile.include | 2 + tests/test-image-locking.c | 157 + 2 files changed, 159 insertions(+) create mode 100644 tests/test-image-locking.c diff --git a/tests/Makefile.include b/tests/Makefile.include index

[Qemu-devel] [PATCH] spapr_pci: rename some structured types

According to CODING_STYLE, structured types names are expected to be in CamelCase. PCI is dropped from the name for better readability. While here, this also converts a call to g_malloc(n * sizeofi(foo)) to g_new(n, foo), which is a recommended good practice. Signed-off-by: Greg Kurz ---

Re: [Qemu-devel] [PATCH v2 2/2] monitor: delay monitor iothread creation

Peter Xu writes: > On Fri, Sep 28, 2018 at 01:00:26PM +0400, Marc-André Lureau wrote: >> Hi >> >> On Fri, Sep 28, 2018 at 12:02 PM Wolfgang Bumiller >> wrote: >> > >> > Commit d32749deb615 moved the call to monitor_init_globals() >> > to before os_daemonize(), making it an unsuitable place to

[Qemu-devel] [QEMU-PPC] [PATCH V3 1/3] target/ppc: Update linux-headers for v4.19-rc7

Signed-off-by: Suraj Jitindar Singh --- linux-headers/asm-powerpc/kvm.h | 1 + linux-headers/linux/kvm.h | 1 + 2 files changed, 2 insertions(+) diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h index 1b32b56a03..8c876c166e 100644 ---

[Qemu-devel] [QEMU-PPC] [PATCH V3 2/3] target/ppc: Add one reg id for ptcr

The ptcr (partition table control register) is used to store the address and size of the partition table. For nested kvm-hv we have a level 1 guest register the location of it's partition table with the hypervisor. Thus to support migration we need to be able to read this out of kvm and restore it

[Qemu-devel] [QEMU-PPC] [PATCH V3 0/3] ppc/spapr: Add support for nested kvm-hv

This patch series adds the qemu support for running nested kvm-hv on a POWER9 platform with appropriate hypervisor support and migration of these guests. That is, the ability to run kvm-hv guests as guests of an operating system which is itself a kvm-hv guest. The host (L0 hypervisor) and level 1

[Qemu-devel] [QEMU-PPC] [PATCH V3 3/3] ppc/spapr_caps: Add SPAPR_CAP_NESTED_KVM_HV

Add the spapr cap SPAPR_CAP_NESTED_KVM_HV to be used to control the availability of nested kvm-hv to the level 1 (L1) guest. Assuming a hypervisor with support enabled an L1 guest can be allowed to use the kvm-hv module (and thus run it's own kvm-hv guests) by setting: -machine

Re: [Qemu-devel] [PATCH v5 0/5] Connect a PCIe host and graphics support to RISC-V

On Wed, 2018-10-10 at 10:57 -0700, Alistair wrote: > On 10/10/2018 05:26 AM, Andrea Bolognani wrote: > > * what should libvirt look for to figure out whether or not a RISC-V > >guest will have PCI support? For aarch64 we look for the presence > >of the 'gpex-pcihost' device, but of course

<    1   2   3   4