From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8B21822DFA7 for ; Mon, 10 Mar 2025 15:44:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741621446; cv=none; b=fuDOVgq61c9nwYDzXutgRiDAJEJW4BNkq6AhLAstN4ndSlh4mtHOv9QnRbkNzndTU7O9zbF2svioqoLi7+nIw1rLpNS3UWQH6tALyomnYsRkf+tZlj74wCd/xIr0MdjcJxvAp/MrPOVwTkcRUp86Id+YXvZUM+MxRb88NMcq3GY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741621446; c=relaxed/simple; bh=TzAtY/6qL6szhG04BGLc4P3/1EgI4kXeNVMDD1TY+bI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C0ytEsuc2SLzSKdIW4fY59FkKVDut48DOAJNhVKDsN0682M5kOKcX8ZMbpx9Sp+dnW9HoxyJUfImnYV4RuV4y4Jl2TBHz7xWRjFEa3NwKYlfsWpanbj1z4snBweDqW3CBZ8QxRSpOQz/UZxalwg6NSwEBsvkR4iGANAIGcgG/3k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VKOW/w2s; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VKOW/w2s" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1165AC4CEED; Mon, 10 Mar 2025 15:44:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741621446; bh=TzAtY/6qL6szhG04BGLc4P3/1EgI4kXeNVMDD1TY+bI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VKOW/w2sM+fI6GxW/iAP8ZxJKI6G/JQPStoY0DxR1ojAjx5ZQnrBp7/lQsrgABGZf xvnH7fdjeUbsHY4X28brpdHgzjUfFe3wUXG7/5xcfinreiZA4R80uvXcj2rGtwuPiw 21EZBbEucc9R/z1IAwKdePjjyuN5Zulkze/b6kA1/XPw7r60lk3NYhluiqKDerve5n IDrsvzIngSishT0LdCCodNX5bdxnjIjfENv6dVx+whC7KBdo9J8wDxq+pVTyH7/jIX DgDXtO5NssLQUCrp4eXzwOpym18sbfi0sSA8iEc6v4NBE/n+NcwXJyjE16o6i5v7j1 une0V8a5TiA7g== Date: Mon, 10 Mar 2025 16:43:59 +0100 From: Alexey Gladkov To: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= Cc: Borislav Petkov , Joerg Roedel , "Alexey Gladkov (Intel)" , "Kirill A. Shutemov" , Dave Hansen , Joerg Roedel , Ingo Molnar , x86@kernel.org, hpa@zytor.com, Tom Lendacky , Nikunj A Dadhania , linux-kernel@vger.kernel.org, Larry.Dewey@amd.com Subject: Re: [PATCH] x86/sev: Make SEV_STATUS available via SYSFS Message-ID: References: <20250310133833.GHZ87rWfuV6WgQTsoh@fat_crate.local> <20250310151154.GOZ88BOinZVkbYEx0w@fat_crate.local> <104b6d4f-2848-42f4-a134-3373d12d9424@suse.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <104b6d4f-2848-42f4-a134-3373d12d9424@suse.com> On Mon, Mar 10, 2025 at 04:33:08PM +0100, Jürgen Groß wrote: > On 10.03.25 16:11, Borislav Petkov wrote: > > On Mon, Mar 10, 2025 at 03:50:09PM +0100, Alexey Gladkov wrote: > >> Am I understand correctly that you and Joerg are proposing > >> > >> /sys/guest/tdx/... > >> /sys/guest/sev/... > >> > >> ? > >> > >> Which path to use for the host side ? > >> > >> For guest: /sys/coco/guest/{tdx,sev}/... > >> For host: /sys/coco/host/{tdx,sev}/... > >> > >> Maybe it would be better to add the "coco" subdirectory or something like > >> that ? > > > > Hmm, so we can do > > > > /sys/guest > > > > and extend > > > > /sys/hypervisor > > > > Or we can do what you're suggesting. > > > > If we do /sys/coco/host, then we'll have two different places to read HV info. > > > > Or we can stick *everything* coco needs in > > > > /sys/coco/{sev,tdx} > > > > but then it is coco-specific and if other guest types want to put stuff in > > sysfs, it'll get ugly. > > > > So I guess having > > > > /sys/guest > > and > > /sys/hypervisor > > > > kinda keeps it all clean, hierarchy-wise... > > > > Right? > > Kind of. > > /sys/hypervisor is meant to provide data for running under a hypervisor. > > It is NOT meant to provide data for running as a hypervisor. > > So far when running either under Xen or under z/VM /sys/hypervisor is being > populated. > > I'm not feeling really strong here. I just want to state the status quo. OK, so I misunderstood. If in the /sys/hypervisor we have information for guest (for running under a hypervisor), where do you propose to put the information for the host-side (for running as a hypervisor) ? -- Rgrds, legion