* Cornelia Huck <coh...@redhat.com> [2017-09-08 12:02:38 +0200]: > 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. Ok. I got the idea!
> > > 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? > > > -- Dong Jia Shi
