* Cornelia Huck <coh...@redhat.com> [2017-09-08 11:59:50 +0200]: > On Fri, 8 Sep 2017 11:21:57 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> 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. Is this understanding right? If so, I'm fine with that, and I can provide the fix in the kernel. > > That makes sense to me. > -- Dong Jia Shi
