On Thu, Aug 11, 2016 at 05:44:16PM +0200, Radim Krčmář wrote: > 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. > > > > Now we are throwing high 24 bits of dest_id away directly. This will > > cause interrupt issues with guests that: > > > > - enabled x2apic with cluster mode > > - have more than 16 vcpus (so will have more than 1 cluster) > > 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. :) > > > 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: > > This might bite us: users cannot easily tell when EIM is sane, so eim=on > is going to be a hazard even after some KVM/QEMU has it fixed. > I'd make make eim=on fail when logical x2APIC is broken. > > Right now, we can allow eim=on if maximal APIC ID < 8, because physical > 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. :) > > > -device intel-iommu,intremap=on,eim=on > > > > Even after we have x2apic support, it'll still be good if we can provide > > a way to switch xapic/x2apic from QEMU side for e.g. debugging purpose, > > which is an alternative for tuning guest kernel boot parameters. > > > > We can switch the default to "on" after x2apic fully supported. > > > > Signed-off-by: Peter Xu <pet...@redhat.com> > > --- > > This will have small conflict with Radim's patches to selectively > > enable EIM. I can do a rebase when needed. > > 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
