Re: Priority of -accel

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 1/7/20 3:14 PM, Thomas Huth wrote:
> 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?).
> 
> What about "-accel any" or "-accel fastest" or something similar?

'any' is a russian roulette, you don't want it to return 'qtest' ;)