From: Halil Pasic <pasic@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
Dong Jia Shi <bjsdjshi@linux.ibm.com>,
"Jason J. Herne" <jjherne@linux.ibm.com>,
qemu-s390x@nongnu.org, qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH v2 1/2] vfio-ccw: add force unlimited prefetch property
Date: Wed, 23 May 2018 00:16:54 +0200 [thread overview]
Message-ID: <20180522221655.78979-2-pasic@linux.ibm.com> (raw)
In-Reply-To: <20180522221655.78979-1-pasic@linux.ibm.com>
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 the machine.
Usually this ain't a big deal, as the original purpose of the P bit is to
allow for performance optimizations. vfio-ccw however can not provide the
guarantees required if the bit is not set.
It is impossible to implement support for P bit not set (at impossible
least without transitioning to lower level protocols) for vfio-ccw. So
let's give the user the opportunity to force the 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 <pasic@linux.ibm.com>
Suggested-by: Dong Jia Shi <bjsdjshi@linux.ibm.com>
Acked-by: Jason J. Herne <jjherne@linux.ibm.com>
Tested-by: Jason J. Herne <jjherne@linux.ibm.com>
---
v1 -> v2:
* reworded commit message
* re-factored the code (Connie)
* added warning when the P bit is forced the first time (Connie)
---
hw/s390x/css.c | 3 +--
hw/vfio/ccw.c | 25 +++++++++++++++++++++++++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 56c3fa8c89..39ae5bbf7e 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -1204,8 +1204,7 @@ static IOInstEnding sch_handle_start_func_passthrough(SubchDev *sch)
* Only support prefetch enable mode.
* Only support 64bit addressing idal.
*/
- if (!(orb->ctrl0 & ORB_CTRL0_MASK_PFCH) ||
- !(orb->ctrl0 & ORB_CTRL0_MASK_C64)) {
+ if (!(orb->ctrl0 & ORB_CTRL0_MASK_C64)) {
warn_report("vfio-ccw requires PFCH and C64 flags set");
sch_gen_unit_exception(sch);
css_inject_io_interrupt(sch);
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index e67392c5f9..62de4c9710 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -32,8 +32,20 @@ typedef struct VFIOCCWDevice {
uint64_t io_region_offset;
struct ccw_io_region *io_region;
EventNotifier io_notifier;
+ bool force_orb_pfch;
+ bool warned_force_orb_pfch;
} VFIOCCWDevice;
+#define WARN_ONCE(warned, fmt...) \
+({\
+if (!(warned)) {\
+ warn_report((fmt));\
+} \
+warned = true;\
+})
+
+
+
static void vfio_ccw_compute_needs_reset(VFIODevice *vdev)
{
vdev->needs_reset = false;
@@ -54,6 +66,18 @@ static IOInstEnding vfio_ccw_handle_request(SubchDev *sch)
struct ccw_io_region *region = vcdev->io_region;
int ret;
+ 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);
+ return IOINST_CC_EXPECTED;
+ } else {
+ sch->orb.ctrl0 |= ORB_CTRL0_MASK_PFCH;
+ WARN_ONCE(vcdev->warned_force_orb_pfch, "PFCH flag forced");
+ }
+ }
+
QEMU_BUILD_BUG_ON(sizeof(region->orb_area) != sizeof(ORB));
QEMU_BUILD_BUG_ON(sizeof(region->scsw_area) != sizeof(SCSW));
QEMU_BUILD_BUG_ON(sizeof(region->irb_area) != sizeof(IRB));
@@ -429,6 +453,7 @@ static void vfio_ccw_unrealize(DeviceState *dev, Error **errp)
static Property vfio_ccw_properties[] = {
DEFINE_PROP_STRING("sysfsdev", VFIOCCWDevice, vdev.sysfsdev),
+ DEFINE_PROP_BOOL("force-orb-pfch", VFIOCCWDevice, force_orb_pfch, false),
DEFINE_PROP_END_OF_LIST(),
};
--
2.16.3
next prev parent reply other threads:[~2018-05-22 22:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-22 22:16 [Qemu-devel] [PATCH v2 0/2] vfio-ccw: loosen orb flags checks Halil Pasic
2018-05-22 22:16 ` Halil Pasic [this message]
2018-05-23 9:37 ` [Qemu-devel] [PATCH v2 1/2] vfio-ccw: add force unlimited prefetch property Cornelia Huck
2018-05-23 14:31 ` [Qemu-devel] [qemu-s390x] " Halil Pasic
2018-05-23 14:46 ` Cornelia Huck
2018-05-23 16:23 ` Halil Pasic
2018-05-23 16:59 ` Cornelia Huck
2018-05-23 17:28 ` Halil Pasic
2018-05-24 7:16 ` Cornelia Huck
2018-05-24 10:29 ` Halil Pasic
2018-05-24 10:33 ` Cornelia Huck
2018-05-24 15:42 ` Halil Pasic
2018-05-24 16:05 ` Cornelia Huck
2018-05-22 22:16 ` [Qemu-devel] [PATCH v2 2/2] vfio-ccw: remove orb.c64 (64 bit data addresses) check Halil Pasic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180522221655.78979-2-pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=bjsdjshi@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=jjherne@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).