Received: by 10.213.65.68 with SMTP id h4csp1235530imn; Wed, 4 Apr 2018 15:19:08 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/c0UmtgmRQW8Kn+PeJi7e/p9XvgEF0Mb3eBTwFFgxJGfLqOaxok7LWDVA718glM44pOjiq X-Received: by 10.98.62.71 with SMTP id l68mr14918352pfa.98.1522880348148; Wed, 04 Apr 2018 15:19:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522880348; cv=none; d=google.com; s=arc-20160816; b=CQwKjk1FYcoql8M/NWnjoy3uNPR9VM9u0SiP9R60bIkwFLSIJJn127jB6ix3h/cy85 /oLO5BakW5uYuxcFQV/cesUdwaz2bwEt0ew1CdY1hVwek8q+Q+PQAFLdbtLUH36KGQ7H yyvGNeHutHVYueiuZ3uhszkCQa/1unC0QMpJfTNpYftgKfVikgJy2HBobnnRgISVDRhh 8PGKsWTYco6Xo67WqGjSetkdjxYtEjPk6TQ1zvmdgPyryrc6iReXDq0IZWf2S/upKiQz AFhISoXoHP+/lLcvEA+DKqQhElyb2EDDbSVLDC+s0uTaBir/ScSK6eSvv9QB3+DF2e45 Aq1w== 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 :arc-authentication-results; bh=RJUKkvBdshNh+7HNcvSDGQnYzffj0NPPaI8hCS45hnA=; b=ATQ58C+nDoQrX9e/Ik1DbI0wEsKGo5nTrlA8r9tBqvSGRsrbDM+qVm57+4PC4F9aKB 3EEqi/kmHmVzX5Cr1MwM3O1Zr36ZSvYa3GyX3T+mdmUhoMjbgAkCNt3W8sy0qjRMKACA y91QDDCsHJvOVtBv8+7iMy+o5HsL6GtkdySV+71UTmSQGv/zh7C/REf5cT/TDHAbh9nE X5Zhaza7ok7OFsryterMhA9GSSD6RIBmyWRSMQR5xJCAvalhLIjprlufI+NW5zZWsOrC ixS0hUMb65farVJqovgJywo9ZULiw0EjW0DMpXh0XCW5lArV5EHq20Zg7IwSm8NDzHVZ UZng== 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 q26si4346589pgd.280.2018.04.04.15.18.51; Wed, 04 Apr 2018 15:19:08 -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 S1752292AbeDDWRm (ORCPT + 99 others); Wed, 4 Apr 2018 18:17:42 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:35482 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751749AbeDDWRl (ORCPT ); Wed, 4 Apr 2018 18:17:41 -0400 Received: from p4fea5f09.dip0.t-ipconnect.de ([79.234.95.9] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1f3qip-0002iX-Hn; Thu, 05 Apr 2018 00:17:39 +0200 Date: Thu, 5 Apr 2018 00:17:39 +0200 (CEST) From: Thomas Gleixner To: Dexuan Cui cc: 'Greg KH' , "Michael Kelley (EOSG)" , "linux-kernel@vger.kernel.org" , KY Srinivasan , Stephen Hemminger , Vitaly Kuznetsov Subject: Re: Any standard kernel API to dynamically allocate/free per-cpu vectors on x86? 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 Dexuan, On Wed, 4 Apr 2018, Dexuan Cui wrote: > Hi, > Recently, two Hyper-V specific vectors were introduced in > arch/x86/include/asm/irq_vectors.h: > > #if IS_ENABLED(CONFIG_HYPERV) > #define HYPERV_REENLIGHTENMENT_VECTOR 0xee > #define HYPERV_STIMER0_VECTOR 0xed > #endif > > What if we need more such vectors on Hyper-V? This static global reservation > mechanism doesn't scale, IMO. > > Actually I believe we don't really need to reserve the same vector on all CPUs, > because the model-specific registers (MSRs) defined for Hyper-V synthetic > interrupt controller (SynIC) are per-cpu, meaning each virtual processor has > its own copy of these registers, so they can be programmed independently. > > That is to say, we can use different vectors for the same Synthetic Interrupt, > as long as we're able to dynamically get a per-cpu vector for each CPU. > > I'm wondering if there is such a standard kernel API on x86. > As I skimmed through the code, I haven't found it yet, if any. > > PS, the background of my question is that: in the future Hyper-V will > support multiple VMBus drivers running simultaneously in one virtual > machine, and I think it would be better for the future secondary VMBus > driver to use a different synthetic interrupt, which I hope can be > configured with dynamic vectors rather than a new static globally-reserved > vector. We don't have a simple way to do such allocations because they involve IDT entry manipulation. If there is no hard requirement that this stuff runs through an direct vector, then we could simply make these interrupts go through the normal interrupt path. That means you have to request them like regular device interrupts and the handling path is slightly longer than the direct vector mode. You'd get virtual interrupt numbers per cpu which also show up in /proc/interrupts as separate lines. That needs a very simple and minimal virtual interrupt controller driver which is mostly a dummy implementation except for the activation function which would allow you to retrieve the vector number and store it in the MSR. There are a few details to be hashed out vs. CPU hotplug, but we have all the infrastructure in place to deal with that. Hmm? Thanks, tglx