[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 14:26:09 +0000 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
On Tue, Jan 07, 2020 at 03:14:52PM +0100, 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?
If there are many HW virt accelerators on a host, "fastest" might
not be what we optimize for - we might prefer the more feature
complete one even if theoeretically slower.
I suggested "best" as it intentionally somewhat vague about what
particular criteria it optimizes for. I would document it as
"best: attempt to use a hardware virt accelerator for this
platform. Falls back to emulation if none is available
for use."
Utimately though this is just bikeshedding & I don't care much
about the specific name choice, just the general concept.
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 :|
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), (continued)
- 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, 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é <=
- 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
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Peter Maydell, 2020/01/08
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Peter Maydell, 2020/01/10
- Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option), Kevin Wolf, 2020/01/07
- Re: Priority of -accel, Philippe Mathieu-Daudé, 2020/01/07