[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yzsvk7zFJrnNPUek@zn.tnic>
Date: Mon, 3 Oct 2022 20:53:07 +0200
From: Borislav Petkov <bp@...en8.de>
To: "Kalra, Ashish" <Ashish.Kalra@....com>
Cc: Peter Gonda <pgonda@...gle.com>, "x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"jroedel@...e.de" <jroedel@...e.de>,
"Lendacky, Thomas" <Thomas.Lendacky@....com>,
"hpa@...or.com" <hpa@...or.com>,
"ardb@...nel.org" <ardb@...nel.org>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"seanjc@...gle.com" <seanjc@...gle.com>,
"vkuznets@...hat.com" <vkuznets@...hat.com>,
"jmattson@...gle.com" <jmattson@...gle.com>,
"luto@...nel.org" <luto@...nel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"slp@...hat.com" <slp@...hat.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"srinivas.pandruvada@...ux.intel.com"
<srinivas.pandruvada@...ux.intel.com>,
"rientjes@...gle.com" <rientjes@...gle.com>,
"dovmurik@...ux.ibm.com" <dovmurik@...ux.ibm.com>,
"tobin@....com" <tobin@....com>,
"Roth, Michael" <Michael.Roth@....com>,
"vbabka@...e.cz" <vbabka@...e.cz>,
"kirill@...temov.name" <kirill@...temov.name>,
"ak@...ux.intel.com" <ak@...ux.intel.com>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"marcorr@...gle.com" <marcorr@...gle.com>,
"sathyanarayanan.kuppuswamy@...ux.intel.com"
<sathyanarayanan.kuppuswamy@...ux.intel.com>,
"alpergun@...gle.com" <alpergun@...gle.com>,
"dgilbert@...hat.com" <dgilbert@...hat.com>,
"jarkko@...nel.org" <jarkko@...nel.org>
Subject: Re: [PATCH Part2 v6 13/49] crypto:ccp: Provide APIs to issue SEV-SNP
commands
On Mon, Oct 03, 2022 at 06:43:08PM +0000, Kalra, Ashish wrote:
> probably it is nice to have an abstracted interface,
Why is it "probably nice" to have an abstracted interface?
Is the hypervisor allowed to issue only a subset of the commands?
Do you want to control the arguments the hypervisor is supposed to send
down to the firmware?
There must be a reason why one would do an abstracted interface. Not
just because and probably.
Because from where I'm standing this looks like adding a bunch of random
wrappers without any logic to it.
So, if you wanna have an interface, you should think this through and
design it properly and explain why it is there and how it is supposed to
be used.
Don't get me wrong - a properly designed interface to control what the
HV issues to the firmware is not a bad idea. But it needs to be properly
designed.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists