On Tue, Dec 05, 2023 at 02:49:57AM -0800, Xin Li wrote:
> Warning: use of this parameter will taint the kernel
> and may cause unknown problems.
>
> + fred[X86-64]
> + Enable flexible return and event delivery
Let's
On Tue, Dec 05, 2023 at 02:49:56AM -0800, Xin Li wrote:
> From: "H. Peter Anvin (Intel)"
>
> Add CONFIG_X86_FRED to to make
> cpu_feature_enabled() work correctly with FRED.
>
> Originally-by: Megha Dey
> Signed-off-by: H. Peter Anvin (Intel)
> Tested-by: Shan Kang
> Signed-off-by: Xin Li
>
On Tue, Jan 02, 2024 at 10:06:27PM +, Li, Xin3 wrote:
> Do I need to send an updated patch?
> Or just leave it to the maintainer who is going to take care of it?
While waiting, please take a look at this:
https://kernel.org/doc/html/latest/process/submitting-patches.html#don-t-get-discourage
On Tue, Dec 05, 2023 at 02:49:50AM -0800, Xin Li wrote:
> Subject: Re: [PATCH v13 01/35] x86/cpufeatures,opcode,msr: Add the WRMSRNS
> instruction support
Or simply "x86/fred: Add ... "
Other than that,
Acked-by: Borislav Petkov (AMD)
--
Regards/Gruss,
Boris.
https://p
On Tue, Nov 28, 2023 at 10:58:50AM -0800, H. Peter Anvin wrote:
> >You have a very good sense 😊
I've been reading code of a couple of people for a couple of years. :-)
> Remember that Signed-off-by: relates to the *patch flow*.
Yes, you should take the time to read Documentation/process/ and
esp
On Mon, Oct 02, 2023 at 11:24:45PM -0700, Xin Li wrote:
> FRED and IDT can share most of the definitions and declarations so
> that in the majority of cases the actual handler implementation is the
> same.
>
> The differences are the exceptions where FRED stores exception related
> information on
On Mon, Oct 02, 2023 at 11:24:41PM -0700, Xin Li wrote:
> + * Note, LKGS loads the GS base address into the IA32_KERNEL_GS_BASE
> + * MSR instead of the GS segment’s descriptor cache. As such, the
:verify_diff: WARNING: Unicode char [’] (0x8217 in line: + * MSR instead of
the GS seg
On Mon, Oct 02, 2023 at 11:24:37PM -0700, Xin Li wrote:
> FRED defines additional information in the upper 48 bits of cs/ss
> fields. Therefore add the information definitions into the pt_regs
> structure.
>
> Specially introduce a new structure fred_ss to denote the FRED flags
> above SS selector
From: "Borislav Petkov (AMD)"
After receiving a second patchset this week without knowing which tree
it applies on and trying to apply it on the obvious ones and failing,
make sure the base tree information which needs to be supplied in the
0th message of the patchset is spelle
On Tue, Nov 14, 2023 at 12:43:38AM +, Li, Xin3 wrote:
> No. tglx asked for it:
> https://lkml.kernel.org/kvm/87y1h81ht4.ffs@tglx/
Aha
"According to the CPU folks FRED systems are guaranteed to have WRMSRNS -
I asked for that :). It's just not yet documented."
so I'm going to expect that to
On Mon, Nov 13, 2023 at 12:36:04PM -0500, H. Peter Anvin wrote:
> A resource cannot be consumed after the value has been written; this
> is the only necessary level of serialization, equivalent to, say, RAX.
Lemme see if I understand this correctly using this context as an
example: after this MSR_
On Mon, Oct 02, 2023 at 11:24:40PM -0700, Xin Li wrote:
> From: "H. Peter Anvin (Intel)"
>
> MSR_IA32_FRED_RSP0 is used during ring 3 event delivery, and needs to
> be updated to point to the top of next task stack during task switch.
>
> Signed-off-by: H. Peter Anvin (Intel)
> Tested-by: Shan
On Mon, Oct 02, 2023 at 11:24:22PM -0700, Xin Li wrote:
> Subject: Re: [PATCH v12 01/37] x86/cpufeatures: Add the cpu feature bit for
> WRMSRNS
For all your text:
s/cpu/CPU/g
> WRMSRNS is an instruction that behaves exactly like WRM
On Wed, Aug 28, 2019 at 02:29:13PM +0200, Pavel Machek wrote:
> This is not a way to have an inteligent conversation.
No, this *is* the way to keep the conversation sane, without veering
off into some absurd claims.
So, to cut to the chase: you can simply add "rdrand=force" to your
cmdline parame
On Wed, Aug 28, 2019 at 02:09:36PM +0200, Pavel Machek wrote:
> Yes, and now AMD has patch to break it on *all* machines.
It doesn't break all machines - you need to look at that patch again.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed, Aug 28, 2019 at 01:49:47PM +0200, Pavel Machek wrote:
> AMD screwed this up,
Except that it wasn't AMD who screwed up but BIOS on *some* laptops.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Sat, Aug 24, 2019 at 09:50:28AM -0400, Sasha Levin wrote:
> Why is this being removed (along with supporting code)?
This was only a temporary bug in the new tip-bot which is fixed now. The
commit in tip is fine:
c49a0a80137c ("x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h")
--
Re
On Tue, Aug 13, 2019 at 01:52:01PM -0700, Yu-cheng Yu wrote:
> Control-flow Enforcement (CET) MSR contents are XSAVES system states.
> To support CET, introduce XSAVES system states first.
>
> XSAVES is a "supervisor" instruction and, comparing to XSAVE, saves
> additional "supervisor" states that
On Tue, Aug 13, 2019 at 01:52:00PM -0700, Yu-cheng Yu wrote:
> Add CPU feature flags for Control-flow Enforcement Technology (CET).
>
> CPUID.(EAX=7,ECX=0):ECX[bit 7] Shadow stack
> CPUID.(EAX=7,ECX=0):EDX[bit 20] Indirect branch tracking
>
> Reviewed-by: Borislav Petkov
&
On Thu, Aug 15, 2019 at 10:25:24PM +0100, Andrew Cooper wrote:
> I'm afraid that a number of hypervisors do write-discard, given the
> propensity of OSes (certainly traditionally) to go poking at bits like
> this without wrmsr_safe().
>
> You either need to read the MSR back and observe that the b
On Thu, Aug 15, 2019 at 09:59:03PM +0100, Andrew Cooper wrote:
> If you're virtualised, the write to MSR_AMD64_CPUID_FN_1 almost
> certainly won't take effect, which means userspace will still be able to
> see the bit.
msr_clear_bit() has a return value. We should check it before
doing anything fu
On Thu, Aug 15, 2019 at 01:47:24PM +, Lendacky, Thomas wrote:
> Sure, I can do that. Do we want to tie this into the nordrand option and
> add rdrand=off or keep that separate?
Yeah, I was looking at that this morning and I'd say keep 'em separate
because if you have to tie, you need to export
On Wed, Aug 14, 2019 at 09:17:41PM +, Lendacky, Thomas wrote:
> From: Tom Lendacky
>
> There have been reports of RDRAND issues after resuming from suspend on
> some AMD family 15h and family 16h systems. This issue stems from BIOS
> not performing the proper steps during resume to ensure RDR
On Thu, Jun 20, 2019 at 04:29:19AM -0400, Ethan Sommer wrote:
> Ah sorry about that, I accidentally replied to Kieran only instead of to
> all, my response was "I will upload a patch with those issues fixed
> shortly, in terms of the dependency as far as I know commands only required
> for running
On Thu, Jun 20, 2019 at 04:11:32AM -0400, Ethan Sommer wrote:
> removes the bc build dependency introduced when timeconst.pl was
> replaced by timeconst.bc:
> 70730bca1331 ("kernel: Replace timeconst.pl with a bc script")
I don't see you answering Kieran's questions anywhere...
--
Regards/Gruss,
On Tue, May 14, 2019 at 03:49:43PM +0200, Christoph Hellwig wrote:
> On Tue, May 14, 2019 at 12:26:32PM +0200, Borislav Petkov wrote:
> > This breaks scripts/spdxcheck.py, it needs below hunk. Also, should
> > "dual" be added to license_dirs too?
>
> Yes. In fa
On Tue, Apr 30, 2019 at 06:51:30AM -0400, Christoph Hellwig wrote:
> Make it clear in the directory name that these are not intended for new
> code.
>
> Signed-off-by: Christoph Hellwig
> ---
> Documentation/process/license-rules.rst | 8
> LICENSES/{other => deprecated}/GPL-1.0
On Mon, Jan 14, 2019 at 03:49:14PM -0500, Dave Anderson wrote:
> Yeah, I've been watching the thread, and the document looks fine to me.
> It's just that when I saw the discussion of this one being removed that
> I felt the need to respond... ;-)
Good. :-)
Ok, I've amended the init_uts_ns.name.r
On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote:
> No. It needs *both* the vmlinux file and the vmcore file in order to read
> kernel
> virtual memory, so just having a kernel virtual address is insufficient.
>
> So it's a chicken-and-egg situation. This particular --osrelease opt
On Mon, Jan 14, 2019 at 03:07:33PM -0500, Dave Anderson wrote:
> That's what it *does* utilize -- it takes a standalone vmcore dumpfile, and
> pulls out the OSRELEASE string from it, so that a user can determine what
> vmlinux file should be used with that vmcore for normal crash analysis.
And th
On Mon, Jan 14, 2019 at 02:36:47PM -0500, Dave Anderson wrote:
> There's no reading of the dumpfile's memory involved, and that being the case,
> the vmlinux file is not utilized. That's the whole point of the crash
> option, i.e.,
> taking a vmcore file, and trying to determine what kernel shoul
On Mon, Jan 14, 2019 at 01:58:32PM -0500, Dave Anderson wrote:
> Preferably it would be left as-is. The crash utility has a "crash
> --osrelease vmcore"
> option that only looks at the dumpfile header, and just dump the string.
> With respect
> to compressed kdumps, crash could alternatively lo
On Mon, Jan 14, 2019 at 05:48:48PM +, Kazuhito Hagio wrote:
> As for makedumpfile, it will be not impossible to remove the
> init_uts_ns.name.relase (OSRELEASE), but some fixes are needed.
> Because historically OSRELEASE has been a kind of a mandatory entry
> in vmcoreinfo from the beginning o
On Mon, Jan 14, 2019 at 01:30:30PM +0800, lijiang wrote:
> I noticed that the checkpatch was coded in Perl. But i am not familiar with
> the Perl program language, that would be beyond my ability to do this, i have
> to learn the Perl program language step by step. :-)
You could give it a try - it
On Mon, Jan 14, 2019 at 09:52:14AM +0800, lijiang wrote:
> I would like to remove this variable and post again.
No, you should remove the vmcoreinfo export too:
kernel/crash_core.c:398:VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
after making sure userspace is not using it and *then*
On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
> This document lists some variables that export to vmcoreinfo, and briefly
> describles what these variables indicate. It should be instructive for
> many people who do not know the vmcoreinfo.
>
> Suggested-by:
On Thu, Jan 10, 2019 at 08:19:43PM +0800, Lianbo Jiang wrote:
> +init_uts_ns.name.release
> +
> +
> +The version of the Linux kernel. Used to find the corresponding source
> +code from which the kernel has been built.
> +
...
> +
> +init_uts_ns
> +---
> +
> +This i
On Tue, Dec 18, 2018 at 03:31:32PM +0800, lijiang wrote:
> The printk_log is used to output human readable text, it will encapsulate
> header
> information for log_buf, such as timestamp, syslog level, etc.
Me asking those questions is supposed to hint that the explanations need
improvement. But
On Sun, Dec 16, 2018 at 09:16:17PM +0800, Lianbo Jiang wrote:
> For AMD machine with SME feature, makedumpfile tools need to know
> whether the crash kernel was encrypted or not. If SME is enabled
> in the first kernel, the crash kernel's page table(pgd/pud/pmd/pte)
> contains the memory encryption
On Sun, Dec 16, 2018 at 09:16:16PM +0800, Lianbo Jiang wrote:
> +clear_idx
> +=
> +The index that the next printk record to read after the last 'clear'
> +command. It indicates the first record after the last SYSLOG_ACTION
> +_CLEAR, like issued by 'dmesg -c'.
What is that used for by the
On Sun, Dec 16, 2018 at 09:16:16PM +0800, Lianbo Jiang wrote:
This...
> +node_online_map
> +===
> +It is a macro definition, actually it is an array node_states[N_ONLINE],
> +and it represents the set of online node in a system, one bit position
> +per node number.
> +
> +This is used
On Sun, Dec 16, 2018 at 09:16:15PM +0800, Lianbo Jiang wrote:
> This patchset did two things:
> a. add a new document for vmcoreinfo
>
> This document lists some variables that export to vmcoreinfo, and briefly
> describles what these variables indicate. It should be instructive for
> many people
On Sun, Dec 16, 2018 at 09:16:16PM +0800, Lianbo Jiang wrote:
> +
> +Common variables
> +
> +
> +init_uts_ns.name.release
> +
> +The number of OS release. Based on this version number, people can find
> +the source code for the corresponding v
On Wed, Dec 05, 2018 at 08:29:14PM +, Kazuhito Hagio wrote:
> Please note that this VMCOREINFO is generated from the information in
> the vmlinux only, not from the running kernel and /proc/kcore. So if
> we add a command to dump it from running kernel, it's not suitable.
Sure, I used a vmlinu
On Tue, Dec 04, 2018 at 05:35:09PM +0800, lijiang wrote:
> There are more people to review and improve this document together, that would
> be fine.
That's basically kernel development :)
> Generating VMCOREINFO is easy in the first kernel, for example:
> # makedumpfile -g VMCOREINFO -x vmlinux
On Tue, Dec 04, 2018 at 09:08:11AM -0800, Yu-cheng Yu wrote:
> Then we will do this very often. Why don't we create all three in the
> beginning: xfeatures_mask_all, xfeatures_mask_user, and xfeatures_mask_system?
Because the _all thing is the OR-ed product of the two and then you
don't have to u
On Mon, Nov 19, 2018 at 01:47:47PM -0800, Yu-cheng Yu wrote:
> Control-flow Enforcement (CET) MSR contents are XSAVES system states.
> To support CET, introduce XSAVES system states first.
>
> Signed-off-by: Yu-cheng Yu
> ---
> arch/x86/include/asm/fpu/internal.h | 3 +-
> arch/x86/include/asm/
d it also normalizes the
> exported variable as a standard ABI between kernel and use-space.
Yeah, I'm not sure about it being an ABI. Apparently, it is considered
too tightly coupled to the kernel for it to be an ABI.
Regardless, thanks for doing that.
> Suggested-by: Borislav Petkov
> Sign
On Mon, Nov 26, 2018 at 02:16:24PM -0800, Reinette Chatre wrote:
> Hi Babu and Borislav,
>
> Two typos seemed to have slipped through into the merged commit ...
>
> On 11/21/2018 12:28 PM, Moger, Babu wrote:
> > @@ -163,14 +163,14 @@ int parse_cbm(struct rdt_parse_data *data, struct
> > rdt_reso
On Mon, Nov 26, 2018 at 10:31:02AM -0800, Luck, Tony wrote:
> Is this talking about renaming /sys/fs/resctrl?
>
> If so NAK to that. It is ABI now. Lots of scripts depend
> on that name.
No no, that is cast in stone. The kernel source dir is called "resctrl"
now too:
arch/x86/kernel/cpu/resctrl
oc.c
|-- rdrand.c
|-- resctrl
| |-- core.c
| |-- ctrlmondata.c
| |-- internal.h
| |-- Makefile
| |-- monitor.c
| |-- pseudo_lock.c
| |-- pseudo_lock_event.h
| `-- rdtgroup.c
|-- scattered.c
|-- topology.c
|-- transmeta.c
|-- umc.c
`-- vmware.c
4 directories, 61 files
---
From: Bori
On Fri, Nov 23, 2018 at 08:28:39AM +0100, Ingo Molnar wrote:
> Ugh, violent NAK on this unreadable directory naming: 'resctrl' is an
> ugly double/triple abbreviation that nobody recognizes for what it is to
> begin with, and even the long form 'resource control' is an overly
> generic naming -
On Wed, Nov 21, 2018 at 08:28:39PM +, Moger, Babu wrote:
> Resource control feature is supported by both Intel and AMD.
> So, rename the INTEL_RDT to vendor neutral RESCTRL.
>
> Now CONFIG_RESCTRL will be used for both Intel and AMD to enable
> Resource Control support. Update the texts in con
these files.
>
> Create a new directory with the name 'resctrl' and move all the
> intel_rdt files to the new directory. This way all the resctrl
> related code resides inside one directory.
>
> Suggested-by: Borislav Petkov
> Signed-off-by: Babu Moger
> ---
.
On Fri, Nov 16, 2018 at 08:54:43PM +, Moger, Babu wrote:
> Enables QOS feature on AMD.
>From Documentation/process/submitting-patches.rst:
"Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", a
On Tue, Nov 20, 2018 at 10:59:18AM +0100, Borislav Petkov wrote:
> So I'm wondering: instead of having mba_wrmsr_intel() and
> mba_wrmsr_amd() and adding those per-vendor initialization functions,
> why don't you push down the vendor differentiation into mba_wrmsr()?
>
>
On Fri, Nov 16, 2018 at 08:54:32PM +, Moger, Babu wrote:
> Initialize the resource functions that are different between the
> vendors. Some features are initialized differently between the vendors.
> Add _intel suffix to Intel specific functions.
>
> For example, MBA feature varies significant
On Fri, Nov 16, 2018 at 08:54:30PM +, Moger, Babu wrote:
> Now Resource control feature is supported by both Intel and AMD.
> Rename the INTEL_RDT to vendor neutral RESCTRL.
>
> Signed-off-by: Babu Moger
> ---
> arch/x86/Kconfig | 4 ++--
> arch/x86/include/asm/resctrl_sc
On Fri, Nov 16, 2018 at 08:54:28PM +, Moger, Babu wrote:
> diff --git a/arch/x86/kernel/cpu/resctrl_monitor.c
> b/arch/x86/kernel/cpu/resctrl_monitor.c
> index 6d654f7b0eba..9fd62263dabd 100644
> --- a/arch/x86/kernel/cpu/resctrl_monitor.c
> +++ b/arch/x86/kernel/cpu/resctrl_monitor.c
> @@ -28
On Fri, Nov 16, 2018 at 08:54:26PM +, Moger, Babu wrote:
> Separate the call sequence for rdt_quirks and MBA feature.
> This is in preparation to handle vendor differences in these
> call sequences.
>
> Signed-off-by: Babu Moger
> ---
> arch/x86/kernel/cpu/resctrl.c | 27
On Mon, Nov 19, 2018 at 08:11:36PM +, Moger, Babu wrote:
> Changed core.c and internel.h to res.c and res.h respectively. Both of
> these files are about resource definitions and initialization.
I guess but the core.c thing we do a lot in the kernel:
$ git ls-files | grep -E "/core\.c" | wc -
QOS) features.
> With more than one vendors supporting these features, it seems more
> appropriate to rename these files.
>
> Changed intel_rdt to resctrl where applicable.
>
> Signed-off-by: Babu Moger
> Reviewed-by: Borislav Petkov
> ---
> arch/x86/include/asm/{i
On Thu, Nov 15, 2018 at 01:01:17PM +0100, David Hildenbrand wrote:
> Just saying that "I'm not the first to do it, don't hit me with a stick" :)
:-)
> Indeed. And we still have without makedumpfile. I think you are aware of
> this, but I'll explain it just for consistency: PG_hwpoison
No, I appr
On Thu, Nov 15, 2018 at 01:11:02PM +0100, Michal Hocko wrote:
> I am not familiar with kexec to judge this particular patch but we
> cannot simply define any range for these pages (same as for hwpoison
> ones) because they can be almost anywhere in the available memory range.
> Then there can be co
On Thu, Nov 15, 2018 at 12:20:40PM +0100, David Hildenbrand wrote:
> Sorry to say, but that is the current practice without which
> makedumpfile would not be able to work at all. (exclude user pages,
> exclude page cache, exclude buddy pages). Let's not reinvent the wheel
> here. This is how dumpin
On Thu, Nov 15, 2018 at 02:19:23PM +0800, Dave Young wrote:
> It would be good to copy some background info from cover letter to the
> patch description so that we can get better understanding why this is
> needed now.
>
> BTW, Lianbo is working on a documentation of the vmcoreinfo exported
> fiel
On Wed, Nov 14, 2018 at 12:19:42PM -0800, Yu-cheng Yu wrote:
> Yes, I was not sure if the addition should follow the existing style (which
> does
> not have identifier names). What do you think is right?
Yeah, we've converted them all now to named params:
https://git.kernel.org/tip/8e1599fcac2e
On Fri, Nov 09, 2018 at 08:52:29PM +, Moger, Babu wrote:
> Separate the call sequence for rdt_quirks and MBA feature.
> This is in preparation to handle vendor differences in these
> call sequences.
>
> Signed-off-by: Babu Moger
> ---
> arch/x86/kernel/cpu/resctrl.c | 29
That subject needs a verb:
Subject: [PATCH v5 06/27] x86/cet: Add control protection exception handler
On Thu, Oct 11, 2018 at 08:15:02AM -0700, Yu-cheng Yu wrote:
> A control protection exception is triggered when a control flow transfer
> attempt violated shadow stack or indirect branch trackin
On Tue, Nov 13, 2018 at 09:35:40PM +, Yu, Fenghua wrote:
> Is "x86/resctrl" a better subject prefix?
Doh, of course. Diffstat is all arch/x86/.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Thu, Oct 11, 2018 at 08:15:01AM -0700, Yu-cheng Yu wrote:
> Explain how CET works and the no_cet_shstk/no_cet_ibt kernel
> parameters.
>
> Signed-off-by: Yu-cheng Yu
> ---
> .../admin-guide/kernel-parameters.txt | 6 +
> Documentation/index.rst | 1 +
> Docum
On Mon, Nov 12, 2018 at 07:25:02PM +, Moger, Babu wrote:
> >> @@ -637,10 +637,11 @@ int rdt_get_mon_l3_config(struct rdt_resource *r)
> >> *
> >> * For a 35MB LLC and 56 RMIDs, this is ~1.8% of the LLC.
> >> */
> >> - intel_cqm_threshold = boot_cpu_data.x86_cache_size * 1024 / r->n
>num_rmid;
No need to break that line here.
With that addressed and FWIW:
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
rdt_monitor.c => resctrl_monitor.c} (99%)
> rename arch/x86/kernel/cpu/{intel_rdt_pseudo_lock.c =>
> resctrl_pseudo_lock.c} (99%)
> rename arch/x86/kernel/cpu/{intel_rdt_pseudo_lock_event.h =>
> resctrl_pseudo_lock_event.h} (95%)
> rename arch/x86/kernel/cpu/{intel_rdt_rdtg
On Thu, Nov 08, 2018 at 12:40:02PM -0800, Yu-cheng Yu wrote:
> In fpu_init_system_xstate(), we test and clear features that are not enabled.
> There we depend on the order of these elements. This is the tenth "unknown
> xstate feature".
Aha, those are *reserved* bits - not unused, in XCR0.
Do an
On Thu, Oct 11, 2018 at 08:15:00AM -0700, Yu-cheng Yu wrote:
> Intel Control-flow Enforcement Technology (CET) introduces the
> following MSRs into the XSAVES system states.
>
> IA32_U_CET (user-mode CET settings),
> IA32_PL3_SSP (user-mode shadow stack),
> IA32_PL0_SSP (kernel-mode sh
On Thu, Oct 18, 2018 at 11:31:25AM +0200, Pavel Machek wrote:
> We want readable sources, not neat ascii art everywhere.
And we want pink ponies.
Reverse xmas tree order is and has been the usual variable sorting in
the tip tree for years.
--
Regards/Gruss,
Boris.
Good mailing practices fo
On Wed, Oct 17, 2018 at 04:17:01PM -0700, Randy Dunlap wrote:
> I asked what I really wanted to know.
Then the answer is a bit better readability, I'd guess.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed, Oct 17, 2018 at 03:39:47PM -0700, Randy Dunlap wrote:
> Would you mind explaining this request? (requirement?)
> Other than to say that it is the preference of some maintainers,
> please say Why it is preferred.
>
> and since the s above won't typically be the same length,
> it's not for v
On Thu, Oct 11, 2018 at 08:14:59AM -0700, Yu-cheng Yu wrote:
> Control Flow Enforcement (CET) MSRs are XSAVES system states.
That sentence needs massaging. MSRs are system states?!?!
> To support CET, we introduce XSAVES system states first.
Pls drop the "we" in all commit messages and convert t
On Thu, Oct 11, 2018 at 08:14:58AM -0700, Yu-cheng Yu wrote:
> Control Flow Enforcement (CET) MSRs are XSAVES system/supervisor
> states. To support CET, we introduce XSAVES system states first.
>
> XSAVES is a "supervisor" instruction and, comparing to XSAVE, saves
> additional "supervisor" stat
> #define X86_FEATURE_SPEC_CTRL(18*32+26) /* "" Speculation
> Control (IBRS + IBPB) */
> #define X86_FEATURE_INTEL_STIBP (18*32+27) /* "" Single Thread
> Indirect Branch Predictors */
> #define X86_FEATURE_FLUSH_L1D
On Fri, Sep 21, 2018 at 08:03:27AM -0700, Yu-cheng Yu wrote:
> XSAVES saves both system and user states. The Linux kernel
> currently does not save/restore any system states. This patch
> creates the framework for supporting system states.
... and needs a lot more text explaining *why* it is doi
On Tue, Oct 02, 2018 at 09:30:52AM -0700, Dave Hansen wrote:
> > Good point. However, "system" is more indicative; CET states are per-task
> > and
> > not "Supervisor". Do we want to go back to "Supervisor" or add comments?
>
> This is one of those things where the SDM language does not match w
On Fri, Sep 21, 2018 at 08:03:26AM -0700, Yu-cheng Yu wrote:
> To support XSAVES system states, change some names to distinguish
> user and system states.
I don't understand what the logic here is. SDM says:
XSAVES—Save Processor Extended States Supervisor
the stress being on "Supervisor" - why
On Fri, Sep 21, 2018 at 08:03:25AM -0700, Yu-cheng Yu wrote:
> Add CPUIDs for Control-flow Enforcement Technology (CET).
>
> CPUID.(EAX=7,ECX=0):ECX[bit 7] Shadow stack
> CPUID.(EAX=7,ECX=0):EDX[bit 20] Indirect branch tracking
>
> Signed-off-by: Yu-cheng Yu
> ---
> arch/x86/include/asm/cpufeat
elevant code) that the patch is appropriate for
> inclusion into the kernel.
Having a second or third author and specifying that fact keeps popping
up during review and people keep screwing up the SOB chains, trying to
express that. So yes, it is a good idea to have a special tag for this.
A
On Tue, Oct 03, 2017 at 03:13:23PM -0600, Jonathan Corbet wrote:
> Man that's a lot of work...much easier to just whine about it on the
> mailing lists...:)
You could've just said "nah, you do it" :)
> (Yes, I tweaked it, thanks).
Thanks!
--
Regards/Gruss,
Boris.
Good mailing practices fo
On Tue, Oct 03, 2017 at 02:39:17PM -0600, Jonathan Corbet wrote:
> So I hate to be fussy. (OK, perhaps I like it, but I'll act reluctant
> anyway...:) If it's an integer value, how can it be null? Can we say "a
> non-zero value" instead?
non-zero yap, I was looking for that version but somehow
From: Borislav Petkov
It should say what that range is and what that integer value
means. I had to look at the code...
Signed-off-by: Borislav Petkov
Cc: Jonathan Corbet
Cc: linux-doc@vger.kernel.org
---
Documentation/admin-guide/kernel-parameters.txt | 6 ++
1 file changed, 6
On Thu, Sep 14, 2017 at 04:41:39PM +0800, Quan Xu wrote:
> > > On Tue, Aug 29, 2017 at 11:46:37AM +, Yang Zhang wrote:
> > > > Add poll in do_idle. For UP VM, if there are running task, it will not
> > > > goes into idle path, so we only enable poll in SMP VM.
> > > >
> > > > Signed-off-by: Ya
Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: Peter Zijlstra
> Cc: Borislav Petkov
> Cc: Kyle Huey
> Cc: Andy Lutomirski
> Cc: Len Brown
> Cc: linux-ker...@vger.kernel.org
> ---
> arch/x86/kernel/process.c | 7 +++
> k
On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote:
> > If I make the scattered feature support conditional on CONFIG_X86_64
> > (based on comment below) then cpu_has() will always be false unless
> > CONFIG_X86_64 is enabled. So this won't need to be wrapped by the
> > #ifdef.
>
> If you
On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote:
> Normally the __p4d() macro would be used and that would be ok whether
> CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the
> paravirt ops path I have to use native_make_p4d().
So __p4d is in !CONFIG_PARAVIRT path.
On Fri, Jun 16, 2017 at 01:56:39PM -0500, Tom Lendacky wrote:
> Add support to check if SME has been enabled and if memory encryption
> should be activated (checking of command line option based on the
> configuration of the default state). If memory encryption is to be
> activated, then the encry
turned, with -1 indicating not found.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cmdline.h |2 +
> arch/x86/lib/cmdline.c | 105
>
> 2 files changed, 107 insertions(+)
Reviewed-by: Borislav Petkov
--
On Fri, Jun 16, 2017 at 01:56:19PM -0500, Tom Lendacky wrote:
> Add the support to encrypt the kernel in-place. This is done by creating
> new page mappings for the kernel - a decrypted write-protected mapping
> and an encrypted mapping. The kernel is encrypted by copying it through
> a temporary b
io.h |3 +++
> arch/x86/mm/ioremap.c | 18 +-
> arch/x86/mm/pat.c |3 +++
> 3 files changed, 15 insertions(+), 9 deletions(-)
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
ities(void)
> setup_clear_cpu_cap(X86_FEATURE_MTRR);
> setup_clear_cpu_cap(X86_FEATURE_ACC);
> setup_clear_cpu_cap(X86_FEATURE_X2APIC);
> + setup_clear_cpu_cap(X86_FEATURE_SME);
>
> if (!xen_initial_domain())
> setup_clear_cpu_cap(X86_FEAT
void *vaddr, unsigned int pages,
gfp_t gfp) { return 0; }
static inline void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages) {
}
Other than that:
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
-
1 - 100 of 313 matches
Mail list logo
