Aims for BMC emulation in qemu

Aims for BMC emulation in qemu

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

Hey all,

There's some divide as to whether our qemu machine types should
accurately describe the hardware, or whether compromises can be made.
We've been at one extreme with the poky vexpress-based qemuarm system,
but are progressing towards machine types that are a better reflection
of the Aspeed SoCs.

Cédric, Teddy, Joel and myself have been working on modelling the SoCs'
devices but some are more complex than others. For example getting
network up and running is desirable, but the the ftgmac100 code that
exists[1] has critical bugs and isn't upstream (though we've started
fixing it[2][3]). We could use a different NIC (e.g. the Cadence GEM),
but this doesn't reflect the hardware.

So, do we compromise or not, or can we avoid the problem altogether?

Accuracy of the models is useful for kernel and u-boot development,
where you can iterate quickly on your own machine to gain confidence
before deploying to hardware (but obviously requires the models to
exist).

Alternatively, compromising on the models can allow us to accelerate
userspace development, where some of the hardware details are
abstracted. For example, it would be useful to add a network device so
the robotframework tests[4] can be run. Depending on what you are
testing, you might not care for any hardware details.

At the moment we have a palmetto-bmc machine type in upstream qemu
(2.6.0) which describes the core devices. Maybe the solution is to keep
such machine types as an accurate reflection of the hardware, and
define others that have relaxed accuracy constraints for different
circumstances. I expect we'd be maintaining a fork if we did so, but it
would evaporate over time as more models were developed.

What are your thoughts?

Andrew


[1] https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02601.html
[2] https://github.com/shenki/qemu/tree/ftgmac100
[3] https://github.com/amboar/qemu/tree/ast2400-net-ftgmac100
[4] https://github.com/mkumatag/openbmc-automation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Aims for BMC emulation in qemu

[Chris Austen]

[-- Attachment #1: Type: text/html, Size: 5015 bytes --]

Re: Aims for BMC emulation in qemu

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

Hi Chris,

On Sat, 2016-05-21 at 22:32 +0000, Chris Austen wrote:
> So in short I think we want to create a build environment that allows
> for inaccurate systems.  Over time that environment should grow from
> palmettoish to wedgeish, Zaius and witherspoonish

I tend to agree. 

My thoughts are that in general we should try to work upstream first,
and to only send upstream something that's an accurate reflection of
the hardware. However, sometimes there are work-arounds with desirable
short-term benefits, and we should be able to accommodate these too.

As an alternative to a number of machines with different levels of
accuracy, we can give the qemu fork on github a defined role: To host
our integrated short-term work-arounds as we develop the right models
to send upstream. As a concrete example, whilst the ftgmac100 model
isn't functional, have the fork provide the Cadence GEM as a NIC. Once
the ftgmac100 model is functional, send it upstream and replace the
GEM.

Any work-arounds included in the fork should have an obvious immediate
benefit and a plan to phase them out, and if that's not the case then
they should be rejected. If it's more work to maintain the hack than to
implement an accurate model, then we should do the latter.

Is there any opposition to this approach?

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Aims for BMC emulation in qemu

[Cédric Le Goater]

Hello,

On 05/23/2016 07:26 AM, Andrew Jeffery wrote:
> Hi Chris,
> 
> On Sat, 2016-05-21 at 22:32 +0000, Chris Austen wrote:
>> So in short I think we want to create a build environment that allows
>> for inaccurate systems.  Over time that environment should grow from
>> palmettoish to wedgeish, Zaius and witherspoonish
> 
> I tend to agree. 
> 
> My thoughts are that in general we should try to work upstream first,
> and to only send upstream something that's an accurate reflection of
> the hardware. However, sometimes there are work-arounds with desirable
> short-term benefits, and we should be able to accommodate these too.

yes. mainline qemu can also live with a slightly inaccurate model which 
we can patch later.

> As an alternative to a number of machines with different levels of
> accuracy, we can give the qemu fork on github a defined role: To host
> our integrated short-term work-arounds as we develop the right models
> to send upstream. As a concrete example, whilst the ftgmac100 model
> isn't functional, have the fork provide the Cadence GEM as a NIC. Once
> the ftgmac100 model is functional, send it upstream and replace the
> GEM.
>
> Any work-arounds included in the fork should have an obvious immediate
> benefit and a plan to phase them out, and if that's not the case then
> they should be rejected. If it's more work to maintain the hack than to
> implement an accurate model, then we should do the latter.

Are we planning to use travis to boot the generated flash image with qemu ?
and eventually run some tests in the guest ? 

> Is there any opposition to this approach?

Looks good to me. 


Here are some thoughts on devices we could work on to complete the model :

- uarts : quick one to get rid of the "serial8250: too much work for irq23"

- occ sensor model : to stress the kernel and user space.

- ftgmac100 : to be done.    

- bt : it would be interesting to establish a link with a powernv guest 
  or an ipmi host simulator. there is already a ipmi bmc similator.  

- smc : rfc available in my github. boots uboot. Mostly accurate I would
  say but a little ugly in some parts.  

- ...

Cheers,

C.

Re: Aims for BMC emulation in qemu

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On Mon, 2016-05-23 at 17:21 +0200, Cédric Le Goater wrote:
> > Any work-arounds included in the fork should have an obvious immediate
> > benefit and a plan to phase them out, and if that's not the case then
> > they should be rejected. If it's more work to maintain the hack than to
> > implement an accurate model, then we should do the latter.
> 
> Are we planning to use travis to boot the generated flash image with qemu ?
> and eventually run some tests in the guest ?

That's certainly something we should be aiming for, in addition to
something we can use to smoke test u-boot/linux as part of the hack-
compile-test cycle. With a view of using qemu as part of CI I had a
pull-request open against openbmc/openbmc that patched the runqemu
scripts to integrate the palmetto-bmc machine, but Patrick had concerns
about my approach there so the pull-request has been closed for the
moment.

I plan on taking a quick look at integration again shortly as some
relevant patches turned up on the openembedded-core mailing list.

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Aims for BMC emulation in qemu

[Teddy Reed]

Wow, sorry for lagging behind in the discussion! But I love all the suggestions!

This 'hybrid' approach definitely fits my need for boot testing and
enabling rapid development for the more-dynamic userland and
non-driver tweaks of U-Boot/Linux.

If possible, and I think this is the current MO, can we use the
openbmc/qemu as staging for changes to be up-streamed?

On Tue, May 24, 2016 at 5:19 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> On Mon, 2016-05-23 at 17:21 +0200, Cédric Le Goater wrote:
>> > Any work-arounds included in the fork should have an obvious immediate
>> > benefit and a plan to phase them out, and if that's not the case then
>> > they should be rejected. If it's more work to maintain the hack than to
>> > implement an accurate model, then we should do the latter.
>>

To fit the hybrid-approach, the development board models for the SoCs
can be the machine targets for the non-accurate models. Then you have
an ast2400 target that may include some work-arounds or devices that
allow for more-rapid prototyping, as is common with devboards. This
fits with several other qemu ARM development boards too-- like the
vexpress suite.

The board-specific models, like palmetto-bmc, can be held to as
absolute of model representation as possible. For these boards, no
work-arounds should be managed/merged, IMO. This makes for healthier
and more-manageable up-streaming.

>> Are we planning to use travis to boot the generated flash image with qemu ?
>> and eventually run some tests in the guest ?
>
> That's certainly something we should be aiming for, in addition to
> something we can use to smoke test u-boot/linux as part of the hack-
> compile-test cycle. With a view of using qemu as part of CI I had a
> pull-request open against openbmc/openbmc that patched the runqemu
> scripts to integrate the palmetto-bmc machine, but Patrick had concerns
> about my approach there so the pull-request has been closed for the
> moment.
>
> I plan on taking a quick look at integration again shortly as some
> relevant patches turned up on the openembedded-core mailing list.
>

-- 
Teddy Reed V

Re: Aims for BMC emulation in qemu

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]

Hi Teddy,

On Sun, 2016-05-29 at 14:17 -0700, Teddy Reed wrote:
> Wow, sorry for lagging behind in the discussion! But I love all the suggestions!
> 
> This 'hybrid' approach definitely fits my need for boot testing and
> enabling rapid development for the more-dynamic userland and
> non-driver tweaks of U-Boot/Linux.
> 
> If possible, and I think this is the current MO, can we use the
> openbmc/qemu as staging for changes to be up-streamed?

Yeah, that's the plan.

> 
> On Tue, May 24, 2016 at 5:19 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> > 
> > On Mon, 2016-05-23 at 17:21 +0200, Cédric Le Goater wrote:
> > > 
> > > > 
> > > > Any work-arounds included in the fork should have an obvious immediate
> > > > benefit and a plan to phase them out, and if that's not the case then
> > > > they should be rejected. If it's more work to maintain the hack than to
> > > > implement an accurate model, then we should do the latter.
> To fit the hybrid-approach, the development board models for the SoCs
> can be the machine targets for the non-accurate models. Then you have
> an ast2400 target that may include some work-arounds or devices that
> allow for more-rapid prototyping, as is common with devboards. This
> fits with several other qemu ARM development boards too-- like the
> vexpress suite.
> 
> The board-specific models, like palmetto-bmc, can be held to as
> absolute of model representation as possible. For these boards, no
> work-arounds should be managed/merged, IMO. This makes for healthier
> and more-manageable up-streaming.

This sounds good - I think we discussed this briefly on IRC in the
past. I was a bit hesitant on the former as upstream told me to pull
the machine definition out from the SoC file (fair enough), but as you
point out the vexpress machines do what you're suggesting.

A lot of the discussion was motivated by the lack of an ftgmac100 model
and whether we should integrate something like the Cadence GEM. This
has largely been resolved thanks to Cédric's latest efforts, but at
least we now have some approaches to handling approximations that we
can use in the future.

Cheers,

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]