Re: [Qemu-devel] [patch 2/6] Use machine options to emulate -no-kvm-irqchip

[Anthony Liguori]

Marcelo Tosatti <address@hidden> writes:

> On Thu, Oct 04, 2012 at 04:30:26PM +0200, Jan Kiszka wrote:
>> On 2012-10-04 16:21, Anthony Liguori wrote:
>> > -no-kvm should be included too.
>> 
>> Reminds me that we still need to agree on the final default accel strategy.
>
> Default accel=kvm for x86_64 targets, no fallback.

Ack.

BTW, if you want to override this, you can just do:

[machine]
accel=kvm:tcg

In /etc/qemu/target-i386.conf

So the distros can do whatever they like in their packages.

We should instruct users how to do this in an error message too in case
they want to permanently disable kvm because they don't have appropriate
hardware suport.

Regards,

Anthony Liguori

> Markus's argument is pretty convincing to me:
>
> "Friendly perhaps, generating an infinite series of questions "why is my
> guest slow as molasses?" certainly.
>
> And for each instance of the question, there's an unknown number of
> users who give QEMU a quick try, screw up KVM unknowingly, observe the
> glacial speed, and conclude it's crap."
>
>> > I just ran across a user that was injecting '-no-kvm-irqchip' in their
>> > libvirt XML via a custom attribute.  It turned out it was to work around
>> > broken MSI support in their funky guest they were running.  It was the
>> > wrong solution to the problem but they were doing it regardless.
>> > 
>> > The point is, there are users in the wild using these options.  There's
>> > no reason to remove them if they are trivial to maintain (and they are
>> > in their current form).
>> 
>> So let's define a consistent policy for them all:
>>  - warn on the command line on use
>>  - avoid adding them to the help or other user documentation
>>  - keep them until we rework the whole command line
>> 
>> Jan
>> 
>> -- 
>> Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
>> Corporate Competence Center Embedded Linux
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to address@hidden
> More majordomo info at  http://vger.kernel.org/majordomo-info.html