Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2115048ybl; Sun, 18 Aug 2019 18:52:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqySqjZ35Lf5Sf3DcEx3YTMiMb5+J+vNum/53e1UuXUIGOjtgkAiGu/rHHnzvjLF1nfjtOSQ X-Received: by 2002:a17:902:8649:: with SMTP id y9mr18772274plt.252.1566179556795; Sun, 18 Aug 2019 18:52:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566179556; cv=none; d=google.com; s=arc-20160816; b=LAKmQnqs0StzKR3SMTd676PpGT44NfcBvswi1Bu4OpCaPXFjNZAY2+NW9lr9nbZW0D GciUjA/lGP3GQLNPYBsjdDhjryMhXYA1MylRvbbM7ANQ+h/SFPPwfcARDuyZ3APNwP9k HFxC0JftDwtgaBnT13eUOnjBqO8lMu2CmF2LDH/0Caw8yr8lAjLRb1LO6wWBbiMYU88i bYiX+i1pka+WPEu7KRZGhx9C/igv6X8SpJNOal+XpS31scD0EQMfLmeKpJVQGnTtbyxW WzH9yYFjBF16c7i703VllIaCMYxbQHdQ7Sn5Y6KSDnUww+LMLmNvv4yEfkROsbjl73SL 0/dA== 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:from:references:cc:to:subject; bh=af1Il6Jt0XExAj82SMz7CdwDRlX5w0rpNgtIYNONLMo=; b=X7ETrT5d4mUWxpnVdzaHc6V8DdCK4FrPmeAZ4tK2CVzAcnOW9dpbaUFOqB9ECT4yMF OxLhQgjCeJHHlEze66mEH2IwTXBvG0rk0XmvgECwRnXPtMv6BJ56h7c2lsJAAC96TYjH k8IM0rtG88BE/VNvZbu7A+0kAkNiQTjOodyBNky4xFm1ANsGfd5f8E5hx/cZBqvy1nRu okhJylRQljKJMbM+LYNNW33P7HOpFOTuZs/51KaaAhidxdSUCkfu1fEo7mZD4mhe3c0n BrVsFAiDbbCjVl9lXJPljyiZZwx8aBVdw6043jVBgulG5JIL4pb34K4/Ws6j7t8Xxr9p 9XCg== 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 g5si8908636pgn.360.2019.08.18.18.52.21; Sun, 18 Aug 2019 18:52:36 -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 S1726347AbfHSBv0 (ORCPT + 99 others); Sun, 18 Aug 2019 21:51:26 -0400 Received: from mga04.intel.com ([192.55.52.120]:17416 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726103AbfHSBvZ (ORCPT ); Sun, 18 Aug 2019 21:51:25 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2019 18:51:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,403,1559545200"; d="scan'208";a="202096627" Received: from genxtest-ykzhao.sh.intel.com (HELO [10.239.143.71]) ([10.239.143.71]) by fmsmga004.fm.intel.com with ESMTP; 18 Aug 2019 18:51:24 -0700 Subject: Re: [RFC PATCH 00/15] acrn: add the ACRN driver module To: Borislav Petkov Cc: x86@kernel.org, linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org References: <1565922356-4488-1-git-send-email-yakui.zhao@intel.com> <20190816063925.GB18980@zn.tnic> From: "Zhao, Yakui" Message-ID: <78897bb2-e6eb-cac2-7166-eccb7cd5c959@intel.com> Date: Mon, 19 Aug 2019 09:44:25 +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: <20190816063925.GB18980@zn.tnic> 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年08月16日 14:39, Borislav Petkov wrote: > On Fri, Aug 16, 2019 at 10:25:41AM +0800, Zhao Yakui wrote: >> The first three patches are the changes under x86/acrn, which adds the >> required APIs for the driver and reports the X2APIC caps. >> The remaining patches add the ACRN driver module, which accepts the ioctl >> from user-space and then communicate with the low-level ACRN hypervisor >> by using hypercall. > > I have a problem with that: you're adding interfaces to arch/x86/ and > its users go into staging. Why? Why not directly put the driver where > it belongs, clean it up properly and submit it like everything else is > submitted? Thanks for your reply and the concern. After taking a look at several driver examples(gma500, android), it seems that they are firstly added into drivers/staging/XXX and then moved to drivers/XXX after the driver becomes mature. So we refer to this method to upstream ACRN driver part. If the new driver can also be added by skipping the staging approach, we will refine it and then submit it in normal process. > > I don't want to have stuff in arch/x86/ which is used solely by code in > staging and the latter is lingering there indefinitely because no one is > cleaning it up... > The ACRN driver will be the only user of the added APIs in x86/acrn. Without the APIs in x86/acrn, the driver can't add the driver-specifc upcall notification ISR or call the hypercall. Not sure whether it can be sent in two patch sets? The first is to add the required APIs for ACRN driver. The second is to add the ACRN driver Thanks Yakui