diff options
| author | Halil Pasic | 2018-05-24 19:58:27 +0200 |
|---|---|---|
| committer | Cornelia Huck | 2018-06-18 10:50:32 +0200 |
| commit | 9a51c9ee6ca6610e4ab89945e6c75eda3a265ceb (patch) | |
| tree | a7ffc640ea034f56611d60fdba8d5e80f1d5b51f /scripts/switch-timer-api | |
| parent | virtio-ccw: clean up notify (diff) | |
| download | qemu-9a51c9ee6ca6610e4ab89945e6c75eda3a265ceb.tar.gz qemu-9a51c9ee6ca6610e4ab89945e6c75eda3a265ceb.tar.xz qemu-9a51c9ee6ca6610e4ab89945e6c75eda3a265ceb.zip | |
vfio-ccw: add force unlimited prefetch property
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 not possible to implement support for the P bit not set without
transitioning to lower level protocols for vfio-ccw. So let's give the
user the opportunity to force setting the P bit, if the user knows this
is safe. For self modifying channel programs forcing the P bit is not
safe. If the P bit is forced for a self modifying channel program things
are expected to break in strange ways.
Let's also avoid warning multiple about P bit not set in the ORB in case
P bit is not told to be forced, and designate the affected vfio-ccw
device.
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>
Message-Id: <20180524175828.3143-2-pasic@linux.ibm.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Diffstat (limited to 'scripts/switch-timer-api')
0 files changed, 0 insertions, 0 deletions
