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 09:22:11 -0600 Message-ID: <550C3B23.30401@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> 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-ig0-f177.google.com ([209.85.213.177]:37031 "EHLO mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751687AbbCTPY3 (ORCPT ); Fri, 20 Mar 2015 11:24:29 -0400 Received: by igcqo1 with SMTP id qo1so20999969igc.0 for ; Fri, 20 Mar 2015 08:24:29 -0700 (PDT) In-Reply-To: <20150320151534.GB14772@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 follo= wing: >> >> * 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 >=20 > Great! (What CPU family was that?) >=20 This was on Intel x86_64 (Core i5-3210m, 'Ivy Bridge'). >> So it seems to be the case that logical destination mode is used whe= never >> DM=3D1, regardless of RH. Furthermore, the case where DM=3D0 and RH=3D= 1 is >> undefined, as was indicated in the closing response to the thread in >> https://software.intel.com/en-us/forums/topic/288883 : >=20 > DM=3D0+RH=3D1 might be defined to "fail", but I think it's acceptable= to > treat it as undefined. (Deliver them in KVM if it improves something= =2E) >=20 My thoughts as well. > 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 broadcas= t > and lowest priority (what the RH bit really is for X86) is illegal > with broadcast. >=20 > Can you also check if RH=3D1 does something to delivery mode? >=20 > Thanks. >=20 Sure, I'll look into that as well. -James