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: Thu, 19 Mar 2015 16:51:53 -0600 Message-ID: <550B5309.1090805@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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org, gleb@kernel.org, pbonzini@redhat.com To: =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Marcelo Tosatti Return-path: Received: from mail-pa0-f42.google.com ([209.85.220.42]:35631 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753412AbbCSWyG (ORCPT ); Thu, 19 Mar 2015 18:54:06 -0400 Received: by pabyw6 with SMTP id yw6so88976446pab.2 for ; Thu, 19 Mar 2015 15:54:05 -0700 (PDT) In-Reply-To: <20150319130015.GA16070@potion.brq.redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/19/2015 07:00 AM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > 2015-03-18 22:09-0300, Marcelo Tosatti: >>>> See native_compose_msi_msg: >>>> ((apic->irq_dest_mode =3D=3D 0) ? >>>> MSI_ADDR_DEST_MODE_PHYSICAL : >>>> MSI_ADDR_DEST_MODE_LOGICAL) | >>>> ((apic->irq_delivery_mode !=3D dest_LowestPrio) ? >>>> MSI_ADDR_REDIRECTION_CPU : >>>> MSI_ADDR_REDIRECTION_LOWPRI) | >>>> So it does configure DM =3D MSI_ADDR_DEST_MODE_LOGICAL >>>> and RH =3D MSI_ADDR_REDIRECTION_LOWPRI. >>> ...and yet this is a good counterexample against my argument :) >=20 > (It could be just to make the code nicer ... the developer might have > known how real hardware will handle it.) >=20 >>> What I think I'll do is revert this particular change so that dest_= mode is >>> set independently of RH. While I'm not entirely convinced that this= is the >>> intended interpretation, I do think that consistency with the exist= ing logic >>> is probably desirable for the time being. If I can get closure on t= he matter >>> I'll re-submit that change, but for the time being I will undo it. >> Just write MSI-X table entries on real hardware (say: modify >> native_compose_msi_msg or MSI-X equivalent), with all RH/DM >> combinations, and see what behaviour is >> comes up? =20 >=20 > I second this idea. > (We'd also get to know how RH interacts with delivery mode.) >=20 I played around with native_compose_msi_msg and discovered the followin= g: * 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 So it seems to be the case that logical destination mode is used whenev= er 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 in https://software.intel.com/en-us/forums/topic/288883 : "...X86 supports logical mode but does not support redirection of physi= cal mode interrupts. I think they should have just said RH=3D1 is not defined in= physical mode, but instead they are trying to tell you what the restrictions are= if you set it on." The default config for PCI devices seems to be DM=3D1,RH=3D1. -James