Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH

[Dong Jia Shi]

* Halil Pasic <address@hidden> [2017-09-25 12:57:31 +0200]:

[restored Cc:]

> 
> 
> On 09/25/2017 09:31 AM, Dong Jia Shi wrote:
> > * Cornelia Huck <address@hidden> [2017-09-08 11:59:50 +0200]:
> > 
> >> On Fri, 8 Sep 2017 11:21:57 +0200
> >> Halil Pasic <address@hidden> wrote:
> >>
> >>> On 09/08/2017 05:41 AM, Dong Jia Shi wrote:
> >>>> Let' me summarize here, in case I misunderstand things. Now we have
> >>>> two ways to choose:
> >>>>
> >>>> A. Kernel: no change.
> >>>>    Qemu  : handle -EFAULT as option 2 by generating a program check.
> >>>>
> >>>> B. Kernel: return -EFAULT
> >>>>            +
> >>>>            update the IRB area in the I/O region for option 1 to present
> >>>>            a unit check SCSW (with proper sense byte ECW), and for option
> >>>>            2 to present a program check.
> >>>>    Qemu  : handle -EFAULT according to the information that the IRB area
> >>>>            provided.  
> >>>
> >>> This is not what I was trying to say. You got my message regarding A, but
> >>> B was supposed to be understood like this.
> >>>
> >>> Keep the current handling for option 1, that is return -EFAULT. For option
> >>> 2 do what the spec says, execute the program until the bad address and 
> >>> then
> >>> generate a program-check (SCSW) once the bad stuff has it's turn. Thus
> >>> the only change in QEMU would be handling -EFAULT with an unit check 
> >>> (because
> >>> now it's just option 1).
> > Let me adding some context information here by copying some words from the
> > previous mail in this thread:
> > The only option 2 case in the kernel is ccwchain_fetch_idal() finding a
> > bad idaw_iova.
> > 
> > What you propose to do for this case is (correct me if I get it wrong):
> > In ccwchain_fetch_idal(), we do not return -EFAULT, instead we return 0,
> > and issuing the incompletely translated channel program with the bad
> > address to the physical device. And QEMU will eventually get the SCSW
> > with the program-check from the physical device I/O result, and inject
> > it to guest for further handling.
> > 
> 
> I guess that would be the cleanest. I would also be fine with not making
> the physical device program-check (issuing a shortened channel program,
> and doing the program check in software) but that's probably more
> complicated to implement.
That's far more complicated. I will try the simple approach.

> > Is this understanding right? If so, I'm fine with that, and I can
> > provide the fix in the kernel.
> > 
> 
> That would be nice.
Ok.

-- 
Dong Jia Shi