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 tha
> 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, hal
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 a
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 ship
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
hardwar
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 f
> 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 Bonzi
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 th
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
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 defaul
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 a
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
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 considere
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 IM
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 pr
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 defa
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 probl
> 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 "-ma
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=t
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" wa
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 thi
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 w
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 p
> On 7 Jan 2020, at 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 "-acce
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 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
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
>
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 wa
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')
> >> Look
On Tue, Jan 7, 2020 at 1:34 PM Philippe Mathieu-Daudé 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')
>
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
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 t
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 a
35 matches
Mail list logo
