From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
Igor Mammedov <imammedo@redhat.com>,
Richard Henderson <rth@twiddle.net>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 7/7] intel-iommu: keep buggy EIM enabled in 2.7 machine type
Date: Thu, 29 Sep 2016 18:49:45 +0200 [thread overview]
Message-ID: <20160929164944.GB12788@potion> (raw)
In-Reply-To: <20160929150119.GS3877@thinpad.lan.raisama.net>
2016-09-29 15:19+0200, Paolo Bonzini:
> On 29/09/2016 13:23, Radim Krčmář wrote:
>> QEMU 2.7 allowed EIM even in configurations that were forbidden in the
>> last patch because they were not working, like old KVM or userspace
>> APIC. In order to keep backward compatibility, we again allow guests to
>> misbehave in non-obvious ways, and make it the default.
>>
>> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
>
> Ugh, I misremembered that VTD_ECAP_EIM was not set in 2.7. :( Perhaps
> it's better to drop this patch...
I think that adding this backward compatibility hack into code that is
supposed to be developed is not a good idea.
2016-09-29 12:01-0300, Eduardo Habkost:
> If you break compatibility and fix it in separate patches, you
> break bisectability (even for people that are bisecting bugs
> unrelated to EIM).
I'd keep it as a separate patch and let maintainers decide whether they
want to squish or drop it.
> (But I still don't understand if patch 6/7 really breaks
> anything, or not.)
Nothing useful.
It "breaks" three cases:
1) If user configured
-machine kernel_irqchip=off -device intel_iommu,intremap=on
QEMU 2.7 pc-q35-2.7 enabled (broken) EIM, but 2.8 wouldn't, leading
to a different machine.
(The same with new KVM and split irqchip.)
2) If user had old KVM and configured
-machine kernel_irqchip=split -device intel_iommu,intremap=on
QEMU 2.7 pc-q35-2.7 enabled (broken) EIM, but after offline migration
to 2.8, QEMU would refuse to start.
3) If user started a pc-q35-2.7 with QEMU 2.8 on a new KVM, then they
could use cluster x2APIC without a problem, but the guest wouldn't
work after offline migration to QEMU 2.7 (I'm not sure if this case
is supported).
Luckily, the intel-iommu device doesn't support live migration. :)
next prev parent reply other threads:[~2016-09-29 16:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-29 11:23 [Qemu-devel] [PATCH v2 0/7] intel_iommu: fix EIM Radim Krčmář
2016-09-29 11:23 ` [Qemu-devel] [PATCH v2 1/7] apic: add global apic_get_class() Radim Krčmář
2016-09-29 14:53 ` Eduardo Habkost
2016-09-29 15:58 ` Radim Krčmář
2016-09-29 11:23 ` [Qemu-devel] [PATCH v2 2/7] apic: add send_msi() to APICCommonClass Radim Krčmář
2016-09-29 11:23 ` [Qemu-devel] [PATCH v2 3/7] intel_iommu: pass whole remapped addresses to apic Radim Krčmář
2016-09-29 11:23 ` [Qemu-devel] [PATCH v2 4/7] intel-iommu: exit on invalid configuraton earlier Radim Krčmář
2016-09-29 11:23 ` [Qemu-devel] [PATCH v2 5/7] intel-iommu: add OnOffAuto intr_eim as "eim" property Radim Krčmář
2016-09-30 5:13 ` Peter Xu
2016-09-30 13:50 ` Radim Krčmář
2016-09-29 11:23 ` [Qemu-devel] [PATCH v2 6/7] intel_iommu: reject broken EIM Radim Krčmář
2016-09-29 13:18 ` Paolo Bonzini
2016-09-29 16:06 ` Igor Mammedov
2016-09-29 16:56 ` Radim Krčmář
2016-09-29 16:56 ` Paolo Bonzini
2016-09-29 15:53 ` Igor Mammedov
2016-09-29 11:23 ` [Qemu-devel] [PATCH v2 7/7] intel-iommu: keep buggy EIM enabled in 2.7 machine type Radim Krčmář
2016-09-29 13:19 ` Paolo Bonzini
2016-09-29 15:01 ` Eduardo Habkost
2016-09-29 16:49 ` Radim Krčmář [this message]
2016-09-30 5:40 ` Peter Xu
2016-09-30 13:55 ` Radim Krčmář
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160929164944.GB12788@potion \
--to=rkrcmar@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.