qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 1/7] pc-bios: s390x: Fix bootmap.c zipl component entry data


From: Janosch Frank
Subject: Re: [PATCH 1/7] pc-bios: s390x: Fix bootmap.c zipl component entry data handling
Date: Wed, 22 Jul 2020 10:06:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 7/22/20 9:33 AM, Christian Borntraeger wrote:
> 
> 
> On 22.07.20 09:30, Janosch Frank wrote:
>> On 7/22/20 8:50 AM, Christian Borntraeger wrote:
>>>
>>>
>>> On 15.07.20 11:40, Janosch Frank wrote:
>>>> The two main types of zipl component entries are execute and
>>>> load/data. The last member of the component entry struct therefore
>>>> denotes either a PSW or an address. Let's make this a bit more clear
>>>> by introducing a union and cleaning up the code that uses that struct
>>>> member.
>>>>
>>>> The execute type component entries written by zipl contain short PSWs,
>>>> not addresses. Let's mask them and only pass the address part to
>>>> jump_to_IPL_code(uint64_t address) because it expects an address as
>>>> visible by the name of the argument.
>>>
>>> If zipl actually specifies a PSW, shouldnt we actually USE that PSW 
>>> including
>>> the zipl specified mask?
>>
>> I expected the current approach to have some kind of meaning behind it,
>> if there isn't I'll be the first one to make it more sensible.
> I think this was just something to make it work with Linux, especially when 
> Linux
> still started in ESA mode.(So we faked a mask that is good enough to boot 
> Linux and
> then used the address). But I think the proper solution is to really use the 
> full PSW and go with that according to the CZAM rules. 
> 

Okay, I'll come up with a proper fix.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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