[PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option

[PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option

[Philippe Mathieu-Daudé]

Commit 6f6e1698a6 desugarized "-machine accel=" to a list
of "-accel" options. Since now "-machine accel" and "-accel"
became incompatible, update the iotests to the new format.

Error reported here:
https://gitlab.com/qemu-project/qemu/-/jobs/385801004#L3400

Reported-by: GitLab CI
Fixes: 6f6e1698a6 (vl: configure accelerators from -accel options)
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 tests/qemu-iotests/235   | 2 +-
 tests/qemu-iotests/check | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/qemu-iotests/235 b/tests/qemu-iotests/235
index fedd111fd4..3d7533980d 100755
--- a/tests/qemu-iotests/235
+++ b/tests/qemu-iotests/235
@@ -49,7 +49,7 @@ qemu_img_create('-f', iotests.imgfmt, '-o', 'preallocation=metadata', disk,
                 str(size))
 
 vm = QEMUMachine(iotests.qemu_prog)
-vm.add_args('-machine', 'accel=kvm:tcg')
+vm.add_args('-accel', 'kvm', '-accel', 'tcg')
 if iotests.qemu_default_machine == 's390-ccw-virtio':
         vm.add_args('-no-shutdown')
 vm.add_args('-drive', 'id=src,file=' + disk)
diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check
index 90970b0549..2890785a10 100755
--- a/tests/qemu-iotests/check
+++ b/tests/qemu-iotests/check
@@ -587,13 +587,13 @@ export QEMU_PROG="$(type -p "$QEMU_PROG")"
 
 case "$QEMU_PROG" in
     *qemu-system-arm|*qemu-system-aarch64)
-        export QEMU_OPTIONS="-nodefaults -display none -machine virt,accel=qtest"
+        export QEMU_OPTIONS="-nodefaults -display none -machine virt -accel qtest"
         ;;
     *qemu-system-tricore)
-        export QEMU_OPTIONS="-nodefaults -display none -machine tricore_testboard,accel=qtest"
+        export QEMU_OPTIONS="-nodefaults -display none -machine tricore_testboard -accel qtest"
         ;;
     *)
-        export QEMU_OPTIONS="-nodefaults -display none -machine accel=qtest"
+        export QEMU_OPTIONS="-nodefaults -display none -accel qtest"
         ;;
 esac
 
-- 
2.21.1

Re: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option

[Max Reitz]

[-- Attachment #1.1: Type: text/plain, Size: 736 bytes --]

On 06.01.20 14:09, Philippe Mathieu-Daudé wrote:
> Commit 6f6e1698a6 desugarized "-machine accel=" to a list
> of "-accel" options. Since now "-machine accel" and "-accel"
> became incompatible, update the iotests to the new format.
> 
> Error reported here:
> https://gitlab.com/qemu-project/qemu/-/jobs/385801004#L3400
> 
> Reported-by: GitLab CI
> Fixes: 6f6e1698a6 (vl: configure accelerators from -accel options)
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  tests/qemu-iotests/235   | 2 +-
>  tests/qemu-iotests/check | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)

Thanks, applied to my block branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Thomas Huth]

On 06/01/2020 14.09, Philippe Mathieu-Daudé wrote:
> Commit 6f6e1698a6 desugarized "-machine accel=" to a list
> of "-accel" options. Since now "-machine accel" and "-accel"
> became incompatible, update the iotests to the new format.
> 
> Error reported here:
> https://gitlab.com/qemu-project/qemu/-/jobs/385801004#L3400
> 
> Reported-by: GitLab CI
> Fixes: 6f6e1698a6 (vl: configure accelerators from -accel options)
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  tests/qemu-iotests/235   | 2 +-
>  tests/qemu-iotests/check | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/qemu-iotests/235 b/tests/qemu-iotests/235
> index fedd111fd4..3d7533980d 100755
> --- a/tests/qemu-iotests/235
> +++ b/tests/qemu-iotests/235
> @@ -49,7 +49,7 @@ qemu_img_create('-f', iotests.imgfmt, '-o', 'preallocation=metadata', disk,
>                  str(size))
>  
>  vm = QEMUMachine(iotests.qemu_prog)
> -vm.add_args('-machine', 'accel=kvm:tcg')
> +vm.add_args('-accel', 'kvm', '-accel', 'tcg')

Looking at this, I wonder whether we really want the "-accel" option to
prioritize the accelerators in the order of appearance? A lot of other
CLI tools give the highest priority to the last parameter instead, e.g.
"gcc -O3 -O1" compiles with -O1, and not with -O3.

Also I think it might be quite common that there are shell scripts which
call "qemu-system-xxx -accel xyz $*" ... and if we don't invert the
priorities of -accel, it will be impossible to override -accel in that
case...

 Thomas

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Paolo Bonzini]

On 07/01/20 11:03, Thomas Huth wrote:
>>  
>>  vm = QEMUMachine(iotests.qemu_prog)
>> -vm.add_args('-machine', 'accel=kvm:tcg')
>> +vm.add_args('-accel', 'kvm', '-accel', 'tcg')
> Looking at this, I wonder whether we really want the "-accel" option to
> prioritize the accelerators in the order of appearance? A lot of other
> CLI tools give the highest priority to the last parameter instead, e.g.
> "gcc -O3 -O1" compiles with -O1, and not with -O3.
> 
> Also I think it might be quite common that there are shell scripts which
> call "qemu-system-xxx -accel xyz $*" ... and if we don't invert the
> priorities of -accel, it will be impossible to override -accel in that
> case...

Hmm, it does match "-machine accel=kvm:tcg" and in general I think it's
more self-explanatory.  However, it is indeed less friendly to scripts.
 On one hand those could be changed to place "-accel xyz" after $* (or
better "$@"), on the other hand we could also add a priority option to
"-accel".  What do you think?

Paolo

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Thomas Huth]

On 07/01/2020 11.14, Paolo Bonzini wrote:
> On 07/01/20 11:03, Thomas Huth wrote:
>>>  
>>>  vm = QEMUMachine(iotests.qemu_prog)
>>> -vm.add_args('-machine', 'accel=kvm:tcg')
>>> +vm.add_args('-accel', 'kvm', '-accel', 'tcg')
>> Looking at this, I wonder whether we really want the "-accel" option to
>> prioritize the accelerators in the order of appearance? A lot of other
>> CLI tools give the highest priority to the last parameter instead, e.g.
>> "gcc -O3 -O1" compiles with -O1, and not with -O3.
>>
>> Also I think it might be quite common that there are shell scripts which
>> call "qemu-system-xxx -accel xyz $*" ... and if we don't invert the
>> priorities of -accel, it will be impossible to override -accel in that
>> case...
> 
> Hmm, it does match "-machine accel=kvm:tcg" and in general I think it's
> more self-explanatory.  However, it is indeed less friendly to scripts.
>  On one hand those could be changed to place "-accel xyz" after $* (or
> better "$@"), on the other hand we could also add a priority option to
> "-accel".  What do you think?

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...?

What do others on the list here think about this?

 Thomas

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Paolo Bonzini]

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...

Paolo

> What do others on the list here think about this?

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Kevin Wolf]

Am 07.01.2020 um 13:18 hat Thomas Huth geschrieben:
> On 07/01/2020 11.14, Paolo Bonzini wrote:
> > On 07/01/20 11:03, Thomas Huth wrote:
> >>>  
> >>>  vm = QEMUMachine(iotests.qemu_prog)
> >>> -vm.add_args('-machine', 'accel=kvm:tcg')
> >>> +vm.add_args('-accel', 'kvm', '-accel', 'tcg')
> >> Looking at this, I wonder whether we really want the "-accel" option to
> >> prioritize the accelerators in the order of appearance? A lot of other
> >> CLI tools give the highest priority to the last parameter instead, e.g.
> >> "gcc -O3 -O1" compiles with -O1, and not with -O3.
> >>
> >> Also I think it might be quite common that there are shell scripts which
> >> call "qemu-system-xxx -accel xyz $*" ... and if we don't invert the
> >> priorities of -accel, it will be impossible to override -accel in that
> >> case...
> > 
> > Hmm, it does match "-machine accel=kvm:tcg" and in general I think it's
> > more self-explanatory.  However, it is indeed less friendly to scripts.
> >  On one hand those could be changed to place "-accel xyz" after $* (or
> > better "$@"), on the other hand we could also add a priority option to
> > "-accel".  What do you think?
> 
> 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...?
> 
> What do others on the list here think about this?

But in those cases where a later option takes priority, at least those
that I'm thinking of right now, it actually completely overrides the
first option as if it hadn't been given.

This one seems to be different in that a later option actually just adds
to the list. Processing a list backwards isn't necessarily less
confusing than what we have.

Kevin

Re: Priority of -accel

[Philippe Mathieu-Daudé]

On 1/7/20 1:18 PM, Thomas Huth wrote:
> On 07/01/2020 11.14, Paolo Bonzini wrote:
>> On 07/01/20 11:03, Thomas Huth wrote:
>>>>   
>>>>   vm = QEMUMachine(iotests.qemu_prog)
>>>> -vm.add_args('-machine', 'accel=kvm:tcg')
>>>> +vm.add_args('-accel', 'kvm', '-accel', 'tcg')
>>> Looking at this, I wonder whether we really want the "-accel" option to
>>> prioritize the accelerators in the order of appearance? A lot of other
>>> CLI tools give the highest priority to the last parameter instead, e.g.
>>> "gcc -O3 -O1" compiles with -O1, and not with -O3.
>>>
>>> Also I think it might be quite common that there are shell scripts which
>>> call "qemu-system-xxx -accel xyz $*" ... and if we don't invert the
>>> priorities of -accel, it will be impossible to override -accel in that
>>> case...
>>
>> Hmm, it does match "-machine accel=kvm:tcg" and in general I think it's
>> more self-explanatory.  However, it is indeed less friendly to scripts.
>>   On one hand those could be changed to place "-accel xyz" after $* (or
>> better "$@"), on the other hand we could also add a priority option to
>> "-accel".  What do you think?
> 
> 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...?
> 
> What do others on the list here think about this?

We can make CLI more complex by adding a 'priority' option:

   -accel tcg,priority=1 -accel kvm,priority=0

Re: Priority of -accel

[Philippe Mathieu-Daudé]

On Tue, Jan 7, 2020 at 1:34 PM Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> On 1/7/20 1:18 PM, Thomas Huth wrote:
> > On 07/01/2020 11.14, Paolo Bonzini wrote:
> >> On 07/01/20 11:03, Thomas Huth wrote:
> >>>>
> >>>>   vm = QEMUMachine(iotests.qemu_prog)
> >>>> -vm.add_args('-machine', 'accel=kvm:tcg')
> >>>> +vm.add_args('-accel', 'kvm', '-accel', 'tcg')
> >>> Looking at this, I wonder whether we really want the "-accel" option to
> >>> prioritize the accelerators in the order of appearance? A lot of other
> >>> CLI tools give the highest priority to the last parameter instead, e.g.
> >>> "gcc -O3 -O1" compiles with -O1, and not with -O3.
> >>>
> >>> Also I think it might be quite common that there are shell scripts which
> >>> call "qemu-system-xxx -accel xyz $*" ... and if we don't invert the
> >>> priorities of -accel, it will be impossible to override -accel in that
> >>> case...
> >>
> >> Hmm, it does match "-machine accel=kvm:tcg" and in general I think it's
> >> more self-explanatory.  However, it is indeed less friendly to scripts.
> >>   On one hand those could be changed to place "-accel xyz" after $* (or
> >> better "$@"), on the other hand we could also add a priority option to
> >> "-accel".  What do you think?
> >
> > 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...?
> >
> > What do others on the list here think about this?
>
> We can make CLI more complex by adding a 'priority' option:
>
>    -accel tcg,priority=1 -accel kvm,priority=0

I meant "more explicit" =)

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Daniel P. Berrangé]

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 :|

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Christophe de Dinechin]

> On 7 Jan 2020, at 11:14, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 07/01/20 11:03, Thomas Huth wrote:
>>> 
>>> vm = QEMUMachine(iotests.qemu_prog)
>>> -vm.add_args('-machine', 'accel=kvm:tcg')
>>> +vm.add_args('-accel', 'kvm', '-accel', 'tcg')
>> Looking at this, I wonder whether we really want the "-accel" option to
>> prioritize the accelerators in the order of appearance? A lot of other
>> CLI tools give the highest priority to the last parameter instead, e.g.
>> "gcc -O3 -O1" compiles with -O1, and not with -O3.
>> 
>> Also I think it might be quite common that there are shell scripts which
>> call "qemu-system-xxx -accel xyz $*" ... and if we don't invert the
>> priorities of -accel, it will be impossible to override -accel in that
>> case...
> 
> Hmm, it does match "-machine accel=kvm:tcg" and in general I think it's
> more self-explanatory.  However, it is indeed less friendly to scripts.
> On one hand those could be changed to place "-accel xyz" after $* (or
> better "$@"), on the other hand we could also add a priority option to
> "-accel".  What do you think?

I tend to agree with Thomas’ assessment that in general, later options
tend to override earlier ones, if only because that’s typically how getopt
works with the typical usage of setting global variables.

I also agree that when it’s a single list given to an option, then it
generally makes more sense to interpret the later ones as a “fallback”
if you could not get the previous ones. Which I believe gives me a
hint of what the intent of specifying multiple options would be…

So what about ranking the accelerators, so that all combinaisons
-accel=kvm:tcg, -accel=tcg:kvm, -accel kvm -accel tcg, etc would
all pickup kvm if available, and tcg as a fallback? Implementation-wise,
it would simply mean ranking the accelerators and updating the accelerator
only if it’s available and better.

To allow full override, we might add something like -accel reset
to reset to the default, i.e. as if no option had been given.

I personally don’t like “priority=n” being explicit on the command-line
because that IMO pushes the problem of ranking the accelerators
to the user, without guidance on how to do that. For example, if I
have a script that reliably overrode before, then it might stop
overriding because the inner script has set priority=2, so I put
priority=3, not knowing that the maintainer thinks my override
broke something, so the inner script maintainers escalates to
priority=4 to “fix” my priority=3. In the end, the whole universe
crumbles or something equally unpredictable.


Cheers,
Christophe

> 
> Paolo
> 
> 

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Thomas Huth]

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?

 Thomas

Re: Priority of -accel

[Philippe Mathieu-Daudé]

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

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Daniel P. Berrangé]

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

[Daniel P. Berrangé]

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

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

[Thomas Huth]

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

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Paolo Bonzini]

On 07/01/20 14:55, Christophe de Dinechin wrote:
> So what about ranking the accelerators, so that all combinaisons
> -accel=kvm:tcg, -accel=tcg:kvm, -accel kvm -accel tcg, etc would

(I assume you mean "-machine accel=kvm:tcg" and "-machine accel=tcg:kvm"
for the first two.  This is the "older" way which has now become sugar
for "-accel kvm -accel tcg").

> all pickup kvm if available, and tcg as a fallback? Implementation-wise,
> it would simply mean ranking the accelerators and updating the accelerator
> only if it’s available and better.

This is an interesting idea.  I like this better than "-accel best",
because "-accel best" has the problem that you can't add suboptions to
it (the suboptions for the various accelerators are disjoint).

It would break backwards compatibility for "-machine accel=tcg:kvm",
which so far meant "use TCG if compiled in, otherwise use KVM".  This is
not something I would have a problem with... except that "tcg:kvm" is
the default if no -accel option is provided!

Paolo

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Thomas Huth]

On 07/01/2020 15.37, Paolo Bonzini wrote:
> On 07/01/20 14:55, Christophe de Dinechin wrote:
>> So what about ranking the accelerators, so that all combinaisons
>> -accel=kvm:tcg, -accel=tcg:kvm, -accel kvm -accel tcg, etc would
> 
> (I assume you mean "-machine accel=kvm:tcg" and "-machine accel=tcg:kvm"
> for the first two.  This is the "older" way which has now become sugar
> for "-accel kvm -accel tcg").
> 
>> all pickup kvm if available, and tcg as a fallback? Implementation-wise,
>> it would simply mean ranking the accelerators and updating the accelerator
>> only if it’s available and better.
> 
> This is an interesting idea.  I like this better than "-accel best",
> because "-accel best" has the problem that you can't add suboptions to
> it (the suboptions for the various accelerators are disjoint).
> 
> It would break backwards compatibility for "-machine accel=tcg:kvm",
> which so far meant "use TCG if compiled in, otherwise use KVM".  This is
> not something I would have a problem with... except that "tcg:kvm" is
> the default if no -accel option is provided!

Note that we need "-M accel=tcg:kvm" (or "-accel tcg -accel kvm" now) in
tests/boot-serial-test.c for example, since some machines can't use KVM
on certain hosts (e.g. with KVM-HV on POWER8/9).

 Thomas

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Christophe de Dinechin]

> On 7 Jan 2020, at 15:37, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 07/01/20 14:55, Christophe de Dinechin wrote:
>> So what about ranking the accelerators, so that all combinaisons
>> -accel=kvm:tcg, -accel=tcg:kvm, -accel kvm -accel tcg, etc would
> 
> (I assume you mean "-machine accel=kvm:tcg" and "-machine accel=tcg:kvm"
> for the first two.  This is the "older" way which has now become sugar
> for "-accel kvm -accel tcg").

Yes.

> 
>> all pickup kvm if available, and tcg as a fallback? Implementation-wise,
>> it would simply mean ranking the accelerators and updating the accelerator
>> only if it’s available and better.
> 
> This is an interesting idea.  I like this better than "-accel best",
> because "-accel best" has the problem that you can't add suboptions to
> it (the suboptions for the various accelerators are disjoint).
> 
> It would break backwards compatibility for "-machine accel=tcg:kvm",
> which so far meant "use TCG if compiled in, otherwise use KVM".  This is
> not something I would have a problem with... except that "tcg:kvm" is
> the default if no -accel option is provided!

What is the rationale for picking tcg over kvm?

My guess is that when this was selected, KVM was the new fancy unstable
thing and this was deemed the safe choice. My other guess is that this was
around 1907 or so :-) My third guess is that you will probably provide me
with a much better rationale ;-)

Without knowing a rationale, my mind goes wild. I’m trying to imagine
who runs qemu directly, without the -accel option. For some reason, I
picture a guy named Joe typing something like "qemu win95.qcow2”,
somewhere in a dark and dusty basement with old neon lamps flashing
in the background and a few rats gnawing at damp CAT5 cables.
Joe is intent on playing Day of the Tentacle one last time before it’s too
late. Joe's only complaint so far has been that the game was a bit slow,
and that’s why he’s nervous and sweats profusely. <insert tense music here>
Will Joe have the time to complete this one last task? <zoom to an old
clock in a corner, ominous tic-toc sound>

Now, it turns out that Joe just updated his system, and suddenly, to his
amazement, Day of the Tentacle is fluid and fast. It’s a miracle!
<insert joyful music here, with a few butterflies flying around for effect>
What is Joe going to do that might be an issue for us? Maybe Joe will
immediately run to Twitter, eyes full of thankful tears, full of a burning
desire to tell the entire world that the qemu folks went totally overboard
with this release and super-optimized it like crazy?

(Consider the above as my way to tell that I’m a bit puzzled as to why
selecting kvm would be a problem. I even intentionally inserted win95,
hoping that this might be one of the scenarios where kvm might be more
trouble than anything, but I don’t know that for sure, having not tested it)

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Peter Maydell]

On Tue, 7 Jan 2020 at 17:44, Christophe de Dinechin <dinechin@redhat.com> wrote:
> > On 7 Jan 2020, at 15:37, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > It would break backwards compatibility for "-machine accel=tcg:kvm",
> > which so far meant "use TCG if compiled in, otherwise use KVM".  This is
> > not something I would have a problem with... except that "tcg:kvm" is
> > the default if no -accel option is provided!
>
> What is the rationale for picking tcg over kvm?

Command line compatibility. QEMU existed before KVM support
was ever merged into it, and so the default has always been
"emulate the CPU". Defaulting to KVM would be a change of
behaviour for existing working command lines. The reason
for using "tcg:kvm" rather than just "tcg" may be that
this way a --disable-tcg QEMU does something useful, but that's
just a guess.

QEMU tends to prioritize "don't change behaviour for users"
to a degree that is arguably counterproductive. But it's a
nice easy rule to follow :-)

thanks
-- PMM

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Kevin Wolf]

Am 07.01.2020 um 18:43 hat Christophe de Dinechin geschrieben:
> > It would break backwards compatibility for "-machine accel=tcg:kvm",
> > which so far meant "use TCG if compiled in, otherwise use KVM".  This is
> > not something I would have a problem with... except that "tcg:kvm" is
> > the default if no -accel option is provided!
> 
> What is the rationale for picking tcg over kvm?
> 
> My guess is that when this was selected, KVM was the new fancy unstable
> thing and this was deemed the safe choice. My other guess is that this was
> around 1907 or so :-) My third guess is that you will probably provide me
> with a much better rationale ;-)

I know I intentionally disabled KVM in the past for debugging guests
because TCG allowed a few more things there (most of -d doesn't do
anything with KVM, and I think the gdb stub also had some restrictions).

Requiring an explicit '-accel tcg' for such cases might be reasonable
enough, though.

(And if we make this change and therefore break with the habit that
Peter mentioned - leaving defaults unchanged - could we make more
changes that better reflect a typical use case today? For example, I
doubt most people can do with only 128 MB of RAM in the guest.)

Kevin

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Alex Bennée]

Thomas Huth <thuth@redhat.com> writes:

> 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?).

Indeed - you may well want to do TCG on Aarch64 if you want to test new
instructions.

>
> What about "-accel any" or "-accel fastest" or something similar?

"any" is just ambiguous, "fastest" is just begging for me to find a
micro-benchmark that TCG outperforms on ;-)

"-accel default" could be considered to have vibes of Do The Right
Thing (tm) and could in time actually become so!

Does qemu support any sort of configurable defaults mechanism via config
file where we can punt this sort of thing to the distribution/packager?

-- 
Alex Bennée

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Thomas Huth]

On 08/01/2020 11.39, Alex Bennée wrote:
> 
> Thomas Huth <thuth@redhat.com> writes:
> 
>> 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?).
> 
> Indeed - you may well want to do TCG on Aarch64 if you want to test new
> instructions.
> 
>>
>> What about "-accel any" or "-accel fastest" or something similar?
> 
> "any" is just ambiguous, "fastest" is just begging for me to find a
> micro-benchmark that TCG outperforms on ;-)
> 
> "-accel default" could be considered to have vibes of Do The Right
> Thing (tm) and could in time actually become so!

"-accel default" sounds like the default behavior that you'd also get if
you don't use this option at all ... what about "-accel auto" to say
that QEMU should pick an accelerator automatically?

 Thomas

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Peter Maydell]

On Wed, 8 Jan 2020 at 10:40, Alex Bennée <alex.bennee@linaro.org> wrote:
> Thomas Huth <thuth@redhat.com> writes:
> > What about "-accel any" or "-accel fastest" or something similar?
>
> "any" is just ambiguous, "fastest" is just begging for me to find a
> micro-benchmark that TCG outperforms on ;-)
>
> "-accel default" could be considered to have vibes of Do The Right
> Thing (tm) and could in time actually become so!

That would be a weird choice, because it's not actually the default!

The obvious analogy here is with -cpu best, -machine gic-version=best,
etc -- use "best". You can argue that it's maybe not got the ideal
set of connotations, but I think that trying to be consistent about
the name we use for "do the thing that seems to be the most
sensible for the host/etc that we've got" is worthwhile.

thanks
-- PMM

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Paolo Bonzini]

On 08/01/20 11:58, Thomas Huth wrote:
>> "-accel default" could be considered to have vibes of Do The Right
>> Thing (tm) and could in time actually become so!
>
> "-accel default" sounds like the default behavior that you'd also get if
> you don't use this option at all ... what about "-accel auto" to say
> that QEMU should pick an accelerator automatically?

Questions to answer before thinking about the name: how would it
co-operate with other "-accel" options?  how would you pass sub-options
to the accelerators?

Paolo

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Daniel P. Berrangé]

On Wed, Jan 08, 2020 at 01:41:59PM +0100, Paolo Bonzini wrote:
> On 08/01/20 11:58, Thomas Huth wrote:
> >> "-accel default" could be considered to have vibes of Do The Right
> >> Thing (tm) and could in time actually become so!
> >
> > "-accel default" sounds like the default behavior that you'd also get if
> > you don't use this option at all ... what about "-accel auto" to say
> > that QEMU should pick an accelerator automatically?
> 
> Questions to answer before thinking about the name: how would it
> co-operate with other "-accel" options?  how would you pass sub-options
> to the accelerators?

If people don't have a preference for a specific accelerator, just need
"a working accelerator", then I think it is reasonable to assume they
won't want/need to pass options to the accelerators either.

"-accel default" is targetting the simple "do the right thing" use
case, so IMHO doesn't need to support per-accelerator options.

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)

[Paolo Bonzini]

On 08/01/20 14:10, Daniel P. Berrangé wrote:
> On Wed, Jan 08, 2020 at 01:41:59PM +0100, Paolo Bonzini wrote:
>> On 08/01/20 11:58, Thomas Huth wrote:
>>>> "-accel default" could be considered to have vibes of Do The Right
>>>> Thing (tm) and could in time actually become so!
>>>
>>> "-accel default" sounds like the default behavior that you'd also get if
>>> you don't use this option at all ... what about "-accel auto" to say
>>> that QEMU should pick an accelerator automatically?
>>
>> Questions to answer before thinking about the name: how would it
>> co-operate with other "-accel" options?  how would you pass sub-options
>> to the accelerators?
> 
> If people don't have a preference for a specific accelerator, just need
> "a working accelerator", then I think it is reasonable to assume they
> won't want/need to pass options to the accelerators either.
> 
> "-accel default" is targetting the simple "do the right thing" use
> case, so IMHO doesn't need to support per-accelerator options.

So basically the idea is to add an option that means "ignore every other
-accel option and act as if we had "-accel kvm -accel tcg"?  That seems
like a hack to me, especially since you can achieve the same effect with
a binary named qemu-kvm and no -accel options at all.

(As for the reason why TCG is preferred, it's because we already special
case binaries whose name ends with "kvm" and it keeps consistency
between all qemu-system-ARCH binaries).

Paolo

Re: Priority of -accel

[Thomas Huth]

On 08/01/2020 14.24, Paolo Bonzini wrote:
> On 08/01/20 14:10, Daniel P. Berrangé wrote:
>> On Wed, Jan 08, 2020 at 01:41:59PM +0100, Paolo Bonzini wrote:
>>> On 08/01/20 11:58, Thomas Huth wrote:
>>>>> "-accel default" could be considered to have vibes of Do The Right
>>>>> Thing (tm) and could in time actually become so!
>>>>
>>>> "-accel default" sounds like the default behavior that you'd also get if
>>>> you don't use this option at all ... what about "-accel auto" to say
>>>> that QEMU should pick an accelerator automatically?
>>>
>>> Questions to answer before thinking about the name: how would it
>>> co-operate with other "-accel" options?  how would you pass sub-options
>>> to the accelerators?
>>
>> If people don't have a preference for a specific accelerator, just need
>> "a working accelerator", then I think it is reasonable to assume they
>> won't want/need to pass options to the accelerators either.
>>
>> "-accel default" is targetting the simple "do the right thing" use
>> case, so IMHO doesn't need to support per-accelerator options.
> 
> So basically the idea is to add an option that means "ignore every other
> -accel option and act as if we had "-accel kvm -accel tcg"?  That seems
> like a hack to me, especially since you can achieve the same effect with
> a binary named qemu-kvm and no -accel options at all.

But we could disallow multiple "-accel" options in that case (or just
always use the last in the list), so we don't have to deal with
priorities of the options here at all... Well, not sure whether that's
really really better than what we currently have, so maybe we should
just keep it in the current shape...

 Thomas

Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)

[Peter Maydell]

On Wed, 8 Jan 2020 at 11:00, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Wed, 8 Jan 2020 at 10:40, Alex Bennée <alex.bennee@linaro.org> wrote:
> > Thomas Huth <thuth@redhat.com> writes:
> > > What about "-accel any" or "-accel fastest" or something similar?
> >
> > "any" is just ambiguous, "fastest" is just begging for me to find a
> > micro-benchmark that TCG outperforms on ;-)
> >
> > "-accel default" could be considered to have vibes of Do The Right
> > Thing (tm) and could in time actually become so!
>
> That would be a weird choice, because it's not actually the default!
>
> The obvious analogy here is with -cpu best, -machine gic-version=best,
> etc -- use "best". You can argue that it's maybe not got the ideal
> set of connotations, but I think that trying to be consistent about
> the name we use for "do the thing that seems to be the most
> sensible for the host/etc that we've got" is worthwhile.

This is actually a load of rubbish, because the cpu option is
'max', not 'best'. I still like consistency, though :-)

-- PMM

Re: Priority of -accel

[Markus Armbruster]

Thomas Huth <thuth@redhat.com> 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?

;-P

[...]

Re: Priority of -accel

[Christophe de Dinechin]

> On 13 Jan 2020, at 15:39, Markus Armbruster <armbru@redhat.com> wrote:
> 
> Thomas Huth <thuth@redhat.com> writes:
>>>> 
>>>> '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?
> 
> ;-P

Well, it makes perfect sense, since we select kvm first on macOS and, I guess,
all non-Linux platforms ;-)

% ./x86_64-softmmu/qemu-system-x86_64   
qemu-system-x86_64: invalid accelerator kvm
qemu-system-x86_64: falling back to tcg

(Fixing that knowing that CONFIG_KVM is poisoned in vl.c is left as an
exercise for the reader)

Christophe

Re: Priority of -accel

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 07/01/20 14:55, Christophe de Dinechin wrote:
>> So what about ranking the accelerators, so that all combinaisons
>> -accel=kvm:tcg, -accel=tcg:kvm, -accel kvm -accel tcg, etc would
>
> (I assume you mean "-machine accel=kvm:tcg" and "-machine accel=tcg:kvm"
> for the first two.  This is the "older" way which has now become sugar
> for "-accel kvm -accel tcg").
>
>> all pickup kvm if available, and tcg as a fallback? Implementation-wise,
>> it would simply mean ranking the accelerators and updating the accelerator
>> only if it’s available and better.
>
> This is an interesting idea.  I like this better than "-accel best",
> because "-accel best" has the problem that you can't add suboptions to
> it (the suboptions for the various accelerators are disjoint).
>
> It would break backwards compatibility for "-machine accel=tcg:kvm",
> which so far meant "use TCG if compiled in, otherwise use KVM".  This is
> not something I would have a problem with... except that "tcg:kvm" is
> the default if no -accel option is provided!

Perfect opportunity to change the default to something more useful.

Re: Priority of -accel

[Paolo Bonzini]

On 13/01/20 17:14, Christophe de Dinechin wrote:
> % ./x86_64-softmmu/qemu-system-x86_64   
> qemu-system-x86_64: invalid accelerator kvm
> qemu-system-x86_64: falling back to tcg

That is a bug, Richard Henderson has posted patches to fix it.

Paolo

Re: Priority of -accel

[Paolo Bonzini]

On 13/01/20 17:17, Markus Armbruster wrote:
> Perfect opportunity to change the default to something more useful.

I am not sure acutally if it's that more useful, now that we have
sanctioned qemu-kvm as the fast alternative.

Particularly it would be confusing for qemu-system-x86_64 to use
hardware virtualization on Linux, but not on other operating systems
where the accelerators are not stable enough.

Paolo

Re: Priority of -accel

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 13/01/20 17:17, Markus Armbruster wrote:
>> Perfect opportunity to change the default to something more useful.
>
> I am not sure acutally if it's that more useful, now that we have
> sanctioned qemu-kvm as the fast alternative.

If there is a fast alternative, why ship the slow one?

> Particularly it would be confusing for qemu-system-x86_64 to use
> hardware virtualization on Linux, but not on other operating systems
> where the accelerators are not stable enough.

Hardly more confusing than qemu-kvm not using hardware virtualization
when /dev/kvm is unavailable.

No matter what we do, somebody is going to be confused.  How to resolve
such a conundrum?  Utilitarian philosophy teaches us to pursue the
greatest confusion of the greatest numbers.  I think not using x86
hardware virtualization by default has been admirably successful there.

;-P

Re: Priority of -accel

[Paolo Bonzini]

On 14/01/20 09:59, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> On 13/01/20 17:17, Markus Armbruster wrote:
>>> Perfect opportunity to change the default to something more useful.
>>
>> I am not sure acutally if it's that more useful, now that we have
>> sanctioned qemu-kvm as the fast alternative.
> 
> If there is a fast alternative, why ship the slow one?

I find it more consistent that qemu-system-* is doing emulation (and can
usually be ignored) and qemu-kvm is doing virtualization.  It's more
intuitive to launch qemu-system-x86_64 than "qemu-kvm --no-kvm".

What we could do is automatically install a qemu-kvm binary for the
"most suitable" target that has KVM enabled (i.e. for
qemu-system-x86_64, not qemu-system-i386) instead of leaving it to distros.

Paolo

> No matter what we do, somebody is going to be confused.  How to resolve
> such a conundrum?  Utilitarian philosophy teaches us to pursue the
> greatest confusion of the greatest numbers.  I think not using x86
> hardware virtualization by default has been admirably successful there.

Re: Priority of -accel

[Christophe de Dinechin]

> On 13 Jan 2020, at 17:25, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 13/01/20 17:17, Markus Armbruster wrote:
>> Perfect opportunity to change the default to something more useful.
> 
> I am not sure acutally if it's that more useful, now that we have
> sanctioned qemu-kvm as the fast alternative.

OK, half a joke, but we should have tested on “q” at the beginning
rather than “-kvm” at the end ;-)

emu being the slow one ;-)

Re: Priority of -accel

[Daniel P. Berrangé]

On Tue, Jan 14, 2020 at 06:49:45PM +0100, Christophe de Dinechin wrote:
> 
> 
> > On 13 Jan 2020, at 17:25, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > 
> > On 13/01/20 17:17, Markus Armbruster wrote:
> >> Perfect opportunity to change the default to something more useful.
> > 
> > I am not sure acutally if it's that more useful, now that we have
> > sanctioned qemu-kvm as the fast alternative.
> 
> OK, half a joke, but we should have tested on “q” at the beginning
> rather than “-kvm” at the end ;-)
> 
> emu being the slow one ;-)

IIRC, Debian had (still has ?) it called /usr/bin/kvm

The qemu-kvm naming came from RHEL / Fedora land originally,
when the project was literally forked as a "qemu-kvm" git repo.

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 :|