Re: [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

On 06/22/2018 03:36 PM, Christian Borntraeger wrote: > > > On 06/22/2018 02:55 PM, Kevin Wolf wrote: >> Am 22.06.2018 um 13:38 hat Christian Borntraeger geschrieben: >>> >>> On 06/15/2018 04:21 PM, Kevin Wolf wrote: >>>> The -drive option

Re: [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

On 06/22/2018 02:55 PM, Kevin Wolf wrote: > Am 22.06.2018 um 13:38 hat Christian Borntraeger geschrieben: >> >> On 06/15/2018 04:21 PM, Kevin Wolf wrote: >>> The -drive option serial was deprecated in QEMU 2.10. It's time to >>> remove it. >>> >

Re: [Qemu-devel] [PATCH v4] s390/ipl: fix ipl with -no-reboot

On 06/22/2018 03:22 PM, no-re...@patchew.org wrote: > Hi, > > This series failed docker-mingw@fedora build test. Please find the testing > commands and > their output below. If you have Docker installed, you can probably reproduce > it > locally. > [...] > CC os-win32.o > CC

[Qemu-devel] request a revert for "block: Remove deprecated -drive option serial" (was block: Remove deprecated -drive option serial)

adding more CC. On 06/22/2018 01:38 PM, Christian Borntraeger wrote: > > On 06/15/2018 04:21 PM, Kevin Wolf wrote: >> The -drive option serial was deprecated in QEMU 2.10. It's time to >> remove it. >> >> Tests need to be updated to set the serial number wi

Re: [Qemu-devel] [PULL 25/26] block: Remove deprecated -drive option serial

On 06/15/2018 04:21 PM, Kevin Wolf wrote: > The -drive option serial was deprecated in QEMU 2.10. It's time to > remove it. > > Tests need to be updated to set the serial number with -global instead > of using the -drive option. libvirt 4.5 still creates those (at least on s390x)

[Qemu-devel] [PATCH v4] s390/ipl: fix ipl with -no-reboot

l from iso images. We need to mark these "subsystem reset" as special. Fixes: a30fb811cbe9 (s390x: refactor reset/reipl handling) Signed-off-by: Christian Borntraeger Reviewed-by: David Hildenbrand --- v3->v4: - rename to SHUTDOWN_CAUSE_SUBSYSTEM_RESET - modify comments and

Re: [Qemu-devel] [PATCH v3 1/1] s390/ipl: fix ipl with -no-reboot

On 06/22/2018 11:59 AM, Paolo Bonzini wrote: > On 22/06/2018 11:46, Cornelia Huck wrote: Ok, then my suggestion made even more sense. :) No other objections apart from the name of the constant. Paolo >>> SHUTDOWN_CAUSE_S390_PARTIAL ? >> Don't like that one much. >> >>>

Re: [Qemu-devel] [PATCH v3 1/1] s390/ipl: fix ipl with -no-reboot

On 06/21/2018 07:08 PM, Paolo Bonzini wrote: > On 21/06/2018 19:01, Christian Borntraeger wrote: >> kexec/kdump as well as the bootloader use a subcode of diagnose 308 >> that is supposed to reset the subsystem but not comprise a full >> "reboot". With the latest

[Qemu-devel] [PATCH v3 1/1] s390/ipl: fix ipl with -no-reboot

hese "soft" reboots as ok for rebooting. Fixes: a30fb811cbe9 (s390x: refactor reset/reipl handling) Signed-off-by: Christian Borntraeger --- hw/s390x/ipl.c | 8 +++- include/sysemu/sysemu.h | 3 +++ vl.c| 4 ++-- 3 files changed, 12 insertions(+), 3 dele

Re: [Qemu-devel] [PATCH v2] s390/ipl: fix ipl with -no-reboot

On 06/21/2018 06:51 PM, Christian Borntraeger wrote: > > > On 06/21/2018 06:35 PM, Christian Borntraeger wrote: >> kexec/kdump as well as the bootloader use a subcode of diagnose 308 >> that is supposed to reset the subsystem but not comprise a full >> "rebo

Re: [Qemu-devel] [PATCH v2] s390/ipl: fix ipl with -no-reboot

On 06/21/2018 06:35 PM, Christian Borntraeger wrote: > kexec/kdump as well as the bootloader use a subcode of diagnose 308 > that is supposed to reset the subsystem but not comprise a full > "reboot". With the latest refactoring this is now broken when > -no-reboot is

[Qemu-devel] [PATCH v2] s390/ipl: fix ipl with -no-reboot

hese "soft" reboots as ok for rebooting. Fixes: a30fb811cbe9 (s390x: refactor reset/reipl handling) Signed-off-by: Christian Borntraeger --- hw/s390x/ipl.c | 8 +++- include/sysemu/sysemu.h | 3 +++ vl.c| 2 +- 3 files changed, 11 insertions(+), 2 deletions

[Qemu-devel] [PATCH 1/1] s390/ipl: fix ipl with -no-reboot

hese "soft" reboots as ok for rebooting. Fixes: a30fb811cbe9 (s390x: refactor reset/reipl handling) Signed-off-by: Christian Borntraeger --- hw/s390x/ipl.c | 8 +++- include/sysemu/sysemu.h | 3 +++ vl.c| 2 +- 3 files changed, 11 insertions(+), 2 deletions

Re: [Qemu-devel] [qemu-s390x] [PATCH v1] s390x: refactor reset/reipl handling

On 06/21/2018 06:20 PM, Christian Borntraeger wrote: > > > On 06/21/2018 06:15 PM, David Hildenbrand wrote: >> On 21.06.2018 17:49, Christian Borntraeger wrote: >>> >>> >>> On 04/24/2018 12:18 PM, David Hildenbrand wrote: >>>> Calling p

Re: [Qemu-devel] [PATCH v1] s390x: refactor reset/reipl handling

On 06/21/2018 06:15 PM, David Hildenbrand wrote: > On 21.06.2018 17:49, Christian Borntraeger wrote: >> >> >> On 04/24/2018 12:18 PM, David Hildenbrand wrote: >>> Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread might >>> not be the best

Re: [Qemu-devel] [PATCH v1] s390x: refactor reset/reipl handling

On 06/21/2018 06:07 PM, David Hildenbrand wrote: > On 21.06.2018 18:04, Cornelia Huck wrote: >> On Thu, 21 Jun 2018 17:49:56 +0200 >> Christian Borntraeger wrote: >> >>> On 04/24/2018 12:18 PM, David Hildenbrand wrote: >>>> Calling pause_all_vcpus()/r

Re: [Qemu-devel] [PATCH v1] s390x: refactor reset/reipl handling

On 06/21/2018 06:04 PM, Cornelia Huck wrote: > On Thu, 21 Jun 2018 17:49:56 +0200 > Christian Borntraeger wrote: > >> On 04/24/2018 12:18 PM, David Hildenbrand wrote: >>> Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread might >>> not be

Re: [Qemu-devel] [PATCH v1] s390x: refactor reset/reipl handling

On 04/24/2018 12:18 PM, David Hildenbrand wrote: > Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread might > not be the best idea. As pause_all_vcpus() temporarily drops the qemu > mutex, two parallel calls to pause_all_vcpus() can be active at a time, > resulting in a deadlock.

Re: [Qemu-devel] [PATCH v2 0/2] Detect & register virtio-crypto algos only if it can be supported by backend

YI. I have not looked into the details of the patch, but I like the idea. Acked-by: Christian Borntraeger > > Thanks > Farhan > > On 06/13/2018 04:38 PM, Farhan Ali wrote: >> Hi, >> >> Currently the Linux virtio-crypto driver registers the crypto >>

Re: [Qemu-devel] [RFC v1 1/1] virtio-crypto: Allow disabling of cipher algorithms for virtio-crypto device

On 06/13/2018 05:05 PM, Daniel P. Berrangé wrote: > On Wed, Jun 13, 2018 at 11:01:05AM -0400, Farhan Ali wrote: >> Hi Daniel >> >> On 06/13/2018 05:37 AM, Daniel P. Berrangé wrote: >>> On Tue, Jun 12, 2018 at 03:48:34PM -0400, Farhan Ali wrote: The virtio-crypto driver currently propagates

Re: [Qemu-devel] [qemu-s390x] [PATCH v2] pc-bios/s390-ccw: Optimize the s390-netboot.img for size

image that > we do not need in the firmware. > > Signed-off-by: Thomas Huth Acked-by: Christian Borntraeger > --- > pc-bios/s390-ccw/Makefile| 1 + > pc-bios/s390-ccw/netboot.mak | 4 ++-- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a

Re: [Qemu-devel] [qemu-s390x] [PATCH] pc-bios/s390-ccw: Optimize the s390-ccw bios for size

On 06/14/2018 10:48 AM, Thomas Huth wrote: > Since we're storing the firmware blobs in the QEMU git repository, it > would be nice if the blobs would be a little bit smaller. By using -Os > and -fno-asynchronous-unwind-tables the size of the s390-ccw.img can be > decreased by ca. 4kB, and the

Re: [Qemu-devel] [PATCH] s390x/cpumodels: add z14 Model ZR1

On 06/13/2018 11:00 AM, David Hildenbrand wrote: > On 13.06.2018 10:18, Christian Borntraeger wrote: >> introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only >> the cpu type differs (3906 vs. 3907) >> >> Signed-off-by: Christian Borntraeg

Re: [Qemu-devel] [PATCH] s390x/cpumodels: add z14 Model ZR1

On 06/13/2018 11:00 AM, David Hildenbrand wrote: > On 13.06.2018 10:18, Christian Borntraeger wrote: >> introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only >> the cpu type differs (3906 vs. 3907) >> >> Signed-off-by: Christian Borntraeg

[Qemu-devel] [PATCH] s390x/cpumodels: add z14 Model ZR1

introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only the cpu type differs (3906 vs. 3907) Signed-off-by: Christian Borntraeger --- target/s390x/cpu_models.c | 1 + 1 file changed, 1 insertion(+) diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c index

[Qemu-devel] [PATCH v4 1/1] s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSW

Right now the IPL device always starts from address 0x1 (the usual Linux entry point). To run other guests (e.g. test programs) it is useful to use the IPL PSW from address 0. We can use the Linux magic at 0x10008 to decide. Signed-off-by: Christian Borntraeger --- v3->v4: - ipl

Re: [Qemu-devel] [PATCH v3 1/1] s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSW

On 06/12/2018 01:55 PM, Cornelia Huck wrote: > On Tue, 12 Jun 2018 12:04:48 +0200 > Christian Borntraeger wrote: > >> Right now the IPL device always starts from address 0x1 (the usual >> Linux entry point). To run other guests (e.g. test programs) it is >> use

[Qemu-devel] [PATCH v3 1/1] s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSW

Right now the IPL device always starts from address 0x1 (the usual Linux entry point). To run other guests (e.g. test programs) it is useful to use the IPL PSW from address 0. We can use the Linux magic at 0x10008 to decide. Signed-off-by: Christian Borntraeger --- v2->v3: - ch

Re: [Qemu-devel] [qemu-s390x] [PATCH v2] hw/s390x/ipl: Fix crashes that occurs when -kernel is used with small images

s390x-softmmu/qemu-system-s390x -kernel /tmp/test.txt -initrd /tmp/test.txt > Segmentation fault (core dumped) > > Signed-off-by: Thomas Huth Reviewed-by: Christian Borntraeger > --- > v2: Fixed 2nd crash with -initrd > > hw/s390x/ipl.c | 9 ++--- > 1 file change

Re: [Qemu-devel] [PATCH v2 1/1] s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSW

On 06/11/2018 06:16 PM, Thomas Huth wrote: > On 11.06.2018 15:52, Christian Borntraeger wrote: >> Right now the IPL device always starts from address 0x1 (the usual >> Linux entry point). To run other guests (e.g. test programs) it is >> useful to use the IPL PSW from

Re: [Qemu-devel] [PATCH v2 1/1] s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSW

On 06/11/2018 06:16 PM, Thomas Huth wrote: > On 11.06.2018 15:52, Christian Borntraeger wrote: >> Right now the IPL device always starts from address 0x1 (the usual >> Linux entry point). To run other guests (e.g. test programs) it is >> useful to use the IPL PSW from

[Qemu-devel] [PATCH v2 1/1] s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSW

Right now the IPL device always starts from address 0x1 (the usual Linux entry point). To run other guests (e.g. test programs) it is useful to use the IPL PSW from address 0. We can use the Linux magic at 0x10008 to decide. Signed-off-by: Christian Borntraeger --- v1->v2: -

Re: [Qemu-devel] [PATCH] hw/s390x/ipl: Fix crash that occurs when -kernel is used with small images

On 06/11/2018 12:08 PM, Thomas Huth wrote: > On 11.06.2018 11:24, Cornelia Huck wrote: >> On Mon, 11 Jun 2018 09:49:39 +0200 >> Christian Borntraeger wrote: >> >>> On 06/10/2018 03:12 PM, Thomas Huth wrote: >>>> Add a sanity check to fix the

Re: [Qemu-devel] [PATCH v2 0/4] pc-bios/s390-ccw: Allow network booting via pxelinux.cfg

> roms/SLOF | 2 +- > 3 files changed, 162 insertions(+), 75 deletions(-) > Series Acked-by: Christian Borntraeger

Re: [Qemu-devel] [PATCH] hw/s390x/ipl: Fix crash that occurs when -kernel is used with small images

ned-off-by: Thomas Huth Reviewed-by: Christian Borntraeger I think a similar problem exists for INITRD_PARM_START and INITRD_PARM_SIZE. No? > --- > hw/s390x/ipl.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c >

Re: [Qemu-devel] [PATCH v1 8/8] s390x: local error handling in hotplug handler functions

On 06/08/2018 09:40 AM, David Hildenbrand wrote: > On 08.06.2018 09:27, Christian Borntraeger wrote: >> >> >> On 06/08/2018 09:25 AM, Cornelia Huck wrote: >>> On Thu, 7 Jun 2018 18:52:18 +0200 >>> David Hildenbrand wrote: >>> >>>>

Re: [Qemu-devel] [qemu-s390x] [PATCH v2 2/4] pc-bios/s390-ccw/net: Update code for the latest changes in SLOF

rid of some superfluous "(char *)" casts now. > > Signed-off-by: Thomas Huth Acked-by: Christian Borntraeger > --- > pc-bios/s390-ccw/netboot.mak | 2 +- > pc-bios/s390-ccw/netmain.c | 86 > +--- > 2 files changed, 18 ins

Re: [Qemu-devel] [PATCH v1 8/8] s390x: local error handling in hotplug handler functions

On 06/08/2018 09:25 AM, Cornelia Huck wrote: > On Thu, 7 Jun 2018 18:52:18 +0200 > David Hildenbrand wrote: > >> Let's introduce and use local error variables in the hotplug handler >> functions. >> >> Signed-off-by: David Hildenbrand >> --- >> hw/s390x/s390-virtio-ccw.c | 11 ---

Re: [Qemu-devel] [PATCH] s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSW

On 05/08/2018 04:15 PM, Christian Borntraeger wrote: > Right now the IPL device always starts from address 0x1 (the usual > Linux entry point). To run other guests (e.g. test programs) it is > useful to use the IPL PSW from address 0. We can use the Linux magic > at 0x100

Re: [Qemu-devel] [PATCH] s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSW

On 05/08/2018 04:15 PM, Christian Borntraeger wrote: > Right now the IPL device always starts from address 0x1 (the usual > Linux entry point). To run other guests (e.g. test programs) it is > useful to use the IPL PSW from address 0. We can use the Linux magic > at 0x100

[Qemu-devel] [PATCH] s390x/ipl: Try to detect Linux vs non Linux for initial IPL PSW

Right now the IPL device always starts from address 0x1 (the usual Linux entry point). To run other guests (e.g. test programs) it is useful to use the IPL PSW from address 0. We can use the Linux magic at 0x10008 to decide. Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com>

Re: [Qemu-devel] [PATCH] pc-bios/s390-ccw: struct tpi_info must be declared as aligned(4)

On 05/08/2018 01:06 PM, Cornelia Huck wrote: > On Tue, 8 May 2018 12:49:59 +0200 > Thomas Huth wrote: > >> On 08.05.2018 12:44, Cornelia Huck wrote: >>> On Tue, 8 May 2018 12:17:52 +0200 >>> Thomas Huth wrote: >>> I've run into a compilation error

Re: [Qemu-devel] [qemu-s390x] [PATCH 2/2] s390x/ccw: make sure all ccw devices are properly reset

> Reported-by: Thomas Huth <th...@redhat.com> > Suggested-by: Christian Borntraeger <borntrae...@de.ibm.com> > Signed-off-by: Cornelia Huck <coh...@redhat.com> > --- > hw/s390x/ccw-device.c | 8 > hw/s390x/virtio-ccw.c | 9 ++--- > hw/s390x

Re: [Qemu-devel] [libvirt] [PATCH 0/1] Bug: Sandbox: libvirt breakdowns qemu guest

On 05/07/2018 02:02 PM, Ján Tomko wrote: > On Mon, May 07, 2018 at 12:33:20PM +0200, Eduardo Otubo wrote: >> On 07/05/2018 - 11:29:57, Christian Borntraeger wrote: >>> On 05/07/2018 05:32 AM, Yi Min Zhao wrote: >>> > 1. Problem Description >>> > ===

Re: [Qemu-devel] [PATCH 0/1] Bug: Sandbox: libvirt breakdowns qemu guest

On 05/07/2018 05:32 AM, Yi Min Zhao wrote: > 1. Problem Description > == > If QEMU is built without seccomp support, 'elevatorprivileges' remains > compiled. > This option of sandbox is treated as an indication for seccomp blacklist > support > in libvirt. This behavior is

Re: [Qemu-devel] [qemu-s390x] [PATCH] s390x/css: disabled subchannels cannot be status pending

ver >> attempts to post an interrupt for a disabled device to begin with. >> >> Reported-by: Thomas Huth <th...@redhat.com> >> Signed-off-by: Cornelia Huck <coh...@redhat.com> I agree with your understanding of the PoP. Acked-by: Christian Borntraeger <borntr

Re: [Qemu-devel] [PATCH] s390-ccw: force diag 308 subcode to unsigned long

(rc) > - : "d" (store ? 6 : 5) > + : "d" (subcode) We could also use 6UL : 5UL instead of a local variable, but I certainly do not care enough. Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> >: "memory", "cc"); > return rc == 0x01; > } >

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 0/3] pc-bios/s390-ccw: Some few network boot improvements

On 04/27/2018 03:14 PM, David Hildenbrand wrote: > On 26.04.2018 11:28, Thomas Huth wrote: >> Note: I've decided to removed the pxelinux.cfg patches from this series >> for now, since full pxelinux support requires to parse some additional >> DHCP options (see

Re: [Qemu-devel] [qemu-s390x] [PATCH v4 0/3] pc-bios/s390-ccw: Some few network boot improvements

+++ > pc-bios/s390-ccw/s390-ccw.h | 4 ++ > 7 files changed, 240 insertions(+), 97 deletions(-) > create mode 100644 pc-bios/s390-ccw/jump2ipl.c > Not looked into all details but the general idea and patches Acked-by: Christian Borntraeger <borntrae...@de.ibm.com>

Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

On 04/26/2018 05:43 AM, Thomas Huth wrote: > On 25.04.2018 18:03, Christian Borntraeger wrote: >> >> >> On 04/25/2018 05:36 PM, Thomas Huth wrote: >>> On 25.04.2018 14:44, Christian Borntraeger wrote: >>>> >>>> >>>> On 04/25/2018

Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

On 04/25/2018 05:36 PM, Thomas Huth wrote: > On 25.04.2018 14:44, Christian Borntraeger wrote: >> >> >> On 04/25/2018 02:41 PM, Christian Borntraeger wrote: >>> You load from address 0. >>> >>> On 04/25/2018 02:34 PM, Thomas Huth wrote: >&

Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

On 04/25/2018 05:36 PM, Thomas Huth wrote: > On 25.04.2018 14:44, Christian Borntraeger wrote: >> >> >> On 04/25/2018 02:41 PM, Christian Borntraeger wrote: >>> You load from address 0. >>> >>> On 04/25/2018 02:34 PM, Thomas Huth wrote: >&

Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

On 04/25/2018 02:41 PM, Christian Borntraeger wrote: > You load from address 0. > > On 04/25/2018 02:34 PM, Thomas Huth wrote: >> On 25.04.2018 14:18, Christian Borntraeger wrote: >>> >>> On 04/25/2018 11:08 AM, Thomas Huth wrote: >>> >>>&g

Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

You load from address 0. On 04/25/2018 02:34 PM, Thomas Huth wrote: > On 25.04.2018 14:18, Christian Borntraeger wrote: >> >> On 04/25/2018 11:08 AM, Thomas Huth wrote: >> >>> --- a/pc-bios/s390-ccw/netmain.c >>> +++ b/pc-bios/s390-ccw/netmain.c >>

Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

On 04/25/2018 11:08 AM, Thomas Huth wrote: > --- a/pc-bios/s390-ccw/netmain.c > +++ b/pc-bios/s390-ccw/netmain.c > @@ -283,6 +283,15 @@ void panic(const char *string) > } > } > > +void write_subsystem_identification(void) > +{ > +uint32_t *schid = (uint32_t *) 184; > +uint32_t

Re: [Qemu-devel] [PATCH v1] hw/s390x: Allow to configure the consoles with the "-serial" parameter

nd we have > less s390x-specific code in vl.c :-) > > I've also checked that migration still works as expected by migrating > a guest with console output back and forth between a qemu-system-s390x > that has this patch and an instance without this patch. > > Signed-off-by: Thomas Huth <th...@redhat.com> Very nice. I tested some combinations (only limited test) and everything looks good. Acked-by: Christian Borntraeger <borntrae...@de.ibm.com>

Re: [Qemu-devel] [RFC PATCH] hw/s390x: Allow to configure the consoles with the "-serial" parameter

On 04/24/2018 01:44 PM, Thomas Huth wrote: > The consoles ("sclpconsole" and "sclplmconsole") can only be configured > with "-device" and "-chardev" so far. Other machines use the convenience > option "-serial" to configure the default consoles, too, even for virtual > consoles like spapr-vty on

Re: [Qemu-devel] [PATCH RFC] s390x: refactor reset/reipl handling

Not a full test, but reboot and kdump seem to work ok with KVM. On 04/12/2018 09:26 PM, David Hildenbrand wrote: > Calling pause_all_vcpus()/resume_all_vcpus() from a VCPU thread might > not be the best idea. As pause_all_vcpus() temporarily drops the qemu > mutex, two parallel calls to

Re: [Qemu-devel] [PATCH v1 for-2.13 2/4] pc-bios/s390-ccw/net: Stop virtio-net device before jumping into the OS

On 04/20/2018 08:31 AM, Thomas Huth wrote: > On 19.04.2018 17:49, Christian Borntraeger wrote: >> On 04/18/2018 02:31 PM, Thomas Huth wrote: >>> The virtio-net receive buffers are filled asynchronously, so we should >>> make sure to properly shut down the virti

Re: [Qemu-devel] [qemu-s390x] [PATCH for-2.13] Clear mem_path if we fall back to anonymous RAM allocation

On 04/19/2018 06:08 PM, Greg Kurz wrote: > On Thu, 19 Apr 2018 16:11:37 +0200 > David Hildenbrand <da...@redhat.com> wrote: > >> On 19.04.2018 15:34, Christian Borntraeger wrote: >>> >>> >>> On 04/19/2018 02:58 PM, Cornelia Huck wrote: &

Re: [Qemu-devel] [PATCH v1 for-2.13 2/4] pc-bios/s390-ccw/net: Stop virtio-net device before jumping into the OS

On 04/18/2018 02:31 PM, Thomas Huth wrote: > The virtio-net receive buffers are filled asynchronously, so we should > make sure to properly shut down the virtio-net device before we jump into > the loaded kernel. Otherwise an incoming packet could destroy memory of > the OS kernel if it did not

Re: [Qemu-devel] [qemu-s390x] [PATCH for-2.13] Clear mem_path if we fall back to anonymous RAM allocation

On 04/19/2018 02:58 PM, Cornelia Huck wrote: > On Thu, 19 Apr 2018 14:33:18 +0200 > Igor Mammedov wrote: > >> On Thu, 19 Apr 2018 17:21:23 +1000 >> David Gibson wrote: >> >>> If the -mem-path option is set, we attempt to map the guest's RAM

Re: [Qemu-devel] [PATCH v4 3/5] s390x/cpumodel: Set up CPU model for AP device support

On 04/16/2018 05:44 PM, David Hildenbrand wrote: > >> >> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c >> index 0cdbc15..0d5b0f7 100644 >> --- a/target/s390x/gen-features.c >> +++ b/target/s390x/gen-features.c >> @@ -447,6 +447,9 @@ static uint16_t full_GEN12_GA1[] =

Re: [Qemu-devel] [PATCH v2 for-2.13] pc-bios/s390-ccw: size_t should be unsigned

ode should all be fine with this change. > > Buglink: https://bugs.launchpad.net/qemu/+bug/1753437 > Signed-off-by: Thomas Huth <th...@redhat.com> looks better. I checked all users of size_t and this seems complete. Reviewed-by: Christian Borntraeger <borntrae...@de.ibm.com> > -

Re: [Qemu-devel] [PATCH v1] s390x/kvm: cleanup calls to cpu_synchronize_state()

U > - target/s390x/cpu.c:s390_cpu_get_crash_info() > > While at it, use kvm_cpu_synchronize_state() instead of > cpu_synchronize_state() in KVM code. (suggested by Thomas Huth) > > Signed-off-by: David Hildenbrand <da...@redhat.com> Acked-by: Christian Borntraeger <borntrae...@de.ibm.

Re: [Qemu-devel] [qemu-s390x] [PATCH v1 for-2.12 1/2] s390x/mmu: don't overwrite pending exception in mmu translate

only applies to old KVM instances without the virtual memory access IOCTL in KVM." with that Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> > --- > target/s390x/mmu_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/s390x

Re: [Qemu-devel] [PATCH v1 for-2.12 2/2] s390x: load_psw() should only exchange the PSW for KVM

On 04/09/2018 01:44 PM, David Hildenbrand wrote: > On 09.04.2018 13:40, Christian Borntraeger wrote: >> >> >> On 04/09/2018 01:36 PM, David Hildenbrand wrote: >>> On 09.04.2018 13:35, Christian Borntraeger wrote: >>>> >>>> >>>

Re: [Qemu-devel] [PATCH v1 for-2.12 2/2] s390x: load_psw() should only exchange the PSW for KVM

On 04/09/2018 01:36 PM, David Hildenbrand wrote: > On 09.04.2018 13:35, Christian Borntraeger wrote: >> >> >> On 04/09/2018 01:30 PM, David Hildenbrand wrote: >>> Let's simplify it a bit. On some weird circumstances we would have tried >>> to recom

Re: [Qemu-devel] [PATCH v1 for-2.12 2/2] s390x: load_psw() should only exchange the PSW for KVM

On 04/09/2018 01:30 PM, David Hildenbrand wrote: > Let's simplify it a bit. On some weird circumstances we would have tried > to recompute watchpoints when running under KVM. > > Signed-off-by: David Hildenbrand > --- > target/s390x/helper.c | 10 ++ > 1 file

Re: [Qemu-devel] [PATCH 0/3] s390: Fix virtio-scsi IPL quirks

On 04/05/2018 05:07 PM, Viktor Mihajlovski wrote: > IPL from virtio-scsi currently uses a non-standard parameter > type definition to pass boot parameters from QEMU to the > BIOS. > > There are two potential issues with this approach: > o If the guest operating systems requests a re-ipl of type

Re: [Qemu-devel] [PATCH 3/3] s390: Do not pass inofficial IPL type to the guest

Linux checks for the IPL type unconditionally. > > Signed-off-by: Viktor Mihajlovski <mihaj...@linux.vnet.ibm.com> Reviewed-by: Christian Borntraeger <borntrae...@de.ibm.com> I will do some testing on the whole series and answer to the cover letter. Just in case. > --- > pc-bios/s390

Re: [Qemu-devel] [PATCH v1 for-2.12] s390x/kvm: call cpu_synchronize_state() on every kvm_arch_handle_exit()

On 04/06/2018 11:35 AM, David Hildenbrand wrote: > Manually having to use cpu_synchronize_state() is error prone. And as > Christian Borntraeger discovered, e.g. handle_diag() is currently > missing a cpu_synchronize_state(), as decode_basedisp_s() uses a > general purpose re

Re: [Qemu-devel] [qemu-s390x] [PATCH RFC] s390x/kvm: call cpu_synchronize_state() on every kvm_arch_handle_exit()

On 04/05/2018 10:19 AM, Thomas Huth wrote: > On 05.04.2018 09:53, Christian Borntraeger wrote: >> So currently we only handle the case with base reg == 0 correctly. >> So >> diag x,y,0x500(0) >> works >> >> >> but things like >> lghi 1,0x500

Re: [Qemu-devel] [PATCH RFC] s390x/kvm: call cpu_synchronize_state() on every kvm_arch_handle_exit()

run, there are no > additional IOCTLs to issue on modern kernels. We had other issues in the past in other (common code) places. For example see commit 79ca7a1b898eb97c4192f3c78027a0f20485e7b4 Author: Christian Borntraeger <borntrae...@de.ibm.com> AuthorDate: Tue Mar 7 15:19:08 2017 +

Re: [Qemu-devel] [qemu-s390x] [PATCH for-2.13] s390x: introduce 2.13 compat machine

On 03/29/2018 01:33 PM, Cornelia Huck wrote: > Signed-off-by: Cornelia Huck <coh...@redhat.com> Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> > --- > Yes, it's that time again :) > --- > hw/s390x/s390-virtio-ccw.c | 17 - > include/hw

Re: [Qemu-devel] [PATCH for-2.13] pc-bios/s390-ccw: Increase virtio timeout to 30 seconds

seems to be a sane value for block IO timeout). > > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1549079 > Signed-off-by: Thomas Huth <th...@redhat.com> Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> I think this should go into 2.12 with a rebuild > --- >

Re: [Qemu-devel] [PATCH for-2.13] pc-bios/s390-ccw: Increase virtio timeout to 30 seconds

On 03/29/2018 11:37 AM, Thomas Huth wrote: > The current timeout is set to only three seconds - and considering that > vring_wait_reply() or rather get_second() is not doing any rounding, > the real timeout is likely rather 2 seconds in most cases. When the > host is really badly loaded and we

Re: [Qemu-devel] [PATCH v2 0/4] Monitor: OOB related patches

On 03/27/2018 03:36 AM, Eric Blake wrote: > This is patches 2, 3, 7, and 8 (with 7 rewritten) from Peter Xu's > series. I've pushed them to git://repo.or.cz/qemu/ericb.git qapi-next that branch seems to work fine. (no make check or iotest regression on s390) > (on top of the other pending

Re: [Qemu-devel] [PATCH for-2.12 0/8] Monitor: some oob related patches (fixes, new param, tests)

Thanks for the quick fixing. This series on top of master works fine on s390. (make check and iotests) Christian On 03/26/2018 08:38 AM, Peter Xu wrote: > I suppose these are all good even for 2.12, so marked in subject. > Tested with "make check" for all targets on x86_64, and iotest -raw. >

Re: [Qemu-devel] [PATCH for-2.12 0/4] Turn OOB off for 2.12-rc1, revert OOB tests

On 03/23/2018 06:17 PM, Eric Blake wrote: > On 03/23/2018 10:53 AM, Eric Blake wrote: > >> Actually, we should revert things in reverse order of the original commits, >> so that we aren't introducing yet more temporary breakage. >> >> Since you reverted: >> >> $ git describe 3fd2457 d003f7a

Re: [Qemu-devel] [PATCH for-2.12 0/4] Turn OOB off for 2.12-rc1, revert OOB tests

whole OOB series, so I suppose that's something already >> exists so I'll ignore. >> >> More tests are really welcomed. Thanks, Series Tested-by: Christian Borntraeger <borntrae...@de.ibm.com> > > CC Eric Blake too. >

Re: [Qemu-devel] [PATCH v8 20/23] monitor: enable IO thread for (qmp & !mux) typed

On 03/23/2018 02:01 PM, Peter Xu wrote: > On Fri, Mar 23, 2018 at 01:44:54PM +0100, Christian Borntraeger wrote: >> >> >> On 03/23/2018 01:25 PM, Peter Xu wrote: >>> On Fri, Mar 23, 2018 at 01:10:51PM +0100, Christian Borntraeger wrote: >>>> As Max Reitz

Re: [Qemu-devel] [PATCH v8 20/23] monitor: enable IO thread for (qmp & !mux) typed

On 03/23/2018 01:25 PM, Peter Xu wrote: > On Fri, Mar 23, 2018 at 01:10:51PM +0100, Christian Borntraeger wrote: >> As Max Reitz said, this breaks several qemu iotests. I can reproduce that on >> s390 >> e.g. with ./check -qcow2 030 in the qemu-iotest. >> >> W

Re: [Qemu-devel] Regression on KVM qemu-system-aarch64 since "monitor: enable IO thread for (qmp & !mux) typed"

On 03/23/2018 01:11 PM, Peter Maydell wrote: > On 23 March 2018 at 12:01, Auger Eric wrote: >> Hi, >> >> On 23/03/18 11:26, Peter Maydell wrote: >>> On 23 March 2018 at 10:24, Auger Eric wrote: Hi, I observe a regression on KVM

Re: [Qemu-devel] [PATCH v8 20/23] monitor: enable IO thread for (qmp & !mux) typed

As Max Reitz said, this breaks several qemu iotests. I can reproduce that on s390 e.g. with ./check -qcow2 030 in the qemu-iotest. Why was this merged? On 03/09/2018 10:00 AM, Peter Xu wrote: > Start to use dedicate IO thread for QMP monitors that are not using > MUXed chardev. > >

[Qemu-devel] [PULL 0/2] s390x: Fixes for 2.12

PCI devices Christian Borntraeger (1): s390x/cpumodel: fix feature groups and breakage of MSA8 Yi Min Zhao (1): s390x/pci: forbid multifunction pci device hw/s390x/s390-pci-bus.c | 10 ++ target/s390x

[Qemu-devel] [PULL 2/2] s390x/cpumodel: fix feature groups and breakage of MSA8

Multiple-epoch facility") Reviewed-by: David Hildenbrand <da...@redhat.com> Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> --- target/s390x/cpu_features.h | 1 + 1 file changed, 1 insertion(+) diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h ind

[Qemu-devel] [PULL 1/2] s390x/pci: forbid multifunction pci device

ux.vnet.ibm.com> Reviewed-by: Thomas Huth <th...@redhat.com> Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> --- hw/s390x/s390-pci-bus.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c index 77a50cab36..10

Re: [Qemu-devel] [PATCH] s390x/pci: forbid multifunction pci device

applied to my s390-next branch. On 03/14/2018 06:14 AM, Yi Min Zhao wrote: > Currently we don't support pci multifunction. If a pci with > multifucntion is plugged, the guest will spin forever. This patch fixes > this. > > Signed-off-by: Yi Min Zhao > Reviewed-by:

Re: [Qemu-devel] [PATCH 1/1] s390x/cpumodel: fix feature groups and breakage of MSA8

On 03/20/2018 02:07 PM, Christian Borntraeger wrote: > Since commit 46a99c9f73c7 ("s390x/cpumodel: model PTFF subfunctions > for Multiple-epoch facility") -cpu help no longer shows the MSA8 > feature group. Turns out that we forgot to add the new MEPOCH_PTFF > group enum. &g

Re: [Qemu-devel] [qemu-s390x] [PATCH 1/1] s390x/cpumodel: fix feature groups and breakage of MSA8

20.03.18 14:17, Christian Borntraeger wrote: >> David, Jason, Michael, >> >> the cpumodel code is somewhat fragile as we have to add maintain things >> in multiple places. I would like to have more robust code, e.g. by either >> generating more or by having build bug_ons

Re: [Qemu-devel] [PATCH 1/1] s390x/cpumodel: fix feature groups and breakage of MSA8

PM, Christian Borntraeger wrote: > Since commit 46a99c9f73c7 ("s390x/cpumodel: model PTFF subfunctions > for Multiple-epoch facility") -cpu help no longer shows the MSA8 > feature group. Turns out that we forgot to add the new MEPOCH_PTFF > group enum. > > Fixes: 4

[Qemu-devel] [PATCH 1/1] s390x/cpumodel: fix feature groups and breakage of MSA8

Multiple-epoch facility") Signed-off-by: Christian Borntraeger <borntrae...@de.ibm.com> --- target/s390x/cpu_features.h | 1 + 1 file changed, 1 insertion(+) diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h index e306aa7ab2..968b12fdfe 100644 --- a/target/s390x/c

Re: [Qemu-devel] [Qemu-block] [PATCH v1 1/1] iotests: fix test case 185

On 03/19/2018 05:10 PM, Stefan Hajnoczi wrote: > On Mon, Mar 19, 2018 at 9:35 AM, QingFeng Hao > wrote: >> Test case 185 failed since commit 4486e89c219 --- "vl: introduce >> vm_shutdown()". >> It's because of the newly introduced function vm_shutdown calls >>

Re: [Qemu-devel] qemu master build failure

Does it make sense to have something like diff --git a/configure b/configure index 831ebf2..67d7ae3 100755 --- a/configure +++ b/configure @@ -552,6 +552,10 @@ else pwd_is_source_path="n" fi +if test -f $source_path\/qemu-version.h -a $pwd_is_source_path = "n" ; then +error_exit "source

Re: [Qemu-devel] [PULL 7/7] vl: introduce vm_shutdown()

On 03/12/2018 08:05 PM, John Snow wrote: > > > On 03/09/2018 08:19 AM, Stefan Hajnoczi wrote: >> Commit 00d09fdbbae5f7864ce754913efc84c12fdf9f1a ("vl: pause vcpus before >> stopping iothreads") and commit dce8921b2baaf95974af8176406881872067adfa >> ("iothread: Stop threads before main() quits")

Re: [Qemu-devel] [qemu-s390x] [PATCH 1/3] tests/boot-sector: Add magic bytes to s390x boot code header

c in pc-bios/s390-ccw/bootmap.c), so > we've got to add them in our boot code here, too. > > Signed-off-by: Thomas Huth <th...@redhat.com> Reviewed-by: Christian Borntraeger <borntrae...@de.ibm.com> > --- > tests/boot-sector.c | 9 ++--- > 1 file changed, 6 ins

Re: [Qemu-devel] [PATCH] update Linux headers to 4.15

-headers.sh| 2 + > 16 files changed, 918 insertions(+), 417 deletions(-) > create mode 100644 linux-headers/asm-s390/unistd_32.h > create mode 100644 linux-headers/asm-s390/unistd_64.h s390 part look sane. Acked-by: Christian Borntraeger <borntrae...@de.ibm.com&

Re: [Qemu-devel] [PATCH] vnc: deal with surface NULL pointers

ered by switching to an unused > display (via vtrl-alt-) in a multihead setup, for example using > -device virtio-vga,max_outputs=2. > > Cc: Christian Borntraeger <borntrae...@de.ibm.com> > Signed-off-by: Gerd Hoffmann <kra...@redhat.com> > --- Tested-by: Christian Borntra

Re: [Qemu-devel] qemu crashes with vnc and multiple outputs + console redirection

On 03/08/2018 04:26 PM, Gerd Hoffmann wrote: > Hi, > >> I am playing with the virtio-gpu support on s390 and for that I also wanted >> to multiplex >> the existing consoles. >> So I basically used the max_outputs=2 of virtio gpu to be able >> to switch with ctrl+alt+1 and 3 between the

<    3   4   5   6   7   8   9   10   11   12   >