Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1935927pxb; Wed, 2 Feb 2022 16:25:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJxXgTQl6j5NLvoDVIDJ250owSqLHkOGZ1thdr1v7KyvvUa76rOE8lmjvfnZSKchc54ssVm9 X-Received: by 2002:a17:906:56d0:: with SMTP id an16mr27247905ejc.641.1643847938414; Wed, 02 Feb 2022 16:25:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643847938; cv=none; d=google.com; s=arc-20160816; b=W6QeepiWpAhUiC8fVywav9T+p0pRSpe6ubTa7ykpkOR54nUuSUJbfABXFujOm1jDJq +nVyvzMSKyyiEgf5gCrPDSMYzOKICGQVY6m6du81oQY2bk7br6eeD0ej4WMVtNw73MLO kyrBf6ZS4NMt6qnXhTDWipqpj+ueZWUgbzq+txYsezayqc/w2baFpFRAqzqjAHcx+TFf LEEiMEsRxWY5o5558o4FCGPsoHi9zCk9kYwv89DwVHVaFQ1W2EnISM+rFeCBvyuVR5fg z3tEtMBWEvberjW45rZQycbr96dcVtg96tMcrtoCsW7m8aUMa2/SCbb7lh1L5pSf1ibp rx/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=DAAMAob0i2Ypp+A9dlOUSKJsFprakiY3w91g/F0pEqo=; b=hWRA+ga0eAAY37BCrU734LQIoKxmgCAbkihI+6/vzqhbCOM1XGNwzHVzp2Vh6QEa7o cEEb2ETph/+BVFOzmW6Upe8gZKn7lf9MhUouM7rZVL25oG9K4gT4g0Karm1PwGQbPXIj bKXpdRqU4bn/ALx7m7D2qB7nkU7NKw6qQ/yXWVdfH3dvzrzmefo2EZB+faEfWUhXmFqE bSASjSXJ5Q9SWmqTuqSBO33/LZGcSoVCrXaPULpSI9FNMgOvBmNFKM7WTZjVeOU+l7/g YlcgwGkQbqWOQsD2zWdReh0qI/vg0HiOdgxjp5lj5sszYKwvyt4bxD9837gOLwypKcS+ sbiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="Rme5/egE"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s26si11899623edc.296.2022.02.02.16.25.14; Wed, 02 Feb 2022 16:25:38 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b="Rme5/egE"; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243110AbiBBB1j (ORCPT + 99 others); Tue, 1 Feb 2022 20:27:39 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:43558 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231428AbiBBB1i (ORCPT ); Tue, 1 Feb 2022 20:27:38 -0500 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1643765256; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DAAMAob0i2Ypp+A9dlOUSKJsFprakiY3w91g/F0pEqo=; b=Rme5/egE39TnNwf0GTCFnL9MNSNkspm0gKJ+rlEleTqe0/nlhTI2VesMG5JwaPOoYMnM53 xAi1+cejjJx7pHhlu/bJ6NuNPTqRFm5oAn3WX7fALzjKFzdB7GjGzBZT/tk9i6y3MKemHP MylvXELtvfozwZ6zIbwutKjrRHiGUNhOkxsH9l6qsd8LvSHSleWhOVQdo8CYRfC43QvrXH CmPO7wPe67QEFPYjdM4hoPSP31cGDS9MUN+E1irZocRDjdldkThtZG4JtjZAbYrw87BSQ9 UzL3tBnot4GBvmZFzPvsVJmJH99OtQX6ec004j5Xng4IsmzknM2lsmVHrKzmBA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1643765256; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DAAMAob0i2Ypp+A9dlOUSKJsFprakiY3w91g/F0pEqo=; b=5oUaHDluevtFg/jMsO7qupZnzIKHQWozO7fNzXC/8HuO5uz5qu94LffpaJpF/5cizgD+zW OQPHL+sQM8/5WcBQ== To: "Kirill A. Shutemov" , mingo@redhat.com, bp@alien8.de, dave.hansen@intel.com, luto@kernel.org, peterz@infradead.org Cc: sathyanarayanan.kuppuswamy@linux.intel.com, aarcange@redhat.com, ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com, hpa@zytor.com, jgross@suse.com, jmattson@google.com, joro@8bytes.org, jpoimboe@redhat.com, knsathya@kernel.org, pbonzini@redhat.com, sdeep@vmware.com, seanjc@google.com, tony.luck@intel.com, vkuznets@redhat.com, wanpengli@tencent.com, x86@kernel.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" , Sean Christopherson , Kai Huang Subject: Re: [PATCHv2 24/29] x86/mm/cpa: Add support for TDX shared memory In-Reply-To: <20220124150215.36893-25-kirill.shutemov@linux.intel.com> References: <20220124150215.36893-1-kirill.shutemov@linux.intel.com> <20220124150215.36893-25-kirill.shutemov@linux.intel.com> Date: Wed, 02 Feb 2022 02:27:36 +0100 Message-ID: <875ypyvz07.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 24 2022 at 18:02, Kirill A. Shutemov wrote: > -void notify_range_enc_status_changed(unsigned long vaddr, int npages, bool enc) > +int amd_notify_range_enc_status_changed(unsigned long vaddr, int npages, > + bool enc) > { > #ifdef CONFIG_PARAVIRT > unsigned long sz = npages << PAGE_SHIFT; > @@ -270,7 +271,7 @@ void notify_range_enc_status_changed(unsigned long vaddr, int npages, bool enc) > kpte = lookup_address(vaddr, &level); > if (!kpte || pte_none(*kpte)) { > WARN_ONCE(1, "kpte lookup for vaddr\n"); > - return; > + return 0; > } > > pfn = pg_level_to_pfn(level, kpte, NULL); > @@ -285,6 +286,7 @@ void notify_range_enc_status_changed(unsigned long vaddr, int npages, bool enc) > vaddr = (vaddr & pmask) + psize; > } > #endif > + return 0; > } This is obviously a preparatory change, so please split it out into a seperate patch. You know the drill already, right? > +static pgprot_t pgprot_cc_mask(bool enc) > +{ > + if (enc) > + return pgprot_encrypted(__pgprot(0)); > + else > + return pgprot_decrypted(__pgprot(0)); > +} How is this relevant to the scope of this TDX patch? Why is this not part of the previous change which consolidated __pgprot(_PAGE_ENC)? Just because it is too obvious to fixup the usage sites first? > +static int notify_range_enc_status_changed(unsigned long vaddr, int npages, > + bool enc) > +{ > + if (cc_platform_has(CC_ATTR_GUEST_TDX)) { > + phys_addr_t start = __pa(vaddr); > + phys_addr_t end = __pa(vaddr + npages * PAGE_SIZE); > + > + return tdx_hcall_request_gpa_type(start, end, enc); > + } else { > + return amd_notify_range_enc_status_changed(vaddr, npages, enc); > + } This is more than lame, really. The existing SEV specific notify_range_enc_status_changed() function has been called unconditionally, but for TDX you add a cc_platform_has() check and still call the AMD part unconditionally if !TDX. Aside of that the two functions have different calling conventions. Why? Just because the TDX function which you defined requires physical addresses this needs to be part of the PAT code? Make both functions share the same calling conventions and thinks hard about whether cc_platform_has() is the proper mechanism. There are other means to handle such things. Hint: x86_platform_ops > +} > + > /* > * __set_memory_enc_pgtable() is used for the hypervisors that get > * informed about "encryption" status via page tables. > @@ -1999,8 +2021,10 @@ static int __set_memory_enc_pgtable(unsigned long addr, int numpages, bool enc) > memset(&cpa, 0, sizeof(cpa)); > cpa.vaddr = &addr; > cpa.numpages = numpages; > - cpa.mask_set = enc ? __pgprot(_PAGE_ENC) : __pgprot(0); > - cpa.mask_clr = enc ? __pgprot(0) : __pgprot(_PAGE_ENC); > + > + cpa.mask_set = pgprot_cc_mask(enc); > + cpa.mask_clr = pgprot_cc_mask(!enc); > + > cpa.pgd = init_mm.pgd; > > /* Must avoid aliasing mappings in the highmem code */ > @@ -2008,9 +2032,17 @@ static int __set_memory_enc_pgtable(unsigned long addr, int numpages, bool enc) > vm_unmap_aliases(); > > /* > - * Before changing the encryption attribute, we need to flush caches. > + * Before changing the encryption attribute, flush caches. > + * > + * For TDX, guest is responsible for flushing caches on private->shared > + * transition. VMM is responsible for flushing on shared->private. > */ > - cpa_flush(&cpa, !this_cpu_has(X86_FEATURE_SME_COHERENT)); > + if (cc_platform_has(CC_ATTR_GUEST_TDX)) { > + if (!enc) > + cpa_flush(&cpa, 1); > + } else { > + cpa_flush(&cpa, !this_cpu_has(X86_FEATURE_SME_COHERENT)); > + } This is the point where my disgust tolerance ends. Seriously. Is that all you can come up with? Slapping this kind of conditionals all over the place? Again. Think hard about the right abstraction for this and not about how to duct tape it into the existing code. Just becausre cc_platform_has() exists does not mean it's the only tool which can be used. Not everything is a nail... This screams for an indirect branch, e.g. some extension to the existing x86_platform_ops. It's trivial enough to add a (encrypted) guest specific data structure with relevant operations to x86_platform_ops and fill that in on detection like we do for other things. Then the whole muck here boils down to: - notify_range_enc_status_changed(addr, numpages, enc); - + if (!ret) + ret = x86_platform.guest.enc_status_changed(addr, numpages, enc); and - cpa_flush(&cpa, !this_cpu_has(X86_FEATURE_SME_COHERENT)); + cpa_flush(&cpa, x86_platform.guest.enc_flush_required(enc)); Hmm? Feel free to come up with better names... Thanks, tglx