qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 03/10] S390: Check Bootdevice Type


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 03/10] S390: Check Bootdevice Type
Date: Fri, 26 Apr 2013 18:07:11 +0200

On 26.04.2013, at 18:04, Dominik Dingel wrote:

> On Fri, 26 Apr 2013 17:48:37 +0200
> Alexander Graf <address@hidden> wrote:
> 
>> 
>> On 26.04.2013, at 17:42, Christian Borntraeger wrote:
>> 
>>> On 26/04/13 17:22, Alexander Graf wrote:
>>>> 
>>>> On 26.04.2013, at 14:12, Dominik Dingel wrote:
>>>> 
>>>>> Check for a kernel IPL entry and load kernel image if one was
>>>>> specified.
>>>>> If no kernel image was supplied and the first boot device
>>>>> is not a virtio-ccw-blk device, print error message and exit.
>>>>> 
>>>>> In case it is a virtio-ccw-blk device store the dev_no in reg[7]
>>>> 
>>>> I thought we want a boot order, not a singular device to boot off of?
>>>> 
>>>> Alex
>>> 
>>> First of all we want to be able to choose a boot device as a first step.
>>> With this patch the user is able to use libvirt and friends to choose the
>>> disk to boot from.
>>> 
>>> The nice approach with this bios/ipl device is that we can update both
>>> in lock-step so this reg7 interface is not an ABI.
>>> 
>>> So in a future version we actually could:
>>> a: implement diag 308 subcode 5/6, which would enable 
>>> /sys/devices/firmware/[ipl|reipl]
>>> just like on z/VM or LPAR (this allows to reboot from a different device).
>>> b: implement a list.
>>> 
>>> b looks  nice, but I actually prefer a for two reasons:
>>> 1. be closer to the real hw
>>> 2. predictability
>>> but we can certainly discuss this.
>>> 
>>> So I suggest to go with this patch and implement later on what we
>>> agree upon?
>> 
>> I don't see how having "first device we find" is any better than a rushed 
>> interface we need to agree on right before 1.5 hard freeze. Let's just 
>> release 1.5 with the very simple one and then go for something awesome in 
>> the next version.
>> 
>> 
>> Alex
> 
> Okay, I like more the evolution over the revolution kind of approach. So this 
> patchset does include a few improvements over the :"boot the first blk device 
> we see" system. 
> We can specify explicitly with the boot index the device to boot and with 
> loadparm even the boot entry. 
> 
> And I also see it like Christian that this is not really an interface, as it 
> should be never exposed to the outside. We only enable the outside to use 
> boot index, which is clearly stated in docs/bootindex.txt and in a later 
> addition we will enable fallbacks.

Is there any particular reason this can't wait a few weeks, go in early in the 
1.6 development cycle and then we see where it carries us?


Alex




reply via email to

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