lkml.org 
[lkml]   [2022]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv3 02/32] x86/coco: Add API to handle encryption mask
On Tue, Feb 22, 2022 at 02:37:27PM +0100, Borislav Petkov wrote:
> On Tue, Feb 22, 2022 at 02:03:12PM +0300, Kirill A. Shutemov wrote:
> > I would rather make cc_mkenc()/cc_mkdec() to operate on u64 (or
> > phys_addr_t?) while pgprot_encrypted()/pgprot_decrypted() cover pgprot_t.
> > It also makes set_memory cleaner:
> >
> > cpa.mask_set = __pgprot(enc ? cc_mkenc(0) : cc_mkdec(0));
> > cpa.mask_clr = __pgprot(enc ? cc_mkdec(0) : cc_mkenc(0));
> >
> > Opinions?
>
> Right, do I see it correctly that the cc_mk{enc,dec}() things should
> take a u64 as an argument and return a pgprot_t, and that would be the
> most optimal way for all the use cases?

No, not really. With u64-in-u64-out in tdx_enc_status_changed() we have

if (!enc) {
start |= cc_mkdec(0);
end |= cc_mkdec(0);
}

to iterate over the range of physical addresses with shared bit set.
With u64-in-pgprot_t-out we will have do add pgprot_val() there.

We will have more cases like this in attestation code when we need to do
hypercall on a shared page.

--
Kirill A. Shutemov

\
 
 \ /
  Last update: 2022-02-22 14:53    [W:0.053 / U:0.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site