[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Huth
Subject: Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
Date: Tue, 7 Jan 2020 15:14:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]