[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type

From: Andrew Jones
Subject: Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type
Date: Wed, 25 Jul 2018 16:08:24 +0200
User-agent: NeoMutt/20180622

On Wed, Jul 25, 2018 at 03:46:01PM +0200, Ard Biesheuvel wrote:
> On 25 July 2018 at 15:38, Andrew Jones <address@hidden> wrote:
> > On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel wrote:
> >> On 25 July 2018 at 14:59, Andrew Jones <address@hidden> wrote:
> >> > On Wed, Jul 25, 2018 at 01:47:00PM +0100, Daniel P. Berrangé wrote:
> >> >> Would iut make any sense to call the machine  "refplatform"  or 
> >> >> "refboard"
> >> >> to indicate it is a generic reference platform, not specifically 
> >> >> following
> >> >> any particular real impl, albeit influence by the sbsa spec.
> >> >>
> >> >
> >> > That would indeed stop me from whining about a machine model with an
> >> > 'sbsa' name not strictly implementing a minimal SBSA machine :-)
> >> >
> >>
> >> I still don't get why only a minimal machine is worth considering,
> >> given that a real-world minimal SBSA machine is not capable of doing
> >> anything useful.
> >
> > One definition of an SBSA machine can be quite different than another.
> > If we only hard code the required [useless] base, but also provide a
> > readconfig for the rest, then we get a useful machine without loss of
> > flexibility.
> >
> > That flexibility comes at the cost of platform-bus code (since we need
> > to add devices to the system bus) and a less concise command line. The
> > platform-bus code may indeed be too expensive for this purpose, but
> > we may need to see patches to be sure. I understand the desire to have
> > a shorter command line, but this is QEMU :)
> >
> My concern is not the QEMU side. It is the code that we will need to
> add to UEFI and ARM-TF to deal with the dynamic nature of the
> underlying platform. That code has no counterpart in real world
> hardware, but will surely turn up in production firmware nonetheless
> if we end up having to add that to our SBSA reference codebase.

It sounds like there's already some sort of informal SBSA reference
instance specification that UEFI and ARM-TF intend to support. If
that instance specification were slightly more formal, i.e. documented
somewhere and given a more descriptive name (not just 'sbsa'), then
I think it would be a lot more palatable to hard code those specifications
directly into a QEMU machine model of the same name.


reply via email to

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