[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: |
Daniel P . Berrangé |
Subject: |
Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) |
Date: |
Tue, 7 Jan 2020 12:54:51 +0000 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
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
which will just "do the right thing(tm)", picking the best available
option for the current host.
Then declare the use of mulitple -machine args is unsupported
or undefined semantics, and ignore this priority question entirely
thus avoid making QEMU's CLI even more complex than it already is
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- [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é <=
- 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, 2020/01/07
- 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