* Halil Pasic [2017-09-25 12:57:31 +0200]:
[restored Cc:]
>
>
> On 09/25/2017 09:31 AM, Dong Jia Shi wrote:
> > * Cornelia Huck [2017-09-08 11:59:50 +0200]:
> >
> >> On Fri, 8 Sep 2017 11:21:57 +0200
> >> Halil Pasic wrote:
> >>
> >>> On 09/08/2017 05:41 AM, Dong Jia Shi wrote:
> Let'
On 09/25/2017 09:31 AM, Dong Jia Shi wrote:
> * Cornelia Huck [2017-09-08 11:59:50 +0200]:
>
>> On Fri, 8 Sep 2017 11:21:57 +0200
>> Halil Pasic 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 c
* Cornelia Huck [2017-09-08 11:59:50 +0200]:
> On Fri, 8 Sep 2017 11:21:57 +0200
> Halil Pasic 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.
> > >
* Cornelia Huck [2017-09-08 12:02:38 +0200]:
> On Fri, 8 Sep 2017 11:41:00 +0800
> Dong Jia Shi 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
On Fri, 8 Sep 2017 11:41:00 +0800
Dong Jia Shi 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 t
On Fri, 8 Sep 2017 11:21:57 +0200
Halil Pasic 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
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
>+
>upda
* Cornelia Huck [2017-09-07 13:41:34 +0200]:
> On Thu, 7 Sep 2017 13:32:41 +0200
> Halil Pasic 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 appropri
On Thu, 7 Sep 2017 13:32:41 +0200
Halil Pasic 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 prob
On 09/07/2017 12:24 PM, Cornelia Huck wrote:
> On Thu, 7 Sep 2017 16:58:31 +0800
> Dong Jia Shi wrote:
>
>> * Halil Pasic [2017-09-06 16:43:42 +0200]:
>>
>>>
>>>
>>> On 09/06/2017 04:20 PM, Cornelia Huck wrote:
On Wed, 6 Sep 2017 14:25:13 +0200
Halil Pasic wrote:
> We
On Thu, 7 Sep 2017 16:58:31 +0800
Dong Jia Shi wrote:
> * Halil Pasic [2017-09-06 16:43:42 +0200]:
>
> >
> >
> > On 09/06/2017 04:20 PM, Cornelia Huck wrote:
> > > On Wed, 6 Sep 2017 14:25:13 +0200
> > > Halil Pasic wrote:
> > >
> > >> We have basically two possibilities/options which a
On 09/07/2017 10:58 AM, Dong Jia Shi wrote:
> * Halil Pasic [2017-09-06 16:43:42 +0200]:
>
>>
>>
>> On 09/06/2017 04:20 PM, Cornelia Huck wrote:
>>> On Wed, 6 Sep 2017 14:25:13 +0200
>>> Halil Pasic wrote:
>>>
We have basically two possibilities/options which ask for different
handli
* Halil Pasic [2017-09-06 16:43:42 +0200]:
>
>
> On 09/06/2017 04:20 PM, Cornelia Huck wrote:
> > On Wed, 6 Sep 2017 14:25:13 +0200
> > Halil Pasic wrote:
> >
> >> We have basically two possibilities/options which ask for different
> >> handling:
> >> 1) EFAULT is due to a bug in the vfio-ccw
On 09/06/2017 04:20 PM, Cornelia Huck wrote:
> On Wed, 6 Sep 2017 14:25:13 +0200
> Halil Pasic wrote:
>
>> We have basically two possibilities/options which ask for different
>> handling:
>> 1) EFAULT is due to a bug in the vfio-ccw implementation
>> (can be QEMU or kernel).
>> 2) EFAULT is due
On Wed, 6 Sep 2017 14:25:13 +0200
Halil Pasic wrote:
> We have basically two possibilities/options which ask for different
> handling:
> 1) EFAULT is due to a bug in the vfio-ccw implementation
> (can be QEMU or kernel).
> 2) EFAULT is due to buggy channel program.
>
> Option 2) is basically to
On 09/06/2017 06:31 AM, Dong Jia Shi wrote:
> * Halil Pasic [2017-09-06 00:30:58 +0200]:
>
> [...]
>
>>>
But I guess, I was afraid of somebody blaming me for this
comment (such TODOs in production code are a bit strange -- what
does it mean: we did not bother to figure it out?).
* Halil Pasic [2017-09-06 00:30:58 +0200]:
[...]
> >
> >> But I guess, I was afraid of somebody blaming me for this
> >> comment (such TODOs in production code are a bit strange -- what
> >> does it mean: we did not bother to figure it out?).
> >
> > For one, the TODO is preexisting... and we
On 09/05/2017 06:25 PM, Cornelia Huck wrote:
> On Tue, 5 Sep 2017 17:55:17 +0200
> Halil Pasic wrote:
>
>> On 08/31/2017 11:55 AM, Cornelia Huck wrote:
>>> On Wed, 30 Aug 2017 18:36:04 +0200
>>> Halil Pasic wrote:
>>>
Simplify the error handling of the SSCH and RSCH handler avoiding
>>
On Tue, 5 Sep 2017 17:55:17 +0200
Halil Pasic wrote:
> On 08/31/2017 11:55 AM, Cornelia Huck wrote:
> > On Wed, 30 Aug 2017 18:36:04 +0200
> > Halil Pasic wrote:
> >
> >> Simplify the error handling of the SSCH and RSCH handler avoiding
> >> arbitrary and cryptic error codes being mapped to w
On 08/31/2017 11:55 AM, Cornelia Huck wrote:
> On Wed, 30 Aug 2017 18:36:04 +0200
> Halil Pasic wrote:
>
>> Simplify the error handling of the SSCH and RSCH handler avoiding
>> arbitrary and cryptic error codes being mapped to what a subchannel is
>> supposed to do. Let the code detecting the
On Wed, 30 Aug 2017 18:36:04 +0200
Halil Pasic wrote:
> Simplify the error handling of the SSCH and RSCH handler avoiding
> arbitrary and cryptic error codes being mapped to what a subchannel is
> supposed to do. Let the code detecting the condition tell how it's to be
> handled in a less ambigu
Simplify the error handling of the SSCH and RSCH handler avoiding
arbitrary and cryptic error codes being mapped to what a subchannel is
supposed to do. Let the code detecting the condition tell how it's to be
handled in a less ambiguous way. It's best to handle SSCH and RSCH in
one go as the emu
22 matches
Mail list logo
