[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Priority of -accel
From: |
Thomas Huth |
Subject: |
Re: Priority of -accel |
Date: |
Tue, 7 Jan 2020 15:35:06 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
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...
Thus if no "-accel" has been specified, then use kvm/haxm/whpv if
possible or TCG otherwise. And if "-accel" has been specified, then only
use that accelerator and don't allow a second "-accel" to be specified.
Thomas
- [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option, Philippe Mathieu-Daudé, 2020/01/06
- Re: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option, Max Reitz, 2020/01/06
- Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Thomas Huth, 2020/01/07
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Paolo Bonzini, 2020/01/07
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Thomas Huth, 2020/01/07
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Paolo Bonzini, 2020/01/07
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Daniel P . Berrangé, 2020/01/07
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Thomas Huth, 2020/01/07
- Re: Priority of -accel, Philippe Mathieu-Daudé, 2020/01/07
- Re: Priority of -accel, Daniel P . Berrangé, 2020/01/07
- Re: Priority of -accel,
Thomas Huth <=
- Re: Priority of -accel, Markus Armbruster, 2020/01/13
- Re: Priority of -accel, Christophe de Dinechin, 2020/01/13
- Re: Priority of -accel, Paolo Bonzini, 2020/01/13
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Daniel P . Berrangé, 2020/01/07
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Alex Bennée, 2020/01/08
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Thomas Huth, 2020/01/08
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Paolo Bonzini, 2020/01/08
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Daniel P . Berrangé, 2020/01/08
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Paolo Bonzini, 2020/01/08
- Re: Priority of -accel, Thomas Huth, 2020/01/08