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: Christian Borntraeger
Subject: Re: [PATCH 1/7] pc-bios: s390x: Fix bootmap.c zipl component entry data handling
Date: Wed, 22 Jul 2020 09:33:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0


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. 



reply via email to

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