qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2] ppc/pnv: Create BMC devices at machine init


From: Cédric Le Goater
Subject: Re: [PATCH v2] ppc/pnv: Create BMC devices at machine init
Date: Sat, 4 Apr 2020 10:22:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 4/4/20 9:17 AM, Nathan Chancellor wrote:
> Hi Cédric,
> 
> On Thu, Nov 21, 2019 at 05:23:40PM +0100, Cédric Le Goater wrote:
>> The BMC of the OpenPOWER systems monitors the machine state using
>> sensors, controls the power and controls the access to the PNOR flash
>> device containing the firmware image required to boot the host.
>>
>> QEMU models the power cycle process, access to the sensors and access
>> to the PNOR device. But, for these features to be available, the QEMU
>> PowerNV machine needs two extras devices on the command line, an IPMI
>> BT device for communication and a BMC backend device:
>>
>>   -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10
>>
>> The BMC properties are then defined accordingly in the device tree and
>> OPAL self adapts. If a BMC device and an IPMI BT device are not
>> available, OPAL does not try to communicate with the BMC in any
>> manner. This is not how real systems behave.
>>
>> To be closer to the default behavior, create an IPMI BMC simulator
>> device and an IPMI BT device at machine initialization time. We loose
>> the ability to define an external BMC device but there are benefits:
>>
>>   - a better match with real systems,
>>   - a better test coverage of the OPAL code,
>>   - system powerdown and reset commands that work,
>>   - a QEMU device tree compliant with the specifications (*).
>>
>> (*) Still needs a MBOX device.
>>
>> Signed-off-by: Cédric Le Goater <address@hidden>
> 
> I just started testing QEMU v5.0.0-rc1 against the little Linux booting
> framework that I helped set up for ClangBuiltLinux and this commit has
> caused some problems because we specify the exact same devices as you
> note in the commit message:
> 
> https://github.com/ClangBuiltLinux/boot-utils/blob/5d9d3f626940a6a176c080717a367c1599f63680/boot-qemu.sh#L154-L155
> 
> $ timeout 3m unbuffer qemu-system-ppc64 -device ipmi-bmc-sim,id=bmc0 \
>                                         -device isa-ipmi-bt,bmc=bmc0,irq=10 \
>                                         -L images/ppc64le/ \
>                                         -bios skiboot.lid \
>                                         -machine powernv \
>                                         -display none \
>                                         -initrd images/ppc64le/rootfs.cpio \
>                                         -kernel zImage.epapr \
>                                         -m 2G \
>                                         -serial mon:stdio
> qemu-system-ppc64: error creating device tree: node: FDT_ERR_EXISTS

sigh ...

> It seems to me like if the machine is silently creating these devices,

yes. It now does at the machine init time.

> it should just warn that the user is trying to create a device that
> already exists? 

That is more complex because the machine only knows very late about 
the user created devices, at reset time. We could check this specific
case (two sets of IPMI devices) and warn the user before exiting. 

> If not, then I assume I will just need to hack up a check for QEMU 
> 5.0.0+ and just not add those devices? 

May be we can improve the behavior. See below.

> We use that script with QEMU 3.1.0 in our CI and I use it locally 
> with QEMU 4.2.0 so universally getting rid of them doesn't seem 
> logical.
> 
> Curious for your thoughts on what to do and cheers,
A solution might be to tie theses default IPMI devices to 
defaults_enabled(). Which means that to create a custom set of 
devices you would need to use -nodefaults now. Would that be OK ?  

Creating these devices at reset would be much easier but it is 
considered a bad practice to do so. 

Any other ideas ? 

Thanks,

C.




reply via email to

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