From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [Patch v5] x86: irq_comm: Add check for RH bit in kvm_set_msi_irq Date: Mon, 23 Mar 2015 22:13:31 +0100 Message-ID: <20150323211331.GA21710@potion.brq.redhat.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> <550C5DD7.5050306@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: James Sullivan Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45703 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752772AbbCWVNf (ORCPT ); Mon, 23 Mar 2015 17:13:35 -0400 Content-Disposition: inline In-Reply-To: <550C5DD7.5050306@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: 2015-03-20 11:50-0600, James Sullivan: > 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 fo= llowing: > >>> > >>> * 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'). Thanks, it's possible that the behavior of chipsets changed since the report on Intel's forum ... (Lowest priority behaved differently before QPI, so it might coincide.) > >> 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 broad= cast > >> and lowest priority (what the RH bit really is for X86) is illeg= al > >> with broadcast. > >> > >> Can you also check if RH=3D1 does something to delivery mode? >=20 > I haven't seen any changes in the MSI Data Register for any values of= RH, > but I don't have a great sample size (one machine with one set of PCI= devices), > so if anyone else can confirm that I would appreciate it. I meant if the delivery mode from data register isn't ignored with RH=3D= 1, and the message delivered as if lowest-priority was set there. (Decided by having something else than fixed or lowest-priority there.) > Worth noting that low prio delivery was used across the board for my = PCI devices > regardless of RH=3D1 or 0, so it doesn't seem to be de facto the case= that the RH > bit's only purpose is for lowprio delivery on x86. Yeah, afaik, it can be done with lowest priority delivery mode on ia64 too, so I have a hard time finding RH's intended purpose. > Again, need to hav= e some more > PCI devices to test against to confirm anything. It's impossible to test everything, and there is no conflict if we have at most one data point ;)