qemu-devel
[Top][All Lists]
Advanced

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

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


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH v3 2/3] pc-bios/s390-ccw/net: Use diag308 to reset machine before jumping to the OS
Date: Wed, 25 Apr 2018 14:44:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0


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
$ git grep 0x10000
boot/head.S:.Lstack: .long  0x10000-160
boot/stage2dump.c:      if (prefix < 0x10000) /* if < linux-start addr */
boot/tape0.S:KERNEL_OFF         = 0x10000               # kernel start code 
offset
boot/tape0.S:KERNEL_ADDR                = 0x10000               # default 
kernel load addr
include/zipl.h:#define DEFAULT_IMAGE_ADDRESS            0x10000LL
include/zipl.h:#define MINIMUM_ADDRESS          0x10000LL
src/bootmap.c:          size += DIV_ROUND_UP(st.st_size - 0x10000,
src/job.c:                          &ipl->image_addr, 0, 0x10000,
src/job.c:                      &ipl->ramdisk_addr, 0, 0, 0x10000);
src/job.c:                          &dump->image_addr, 0, 0x10000,
src/job.c:                                  0, 0, 0x10000);
src/job.c:                          &ipl_tape->image_addr, 0, 0x10000,
src/job.c:                                  0, 0, 0x10000);




reply via email to

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