On Fri, 8 Sep 2017 11:41:00 +0800 Dong Jia Shi <bjsdj...@linux.vnet.ibm.com> wrote:
> 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... It's not odd at all, if you consider these as two stages: - Initial acceptance of the command, set cc 0 to indicate you got it. - Execution of the start function. This can then fail, of course. > 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(). Probably, yes. > > 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? >
