Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2191332imm; Fri, 7 Sep 2018 12:13:45 -0700 (PDT) X-Google-Smtp-Source: ANB0VdasHgvpGRlm3Dl2ZV30YscLnOmmC4+vaTJ2AXnF2M5i9+FefL2MIt98pd71DvlNqzhgr7g4 X-Received: by 2002:a65:52cc:: with SMTP id z12-v6mr9771846pgp.69.1536347625529; Fri, 07 Sep 2018 12:13:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536347625; cv=none; d=google.com; s=arc-20160816; b=PeIEIXthoTDueCmC/fN4bZ7UQUDX1avG4GoosfrKgTbnCL9J07eBm4LhU0o/Oc2aqe 921IXR3gYNOi86/hVApBpfDvakEZPJHcirih6Eno2gWjCgbYrMfFR81BoYp9UfKN57e6 eHMQ9knrt9W2JAPmjbl6fxRJRPn5eHbcE1IvNsjLVH09bgv5Ci/vEMduZNR7rFGvCzIL luYjukbN+qlYsOkaQmGC5lkn1OpqmFlvpR0/SUkSbWsFcWzMhPkPETTyvRr0PDEbCIm0 vPklSpRv9N9pzG0v4SJXn+qGHTFOA170sSvR6vXjfYhsiKrR+lk1Iahf8C0bpLl12L3r iWxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=2YPBmvW9OgJx/kHrtYZKGRxU3CldnzaiA+sYaL9m4Ck=; b=eqPCxe3tFcCn9lJVFTlEVbtrAaMu09Y3GyKBKlSv8ZgwGGtLvV9Hxw7NfS1f5WjsJp jecOKJWGJa0BvmyMdZhTgtqcIRN1ZJLVYSLU0xg/A6LkT0LBtZV+xSqVES31SxsyQH0S ZqTVMvLtQpUI1eZqRtbQIrGJOtzMjCjPFD5iHGweM5SafE5P3MMmjytlZn6VS/Q6/FTI I9LNbgC0mj/snKT2e/p70eeT0+YvC584vwIhH/zREA00uGoIklQUQeIOxPky3xlfA61C qfe8UQyjtSqZDxL5hIYUCt1aTz/nOZKMF65xHQZRBTrwrsTrbJ/Nix60Ld6cMQiJbhFW lung== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c17-v6si8462970pgp.299.2018.09.07.12.13.29; Fri, 07 Sep 2018 12:13:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726125AbeIGXyU (ORCPT + 99 others); Fri, 7 Sep 2018 19:54:20 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:36912 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725963AbeIGXyU (ORCPT ); Fri, 7 Sep 2018 19:54:20 -0400 Received: from p4fea45ac.dip0.t-ipconnect.de ([79.234.69.172] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fyMAh-0008Um-CY; Fri, 07 Sep 2018 21:11:59 +0200 Date: Fri, 7 Sep 2018 21:11:58 +0200 (CEST) From: Thomas Gleixner To: Philipp Eppelt cc: linux-kernel@vger.kernel.org Subject: Re: x86/apic: MSI address malformed for "flat" driver In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 6 Sep 2018, Philipp Eppelt wrote: > > The "flat" driver defines the MSI addressing scheme to be used as > logical addressing in flat mode. The MSI msg address is composed > accordingly, but sets MSI_ADDR_REDIRECTION_CPU which is a zero at bit[3]. Correct. That's what it means: * When RH is 0, the interrupt is directed to the processor listed in the Destination ID field. So for DM: * If RH is 0, then the DM bit is ignored and the message is sent ahead independent of whether the physical or logical destination mode is used. which is means that the delivery does not do any magic redirections, because the Redirection Hint is off. If RH is set, then the delivery can redirect according to the rules in the DM section. We are not using that because we want targeted single CPU delivery. The interpretation of the DID field is purely depending on the local APIC itself by matching the APIC ID against the DID field. And the local APIC ID of CPU0 is 1 << 0, i.e. 0x1 which matches the MSI message you see. > Currently, irq_msi_compose_msg composes for the "flat" driver an address > like 0xfee0'1004 for a 64-bit single-core system without IO-APIC and MSI > remapping and no ACPI (a virtual system). The DM field is irrelevant if RH is 0. If RH is one and DM is 1 then you can do group stuff and other magic, but we don't use that for 'external' interrupts. Where it _is_ used though is in the IPI delivery so that IPIs to multiple CPUs require only a single APIC write, while with physical mode it's necessary to write a single message to each CPU. Hope that helps. Thanks, tglx