Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

["Alex Bennée" <alex.bennee@linaro.org>]

Thomas Huth <thuth@redhat.com> writes:

> On 07/01/2020 13.54, Daniel P. Berrangé wrote:
>> On Tue, Jan 07, 2020 at 01:23:18PM +0100, Paolo Bonzini wrote:
>>> On 07/01/20 13:18, Thomas Huth wrote:
>>>> I don't think we need a separate priority parameter here. But IMHO it's
>>>>  really rather common practice to prioritize the last option. So while
>>>> it might be more "self-explanatory" to a CLI newbie if the first
>>>> occurrence got the highest priority, it might be rather confusing
>>>> instead for a CLI veteran...?
>>>
>>> Prioritising the last certainly makes sense for a choose-one-only
>>> option, but I'm not sure it's the same for a choose-best option.  After
>>> all it was -machine accel=kvm:tcg, not -machine accel=tcg:kvm...
>> 
>> IIUC, the main use case for specifying multiple accelerators is
>> so that lazy invokations can ask for a hardware virt, but then get
>> fallback to TCG if not available. For things that should be platform
>> portabile, there's more than just kvm to consider though, as we have
>> many accelerators.  Listing all possible accelerators is kind of
>> crazy though no matter what the syntax is.
>> 
>> How about taking a completely different approach, inspired by the
>> -cpu arg and implement:
>> 
>>     -machine accel=best
>
> Something like that sounds like the best solution to me, but I'd maybe
> rather not call it "best", since the definition of "best" might depend
> on your use-case (e.g. do you want to use a CPU close to the host or
> something different which might be better emulated by TCG?).

Indeed - you may well want to do TCG on Aarch64 if you want to test new
instructions.

>
> What about "-accel any" or "-accel fastest" or something similar?

"any" is just ambiguous, "fastest" is just begging for me to find a
micro-benchmark that TCG outperforms on ;-)

"-accel default" could be considered to have vibes of Do The Right
Thing (tm) and could in time actually become so!

Does qemu support any sort of configurable defaults mechanism via config
file where we can punt this sort of thing to the distribution/packager?

-- 
Alex Bennée