[Top][All Lists]

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

Re: Priority of -accel

From: Markus Armbruster
Subject: Re: Priority of -accel
Date: Mon, 13 Jan 2020 15:39:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Thomas Huth <address@hidden> writes:

> On 07/01/2020 15.27, Daniel P. Berrangé wrote:
>> On Tue, Jan 07, 2020 at 03:20:40PM +0100, Philippe Mathieu-Daudé wrote:
>>> 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' ;)
>> We could make it return "qtest" only on April 1st ;-P
> ... or we finally dare to let QEMU chose the "best" accelerator by
> default if no "-accel" option has been specified...

Changing a default that has ceased to make sense a decade ago?  Are you
out of your mind?



reply via email to

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