On Wed, Jun 27, 2018 at 10:39:29AM +0200, Paolo Bonzini wrote:
> On 26/06/2018 18:06, Eduardo Habkost wrote:
> >> On the other hand I see no benefit in changing a default that people are
> >> obviously not using (since most people use KVM, not TCG). Distros will
> >> keep shipping, and people will
On 26/06/2018 18:43, Markus Armbruster wrote:
>>> Not sure how serious you meant that, but I actually quite like the
>>> idea :)
>> Also, this mode could be enabled by default if stderr is a tty.
> It could be enabled by default, period.
I agree, summarizing the configuration to stderr on startup
On 26/06/2018 18:06, Eduardo Habkost wrote:
>> On the other hand I see no benefit in changing a default that people are
>> obviously not using (since most people use KVM, not TCG). Distros will
>> keep shipping, and people will keep using qemu-kvm even if we change the
>> default.
>
> Not changing
Eduardo Habkost writes:
> On Tue, Jun 26, 2018 at 09:50:04AM +0200, Cornelia Huck wrote:
>> On Tue, 26 Jun 2018 06:40:56 +0200
>> Thomas Huth wrote:
>>
>> > On 25.06.2018 20:26, Paolo Bonzini wrote:
>> > > On 25/06/2018 19:30, Eduardo Habkost wrote:
>> > Attentive distros could even repl
On Tue, Jun 26, 2018 at 01:06:23PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 26, 2018 at 03:05:33PM +0200, Paolo Bonzini wrote:
> > On 26/06/2018 14:29, Eduardo Habkost wrote:
> > > On Tue, Jun 26, 2018 at 07:57:18AM +0200, Paolo Bonzini wrote:
> > >> On 25/06/2018 21:51, Eduardo Habkost wrote:
>
On Tue, Jun 26, 2018 at 03:05:33PM +0200, Paolo Bonzini wrote:
> On 26/06/2018 14:29, Eduardo Habkost wrote:
> > On Tue, Jun 26, 2018 at 07:57:18AM +0200, Paolo Bonzini wrote:
> >> On 25/06/2018 21:51, Eduardo Habkost wrote:
> >>> In either case, I'm not arguing (yet) for changing the default
> >>>
On 26/06/2018 14:29, Eduardo Habkost wrote:
> On Tue, Jun 26, 2018 at 07:57:18AM +0200, Paolo Bonzini wrote:
>> On 25/06/2018 21:51, Eduardo Habkost wrote:
>>> In either case, I'm not arguing (yet) for changing the default
>>> upstream. I'm just arguing for upstream QEMU to not make any
>>> promis
On Tue, Jun 26, 2018 at 09:50:04AM +0200, Cornelia Huck wrote:
> On Tue, 26 Jun 2018 06:40:56 +0200
> Thomas Huth wrote:
>
> > On 25.06.2018 20:26, Paolo Bonzini wrote:
> > > On 25/06/2018 19:30, Eduardo Habkost wrote:
> > Attentive distros could even replace the wrapper script by a link.
On Tue, Jun 26, 2018 at 07:57:18AM +0200, Paolo Bonzini wrote:
> On 25/06/2018 21:51, Eduardo Habkost wrote:
> > In either case, I'm not arguing (yet) for changing the default
> > upstream. I'm just arguing for upstream QEMU to not make any
> > promises about the default.
>
> It would be a guest
On Tue, 26 Jun 2018 06:40:56 +0200
Thomas Huth wrote:
> On 25.06.2018 20:26, Paolo Bonzini wrote:
> > On 25/06/2018 19:30, Eduardo Habkost wrote:
> Attentive distros could even replace the wrapper script by a link.
> >>> If they are okay with replacing the "KVM only" semantics with "KVM
On 25/06/2018 21:51, Eduardo Habkost wrote:
>> Before that we should ask what the benefit is in changing the default
>> for qemu-system-*. Nobody is using it in practice to start QEMU with
>> KVM enabled...
>
> How can you be sure? If qemu-system-* is installed with KVM
> compiled in, libvirt wil
On 25.06.2018 20:26, Paolo Bonzini wrote:
> On 25/06/2018 19:30, Eduardo Habkost wrote:
Attentive distros could even replace the wrapper script by a link.
>>> If they are okay with replacing the "KVM only" semantics with "KVM or
>>> TCG", which I think is generally worse.
>>
>> If we can't get
On Mon, Jun 25, 2018 at 08:26:28PM +0200, Paolo Bonzini wrote:
> On 25/06/2018 19:30, Eduardo Habkost wrote:
> >>> Attentive distros could even replace the wrapper script by a link.
> >> If they are okay with replacing the "KVM only" semantics with "KVM or
> >> TCG", which I think is generally wors
On 25/06/2018 19:30, Eduardo Habkost wrote:
>>> Attentive distros could even replace the wrapper script by a link.
>> If they are okay with replacing the "KVM only" semantics with "KVM or
>> TCG", which I think is generally worse.
>
> If we can't get agreement on what's the right default for each
>
On Mon, Jun 25, 2018 at 12:28:34PM +0200, Paolo Bonzini wrote:
> On 25/06/2018 08:50, Markus Armbruster wrote:
> > Paolo Bonzini writes:
> >
> >> On 22/06/2018 21:35, Eduardo Habkost wrote:
> > Why is this better than using KVM by default if it's available?
> The answer is (as almost alw
On 25/06/2018 08:50, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 22/06/2018 21:35, Eduardo Habkost wrote:
> Why is this better than using KVM by default if it's available?
The answer is (as almost always): Compatibility with migration. Nobody
dares to sacrifice that chi
Paolo Bonzini writes:
> On 22/06/2018 21:35, Eduardo Habkost wrote:
Why is this better than using KVM by default if it's available?
>>> The answer is (as almost always): Compatibility with migration. Nobody
>>> dares to sacrifice that chicken :-(
>> We can now kill it if we announce the feat
On 22/06/2018 21:35, Eduardo Habkost wrote:
>>> Why is this better than using KVM by default if it's available?
>> The answer is (as almost always): Compatibility with migration. Nobody
>> dares to sacrifice that chicken :-(
> We can now kill it if we announce the feature as deprecated a
> couple o
On Fri, Jun 22, 2018 at 09:19:56PM +0200, Thomas Huth wrote:
> On 22.06.2018 20:11, Eduardo Habkost wrote:
> > On Tue, Jun 19, 2018 at 06:16:33PM +0200, Paolo Bonzini wrote:
> >> On 19/06/2018 17:15, Cornelia Huck wrote:
> Why does a user have to know how to enable KVM? Oh, because our defaul
On 22.06.2018 20:11, Eduardo Habkost wrote:
> On Tue, Jun 19, 2018 at 06:16:33PM +0200, Paolo Bonzini wrote:
>> On 19/06/2018 17:15, Cornelia Huck wrote:
Why does a user have to know how to enable KVM? Oh, because our default
is "run this guest much slower than necessary". Great!
>>> Sh
On Tue, Jun 19, 2018 at 06:16:33PM +0200, Paolo Bonzini wrote:
> On 19/06/2018 17:15, Cornelia Huck wrote:
> >> Why does a user have to know how to enable KVM? Oh, because our default
> >> is "run this guest much slower than necessary". Great!
> > Should we try again to default to a better accele
On 19/06/2018 17:15, Cornelia Huck wrote:
>> Why does a user have to know how to enable KVM? Oh, because our default
>> is "run this guest much slower than necessary". Great!
> Should we try again to default to a better accelerator, if possible? I
> don't quite recall why we didn't do so the last
On Wed, 13 Jun 2018 18:02:27 +0200
Markus Armbruster wrote:
> Daniel P. Berrangé writes:
> > If I'm a user looking for how to enable KVM, then -enable-kvm is the
> > one I'll pick because of the obvious name.
>
> Why does a user have to know how to enable KVM? Oh, because our default
> is "
Daniel P. Berrangé writes:
> On Wed, Jun 13, 2018 at 05:11:51PM +0200, Thomas Huth wrote:
>> On 13.06.2018 15:44, Daniel P. Berrangé wrote:
>> > On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
>> >> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
>> >>> We've got thr
On 13.06.2018 17:19, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 05:11:51PM +0200, Thomas Huth wrote:
>> On 13.06.2018 15:44, Daniel P. Berrangé wrote:
>>> On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
On Wed, Jun 13, 2018 at 05:11:51PM +0200, Thomas Huth wrote:
> On 13.06.2018 15:44, Daniel P. Berrangé wrote:
> > On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
> >> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
> >>> We've got three ways of enabling an accelerator:
On 13.06.2018 15:44, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
>> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
>>> We've got three ways of enabling an accelerator: -machine accel=xyz,
>>> -accel xyz and -enable-xyz. For new QEMU use
On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
> > We've got three ways of enabling an accelerator: -machine accel=xyz,
> > -accel xyz and -enable-xyz. For new QEMU users, this must be very
> > confusing ("Which one do
On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
> We've got three ways of enabling an accelerator: -machine accel=xyz,
> -accel xyz and -enable-xyz. For new QEMU users, this must be very
> confusing ("Which one do I have to use? Is there a difference between
> the options?"). While -en
On 13/06/2018 07:05, Thomas Huth wrote:
> We've got three ways of enabling an accelerator: -machine accel=xyz,
> -accel xyz and -enable-xyz. For new QEMU users, this must be very
> confusing ("Which one do I have to use? Is there a difference between
> the options?"). While -enable-kvm was useful i
We've got three ways of enabling an accelerator: -machine accel=xyz,
-accel xyz and -enable-xyz. For new QEMU users, this must be very
confusing ("Which one do I have to use? Is there a difference between
the options?"). While -enable-kvm was useful in the past, there is no
real good reason for usi
31 matches
Mail list logo
