From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Sullivan Subject: Re: [Patch v5] x86: irq_comm: Add check for RH bit in kvm_set_msi_irq Date: Fri, 20 Mar 2015 11:50:15 -0600 Message-ID: <550C5DD7.5050306@gmail.com> References: <5502FEDB.3030606@gmail.com> <20150318225225.GA8702@amt.cnet> <550A1F6A.6030602@gmail.com> <20150319010932.GA18338@amt.cnet> <20150319130015.GA16070@potion.brq.redhat.com> <550B5309.1090805@gmail.com> <20150320151534.GB14772@potion.brq.redhat.com> <550C3B23.30401@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Marcelo Tosatti , kvm@vger.kernel.org, gleb@kernel.org, pbonzini@redhat.com To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Return-path: Received: from mail-pd0-f175.google.com ([209.85.192.175]:36583 "EHLO mail-pd0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751362AbbCTRw2 (ORCPT ); Fri, 20 Mar 2015 13:52:28 -0400 Received: by pdbcz9 with SMTP id cz9so114921869pdb.3 for ; Fri, 20 Mar 2015 10:52:28 -0700 (PDT) In-Reply-To: <550C3B23.30401@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/20/2015 09:22 AM, James Sullivan wrote: > On 03/20/2015 09:15 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> 2015-03-19 16:51-0600, James Sullivan: >>> I played around with native_compose_msi_msg and discovered the foll= owing: >>> >>> * dm=3D0, rh=3D0 =3D> Physical Destination Mode >>> * dm=3D0, rh=3D1 =3D> Failed delivery >>> * dm=3D1, rh=3D0 =3D> Logical Destination Mode, No Redirection >>> * dm=3D1, rh=3D1 =3D> Logical Destination Mode, Redirection >> >> Great! (What CPU family was that?) >> >=20 > This was on Intel x86_64 (Core i5-3210m, 'Ivy Bridge'). >=20 >>> So it seems to be the case that logical destination mode is used wh= enever >>> DM=3D1, regardless of RH. Furthermore, the case where DM=3D0 and RH= =3D1 is >>> undefined, as was indicated in the closing response to the thread i= n >>> https://software.intel.com/en-us/forums/topic/288883 : >> >> DM=3D0+RH=3D1 might be defined to "fail", but I think it's acceptabl= e to >> treat it as undefined. (Deliver them in KVM if it improves somethin= g.) >> >=20 > My thoughts as well. >=20 >> I'm still wondering about last sentence from that link, the >> parenthesised part to be exact, >> The reference to the APIC ID being 0xff is because 0xff is broadca= st >> and lowest priority (what the RH bit really is for X86) is illegal >> with broadcast. >> >> Can you also check if RH=3D1 does something to delivery mode? >> >> Thanks. >> >=20 > Sure, I'll look into that as well. >=20 > -James >=20 I haven't seen any changes in the MSI Data Register for any values of R= H, but I don't have a great sample size (one machine with one set of PCI d= evices), so if anyone else can confirm that I would appreciate it. Worth noting that low prio delivery was used across the board for my PC= I devices regardless of RH=3D1 or 0, so it doesn't seem to be de facto the case t= hat the RH bit's only purpose is for lowprio delivery on x86. Again, need to have = some more PCI devices to test against to confirm anything. -James