From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 81BDB1360 for ; Sun, 4 Sep 2022 06:37:08 +0000 (UTC) Received: from nazgul.tnic (dynamic-002-247-250-198.2.247.pool.telefonica.de [2.247.250.198]) (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 609571EC03EA; Sun, 4 Sep 2022 08:37:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1662273421; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=A/yg6xLScDG3nkcrMuFvwn0cTlwl9YzQi+dbx7SZXE4=; b=pN97dF0fDmXybRWJ/KRiBRIBo09g3o8gogusERQNNw/JE8r+lwYvwNsl/Jei5OIwVjhq/B b4JnlpbPeLY2hOK5QXqEsipafAphSpvCQIRejvFSC4daKFKQhmr2vc9Y4uQKMLfCCpLJxz kn63o730nFrlWU4nmmHm95lGJS7I//U= Date: Sun, 4 Sep 2022 08:37:08 +0200 From: Borislav Petkov To: "Kalra, Ashish" Cc: "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , "rientjes@google.com" , "linux-mm@kvack.org" , "linux-coco@lists.linux.dev" , "tglx@linutronix.de" , "slp@redhat.com" , "peterz@infradead.org" , "linux-crypto@vger.kernel.org" , "mingo@redhat.com" , "hpa@zytor.com" , "ak@linux.intel.com" , "Lendacky, Thomas" , "alpergun@google.com" , "jroedel@suse.de" , "dave.hansen@linux.intel.com" , "seanjc@google.com" , "pgonda@google.com" , "pbonzini@redhat.com" , "srinivas.pandruvada@linux.intel.com" , "ardb@kernel.org" , "dovmurik@linux.ibm.com" , "tobin@ibm.com" , "Roth, Michael" , "jmattson@google.com" , "kirill@shutemov.name" , "vkuznets@redhat.com" , "tony.luck@intel.com" , "vbabka@suse.cz" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "luto@kernel.org" , "dgilbert@redhat.com" , "marcorr@google.com" , "jarkko@kernel.org" Subject: Re: [PATCH Part2 v6 09/49] x86/fault: Add support to handle the RMP fault for user address Message-ID: References: Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sat, Sep 03, 2022 at 05:30:28PM +0000, Kalra, Ashish wrote: > There is 1 64-bit RMP entry for every physical 4k page of DRAM, so > essentially every 4K page of DRAM is represented by a RMP entry. Before we get to the rest - this sounds wrong to me. My APM has: "PSMASH Page Smash Expands a 2MB-page RMP entry into a corresponding set of contiguous 4KB-page RMP entries. The 2MB page’s system physical address is specified in the RAX register. The new entries inherit the attributes of the original entry. Upon completion, a return code is stored in EAX. rFLAGS bits OF, ZF, AF, PF and SF are set based on this return code..." So there *are* 2M entries in the RMP table. > So even if host page is 1G and underlying (smashed/split) RMP > entries are 2M, the RMP table entry has to be indexed to a 4K entry > corresponding to that. So if there are 2M entries in the RMP table, how does that indexing with 4K entries is supposed to work? Hell, even PSMASH pseudocode shows how you go and write all those 512 4K entries using the 2M entry as a template. So *before* you have smashed that 2M entry, it *is* an *actual* 2M entry. So if you fault on a page which is backed by that 2M RMP entry, you will get that 2M RMP entry. > If it was simply a 2M entry in the RMP table, then pmd_index() will > work correctly. Judging by the above text, it *can* *be* a 2M RMP entry! By reading your example you're trying to tell me that a RMP #PF will always need to work on 4K entries. Which would then need for a 2M entry as above to be PSMASHed in order to get the 4K thing. But that would be silly - RMP PFs will this way gradually break all 2M pages and degrage performance for no real reason. So this still looks real wrong to me. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette