This 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
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 b
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
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 th
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 subsy
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
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
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:
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:
> vfio
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
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
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
> &
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
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 vfio-ccw-cap
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
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
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
> AP
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 reported
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 vfio-ccw-caps
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
gure 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 +
> d
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
the AP 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 fi
if APFT is installed
>on the host.
>
> Signed-off-by: Tony Krowiak
> Tested-by: Pierre Morel
Reviewed-by: Halil Pasic
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 = vfio_
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
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
>>> ---
>
>
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 lock
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 virtua
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
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
27;ve seen 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:0
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 A,B,C,
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|
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 theor
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 per
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
"
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, &orb);
+if (rc) {
+print_int("
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;
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
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
a
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, msc
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
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) |
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 ca
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
-
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 this to
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
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 of
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
On 05/25/2018 11:40 AM, 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 this to
.
Signed-off-by: Halil Pasic
Acked-by: Jason J. Herne
Tested-by: Jason J. Herne
---
hw/s390x/css.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 39ae5bbf7e..5424ea4562 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -1199,17 +1199,6
not told to be forced, and designate the affected vfio-ccw
device.
Signed-off-by: Halil Pasic
Suggested-by: Dong Jia Shi
Acked-by: Jason J. Herne
Tested-by: Jason J. Herne
---
@Jason:
I have kept the tags this time without consulting you because
all that changed is the logging. Scream if that&#x
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
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 wrote:
On 05/23/2018 06:59 PM, Cornelia Huck wrote:
On Wed, 23 May 2018 18:23:44 +0200
Halil Pasic wrote:
On 05/23/2018 04:46 PM, Cornelia Huck wrote
On 05/24/2018 09:16 AM, Cornelia Huck wrote:
On Wed, 23 May 2018 19:28:31 +0200
Halil Pasic wrote:
On 05/23/2018 06:59 PM, Cornelia Huck wrote:
On Wed, 23 May 2018 18:23:44 +0200
Halil Pasic wrote:
On 05/23/2018 04:46 PM, Cornelia Huck wrote:
+if (!(sch->orb.ct
On 05/23/2018 06:59 PM, Cornelia Huck wrote:
On Wed, 23 May 2018 18:23:44 +0200
Halil Pasic wrote:
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 req
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);
+
On 05/23/2018 11:37 AM, Cornelia Huck wrote:
On Wed, 23 May 2018 00:16:54 +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 this to
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
e P bit 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
Suggested-by: Dong Jia Shi
Acked-by: Jason J. Herne
.
Signed-off-by: Halil Pasic
Acked-by: Jason J. Herne
Tested-by: Jason J. Herne
---
v1 -> v2: unchanged
---
hw/s390x/css.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 39ae5bbf7e..5424ea4562 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/cs
On 05/17/2018 05:26 PM, Cornelia Huck wrote:
On Wed, 16 May 2018 15:27:57 +0200
Halil Pasic 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 to me.
I wanted to co
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.
C
On 05/14/2018 06:04 PM, Cornelia Huck wrote:
On Mon, 14 May 2018 16:22:30 +0200
Halil Pasic wrote:
On 05/14/2018 03:45 PM, Cornelia Huck wrote:
On Mon, 14 May 2018 14:40:13 +0200
Halil Pasic wrote:
On 05/14/2018 02:18 PM, Cornelia Huck wrote:
On Thu, 10 May 2018 02:07:11 +0200
Halil
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
Fixes: CID 1390619
Signed-off-by: Halil Pasic
---
hw/s390x/virtio-ccw.c | 13 +
1 file changed, 9 inser
On 05/15/2018 04:01 PM, Cornelia Huck wrote:
On Tue, 15 May 2018 15:17:51 +0200
Halil Pasic wrote:
8<
From: Halil Pasic
Date: Tue, 15 May 2018 13:57:44 +0200
Subject: [PATCH] WIP: cleanup virtio notify
Sig
On 05/15/2018 02:07 PM, Peter Maydell wrote:
On 15 May 2018 at 13:00, Halil Pasic 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
Date: Tue, 15 May 2018 13:57:44 +0200
Subject: [PATCH
t indicators). We 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<---
F
On 05/14/2018 03:45 PM, Cornelia Huck wrote:
On Mon, 14 May 2018 14:40:13 +0200
Halil Pasic wrote:
On 05/14/2018 02:18 PM, Cornelia Huck wrote:
On Thu, 10 May 2018 02:07:11 +0200
Halil Pasic wrote:
There is at least one control program (guest) that although it does not
I'd
On 05/14/2018 02:18 PM, Cornelia Huck wrote:
On Thu, 10 May 2018 02:07:11 +0200
Halil Pasic 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.
Will do (everywh
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 a
.
Signed-off-by: Halil Pasic
Acked-by: Jason J. Herne
Tested-by: Jason J. Herne
---
hw/s390x/css.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 32f1b2820d..1554b4c2f5 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -1191,17 +1191,6
tions 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
Su
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
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 devic
On 05/08/2018 03:55 PM, Cornelia Huck wrote:
On Tue, 8 May 2018 15:29:50 +0200
Halil Pasic 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 cannot be status pending", bu
(-)
[..]
+M: Christian Borntraeger
+M: Tony Krowiak
+M: Halil Pasic
+M: Pierre Morel
Dumb question: Aren't you folks dropping the 'vnet' part in the future?
Not dumb at all. Please drop 'vnet' (at least for me).
[..]
igned-off-by: Cornelia Huck
Reviewed-by: Halil Pasic
The 'all' from the subject is actually 'all except maybe vfio-ccw'
AFAIU.
[..]
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
Reviewed-by: Halil Pasic
---
hw/s390x/virtio-ccw.c | 13 +
[..]
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.
This
On 05/07/2018 12:12 PM, Cornelia Huck wrote:
On Fri, 4 May 2018 17:02:07 +0200
Halil Pasic 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 counter proposal.
disabled device to begin 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
Signed-off-by: Cornelia Huck
Overall I agree with the patch.
Acked-by: Halil Pasic
---
hw/s390x/css.c | 8
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 al
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
just
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
--- a/target/s390x/cpu_features.
all be fine with this change.
>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1753437
> Signed-off-by: Thomas Huth
Reviewed-by: Halil Pasic
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
th this change.
>
> Buglink: https://bugs.launchpad.net/qemu/+bug/1753437
> Signed-off-by: Thomas Huth
> ---
This is certainly an improvement over the confusing signed size_t, so:
Acked-by: Halil Pasic
BTW The stuff behind the buglink is a bit misleading. The description
states
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. Mayb
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
>>
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 16.03.2018 00:24, Tony Krowiak wro
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 somet
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 wrote:
>>
>>> On 04/05/2018 06:38 PM, Tony Krowiak wrote:
>>>>> Hard to really give good advice without
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 no
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 26/03/201
On 03/26/2018 11:03 AM, Pierre Morel wrote:
>>> +int ap_device_handle_pqap(S390CPU *cpu)
>>> +{
>>> +CPUS390XState *env = &cpu->env;
>>> +int fc = 4 & (env->regs[0] >> 24);
>>> +
>>> +/*
>>> + * The Query Configuration Information (QCI) function (fc == 4) does
>>> not
>>> + *
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
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
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 agai
301 - 400 of 1027 matches
Mail list logo
