Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS

[Christian Borntraeger]

On 04/26/2018 05:43 AM, Thomas Huth wrote:
> On 25.04.2018 18:03, Christian Borntraeger wrote:
>>
>>
>> On 04/25/2018 05:36 PM, Thomas Huth wrote:
>>> On 25.04.2018 14:44, Christian Borntraeger wrote:
>>>>
>>>>
>>>> On 04/25/2018 02:41 PM, Christian Borntraeger wrote:
>>>>> You load from address 0. 
>>>>>
>>>>> On 04/25/2018 02:34 PM, Thomas Huth wrote:
>>>>>> On 25.04.2018 14:18, Christian Borntraeger wrote:
>>>>>>>
>>>>>>> On 04/25/2018 11:08 AM, Thomas Huth wrote:
>>>>>>>
>>>>>>>> --- a/pc-bios/s390-ccw/netmain.c
>>>>>>>> +++ b/pc-bios/s390-ccw/netmain.c
>>>>>>>> @@ -283,6 +283,15 @@ void panic(const char *string)
>>>>>>>>      }
>>>>>>>>  }
>>>>>>>>  
>>>>>>>> +void write_subsystem_identification(void)
>>>>>>>> +{
>>>>>>>> +    uint32_t *schid = (uint32_t *) 184;
>>>>>>>> +    uint32_t *zeroes = (uint32_t *) 188;
>>>>>>>> +
>>>>>>>> +    *schid = 0;         /* We must not set this for virtio-net */
>>>>>>>> +    *zeroes = 0;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>
>>>>>>> I think we actually want to have the CCW devno of that network device
>>>>>>> stored. It has some value to know which CCW device we bootet from, no?
>>>>>>
>>>>>> Actually, I tried that first (and it took quite some time to debug it),
>>>>>> but the Linux kernel then bails out quite early, without any error
>>>>>> message. The trace looks like this:
>>>>>>
>>>>>> 0x0000000007801802:  diag        %r1,%r1,776
>>>>>> 0x0000000007801780:  larl        %r2,0x7831004
>>>>>> 0x0000000007801786:  llgf        %r1,8
>>>>>> 0x000000000780178c:  mvc 0(12,%r0),0(%r2)
>>>>>> 0x0000000007801792:  br  %r1
>>>>>> 0x0000000000000418:  bas %r14,512
>>>>>> 0x0000000000000200:  mvi 163,1
>>>>>> 0x0000000000000204:  slr %r0,%r0
>>>>>> 0x0000000000000206:  lhi %r1,2
>>>>>> 0x000000000000020a:  sigp        %r1,%r0,18
>>>>>> 0x000000000000020e:  bras        %r13,0x252
>>>>>> 0x0000000000000252:  lmh %r0,%r15,0(%r13)
>>>>>> 0x0000000000000258:  sam31
>>>>>> 0x000000000000025a:  br  %r14
>>>>>> 0x000000000000041c:  lh  %r1,184
>>>>>> 0x0000000000000420:  bct %r1,1322
>>>>>> 0x0000000000000424:  l   %r1,184
>>>>>> 0x0000000000000428:  la  %r2,1840
>>>>>> 0x000000000000042c:  bas %r14,640
>>>>>> 0x0000000000000280:  la  %r4,0(%r14)
>>>>>> 0x0000000000000284:  la  %r3,792
>>>>>> 0x0000000000000288:  la  %r5,804
>>>>>> 0x000000000000028c:  la  %r6,888
>>>>>> 0x0000000000000290:  la  %r7,20
>>>>>> 0x0000000000000294:  st  %r2,4(%r6)
>>>>>> 0x0000000000000298:  la  %r2,80(%r2)
>>>>>> 0x000000000000029c:  la  %r6,8(%r6)
>>>>>> 0x00000000000002a0:  bct %r7,660
>>>>>> 0x00000000000002a4:  lctl        %c6,%c6,868
>>>>>> 0x00000000000002a8:  slr %r2,%r2
>>>>>> 0x00000000000002aa:  ssch        0(%r3)
>>>>>> 0x00000000000002ae:  bne 786
>>>>>> 0x0000000000000312:  lpsw        880
>>>>>> Guest crashed on cpu 0: disabled-wait
>>>>>> PSW: 0x000a000000000000 0x0000000000000000
>>>>>>
>>>>>> That's the Lloader function in arch/s390/kernel/head.S which is failing
>>>>>> here, so seems like Linux tries to load from a block device in case
>>>>>> there is a value in 184. Thus I assume that 184 has to contain 0 in this
>>>>>> case.
>>>>>
>>>>> Hmm, I think this is because we jump to 418 for your kernel (which is the 
>>>>> loader
>>>>> that tries to bootstrap the ccw ipl). When you look at ipl.c we override 
>>>>> that
>>>>> and jump to 0x10000 instead for linux (which is also hackish) for image 
>>>>> files.
>>>>> So I guess if we would do a psw restart instead (like you do) on a kernel 
>>>>> image
>>>>> the normal ipl would also fail....
>>>>
>>>> FWIW, zipl also loads linux kernels from 0x10000
>>>
>>> OK, I just checked, and indeed, if I change to code to jump to 0x10000,
>>> it also works when setting a value into 184. So I'll change this patch
>>> here accordingly.
>>
>> This will of course break loading non-Linux binaries.
>> Could we maybe check 0x10008 for S390EP (see head.S) which indicates Linux 
>> since 3.2 or so
>> and only in that case change the address to 0x10000?
> 
> Sounds like a good idea! I assume load_iso_bc_entry() in bootmap.c
> should use that mechanism, too? And what about hw/s390/ipl.c, should we
> change the code there, too?

Yes, we should fix them all.