qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Cédric Le Goater" <clg@kaod.org>
To: Nathan Chancellor <natechancellor@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Corey Minyard <cminyard@mvista.com>,
	qemu-devel@nongnu.org, Oliver O'Halloran <oohall@gmail.com>,
	qemu-ppc@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v2] ppc/pnv: Create BMC devices at machine init
Date: Sat, 4 Apr 2020 10:22:03 +0200	[thread overview]
Message-ID: <8d46dc9f-bc7e-b449-42f3-54d2d0f304b3@kaod.org> (raw)
In-Reply-To: <20200404071707.GA24708@ubuntu-m2-xlarge-x86>

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 <clg@kaod.org>
> 
> 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	other threads:[~2020-04-04  8:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-21 16:23 [PATCH v2] ppc/pnv: Create BMC devices at machine init Cédric Le Goater
2019-11-21 17:14 ` Corey Minyard
2019-11-22  3:41 ` David Gibson
2020-04-04  7:17 ` Nathan Chancellor
2020-04-04  8:22   ` Cédric Le Goater [this message]
2020-04-04 15:46   ` Cédric Le Goater

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8d46dc9f-bc7e-b449-42f3-54d2d0f304b3@kaod.org \
    --to=clg@kaod.org \
    --cc=cminyard@mvista.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=natechancellor@gmail.com \
    --cc=oohall@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).