[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: Hongbo Zhang
Subject: Re: [Qemu-devel] [PATCH v2 2/2] hw/arm: Add Arm Enterprise machine type
Date: Thu, 26 Jul 2018 17:46:23 +0800

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

reply via email to

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