On 25 July 2018 at 22:08, Andrew Jones <drjo...@redhat.com> wrote: > On Wed, Jul 25, 2018 at 03:46:01PM +0200, Ard Biesheuvel wrote: >> 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. > > 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