[Qemu-devel] [PATCH v2 2/4] s390x/css: use ccw data stream

Replace direct access which implicitly assumes no IDA or MIDA with the new ccw data stream interface which should cope with these transparently in the future. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/css.c | 9 + 1 file changed, 5 insertions(+), 4 del

[Qemu-devel] [PATCH v2 1/4] s390x/css: introduce css data stream

-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/css.c | 55 + include/hw/s390x/css.h | 67 ++ 2 files changed, 122 insertions(+) diff --git a/hw/s390x/css.c b/hw/s390x/css.c index 901d

[Qemu-devel] [PATCH v2 3/4] virtio-ccw: use ccw data stream

Replace direct access which implicitly assumes no IDA or MIDA with the new ccw data stream interface which should cope with these transparently in the future. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- v1 --> v2: Removed todo comments on possible errno change as w

[Qemu-devel] [PATCH v2 0/4] add CCW indirect data access support

mit message #3 Halil Pasic (4): s390x/css: introduce css data stream s390x/css: use ccw data stream virtio-ccw: use ccw data stream s390x/css: support ccw IDA hw/s390x/css.c | 171 +++-- hw/s390x/virtio-ccw.c |

[Qemu-devel] [PATCH v2 4/4] s390x/css: support ccw IDA

Let's add indirect data addressing support for our virtual channel subsystem. This implementation does no bother with any kind of prefetching. We simply step trough the IDAL on demand. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/css.c

Re: [Qemu-devel] [PATCH 3/5] virtio-ccw: use ccw data stream

On 09/13/2017 11:58 AM, Cornelia Huck wrote: > On Mon, 11 Sep 2017 20:14:59 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 09/06/2017 02:42 PM, Cornelia Huck wrote: >>>> @@ -488,7 +446,8 @@ static int virtio_ccw_cb(SubchDev *sc

Re: [Qemu-devel] [PATCH 1/5] s390x/css: introduce css data stream

On 09/13/2017 11:53 AM, Cornelia Huck wrote: > On Mon, 11 Sep 2017 18:36:00 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 09/06/2017 02:51 PM, Cornelia Huck wrote: >>>>>> +void ccw_dstream_init(CcwDataStream *cds,

Re: [Qemu-devel] [PATCH 4/5] s390x/css: support ccw IDA

On 09/13/2017 11:58 AM, Cornelia Huck wrote: > On Mon, 11 Sep 2017 20:08:16 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 09/06/2017 03:10 PM, Cornelia Huck wrote: >>> On Tue, 5 Sep 2017 13:16:44 +0200 >>> Halil Pasic <pa...@linux.

Re: [Qemu-devel] [PATCH 4/4] s390x/css: fix incorrect length indication

On 09/12/2017 05:59 PM, Cornelia Huck wrote: > On Tue, 12 Sep 2017 17:43:03 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 09/12/2017 04:37 PM, Cornelia Huck wrote: >>> On Mon, 11 Sep 2017 13:36:29 +0200 >>> Halil Pasic <pa...@linux.vnet

Re: [Qemu-devel] [PATCH 4/4] s390x/css: fix incorrect length indication

On 09/12/2017 04:37 PM, Cornelia Huck wrote: > On Mon, 11 Sep 2017 13:36:29 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 09/11/2017 12:07 PM, Cornelia Huck wrote: >>> On Fri, 8 Sep 2017 17:24:46 +0200 >>> Halil Pasic <pa...@linux.

Re: [Qemu-devel] [PATCH 4/5] s390x/css: support ccw IDA

On 09/06/2017 03:10 PM, Cornelia Huck wrote: > On Tue, 5 Sep 2017 13:16:44 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> Let's add indirect data addressing support for our virtual channel >> subsystem. This implementation does no prefetching, but steps

Re: [Qemu-devel] [PATCH 3/5] virtio-ccw: use ccw data stream

On 09/06/2017 02:42 PM, Cornelia Huck wrote: >> @@ -488,7 +446,8 @@ static int virtio_ccw_cb(SubchDev *sch, CCW1 ccw) >> } else { >> virtio_bus_get_vdev_config(>bus, vdev->config); >> /* XXX config space endianness */ > Unrelated: That should be fine, I guess?

Re: [Qemu-devel] [PATCH 1/5] s390x/css: introduce css data stream

On 09/06/2017 02:51 PM, Cornelia Huck wrote: +void ccw_dstream_init(CcwDataStream *cds, CCW1 const *ccw, ORB const *orb) +{ +/* + * We don't support MIDA (an optional facility) yet and we + * catch this earlier. Just for expressing the precondition. +

Re: [Qemu-devel] [PATCH 1/4] s390x/css: drop data-check in interpretation

On 09/11/2017 11:33 AM, Cornelia Huck wrote: > On Fri, 8 Sep 2017 17:24:43 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> The architecture says that channel-data check is indicating that >> an uncorrected storage (memory) error has been detected in reg

Re: [Qemu-devel] [PATCH 3/4] s390x/css: remove dubious error handling branch

On 09/11/2017 11:48 AM, Cornelia Huck wrote: > On Fri, 8 Sep 2017 17:24:45 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > > s/dubious/unused/ > Nod. >> The case in question actually never happens. Let us get rid of the dead >> code. > > I

Re: [Qemu-devel] [PATCH 4/4] s390x/css: fix incorrect length indication

On 09/11/2017 12:07 PM, Cornelia Huck wrote: > On Fri, 8 Sep 2017 17:24:46 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> We report incorrect length via SCSW program check instead of incorrect >> length check (SCWS word 2 bit 10 inste

[Qemu-devel] [PATCH 4/4] s390x/css: fix incorrect length indication

interpretation are replaced with an enum using more speaking names. For virtio, if incorrect length checking is suppressed we keep the current behavior (channel-program check). Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/3270-ccw.c| 24 +- hw/s390x

[Qemu-devel] [PATCH 3/4] s390x/css: remove dubious error handling branch

The case in question actually never happens. Let us get rid of the dead code. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/css.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/hw/s390x/css.c b/hw/s390x/css.c index a44d87ab3e..a9cdd54efc 100644 --- a/hw

[Qemu-devel] [PATCH 0/4] s390x/css: ccw interpretation fixes

Here come some bug fixes concerning CCW interpretation. Patch #1 was already posted as a stand alone patch, is (kind of) required by patch #4 so it's included in this series too. Halil Pasic (4): s390x/css: drop data-check in interpretation s390x/css: fix NULL handling for CCW addresses

[Qemu-devel] [PATCH 2/4] s390x/css: fix NULL handling for CCW addresses

changed dramatically. Let us roll back this undesired side effect, and go back to channel-program check. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Fixes: 2dc95b4cac "s390x/3270: 3270 data stream handling" --- I'm not sure 0 as CCW address it's strictly illegal. Ye

[Qemu-devel] [PATCH 1/4] s390x/css: drop data-check in interpretation

is to get rid of the switch case matching -EFAULT: the default is generating a channel-program check. --- Was posted as stand alone patch. See: http://patchwork.ozlabs.org/patch/810995/ If you are going to, *please review there*. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw

Re: [Qemu-devel] [PATCH 0/5] add CCW indirect data access support

On 09/08/2017 01:19 PM, Cornelia Huck wrote: > On Fri, 8 Sep 2017 13:03:00 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 09/08/2017 12:49 PM, Cornelia Huck wrote: >>> On Fri, 8 Sep 2017 12:45:25 +0200 >>> Halil Pasic <pa...@linux.vnet

Re: [Qemu-devel] [PATCH 0/5] add CCW indirect data access support

On 09/08/2017 12:49 PM, Cornelia Huck wrote: > On Fri, 8 Sep 2017 12:45:25 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> The discussion seems to have settled down quite a bit. Since there weren't >> many complaints, I would like to opt for a v2 fi

Re: [Qemu-devel] [PATCH 0/5] add CCW indirect data access support

On 09/05/2017 01:16 PM, Halil Pasic wrote: > Abstract > > > The objective of this series is introducing CCW IDA (indirect data > access) support to our virtual channel subsystem implementation. Briefly > CCW IDA can be thought of as a kind of a scatter gather supp

Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device

On 09/08/2017 04:01 AM, Dong Jia Shi wrote: > * Cornelia Huck <coh...@redhat.com> [2017-09-07 12:52:20 +0200]: > >> On Thu, 7 Sep 2017 12:21:50 +0200 >> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: >> >>> On 09/07/2017 10:08 AM, Cornelia Huck

Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH

On 09/08/2017 05:41 AM, Dong Jia Shi wrote: > Let' me summarize here, in case I misunderstand things. Now we have > two ways to choose: > > A. Kernel: no change. >Qemu : handle -EFAULT as option 2 by generating a program check. > > B. Kernel: return -EFAULT >+ >

[Qemu-devel] [PATCH 1/1] s390x/css: drop data-check in interpretation

is to get rid of the switch case matching -EFAULT: the default is generating a channel-program check. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- References --- 1. paragraph: PoP page 16-42 "Channel-Data Check". 3. paragraph: PoP page 15-59 "Designation of Sto

Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH

On 09/07/2017 12:24 PM, Cornelia Huck wrote: > On Thu, 7 Sep 2017 16:58:31 +0800 > Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> wrote: > >> * Halil Pasic <pa...@linux.vnet.ibm.com> [2017-09-06 16:43:42 +0200]: >> >>> >>> >>> On 09/06/2

Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH

On 09/07/2017 10:02 AM, Dong Jia Shi wrote: > * Cornelia Huck <coh...@redhat.com> [2017-09-06 13:25:38 +0200]: > >> On Wed, 6 Sep 2017 16:27:20 +0800 >> Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> wrote: >> >>> * Halil Pasic <pa..

Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device

On 09/07/2017 10:08 AM, Cornelia Huck wrote: > On Thu, 7 Sep 2017 15:31:09 +0800 > Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> wrote: > >> * Cornelia Huck <coh...@redhat.com> [2017-09-06 15:18:21 +0200]: >> >>> On Tue, 5 Sep 2017 13:16:45 +0200 >&g

Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH

On 09/07/2017 10:58 AM, Dong Jia Shi wrote: > * Halil Pasic <pa...@linux.vnet.ibm.com> [2017-09-06 16:43:42 +0200]: > >> >> >> On 09/06/2017 04:20 PM, Cornelia Huck wrote: >>> On Wed, 6 Sep 2017 14:25:13 +0200 >>> Halil Pasic <pa...@linux.

Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device

On 09/06/2017 05:20 PM, Cornelia Huck wrote: > On Wed, 6 Sep 2017 16:24:13 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 09/06/2017 03:18 PM, Cornelia Huck wrote: >>> On Tue, 5 Sep 2017 13:16:45 +0200 >>> Halil Pasic <pa...@linux.v

Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH

On 09/06/2017 04:20 PM, Cornelia Huck wrote: > On Wed, 6 Sep 2017 14:25:13 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> We have basically two possibilities/options which ask for different >> handling: >> 1) EFAULT is due to a bug in the vfio-c

Re: [Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device

On 09/06/2017 03:18 PM, Cornelia Huck wrote: > On Tue, 5 Sep 2017 13:16:45 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> Add a fake device meant for testing the correctness of our css emulation. >> >> What we currently have is writing

Re: [Qemu-devel] [virtio-dev] Re: [PATCH v19 0/2] virtio-crypto: virtio crypto device specification

On 09/06/2017 03:52 PM, Michael S. Tsirkin wrote: > On Fri, Sep 01, 2017 at 01:45:45PM +0200, Halil Pasic wrote: >> >> >> On 09/01/2017 02:47 AM, Longpeng (Mike) wrote: >>> Ping... >>> >>> Stefan, Halil, do you have any suggestion ? >>

Re: [Qemu-devel] [PATCH 3/5] virtio-ccw: use ccw data stream

On 09/06/2017 02:42 PM, Cornelia Huck wrote: > On Tue, 5 Sep 2017 13:16:43 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> Replace direct access which implicitly assumes no IDA >> or MIDA with the new ccw data stream interface which should >&

Re: [Qemu-devel] [PATCH 2/5] s390x/css: use ccw data stream

On 09/06/2017 02:32 PM, Cornelia Huck wrote: > On Tue, 5 Sep 2017 13:16:42 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> Replace direct access which implicitly assumes no IDA >> or MIDA with the new ccw data stream interface which should >&

Re: [Qemu-devel] [PATCH 1/5] s390x/css: introduce css data stream

On 09/06/2017 02:18 PM, Cornelia Huck wrote: > On Tue, 5 Sep 2017 13:16:41 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> This is a preparation for introducing handling for indirect data >> addressing and modified indirect data addressing (CCW). Here w

Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH

On 09/06/2017 06:31 AM, Dong Jia Shi wrote: > * Halil Pasic <pa...@linux.vnet.ibm.com> [2017-09-06 00:30:58 +0200]: > > [...] > >>> >>>> But I guess, I was afraid of somebody blaming me for this >>>> comment (such TODOs in production code

Re: [Qemu-devel] [RFC PATCH] osdep.h: Prohibit disabling assert() in supported builds

On 09/05/2017 09:50 PM, Eric Blake wrote: > On 08/24/2017 02:51 AM, Markus Armbruster wrote: >> Eric Blake <ebl...@redhat.com> writes: >> >>> On 08/22/2017 06:19 AM, Halil Pasic wrote: >>> >>>> OTOH I do think this is to some degree institution

Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH

On 09/05/2017 06:25 PM, Cornelia Huck wrote: > On Tue, 5 Sep 2017 17:55:17 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 08/31/2017 11:55 AM, Cornelia Huck wrote: >>> On Wed, 30 Aug 2017 18:36:04 +0200 >>> Halil Pasic <pa...@linux

Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH

On 09/05/2017 05:46 PM, Cornelia Huck wrote: > On Tue, 5 Sep 2017 17:24:19 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> My problem with a program check (indicated by SCSW word 2 bit 10) is >> that, in my reading of the architecture, the semantic b

Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH

On 08/31/2017 11:55 AM, Cornelia Huck wrote: > On Wed, 30 Aug 2017 18:36:04 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> Simplify the error handling of the SSCH and RSCH handler avoiding >> arbitrary and cryptic error codes being mapped to what a subc

Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH

On 09/05/2017 10:02 AM, Cornelia Huck wrote: > On Thu, 31 Aug 2017 12:41:05 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 08/31/2017 11:19 AM, Cornelia Huck wrote: >>> On Wed, 30 Aug 2017 18:36:02 +0200 >>> Halil Pasic <pa...@linux.

[Qemu-devel] [PATCH 4/5] s390x/css: support ccw IDA

Let's add indirect data addressing support for our virtual channel subsystem. This implementation does no prefetching, but steps trough the idal as we go. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/css.c | 110 ++

[Qemu-devel] [PATCH 3/5] virtio-ccw: use ccw data stream

Replace direct access which implicitly assumes no IDA or MIDA with the new ccw data stream interface which should cope with these transparently in the future. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- Error handling: At the moment we ignore errors reported by stream ops t

[Qemu-devel] [PATCH 1/5] s390x/css: introduce css data stream

-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/css.c | 55 + include/hw/s390x/css.h | 67 ++ 2 files changed, 122 insertions(+) diff --git a/hw/s390x/css.c b/hw/s390x/css.c index 1880

[Qemu-devel] [PATCH 2/5] s390x/css: use ccw data stream

Replace direct access which implicitly assumes no IDA or MIDA with the new ccw data stream interface which should cope with these transparently in the future. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- hw/s390x/css.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

[Qemu-devel] [PATCH 5/5] s390x/ccs: add ccw-tester emulated device

count. Of course lot's of invalid inputs (besides basic data processing) can be tested with that as well. Usage: 1) fire up a qemu with something like -device ccw-tester,devno=fe.0.0001 on the command line 2) exercise the device from the guest Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.

[Qemu-devel] [PATCH 0/5] add CCW indirect data access support

). Halil Pasic (5): s390x/css: introduce css data stream s390x/css: use ccw data stream virtio-ccw: use ccw data stream s390x/css: support ccw IDA s390x/ccs: add ccw-tester emulated device hw/s390x/Makefile.objs | 1 + hw/s390x/ccw-tester.c | 179

Re: [Qemu-devel] [PATCH v19 0/2] virtio-crypto: virtio crypto device specification

On 09/01/2017 02:47 AM, Longpeng (Mike) wrote: > Ping... > > Stefan, Halil, do you have any suggestion ? > Hi Longpeng, I've ran trough your patch, and it reads much better that what I recall v18 used to read like. Because it's been a while since v18 doing a conscious review on this will

[Qemu-devel] [PATCH 1/1] s390x/css: fix cc handling for XSCH

The function ioinst_handle_xsch is presenting cc 2 when it's supposed to present cc 1 and the other way around, because css_do_xsch has the error codes mixed up. Because cc 1 has precedence over cc 2 we also have to swap the two checks. Let us fix this. Signed-off-by: Halil Pasic <

Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH

On 08/31/2017 09:50 AM, Thomas Huth wrote: > On 30.08.2017 18:36, Halil Pasic wrote: >> According to the POP a start subchannel instruction (SSCH) returning with >> cc 1 implies that the subchannel was status pending when SSCH executed. >> >> Due to a somewhat conf

Re: [Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH

On 08/31/2017 11:19 AM, Cornelia Huck wrote: > On Wed, 30 Aug 2017 18:36:02 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> According to the POP a start subchannel instruction (SSCH) returning with >> cc 1 implies that the subchannel was status pending wh

Re: [Qemu-devel] [PATCH 0/9]

On 08/31/2017 12:04 PM, Cornelia Huck wrote: > On Wed, 30 Aug 2017 18:36:00 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> This series has a character of a refactoring, as the initial motivation >> was improving readability and reducing complexity. >

Re: [Qemu-devel] [PATCH 1/9] s390x/css: fix cc handling for XSCH

On 08/31/2017 10:42 AM, Cornelia Huck wrote: > On Thu, 31 Aug 2017 09:32:49 +0200 > Thomas Huth <th...@redhat.com> wrote: > >> On 31.08.2017 08:38, Cornelia Huck wrote: >>> On Thu, 31 Aug 2017 07:51:17 +0200 >>> Thomas Huth <th...@redhat.com> wrote:

Re: [Qemu-devel] [PATCH 1/9] s390x/css: fix cc handling for XSCH

On 08/31/2017 07:51 AM, Thomas Huth wrote: > On 30.08.2017 18:36, Halil Pasic wrote: >> The function ioinst_handle_xsch is presenting cc 2 when it's supposed to >> present cc 1 and the other way around, because css_do_xsch has the error >> codes mixed up. Fixing the e

[Qemu-devel] [PATCH 5/9] s390x: refactor error handling for XSCH handler

Simplify the error handling of the XSCH handler avoiding arbitrary and cryptic error codes being mapped to what a subchannel is supposed to do. Let the code detecting the condition tell how it's to be handled in a less ambiguous way. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com>

[Qemu-devel] [PATCH 7/9] s390x: refactor error handling for HSCH handler

Simplify the error handling of the HSCH handler avoiding arbitrary and cryptic error codes being mapped to what a subchannel is supposed to do. Let the code detecting the condition tell how it's to be handled in a less ambiguous way. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Re

[Qemu-devel] [PATCH 8/9] s390x: refactor error handling for MSCH handler

Simplify the error handling of the MSCH handler avoiding arbitrary and cryptic error codes being mapped to what a subchannel is supposed to do. Let the code detecting the condition tell how it's to be handled in a less ambiguous way. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Re

[Qemu-devel] [PATCH 3/9] s390x/css: be more consistent if broken beyond repair

whose handler triggered the call. Let's be consistent on this and do the -ENODEV also for virtual subchannels. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Acked-by: Pierre Morel<pmo...@linux.vnet.ibm.com> --- hw/s390x/css.c | 2 +- 1 file changed, 1 insertion(+), 1 delet

[Qemu-devel] [PATCH 9/9] s390x: factor out common ioinst handler logic

Some of ioinst the handlers look very much the same: they basically delegate the work to the appropriate css function (doing some always the same stuff before and after the call to the appropriate css function). Let us create a template and get rid of some code. Signed-off-by: Halil Pasic <

[Qemu-devel] [PATCH 0/9]

arbitrarily), then possibly mapping these errnos around, to finally (mentally) map the errno back to the condition and take appropriate action. At the end of the series we also have 125 lines of code less to maintain, and the executable got a bit smaller too. Halil Pasic (9): s390x/css: fix cc

[Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH

as the emulation of the two shares a lot of code. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Acked-by: Pierre Morel<pmo...@linux.vnet.ibm.com> --- Notes: Funny, we had a different swich-case for SSCH and RSCH. For virtual it did not matter, but for passtrough it could. In practice

[Qemu-devel] [PATCH 6/9] s390x: refactor error handling for CSCH handler

Simplify the error handling of the CSCH handler avoiding arbitrary and cryptic error codes being mapped to what a subchannel is supposed to do. Let the code detecting the condition tell how it's to be handled in a less ambiguous way. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Re

[Qemu-devel] [PATCH 2/9] s390x: fix invalid use of cc 1 for SSCH

. Let's fix this! Instead of cc 1 we use cc 3 which means device not operational, and is much closer to the truth in the given cases. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Acked-by: Pierre Morel<pmo...@linux.vnet.ibm.com> --- This patch turned out quite controversial. We d

[Qemu-devel] [PATCH 1/9] s390x/css: fix cc handling for XSCH

The function ioinst_handle_xsch is presenting cc 2 when it's supposed to present cc 1 and the other way around, because css_do_xsch has the error codes mixed up. Fixing the error codes also fixes the priority. Let us fix this. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> Re

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

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 for

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

On 08/24/2017 05:53 PM, Farhan Ali wrote: > > > 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: >

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

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

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

On 08/24/2017 05:13 PM, 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 QEMU bios which is exposed by commit >> >> commit 198c0d1f9df8c429502cb7

Re: [Qemu-devel] [PATCH for-2.11] s390x/s390-stattrib: Mark the storage attribute as not user_creatable

.com> > Signed-off-by: Thomas Huth <th...@redhat.com> Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH for-2.11] hw/s390x/s390-skeys: Mark the storage key devices with user_creatable = false

eyclass->get_skeys = qemu_s390_skeys_get; > skeyclass->set_skeys = qemu_s390_skeys_set; > + > + /* Reason: Internal device (only one skeys device for the whole memory) > */ > +dc->user_creatable = false; > } > > static const TypeInfo qemu_s390_skeys_info = { > Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH v5 3/9] s390x/pci: add stubs

> Does not really change anything in practice, but I can move it. > You mean these stubs are not supposed to be reachable and are just for making the linker happy, or? If that's the case I would prefer having that expressed by something like assert(false) or even #define NOT_REACHABLE assert(false). Otherwise patch looks good, but I did not a full review on it, so let's try this: Acked-by: Halil Pasic <pa...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH v5 7/9] s390x/sclp: properly guard pci-specific functions

sccb->h.response_code = cpu_to_be16(SCLP_RC_NORMAL_READ_COMPLETION); > } > > +static void sclp_configure_io_adapter(SCLPDevice *sclp, SCCB *sccb, > + bool configure) Just an idea. This could be called reconfigure instead of configure (that's sclp_reconfigure_io_adapter) as the facility providing both conf and deconf is called reconf. It ain't important. Patch looks good! Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH v4 08/10] s390x/pci: fence off instructions for non-pci

9,10 +1293,14 @@ static int kvm_mpcifc_service_call(S390CPU *cpu, > struct kvm_run *run) > uint64_t fiba; > uint8_t ar; > > -cpu_synchronize_state(CPU(cpu)); > -fiba = get_base_disp_rxy(cpu, run, ); > +if (s390_has_feat(S390_FEAT_ZPCI)) { > +cpu_synchronize_state(CPU(cpu)); > +fiba = get_base_disp_rxy(cpu, run, ); > > -return mpcifc_service_call(cpu, r1, fiba, ar); > +return mpcifc_service_call(cpu, r1, fiba, ar); > +} else { > +return -1; > +} The rest is directly tied to the zPCI facility. Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com> > } > > static int handle_b9(S390CPU *cpu, struct kvm_run *run, uint8_t ipa1) >

Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

On 08/22/2017 04:06 PM, Cornelia Huck wrote: > On Tue, 22 Aug 2017 15:24:34 +0200 > Cornelia Huck <coh...@redhat.com> wrote: > >> On Tue, 22 Aug 2017 14:58:37 +0200 >> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: >> >>> On 08/22/2017 11:39 AM, Co

Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

On 08/22/2017 04:15 PM, Cornelia Huck wrote: > On Tue, 22 Aug 2017 15:54:32 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 08/22/2017 03:24 PM, Cornelia Huck wrote: >>> On Tue, 22 Aug 2017 14:58:37 +0200 >>> Halil Pasic <pa...@linux.vne

Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

On 08/22/2017 03:24 PM, Cornelia Huck wrote: > On Tue, 22 Aug 2017 14:58:37 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 08/22/2017 11:39 AM, Cornelia Huck wrote: >>> On Tue, 22 Aug 2017 11:20:51 +0200 >>> Halil Pasic <pa...@linux.vnet

Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

On 08/22/2017 02:57 PM, Cornelia Huck wrote: > On Tue, 22 Aug 2017 11:39:14 +0200 > Cornelia Huck <coh...@redhat.com> wrote: > >> On Tue, 22 Aug 2017 11:20:51 +0200 >> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: >> >>> On 08/22/2017 10:39 AM,

Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

On 08/22/2017 11:39 AM, Cornelia Huck wrote: > On Tue, 22 Aug 2017 11:20:51 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 08/22/2017 10:39 AM, Cornelia Huck wrote: >>>> I'm fine either way. If I imagine having a lots of adapter types,

Re: [Qemu-devel] [RFC PATCH] osdep.h: Prohibit disabling assert() in supported builds

On 08/19/2017 12:23 AM, Eric Blake wrote: > We already have several files that knowingly require assert() > to work. While we do NOT want to encourage the use of > 'assert(side-effects)' (that is a bad practice that prevents > copy-and-paste of code to other projects that CAN disable >

Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

On 08/22/2017 10:39 AM, Cornelia Huck wrote: >> I'm fine either way. If I imagine having a lots of adapter types, then I >> would expect a switch or a jumptable on the type before handling control >> to the pci specific function. In this case statically not supported types >> would probably get

Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

On 08/21/2017 04:58 PM, Pierre Morel wrote: > On 21/08/2017 11:16, Cornelia Huck wrote: >> If we do not provide zpci, pci reconfiguration via sclp is not available >> either. Don't indicate it in the sclp facilities and return an invalid >> command if the guest tries to issue pci

Re: [Qemu-devel] [PATCH v4 09/10] s390x/kvm: msi route fixup for non-pci

On 08/21/2017 05:17 PM, Thomas Huth wrote: > On 21.08.2017 17:10, Halil Pasic wrote: > [...] >> The situation is just complicated by the fact that there is code which >> relies on assert(true) asserting for correctness (e.g. virtio goes so far >> to make builds with norm

Re: [Qemu-devel] [PATCH v4 09/10] s390x/kvm: msi route fixup for non-pci

On 08/21/2017 02:13 PM, Cornelia Huck wrote: > On Mon, 21 Aug 2017 14:00:15 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 08/21/2017 11:16 AM, Cornelia Huck wrote: >>> If we don't provide pci, we cannot have a pci device for which we >>> ha

Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

On 08/21/2017 03:16 PM, Cornelia Huck wrote: > On Mon, 21 Aug 2017 13:41:53 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 08/21/2017 11:16 AM, Cornelia Huck wrote: >>> If we do not provide zpci, pci reconfiguration via sclp is not availa

Re: [Qemu-devel] [PATCH v4 09/10] s390x/kvm: msi route fixup for non-pci

On 08/21/2017 11:16 AM, Cornelia Huck wrote: > If we don't provide pci, we cannot have a pci device for which we > have to translate to adapter routes: just return -ENODEV. > > Signed-off-by: Cornelia Huck > --- > target/s390x/kvm.c | 6 ++ > 1 file changed, 6

Re: [Qemu-devel] [PATCH v4 07/10] s390x/sclp: properly guard pci-specific functions

On 08/21/2017 11:16 AM, Cornelia Huck wrote: > If we do not provide zpci, pci reconfiguration via sclp is not available > either. Don't indicate it in the sclp facilities and return an invalid > command if the guest tries to issue pci configure/deconfigure. > > Reviewed-by: Thomas Huth

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

de/hw/compat.h b/include/hw/compat.h > index 08f36004da..3e101f8f67 100644 > --- a/include/hw/compat.h > +++ b/include/hw/compat.h > @@ -1,6 +1,9 @@ > #ifndef HW_COMPAT_H > #define HW_COMPAT_H > > +#define HW_COMPAT_2_10 \ > +/* empty */ > + > #define HW_COMPAT_2_9 \ > {\ > .driver = "pci-bridge",\ > LGTM Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH] error: Improve documentation of error_append_hint()

On 08/10/2017 12:06 PM, Markus Armbruster wrote: > Suggested-by: Halil Pasic <pa...@linux.vnet.ibm.com> > Signed-off-by: Markus Armbruster <arm...@redhat.com> Nice clarification! Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com>

Re: [Qemu-devel] [PATCH] virtio: Mark virtio-device as non-user-creatable

On 08/03/2017 04:45 PM, Eduardo Habkost wrote: > On Wed, Aug 02, 2017 at 02:33:00PM +0200, Halil Pasic wrote: >> >> >> On 08/02/2017 01:01 AM, Eduardo Habkost wrote: >>> TYPE_VIRTIO_DEVICE devices are already not usable with -device >>> and device_add,

Re: [Qemu-devel] [PATCH] virtio: Mark virtio-device as non-user-creatable

On 08/02/2017 01:01 AM, Eduardo Habkost wrote: > TYPE_VIRTIO_DEVICE devices are already not usable with -device > and device_add, but they are reported as user-creatable on > "-device help" and through monitor interfaces. I've tried -device virtio-rng on s390x and from what I see, it seems we

Re: [Qemu-devel] [PATCH v2 1/2] s390x/css: use macro for event-information pending error recover code

On 08/01/2017 09:57 AM, Dong Jia Shi wrote: > Let's use a macro for the ERC (error recover code) when generating a > Channel Subsystem Event-information pending CRW (channel report word). > > While we are at it, let's also add all other ERCs. > > Signed-off-by: Dong Jia Shi

Re: [Qemu-devel] [PATCH v2 2/2] s390x/css: generate solicited crw for rchp completion signaling

On 08/01/2017 09:57 AM, Dong Jia Shi wrote: [..] > --- a/hw/s390x/css.c > +++ b/hw/s390x/css.c > @@ -1745,10 +1745,10 @@ int css_do_rchp(uint8_t cssid, uint8_t chpid) > } > > /* We don't really use a channel path, so we're done here. */ > -css_queue_crw(CRW_RSC_CHP, CRW_ERC_INIT,

Re: [Qemu-devel] [PATCH 3/3] s390x/css: generate channel path initialized CRW for channel path hotplug

On 07/31/2017 01:13 PM, Cornelia Huck wrote: > On Mon, 31 Jul 2017 11:51:37 +0800 > Dong Jia Shi wrote: > >> * Cornelia Huck [2017-07-27 13:59:10 +0200]: >> >>> On Thu, 27 Jul 2017 03:54:18 +0200 >>> Dong Jia Shi

Re: [Qemu-devel] [PATCH 3/3] s390x/css: generate channel path initialized CRW for channel path hotplug

On 07/28/2017 02:58 PM, Cornelia Huck wrote: > On Fri, 28 Jul 2017 14:32:11 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 07/28/2017 12:11 PM, Cornelia Huck wrote: >>> On Thu, 27 Jul 2017 18:15:07 +0200 >>> Halil Pasic <pa...@linux.vn

Re: [Qemu-devel] [PATCH 3/3] s390x/css: generate channel path initialized CRW for channel path hotplug

On 07/28/2017 12:11 PM, Cornelia Huck wrote: > On Thu, 27 Jul 2017 18:15:07 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 07/27/2017 04:14 PM, Cornelia Huck wrote: >>> On Thu, 27 Jul 2017 15:37:08 +0200 >>> Halil Pasic <pa...@linux.vnet

Re: [Qemu-devel] [PATCH 3/3] s390x/css: generate channel path initialized CRW for channel path hotplug

On 07/27/2017 04:14 PM, Cornelia Huck wrote: > On Thu, 27 Jul 2017 15:37:08 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > >> On 07/27/2017 01:59 PM, Cornelia Huck wrote: >>> On Thu, 27 Jul 2017 03:54:18 +0200 >>> Dong Jia Shi <bjsdj...@l

[Qemu-devel] [PATCH v2 1/1] s390x/css: check ccw address validity

implementation follow the AR more closely. Signed-off-by: Halil Pasic <pa...@linux.vnet.ibm.com> --- This patch used to be a patch used to be a part of the series 'ccw interpretation AR compliance improvements' but the other patch was already applied. I would still like this one being in front of '39

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