Messages in this thread | | | Date | Tue, 22 Feb 2022 16:52:53 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [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
| |