From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYDID-0002Pr-0i for qemu-devel@nongnu.org; Fri, 12 Aug 2016 10:19:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bYDHl-0007hR-Fd for qemu-devel@nongnu.org; Fri, 12 Aug 2016 10:18:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57030) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bYDHl-0007gF-9D for qemu-devel@nongnu.org; Fri, 12 Aug 2016 10:18:09 -0400 Date: Fri, 12 Aug 2016 17:29:18 +0800 From: Peter Xu Message-ID: <20160812092918.GY4793@pxdev.xzpeter.org> References: <1470922183-22873-1-git-send-email-peterx@redhat.com> <20160811154416.GC10637@potion> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160811154416.GC10637@potion> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] intel_iommu: add "eim" property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Radim =?utf-8?B?S3LEjW3DocWZ?= Cc: qemu-devel@nongnu.org, ehabkost@redhat.com, mst@redhat.com, jan.kiszka@web.de, pbonzini@redhat.com, imammedo@redhat.com, davidkiarie4@gmail.com, rth@twiddle.net On Thu, Aug 11, 2016 at 05:44:16PM +0200, Radim Kr=C4=8Dm=C3=A1=C5=99 wro= te: > 2016-08-11 21:29+0800, Peter Xu: > > Adding one extra property for intel-iommu device to decide whether we > > should support EIM bit for IR. > >=20 > > Now we are throwing high 24 bits of dest_id away directly. This will > > cause interrupt issues with guests that: > >=20 > > - enabled x2apic with cluster mode > > - have more than 16 vcpus (so will have more than 1 cluster) >=20 > Good catch, it is a problem starting at 9 VCPUs, because that one is > already "0x100" and we truncate to 8 bits ... Ah yes. I muddled on the bits. :) >=20 > > Let's make xapic the default one, and for the brave people who would > > like to try EIM and know the side effects, we can do it by explicitly > > enabling EIM using: >=20 > This might bite us: users cannot easily tell when EIM is sane, so eim=3D= on > is going to be a hazard even after some KVM/QEMU has it fixed. > I'd make make eim=3Don fail when logical x2APIC is broken. >=20 > Right now, we can allow eim=3Don if maximal APIC ID < 8, because physic= al > 0xffffffff gets truncated to 0xff and is still interpreted as a > broadcast thanks to the quirk. > Logical 0xff gets misinterpreted as a broadcast, but it would address > all APICs anyway and KVM's lowest-priority works for broadcast too, so > it is fine to do so. Not very wise, though. :) >=20 > > -device intel-iommu,intremap=3Don,eim=3Don > >=20 > > Even after we have x2apic support, it'll still be good if we can prov= ide > > a way to switch xapic/x2apic from QEMU side for e.g. debugging purpos= e, > > which is an alternative for tuning guest kernel boot parameters. > >=20 > > We can switch the default to "on" after x2apic fully supported. > >=20 > > Signed-off-by: Peter Xu > > --- > > This will have small conflict with Radim's patches to selectively > > enable EIM. I can do a rebase when needed. >=20 > This patch made me realize that broadcast quirk is not enough, so I'll > do v2 on top of this. I'll post v2 soon with DEFINE_PROP_BOOL. Thanks, -- peterx