qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 3/5] s390x/ipl: Load network boot image


From: Thomas Huth
Subject: Re: [Qemu-devel] [PATCH v2 3/5] s390x/ipl: Load network boot image
Date: Mon, 27 Feb 2017 12:59:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 27.02.2017 12:51, Cornelia Huck wrote:
> On Sat, 25 Feb 2017 07:18:29 +0100
> Thomas Huth <address@hidden> wrote:
> 
>> On 23.02.2017 13:20, Cornelia Huck wrote:
>>> From: Farhan Ali <address@hidden>
>>>
>>> Load the network boot image into guest RAM when the boot
>>> device selected is a network device. Use some of the reserved
>>> space in IplBlockCcw to store the start address of the netboot
>>> image.
>>>
>>> A user could also use 'chreipl'(diag 308/5) to change the boot device.
>>> So every time we update the IPLB, we need to verify if the selected
>>> boot device is a network device so we can appropriately load the
>>> network boot image.
>>>
>>> Signed-off-by: Farhan Ali <address@hidden>
>>> Signed-off-by: Cornelia Huck <address@hidden>
>>> ---
>>>  hw/s390x/ipl.c | 89 
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>  hw/s390x/ipl.h |  4 ++-
>>>  2 files changed, 92 insertions(+), 1 deletion(-)
[...]
>>> +    if (ipl->netboot) {
>>> +        if (load_netboot_image(&err) < 0) {
>>> +            error_report_err(err);
>>> +            vm_stop(RUN_STATE_INTERNAL_ERROR);
>>> +        }
>>> +        ipl->iplb.ccw.netboot_start_addr = ipl->start_addr;
>>
>> Not sure whether it matters, but in case of early errors during
>> load_netboot_image(), ipl->start_addr could be used uninitialized here.
>> Maybe you should move the "ipl->start_addr = KERN_IMAGE_START;" there at
>> the beginning of the function, to make it also the default value for the
>> other error cases?
> 
> ipl->start_addr has already been set to some value in the realize
> function (either the kernel entry address, or the bios address).
> 
> But that should not matter with the vm_stop() on error anyway, no?

Likely not. It's just a little bit strange to see that the program flow
continues after the error in this function here ... maybe it would have
been clearer to put a "return" right after the "vm_stop()"? Anyway, it
likely does not really matter here, so never mind.

 Thomas





reply via email to

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