Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1874761yba; Thu, 25 Apr 2019 07:08:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqxOl3rOGQBA+V1Sk/8ymkekKiONspzepGxpO2+q8QkNSAJGe+/gpiy0rkj6zuEJtHODNcEB X-Received: by 2002:a63:dd10:: with SMTP id t16mr37618767pgg.446.1556201296461; Thu, 25 Apr 2019 07:08:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556201296; cv=none; d=google.com; s=arc-20160816; b=nAOwSvJiROtqx/ccMVlHPFRJimzH14GhvwasN4ppVumW5Am8rLjIJdBdIWdDOMYx2u /clKxO8E2bj1BFMdk9yYYSdADUtcLfkQ00uJH/y4YCVXYryiWFUBf8gE0BptGeJPSOtX LeejTrahR9EfmCLgjzm7YiZBqZEjjHAIGxcd1M47cmF3MA0fvMJCIwa0CYTXXlVRJUAL Q5eiTQMvLihRZyU/vp2l8oD1RfvQ3i3RBS0byZ6W3Xm7eGrq9N5JZTFTi96opM/GsNR+ 9ry0VpebXAQrOJWlqu0L9MnmCaVT5nut5PTymXOc4g3r80Ysh9cMm4/4CDlJMzmZlfHG +D1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:subject:from; bh=VJvkBIPxoxWCoRLishQYcyC98qqwYMkgam3KV2tZBvw=; b=mTWgcDbXRe43gaukAk8yTUn/6fAtBDWsCy88PuKP48a1FuRX/ICZqohNVRpsuDLQGZ 5WOkgNKQbtu2WQ534bGpRTbcyiUePg9ZLUEi3OTZRgx/9CgPmXlmP70khWspElONUWcX Ie1rujhvji9rp5zjJnorS0WsDWo5BN9PABr1Dk9ynAd7gIzqxLTFjA4bhvT8wrZJWHag QjNjqx5Z0lyXKqEXU6Hze76J55JwYpHfFqhS0Rr2xVMaCJ/39bB7mOvGZXCRXnywOJOh xeLMfQPKhxJxPco1Zlybco2puy8BsMF30pEWvyVobSWALmxEB00186rbXZCmAzV9vWqD uezA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z4si21728150plk.385.2019.04.25.07.08.00; Thu, 25 Apr 2019 07:08:16 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387953AbfDYMot (ORCPT + 99 others); Thu, 25 Apr 2019 08:44:49 -0400 Received: from mga01.intel.com ([192.55.52.88]:35426 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387943AbfDYMor (ORCPT ); Thu, 25 Apr 2019 08:44:47 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2019 05:44:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,393,1549958400"; d="scan'208";a="340714255" Received: from genxtest-ykzhao.sh.intel.com (HELO [10.239.143.71]) ([10.239.143.71]) by fmsmga006.fm.intel.com with ESMTP; 25 Apr 2019 05:44:46 -0700 From: "Zhao, Yakui" Subject: Re: [RFC PATCH v5 3/4] x86/acrn: Use HYPERVISOR_CALLBACK_VECTOR for ACRN guest upcall vector To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de, bp@alien8.de, Jason Chen CJ References: <1556067260-9128-1-git-send-email-yakui.zhao@intel.com> <1556067260-9128-4-git-send-email-yakui.zhao@intel.com> <20190425071700.GB57256@gmail.com> Message-ID: Date: Thu, 25 Apr 2019 20:42:17 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20190425071700.GB57256@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019年04月25日 15:17, Ingo Molnar wrote: > > * Zhao Yakui wrote: > >> Linux kernel uses the HYPERVISOR_CALLBACK_VECTOR for hypervisor upcall >> vector. And it is already used for Xen and HyperV. > > English sentences should not be started with 'and'. OK. I will remove it. > >> After ACRN hypervisor is detected, it will also use this defined vector >> to notify ACRN guest. > > Missing 'the', twice. OK. It will be added. > >> +/* SPDX-License-Identifier: GPL-2.0 */ >> +#ifndef _ASM_X86_ACRN_H >> +#define _ASM_X86_ACRN_H >> + >> +void acrn_hv_callback_vector(void); > > Please mark these with 'extern', as customary in x86 headers. OK. The "extern" will be added. > >> >> +#include >> +#include >> +#include >> #include >> +#include >> >> static uint32_t __init acrn_detect(void) >> { >> @@ -18,6 +22,8 @@ static uint32_t __init acrn_detect(void) >> >> static void __init acrn_init_platform(void) >> { >> + alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR, >> + acrn_hv_callback_vector); > > Why is this on two lines, not a single line? At first it used the long function name for acrn_hv_callback_vector. As it exceeds 80 columns, it is split into two lines. I will check it and see whether it can be fit into one single line. If it is ok, it will be in one single line. > >> +static void (*acrn_intr_handler)(void); >> + >> +__visible void __irq_entry acrn_hv_vector_handler(struct pt_regs *regs) >> +{ >> + struct pt_regs *old_regs = set_irq_regs(regs); >> + >> + entering_ack_irq(); > > Does the hypervisor model the APIC EOI command, i.e. does it require the > APIC to be acked? I.e. would not acking the APIC create an IRQ storm? The hypervisor requires that the APIC EOI should be acked. If the EOI APIC is not acked, the APIC ISR bit for the HYPERVISOR_CALLBACK_VECTOR will not be cleared and then it will block the interrupt whose vector is lower than HYPERVISOR_CALLBACK_VECTOR. > >> + inc_irq_stat(irq_hv_callback_count); >> + >> + if (acrn_intr_handler) >> + acrn_intr_handler(); > > Nothing appears to be setting acrn_intr_handler, so this will never > execute anything? Is more code relying on this? Nothing will be done in this patch. Later the driver part code will be added and it needs to add/remove the corresponding driver handler. It is similar to vmbus_handler in hyperv_vector_handler. > > Thanks, > > Ingo >