On 08.10.2012, at 16:03, Andreas Färber wrote:
> Am 05.10.2012 04:24, schrieb Alexander Graf:
>>
>> On 05.10.2012, at 04:17, Anthony Liguori wrote:
>>
>>> Alexander Graf writes:
>>>
On 03.10.2012, at 22:26, Peter Maydell wrote:
> On 3 October 2012 21:01, Blue Swirl wrote:
Am 05.10.2012 04:24, schrieb Alexander Graf:
>
> On 05.10.2012, at 04:17, Anthony Liguori wrote:
>
>> Alexander Graf writes:
>>
>>> On 03.10.2012, at 22:26, Peter Maydell wrote:
>>>
On 3 October 2012 21:01, Blue Swirl wrote:
> On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori
> wro
On 5 October 2012 03:24, Alexander Graf wrote:
> On 05.10.2012, at 04:17, Anthony Liguori wrote:
>> Alexander Graf writes:
>>> We get similar problems on PPC. Take the following example:
>>>
>>> $ qemu-system-ppc -M mpc8544ds -kernel uImage -nographic
>>
>> But do you really expect people to do
On 05.10.2012, at 04:17, Anthony Liguori wrote:
> Alexander Graf writes:
>
>> On 03.10.2012, at 22:26, Peter Maydell wrote:
>>
>>> On 3 October 2012 21:01, Blue Swirl wrote:
On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori
wrote:
> Jan Kiszka writes:
>> +/* The def
Alexander Graf writes:
> On 03.10.2012, at 22:26, Peter Maydell wrote:
>
>> On 3 October 2012 21:01, Blue Swirl wrote:
>>> On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori
>>> wrote:
Jan Kiszka writes:
> +/* The default accelerator depends on the availability of KVM. */
>
On 03.10.2012, at 22:26, Peter Maydell wrote:
> On 3 October 2012 21:01, Blue Swirl wrote:
>> On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori
>> wrote:
>>> Jan Kiszka writes:
+/* The default accelerator depends on the availability of KVM. */
+p = kvm_configured ? "kv
On 3 October 2012 21:01, Blue Swirl wrote:
> On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori wrote:
>> Jan Kiszka writes:
>>> +/* The default accelerator depends on the availability of KVM. */
>>> +p = kvm_configured ? "kvm" : "tcg";
>>> }
>> Blue/Aurelien, any objections?
On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori wrote:
> Jan Kiszka writes:
>
>> If we built a target for a host that supports KVM in principle, set the
>> default accelerator to KVM as well. This also means the start of QEMU
>> will fail to start if KVM support turns out to be unavailable at
>>
On 2012-10-03 08:58, Michael Tokarev wrote:
> On 02.10.2012 11:46, Markus Armbruster wrote:
>> "Daniel P. Berrange" writes:
>
>>> IMHO, default to KVM, fallback to TCG is the most friendly default
>>> behaviour.
>>
>> Friendly perhaps, generating an infinite series of questions "why is my
>> gues
On 2012-10-01 18:20, Anthony Liguori wrote:
> Jan Kiszka writes:
>
>> If we built a target for a host that supports KVM in principle, set the
>> default accelerator to KVM as well. This also means the start of QEMU
>> will fail to start if KVM support turns out to be unavailable at
>> runtime.
>>
On 02.10.2012 11:46, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>> IMHO, default to KVM, fallback to TCG is the most friendly default
>> behaviour.
>
> Friendly perhaps, generating an infinite series of questions "why is my
> guest slow as molasses?" certainly.
With a warning about
On Tue, Oct 02, 2012 at 09:46:12AM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
> > On Mon, Oct 01, 2012 at 06:43:00PM +0200, Andreas Färber wrote:
> >> Hello Jan,
> >>
> >> Am 01.10.2012 16:34, schrieb Jan Kiszka:
> >> > If we built a target for a host that supports KVM in p
"Daniel P. Berrange" writes:
> On Mon, Oct 01, 2012 at 06:43:00PM +0200, Andreas Färber wrote:
>> Hello Jan,
>>
>> Am 01.10.2012 16:34, schrieb Jan Kiszka:
>> > If we built a target for a host that supports KVM in principle, set the
>> > default accelerator to KVM as well. This also means the st
Paolo Bonzini writes:
>> But libguest can set it's accelerator option to whatever it wants.
>>
>> If your running QEMU under a VM, it's pretty reasonable to have to
>> use a special option IMHO.
>
> It's also reasonable to have consecutive releases change defaults in
> a more "friendly" way (i.e
> But libguest can set it's accelerator option to whatever it wants.
>
> If your running QEMU under a VM, it's pretty reasonable to have to
> use a special option IMHO.
It's also reasonable to have consecutive releases change defaults in
a more "friendly" way (i.e. from tcg to kvm:tcg), especial
"Daniel P. Berrange" writes:
> On Mon, Oct 01, 2012 at 06:43:00PM +0200, Andreas Färber wrote:
>> Hello Jan,
>>
>> Am 01.10.2012 16:34, schrieb Jan Kiszka:
>> > If we built a target for a host that supports KVM in principle, set the
>> > default accelerator to KVM as well. This also means the st
On Mon, Oct 01, 2012 at 11:20:41AM -0500, Anthony Liguori wrote:
> Jan Kiszka writes:
>
> > If we built a target for a host that supports KVM in principle, set the
> > default accelerator to KVM as well. This also means the start of QEMU
> > will fail to start if KVM support turns out to be unava
On Mon, Oct 01, 2012 at 06:43:00PM +0200, Andreas Färber wrote:
> Hello Jan,
>
> Am 01.10.2012 16:34, schrieb Jan Kiszka:
> > If we built a target for a host that supports KVM in principle, set the
> > default accelerator to KVM as well. This also means the start of QEMU
> > will fail to start if
Hello Jan,
Am 01.10.2012 16:34, schrieb Jan Kiszka:
> If we built a target for a host that supports KVM in principle, set the
> default accelerator to KVM as well. This also means the start of QEMU
> will fail to start if KVM support turns out to be unavailable at
> runtime.
>From a distro point
Jan Kiszka writes:
> If we built a target for a host that supports KVM in principle, set the
> default accelerator to KVM as well. This also means the start of QEMU
> will fail to start if KVM support turns out to be unavailable at
> runtime.
>
> Signed-off-by: Jan Kiszka
> ---
> kvm-all.c |
If we built a target for a host that supports KVM in principle, set the
default accelerator to KVM as well. This also means the start of QEMU
will fail to start if KVM support turns out to be unavailable at
runtime.
Signed-off-by: Jan Kiszka
---
kvm-all.c |1 +
kvm-stub.c |1 +
kvm.h
21 matches
Mail list logo
