Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp3197694pxb; Tue, 20 Apr 2021 02:51:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx++QxIV+35/RAiuoPGb6X9u8/F0krMPru67lx7EyApbtDCpZjeeHsjj7hrFgZPL9YAx5U3 X-Received: by 2002:a63:6ec1:: with SMTP id j184mr16034797pgc.364.1618912289645; Tue, 20 Apr 2021 02:51:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618912289; cv=none; d=google.com; s=arc-20160816; b=fh7rta9mvw6Hg7Z4uKjmr9f5HBKFtSaF3ueTjPpVDrcV2/CWBCcIDS99Uq169gpn8Y x0VrAnDwSVD9oe6vcFn8ABpDYZ2fQp9X5iIJx6IB91/gr8l5rS50XbWkjcGf24G1znnJ ruG58MNM+Zu6o6eEg+DA3viWc3cIvQqfNilVgASkIDC4q/m8CDZ6MqKgmijI7++kv756 5CqoTj9U+Faxs/SXda4Q6Id7a6yGMxAwrU/G5V80tLIGO46tACITyqK9XIf/7BHNssEt YetHWdItZghtnaYHaqbvRLnkyJPozaHyQwGRpnOPAtdVe96DSemwkaZW84HiOpZmOW29 ZDDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=nu9NnhXo+DMKJ3rvwlbMifnQjVrpaKGMWoTrw6zuu30=; b=kdwFfnNheeIg10B3DNr/MbzUrxfSWh0d21IGIxRpH4nL9yBYwr/g6TAG39ZO8wGz+O +nxVCg8h5cbSHpRcpzFu2XDGT6LQgFEqhtFpa+BtzC8QFAFKpZds3Lh/dazcNB4sbG1x 8pXxejZufW5mLtdLcZS13l7MjrUFKLUGKgY1Qyu3I2q7mR9nFt+m88jZLaDpMmPc6edq Lp+rY5wW+EXa8xOx8M95dxrjfZVkdlYiYJv3ihfkaVn55NeiZvY/k6VxFHPh/f8/mnVP +8J7Lx1A6JP2n/O6wB6MP1/vINJPDCmj8V6SQyecoPdumLJNqvZyu0SuNEp/1lGmkPLm TBBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=fD2V4XGG; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y22si2821193pju.8.2021.04.20.02.51.16; Tue, 20 Apr 2021 02:51:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=fD2V4XGG; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230204AbhDTJvp (ORCPT + 99 others); Tue, 20 Apr 2021 05:51:45 -0400 Received: from mail.skyhub.de ([5.9.137.197]:38524 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229937AbhDTJvp (ORCPT ); Tue, 20 Apr 2021 05:51:45 -0400 Received: from zn.tnic (p200300ec2f0e52003145dfcc247b909a.dip0.t-ipconnect.de [IPv6:2003:ec:2f0e:5200:3145:dfcc:247b:909a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id DFCE01EC0103; Tue, 20 Apr 2021 11:51:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1618912273; 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: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=nu9NnhXo+DMKJ3rvwlbMifnQjVrpaKGMWoTrw6zuu30=; b=fD2V4XGGukrvb+aMl/SUZbaqnmeF+f1AJBhnO35x+YlEOUEd+pt5qKbhpTcyFoQa1rtztW jAd7o2oVbz0ciA/NXOwfrOoE7uYONxrhmJOPcwbfk0iwRx7neBH9qi+b+4fDEsCzS92NK7 glFwpdjvYi2mGQkiO/xepxxLOL6Z7h0= Date: Tue, 20 Apr 2021 11:51:15 +0200 From: Borislav Petkov To: Dave Hansen Cc: Andy Lutomirski , Brijesh Singh , linux-kernel@vger.kernel.org, x86@kernel.org, kvm@vger.kernel.org, linux-crypto@vger.kernel.org, ak@linux.intel.com, herbert@gondor.apana.org.au, Thomas Gleixner , Ingo Molnar , Joerg Roedel , "H. Peter Anvin" , Tony Luck , "Peter Zijlstra (Intel)" , Paolo Bonzini , Tom Lendacky , David Rientjes , Sean Christopherson , Vlastimil Babka Subject: Re: [RFC Part2 PATCH 04/30] x86/mm: split the physmap when adding the page in RMP table Message-ID: <20210420095115.GE5029@zn.tnic> References: <61596c4c-3849-99d5-b0aa-6ad6b415dff9@intel.com> <535400b4-0593-a7ca-1548-532ee1fefbd7@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <535400b4-0593-a7ca-1548-532ee1fefbd7@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Apr 19, 2021 at 11:33:08AM -0700, Dave Hansen wrote: > My point was just that you can't _easily_ do the 2M->4k kernel mapping > demotion in a page fault handler, like I think Borislav was suggesting. Yeah, see my reply to Brijesh. Not in the #PF handler but when the guest does update the RMP table on page allocation, we should split the kernel mapping too, so that it corresponds to what's being changed in the RMP table. Dunno how useful it would be if we also do coalescing of 4K pages into their corresponding 2M pages... I haven't looked at set_memory.c for a long time and have forgotten about all details... In any case, my main goal here is to keep the tables in sync so that we don't have to do crazy splitting in unsafe contexts like #PF. I hope I'm making sense... -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette