[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:31:59 +0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
* Cornelia Huck <address@hidden> [2017-09-08 11:59:50 +0200]:
> On Fri, 8 Sep 2017 11:21:57 +0200
> Halil Pasic <address@hidden> 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.
Is this understanding right? If so, I'm fine with that, and I can
provide the fix in the kernel.
>
> That makes sense to me.
>
--
Dong Jia Shi
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, (continued)
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Cornelia Huck, 2017/09/06
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Halil Pasic, 2017/09/06
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Dong Jia Shi, 2017/09/07
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Halil Pasic, 2017/09/07
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Cornelia Huck, 2017/09/07
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Halil Pasic, 2017/09/07
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Cornelia Huck, 2017/09/07
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Dong Jia Shi, 2017/09/07
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Halil Pasic, 2017/09/08
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Cornelia Huck, 2017/09/08
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH,
Dong Jia Shi <=
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Halil Pasic, 2017/09/25
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Dong Jia Shi, 2017/09/27
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Cornelia Huck, 2017/09/08
- Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH, Dong Jia Shi, 2017/09/25