[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241017152601.GAZxEsid01FYKqwnPA@fat_crate.local>
Date: Thu, 17 Oct 2024 17:26:01 +0200
From: Borislav Petkov <bp@...en8.de>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Michael Roth <michael.roth@....com>,
Ashish Kalra <ashish.kalra@....com>
Subject: Re: [PATCH v3 2/8] x86/sev: Add support for the RMPREAD instruction
On Mon, Sep 30, 2024 at 10:22:10AM -0500, Tom Lendacky wrote:
> + if (cpu_feature_enabled(X86_FEATURE_RMPREAD)) {
> + int ret;
> +
> + asm volatile(".byte 0xf2, 0x0f, 0x01, 0xfd"
> + : "=a" (ret)
> + : "a" (pfn << PAGE_SHIFT), "c" (entry)
> + : "memory", "cc");
> +
> + return ret;
> + }
> +
> e = __get_rmpentry(pfn);
So dump_rmpentry() still calls this but it doesn't require the newly added
services of RMPREAD and so this is looking to be disambiguated: a function
which gives you the entry coming from RMPREAD, I guess the architectural one,
and the other one.
IOW, I am still unclear on the nomenclature:
The _raw* entries do not come from the insn but then what's the raw-ness about
them?
This convention sounds weird as it is now, I'd say.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists