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

[Hongbo Zhang]

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.

As to command line and readconfig, my opinion is they are suitable for
change slightly some base/typical platforms, not for change one to
another with big difference, otherwise we can even reduce some
platforms in qemu I guess.

> Thanks,
> drew