qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and


From: Dong Jia Shi
Subject: Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH
Date: Mon, 25 Sep 2017 15:14:04 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

* Cornelia Huck <address@hidden> [2017-09-08 12:02:38 +0200]:

> On Fri, 8 Sep 2017 11:41:00 +0800
> Dong Jia Shi <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]