On Wed, Jul 25, 2018 at 02:29:09PM +0200, Ard Biesheuvel wrote:
> To prevent spending a disproportionate amount of time on inventing
> ways to parameterize these 'models', which includes interfaces not
> only between UEFI and QEMU but also between ARM-TF and QEMU (and
> potentially between UEFI and ARM-TF as well), could we please consider
I guess a UEFI <=> ARM-TF interface will also need to work on real
hardware, and therefore need a QEMU model. If whatever that interface
needs can also satisfy the UEFI <=> QEMU and ARM-TF <=> interfaces,
then that's all we need - no need for fw-cfg.
> fixed configurations for the non-discoverable bits? If there is a new
Well, at least one thing must to be fixed, which is
a) address/register where the address of the DTB will be stored
b) address of the QEMU interface device, e.g. fw-cfg. fw-cfg or
whatever can then be used to get the DTB.
And I guess everything the SBSA says should be fixed should be fixed.
Otherwise, what's non-discoverable?
> and improved sbsa model in the future, we could call it sbsa-2.0, no?
Of course the model can be versioned, allowing for any change, but
I don't think model versions were meant to be aliases for peripheral
selections. That's what scripts wrapped around qemu are for.
Thanks,
drew
