* [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 related [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: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 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 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 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-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 (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 (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: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 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 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 (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 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 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 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: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, other threads:[~2020-01-14 18:00 UTC | newest] 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é
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).