On Tue, Jan 14, 2020 at 06:49:45PM +0100, Christophe de Dinechin wrote:
>
>
> > On 13 Jan 2020, at 17:25, Paolo Bonzini 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
> On 13 Jan 2020, at 17:25, Paolo Bonzini 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,
On 14/01/20 09:59, Markus Armbruster wrote:
> Paolo Bonzini 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
Paolo Bonzini 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
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
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
Paolo Bonzini 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
> On 13 Jan 2020, at 15:39, Markus Armbruster wrote:
>
> Thomas Huth 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
Thomas Huth 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
On Wed, 8 Jan 2020 at 11:00, Peter Maydell wrote:
>
> On Wed, 8 Jan 2020 at 10:40, Alex Bennée wrote:
> > Thomas Huth 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
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
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
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
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
On Wed, 8 Jan 2020 at 10:40, Alex Bennée wrote:
> Thomas Huth 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
On 08/01/2020 11.39, Alex Bennée wrote:
>
> Thomas Huth 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
Thomas Huth 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
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
On Tue, 7 Jan 2020 at 17:44, Christophe de Dinechin wrote:
> > On 7 Jan 2020, at 15:37, Paolo Bonzini 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
> On 7 Jan 2020, at 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
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"
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
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
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
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
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
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
ndeed 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
; 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 a
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
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
;> "-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" =)
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
tch "-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
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:
>
d 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
36 matches
Mail list logo
