On Thu, Nov 08, 2018 at 04:49:04PM +0100, Thomas Gleixner wrote:
> > Suppose I came along with my nifty new architecture, and it dragged in a
> > whole new set of timer and interrupt subsystems that duplicated a lot of
> > what's in the kernel now, but buried a few "local quirks" deep in the
> >
From: Borislav Petkov
Realign help text vertically and add spacing so that target help text
is properly separated.
No functional changes.
Signed-off-by: Borislav Petkov
---
arch/x86/Makefile | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git
From: Borislav Petkov
Add the targets which add Kconfig items to the .config so that the
kernel can be run as a guest, to the 'make help' output so that they
can be found easier and there's no need to grep the tree each time to
remember what they should be called.
Signed-off-by: Borislav Petkov
On Thu, Dec 17, 2020 at 09:47:07PM +0900, Masahiro Yamada wrote:
> I do not want to touch scripts/kconfig/Makefile
> every time somebody adds a new file to
> kernel/configs/*.config or arch/$(ARCH)/configs/*.config
Because that happens so often and somehow burdens your maintenance
effort
From: Borislav Petkov
Add the targets which add Kconfig items to the .config so that the
kernel can be run as a guest, to the main 'make help' output so that
they can be found easier and there's no need to grep the tree each time
to remember what they should be called.
Signed-off-by: Borislav
On Tue, Dec 15, 2020 at 02:00:58PM -0500, Rodrigo Siqueira wrote:
> Thanks for reporting this issue and test the fix.
It was my pleasure. Thanks for the quick fix!
:-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Dec 15, 2020 at 10:11:20AM -0600, Yazen Ghannam wrote:
> Can we say "Opterons (Family 10h to Family 15h)"? It may also apply to
> Family 16h, but I don't know if they were branded as Opterons.
>
> The injection code in this module doesn't apply to Family 17h and later.
>
> Also, Family
On Tue, Dec 15, 2020 at 12:04:23PM -0500, Alex Deucher wrote:
> That patch trivially backports to 5.10. See attached backported
> patch. @Borislav Petkov does the attached patch fix 5.10 for you?
Yes, thanks.
Reported-and-tested-by: Borislav Petkov
--
Regards/Gruss,
Boris.
On Tue, Dec 15, 2020 at 10:47:03AM -0500, Rodrigo Siqueira wrote:
> Hi Boris,
>
> Could you check if your branch has this commit:
>
> drm/amd/display: Fix module load hangs when connected to an eDP
>
> If so, could you try this patch:
>
> https://patchwork.freedesktop.org/series/84965/
So I
From: Borislav Petkov
There's no need for them to be in a separate file so merge them into the
main driver compilation unit like the other EDAC drivers do.
Drop now-unneeded function export, make the function static and shorten
static function names.
No functional changes.
Signed-off
From: Borislav Petkov
Merge them into the main driver and put them inside an EDAC_DEBUG
ifdeffery to simplify the driver and have all debugging/injection stuff
behind a debug build-time switch.
No functional changes.
Signed-off-by: Borislav Petkov
---
drivers/edac/Kconfig | 7
Hi Linus,
please pull two x86/build fixes for v5.11.
Thx.
---
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
X99 and BDF102
(Fenghua Yu)
- Cleanups.
--------
Borislav Petkov (1):
Merge tag 'v5.10-rc6' into x86/cache
Fenghua Yu (2):
Documentation/x86: Rename resctrl_ui.rst and add two errata to the file
x86/resctrl: Correct MBM total and local values
Rikard Falkeborn (1):
x86/resctrl
Sankar (2):
x86/boot: Remove unused finalize_identity_maps()
x86/head/64: Remove unused GET_CR2_INTO() macro
Borislav Petkov (1):
x86/setup: Remove unused MCA variables
Dan Williams (1):
x86, libnvdimm/test: Remove COPY_MC_TEST
Gabriel Krisman Bertazi (10):
perf/x86
On Mon, Dec 14, 2020 at 10:27:09PM +0900, Punit Agrawal wrote:
> IIUC, this suggests that Linux booting on anything prior to Zen3 is down
> to pure luck - I hope that wasn't the case.
WTF does this have to do with linux booting?!
> At the moment acpi thermals is bust on this and other affected
On Sat, Dec 12, 2020 at 08:36:48AM +0900, Punit Agrawal wrote:
> To me it suggests, that there are likely more systems from the family
> that show the characteristic described below.
Until we find a *single* system with a broken BIOS which has those
objects kaputt and then this heuristic would
Hi Linus,
please pull the x86/platform drivers pile for v5.11.
Thx.
---
The following changes since commit 418baf2c28f3473039f2f7377760bd8f6897ae18:
Linux 5.10-rc5 (2020-11-22 15:36:08 -0800)
are available in the Git repository at:
Hi Linus,
please pull the x86/CPU pile for v5.11. Only AMD-specific changes this time.
Thx.
---
The following changes since commit 09162bc32c880a791c6c0668ce0745cf7958f576:
Linux 5.10-rc4 (2020-11-15 16:44:31 -0800)
are available in the Git repository at:
the usual small fixes and improvements.
Andy Lutomirski (2):
selftests/x86/fsgsbase: Fix GS == 1, 2, and 3 tests
selftests/x86: Add missing .note.GNU-stack sections
Borislav Petkov (6):
tools/power/cpup
Hi Linus,
just a single robustification fix this time around.
Pls pull,
thx.
---
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
ll is used by
SGX enclaves.
All this work by Sean Christopherson, Jarkko Sakkinen and many others.
----
Borislav Petkov (1):
x86/sgx: Fix sgx_ioc_enclave_provision() kernel-doc comment
Dave Hansen (1):
x86/sgx: Clarify 'laundry_lis
Hi Linus,
this one wins the award for most boring pull request ever. But that's a
good thing - this is how I like 'em and the microcode loader *should* be
boring. :-)
Pls pull,
thx.
---
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25
.
Borislav Petkov (1):
Merge tag 'v5.10-rc6' into ras/core
Gabriele Paoloni (4):
x86/mce: Move the mce_panic() call and 'kill_it' assignments to the right
places
x86/mce: Panic for LMCE only if mca_cfg.tolerant < 3
x86/mce: Remove redundant c
in-band ECC (Qiuxu Zhuo and Tony Luck)
- The usual smattering of fixes and cleanups all over.
Borislav Petkov (3):
EDAC: Do not issue useless debug statements in the polling routine
EDAC/amd64: Fix PCI component registration
On Fri, Dec 11, 2020 at 07:55:50PM +0100, Lukas Bulwahn wrote:
> Yes, agree. Other maintainers noted that I should point out that the
> patch is only a minor clean-up and it is not urgent to be considered.
>
> So, I add this remark to make clear that it is not top priority to
> apply just that
On Mon, Dec 07, 2020 at 01:41:41PM +0100, Lukas Bulwahn wrote:
> Thomas, Ingo, Boris, please pick this minor non-urgent clean-up patch.
Why?
Isn't it obvious that when you send a patch to us, the final goal is for
it to be applied. Eventually.
--
Regards/Gruss,
Boris.
Hi,
patch in $Subject breaks booting on a laptop here, GPU details are
below. The machine stops booting right when it attempts to switch modes
during boot, to a higher mode than the default VGA one. Machine doesn't
ping and is otherwise unresponsive so that a hard reset is the only
thing that
On Mon, Dec 07, 2020 at 02:12:26PM +0800, Ying-Tsun Huang wrote:
> In mtrr_type_lookup, if the input memory address region is not in the
> MTRR, over 4GB, and not over the top of memory, write-back attribute
> is returned. These condition checks are for ensuring the input memory
> address region
On Fri, Dec 11, 2020 at 07:56:40AM +0900, Punit Agrawal wrote:
> Booting Linux on a Zen2 based processor (family: 0x17, model: 0x60,
> stepping: 0x1) shows the following message in the logs -
>
> acpi_cpufreq: overriding BIOS provided _PSD data
>
> Although commit 5368512abe08
On Tue, Dec 01, 2020 at 12:39:57PM +0100, Heiner Kallweit wrote:
> On this system the M.2 PCIe WiFi card isn't detected after reboot,
> only after cold boot. reboot=pci fixes this behavior.
> In [0] the same issue is described, although on another system and
> with another Intel WiFi card. In case
On Thu, Dec 10, 2020 at 12:19:46PM +0800, Chris Chiu wrote:
> From: Dan Nicholson
>
> The GIGABYTE BRIX BXBT-2807 always hangs with the normal acpi
> reboot.
Is that what the "hard disk crash" in the comment below, refers to?
> It works without problem after adding the parameter
> reboot=bios.
On Wed, Dec 09, 2020 at 01:22:24PM +0100, Jürgen Groß wrote:
> Lets take the spin_unlock() case. With patch 11 of the series this is
>
> PVOP_ALT_VCALLEE1(lock.queued_spin_unlock, lock,
> "movb $0, (%%" _ASM_ARG1 ");",
> X86_FEATURE_NO_PVUNLOCK);
>
> which
On Tue, Dec 08, 2020 at 11:24:16AM -0800, Yu, Yu-cheng wrote:
> Case (a) is a normal writable data page that has gone through fork(). So it
Writable?
> has W=0, D=1. But here, the software chooses not to use the D bit, and
But it has W=0. So not writable?
> instead, W=0, COW=1.
So the "new"
On Fri, Dec 11, 2020 at 12:40:46AM +0800, Xiaochen Shen wrote:
> I plan to do backporting for all -stable trees after this patch is merged
> into upstream.
Ok, you can do that when Greg sends the mails that it cannot apply to
the respective trees. Lemme queue this one to urgent now.
Thx.
--
On Wed, Dec 09, 2020 at 03:01:47PM -0300, Arnaldo Carvalho de Melo wrote:
> Trying to swap this back into my brain...
I know *exactly* what you mean. :)
>
> Humm, if I'm building this on, say, aarch64 then asm/ will not be
> pointing to x86, right? Intel PT needs the x86 instruction decoder,
>
On Thu, Dec 10, 2020 at 12:45:11PM +0800, Xiaochen Shen wrote:
> Thank you for clarifying this issue. It is not a 0-DAY CI issue.
Which begs the question: this patch should be Cc: stable and should go
in now, shouldn't it?
Because then the first submission applies cleanly ontop of
On Wed, Dec 09, 2020 at 07:06:58PM -, tip-bot2 for Xiaochen Shen wrote:
> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c
> b/arch/x86/kernel/cpu/resctrl/monitor.c
> index 622073f..93a33b7 100644
> --- a/arch/x86/kernel/cpu/resctrl/monitor.c
> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
>
On Wed, Dec 09, 2020 at 11:23:28PM +0100, Borislav Petkov wrote:
> and you should remove the chunks assignment too.
Yah, ignore that part - mbm_bw_count() does need chunks for cur_bw. Oh
well.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, Dec 09, 2020 at 07:34:16PM +, Ashish Kalra wrote:
> This should work, but i am concerned about making IO_TLB_DEFAULT_SIZE
> (which is pretty much private to generic swiotlb code) to be visible
> externally, i don't know if there are any concerns with that ?
Meh, it's just a define and
On Wed, Dec 09, 2020 at 01:19:46PM +, Ashish Kalra wrote:
> reserve_crashkernel() calls swiotlb_size_or_default() to get SWIOTLB
...
Thanks for explaining.
> There is a need to introduce an architecture specific callback
> for swiotlb_adjust() because of the following reason :
So what your
On Wed, Dec 09, 2020 at 12:29:07PM +, Ashish Kalra wrote:
> As i mentioned in the main comments above, this cannot be called in
> mem_encrypt_init() as that breaks reserve_crashkernel() which depends
> on SWIOTLB buffer size
Please elaborate how does it break.
> and is called before
On Wed, Dec 09, 2020 at 08:30:53AM +0100, Jürgen Groß wrote:
> Hey, I already suggested to use ~FEATURE for that purpose (see
> https://lore.kernel.org/lkml/f105a63d-6b51-3afb-83e0-e899ea408...@suse.com/
Great minds think alike!
:-P
> I'd rather make the syntax:
>
> ALTERNATIVE_TERNARY
>
> Subject: Re: [PATCH v8] swiotlb: Adjust SWIOTBL bounce buffer size for SEV
> guests.
Fix subject prefix to "x86, swiotlb: ... SWIOTLB ... for SEV guests
Fix typo and no fullstop at the end.
On Mon, Dec 07, 2020 at 11:10:57PM +, Ashish Kalra wrote:
> From: Ashish Kalra
>
> For SEV, all
On Wed, Dec 09, 2020 at 08:21:48AM +0900, Punit Agrawal wrote:
> According to the commit log, acd316248205 seems to be only targeted at
> powernow-K8 -
No, it is not targeted at powernow-k8 - acpi-cpufreq.c is what is used
on AMD hw. He means to make acpi-cpufreq's behavior consistent with
On Tue, Dec 08, 2020 at 06:27:39PM -0500, Konrad Rzeszutek Wilk wrote:
> That said if you have the time to take a peek at the x86 bits - that
> would be awesome!
Sure, tomorrow.
Good night. :-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Dec 08, 2020 at 05:22:20PM -0500, Konrad Rzeszutek Wilk wrote:
> I will fix it up.
So who's picking this up? If not me then I probably should have a
detailed look at the x86 bits before it goes in...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Fri, Nov 20, 2020 at 12:46:25PM +0100, Juergen Gross wrote:
> diff --git a/arch/x86/include/asm/cpufeatures.h
> b/arch/x86/include/asm/cpufeatures.h
> index dad350d42ecf..ffa23c655412 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -237,6
On Tue, Dec 08, 2020 at 10:25:15AM -0800, Yu, Yu-cheng wrote:
> > Both are "R/O + _PAGE_COW". Where's the difference? The dirty bit?
>
> The PTEs are the same for both (a) and (b), but come from different routes.
Do not be afraid to go into detail and explain to me what those routes
are please.
On Tue, Nov 10, 2020 at 08:21:53AM -0800, Yu-cheng Yu wrote:
> There is essentially no room left in the x86 hardware PTEs on some OSes
> (not Linux). That left the hardware architects looking for a way to
> represent a new memory type (shadow stack) within the existing bits.
> They chose to
r, can check some of its features
> using
> +cpuid.
s/cpuid/CPUID/g
> +ACRN Hypervisor Introduction
> +
> +
> +The ACRN Hypervisor is a Type 1 hypervisor, running directly on the
> bare-metal
s/the //
with those fixed:
Reviewed-by: Borislav
On Mon, Dec 07, 2020 at 01:24:51PM -0800, Reinette Chatre wrote:
> How about:
> "Move the setting of the CPU on which a task is running in a CPU mask into a
> couple of helpers.
>
> There is no functional change. This is a preparatory change for the fix in
> the following patch from where the
X86_FEATURE_CQM_LLC },
> { X86_FEATURE_CQM_MBM_LOCAL,X86_FEATURE_CQM_LLC },
> { X86_FEATURE_AVX512_BF16, X86_FEATURE_AVX512VL },
> + { X86_FEATURE_AVX512_FP16, X86_FEATURE_AVX512BW },
> { X86_FEATURE_ENQCMD, X86_FEATURE_
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: f77f420d34754b8d08ac6ebf094ff7193023196a
Gitweb:
https://git.kernel.org/tip/f77f420d34754b8d08ac6ebf094ff7193023196a
Author:Borislav Petkov
AuthorDate:Sat, 05 Dec 2020 01:19:45 +01:00
On Mon, Dec 07, 2020 at 11:03:27PM +, Bae, Chang Seok wrote:
> It was considered to be concise to represent, but it looks to be
> unreadable.
Not only unreadable but actively confusing - there *is* a "task" pointer
all around the kernel which we use for struct task_struct *.
> (I suspect
On Mon, Dec 07, 2020 at 10:20:20PM +, Kalra, Ashish wrote:
> It is more of an approximation of the earlier static adjustment which
> was 128M for <1G guests, 256M for 1G-4G guests and 512M for >4G
> guests.
Makes sense and it is better than nothing. Please put that explanation
over the 6%
On Mon, Dec 07, 2020 at 04:07:52PM -0600, Wei Huang wrote:
> I think we shouldn't override zen2 if _PSD is correct. In my opinion,
> there are two approaches:
>
> * Keep override_acpi_psd()
> Let us keep the original quirk and override_acpi_psd() function. Over
> the time, people may want to add
On Mon, Dec 07, 2020 at 10:06:24PM +, Ashish Kalra wrote:
> This is related to the earlier static adjustment of the SWIOTLB buffers
> as per guest memory size and Konrad's feedback on the same, as copied
> below :
>
> >>That is eating 128MB for 1GB, aka 12% of the guest memory allocated
>
On Mon, Dec 07, 2020 at 02:20:55PM -0600, Wei Huang wrote:
> In summary, this patch is fine if Punit already verified it. My only
> concern is the list can potentially increase over the time, and we will
> keep coming back to fix override_acpi_psd() function.
Can the detection be done by looking
On Thu, Dec 03, 2020 at 03:25:48PM -0800, Reinette Chatre wrote:
> From: Fenghua Yu
>
> The code of setting the CPU on which a task is running in a CPU mask is
> moved into a couple of helpers.
Pls read section "2) Describe your changes" in
Documentation/process/submitting-patches.rst for more
On Thu, Nov 19, 2020 at 03:32:36PM -0800, Chang S. Bae wrote:
> The xstate infrastructure is not flexible to support dynamic areas in
> task->fpu.
task->fpu?
Do you mean the fpu member in struct thread_struct ?
> Change the fpstate_init() prototype to access task->fpu directly. It
> treats a
On Tue, Nov 10, 2020 at 08:21:52AM -0800, Yu-cheng Yu wrote:
> Kernel read-only PTEs are setup as _PAGE_DIRTY_HW. Since these become
> shadow stack PTEs, remove the dirty bit.
This commit message is laconic to say the least. You need to start
explaining what you're doing because everytime I look
On Thu, Dec 03, 2020 at 03:25:59AM +, Ashish Kalra wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 1bcfbcd2bfd7..46549bd3d840 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -485,7 +485,38 @@ static void
;powerpc/embedded6xx: Remove C2K board support")
>
> That means the driver is now dead code, so remove it.
>
> Suggested-by: Borislav Petkov
> Signed-off-by: Michael Ellerman
> ---
> drivers/edac/Kconfig| 7 -
> drivers/edac/Makefile
On Mon, Dec 07, 2020 at 05:00:11PM +0800, Troy Lee wrote:
> Adding Aspeed AST2400 and AST2600 binding for edac driver.
>
> Signed-off-by: Troy Lee
> Acked-by: Joel Stanley
> ---
> .../devicetree/bindings/edac/aspeed-sdram-edac.txt | 9 ++---
> 1 file changed, 6 insertions(+), 3
( drop stable@ )
On Sun, Dec 06, 2020 at 12:53:25PM +0900, Masami Hiramatsu wrote:
> On Sat, 5 Dec 2020 11:17:04 +0100
> Borislav Petkov wrote:
>
> > On Sat, Dec 05, 2020 at 09:12:56AM +0900, Masami Hiramatsu wrote:
> > > This may break tools/objtool build. Please kee
On Sat, Dec 05, 2020 at 09:12:56AM +0900, Masami Hiramatsu wrote:
> This may break tools/objtool build. Please keep "inat.h".
How? Please elaborate.
Build tests are fine here.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sat, Dec 05, 2020 at 09:10:32AM +0900, Masami Hiramatsu wrote:
> In the future, if x86 ISA is expanded and add a legacy prefix
> groups,
Very unlikely.
> then we have to add new insn_prefix_field data structure, which
> size will not depend on NUM_INSN_FIELD_BYTES, but still depend on
>
From: Borislav Petkov
After having collected the majority of reports about MSRs being written
by userspace tools and what tools those are, and all newer reports
mostly repeating, add an URL where detailed information is gathered and
kept up-to-date.
Signed-off-by: Borislav Petkov
---
arch/x86
On Fri, Dec 04, 2020 at 07:55:20PM +0900, Masami Hiramatsu wrote:
> +/**
> + * for_each_insn_prefix() -- Iterate prefixes in the instruction
> + * @insn: Pointer to struct insn.
> + * @idx: Index storage.
> + * @prefix: Prefix byte.
> + *
> + * Iterate prefix bytes of given @insn. Each prefix
On Fri, Dec 04, 2020 at 07:55:09PM +0900, Masami Hiramatsu wrote:
> Hi,
>
> Here are the 3rd version of patches to fix the wrong loop boundary
> check on insn.prefixes.bytes[] array.
Ok, so I've committed the version with ARRAY_SIZE to keep it as small
as possible for stable. Let's discuss the
On Fri, Dec 04, 2020 at 09:56:53AM +0900, Masami Hiramatsu wrote:
> Hmm, there is a difference between Intel SDM and AMD APM.
>
> Intel SDM vol.2
>
> 2.1.1 Instruction Prefixes
> Instruction prefixes are divided into four groups, each with a set of
> allowable prefix codes. For each
On Thu, Dec 03, 2020 at 12:10:10PM -0600, Tom Lendacky wrote:
> Since that struct is used in multiple places, I think basing it on the array
> size is the best way to go. The main point of the check is just to be sure
> you don't read outside of the array.
Well, what happens if someone increases
On Thu, Dec 03, 2020 at 05:54:20PM +0100, Borislav Petkov wrote:
> On Thu, Dec 03, 2020 at 10:45:48AM -0600, Tom Lendacky wrote:
> > Since this is based on the array size, can
> >
> > idx < NUM_LEGACY_PREFIXES
> >
> > be replaced with:
> >
>
On Thu, Dec 03, 2020 at 10:45:48AM -0600, Tom Lendacky wrote:
> Since this is based on the array size, can
>
> idx < NUM_LEGACY_PREFIXES
>
> be replaced with:
>
> idx < ARRAY_SIZE(insn->prefixes.bytes)
Actually, this needs another change:
struct insn_field {
union {
On Thu, Dec 03, 2020 at 11:14:06AM -0500, Arvind Sankar wrote:
> Do any of them have it mapped at all, regardless of the alignment? There
> seems to be nothing else in the kernel that ever looks at the TSEG MSR,
> so I would guess that it has to be non-RAM in the E820 map, otherwise
> nothing
e, add NUM_LEGACY_PREFIXES, sync with the
respective header in tools/ and drop "we". ]
Fixes: 2b1444983508 ("uprobes, mm, x86: Add the ability to install and remove
uprobes breakpoints")
Reported-by: syzbot+9b64b619f10f19d19...@syzkaller.appspotmail.com
Signed-off-by: Masami Hiramats
On Thu, Dec 03, 2020 at 01:37:57PM +0100, Borislav Petkov wrote:
> Btw, looking at the struct insn definition, that prefixes member should
> have a comment above it that those are the legacy prefixes which can be
> <= 4. But that's minor.
And that naked 4 is poking my eye too - It
On Thu, Dec 03, 2020 at 01:50:37PM +0900, Masami Hiramatsu wrote:
> Since the insn.prefixes.nbytes can be bigger than the size of
> insn.prefixes.bytes[] when a same prefix is repeated, we have to
> check whether the insn.prefixes.bytes[i] != 0 and i < 4 instead
> of insn.prefixes.nbytes.
> This
On Thu, Dec 03, 2020 at 10:27:25PM +1100, Michael Ellerman wrote:
> It's dead code, so drop it.
>
> I can send a patch if no one else wants to.
Yes please.
I love patches removing code! :-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Tue, Nov 10, 2020 at 08:21:51AM -0800, Yu-cheng Yu wrote:
> Before introducing _PAGE_COW for non-hardware memory management purposes in
> the next patch, rename _PAGE_DIRTY to _PAGE_DIRTY_HW and _PAGE_BIT_DIRTY to
> _PAGE_BIT_DIRTY_HW to make meanings more clear. There are no functional
>
On Wed, Dec 02, 2020 at 05:32:32PM -0500, Arvind Sankar wrote:
> The pfn_range_is_mapped() call just checks whether it is mapped at all
> in the direct mapping. Is the TSEG range supposed to be marked as
> non-RAM in the E820 map? AFAICS, the only case when a direct mapping is
> created for
On Wed, Dec 02, 2020 at 10:19:48PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Make it possible to opt-out from VMware support, for minimized kernels
> that never will be run under Vmware (eg. high-density virtualization
> or embedded systems).
>
> Average distro kernel will leave it on,
On Thu, Dec 03, 2020 at 01:27:27AM +, Troy Lee wrote:
> Hi Broislav and Andrew,
>
> I removed these exported function and submitted v3 PATCH.
I saw that. A couple of comments:
First of all, please do not top-post on a public mailing list.
Secondly, Joel gave you Reviewed-by: and Acked-by:
On Wed, Dec 02, 2020 at 08:17:23PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Reducing the kernel size. Think of very high density virtualization
> (w/ specially stripped-down workloads) or embedded systems.
>
> For example, I'm running bare minimum kernels w/ only kvm and virtio
> (not
On Thu, Dec 03, 2020 at 01:32:44AM +1030, Andrew Jeffery wrote:
> On Wed, 2 Dec 2020, at 19:11, Troy Lee wrote:
> > Hi Joel,
> >
> > Thanks for the suggestion, I'll fix the review and create an new patch
> > against
> > latest Linux branch. Those exported function will be referenced in
> >
On Wed, Dec 02, 2020 at 11:58:15AM -0600, Tom Lendacky wrote:
> I believe this is geared towards performance. If the TSEG base address is
> not 2MB aligned, then hardware has to break down a 2MB TLB entry if the OS
> references the memory within the 2MB page that is before the TSEG base
> address.
On Tue, Dec 01, 2020 at 02:21:45AM +0900, Masami Hiramatsu wrote:
> Because it overruns the buffer. Maybe -E2BIG/ENODATA or any other
> error (except for -EINVAL) is OK :)
ENODATA it is. :)
And propagating that error value is easy because the err_out: labels are
all coming from the
On Wed, Dec 02, 2020 at 06:22:00PM +0200, Jarkko Sakkinen wrote:
> Initialize "ret" to zero as otherwise a zero length address range will
> leave it uninitialized.
That length is:
* @length: length of the data (multiple of the page size)
I think we wanna fail this even earlier when it
On Wed, Dec 02, 2020 at 03:48:21PM +0100, Jürgen Groß wrote:
> I wanted to avoid the additional NOPs for the bare metal case.
Yeah, in that case it gets optimized to a single NOP:
[0.176692] SMP alternatives: 81a00068: [0:5) optimized NOPs: 0f 1f
44 00 00
which is nopl
On Wed, Dec 02, 2020 at 11:13:02PM +0900, Punit Agrawal wrote:
> Didn't realize the core was internal only.
F10h is not internal only - all I'm saying is that "K10" wasn't use
inside AMD AFAIR.
> Makes sense - I will follow your suggestion in the next version.
Well, I don't think it is worth
On Fri, Nov 20, 2020 at 12:46:22PM +0100, Juergen Gross wrote:
> @@ -123,12 +115,15 @@ SYM_INNER_LABEL(entry_SYSCALL_64_after_hwframe,
> SYM_L_GLOBAL)
>* Try to use SYSRET instead of IRET if we're returning to
>* a completely clean 64-bit userspace context. If we're not,
>
On Tue, Nov 24, 2020 at 02:30:09PM +0800, Wang ShaoBo wrote:
> Fix to return -ENODEV error code when edac_pci_add_device() failed instaed
> of 0 in mv64x60_pci_err_probe(), as done elsewhere in this function.
>
> Fixes: 4f4aeeabc061 ("drivers-edac: add marvell mv64x60 driver")
> Signed-off-by:
+ nouv...@lists.freedesktop.org
On Wed, Dec 02, 2020 at 10:32:57AM +, Capek Pavel wrote:
> Dear kernel maintainers,
>
> After upgrading Fedora from 31 to 32 I try to deal with frequent and
> substantial slowing down of the OS. The computer does not react at random
> when I move a mouse or
gt; * %SGX_PAGE_MEASURE:Measure the page contents with a sequence of
> * ENCLS[EEXTEND] operations.
> */
> --
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Nov 30, 2020 at 02:48:09PM -0800, Yu, Yu-cheng wrote:
> Logically, enabling IBT without shadow stack does not make sense, but these
> features have different CPUIDs, and CONFIG_X86_SHADOW_STACK_USER and
> CONFIG_X86_BRANCH_TRACKING_USER can be selected separately.
>
> Do we want to have
On Tue, Dec 01, 2020 at 10:48:10AM +0100, Jan Kara wrote:
> On Mon 30-11-20 17:30:59, Brian Gerst wrote:
> > Commit 121b32a58a3a converted native x86-32 which take 64-bit arguments to
> > use the compat handlers to allow conversion to passing args via pt_regs.
> > sys_fanotify_mark() was however
On Tue, Dec 01, 2020 at 11:17:39PM +0800, Rongwei Wang wrote:
> In ARM, the system registers can only be accessed through msr and mrs,
> so the problem created by MSR driver (depend on rdmsr and wrmsr) in
> x86 is not necessarily present in ARM, which is very different from
> x86.
No, the point
On Tue, Dec 01, 2020 at 10:33:42PM +0800, wangrongwei wrote:
> Yes, and x86 also provides two instructions with the same name in the
> instruction set, but not in ARM.
Sorry, I can't parse what you're trying to say here.
--
Regards/Gruss,
Boris.
On Mon, Nov 30, 2020 at 08:40:32PM +, Bae, Chang Seok wrote:
> In general, putting #ifdef in a C file is advised to avoid.
Well, in this case it is arguably better to have the ifdeffery there,
where it is being used.
> I wonder whether it is okay to include #ifdef in the C file in this
>
On Tue, Dec 01, 2020 at 11:44:52AM +0800, wangrongwei wrote:
> Indeed, I have read the commit message, and it seems that writes data
> to a system register may cause many problems. Actually, we have taken
> this into account. In the current version, we have separated the read
> and write functions
701 - 800 of 23602 matches
Mail list logo
