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: Mon, 23 Mar 2015 16:46:07 -0600 Message-ID: <551097AF.4000303@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> <550C5DD7.5050306@gmail.com> <20150323211331.GA21710@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-pa0-f46.google.com ([209.85.220.46]:35739 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752214AbbCWWsV (ORCPT ); Mon, 23 Mar 2015 18:48:21 -0400 Received: by pagv19 with SMTP id v19so30279450pag.2 for ; Mon, 23 Mar 2015 15:48:20 -0700 (PDT) In-Reply-To: <20150323211331.GA21710@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/23/2015 03:13 PM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 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?) >>>> >>> >>> This was on Intel x86_64 (Core i5-3210m, 'Ivy Bridge'). >=20 > 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= =2E) >=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 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? >> >> I haven't seen any changes in the MSI Data Register for any values o= f RH, >> but I don't have a great sample size (one machine with one set of PC= I devices), >> so if anyone else can confirm that I would appreciate it. >=20 > I meant if the delivery mode from data register isn't ignored with RH= =3D1, > and the message delivered as if lowest-priority was set there. > (Decided by having something else than fixed or lowest-priority there= =2E) >=20 Hmm, any thoughts on how I could test for that? >> 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 cas= e that the RH >> bit's only purpose is for lowprio delivery on x86. >=20 > Yeah, afaik, it can be done with lowest priority delivery mode on ia6= 4 > too, so I have a hard time finding RH's intended purpose. >=20 >> Again, need to ha= ve some more >> PCI devices to test against to confirm anything. >=20 > It's impossible to test everything, and there is no conflict if we ha= ve > at most one data point ;) >=20 Very true :)