On 25 July 2018 at 15:38, Andrew Jones <drjo...@redhat.com> wrote: > On Wed, Jul 25, 2018 at 03:03:40PM +0200, Ard Biesheuvel wrote: >> On 25 July 2018 at 14:59, Andrew Jones <drjo...@redhat.com> 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. Of course, we can keep QEMU dynamic, and hardcode the firmware bits against a certain instantiation of the SBSA machine. Bonus points for making that command line part of the firmware payload :-)
