Re: [Qemu-devel] [PATCH v2] qdev/core: Can not replug device on bus that allows one device

patch fixes that problem. > As Pierre has pointed out, the commit message is stale and inaccurate. Subject could be better as well. I mean the problem is not limited to buses that allow only one device. Each bus that can get full looses capacity with every plug/unplug op pair. With that fixed

Re: [Qemu-devel] [PATCH] qdev/core: Can not replug device on bus that allows one device

On Thu, 13 Dec 2018 13:09:59 +0100 Igor Mammedov wrote: > On Tue, 11 Dec 2018 14:41:00 -0500 > Tony Krowiak wrote: > > > On 12/11/18 10:23 AM, Igor Mammedov wrote: > > > On Mon, 10 Dec 2018 14:14:14 -0500 > > > Tony Krowiak wrote: > > > > > >> If the maximum number of devices allowed on a

Re: [Qemu-devel] [qemu-s390x] [PATCH] hw/s390x/virtio-ccw.c: Don't take address of fields in packed structs

f clang warn about this. Avoid the bug by not using the > "modify in place" byte swapping functions. > > Patch produced with scripts/coccinelle/inplace-byteswaps.cocci > (with a couple of long lines manually wrapped). > > Signed-off-by: Peter Maydell Reviewed-by: Hal

Re: [Qemu-devel] [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part)

On Fri, 7 Dec 2018 11:05:29 +0100 Cornelia Huck wrote: > > > I think most of the sorting-out-the-operations stuff should be done by > > > the hardware itself, and we should not really try to enforce anything > > > special in our vfio code. > > > > > > > Sounds very reasonable to me. Does

Re: [Qemu-devel] [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part)

On Fri, 7 Dec 2018 11:05:29 +0100 Cornelia Huck wrote: [..] > > To clarify my concern let me quote from the PoP > > (SA22-7832-10 page 14-9): > > > > """ > > If a device presents unsolicited status while the > > associated subchannel is disabled, that status is > > discarded by the channel

Re: [Qemu-devel] [PATCH RFC] vfio-ap: flag as compatible with balloon

On Fri, 7 Dec 2018 14:17:20 +0100 Cornelia Huck wrote: > On Fri, 7 Dec 2018 13:52:53 +0100 > Halil Pasic wrote: > > > On Fri, 7 Dec 2018 13:29:46 +0100 > > Cornelia Huck wrote: > > > > > On Fri, 7 Dec 2018 13:17:02 +0100 > > > Christian Borntrae

Re: [Qemu-devel] [PATCH RFC] vfio-ap: flag as compatible with balloon

ived to be compatible with memory ballooning. > > > > > > Flag them as compatible, so both vfio-ap and a balloon can be > > > used simultaneously. > > > > > > Signed-off-by: Cornelia Huck With the comment stuff sorted out: Reviewed-by: Halil Pasic @Co

Re: [Qemu-devel] [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part)

On Wed, 5 Dec 2018 13:54:02 +0100 Cornelia Huck wrote: > On Tue, 4 Dec 2018 16:02:36 +0100 > Halil Pasic wrote: > > > On Tue, 4 Dec 2018 14:11:30 +0100 > > Cornelia Huck wrote: > > > > > On Tue, 4 Dec 2018 13:38:10 +0100 > > > Halil Pasic wrote:

Re: [Qemu-devel] [PATCH RFC] vfio-ap: flag as compatible with balloon

On Thu, 6 Dec 2018 09:28:34 +0100 David Hildenbrand wrote: > On 05.12.18 18:25, Christian Borntraeger wrote: > > > > > > On 05.12.2018 17:45, Cornelia Huck wrote: > >> On Wed, 5 Dec 2018 17:38:22 +0100 > >> David Hildenbrand wrote: > >> > >>> On 05.12.18 15:51, Cornelia Huck wrote: >

Re: [Qemu-devel] [qemu-s390x] [PATCH v2 2/6] s390x/vfio: ap: Use the APdevice as a child of the APBus

On Thu, 22 Nov 2018 17:35:51 +0100 Pierre Morel wrote: > Two good reasons to use the base device as a child of the > AP BUS: > - We can easily find the device without traversing the qtree. > - In case we have different APdevice instantiation, VFIO with > interception or emulation, we will need

Re: [Qemu-devel] [qemu-s390x] [PATCH] Clean up includes

parc64/signal.c > linux-user/x86_64/cpu_loop.c > linux-user/x86_64/signal.c > target/s390x/gen-features.c > tests/migration/s390x/a-b-bios.c > tests/test-rcu-simpleq.c > tests/test-rcu-tailq.c > > Signed-off-by: Markus Armbruster Acked-by: Halil Pasic Thanks, Halil

Re: [Qemu-devel] [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part)

On Tue, 4 Dec 2018 14:11:30 +0100 Cornelia Huck wrote: > On Tue, 4 Dec 2018 13:38:10 +0100 > Halil Pasic wrote: > > > On Thu, 22 Nov 2018 17:54:29 +0100 > > Cornelia Huck wrote: > > > > > [This is the Linux kernel part, git tree is available at > &

Re: [Qemu-devel] [qemu-s390x] [PATCH] s390/MAINTAINERS: Add Halil as kvm and machine maintainer

On Tue, 4 Dec 2018 14:38:02 +0100 Christian Borntraeger wrote: > Halil does more work in this area than I do right now. Lets add Halil. > > Signed-off-by: Christian Borntraeger Acked-by: Halil Pasic > --- > MAINTAINERS | 4 +++- > 1 file changed, 3 insertions(+), 1 del

Re: [Qemu-devel] [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part)

On Thu, 22 Nov 2018 17:54:29 +0100 Cornelia Huck wrote: > [This is the Linux kernel part, git tree is available at > https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git > vfio-ccw-caps > > The companion QEMU patches are available at > https://github.com/cohuck/qemu

Re: [Qemu-devel] [PATCH v2 0/6] s390x/vfio: VFIO-AP interrupt control interception

On Fri, 30 Nov 2018 14:01:42 +0100 Pierre Morel wrote: > On 29/11/2018 16:55, Halil Pasic wrote: > > On Thu, 22 Nov 2018 17:35:49 +0100 > > Pierre Morel wrote: > > > >> This series has 3 different type of patches: > >> > >> The first tw

Re: [Qemu-devel] [qemu-s390x] [PATCH 3/3] vfio-ccw: add handling for asnyc channel instructions

On Thu, 29 Nov 2018 17:52:34 +0100 Cornelia Huck wrote: > On Wed, 28 Nov 2018 17:36:04 +0100 > Halil Pasic wrote: > > > On Thu, 22 Nov 2018 17:54:32 +0100 > > Cornelia Huck wrote: > > > > > Add a region to the vfio-ccw device that can be used to submit

Re: [Qemu-devel] [PATCH v2 0/6] s390x/vfio: VFIO-AP interrupt control interception

On Thu, 22 Nov 2018 17:35:49 +0100 Pierre Morel wrote: > This series has 3 different type of patches: > > The first two: > s390x/vfio: ap: Finding the AP bridge > s390x/vfio: ap: Use the APdevice as a child of the APBus > > Are dealing with the QEMU Object Model and how we retrieve the >

Re: [Qemu-devel] [qemu-s390x] [PATCH 3/3] vfio-ccw: add handling for asnyc channel instructions

On Thu, 22 Nov 2018 17:54:32 +0100 Cornelia Huck wrote: > Add a region to the vfio-ccw device that can be used to submit > asynchronous I/O instructions. ssch continues to be handled by the > existing I/O region; the new region handles hsch and csch. > > Interrupt status continues to be

Re: [Qemu-devel] [qemu-s390x] [PATCH 0/3] vfio-ccw: support hsch/csch (kernel part)

On Thu, 22 Nov 2018 17:54:29 +0100 Cornelia Huck wrote: > [This is the Linux kernel part, git tree is available at > https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git > vfio-ccw-caps > > The companion QEMU patches are available at > https://github.com/cohuck/qemu

Re: [Qemu-devel] [PATCH 2/4] MAINTAINERS: s390/virtio-ccw: drop Christian add Halil

On 10/29/2018 04:42 PM, Christian Borntraeger wrote: > Halil does all the work anyway. > > Signed-off-by: Christian Borntraeger Acked-by: Halil Pasic > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAI

Re: [Qemu-devel] [PATCH v10 5/6] s390x/vfio: ap: Introduce VFIO AP device

the the AP devices to which the guest will > be granted access. > > Signed-off-by: Tony Krowiak > Tested-by: Pierre Morel Whit the things Thomas and David noticed fixed: Acked-by: Halil Pasic > --- > MAINTAINERS | 1 + > defaul

Re: [Qemu-devel] [qemu-s390x] [PATCH v10 4/6] s390x/ap: base Adjunct Processor (AP) object model

On 10/09/2018 07:52 PM, Tony Krowiak wrote: > From: Tony Krowiak > > Introduces the base object model for virtualizing AP devices. > > Signed-off-by: Tony Krowiak > Tested-by: Pierre Morel > Acked-by: David Hildenbrand Reviewed-by: Halil Pasic > --- > MAINTA

Re: [Qemu-devel] [qemu-s390x] [PATCH v10 3/6] s390x/kvm: enable AP instruction interpretation for guest

P instructions executed on the guest must be > intercepted; so when the device is realized, it must disable > interpretation. > > Signed-off-by: Tony Krowiak > Tested-by: Pierre Morel Acked-by: Halil Pasic > --- > target/s390x/kvm.c | 19 +++ > 1 file ch

Re: [Qemu-devel] [PATCH v10 2/6] s390x/cpumodel: Set up CPU model for AP device support

ly if APFT is installed >on the host. > > Signed-off-by: Tony Krowiak > Tested-by: Pierre Morel Reviewed-by: Halil Pasic

Re: [Qemu-devel] [qemu-s390x] [PATCH v9 4/6] s390x/ap: base Adjunct Processor (AP) object model

On 09/27/2018 02:29 PM, Thomas Huth wrote: >> +static void vfio_ap_bus_class_init(ObjectClass *klass, void *data) >> +{ >> +BusClass *k = BUS_CLASS(klass); > I think calling the variable "oc" (or something similar) instead of > "klass" is prefered nowadays. > >> +k->get_dev_path =

Re: [Qemu-devel] [qemu-s390x] [PATCH v9 4/6] s390x/ap: base Adjunct Processor (AP) object model

On 09/27/2018 12:54 AM, Tony Krowiak wrote: > From: Tony Krowiak > > Introduces the base object model for virtualizing AP devices. > [..] > + > +static char *vfio_ap_bus_get_dev_path(DeviceState *dev) Cover letter states you want to remove vifo_ap references form the bus. Sane thing to do

Re: [Qemu-devel] [qemu-s390x] [PATCH v9 4/6] s390x/ap: base Adjunct Processor (AP) object model

On 09/27/2018 02:52 PM, Cornelia Huck wrote: > On Thu, 27 Sep 2018 14:29:01 +0200 > Thomas Huth wrote: > >> On 2018-09-27 00:54, Tony Krowiak wrote: >>> From: Tony Krowiak >>> >>> Introduces the base object model for virtualizing AP devices. >>> >>> Signed-off-by: Tony Krowiak >>> --- >

Re: [Qemu-devel] [qemu-s390x] [PATCH v8 3/6] s390x/kvm: enable/disable AP instruction interpretation for guest

On 09/18/2018 06:59 PM, Tony Krowiak wrote: > I've discussed this with Halil -- Pierre is out until next week. We > are in agreement that while these changes are viable, they result in > a slightly more complicated implementation compared to previous versions (e.g. > kernel v9 QEMU v7), and 

Re: [Qemu-devel] [qemu-s390x] [PATCH v8 4/6] s390x/ap: base Adjunct Processor (AP) object model

On 09/13/2018 07:15 PM, Tony Krowiak wrote: On 09/13/2018 01:02 PM, Tony Krowiak wrote: On 09/13/2018 02:29 AM, Christian Borntraeger wrote: On 09/13/2018 07:48 AM, Thomas Huth wrote: On 2018-09-12 22:08, Tony Krowiak wrote: From: Tony Krowiak Introduces the base object model for

Re: [Qemu-devel] [virtio-dev] Re: [v23 1/2] virtio-crypto: Add virtio crypto device specification

On 07/27/2018 01:51 PM, Michael S. Tsirkin wrote: On Thu, Jul 26, 2018 at 06:55:44PM +0200, Halil Pasic wrote: Sorry I did not have any time for this last days. And this to make it worse this is a follow up to something that was half a year ago. That means I have to re-familiarize myself

Re: [Qemu-devel] [PATCH for-3.1] s390x: remove 's390-squash-mcss' option

On 07/24/2018 11:24 AM, Cornelia Huck wrote: This option has been deprecated for two releases; remove it. Signed-off-by: Cornelia Huck Acked-by: Halil Pasic --- hw/s390x/3270-ccw.c| 2 +- hw/s390x/css-bridge.c | 1 - hw/s390x/css.c

Re: [Qemu-devel] [v23 1/2] virtio-crypto: Add virtio crypto device specification

most of the questions were of type 'Can we do it like this?', maybe sending out a new version is the best. So people (like me) can read through the whole thing and point out problems if any. Regards, Halil On 07/20/2018 02:01 PM, Longpeng (Mike) wrote: On 2018/1/10 1:05, Halil Pasic wrote

Re: [Qemu-devel] [qemu-s390x] [RFC 14/15] s390-bios: Support booting from real dasd device

On 07/18/2018 01:35 PM, Cornelia Huck wrote: So to translate the new stuff we would actually have to stop the channel program and resubmit the rest (either by suspend+resume or by break chaining+ssch). The problem with that an execution of a channel program that is composed of four ccws

Re: [Qemu-devel] [RFC 14/15] s390-bios: Support booting from real dasd device

On 07/05/2018 07:25 PM, Jason J. Herne wrote: From: "Jason J. Herne" Allows guest to boot from a vfio configured real dasd device. Signed-off-by: Jason J. Herne Signed-off-by: Jason J. Herne --- docs/devel/s390-dasd-ipl.txt | 132 +++ pc-bios/s390-ccw/Makefile|

Re: [Qemu-devel] [qemu-s390x] [RFC 14/15] s390-bios: Support booting from real dasd device

On 07/18/2018 09:40 AM, Cornelia Huck wrote: On Tue, 17 Jul 2018 22:43:27 +0200 David Hildenbrand wrote: On 05.07.2018 19:25, Jason J. Herne wrote: +* +* How this all pertains to Qemu * +* + +In

Re: [Qemu-devel] [RFC 15/15] s390-bios: Use sense ccw to ensure consistent device state at boot time

On 07/05/2018 07:25 PM, Jason J. Herne wrote: If a vfio-ccw device is left in an error state (example: pending unit check) then it is possible for that state to persist for a vfio-ccw device even after the enable subchannel that we do to bring the device online. If this state is allowed to

Re: [Qemu-devel] [qemu-s390x] [RFC 10/15] s390-bios: Support for running format-0/1 channel programs

On 07/06/2018 03:15 PM, Cornelia Huck wrote: On Fri, 6 Jul 2018 15:03:49 +0200 Halil Pasic wrote: On 07/06/2018 02:26 PM, Cornelia Huck wrote: On Fri, 6 Jul 2018 13:42:25 +0200 Halil Pasic wrote: On 07/06/2018 10:03 AM, Cornelia Huck wrote: On Thu, 5 Jul 2018 13:25:38 -0400 "

Re: [Qemu-devel] [qemu-s390x] [RFC 10/15] s390-bios: Support for running format-0/1 channel programs

On 07/06/2018 02:26 PM, Cornelia Huck wrote: On Fri, 6 Jul 2018 13:42:25 +0200 Halil Pasic wrote: On 07/06/2018 10:03 AM, Cornelia Huck wrote: On Thu, 5 Jul 2018 13:25:38 -0400 "Jason J. Herne" wrote: +rc = ssch(schid, ); +if (rc) { +print_int("ssch faile

Re: [Qemu-devel] [qemu-s390x] [RFC 10/15] s390-bios: Support for running format-0/1 channel programs

On 07/06/2018 10:03 AM, Cornelia Huck wrote: On Thu, 5 Jul 2018 13:25:38 -0400 "Jason J. Herne" wrote: From: "Jason J. Herne" Add struct for format-0 ccws. Support executing format-0 channel + */ +if (irb->scsw.cstat != 0x00 && irb->scsw.cstat != 0x40) { +return true;

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

On 06/22/2018 12:29 PM, Christian Borntraeger wrote: kexec/kdump as well as the bootloader use a subcode of diagnose 308 that is supposed to reset the I/O subsystem but not comprise a full "reboot". With the latest refactoring this is now broken when -no-reboot is used or when libvirt acts on

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 to the guest

Re: [Qemu-devel] [PATCH RFC 2/2] vfio-ccw: support for halt/clear subchannel

On 06/12/2018 03:56 PM, Pierre Morel wrote: So, what are you proposing? Being more specific and stating that the scsw is not necessarily a real scsw, but merely a vehicle for sending a command? Or keeping it as it is now for ssch, and adding a second interface for hsch/csch (and maybe rsch, 

Re: [Qemu-devel] [PATCH RFC 2/2] vfio-ccw: support for halt/clear subchannel

On 06/08/2018 04:45 PM, Cornelia Huck wrote: On Fri, 8 Jun 2018 15:13:28 +0200 Halil Pasic wrote: On 06/08/2018 02:20 PM, Cornelia Huck wrote: My proposal is to do the same copying to scsw(r) again, which would mean we get a request with both the halt and the start bit set. The vfio code

Re: [Qemu-devel] [qemu-s390x] [PATCH RFC 2/2] vfio-ccw: support for halt/clear subchannel

On 06/07/2018 06:34 PM, Cornelia Huck wrote: On Thu, 7 Jun 2018 18:17:57 +0200 Halil Pasic wrote: On 06/07/2018 11:54 AM, Cornelia Huck wrote: Hm, I think we need to be more precise as to what scsw we're talking about. Bad ascii art time: -- | scsw(g) | ssch

Re: [Qemu-devel] [PATCH RFC 2/2] vfio-ccw: support for halt/clear subchannel

On 06/08/2018 02:20 PM, Cornelia Huck wrote: My proposal is to do the same copying to scsw(r) again, which would mean we get a request with both the halt and the start bit set. The vfio code now needs to do a hsch (instead of a ssch). The real channel subsystem should figure this out, as we

Re: [Qemu-devel] [qemu-s390x] [PATCH RFC 2/2] vfio-ccw: support for halt/clear subchannel

On 06/07/2018 11:54 AM, Cornelia Huck wrote: Hm, I think we need to be more precise as to what scsw we're talking about. Bad ascii art time: -- | scsw(g) | ssch -- | | guest

Re: [Qemu-devel] [PATCH v3 1/2] vfio-ccw: add force unlimited prefetch property

On 06/05/2018 12:14 PM, Cornelia Huck wrote: On Thu, 24 May 2018 19:58:27 +0200 Halil Pasic wrote: There is at least one guest (OS) such that although it does not rely on the guarantees provided by ORB 1 word 9 bit (aka unlimited prefetch, aka P bit) not being set, it fails to tell

Re: [Qemu-devel] [PATCH v4 1/2] qemu-error: introduce {error|warn}_report_once

On 05/30/2018 05:19 PM, Michael S. Tsirkin wrote: On Wed, May 30, 2018 at 05:15:19PM +0200, Halil Pasic wrote: On 05/30/2018 06:47 AM, Michael S. Tsirkin wrote: On Thu, May 24, 2018 at 12:44:53PM +0800, Peter Xu wrote: There are many error_report()s that can be used in frequently called

Re: [Qemu-devel] [PATCH v4 1/2] qemu-error: introduce {error|warn}_report_once

On 05/30/2018 06:47 AM, Michael S. Tsirkin wrote: On Thu, May 24, 2018 at 12:44:53PM +0800, Peter Xu wrote: There are many error_report()s that can be used in frequently called functions, especially on IO paths. That can be unideal in that malicious guest can try to trigger the error tons

Re: [Qemu-devel] [PATCH v3 1/2] vfio-ccw: add force unlimited prefetch property

On 05/25/2018 08:08 PM, Eric Blake wrote: On 05/25/2018 12:46 PM, Halil Pasic wrote: +static inline void warn_once(bool *warned, const char *fmt, ...) +{ +    va_list ap; + +    if (!warned || *warned) { +    return; +    } +    *warned = true; +    va_start(ap, fmt); +    warn_vreport

Re: [Qemu-devel] [PATCH v3 1/2] vfio-ccw: add force unlimited prefetch property

On 05/25/2018 11:40 AM, Cornelia Huck wrote: On Thu, 24 May 2018 19:58:27 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: There is at least one guest (OS) such that although it does not rely on the guarantees provided by ORB 1 word 9 bit (aka unlimited prefetch, aka P bit) not bei

[Qemu-devel] [PATCH v3 2/2] vfio-ccw: remove orb.c64 (64 bit data addresses) check

. Signed-off-by: Halil Pasic <pa...@linux.ibm.com> Acked-by: Jason J. Herne <jjhe...@linux.ibm.com> Tested-by: Jason J. Herne <jjhe...@linux.ibm.com> --- hw/s390x/css.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/hw/s390x/css.c b/hw/s390x/css.c index 39ae5bbf7e.

[Qemu-devel] [PATCH v3 1/2] vfio-ccw: add force unlimited prefetch property

to be forced, and designate the affected vfio-ccw device. Signed-off-by: Halil Pasic <pa...@linux.ibm.com> Suggested-by: Dong Jia Shi <bjsdj...@linux.ibm.com> Acked-by: Jason J. Herne <jjhe...@linux.ibm.com> Tested-by: Jason J. Herne <jjhe...@linux.ibm.com> --- @Jason: I have kept th

[Qemu-devel] [PATCH v3 0/2] vfio-ccw: loosen orb flags checks

See the individual patches (inclusive change log). Halil Pasic (2): vfio-ccw: add force unlimited prefetch property vfio-ccw: remove orb.c64 (64 bit data addresses) check hw/s390x/css.c | 12 hw/vfio/ccw.c | 35 +++ 2 files changed, 35

Re: [Qemu-devel] [qemu-s390x] [PATCH v2 1/2] vfio-ccw: add force unlimited prefetch property

On 05/24/2018 12:29 PM, Halil Pasic wrote: On 05/24/2018 09:16 AM, Cornelia Huck wrote: On Wed, 23 May 2018 19:28:31 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: On 05/23/2018 06:59 PM, Cornelia Huck wrote: On Wed, 23 May 2018 18:23:44 +0200 Halil Pasic <pa...@linux.ibm.c

Re: [Qemu-devel] [qemu-s390x] [PATCH v2 1/2] vfio-ccw: add force unlimited prefetch property

On 05/24/2018 09:16 AM, Cornelia Huck wrote: On Wed, 23 May 2018 19:28:31 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: On 05/23/2018 06:59 PM, Cornelia Huck wrote: On Wed, 23 May 2018 18:23:44 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: On 05/23/2018 04:46 PM, Corneli

Re: [Qemu-devel] [qemu-s390x] [PATCH v2 1/2] vfio-ccw: add force unlimited prefetch property

On 05/23/2018 06:59 PM, Cornelia Huck wrote: On Wed, 23 May 2018 18:23:44 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: On 05/23/2018 04:46 PM, Cornelia Huck wrote: +if (!(sch->orb.ctrl0 & ORB_CTRL0_MASK_PFCH)) { +if (!(vcdev->force_orb_pfch)) { +w

Re: [Qemu-devel] [qemu-s390x] [PATCH v2 1/2] vfio-ccw: add force unlimited prefetch property

On 05/23/2018 04:46 PM, Cornelia Huck wrote: +if (!(sch->orb.ctrl0 & ORB_CTRL0_MASK_PFCH)) { +if (!(vcdev->force_orb_pfch)) { +warn_report("vfio-ccw requires PFCH flag set"); +sch_gen_unit_exception(sch); +css_inject_io_interrupt(sch); +

Re: [Qemu-devel] [qemu-s390x] [PATCH v2 1/2] vfio-ccw: add force unlimited prefetch property

On 05/23/2018 11:37 AM, Cornelia Huck wrote: On Wed, 23 May 2018 00:16:54 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: There is at least one guest (OS) such that although it does not rely on the guarantees provided by ORB 1 word 9 bit (aka unlimited prefetch, aka P bit) not bei

[Qemu-devel] [PATCH v2 0/2] vfio-ccw: loosen orb flags checks

See the individual patches (inclusive change log). Halil Pasic (2): vfio-ccw: add force unlimited prefetch property vfio-ccw: remove orb.c64 (64 bit data addresses) check hw/s390x/css.c | 12 hw/vfio/ccw.c | 25 + 2 files changed, 25 insertions(+), 12

[Qemu-devel] [PATCH v2 1/2] vfio-ccw: add force unlimited prefetch property

to set, if the user knows this is safe. For self modifying channel programs forcing the P bit is not safe. If P bit is forced for a self modifying channel program things are expected to break in strange ways. Signed-off-by: Halil Pasic <pa...@linux.ibm.com> Suggested-by: Dong Jia Shi

[Qemu-devel] [PATCH v2 2/2] vfio-ccw: remove orb.c64 (64 bit data addresses) check

. Signed-off-by: Halil Pasic <pa...@linux.ibm.com> Acked-by: Jason J. Herne <jjhe...@linux.ibm.com> Tested-by: Jason J. Herne <jjhe...@linux.ibm.com> --- v1 -> v2: unchanged --- hw/s390x/css.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/hw/s390x/css.c b

Re: [Qemu-devel] [PATCH 1/1] virtio-ccw: clean up notify

On 05/17/2018 05:26 PM, Cornelia Huck wrote: On Wed, 16 May 2018 15:27:57 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: Coverity recently started complaining about virtio_ccw_notify(). Turns out, there is a couple of things that can be cleaned up. Let's clean! Changes look good

Re: [Qemu-devel] [qemu-s390x] [PATCH 1/2] vfio-ccw: add force unlimited prefetch property

On 05/17/2018 04:21 PM, Cornelia Huck wrote: How about force-orb-pfch or force-orb-pbit (PoP name) for the property and with underscores for the variable. My idea was (starting from your force_pfch) to spell out that we are fiddling with that orb bit. force-orb-pfch looks reasonable to me.

Re: [Qemu-devel] [qemu-s390x] [PATCH 1/2] vfio-ccw: add force unlimited prefetch property

On 05/14/2018 06:04 PM, Cornelia Huck wrote: On Mon, 14 May 2018 16:22:30 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: On 05/14/2018 03:45 PM, Cornelia Huck wrote: On Mon, 14 May 2018 14:40:13 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: On 05/14/2018 02:18 PM, Corneli

[Qemu-devel] [PATCH 1/1] virtio-ccw: clean up notify

Coverity recently started complaining about virtio_ccw_notify(). Turns out, there is a couple of things that can be cleaned up. Let's clean! Reported-by: Peter Maydell <peter.mayd...@linaro.org> Fixes: CID 1390619 Signed-off-by: Halil Pasic <pa...@linux.ibm.com> --- hw/s390x/virti

Re: [Qemu-devel] [qemu-s390x] virtio-ccw.c vs larger VIRTIO_QUEUE_MAX (coverity warning CID 1390619)

On 05/15/2018 04:01 PM, Cornelia Huck wrote: On Tue, 15 May 2018 15:17:51 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: 8<---- From: Halil Pasic <pa...@linux.ibm.com> Date: Tue, 15 May 2018 13:57:4

Re: [Qemu-devel] [qemu-s390x] virtio-ccw.c vs larger VIRTIO_QUEUE_MAX (coverity warning CID 1390619)

On 05/15/2018 02:07 PM, Peter Maydell wrote: On 15 May 2018 at 13:00, Halil Pasic <pa...@linux.ibm.com> wrote: To sum it up, my take on the whole is the diff below. I can convert it to a proper patch if we agree that's the way to go. From: Halil Pasic <pa...@linux.ibm.com> Date:

Re: [Qemu-devel] [qemu-s390x] virtio-ccw.c vs larger VIRTIO_QUEUE_MAX (coverity warning CID 1390619)

e always set the same bit, and it is always triggered by doing a notification with a number one above the maximum possible virtqueue number. (I agree that it does look odd, we should maybe add a comment.) --------8<--- From: Halil Pasic <pa...@

Re: [Qemu-devel] [PATCH 1/2] vfio-ccw: add force unlimited prefetch property

On 05/14/2018 03:45 PM, Cornelia Huck wrote: On Mon, 14 May 2018 14:40:13 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: On 05/14/2018 02:18 PM, Cornelia Huck wrote: On Thu, 10 May 2018 02:07:11 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: There is at least one control pr

Re: [Qemu-devel] [PATCH 1/2] vfio-ccw: add force unlimited prefetch property

On 05/14/2018 02:18 PM, Cornelia Huck wrote: On Thu, 10 May 2018 02:07:11 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: There is at least one control program (guest) that although it does not I'd drop 'control program' here as well, as it probably confuses more than helps. W

Re: [Qemu-devel] [PATCH v5 4/6] s390x/vfio: ap: Introduce VFIO AP device

On 05/10/2018 03:10 PM, Tony Krowiak wrote: If I did not. I think this is a big problem. We need to at least zeroize the queues (e.g. on system reset)  to avoid leaking sensitive information. Without this, there is no sane way to use ap-passthrough. Or am I wrong? I do not have a definitive 

[Qemu-devel] [PATCH 2/2] vfio-ccw: remove orb.c64 (64 bit data addresses) check

. Signed-off-by: Halil Pasic <pa...@linux.ibm.com> Acked-by: Jason J. Herne <jjhe...@linux.ibm.com> Tested-by: Jason J. Herne <jjhe...@linux.ibm.com> --- hw/s390x/css.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/hw/s390x/css.c b/hw/s390x/css.c index 32f1b2820d.

[Qemu-devel] [PATCH 1/2] vfio-ccw: add force unlimited prefetch property

only. But vfio-ccw can not provide the guarantees required if the bit is not set. Since it is impossible to implement support for P bit not set (at impossible least without transitioning to lower level protocols) in vfio-ccw let's provide a manual override. Signed-off-by: Halil Pasic <

[Qemu-devel] [PATCH 0/2] vfio-ccw: loosen orb flags checks

See the individual patches. The second one makes even more sense with the corresponding kernel patch. Halil Pasic (2): vfio-ccw: add force unlimited prefetch property vfio-ccw: remove orb.c64 (64 bit data addresses) check hw/s390x/css.c | 12 hw/vfio/ccw.c | 13

Re: [Qemu-devel] [PATCH v5 4/6] s390x/vfio: ap: Introduce VFIO AP device

On 05/08/2018 02:25 PM, Tony Krowiak wrote: Introduces a VFIO based AP device. The device is defined via the QEMU command line by specifying: -device vfio-ap,sysfsdev= There may be only one vfio-ap device configured for a guest. The mediated matrix device is created by the VFIO AP

Re: [Qemu-devel] [PATCH 0/2] s390x: reset handling for ccw devices

On 05/08/2018 03:55 PM, Cornelia Huck wrote: On Tue, 8 May 2018 15:29:50 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: On 05/07/2018 05:51 PM, Cornelia Huck wrote: On Friday, Thomas noticed some problems with 3270 devices. One result was "s390x/css: disabled subchannels canno

Re: [Qemu-devel] [PATCH v5 6/6] MAINTAINERS: add entries for AP

1 files changed, 14 insertions(+), 0 deletions(-) [..] +M: Christian Borntraeger <borntrae...@de.ibm.com> +M: Tony Krowiak <akrow...@linux.vnet.ibm.com> +M: Halil Pasic <pa...@linux.vnet.ibm.com> +M: Pierre Morel <pmo...@linux.vnet.ibm.com> Dumb question:

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

istian Borntraeger <borntrae...@de.ibm.com> Signed-off-by: Cornelia Huck <coh...@redhat.com> Reviewed-by: Halil Pasic <pa...@linux.ibm.com> The 'all' from the subject is actually 'all except maybe vfio-ccw' AFAIU. [..]

Re: [Qemu-devel] [qemu-s390x] [PATCH 1/2] virtio-ccw: common reset handler

On 05/07/2018 05:51 PM, Cornelia Huck wrote: All the different virtio ccw devices use the same reset handler, so let's move setting it into the base virtio ccw device class. Signed-off-by: Cornelia Huck <coh...@redhat.com> Reviewed-by: Halil Pasic <pa...@linux.ibm.com> --

Re: [Qemu-devel] [PATCH 0/2] s390x: reset handling for ccw devices

On 05/07/2018 05:51 PM, Cornelia Huck wrote: On Friday, Thomas noticed some problems with 3270 devices. One result was "s390x/css: disabled subchannels cannot be status pending", but a reboot did not cure the previous broken status. Turns out that 3270 devices are missing a reset handler.

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

On 05/07/2018 12:12 PM, Cornelia Huck wrote: On Fri, 4 May 2018 17:02:07 +0200 Halil Pasic <pa...@linux.ibm.com> wrote: Could we somehow get 'fix' or something similar into the title? Frankly, I have no idea how to do so in a readable way. OK. Neither do I have a competitive c

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

with. And I guess vfio-ccw is also unaffected, as the passed through stuff is going to handle this correctly on the lower levels. Reported-by: Thomas Huth <th...@redhat.com> Signed-off-by: Cornelia Huck <coh...@redhat.com> Overall I agree with the patch. Acked-by: Hal

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

On 04/22/2018 05:43 PM, Tony Krowiak wrote: +FEAT_INIT_MISC("ap", "AP facilities installed"), Why plural ('facilities')? Would not s/facilities/instructions be more end-user friendly? It's a matter of opinion. I prefer facilities because AP is comprised of not  only instructions, but 

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

On 04/22/2018 05:52 PM, Tony Krowiak wrote: +    FEAT_INIT("apqci", S390_FEAT_TYPE_STFL, 12, "Query AP Configuration  facility"), Why did you change this form qci to apqci. Too may people found the qci good? I changed it by request and I thought it made sense to do so. Maybe we should 

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

On 04/15/2018 09:07 PM, Tony Krowiak wrote: A new CPU model feature and two new CPU model facilities are introduced to support AP devices for a KVM guest. [..] diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c index 3b9e274..5ee3a2d 100644 ---

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> Reviewed-by: Halil Pasic <pa...@linux.vnet.ibm.com>

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

On 04/13/2018 05:50 PM, Thomas Huth wrote: > On 13.04.2018 17:28, Halil Pasic wrote: >> >> On 04/13/2018 04:30 PM, Thomas Huth wrote: >>> "size_t" should be an unsigned type - the signed counterpart is called >>> "ssize_t" in the C standa

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

th this change. > > Buglink: https://bugs.launchpad.net/qemu/+bug/1753437 > Signed-off-by: Thomas Huth <th...@redhat.com> > --- This is certainly an improvement over the confusing signed size_t, so: Acked-by: Halil Pasic <pa...@linux.vnet.ibm.com> BTW The stuff beh

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/11/2018 03:20 PM, Tony Krowiak wrote: I may be all wrong, though... can we at least have a translation of ECA.28 and EECA.28 (the "ap is there" bit and the "ap instructions are interpreted" bit?)    >>> I think we have a misunderstanding here. I will wait for Tony. 

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/09/2018 11:32 AM, Cornelia Huck wrote: >> We can kind of (i.e. modulo EECA.28) ensure this in a different fashion I >> think. How >> about proclaiming a 'has ap instructions, but nothing to see here' in the >> SIE interpreted flavor (ECA.28 set) the default way of having ap instructions

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/05/2018 06:38 PM, Tony Krowiak wrote: > On 04/03/2018 05:36 AM, Cornelia Huck wrote: >> On Mon, 2 Apr 2018 12:36:27 -0400 >> Tony Krowiak  wrote: >> >>> On 03/26/2018 05:03 AM, Pierre Morel wrote: On 26/03/2018 10:32, David Hildenbrand wrote: > On 

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/06/2018 02:09 PM, Halil Pasic wrote: > Yes it is conceptually ugly. I'm 100% with you. That's why it should go > away soon. From the practicality perspective however I would even argue that > it's > helpful to the user: tells 'oops you have forgotten something'. IMHO >

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/06/2018 11:11 AM, David Hildenbrand wrote: > On 06.04.2018 10:40, Cornelia Huck wrote: >> On Thu, 5 Apr 2018 19:17:47 +0200 >> Halil Pasic <pa...@linux.vnet.ibm.com> wrote: >> >>> On 04/05/2018 06:38 PM, Tony Krowiak wrote: >>>>

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/05/2018 06:38 PM, Tony Krowiak wrote: >> Hard to really give good advice without access to the documentation, but: >> - If we tell the guest that the feature is available, but it does not >>    get any cards to use, returning an empty matrix makes the most sense >>    to me. >> - I would 

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 04/04/2018 10:12 PM, Tony Krowiak wrote: > On 04/04/2018 09:43 AM, Pierre Morel wrote: >> On 04/04/2018 15:33, Tony Krowiak wrote: >>> On 04/04/2018 07:09 AM, Pierre Morel wrote: On 02/04/2018 18:36, Tony Krowiak wrote: > On 03/26/2018 05:03 AM, Pierre Morel wrote: >> On

Re: [Qemu-devel] [PATCH v3 6/7] s390x/kvm: handle AP instruction interception

On 03/26/2018 11:03 AM, Pierre Morel wrote: >>> +int ap_device_handle_pqap(S390CPU *cpu) >>> +{ >>> +CPUS390XState *env = >env; >>> +int fc = 4 & (env->regs[0] >> 24); >>> + >>> +/* >>> + * The Query Configuration Information (QCI) function (fc == 4) does  >>> not >>> + * set 

Re: [Qemu-devel] [virtio-dev] Re: [v23 1/2] virtio-crypto: Add virtio crypto device specification

On 03/16/2018 05:27 PM, Michael S. Tsirkin wrote: > On Tue, Jan 09, 2018 at 06:05:41PM +0100, Halil Pasic wrote: >>> +\item[\field{max_cipher_key_len}] is the maximum length of cipher key >>> supported by the device. >> >> I can't find what happens if this

Re: [Qemu-devel] [PATCH v3 5/7] s390x/vfio: ap: Introduce VFIO AP device

On 03/16/2018 04:53 PM, Tony Krowiak wrote: > On 03/16/2018 11:36 AM, Halil Pasic wrote: >> >> On 03/16/2018 04:29 PM, Tony Krowiak wrote: >>>>> However it is a general switch for the VM. >>>>> It looks strange to have this inside the rea

Re: [Qemu-devel] [PATCH v3 5/7] s390x/vfio: ap: Introduce VFIO AP device

On 03/16/2018 04:29 PM, Tony Krowiak wrote: >>> However it is a general switch for the VM. >>> It looks strange to have this inside the realize callback >>> >> I kind of semi agree. >> >> The previous solution (having this transparent for QEMU) had >> benefits. Why did we move away from that 

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