On 09/25/2017 09:31 AM, Dong Jia Shi wrote: > * Cornelia Huck <[email protected]> [2017-09-08 11:59:50 +0200]: > >> On Fri, 8 Sep 2017 11:21:57 +0200 >> Halil Pasic <[email protected]> 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. > Is this understanding right? If so, I'm fine with that, and I can > provide the fix in the kernel. > That would be nice. >> >> That makes sense to me. >> >
