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: Fri, 8 Sep 2017 11:41:00 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

* Cornelia Huck <address@hidden> [2017-09-07 13:41:34 +0200]:

> On Thu, 7 Sep 2017 13:32:41 +0200
> Halil Pasic <address@hidden> 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  <address@hidden>).
> > 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




reply via email to

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