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: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH 4/9] s390x: refactor error handling for SSCH and RSCH
Date: Fri, 8 Sep 2017 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.

> 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?
> 




reply via email to

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