On Wed, Sep 04, 2024 at 09:44:29AM -0700, Josh Poimboeuf wrote:
> Not that I know of, since the compiler usually doesn't have visibility
> to these sections.
>
> It might be possible to specify "entsize" in the .pushsection flags,
> which is an ELF section header attribute which objtool could read
On Tue, Sep 03, 2024 at 09:28:29PM -0700, Josh Poimboeuf wrote:
> Take a more generic approach: for the "array of structs" style sections,
> annotate each struct entry with a symbol containing the entry. This
> makes it easy for tooling to parse the data and avoids the fragility of
> hardcoding se
On Tue, Jul 09, 2024 at 01:27:25AM -0500, Naik, Avadhut wrote:
> IIUC, its an abbreviation of a Latin word and is used as a synonym for
> "namely"
> or "that is to say".
> Might not be the best choice in this case. Will change it.
I learn new stuff every day:
https://en.wikipedia.org/wiki/Viz.
On Wed, Jun 26, 2024 at 01:00:30PM -0500, Naik, Avadhut wrote:
> >
> > Why are you clearing it if you're overwriting it immediately?
> >
> Since its a local variable, wanted to ensure that the memory is zeroed out to
> prevent
> any issues with the %s specifier, used later on.
What issues?
> W
On Wed, Jun 26, 2024 at 12:24:20PM -0500, Naik, Avadhut wrote:
>
>
> On 6/26/2024 06:10, Borislav Petkov wrote:
> > On Tue, Jun 25, 2024 at 02:56:22PM -0500, Avadhut Naik wrote:
> >> AMD's Scalable MCA systems viz. Genoa will include two new registers:
> >
>
On Wed, Jun 26, 2024 at 05:11:29PM +, Luck, Tony wrote:
> > Tony, any comments? You ok with this, would that fit any Intel-specific
> > vendor
> > fields too or do you need some additional Intel-specific changes?
>
> It looks easy enough to add any Intel specific bits to the union later.
>
>
On Tue, Jun 25, 2024 at 02:56:24PM -0500, Avadhut Naik wrote:
> From: Yazen Ghannam
>
> A new "FRU Text in MCA" feature is defined where the Field Replaceable
> Unit (FRU) Text for a device is represented by a string in the new
> MCA_SYND1 and MCA_SYND2 registers. This feature is supported per MC
On Tue, Jun 25, 2024 at 02:56:23PM -0500, Avadhut Naik wrote:
> From: Yazen Ghannam
>
> ACPI Boot Error Record Table (BERT) is being used by the kernel to
> report errors that occurred in a previous boot. On some modern AMD
> systems, these very errors within the BERT are reported through the
> x
On Tue, Jun 25, 2024 at 02:56:22PM -0500, Avadhut Naik wrote:
> AMD's Scalable MCA systems viz. Genoa will include two new registers:
"viz."?
Not a lot of people outside of AMD know what Genoa is. Zen4 is probably a lot
more widespread.
> MCA_SYND1 and MCA_SYND2.
>
> These registers will includ
cord tracepoint.
>
> Furthermore, new internal kernel fields can be added to the wrapper
> struct without impacting the user space API.
>
> Note: Some Checkpatch checks have been ignored to maintain coding style.
>
> [Yazen: Add last commit message paragraph.]
>
>
On Tue, Jun 25, 2024 at 07:45:50AM -0700, Alexey Makhalov wrote:
> My test environment was screwed up during the last version of the patchset.
> I was using a kernel which was built previously and didn't pay attention to
> commit hash suffix in `uname -r`.
> Human mistake, apologize for that.
Ok,
On Tue, Jun 25, 2024 at 01:33:48AM -0700, Alexey Makhalov wrote:
> Caller of vmware_hypercall_slow() can pass NULL into *out1,
> *out2,... *out5. It will lead to a NULL pointer dereference.
>
> Check a pointer for NULL before assigning a value.
I queue your patches and *now* you find this?!
How
On Thu, May 30, 2024 at 04:16:16PM -0500, Avadhut Naik wrote:
> arch/x86/include/asm/mce.h | 20 ++-
> arch/x86/kernel/cpu/mce/apei.c | 111 ++
> arch/x86/kernel/cpu/mce/core.c | 191 ++--
> arch/x86/kernel/cpu/mce/dev-mcelog.c|
On Thu, Mar 28, 2024 at 01:17:43AM -0500, Naik, Avadhut wrote:
> SOCKET -> Socket
> PROCESSOR -> Processor
> MICROCODE -> Microcode
SOCKET -> socket
PROCESSOR -> processor
MICROCODE -> microcode
And yeah, the acronyms need to obviously stay in all caps.
Thx.
--
Regards/Gruss,
Boris.
https
On Wed, Mar 27, 2024 at 03:31:01PM -0700, Sohil Mehta wrote:
> On 3/27/2024 1:54 PM, Avadhut Naik wrote:
>
> > - TP_printk("CPU: %d, MCGc/s: %llx/%llx, MC%d: %016Lx, IPID: %016Lx,
> > ADDR/MISC/SYND: %016Lx/%016Lx/%016Lx, RIP: %02x:<%016Lx>, TSC: %llx, PPIN:
> > %llx, PROCESSOR: %u:%x, TIME: %
On Mon, Mar 25, 2024 at 03:12:14PM -0500, Naik, Avadhut wrote:
> Can this patchset be merged in? Or would you prefer me sending out
> another revision with Steven's "Reviewed-by:" tag?
First of all, please do not top-post.
Then, you were on Cc on the previous thread. Please summarize from it
and
; someone to search for exactly where the bug happened.
>
> Reported-by: Borislav Petkov
> Signed-off-by: Steven Rostedt (Google)
> ---
> include/linux/tracepoint.h | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Tested-by: Borislav Petkov (AMD)
meani
On Fri, Jan 26, 2024 at 10:01:29PM +, Luck, Tony wrote:
> PPIN: Nice to have. People that send stuff to me are terrible about
> providing surrounding details. The record already includes
> CPUID(1).EAX ... so I can at least skip the step of asking them which
> CPU family/model/stepping they wer
On Fri, Jan 26, 2024 at 08:49:03PM +, Luck, Tony wrote:
> Every patch that adds new code or data structures adds to the kernel
> memory footprint. Each should be considered on its merits. The basic
> question being:
>
>"Is the new functionality worth the cost?"
>
> Where does it end? It w
On Fri, Jan 26, 2024 at 07:15:50PM +, Luck, Tony wrote:
> If deployment of a microcode update across a fleet always went
> flawlessly, life would be simpler. But things can fail. And maybe the
> failure wasn't noticed. Perhaps a node was rebooting when the sysadmin
> pushed the update to the fl
On Fri, Jan 26, 2024 at 05:10:20PM +, Luck, Tony wrote:
> 12 extra bytes divided by (say) 64GB (a very small server these days, may
> laptop has that much)
>= 0.0001746%
>
> We will need 57000 changes like this one before we get to 0.001% :-)
You're forgetting that those 12 bytes rep
On Thu, Jan 25, 2024 at 07:19:22PM +, Luck, Tony wrote:
> 8 bytes for PPIN, 4 more for microcode.
I know, nothing leads to bloat like 0.01% here, 0.001% there...
> Number of recoverable machine checks per system I hope the
> monthly rate should be countable on my fingers...
That's not t
On Thu, Jan 25, 2024 at 12:48:55PM -0600, Avadhut Naik wrote:
> This patchset updates the mce_record tracepoint so that the recently added
> fields of struct mce are exported through it to userspace.
>
> The first patch adds PPIN (Protected Processor Inventory Number) field to
> the tracepoint.
>
On Wed, Jan 24, 2024 at 09:09:08AM -0500, Steven Rostedt wrote:
> I don't think that's a worry anymore. The offsets can change based on
> kernel config. PowerTop needed to have the library ported to it because
> it use to hardcode the offsets but then it broke when running the 32bit
> version on a
On Tue, Jan 23, 2024 at 08:38:53PM -0500, Steven Rostedt wrote:
> Yes, rasdaemon uses libtraceevent (or a copy of it internally) that
> reads the format file to find fields. You can safely add fields to the
> middle of the event structure and the parsing will be just fine.
Should we worry about to
On Fri, Dec 08, 2023 at 12:53:47PM +0100, Juergen Gross wrote:
> Took me a while to find it. Patch 5 was repairing the issue again
Can't have that. Any patch in any set must build and boot successfully
for bisection reasons.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-abou
On Mon, Oct 30, 2023 at 03:25:07PM +0100, Juergen Gross wrote:
> Instead of stacking alternative and paravirt patching, use the new
> ALT_FLAG_CALL flag to switch those mixed calls to pure alternative
> handling.
>
> This eliminates the need to be careful regarding the sequence of
> alternative an
On Mon, Oct 30, 2023 at 03:25:06PM +0100, Juergen Gross wrote:
> Introduce the macro ALT_NOT_XEN as a short form of
> ALT_NOT(X86_FEATURE_XENPV).
Not crazy about adding yet another macro indirection - at least with the
X86_FEATURE_ it is clear what this is. But ok, whatever.
Anyway, this patch ca
On Tue, Apr 20, 2021 at 09:08:26PM +0200, Paolo Bonzini wrote:
> Yup, for now it's all at kvm/queue and it will land in kvm/next tomorrow
> (hopefully). The guest interface patches in KVM are very near the top.
Thx, I'll have a look tomorrow.
--
Regards/Gruss,
Boris.
https://people.kernel.
On Mon, Apr 19, 2021 at 04:05:12PM +0800, Steven Zhou wrote:
> Do you have any other suggestion about the link location please ?
Yeah, I'm working on it. We need to come up with a proper solution for
all those docs but it'll take time...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.
Hey Paolo,
On Tue, Apr 20, 2021 at 01:11:31PM +0200, Paolo Bonzini wrote:
> I have queued patches 1-6.
>
> For patches 8 and 10 I will post my own version based on my review and
> feedback.
can you pls push that tree up to here to a branch somewhere so that ...
> For guest patches, please repo
On Tue, Apr 20, 2021 at 09:15:41PM +0800, Chen Yu wrote:
> This patch was sent to Len and it is not in public repo yet.
If that thing were in a public repo, you'd have the advantage of
pointing people to it and they could be testing patches.
--
Regards/Gruss,
Boris.
SUSE Software Solutions
On Wed, Mar 24, 2021 at 12:04:11PM -0500, Brijesh Singh wrote:
Btw, for all your patches where the subject prefix is only "x86:":
The tip tree preferred format for patch subject prefixes is
'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:',
'genirq/core:'. Please do not use fi
On Tue, Apr 20, 2021 at 07:46:26AM +, HORIGUCHI NAOYA(堀口 直也) wrote:
> If you have any other suggestion, please let me know.
Looks almost ok...
> From: Tony Luck
> Date: Tue, 20 Apr 2021 16:42:01 +0900
> Subject: [PATCH 1/3] mm/memory-failure: Use a mutex to avoid memory_failure()
> races
>
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 R
On Mon, Apr 19, 2021 at 12:46:53PM -0500, Brijesh Singh wrote:
> - KVM calls alloc_page() to allocate a VMSA page. The allocator returns
> 0xc820 (PFN 0x200, page-level=2M). The VMSA page is private
> page so KVM will call RMPUPDATE to add the page as a private page in the
> RMP table.
MD
> systems")
> Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost
> frequencies")
>
> Reported-by: Jason Bagavatsingham
> Tested-by: Jason Bagavatsingham
> Signed-off-by: Huang Rui
> Cc: Alex Deucher
> Cc: Nathan Fontenot
On Tue, Apr 20, 2021 at 10:03:36AM +0800, Chen Yu wrote:
> On Mon, Apr 19, 2021 at 02:58:12PM -0500, Terry Bowman wrote:
> > Turbostat fails to correctly collect and display RAPL summary information
> > on Family 17h and 19h AMD processors. Running turbostat on these processors
> > returns immediat
On Mon, Apr 19, 2021 at 05:33:03PM -0400, Len Brown wrote:
> For this to happen, every thread would not only have to include/link-with
> code that uses AMX, but that code would have to *run*.
It looks like either I'm not expressing myself clearly enough or you're
not reading my text: the *library*
On Mon, Apr 19, 2021 at 02:18:51PM -0400, Len Brown wrote:
> Yes, we could invent a new system call and mandate that it be called
> between #2 and #3. However, we'd still do #4 in response, so I don't
> see any value to that system call.
Lemme refresh your memory: there was a time when the kernel
On Tue, Apr 13, 2021 at 07:43:18AM +0900, Naoya Horiguchi wrote:
> From: Tony Luck
>
> There can be races when multiple CPUs consume poison from the same
> page. The first into memory_failure() atomically sets the HWPoison
> page flag and begins hunting for tasks that map this page. Eventually
>
On Mon, Apr 19, 2021 at 10:25:01AM -0500, Brijesh Singh wrote:
> To my understanding, we don't group 512 4K entries into a 2M for the
> kernel address range. We do this for the userspace address through
> khugepage daemon. If page tables get out of sync then it will cause an
> RMP violation, the Pa
On Fri, Apr 16, 2021 at 06:05:10PM -0400, Len Brown wrote:
> I'm not aware of any intent to transparently use AMX for bcopy, like
> what happened
> with AVX-512. (didn't they undo that mistake?)
No clue, did they?
> Tasks are created without an 8KB AMX buffer.
> Tasks have to actually touch the
On Wed, Mar 24, 2021 at 12:04:10PM -0500, Brijesh Singh wrote:
> A write from the hypervisor goes through the RMP checks. When the
> hypervisor writes to pages, hardware checks to ensures that the assigned
> bit in the RMP is zero (i.e page is shared). If the page table entry that
> gives the sPA i
elf header region */
326 start = image->arch.elf_load_addr;
(gdb)
Make sure the ranges array becomes a single element allocated.
[ bp: Write a proper commit message. ]
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Mike Galb
On Sun, Apr 18, 2021 at 09:29:46AM -0700, Liang Zhou wrote:
> This patch fixes the invalid vt-d spec location.
Avoid having "This patch" or "This commit" in the commit message. It is
tautologically useless.
Also, do
$ git grep 'This patch' Documentation/process
for more details.
> Signed-off-b
.kernel.org/tip/9f8614f5567eb4e38579422d38a1bdfeeb648ffc
> Author:Jean-Philippe Brucker
> AuthorDate:Wed, 14 Apr 2021 10:26:34 +02:00
> Committer: Borislav Petkov
> CommitterDate: Thu, 15 Apr 2021 10:27:29 +02:00
>
> x86/dma: Tear down DMA ops on driver unbind
>
> Since
>
>
On Sat, Apr 17, 2021 at 02:47:46PM +0800, kernel test robot wrote:
>kernel/sched/topology.c: In function 'sched_debug_setup':
> >> kernel/sched/topology.c:17:2: error: 'sched_debug_verbose' undeclared
> >> (first use in this function); did you mean 'sched_debug_setup'?
> 17 | sched_debu
On Fri, Apr 16, 2021 at 03:06:17PM -0700, Andy Lutomirski wrote:
> On Fri, Apr 16, 2021 at 3:03 PM Borislav Petkov wrote:
> >
> > On Fri, Apr 16, 2021 at 02:49:23PM -0700, Sami Tolvanen wrote:
> > > __nocfi only disables CFI checking in a function, the compiler stil
On Fri, Apr 16, 2021 at 02:49:23PM -0700, Sami Tolvanen wrote:
> __nocfi only disables CFI checking in a function, the compiler still
> changes function addresses to point to the CFI jump table, which is
> why we need function_nocfi().
So call it __func_addr() or get_function_addr() or so, so that
On Fri, Apr 16, 2021 at 01:38:34PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler replaces function addresses in
> instrumented C code with jump table addresses. This change implements
> the function_nocfi() macro, which returns the actual function address
> instead.
>
> Signed-
On Fri, Apr 16, 2021 at 06:40:55PM +0300, Kirill A. Shutemov wrote:
> Provide basic helpers, KVM_FEATURE, CPUID flag and a hypercall.
>
> Host side doesn't provide the feature yet, so it is a dead code for now.
>
> Signed-off-by: Kirill A. Shutemov
> ---
> arch/x86/include/asm/cpufeatures.h |
On Fri, Apr 16, 2021 at 03:16:07PM +0200, Mike Galbraith wrote:
> On Fri, 2021-04-16 at 14:16 +0200, Borislav Petkov wrote:
> >
> > Please be more verbose and structure your commit message like this:
>
> Hrmph, I thought it was too verbose for dinky one-liner if anything.
On Fri, Apr 16, 2021 at 02:02:07PM +0200, Mike Galbraith wrote:
> [ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
> crash_setup_memmap_entries+0x17e/0x3a0
> [ 15.428018] Write of size 8 at addr c9426008 by task kexec/1187
>
> (gdb) list *crash_setup_memmap_entries+0x17e
> 0x
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: df448cdfc01ffc117702a494ef302e7fb76df78a
Gitweb:
https://git.kernel.org/tip/df448cdfc01ffc117702a494ef302e7fb76df78a
Author:Borislav Petkov
AuthorDate:Mon, 12 Apr 2021 10:59:51 +02:00
On Thu, Apr 15, 2021 at 01:08:09PM -0500, Brijesh Singh wrote:
> This is from Family 19h Model 01h Rev B01. The processor which
> introduces the SNP feature. Yes, I have already upload the PPR on the BZ.
>
> The PPR is also available at AMD: https://www.amd.com/en/support/tech-docs
Please add the
On Wed, Mar 24, 2021 at 12:04:09PM -0500, Brijesh Singh wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 06394b6d56b2..7a0138cb3e17 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -644,3 +644,44 @@ rmpentry_t *lookup_page_in_rmptabl
On Wed, Mar 24, 2021 at 12:04:08PM -0500, Brijesh Singh wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
Also, why is all this SNP stuff landing in this file instead of in sev.c
or so which is AMD-specific?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/n
On Wed, Mar 24, 2021 at 12:04:08PM -0500, Brijesh Singh wrote:
> The lookup_page_in_rmptable() can be used by the host to read the RMP
> entry for a given page. The RMP entry format is documented in PPR
> section 2.1.5.2.
I see
Table 15-36. Fields of an RMP Entry
in the APM.
Which PPR do you me
On Tue, Apr 13, 2021 at 03:02:21PM -0600, Jonathan Corbet wrote:
> For future installments, could you send them in their own thread as an
> ordinary patch so I don't need to edit in the changelog after applying
> them?
Ok, sure but I might not need to anymore because, AFAICT, what is left
is reall
On Thu, Apr 15, 2021 at 07:29:38AM +0200, Willy Tarreau wrote:
> What Len is saying is that not being interested in a feature is not an
> argument for rejecting its adoption,
Oh, I'm not rejecting its adoption - no, don't mean that.
> which I'm perfectly fine with. But conversely not being intere
On Wed, Apr 14, 2021 at 05:57:22PM -0400, Len Brown wrote:
> I'm pretty sure that the "it isn't my use case of interest, so it
> doesn't matter" line of reasoning has long been established as -EINVAL
> ;-)
I have only a very faint idea what you're trying to say here. Please
explain properly and mo
On Wed, Apr 14, 2021 at 07:46:49AM -0700, Jue Wang wrote:
> I can see this is useful in other types of domains, e.g., on multi-tenant
> cloud
> servers where many VMs are collocated on the same host,
> with proper recovery + live migration, a single MCE would only affect a single
> VM at most.
>
On Tue, Apr 13, 2021 at 10:47:21PM -0700, Jue Wang wrote:
> This path is when EPT #PF finds accesses to a hwpoisoned page and
> sends SIGBUS to user space (KVM exits into user space) with the same
> semantic as if regular #PF found access to a hwpoisoned page.
>
> The KVM_X86_SET_MCE ioctl actuall
On Tue, Apr 13, 2021 at 04:13:03PM +, Luck, Tony wrote:
> Even if no applications ever do anything with it, it is still useful to avoid
> crashing the whole system and just terminate one application/guest.
True.
> There's one more item on my long term TODO list. Add fixups so that
> copy_to_u
On Wed, Apr 14, 2021 at 01:30:43PM +0200, Florian Weimer wrote:
> Is this discussion about better behavior (at least diagnostics) for
> existing applications, without any code changes? Or an alternative
> programming model?
Former.
> Does noavx512 acutally reduce the XSAVE size to AVX2 levels?
On Mon, Apr 12, 2021 at 10:30:23PM +, Bae, Chang Seok wrote:
> On Mar 26, 2021, at 03:30, Borislav Petkov wrote:
> > On Thu, Mar 25, 2021 at 09:56:53PM -0700, Andy Lutomirski wrote:
> >> We really ought to have a SIGSIGFAIL signal that's sent, double-fault
> >&g
On Wed, Apr 14, 2021 at 12:06:39PM +0200, Willy Tarreau wrote:
> And change jobs :-)
I think by the time that happens, we'll be ready to go to the eternal
vacation. Which means: not my problem.
:-)))
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Apr 13, 2021 at 03:51:50PM -0400, Len Brown wrote:
> AMX does the type of matrix multiplication that AI algorithms use. In
> the unlikely event that you or one of the libraries you call are doing
> the same, then you will be very happy with AMX. Otherwise, you'll
> probably not use it.
Whi
On Wed, Mar 24, 2021 at 12:04:07PM -0500, Brijesh Singh wrote:
> @@ -538,6 +540,10 @@
> #define MSR_K8_SYSCFG0xc0010010
> #define MSR_K8_SYSCFG_MEM_ENCRYPT_BIT23
> #define MSR_K8_SYSCFG_MEM_ENCRYPTBIT_ULL(MSR_K8_SYSCFG_MEM_ENCRYPT_BIT)
> +#define MSR_K8_SYSCFG
On Wed, Apr 14, 2021 at 07:39:25AM +0100, Christoph Hellwig wrote:
> On Mon, Apr 12, 2021 at 11:03:46AM +0200, Borislav Petkov wrote:
> > IDE/ATAPI DRIVERS
> > -M: Borislav Petkov
> > L: linux-...@vger.kernel.org
> > S: Maintained
> > F: Documentation/cdr
On Tue, Apr 13, 2021 at 09:58:01PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -27.4% regression of stress-ng.msg.ops_per_sec due to
> commit:
>
>
> commit: 9223d0dccb8f8523754122f68316dd1a4f39f7f8 ("thermal: Move therm_throt
> there from x86/mce")
> https://git.kernel.or
On Tue, Apr 13, 2021 at 08:54:55PM +0800, Kemeng Shi wrote:
> Yes. And NT stores should be better for copy_page especially copying a lot
> of pages as only partial memory of copied page will be access recently.
I thought "should be better" too last time when I measured rep; movs vs
NT stores but a
Hi Jon,
here's the next piece of documentation which should be generic enough.
Thx.
---
From: Borislav Petkov
Date: Tue, 13 Apr 2021 13:26:29 +0200
Explain when a submitter should tag a patch or a patch series with the
"RESEND" tag.
This has been partially carved out from
+ linux-nvdimm
Original mail at
https://lkml.kernel.org/r/3f28adee-8214-fa8e-b368-eaf8b1934...@huawei.com
On Tue, Apr 13, 2021 at 02:25:58PM +0800, Kemeng Shi wrote:
> I'm using AEP with dax_kmem drvier, and AEP is export as a NUMA node in
What is AEP?
> my system. I will move cold pages from
On Thu, Apr 08, 2021 at 10:08:52AM -0700, Luck, Tony wrote:
> Also not clear to me either ... but sending a SIGBUS to a kthread isn't
> going to do anything useful. So avoiding doing that is another worthy
> goal.
Ack.
> With these patches nothing gets killed when kernel touches user poison.
> If
On Mon, Apr 12, 2021 at 03:09:41PM -0700, Randy Dunlap wrote:
>
> [ 27.075563] msr: Write to unrecognized MSR 0x1b0 by x86_energy_perf (pid:
> 1223).
> [ 27.078979] msr: See
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/about for details.
>
> (aka x86_energy_perf_policy)
>
On Mon, Apr 12, 2021 at 04:38:15PM +0200, Florian Weimer wrote:
> Yes, that's why we have the XGETBV handshake. I was imprecise. It's
> CPUID + XGETBV of course. Or even AT_HWCAP2 (for FSGSBASE).
Ok, that sounds better. So looking at glibc sources, I see something
like this:
init_cpu_features
On Mon, Apr 12, 2021 at 04:19:29PM +0200, Florian Weimer wrote:
> Maybe we could have done this in 2016 when I reported this for the first
> time. Now it is too late, as more and more software is using
> CPUID-based detection for AVX-512.
So as I said on another mail today, I don't think a librar
On Mon, Apr 12, 2021 at 07:55:01AM -0500, Brijesh Singh wrote:
> The cur_entry is updated by the hypervisor. While building the psc
> buffer the guest sets the cur_entry=0 and the end_entry point to the
> last valid entry. The cur_entry is incremented by the hypervisor after
> it successfully proce
On Sun, Apr 11, 2021 at 03:07:29PM -0400, Len Brown wrote:
> If it is the program, how does it know that the library wants to use
> what instructions?
>
> If it is the library, then you have just changed XCR0 at run-time and
> you expose breakage of the thread library that has computed XSAVE size.
On Wed, Mar 24, 2021 at 11:44:24AM -0500, Brijesh Singh wrote:
> @@ -161,3 +162,108 @@ void __init early_snp_set_memory_shared(unsigned long
> vaddr, unsigned long paddr
>/* Ask hypervisor to make the memory shared in the RMP table. */
> early_snp_set_page_state(paddr, npages, SNP_PA
On Sun, Apr 11, 2021 at 04:21:21PM -0700, Andy Lutomirski wrote:
> https://bugs.winehq.org/show_bug.cgi?id=33275#c19
>
> I sure hope no one is still doing this.
Aha, IRET with rFLAGS.NT set. At least it is only an ad-hoc program to
fix this particular issue and I hope too it hasn't propagated som
From: Borislav Petkov
It has been years since I've touched this and "this" is going away
anyway... any day now. :-)
So remove me so that I do not get CCed on bugs/patches.
Signed-off-by: Borislav Petkov
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git
On Sun, Apr 11, 2021 at 09:57:20AM -0700, Andy Lutomirski wrote:
> Working around a kernel bug. The workaround only worked on AMD
> systems. The correct solution was to fix the kernel bug, not poke
> MSRs.
Do you remember which program(s) and where I can get them to have a
look?
--
Regards/Gruss
On Sat, Apr 10, 2021 at 11:52:17AM -0700, Andi Kleen wrote:
> Have you ever seen any user programs actually write those MSRs?
> I don't see why they ever would, it's not that they have any motivation
> to do it (unlike SMM), and I don't know of any examples.
You'd be surprised how much motivation
On Sun, Apr 11, 2021 at 11:12:32AM +0200, Jan Kiszka wrote:
> The patches are coming from downstream usage, yes,
Ok, for the future, it would be good to mention that in the commit
message so that a committer knows what they're for.
> but I think the solutions are relevant cleanups for upstream as
On Sun, Apr 11, 2021 at 10:22:19AM +0200, Jan Kiszka wrote:
> On 26.10.20 18:39, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > Those are already provided by linux/io.h as stubs.
> >
> > The conflict remains invisible until someone would pull linux/io.h into
> > memtype.c.
> >
> > Signed-off-by: J
Hi Linus,
please pull two more urgent fixes (not gonna say "final" this time) from
x86-land.
Thx.
---
The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120:
Linux 5.12-rc6 (2021-04-04 14:15:36 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/s
On Sat, Apr 10, 2021 at 10:48:56PM +0800, Feng Tang wrote:
> And the bigger risk is still BIOS's writing to TSC_ADJUST MSR beneath
> kernel.
For that we need to do more persuasive work with hw guys. Needs a *lot*
of perseverance.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes
On Sat, Apr 10, 2021 at 07:51:58AM -0700, Andy Lutomirski wrote:
> Can you add STAR, CSTAR, LSTAR, SYSENTER*, SYSCALL*, and EFER please?
Sure.
---
From: Borislav Petkov
Date: Sat, 10 Apr 2021 14:08:13 +0200
There are a bunch of MSRs which luserspace has no business poking
at, whatsoever.
From: Borislav Petkov
Date: Sat, 10 Apr 2021 14:08:13 +0200
There are a bunch of MSRs which luserspace has no business poking at,
whatsoever. Add a ban list and put the TSC-related MSRs in there. Issue
a big juicy splat to catch offenders.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel
On Sat, Apr 10, 2021 at 11:27:11AM +0200, Thomas Gleixner wrote:
> On Tue, Mar 30 2021 at 16:25, Feng Tang wrote:
> > Normally the tsc_sync will be checked every time system enters idle state,
> > but there is still caveat that a system won't enter idle, either because
> > it's too busy or configur
On Fri, Apr 09, 2021 at 04:14:09PM -0700, Yu, Yu-cheng wrote:
> > @@ -53,6 +55,8 @@ static short xsave_cpuid_features[] __initdata = {
> > X86_FEATURE_INTEL_PT,
> > X86_FEATURE_PKU,
> > X86_FEATURE_ENQCMD,
> > + X86_FEATURE_CET, /* XFEATURE_CET_USER */
> > + X86_FEATURE_CET, /* XFEA
On Fri, Apr 09, 2021 at 02:45:23PM -0500, Saripalli, RK wrote:
> Yes, these options should be fine for now.
> Like you said, if we get the need to add prctl and seccomp, I can always do
> that later.
>
> What do you think auto should default to?.
> In SSBD case, I believe auto defaults to prctl
On Fri, Apr 09, 2021 at 01:22:49PM -0500, Saripalli, RK wrote:
> > And I think you don't need this one either if we do a "light" controls
> > thing but lemme look at the rest first.
Ok, and what I mean with "lite" version is something like this below
which needs finishing and testing.
Initially,
On Tue, Apr 06, 2021 at 10:50:00AM -0500, Ramakrishna Saripalli wrote:
> diff --git a/arch/x86/include/asm/cpufeatures.h
> b/arch/x86/include/asm/cpufeatures.h
> index cc96e26d69f7..21e7f8d0d7d9 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -201,
On Fri, Apr 09, 2021 at 08:52:52AM -0700, Yu, Yu-cheng wrote:
> Recall we had complicated code for the XSAVES features detection in
> xstate.c. Dave Hansen proposed the solution and then the whole thing
> becomes simple. Because of this flag, even when only the shadow stack is
> available, the co
On Wed, Mar 24, 2021 at 11:44:22AM -0500, Brijesh Singh wrote:
> + /*
> + * The ROM memory is not part of the E820 system RAM and is not
> prevalidated by the BIOS.
> + * The kernel page table maps the ROM region as encrypted memory, the
> SEV-SNP requires
> + * the all the enc
On Fri, Apr 09, 2021 at 04:36:01PM +0300, Kirill A. Shutemov wrote:
> The patchset is still in path-finding stage. I'll be more specific once we
> settle on how the feature works.
This is not why I'm asking: these feature bits are visible to userspace
in /proc/cpuinfo and if you don't have a use c
1 - 100 of 6698 matches
Mail list logo