From: Brijesh Singh <brijesh.singh@amd.com>
To: Borislav Petkov <bp@suse.de>
Cc: brijesh.singh@amd.com, linux-kernel@vger.kernel.org,
x86@kernel.org, kvm@vger.kernel.org,
"Thomas Gleixner" <tglx@linutronix.de>,
"Joerg Roedel" <joro@8bytes.org>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"\\\"Radim Krčmář\\\"" <rkrcmar@redhat.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S . Miller" <davem@davemloft.net>,
"Gary Hook" <gary.hook@amd.com>,
linux-crypto@vger.kernel.org
Subject: Re: [RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support
Date: Fri, 8 Sep 2017 08:54:17 -0500 [thread overview]
Message-ID: <628e9dbd-77ff-b931-50b1-e72d753612ee@amd.com> (raw)
In-Reply-To: <20170908084009.tb7wzm4j63vhgem4@pd.tnic>
On 09/08/2017 03:40 AM, Borislav Petkov wrote:
> On Thu, Sep 07, 2017 at 05:19:32PM -0500, Brijesh Singh wrote:
>> At high level, AMD-SP (AMD Secure Processor) (i.e CCP driver) will provide the
>> support for CCP, SEV and TEE FW commands.
>>
>>
>> +--- CCP
>> |
>> AMD-SP --|
>> | +--- SEV
>> | |
>> +---- PSP ---*
>> |
>> +---- TEE
>
> I still don't see the need for such finegrained separation, though.
> There's no "this is a separate compilation unit because... ". At least
> the PSP branch could be a single driver without the interface.
>
> For example, psp_request_sev_irq() is called only by sev_dev_init(). So
> why is sev-dev a separate compilation unit? Is anything else going to
> use the PSP interface?
>
I don't know anything about the TEE support hence I don't have very strong
reason for finegrained separation -- I just wanted to ensure that the SEV
enablement does not interfere with TEE support in the future.
> If not, just put it all in a psp-dev file and that's it. We have a
> gazillion config options and having two more just because, is not a good
> reason. You can always carve it out later if there's real need. But if
> the SEV thing can't function without the PSP thing, then you can just as
> well put it inside it.
>
> This way you can save yourself a bunch of exported functions and the
> like.
>
> Another example for not optimal design is psp_request_tee_irq() - it
> doesn't really request an irq by calling into the IRQ core but simply
> assigns a handler. Which looks to me like you're simulating an interface
> where one is not really needed. Ditto for the sev_irq version, btw.
>
It's possible that both TEE and SEV share the same interrupt but their
interrupt handling approach could be totally different hence I tried to
abstract it.
I am making several assumption on TEE side without knowing in detail ;)
I can go with your recommendation -- we can always crave it out later once
the TEE support is visible.
-Brijesh
next prev parent reply other threads:[~2017-09-08 13:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-24 20:02 [RFC Part2 PATCH v3 00/26] x86: Secure Encrypted Virtualization (AMD) Brijesh Singh
2017-07-24 20:02 ` [RFC Part2 PATCH v3 02/26] crypto: ccp: Add Platform Security Processor (PSP) device support Brijesh Singh
2017-07-25 8:29 ` Kamil Konieczny
2017-07-25 15:00 ` Brijesh Singh
2017-09-06 17:00 ` Borislav Petkov
2017-09-06 20:38 ` Brijesh Singh
2017-09-06 20:46 ` Borislav Petkov
2017-09-06 21:26 ` Gary R Hook
2017-09-07 10:34 ` Borislav Petkov
2017-09-07 14:27 ` Borislav Petkov
2017-09-07 22:19 ` Brijesh Singh
2017-09-07 23:15 ` Gary R Hook
2017-09-08 8:22 ` Borislav Petkov
2017-09-08 8:40 ` Borislav Petkov
2017-09-08 13:54 ` Brijesh Singh [this message]
2017-09-08 16:06 ` Brijesh Singh
2017-07-24 20:02 ` [RFC Part2 PATCH v3 03/26] crypto: ccp: Add Secure Encrypted Virtualization (SEV) " Brijesh Singh
2017-09-12 14:02 ` Borislav Petkov
2017-09-12 15:32 ` Brijesh Singh
2017-09-12 16:29 ` Borislav Petkov
2017-09-13 14:17 ` Borislav Petkov
2017-09-13 15:18 ` Brijesh Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=628e9dbd-77ff-b931-50b1-e72d753612ee@amd.com \
--to=brijesh.singh@amd.com \
--cc=bp@suse.de \
--cc=davem@davemloft.net \
--cc=gary.hook@amd.com \
--cc=herbert@gondor.apana.org.au \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox