[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9ae137d6-dc96-e399-8ea8-cb16b10f9d0b@amd.com>
Date: Fri, 3 Nov 2017 15:01:05 -0500
From: Brijesh Singh <brijesh.singh@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: brijesh.singh@....com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Gary Hook <gary.hook@....com>,
Tom Lendacky <thomas.lendacky@....com>,
linux-crypto@...r.kernel.org
Subject: Re: [Part2 PATCH v7 18/38] crypto: ccp: Implement SEV_PEK_CSR ioctl
command
On 11/3/17 2:42 PM, Borislav Petkov wrote:
...
>> + if (psp_master->sev_state == SEV_STATE_UNINIT) {
>> + ret = __sev_platform_init_locked(psp_master->sev_init, &argp->error);
> Right, you're passing psp_master->sev_init (or whatever you're going to
> end up calling it) down but then in __sev_platform_init_locked() you end
> up doing
>
> if (!data)
> data = &psp->cmd_buf;
>
> which looks silly.
>
> IOW, if not really required, __sev_platform_init_locked() could have
> only one argument instead:
>
> static int __sev_platform_init_locked(int *error)
The cmd_buf argument can be remove. I am have not looked at SEV-ES but
it may be possible that during SEV-ES patches kvm driver may need to
call the sev_platform_init() with different cmd_buf to initialize SEV-ES
states. I can removed it in next version.
-Brijesh
Powered by blists - more mailing lists