From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FC77C11F64 for ; Thu, 1 Jul 2021 18:04:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0FEAA61417 for ; Thu, 1 Jul 2021 18:04:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0FEAA61417 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=alien8.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 42AE48D02AE; Thu, 1 Jul 2021 14:04:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DB138D0001; Thu, 1 Jul 2021 14:04:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2558E8D02AE; Thu, 1 Jul 2021 14:04:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) by kanga.kvack.org (Postfix) with ESMTP id F21FD8D0001 for ; Thu, 1 Jul 2021 14:04:10 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id A8CB81802C501 for ; Thu, 1 Jul 2021 18:04:10 +0000 (UTC) X-FDA: 78314793060.29.56A37B8 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf20.hostedemail.com (Postfix) with ESMTP id 4F9E3D0000A8 for ; Thu, 1 Jul 2021 18:04:02 +0000 (UTC) Received: from zn.tnic (p200300ec2f129e0080cb4010141c3d3f.dip0.t-ipconnect.de [IPv6:2003:ec:2f12:9e00:80cb:4010:141c:3d3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 7547E1EC054E; Thu, 1 Jul 2021 20:04:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1625162640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=pA5qidpGRMz4iB462uPn953XJs14KjqFbjDwTnvDnKg=; b=OHT4NlQL9fVtGHXge2xZSd0T4EtBcQOmHUNmaE2UC612fKA/8lwfY5w8HH19skwww6/STE w59gY7ILIMMe0ZyN6jwbgjjR4zWs30kvUfgtbeBw73IN/ywKqCl1h2D8vx+XtIEcdzKNGg kS/Fvml/488FUBEJyM1T7mfITHlUCSg= Date: Thu, 1 Jul 2021 20:03:55 +0200 From: Borislav Petkov To: Brijesh Singh Cc: x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , tony.luck@intel.com, npmccallum@redhat.com, Dov Murik Subject: Re: [PATCH Part1 RFC v3 22/22] virt: Add SEV-SNP guest driver Message-ID: References: <20210602140416.23573-1-brijesh.singh@amd.com> <20210602140416.23573-23-brijesh.singh@amd.com> <46499161-0106-3ae9-9688-0afd9076b28b@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <46499161-0106-3ae9-9688-0afd9076b28b@amd.com> X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4F9E3D0000A8 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=alien8.de header.s=dkim header.b=OHT4NlQL; spf=temperror (imf20.hostedemail.com: error in processing during lookup of bp@alien8.de: DNS error) smtp.mailfrom=bp@alien8.de; dmarc=temperror reason="query timed out" header.from=alien8.de (policy=temperror) X-Stat-Signature: n9mbrcikq1aukwuwxprpnzqzhdjwaxw5 X-HE-Tag: 1625162642-753686 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jun 30, 2021 at 11:26:46AM -0500, Brijesh Singh wrote: > As you have noticed that Dov is submitting the SEV specific driver. Well, reportedly that driver is generic-ish as it only handles the EFI-provided sekrits and is not SEV-specific - the SEV use is only exemplary. > I was thinking that it will be nice if we have one driver that covers > both the SEV and SEV-SNP. That driver can be called "sevguest". The > kernel will install the appropriate platform device. The sevguest > driver can probe for both the "sev-guest" and "snp-guest" and delegate > the ioctl handling accordingly. > > In the kernel the directory structure may look like this: > > virt/coco/sevguest > sevguest.c // common code > snp.c // SNP specific ioctl implementation > sev.c // SEV specific ioctl or sysfs implementation > > Thoughts ? Sure, but I'd call it sevguest.c and will have it deal with both SEV and SNP ioctls depending on what has been detected in the hardware. Or is there some special reason for having snp.c and sev.c separate? > I followed the naming convension you recommended during the initial SEV driver > developement. IIRC, the main reason for us having to add "user" in it because > we wanted to distinguious that this structure is not exactly same as the what > is defined in the SEV-SNP firmware spec. I most definitely have forgotten about this. Can you point me to the details of that discussion and why there's a need to distinguish? > Good question, I am not able to find a generic place to document it. Should we > create a documentation "Documentation/virt/coco/sevguest-api.rst" for it ? I am > open to other suggestions. Well, grepping the tree for "ioctl" I see: Documentation/driver-api/ioctl.rst Documentation/process/botching-up-ioctls.rst Documentation/userspace-api/ioctl/cdrom.rst Documentation/userspace-api/ioctl/hdio.rst Documentation/userspace-api/ioctl/index.rst Documentation/userspace-api/ioctl/ioctl-decoding.rst Documentation/userspace-api/ioctl/ioctl-number.rst Documentation/userspace-api/media/cec/cec-func-ioctl.rst Documentation/userspace-api/media/mediactl/media-func-ioctl.rst Documentation/userspace-api/media/mediactl/request-func-ioctl.rst Documentation/userspace-api/media/v4l/func-ioctl.rst and there's some good info as to what to do. In any case, Documentation/virt/coco/sevguest-api.rst doesn't sound too bad either, actually, as it collects everything under virt/ Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette