[Top][All Lists]

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

Re: Priority of -accel

From: Philippe Mathieu-Daudé
Subject: Re: Priority of -accel
Date: Tue, 7 Jan 2020 15:20:40 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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' ;)

reply via email to

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