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

[Cornelia Huck]

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
> device.
> 
> 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>
> ---
> 
> @Jason:
> 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.
> 
> v2->v3:
> * 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.