* Cornelia Huck <coh...@redhat.com> [2017-09-07 13:41:34 +0200]: > On Thu, 7 Sep 2017 13:32:41 +0200 > Halil Pasic <pa...@linux.vnet.ibm.com> wrote: > > > On 09/07/2017 12:24 PM, Cornelia Huck wrote: > > > > So we would do an equipment check for the first two ("equipment", i.e. > > > the software, is malfunctioning) and use a more appropriate way for the > > > malformed idaw? > > > > > > > You have probably missed my previous email where I state something very > > similar (MID <2aa8cf98-c331-fe5a-0a7e-1a553c6c5...@linux.vnet.ibm.com>). > > There I say: if we change the kernel code, yes, if we don't I prefer a > > program check. > > Not missed, they crossed in mid-air. > > But I agree, the decision is Dong Jia's. > 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. I think the difficult part is in the Qemu side. For either A or B, in Qemu, we'd need to return a cc0 to indicate the channel program is accepted successfully by the device, and then update the virtual IRB and inject an I/O interrupt to notify the guest. The question is, now we need to map -EFAULT to cc0? This is too odd... And we need to find a proper place to do the interrupt injection. I guess it could be in the sch_handle_start_func_passthrough(). If we do not like such modification in the Qemu side, then A is not the way to go. And for B, we need to update the IRB area of the I/O region in the three cases listed in the former mail, and: 1. We need to set the ret_code as 0 for them, so that Qemu could map it to cc0. 2. We need to signal Qemu to fetch the IRB we generated with the checks. All of these are doable I think. Any comment for the above thoughts? -- Dong Jia Shi