QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option
@ 2020-01-06 13:09 Philippe Mathieu-Daudé
  2020-01-06 13:16 ` Max Reitz
  2020-01-07 10:03 ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Thomas Huth
  0 siblings, 2 replies; 38+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-01-06 13:09 UTC (permalink / raw)
  To: qemu-devel, Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, qemu-block, Wainer dos Santos Moschetta,
	Max Reitz, 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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option
  2020-01-06 13:09 [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option Philippe Mathieu-Daudé
@ 2020-01-06 13:16 ` Max Reitz
  2020-01-07 10:03 ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Thomas Huth
  1 sibling, 0 replies; 38+ messages in thread
From: Max Reitz @ 2020-01-06 13:16 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, qemu-devel, Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, qemu-block, Wainer dos Santos Moschetta

[-- 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 --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-06 13:09 [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option Philippe Mathieu-Daudé
  2020-01-06 13:16 ` Max Reitz
@ 2020-01-07 10:03 ` Thomas Huth
  2020-01-07 10:14   ` Paolo Bonzini
  1 sibling, 1 reply; 38+ messages in thread
From: Thomas Huth @ 2020-01-07 10:03 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Paolo Bonzini
  Cc: Kevin Wolf, qemu-block, qemu-devel, Wainer dos Santos Moschetta,
	Max Reitz

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 10:03 ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Thomas Huth
@ 2020-01-07 10:14   ` Paolo Bonzini
  2020-01-07 12:18     ` Thomas Huth
  2020-01-07 13:55     ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Christophe de Dinechin
  0 siblings, 2 replies; 38+ messages in thread
From: Paolo Bonzini @ 2020-01-07 10:14 UTC (permalink / raw)
  To: Thomas Huth, Philippe Mathieu-Daudé
  Cc: Kevin Wolf, qemu-block, qemu-devel, Wainer dos Santos Moschetta,
	Max Reitz

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 10:14   ` Paolo Bonzini
@ 2020-01-07 12:18     ` Thomas Huth
  2020-01-07 12:23       ` Paolo Bonzini
                         ` (2 more replies)
  2020-01-07 13:55     ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Christophe de Dinechin
  1 sibling, 3 replies; 38+ messages in thread
From: Thomas Huth @ 2020-01-07 12:18 UTC (permalink / raw)
  To: Paolo Bonzini, Philippe Mathieu-Daudé
  Cc: Kevin Wolf, Daniel P. Berrange, qemu-block, Markus Armbruster,
	qemu-devel, Wainer dos Santos Moschetta, Max Reitz

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 12:18     ` Thomas Huth
@ 2020-01-07 12:23       ` Paolo Bonzini
  2020-01-07 12:54         ` Daniel P. Berrangé
  2020-01-07 12:29       ` Kevin Wolf
  2020-01-07 12:34       ` Priority of -accel Philippe Mathieu-Daudé
  2 siblings, 1 reply; 38+ messages in thread
From: Paolo Bonzini @ 2020-01-07 12:23 UTC (permalink / raw)
  To: Thomas Huth, Philippe Mathieu-Daudé
  Cc: Kevin Wolf, Daniel P. Berrange, qemu-block, Markus Armbruster,
	qemu-devel, Wainer dos Santos Moschetta, Max Reitz

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?



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 12:18     ` Thomas Huth
  2020-01-07 12:23       ` Paolo Bonzini
@ 2020-01-07 12:29       ` Kevin Wolf
  2020-01-07 12:34       ` Priority of -accel Philippe Mathieu-Daudé
  2 siblings, 0 replies; 38+ messages in thread
From: Kevin Wolf @ 2020-01-07 12:29 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Daniel P. Berrange, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz, Paolo Bonzini,
	Philippe Mathieu-Daudé,
	Markus Armbruster

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-07 12:18     ` Thomas Huth
  2020-01-07 12:23       ` Paolo Bonzini
  2020-01-07 12:29       ` Kevin Wolf
@ 2020-01-07 12:34       ` Philippe Mathieu-Daudé
  2020-01-07 12:37         ` Philippe Mathieu-Daudé
  2 siblings, 1 reply; 38+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-01-07 12:34 UTC (permalink / raw)
  To: Thomas Huth, Paolo Bonzini
  Cc: Kevin Wolf, Daniel P. Berrange, qemu-block, Markus Armbruster,
	qemu-devel, Wainer dos Santos Moschetta, Max Reitz

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-07 12:34       ` Priority of -accel Philippe Mathieu-Daudé
@ 2020-01-07 12:37         ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 38+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-01-07 12:37 UTC (permalink / raw)
  To: Thomas Huth, Paolo Bonzini
  Cc: Kevin Wolf, Daniel P. Berrange, Qemu-block, Markus Armbruster,
	QEMU Developers, Wainer dos Santos Moschetta, Max Reitz

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" =)



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 12:23       ` Paolo Bonzini
@ 2020-01-07 12:54         ` Daniel P. Berrangé
  2020-01-07 14:14           ` Thomas Huth
  0 siblings, 1 reply; 38+ messages in thread
From: Daniel P. Berrangé @ 2020-01-07 12:54 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, qemu-block, Markus Armbruster,
	Wainer dos Santos Moschetta, qemu-devel, Max Reitz,
	Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 10:14   ` Paolo Bonzini
  2020-01-07 12:18     ` Thomas Huth
@ 2020-01-07 13:55     ` Christophe de Dinechin
  2020-01-07 14:37       ` Paolo Bonzini
  1 sibling, 1 reply; 38+ messages in thread
From: Christophe de Dinechin @ 2020-01-07 13:55 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz,
	Philippe Mathieu-Daudé



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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 12:54         ` Daniel P. Berrangé
@ 2020-01-07 14:14           ` Thomas Huth
  2020-01-07 14:20             ` Priority of -accel Philippe Mathieu-Daudé
                               ` (2 more replies)
  0 siblings, 3 replies; 38+ messages in thread
From: Thomas Huth @ 2020-01-07 14:14 UTC (permalink / raw)
  To: Daniel P. Berrangé, Paolo Bonzini
  Cc: Kevin Wolf, qemu-block, Markus Armbruster,
	Wainer dos Santos Moschetta, qemu-devel, Max Reitz,
	Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-07 14:14           ` Thomas Huth
@ 2020-01-07 14:20             ` Philippe Mathieu-Daudé
  2020-01-07 14:27               ` Daniel P. Berrangé
  2020-01-07 14:26             ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Daniel P. Berrangé
  2020-01-08 10:39             ` Alex Bennée
  2 siblings, 1 reply; 38+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-01-07 14:20 UTC (permalink / raw)
  To: Thomas Huth, Daniel P. Berrangé, Paolo Bonzini
  Cc: Kevin Wolf, qemu-block, qemu-devel, Markus Armbruster,
	Wainer dos Santos Moschetta, Max Reitz

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 14:14           ` Thomas Huth
  2020-01-07 14:20             ` Priority of -accel Philippe Mathieu-Daudé
@ 2020-01-07 14:26             ` Daniel P. Berrangé
  2020-01-08 10:39             ` Alex Bennée
  2 siblings, 0 replies; 38+ messages in thread
From: Daniel P. Berrangé @ 2020-01-07 14:26 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Kevin Wolf, qemu-block, Markus Armbruster,
	Wainer dos Santos Moschetta, qemu-devel, Paolo Bonzini,
	Max Reitz, Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-07 14:20             ` Priority of -accel Philippe Mathieu-Daudé
@ 2020-01-07 14:27               ` Daniel P. Berrangé
  2020-01-07 14:35                 ` Thomas Huth
  0 siblings, 1 reply; 38+ messages in thread
From: Daniel P. Berrangé @ 2020-01-07 14:27 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Kevin Wolf, Thomas Huth, qemu-block, Markus Armbruster,
	Wainer dos Santos Moschetta, qemu-devel, Paolo Bonzini,
	Max Reitz

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-07 14:27               ` Daniel P. Berrangé
@ 2020-01-07 14:35                 ` Thomas Huth
  2020-01-13 14:39                   ` Markus Armbruster
  0 siblings, 1 reply; 38+ messages in thread
From: Thomas Huth @ 2020-01-07 14:35 UTC (permalink / raw)
  To: Daniel P. Berrangé, Philippe Mathieu-Daudé
  Cc: Kevin Wolf, qemu-block, Markus Armbruster,
	Wainer dos Santos Moschetta, qemu-devel, Paolo Bonzini,
	Max Reitz

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 13:55     ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Christophe de Dinechin
@ 2020-01-07 14:37       ` Paolo Bonzini
  2020-01-07 14:42         ` Thomas Huth
                           ` (2 more replies)
  0 siblings, 3 replies; 38+ messages in thread
From: Paolo Bonzini @ 2020-01-07 14:37 UTC (permalink / raw)
  To: Christophe de Dinechin
  Cc: Kevin Wolf, Thomas Huth, Daniel Berrange, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz,
	Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 14:37       ` Paolo Bonzini
@ 2020-01-07 14:42         ` Thomas Huth
  2020-01-07 17:43         ` Christophe de Dinechin
  2020-01-13 16:17         ` Priority of -accel Markus Armbruster
  2 siblings, 0 replies; 38+ messages in thread
From: Thomas Huth @ 2020-01-07 14:42 UTC (permalink / raw)
  To: Paolo Bonzini, Christophe de Dinechin
  Cc: Kevin Wolf, Daniel Berrange, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz,
	Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 14:37       ` Paolo Bonzini
  2020-01-07 14:42         ` Thomas Huth
@ 2020-01-07 17:43         ` Christophe de Dinechin
  2020-01-07 17:53           ` Peter Maydell
  2020-01-08  9:47           ` Kevin Wolf
  2020-01-13 16:17         ` Priority of -accel Markus Armbruster
  2 siblings, 2 replies; 38+ messages in thread
From: Christophe de Dinechin @ 2020-01-07 17:43 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, Daniel Berrange, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz,
	Philippe Mathieu-Daudé



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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 17:43         ` Christophe de Dinechin
@ 2020-01-07 17:53           ` Peter Maydell
  2020-01-08  9:47           ` Kevin Wolf
  1 sibling, 0 replies; 38+ messages in thread
From: Peter Maydell @ 2020-01-07 17:53 UTC (permalink / raw)
  To: Christophe de Dinechin
  Cc: Kevin Wolf, Thomas Huth, Daniel Berrange, Qemu-block,
	QEMU Developers, Wainer dos Santos Moschetta, Max Reitz,
	Paolo Bonzini, Philippe Mathieu-Daudé

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


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 17:43         ` Christophe de Dinechin
  2020-01-07 17:53           ` Peter Maydell
@ 2020-01-08  9:47           ` Kevin Wolf
  1 sibling, 0 replies; 38+ messages in thread
From: Kevin Wolf @ 2020-01-08  9:47 UTC (permalink / raw)
  To: Christophe de Dinechin
  Cc: Thomas Huth, Daniel Berrange, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz, Paolo Bonzini,
	Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-07 14:14           ` Thomas Huth
  2020-01-07 14:20             ` Priority of -accel Philippe Mathieu-Daudé
  2020-01-07 14:26             ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Daniel P. Berrangé
@ 2020-01-08 10:39             ` Alex Bennée
  2020-01-08 10:58               ` Thomas Huth
  2020-01-08 11:00               ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Peter Maydell
  2 siblings, 2 replies; 38+ messages in thread
From: Alex Bennée @ 2020-01-08 10:39 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Daniel P. Berrangé,
	qemu-block, Markus Armbruster, Wainer dos Santos Moschetta,
	Max Reitz, Paolo Bonzini, Philippe Mathieu-Daudé


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


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-08 10:39             ` Alex Bennée
@ 2020-01-08 10:58               ` Thomas Huth
  2020-01-08 12:41                 ` Paolo Bonzini
  2020-01-08 11:00               ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Peter Maydell
  1 sibling, 1 reply; 38+ messages in thread
From: Thomas Huth @ 2020-01-08 10:58 UTC (permalink / raw)
  To: Alex Bennée, qemu-devel
  Cc: Kevin Wolf, Daniel P. Berrangé,
	qemu-block, Markus Armbruster, Wainer dos Santos Moschetta,
	Max Reitz, Paolo Bonzini, Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-08 10:39             ` Alex Bennée
  2020-01-08 10:58               ` Thomas Huth
@ 2020-01-08 11:00               ` Peter Maydell
  2020-01-10 10:43                 ` Peter Maydell
  1 sibling, 1 reply; 38+ messages in thread
From: Peter Maydell @ 2020-01-08 11:00 UTC (permalink / raw)
  To: Alex Bennée
  Cc: Kevin Wolf, Daniel P. Berrangé,
	Qemu-block, QEMU Developers, Wainer dos Santos Moschetta,
	Markus Armbruster, Paolo Bonzini, Max Reitz,
	Philippe Mathieu-Daudé

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


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-08 10:58               ` Thomas Huth
@ 2020-01-08 12:41                 ` Paolo Bonzini
  2020-01-08 13:10                   ` Daniel P. Berrangé
  0 siblings, 1 reply; 38+ messages in thread
From: Paolo Bonzini @ 2020-01-08 12:41 UTC (permalink / raw)
  To: Thomas Huth, Alex Bennée, qemu-devel
  Cc: Kevin Wolf, Daniel P. Berrangé,
	qemu-block, Markus Armbruster, Wainer dos Santos Moschetta,
	Max Reitz, Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-08 12:41                 ` Paolo Bonzini
@ 2020-01-08 13:10                   ` Daniel P. Berrangé
  2020-01-08 13:24                     ` Paolo Bonzini
  0 siblings, 1 reply; 38+ messages in thread
From: Daniel P. Berrangé @ 2020-01-08 13:10 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, qemu-block, Philippe Mathieu-Daudé,
	qemu-devel, Wainer dos Santos Moschetta, Markus Armbruster,
	Max Reitz, Alex Bennée

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-08 13:10                   ` Daniel P. Berrangé
@ 2020-01-08 13:24                     ` Paolo Bonzini
  2020-01-08 14:00                       ` Priority of -accel Thomas Huth
  0 siblings, 1 reply; 38+ messages in thread
From: Paolo Bonzini @ 2020-01-08 13:24 UTC (permalink / raw)
  To: Daniel P. Berrangé
  Cc: Kevin Wolf, Thomas Huth, qemu-block, Philippe Mathieu-Daudé,
	qemu-devel, Wainer dos Santos Moschetta, Markus Armbruster,
	Max Reitz, Alex Bennée

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-08 13:24                     ` Paolo Bonzini
@ 2020-01-08 14:00                       ` Thomas Huth
  0 siblings, 0 replies; 38+ messages in thread
From: Thomas Huth @ 2020-01-08 14:00 UTC (permalink / raw)
  To: Paolo Bonzini, Daniel P. Berrangé
  Cc: Kevin Wolf, qemu-block, Alex Bennée, Markus Armbruster,
	Wainer dos Santos Moschetta, qemu-devel, Max Reitz,
	Philippe Mathieu-Daudé

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




^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option)
  2020-01-08 11:00               ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Peter Maydell
@ 2020-01-10 10:43                 ` Peter Maydell
  0 siblings, 0 replies; 38+ messages in thread
From: Peter Maydell @ 2020-01-10 10:43 UTC (permalink / raw)
  To: Alex Bennée
  Cc: Kevin Wolf, Daniel P. Berrangé,
	Qemu-block, QEMU Developers, Wainer dos Santos Moschetta,
	Markus Armbruster, Paolo Bonzini, Max Reitz,
	Philippe Mathieu-Daudé

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


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-07 14:35                 ` Thomas Huth
@ 2020-01-13 14:39                   ` Markus Armbruster
  2020-01-13 16:14                     ` Christophe de Dinechin
  0 siblings, 1 reply; 38+ messages in thread
From: Markus Armbruster @ 2020-01-13 14:39 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Kevin Wolf, Daniel P. Berrangé,
	qemu-block, qemu-devel, Wainer dos Santos Moschetta, Max Reitz,
	Paolo Bonzini, Philippe Mathieu-Daudé

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

[...]



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-13 14:39                   ` Markus Armbruster
@ 2020-01-13 16:14                     ` Christophe de Dinechin
  2020-01-13 16:23                       ` Paolo Bonzini
  0 siblings, 1 reply; 38+ messages in thread
From: Christophe de Dinechin @ 2020-01-13 16:14 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Kevin Wolf, Thomas Huth, \"Daniel P. Berrangé\,
	qemu-block, qemu-devel, Wainer dos Santos Moschetta, Max Reitz,
	Paolo Bonzini, Philippe Mathieu-Daudé



> 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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-07 14:37       ` Paolo Bonzini
  2020-01-07 14:42         ` Thomas Huth
  2020-01-07 17:43         ` Christophe de Dinechin
@ 2020-01-13 16:17         ` Markus Armbruster
  2020-01-13 16:25           ` Paolo Bonzini
  2 siblings, 1 reply; 38+ messages in thread
From: Markus Armbruster @ 2020-01-13 16:17 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, Daniel Berrange, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz, Christophe de Dinechin,
	Philippe Mathieu-Daudé

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.



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-13 16:14                     ` Christophe de Dinechin
@ 2020-01-13 16:23                       ` Paolo Bonzini
  0 siblings, 0 replies; 38+ messages in thread
From: Paolo Bonzini @ 2020-01-13 16:23 UTC (permalink / raw)
  To: Christophe de Dinechin, Markus Armbruster
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	qemu-block, qemu-devel, Wainer dos Santos Moschetta, Max Reitz,
	Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-13 16:17         ` Priority of -accel Markus Armbruster
@ 2020-01-13 16:25           ` Paolo Bonzini
  2020-01-14  8:59             ` Markus Armbruster
  2020-01-14 17:49             ` Christophe de Dinechin
  0 siblings, 2 replies; 38+ messages in thread
From: Paolo Bonzini @ 2020-01-13 16:25 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Kevin Wolf, Thomas Huth, Daniel Berrange, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz, Christophe de Dinechin,
	Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-13 16:25           ` Paolo Bonzini
@ 2020-01-14  8:59             ` Markus Armbruster
  2020-01-14 10:44               ` Paolo Bonzini
  2020-01-14 17:49             ` Christophe de Dinechin
  1 sibling, 1 reply; 38+ messages in thread
From: Markus Armbruster @ 2020-01-14  8:59 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, Daniel Berrange, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz, Christophe de Dinechin,
	Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-14  8:59             ` Markus Armbruster
@ 2020-01-14 10:44               ` Paolo Bonzini
  0 siblings, 0 replies; 38+ messages in thread
From: Paolo Bonzini @ 2020-01-14 10:44 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Kevin Wolf, Thomas Huth, Daniel Berrange, qemu-block, qemu-devel,
	Wainer dos Santos Moschetta, Max Reitz, Christophe de Dinechin,
	Philippe Mathieu-Daudé

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.



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-13 16:25           ` Paolo Bonzini
  2020-01-14  8:59             ` Markus Armbruster
@ 2020-01-14 17:49             ` Christophe de Dinechin
  2020-01-14 17:59               ` Daniel P. Berrangé
  1 sibling, 1 reply; 38+ messages in thread
From: Christophe de Dinechin @ 2020-01-14 17:49 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, Daniel Berrange, qemu-block,
	Markus Armbruster, Wainer dos Santos Moschetta, qemu-devel,
	Max Reitz, Philippe Mathieu-Daudé



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



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: Priority of -accel
  2020-01-14 17:49             ` Christophe de Dinechin
@ 2020-01-14 17:59               ` Daniel P. Berrangé
  0 siblings, 0 replies; 38+ messages in thread
From: Daniel P. Berrangé @ 2020-01-14 17:59 UTC (permalink / raw)
  To: Christophe de Dinechin
  Cc: Kevin Wolf, Thomas Huth, qemu-block, Markus Armbruster,
	Wainer dos Santos Moschetta, qemu-devel, Paolo Bonzini,
	Max Reitz, Philippe Mathieu-Daudé

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



^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, back to index

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-06 13:09 [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option Philippe Mathieu-Daudé
2020-01-06 13:16 ` Max Reitz
2020-01-07 10:03 ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Thomas Huth
2020-01-07 10:14   ` Paolo Bonzini
2020-01-07 12:18     ` Thomas Huth
2020-01-07 12:23       ` Paolo Bonzini
2020-01-07 12:54         ` Daniel P. Berrangé
2020-01-07 14:14           ` Thomas Huth
2020-01-07 14:20             ` Priority of -accel Philippe Mathieu-Daudé
2020-01-07 14:27               ` Daniel P. Berrangé
2020-01-07 14:35                 ` Thomas Huth
2020-01-13 14:39                   ` Markus Armbruster
2020-01-13 16:14                     ` Christophe de Dinechin
2020-01-13 16:23                       ` Paolo Bonzini
2020-01-07 14:26             ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Daniel P. Berrangé
2020-01-08 10:39             ` Alex Bennée
2020-01-08 10:58               ` Thomas Huth
2020-01-08 12:41                 ` Paolo Bonzini
2020-01-08 13:10                   ` Daniel P. Berrangé
2020-01-08 13:24                     ` Paolo Bonzini
2020-01-08 14:00                       ` Priority of -accel Thomas Huth
2020-01-08 11:00               ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Peter Maydell
2020-01-10 10:43                 ` Peter Maydell
2020-01-07 12:29       ` Kevin Wolf
2020-01-07 12:34       ` Priority of -accel Philippe Mathieu-Daudé
2020-01-07 12:37         ` Philippe Mathieu-Daudé
2020-01-07 13:55     ` Priority of -accel (was: [PATCH] tests/qemu-iotests: Update tests to recent desugarized -accel option) Christophe de Dinechin
2020-01-07 14:37       ` Paolo Bonzini
2020-01-07 14:42         ` Thomas Huth
2020-01-07 17:43         ` Christophe de Dinechin
2020-01-07 17:53           ` Peter Maydell
2020-01-08  9:47           ` Kevin Wolf
2020-01-13 16:17         ` Priority of -accel Markus Armbruster
2020-01-13 16:25           ` Paolo Bonzini
2020-01-14  8:59             ` Markus Armbruster
2020-01-14 10:44               ` Paolo Bonzini
2020-01-14 17:49             ` Christophe de Dinechin
2020-01-14 17:59               ` Daniel P. Berrangé

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git