[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [Qemu-devel] [PATCH v3 1/2] vfio-ccw: add force unlimit

From: Halil Pasic
Subject: Re: [qemu-s390x] [Qemu-devel] [PATCH v3 1/2] vfio-ccw: add force unlimited prefetch property
Date: Tue, 5 Jun 2018 13:16:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 06/05/2018 12:14 PM, Cornelia Huck wrote:
On Thu, 24 May 2018 19:58:27 +0200
Halil Pasic <address@hidden> 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 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

Signed-off-by: Halil Pasic <address@hidden>
Suggested-by: Dong Jia Shi <address@hidden>
Acked-by: Jason J. Herne <address@hidden>
Tested-by: Jason J. Herne <address@hidden>

I have kept the tags this time without consulting you because
all that changed is the logging. Scream if that's not OK with you.

* tweak commit message (Connie)
* designate subsystem (vfio-ccw) and devno in the log messages (Connie)
* turn WARN_ONCE macro into inline function

  hw/s390x/css.c |  3 +--
  hw/vfio/ccw.c  | 35 +++++++++++++++++++++++++++++++++++
  2 files changed, 36 insertions(+), 2 deletions(-)

How shall we proceed with this? I currently don't have much
(understatement of the year...) queued, so we could wait until we
hashed out where to go with _once logging (although the discussion
seems to have died down a bit). If I merge a respin of David's tcg
patches, however, I'd be inclined to merge this in the current form as
well and transition to a common _once handling later.

I'd prefer going ahead with this as is, and eventually transitioning
to common infrastructure when it's there.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]