Re: [Qemu-devel] [PATCH 3/5] s390x/ipl: Load network boot image

Hi Thomas, Thanks for the review. On 02/20/2017 10:28 AM, Thomas Huth wrote: On 20.02.2017 15:19, Cornelia Huck wrote: From: Farhan Ali <al...@linux.vnet.ibm.com> Load the network boot image into guest RAM when the boot device selected is a network device. Use some of the reserved

Re: [Qemu-devel] [PATCH 3/5] s390x/ipl: Load network boot image

On 02/24/2017 05:11 AM, Thomas Huth wrote: On 22.02.2017 16:01, Farhan Ali wrote: Hi Thomas, Thanks for the review. On 02/20/2017 10:28 AM, Thomas Huth wrote: On 20.02.2017 15:19, Cornelia Huck wrote: From: Farhan Ali <al...@linux.vnet.ibm.com> [...] +} + +r

Re: [Qemu-devel] [PATCH 1/5] elf-loader: Allow late loading of elf

On 02/24/2017 05:44 AM, Thomas Huth wrote: On 21.02.2017 11:23, Christian Borntraeger wrote: On 02/20/2017 04:33 PM, Thomas Huth wrote: On 20.02.2017 15:19, Cornelia Huck wrote: From: Farhan Ali <al...@linux.vnet.ibm.com> The current QEMU ROM infrastructure rejects late loading o

Re: [Qemu-devel] [PATCH for-2.8 0/3] virtio fixes

to solve the issue. Tested-by : Farhan Ali <al...@linux.vnet.ibm.com> Thank you Farhan On 11/16/2016 02:50 PM, Christian Borntraeger wrote: On 11/15/2016 02:46 PM, Paolo Bonzini wrote: Patch 1 fixes vhost, patches 2-3 fix Windows hibernation. Paolo Paolo Bonzini (3): virtio: introduc

Re: [Qemu-devel] [PATCH for-2.8 0/3] virtio fixes

On 11/16/2016 03:16 PM, Michael S. Tsirkin wrote: On Wed, Nov 16, 2016 at 03:03:13PM -0500, Farhan Ali wrote: Hi Paolo, I was able to test your patches in our s390 environment. I don't see the qemu crashes anymore which I noticed before. Testing a guest running high stress I/O workload

Re: [Qemu-devel] [PATCH for-2.8 0/3] virtio fixes

On 11/16/2016 03:32 PM, Farhan Ali wrote: On 11/16/2016 03:16 PM, Michael S. Tsirkin wrote: On Wed, Nov 16, 2016 at 03:03:13PM -0500, Farhan Ali wrote: Hi Paolo, I was able to test your patches in our s390 environment. I don't see the qemu crashes anymore which I noticed before

Re: [Qemu-devel] [RFC PATCH v2 1/8] pc-bios/s390-ccw: Move libc functions to separate header

w.h" #include "virtio.h" #include "scsi.h" diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c index 6ee93d5..8768331 100644 --- a/pc-bios/s390-ccw/virtio.c +++ b/pc-bios/s390-ccw/virtio.c @@ -8,6 +8,7 @@ * directory. */ +#include "libc.h" #include "s390-ccw.h" #include "virtio.h" #include "virtio-scsi.h" Reviewed-by: Farhan Ali <al...@linux.vnet.ibm.com>

Re: [Qemu-devel] [RFC PATCH v2 2/8] pc-bios/s390-ccw: Move ebc2asc to sclp.c

On 07/07/2017 06:26 AM, Thomas Huth wrote: We will later need this array in a file that we will link to the netboot code, too. Since there is some ebcdic convertion done in sclp_get_loadparm_ascii(), the sclp.c file seems to be a good candidate. s/convertion/conversion Signed-off-by:

Re: [Qemu-devel] [RFC PATCH 00/14] Implement network booting directly into the s390-ccw BIOS

Hi Thomas, This is really interesting :) On 06/27/2017 07:48 AM, Thomas Huth wrote: It's already possible to do a network boot of an s390x guest with an external netboot image (based on a Linux installation), but it would be much more convenient if the s390-ccw firmware supported network

Re: [Qemu-devel] [PATCH v2 2/2] virtio-gpu-ccw: Create a virtio gpu device for the ccw bus

On 09/15/2017 03:40 AM, Thomas Huth wrote: On 14.09.2017 17:55, Farhan Ali wrote: Wire up the virtio-gpu device for the CCW bus. The virtio-gpu is a virtio-1 device, so disable revision 0. Signed-off-by: Farhan Ali <al...@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <

Re: [Qemu-devel] [PATCH v2 1/2] virtio-gpu: Handle endian conversion

On 09/15/2017 03:31 AM, Gerd Hoffmann wrote: Hi, +static void +virtio_gpu_ctrl_hdr_bswap_cpu(struct virtio_gpu_ctrl_hdr *hdr) +{ +hdr->type = le32_to_cpu(hdr->type); +hdr->flags = le32_to_cpu(hdr->flags); +hdr->fence_id = le64_to_cpu(hdr->fence_id); +hdr->ctx_id =

Re: [Qemu-devel] [PATCH v1 1/2] virtio_gpu: Handle endian conversion

On 09/13/2017 04:13 AM, Gerd Hoffmann wrote: Please move this to a helper function, maybe by updating the VIRTIO_GPU_FILL_CMD macro. The header fields should be byteswapped too. As most structs have 32bit fields only (with the exception of hdr.fence_id) you should be able to create a generic

[Qemu-devel] [PATCH v3 1/2] virtio-gpu: Handle endian conversion

Virtio GPU code currently only supports litte endian format, and so using the Virtio GPU device on a big endian machine does not work. Let's fix it by supporting the correct host cpu byte order. Signed-off-by: Farhan Ali <al...@linux.vnet.ibm.com> --- hw/display/virtio-gpu.

[Qemu-devel] [PATCH v3 0/2] Virtio GPU for S390

endian conversion for cursor update (patch 1) Thank you Farhan Farhan Ali (2): virtio-gpu: Handle endian conversion virtio-gpu-ccw: Create a virtio gpu device for the ccw bus hw/display/virtio-gpu.c | 70 +++-- hw/s390x/virtio-ccw.c

[Qemu-devel] [PATCH v3 2/2] virtio-gpu-ccw: Create a virtio gpu device for the ccw bus

Wire up the virtio-gpu device for the CCW bus. The virtio-gpu is a virtio-1 device, so disable revision 0. Signed-off-by: Farhan Ali <al...@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-b

Re: [Qemu-devel] [PATCH v1 0/2] Virtio GPU for S390

On 09/13/2017 03:00 PM, Thomas Huth wrote: On 12.09.2017 16:26, Farhan Ali wrote: These patches wire up the virtio-gpu device for CCW bus for S390. For the S390 architecture which does not natively support any graphics device, virtio gpu in 2D mode could be used to emulate a simple graphics

[Qemu-devel] [PATCH v2 2/2] virtio-gpu-ccw: Create a virtio gpu device for the ccw bus

Wire up the virtio-gpu device for the CCW bus. The virtio-gpu is a virtio-1 device, so disable revision 0. Signed-off-by: Farhan Ali <al...@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/

[Qemu-devel] [PATCH v2 1/2] virtio-gpu: Handle endian conversion

Virtio GPU code currently only supports litte endian format, and so using the Virtio GPU device on a big endian machine does not work. Let's fix it by supporting the correct host cpu byte order. Signed-off-by: Farhan Ali <al...@linux.vnet.ibm.com> --- hw/display/virtio-gpu.

[Qemu-devel] [PATCH v2 0/2] Virtio GPU for S390

ove error_propagate (patch 2) - Add byteswap functions (patch 1) - Handle endian conversion for virtio_gpu_ctrl_response (patch 1) Thank you Farhan Farhan Ali (2): virtio-gpu: Handle endian conversion virtio-gpu-ccw: Create a virtio gpu device for the ccw bus hw/display/virtio-gpu.c |

Re: [Qemu-devel] [PATCH v3 1/2] virtio-gpu: Handle endian conversion

On 09/18/2017 06:32 AM, Gerd Hoffmann wrote: On Fri, 2017-09-15 at 10:40 -0400, Farhan Ali wrote: Virtio GPU code currently only supports litte endian format, and so using the Virtio GPU device on a big endian machine does not work. Let's fix it by supporting the correct host cpu byte order

Re: [Qemu-devel] [PATCH v3 0/2] Virtio GPU for S390

On 09/18/2017 08:29 AM, Cornelia Huck wrote: On Fri, 15 Sep 2017 10:40:30 -0400 Farhan Ali <al...@linux.vnet.ibm.com> wrote: These patches wire up the virtio-gpu device for CCW bus for S390. For the S390 architecture which does not natively support any graphics device, virtio gpu in 2

Re: [Qemu-devel] [PATCH] hw/s390x/sclp: Mark the sclp device with user_creatable = false

gt;read_SCP_info = read_SCP_info; sc->read_storage_element0_info = read_storage_element0_info; Reviewed-by: Farhan Ali <al...@linux.vnet.ibm.com>

[Qemu-devel] [PATCH v1 1/1] virtio-ccw: Add the virtio-input devices for CCW bus

Wire up the virtio-input HID devices (keyboard, mouse, tablet) for the CCW bus. The virtio-input is a virtio-1 device, so disable legacy revision 0. Signed-off-by: Farhan Ali <al...@linux.vnet.ibm.com> Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com> Reviewed-by: Christian

[Qemu-devel] [PATCH v1 1/2] virtio_gpu: Handle endian conversion

Virtio GPU code currently only supports litte endian format, and so using the Virtio GPU device on a big endian machine does not work. Let's fix it by supporting the correct host cpu byte order. Signed-off-by: Farhan Ali <al...@linux.vnet.ibm.com> --- hw/display/virtio-gpu.

[Qemu-devel] [PATCH v1 2/2] virtio-gpu-ccw: Create a virtio gpu device for the ccw bus

Wire up the virtio-gpu device for the CCW bus. The virtio-gpu is a virtio-1 device, so disable revision 0. Signed-off-by: Farhan Ali <al...@linux.vnet.ibm.com> Acked-by: Christian Borntraeger <borntrae...@de.ibm.com> --- hw/s390x/virti

[Qemu-devel] [PATCH v1 0/2] Virtio GPU for S390

,devno=fe.0.0101 -vnc host_ip_addr:5900 Note, to actually see any display content the guest kernel needs to support DRM layer, Virtio GPU driver, the Virtual Terminal layer etc. I would appreciate any feedback on these patches, specially the first patch. Thank you Farhan Farhan Ali (2

Re: [Qemu-devel] S390 bios breaks in qemu 2.10.rc3

On 08/24/2017 11:50 AM, Thomas Huth wrote: On 24.08.2017 17:47, Halil Pasic wrote: On 08/24/2017 05:35 PM, Thomas Huth wrote: On 24.08.2017 17:13, Cornelia Huck wrote: On Thu, 24 Aug 2017 11:05:08 -0400 Farhan Ali <al...@linux.vnet.ibm.com> wrote: Hi, There is an issue in QEM

[Qemu-devel] S390 bios breaks in qemu 2.10.rc3

Hi, There is an issue in QEMU bios which is exposed by commit commit 198c0d1f9df8c429502cb744fc26b6ba6e71db74 Author: Halil Pasic Date: Thu Jul 27 17:48:42 2017 +0200 s390x/css: check ccw address validity According to the PoP channel command words (CCW)

Re: [Qemu-devel] S390 bios breaks in qemu 2.10.rc3

On 08/24/2017 12:07 PM, Peter Maydell wrote: On 24 August 2017 at 16:53, Farhan Ali <al...@linux.vnet.ibm.com> wrote: On 08/24/2017 11:50 AM, Thomas Huth wrote: True, so that could still be an issue. Looking at the cio.h in the kernel, they define the struct like this: struc

Re: [Qemu-devel] S390 bios breaks in qemu 2.10.rc3

. On 08/24/2017 05:05 PM, Farhan Ali wrote: Hi, There is an issue in QEMU bios which is exposed by commit commit 198c0d1f9df8c429502cb744fc26b6ba6e71db74 Author: Halil Pasic <pa...@linux.vnet.ibm.com> Date: Thu Jul 27 17:48:42 2017 +0200 s390x/css: check ccw address va

Re: [Qemu-devel] [PATCH] s390-ccw: Fix alignment for CCW1

On 08/28/2017 09:06 AM, Cornelia Huck wrote: On Mon, 28 Aug 2017 08:56:42 -0400 Farhan Ali <al...@linux.vnet.ibm.com> wrote: On 08/28/2017 04:22 AM, Cornelia Huck wrote: On Fri, 25 Aug 2017 11:05:30 -0400 Farhan Ali <al...@linux.vnet.ibm.com> wrote: On 08/25/2017 10:04 AM, C

Re: [Qemu-devel] [PATCH] s390-ccw: Fix alignment for CCW1

On 08/28/2017 09:24 AM, Christian Borntraeger wrote: On 08/28/2017 03:18 PM, Farhan Ali wrote: On 08/28/2017 09:06 AM, Cornelia Huck wrote: On Mon, 28 Aug 2017 08:56:42 -0400 Farhan Ali <al...@linux.vnet.ibm.com> wrote: On 08/28/2017 04:22 AM, Cornelia Huck wrote: On Fri, 25 Au

Re: [Qemu-devel] [PATCH] s390-ccw: Fix alignment for CCW1

On 08/28/2017 10:05 AM, Cornelia Huck wrote: It's the alignment of the CCW which causes the problem. The exact error message when starting the guest was: ! No virtio device found ! Since it worked for SCSI and CDL, and failed for LDL disks on that particular system, we are not really sure

Re: [Qemu-devel] [PATCH] s390-ccw: Fix alignment for CCW1

On 08/28/2017 10:19 AM, Halil Pasic wrote: On 08/28/2017 04:15 PM, Farhan Ali wrote: On 08/28/2017 10:05 AM, Cornelia Huck wrote: It's the alignment of the CCW which causes the problem. The exact error message when starting the guest was: ! No virtio device found ! Since it worked

Re: [Qemu-devel] [PATCH] s390-ccw: Fix alignment for CCW1

On 08/28/2017 04:22 AM, Cornelia Huck wrote: On Fri, 25 Aug 2017 11:05:30 -0400 Farhan Ali <al...@linux.vnet.ibm.com> wrote: On 08/25/2017 10:04 AM, Cornelia Huck wrote: On Fri, 25 Aug 2017 09:24:46 -0400 Farhan Ali <al...@linux.vnet.ibm.com> wrote: The commit 198c0d1f9df8

Re: [Qemu-devel] [PATCH] s390-ccw: Fix alignment for CCW1

Hi Phil, On 08/28/2017 11:04 AM, Philippe Mathieu-Daudé wrote: Can you provide the link script used in both systems? See on the previous thread:

[Qemu-devel] [PATCH] s390-ccw: Fix alignment for CCW1

The commit 198c0d1f9df8c4 s390x/css: check ccw address validity exposes an alignment issue in ccw bios. According to PoP the CCW must be doubleword aligned. Let's fix this in the bios. Cc: qemu-sta...@nongnu.org Signed-off-by: Farhan Ali <al...@linux.vnet.ibm.com> Reviewed-by: Halil Pas

Re: [Qemu-devel] [PATCH] s390-ccw: Fix alignment for CCW1

On 08/25/2017 10:04 AM, Cornelia Huck wrote: On Fri, 25 Aug 2017 09:24:46 -0400 Farhan Ali <al...@linux.vnet.ibm.com> wrote: The commit 198c0d1f9df8c4 s390x/css: check ccw address validity exposes an alignment issue in ccw bios. According to PoP the CCW must be doubleword aligned. Let

Re: [Qemu-devel] [PATCH] s390-ccw: Fix alignment for CCW1

On 08/29/2017 08:04 AM, Cornelia Huck wrote: On Mon, 28 Aug 2017 10:28:53 -0400 Farhan Ali <al...@linux.vnet.ibm.com> wrote: On 08/28/2017 10:19 AM, Halil Pasic wrote: On 08/28/2017 04:15 PM, Farhan Ali wrote: On 08/28/2017 10:05 AM, Cornelia Huck wrote: It's the alignment of t

Re: [Qemu-devel] [PATCH v2 4/5] s390-ccw: interactive boot menu for eckd dasd

On 12/11/2017 05:19 PM, Collin L. Walling wrote: When the boot menu options are present and the guest's disk has been configured by the zipl tool, then the user will be presented with an interactive boot menu with labeled entries. An example of what the menu might look like: zIPL

[Qemu-devel] [RFC v1 1/2] crypto/virtio-crypto: Read crypto services and algorithm masks

Read the crypto services and algorithm masks which provides information about the services and algorithms supported by virtio-crypto backend. Signed-off-by: Farhan Ali --- drivers/crypto/virtio/virtio_crypto_common.h | 14 ++ drivers/crypto/virtio/virtio_crypto_core.c | 29

[Qemu-devel] [RFC v1 0/2] Detect & register virtio-crypto algos only if it can be supported by backend

. This also makes the driver more compliant with the virtio-crypto spec [1]. I would appreciate any feedback or comments on this. Thank you Farhan Reference - [1] Virtio crypto spec proposal https://lists.gnu.org/archive/html/qemu-devel/2017-12/msg00816.html Farhan Ali (2): crypto/virtio

[Qemu-devel] [RFC v1 2/2] crypto/virtio-crypto: Register an algo only if it's supported

From: Farhan Ali Register a crypto algo with the Linux crypto layer only if the algorithm is supported by the backend virtio-crypto device. Also route crypto requests to a virtio-crypto device, only if it can support the requested service and algorithm. Signed-off-by: Farhan Ali --- drivers

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

adds support for disabling the cipher algorithms of the backend cryptodev. eg: -object cryptodev-backend-builtin,id=cryptodev0 -device virtio-crypto-ccw,id=crypto0,cryptodev=cryptodev0,cipher-aes-cbc=off Signed-off-by: Farhan Ali --- Please note this patch is not complete, and there are TODOs

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

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 to the guest all the cipher algorithms that the backend cryptodev can support. But in certain cases where the guest has more

[Qemu-devel] [PATCH v2 1/2] crypto/virtio-crypto: Read crypto services and algorithm masks

Read the crypto services and algorithm masks which provides information about the services and algorithms supported by virtio-crypto backend. Signed-off-by: Farhan Ali Acked-by: Gonglei --- drivers/crypto/virtio/virtio_crypto_common.h | 14 ++ drivers/crypto/virtio

[Qemu-devel] [PATCH v2 2/2] crypto/virtio-crypto: Register an algo only if it's supported

From: Farhan Ali Register a crypto algo with the Linux crypto layer only if the algorithm is supported by the backend virtio-crypto device. Also route crypto requests to a virtio-crypto device, only if it can support the requested service and algorithm. Signed-off-by: Farhan Ali Acked

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

v2 - Modify comment as suggested by Arei (patch 1) - Modify error message as suggested by Arei (patch 2) Farhan Ali (2): crypto/virtio-crypto: Read crypto services and algorithm masks crypto/virtio-crypto: Register an algo only if it's supported drivers/crypto/virtio/virtio_crypto_algs.c |

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

Hi Arei On 06/12/2018 08:57 PM, Gonglei (Arei) wrote: -Original Message- From: Farhan Ali [mailto:al...@linux.ibm.com] Sent: Wednesday, June 13, 2018 3:49 AM To: qemu-devel@nongnu.org Cc: m...@redhat.com; Gonglei (Arei) ; longpeng ; pa...@linux.ibm.com; borntrae...@de.ibm.com; fran

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

On 06/14/2018 04:21 AM, Daniel P. Berrangé wrote: On Wed, Jun 13, 2018 at 07:28:08PM +0200, Halil Pasic wrote: 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

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

On 06/14/2018 11:10 AM, Daniel P. Berrangé wrote: On Thu, Jun 14, 2018 at 10:50:40AM -0400, Farhan Ali wrote: On 06/14/2018 04:21 AM, Daniel P. Berrangé wrote: On Wed, Jun 13, 2018 at 07:28:08PM +0200, Halil Pasic wrote: On 06/13/2018 05:05 PM, Daniel P. Berrangé wrote: On Wed, Jun 13

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

On 06/15/2018 09:17 AM, Viktor VM Mihajlovski wrote: On 14.06.2018 18:12, Farhan Ali wrote: On 06/14/2018 11:10 AM, Daniel P. Berrangé wrote: On Thu, Jun 14, 2018 at 10:50:40AM -0400, Farhan Ali wrote: On 06/14/2018 04:21 AM, Daniel P. Berrangé wrote: On Wed, Jun 13, 2018 at 07:28

[Qemu-devel] [PATCH v3 2/2] crypto/virtio-crypto: Register an algo only if it's supported

From: Farhan Ali Register a crypto algo with the Linux crypto layer only if the algorithm is supported by the backend virtio-crypto device. Also route crypto requests to a virtio-crypto device, only if it can support the requested service and algorithm. Signed-off-by: Farhan Ali Acked

[Qemu-devel] [PATCH v3 1/2] crypto/virtio-crypto: Read crypto services and algorithm masks

Read the crypto services and algorithm masks which provides information about the services and algorithms supported by virtio-crypto backend. Signed-off-by: Farhan Ali Acked-by: Gonglei Acked-by: Christian Borntraeger --- drivers/crypto/virtio/virtio_crypto_common.h | 14

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

v3 - Add Christian Borntrager's acks for the patches. v1 -> v2 - Modify comment as suggested by Arei (patch 1) - Modify error message as suggested by Arei (patch 2) Farhan Ali (2): crypto/virtio-crypto: Read crypto services and algorithm masks crypto/virtio-crypto: Register an algo only i

Re: [Qemu-devel] [RFC v1 1/2] crypto/virtio-crypto: Read crypto services and algorithm masks

Hi Arei On 06/11/2018 02:43 AM, Gonglei (Arei) wrote: -Original Message- From: Farhan Ali [mailto:al...@linux.ibm.com] Sent: Saturday, June 09, 2018 3:09 AM To: linux-ker...@vger.kernel.org; k...@vger.kernel.org Cc: m...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei) ; longpeng

Re: [Qemu-devel] [RFC v1 2/2] crypto/virtio-crypto: Register an algo only if it's supported

On 06/11/2018 04:48 AM, Gonglei (Arei) wrote: -Original Message- From: Farhan Ali [mailto:al...@linux.ibm.com] Sent: Saturday, June 09, 2018 3:09 AM To: linux-ker...@vger.kernel.org; k...@vger.kernel.org Cc: m...@redhat.com; qemu-devel@nongnu.org; Gonglei (Arei) ; longpeng ; pa

Re: [Qemu-devel] [PATCH] pc-bios/s390-ccw: define loadparm length

pc-bios/s390-ccw/sclp.c | 2 +- pc-bios/s390-ccw/sclp.h | 2 +- 4 files changed, 9 insertions(+), 7 deletions(-) Reviewed-by: Farhan Ali

Re: [Qemu-devel] [PATCH 2/3] pc-bios/s390-ccw/net: Add support for pxelinux-style config files

On 05/30/2018 05:16 AM, Thomas Huth wrote: Since it is quite cumbersome to manually create a combined kernel with initrd image for network booting, we now support loading via pxelinux configuration files, too. In these files, the kernel, initrd and command line parameters can be specified

Re: [Qemu-devel] [PATCH 2/3] pc-bios/s390-ccw/net: Add support for pxelinux-style config files

On 05/31/2018 11:21 PM, Thomas Huth wrote: Just a question do we want to clear cfgbuf here, before calling pxelinux_load_parse_cfg? That's theoretically not necessary. The buffer either gets populated with data, or the function errors out. The code also makes sure that there is a final

Re: [Qemu-devel] [PATCH 3/3] pc-bios/s390-ccw/net: Try to load pxelinux.cfg file accoring to the UUID

Reviewed-by: Farhan Ali

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

Polite ping :) Would like to know how to merge these patches in the mainline kernel. Thanks Farhan On 06/19/2018 11:41 AM, Farhan Ali wrote: Hi, Currently the Linux virtio-crypto driver registers the crypto algorithm without verifying if the backend actually supports the algorithm

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

A polite ping :) If no one has any more comments/feedback then I would like to how to merge these patches to the mainline kernel tree. Thanks Farhan On 06/13/2018 04:38 PM, Farhan Ali wrote: Hi, Currently the Linux virtio-crypto driver registers the crypto algorithm without verifying

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

On 06/19/2018 10:32 AM, Herbert Xu wrote: On Tue, Jun 19, 2018 at 04:08:05PM +0200, Christian Borntraeger wrote: On 06/19/2018 03:26 PM, Farhan Ali wrote: A polite ping :) If no one has any more comments/feedback then I would like to how to merge these patches to the mainline kernel tree

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

On 05/02/2018 08:52 AM, Cornelia Huck wrote: We currently pass an integer as the subcode parameter. However, the upper bits of the register containing the subcode need to be 0, which is not guaranteed unless we explicitly specify the subcode to be an unsigned long value. Fixes: d046c51dad3

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

On 05/03/2018 11:48 AM, Eric Blake wrote: On 05/03/2018 10:25 AM, Farhan Ali wrote: On 05/02/2018 08:52 AM, Cornelia Huck wrote: We currently pass an integer as the subcode parameter. However, the upper bits of the register containing the subcode need to be 0, which is not guaranteed unless

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

On 05/03/2018 11:44 AM, Cornelia Huck wrote: On Thu, 3 May 2018 11:25:08 -0400 Farhan Ali <al...@linux.ibm.com> wrote: On 05/02/2018 08:52 AM, Cornelia Huck wrote: We currently pass an integer as the subcode parameter. However, the upper bits of the register containing the subcod

Re: [Qemu-devel] [PATCH] s390-ccw: print carriage return with new lines

On 10/20/2017 07:02 AM, Christian Borntraeger wrote: --- a/pc-bios/s390-ccw/sclp.c +++ b/pc-bios/s390-ccw/sclp.c @@ -83,7 +83,7 @@ long write(int fd, const void *str, size_t len) return -EIO; } -for (p = str; *p; ++p) { +for (p = str; len ; ++p, len--) { if

Re: [Qemu-devel] [PATCH v4] s390-ccw: print carriage return with new lines

_NORMAL_WRITE; -sccb->ebh.length = sizeof(EventBufferHeader) + len; +sccb->ebh.length = sizeof(EventBufferHeader) + data_len; sccb->ebh.type = SCLP_EVENT_ASCII_CONSOLE_DATA; sccb->ebh.flags = 0; -memcpy(sccb->data, str, len); sclp_service_call(SCLP_CMD_WRITE_EVENT_DATA, sccb); Reviewed-by: Farhan Ali <al...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH 05/11] virtio-ccw: convert VirtIOCCWDeviceClass::init -> realize

On 01/16/2018 09:07 AM, Philippe Mathieu-Daudé wrote: On 01/16/2018 10:41 AM, Farhan Ali wrote: shouldn't the commit message say exit -> unrealize? Oops, indeed :| Thanks :) Phil. Sure, you are welcome :) With the change in commit message, the patch looks good to me: Revie

Re: [Qemu-devel] [PATCH 05/11] virtio-ccw: convert VirtIOCCWDeviceClass::init -> realize

shouldn't the commit message say exit -> unrealize? Thanks Farhan On 01/16/2018 08:15 AM, Philippe Mathieu-Daudé wrote: Signed-off-by: Philippe Mathieu-Daudé --- hw/s390x/virtio-ccw.h | 2 +- hw/s390x/virtio-ccw.c | 35 +-- 2 files

[Qemu-devel] QEMU on s390 segfaults with co-routine error

Hi, I have noticed a QEMU crash with one of my tests. And the qemu log file states the guest crashed with the following error message: aio_co_schedule: Co-routine was already scheduled in 'aio_co_schedule' Investigating a little more, it looks like the error message was introduced by the

Re: [Qemu-devel] [Qemu-block] [PATCH] block/file-posix: add bdrv_attach_aio_context callback for host dev and cdrom

On 07/27/2018 09:26 AM, Stefan Hajnoczi wrote: On Mon, Jul 23, 2018 at 12:42:02PM -0400, Farhan Ali wrote: On 07/23/2018 12:30 PM, Stefan Hajnoczi wrote: On Fri, Jul 20, 2018 at 03:11:14PM -0400, Farhan Ali wrote: I am seeing another issue pop up, in a different test. Even though it's

Re: [Qemu-devel] [PATCH] block/file-posix: add bdrv_attach_aio_context callback for host dev and cdrom

ted driver definitions. Fixes: ed6e2161 ("linux-aio: properly bubble up errors from initialization") Reported-by: Farhan Ali Signed-off-by: Nishanth Aravamudan Cc: Eric Blake Cc: Kevin Wolf Cc: John Snow Cc: Max Reitz Cc: Stefan Hajnoczi Cc: Fam Zheng Cc: Paolo Bonzini Cc: qemu-bl...

Re: [Qemu-devel] [PATCH] block/file-posix: add bdrv_attach_aio_context callback for host dev and cdrom

On 07/20/2018 03:32 PM, Nishanth Aravamudan wrote: On 20.07.2018 [15:11:14 -0400], Farhan Ali wrote: I am seeing another issue pop up, in a different test. Even though it's a different assertion, it might be related based on the call trace. Just to be clear, this does not happen if you

[Qemu-devel] [BUG?] aio_get_linux_aio: Assertion `ctx->linux_aio' failed

Hi, I am seeing some strange QEMU assertion failures for qemu on s390x, which prevents a guest from starting. Git bisecting points to the following commit as the source of the error. commit ed6e2161715c527330f936d44af4c547f25f687e Author: Nishanth Aravamudan Date: Fri Jun 22 12:37:00 2018

Re: [Qemu-devel] [BUG?] aio_get_linux_aio: Assertion `ctx->linux_aio' failed

On 07/18/2018 09:42 AM, Farhan Ali wrote: On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: iiuc, this possibly implies AIO was not actually used previously on this guest (it might have silently been falling back to threaded IO?). I don't have access to s390x, but would it be possible

Re: [Qemu-devel] [PATCH] block/file-posix: add bdrv_attach_aio_context callback for host dev and cdrom

On 07/23/2018 12:30 PM, Stefan Hajnoczi wrote: On Fri, Jul 20, 2018 at 03:11:14PM -0400, Farhan Ali wrote: I am seeing another issue pop up, in a different test. Even though it's a different assertion, it might be related based on the call trace. Which test case? This test case involved

Re: [Qemu-devel] [PATCH] block/file-posix: add bdrv_attach_aio_context callback for host dev and cdrom

On 07/20/2018 03:11 PM, Farhan Ali wrote: I am seeing another issue pop up, in a different test. Even though it's a different assertion, it might be related based on the call trace. Stack trace of thread 276199: #0  0x03ff8473e274 raise (libc.so.6) #1  0x03ff847239a8 abort (libc.so

Re: [Qemu-devel] [BUG?] aio_get_linux_aio: Assertion `ctx->linux_aio' failed

On 07/17/2018 04:52 PM, Nishanth Aravamudan wrote: iiuc, this possibly implies AIO was not actually used previously on this guest (it might have silently been falling back to threaded IO?). I don't have access to s390x, but would it be possible to run qemu under gdb and see if

Re: [Qemu-devel] [PATCH] hw/s390x/ipl: Bail out if the network bootloader can not be found

On 02/27/2018 05:16 AM, Viktor Mihajlovski wrote: On 27.02.2018 11:05, Thomas Huth wrote: If QEMU fails to load 's390-netboot.img', the guest firmware currently loops forever and just floods the console with "Network boot device detected" messages. The code in ipl.c apparently already tried

[Qemu-devel] [BUG] I/O thread segfault for QEMU on s390x

Hi, I have been noticing some segfaults for QEMU on s390x, and I have been hitting this issue quite reliably (at least once in 10 runs of a test case). The qemu version is 2.11.50, and I have systemd created coredumps when this happens. Here is a back trace of the segfaulting thread: #0

Re: [Qemu-devel] [BUG] I/O thread segfault for QEMU on s390x

On 03/06/2018 01:34 AM, Martin Schwidefsky wrote: On Mon, 5 Mar 2018 20:08:45 +0100 Christian Borntraeger wrote: Do you happen to run with a recent host kernel that has commit 7041d28115e91f2144f811ffe8a195c696b1e1d0 s390: scrub registers on kernel entry and

Re: [Qemu-devel] [PATCH 1/3] s390: Refactor IPL parameter block generation

rtions(+), 30 deletions(-) Reviewed-by: Farhan Ali <al...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH 2/3] s390: Ensure IPL from SCSI works as expected

T); } This does feel a little hackish, but I can't think of a better way to ensure the correct SCSI device is used for booting. Reviewed-by: Farhan Ali <al...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH 2/4] pc-bios/s390-ccw: fix loadparm initialization and int conversion

On 04/12/2018 04:57 PM, Collin Walling wrote: On 04/12/2018 02:57 PM, Thomas Huth wrote: On 10.04.2018 17:01, Collin Walling wrote: Rename the loadparm char array in main.c to loadparm_str and increase the size by one byte to account for a null termination when converting the loadparm string

Re: [Qemu-devel] [PATCH v1 for-2.13 0/4] pc-bios/s390-ccw: Network boot improvements

On 04/18/2018 08:31 AM, Thomas Huth wrote: Some patches to improve the network boot experience on s390x: First, make sure that we shut down the virtio-net device before jumping into the kernel. Otherwise some incoming packets might destroy some of the kernel's data if it has not taken over

Re: [Qemu-devel] [PATCH v1 for-2.13 1/4] pc-bios/s390-ccw/net: Split up net_load() into init, load and uninit parts

On 04/18/2018 08:31 AM, Thomas Huth wrote: When we want to support pxelinux-style network booting later, we've got to do several TFTP transfers - and we do not want to apply for a new IP address via DHCP each time. So split up net_load into three parts: 1. net_init(), which initializes

Re: [Qemu-devel] [qemu-s390x] [PATCH v1 for-2.13 0/4] pc-bios/s390-ccw: Network boot improvements

On 04/19/2018 01:27 AM, Thomas Huth wrote: Ah, that's not a memory leak, though it might look like one if you don't know what the vring_send_buf function is doing: vring_send_buf adds a buffer to a virtio ring for later use. So the buffer is not unused after this function, but gets filled in

Re: [Qemu-devel] [PATCH v3 1/3] pc-bios/s390-ccw/net: Split up net_load() into init, load and uninit parts

On 04/25/2018 05:08 AM, Thomas Huth wrote: When we want to support pxelinux-style network booting later, we've got to do several TFTP transfers - and we do not want to apply for a new IP address via DHCP each time. So split up net_load into three parts: 1. net_init(), which initializes

Re: [Qemu-devel] [BUG] I/O thread segfault for QEMU on s390x

On 03/05/2018 06:03 AM, Stefan Hajnoczi wrote: Please include the following gdb output: (gdb) disas swapcontext (gdb) i r That way it's possible to see which instruction faulted and which registers were being accessed. here is the disas out for swapcontext, this is on a coredump

Re: [Qemu-devel] [BUG] I/O thread segfault for QEMU on s390x

. On 03/05/2018 07:54 PM, Christian Borntraeger wrote: On 03/05/2018 07:45 PM, Farhan Ali wrote: On 03/05/2018 06:03 AM, Stefan Hajnoczi wrote: Please include the following gdb output:    (gdb) disas swapcontext    (gdb) i r That way it's possible to see which instruction faulted

Re: [Qemu-devel] [BUG] I/O thread segfault for QEMU on s390x

On 03/02/2018 04:23 AM, Stefan Hajnoczi wrote: On Thu, Mar 01, 2018 at 09:33:35AM -0500, Farhan Ali wrote: Hi, I have been noticing some segfaults for QEMU on s390x, and I have been hitting this issue quite reliably (at least once in 10 runs of a test case). The qemu version is 2.11.50

Re: [Qemu-devel] [BUG] I/O thread segfault for QEMU on s390x

On 03/02/2018 01:13 AM, Fam Zheng wrote: On Thu, Mar 1, 2018 at 10:33 PM, Farhan Ali <al...@linux.vnet.ibm.com> wrote: Hi, I have been noticing some segfaults for QEMU on s390x, and I have been hitting this issue quite reliably (at least once in 10 runs of a test case). The qemu v

Re: [Qemu-devel] [PATCH] hw/s390x/ipl: Bail out if the network bootloader can not be found

On 02/27/2018 02:11 PM, Thomas Huth wrote: On 27.02.2018 18:26, Farhan Ali wrote: On 02/27/2018 05:16 AM, Viktor Mihajlovski wrote: On 27.02.2018 11:05, Thomas Huth wrote: If QEMU fails to load 's390-netboot.img', the guest firmware currently loops forever and just floods the console

[Qemu-devel] [RFC v1 1/1] qemu-iotests: Fix output for testcase 082

Commit 9cbef9d68ee: qemu-option: improve qemu_opts_print_help() output, changed some of the output for qemu-img tool but did not update the corresponding 082 test case file. This broke qemu-iotests. Signed-off-by: Farhan Ali --- tests/qemu-iotests/082.out | 956

Re: [Qemu-devel] [RFC v1 1/1] qemu-iotests: Fix output for testcase 082

On 10/15/2018 11:45 AM, Max Reitz wrote: 082 is failing for me on master (046936ed), and this fixes it. I'm wondering if/why other people are not running into this, as 082 runs with qcow2 and is included on `make check-block`. + Max, FIY, I ran into this while reviewing/testing your Python

Re: [Qemu-devel] [PATCH 1/4] MAINTAINERS: s390: more maintainers for vfio-ccw

+++ b/MAINTAINERS @@ -1204,6 +1204,8 @@ F: include/hw/vfio/ vfio-ccw M: Cornelia Huck +M: Eric Farman +M: Farhan Ali S: Supported F: hw/vfio/ccw.c F: hw/s390x/s390-ccw.c Acked-by: Farhan Ali

Re: [Qemu-devel] [PATCH 02/15] s390-bios: decouple cio setup from virtio

); sclp_print(ldp); @@ -168,6 +173,7 @@ static void virtio_setup(void) int main(void) { sclp_setup(); +css_setup(); virtio_setup(); zipl_load(); /* no return */ Reviewed-by: Farhan Ali

Re: [Qemu-devel] [PATCH 03/15] s390-bios: decouple common boot logic from virtio

if (store_iplb()) { +if (have_iplb) { switch (iplb.pbt) { case S390_IPL_TYPE_CCW: dev_no = iplb.ccw.devno; @@ -174,6 +185,7 @@ int main(void) { sclp_setup(); css_setup(); +boot_setup(); virtio_setup(); zipl_load(); /* no return */ Reviewed-by: Farhan Ali

  1   2   >