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

[Andrew Jones]

On Thu, Jul 26, 2018 at 05:46:23PM +0800, Hongbo Zhang wrote:
> On 25 July 2018 at 22:08, Andrew Jones <address@hidden> wrote:
> > 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.
> >
> Root cause is requirement. This platform and virt serve different use cases.

Never any disagreement there. I'm just disagreeing with how you're naming
one instance of an SBSA platform with the very generic name of 'sbsa'.

> 
> As to command line and readconfig, my opinion is they are suitable for
> change slightly some base/typical platforms, not for change one to

Yes, command line and readconfig are suitable for changing a base
platform. That's why your new machine model should be a *base* platform,
not a specific platform with hard coded peripheral selections.

Thanks,
drew