qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to res


From: Thomas Huth
Subject: Re: [qemu-s390x] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS
Date: Wed, 25 Apr 2018 17:36:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

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.

 Thomas



reply via email to

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