Aims for BMC emulation in qemu

[Andrew Jeffery]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160523/11b6b050/attachment.sig>