From: "Cédric Le Goater" <clg@kaod.org>
To: andrew@aj.id.au, Chris Austen <austenc@us.ibm.com>
Cc: joel@jms.id.au, openbmc@lists.ozlabs.org, patrick@stwcx.xyz,
teddy.reed@gmail.com
Subject: Re: Aims for BMC emulation in qemu
Date: Mon, 23 May 2016 17:21:06 +0200 [thread overview]
Message-ID: <57431FE2.3000506@kaod.org> (raw)
In-Reply-To: <1463981199.2703.286.camel@aj.id.au>
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.
next prev parent reply other threads:[~2016-05-23 15:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-19 6:22 Aims for BMC emulation in qemu Andrew Jeffery
2016-05-21 22:32 ` Chris Austen
[not found] ` <20160521223211.26848C6042@b03ledav006.gho.boulder.ibm.com>
2016-05-23 5:26 ` Andrew Jeffery
2016-05-23 15:21 ` Cédric Le Goater [this message]
2016-05-25 0:19 ` Andrew Jeffery
2016-05-29 21:17 ` Teddy Reed
2016-05-31 6:07 ` Andrew Jeffery
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=57431FE2.3000506@kaod.org \
--to=clg@kaod.org \
--cc=andrew@aj.id.au \
--cc=austenc@us.ibm.com \
--cc=joel@jms.id.au \
--cc=openbmc@lists.ozlabs.org \
--cc=patrick@stwcx.xyz \
--cc=teddy.reed@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.