qemu-devel
[Top][All Lists]
Advanced

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

Re: [PULL 0/2] Fix for the s390-ccw bios


From: Thomas Huth
Subject: Re: [PULL 0/2] Fix for the s390-ccw bios
Date: Fri, 29 Nov 2019 13:07:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 29/11/2019 11.46, Peter Maydell wrote:
> On Fri, 29 Nov 2019 at 10:08, Thomas Huth <address@hidden> wrote:
>>
>>  Hi Peter,
>>
>> the following changes since commit 1a61a081ac33ae6cb7dd2e38d119a572f416c7f7:
>>
>>   Update version for v4.2.0-rc3 release (2019-11-26 21:52:26 +0000)
>>
>> are available in the Git repository at:
>>
>>   https://gitlab.com/huth/qemu.git tags/pull-request-2019-11-29
>>
>> for you to fetch changes up to bf876a688c9319b506d5ff1175ba7189cd933d91:
>>
>>   pc-bios/s390: Update firmware image with the "fix sclp_get_loadparm_ascii" 
>> patch (2019-11-29 10:12:33 +0100)
>>
>> ----------------------------------------------------------------
>> A fix for regression in the s390-ccw bios
>> ----------------------------------------------------------------
>>
>> ... it would be good to still get this into 4.2 if possible!
> 
> Well, it's possible, but this is currently the only thing
> that would need an rc4, so the question is how important
> is the regression and how safe is the fix? If it's just
> a minor corner case then it's tempting to not have an rc4
> unless we need it for some other reason.
> 
> Summary: it can go into 4.2 but you need to provide some
> rationale in the pullreq cover letter to make the case for it :-)

 Hi Peter,

without the fix, certain boot scenarios break:

- "-boot menu=on" does not work anymore.

- It's not possible anymore to specify the s390x-specific "loadparm"
  option (can be used e.g. with "-machine s390-ccw-virtio,loadparm=xyz")
  This is e.g. important for booting alternate kernel that are installed
  on the guest's hard disk image.

The fix is just a one-liner, has been reviewed and tested by multiple
people already, so it should not cause any other regressions.

I think you could merge it also without doing another RC next week - the
people who care about s390x on the list already have checked the fix, so
we won't get too much additional testing coverage if you release yet
another RC before the final release.

 Thomas




reply via email to

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