On Wed, Jan 30, 2019 at 01:46:44PM +0100, Jiri Slaby wrote:
> Introduce new C macros for annotations of functions and data in
> assembly. There is a long-standing mess in macros like ENTRY, END,
> ENDPROC and similar. They are used in different manners and sometimes
> incorrectly.
>
> So introduce
Hi,
this time a more detailed look. :)
> Subject: Re: [PATCH v8 01/28] linkage: new macros for assembler symbols
Patch subject needs a verb, like, for example:
"linkage: Introduce new macros for assembler symbols"
On Thu, Aug 08, 2019 at 12:38:27PM +0200, Jiri Slaby wrote:
> Introduce new C ma
64, given these were
> the last users.
>
> Signed-off-by: Jiri Slaby
> Reviewed-by: Rafael J. Wysocki [hibernate]
> Reviewed-by: Boris Ostrovsky [xen bits]
> Cc: "H. Peter Anvin"
> Cc: Borislav Petkov
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: x..
On Mon, Nov 04, 2019 at 04:13:51PM +0100, Daniel Kiper wrote:
> Hi,
>
> Due to very limited space in the setup_header this patch series introduces new
> kernel_info struct which will be used to convey information from the kernel to
> the bootloader. This way the boot protocol can be extended regar
On Wed, Nov 06, 2019 at 09:56:48AM -0800, h...@zytor.com wrote:
> For one thing, we already have people asking for more than 4 GiB
> worth of initramfs, and especially with initramfs that huge it would
> make a *lot* of sense to allow loading it in chunks without having to
> concatenate them.
Yeah
On Mon, Nov 04, 2019 at 04:13:53PM +0100, Daniel Kiper wrote:
> This field contains maximal allowed type for setup_data.
>
> This patch does not bump setup_header version in arch/x86/boot/header.S
> because it will be followed by additional changes coming into the
> Linux/x86 boot protocol.
>
> S
On Fri, Nov 08, 2019 at 11:47:02AM +0100, Daniel Kiper wrote:
> Yeah, you are right. Would you like me to repost whole patch series or
> could you fix it before committing?
Lemme finish looking at patch 3 first.
If you have to resend, please remove "This patch" and "We" in your text.
Thx.
--
R
On Mon, Nov 04, 2019 at 04:13:54PM +0100, Daniel Kiper wrote:
> diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
> index edaa30b20841..701a98300f86 100644
> --- a/arch/x86/kernel/kdebugfs.c
> +++ b/arch/x86/kernel/kdebugfs.c
> @@ -44,7 +44,11 @@ static ssize_t setup_data_read(st
On Fri, Nov 08, 2019 at 01:52:48PM +0100, Daniel Kiper wrote:
> OK, got your comments. I will repost the patch series probably on Tuesday.
> I hope that it will land in 5.5 then.
I don't see why not if you base it ontop of tip:x86/boot and test it
properly before sending.
Out of curiosity, is the
On Sun, Dec 02, 2018 at 08:23:05PM +, Andrew Cooper wrote:
> Hello,
>
> I have dual socket server with the following processor:
>
> [root@xrtmia-09-01 ~]# head /proc/cpuinfo
> processor : 0
> vendor_id : AuthenticAMD
> cpu family: 23
> model : 1
> model name: AMD EPYC
On Thu, Dec 06, 2018 at 10:21:12PM +0100, Paolo Bonzini wrote:
> Thanks! I should be able to post a Tested-by next Monday. Boris, are
> you going to pick it up for 4.21?
Boris me or Boris O.?
:-)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the repl
On Thu, Dec 06, 2018 at 11:14:34PM +0100, Paolo Bonzini wrote:
> > There are some minor changes in non-xen x86 code so it would be good to
> > get x86 maintainers' ack.
>
> It's not really code, only Kconfig (and I remarked on it just now), but
> it doesn't hurt of course.
Yeah, I don't see anyth
On Fri, Dec 07, 2018 at 11:07:54AM -0500, Boris Ostrovsky wrote:
> Can this be considered as an ACK from you?
I'll look at v9 next week and add tags, assuming v9 is going to be the
final one, of course.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham N
On Mon, Dec 03, 2018 at 11:23:49AM +, Andrew Cooper wrote:
> Right, but the documentation also states that where it says package, it
> means "Node" in AMD's terminology, and the information in CPUID is per
> socket, not per node.
>
> My point is that the numbers ending up in cpuinfo_x86 don't
On Mon, Dec 10, 2018 at 11:05:34AM -0800, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux
- a/arch/x86/xen/Kconfig
> +++ b/arch/x86/xen/Kconfig
> @@ -74,6 +74,7 @@ config XEN_DEBUG_FS
> Enabling this option may incur a significant performance overhead.
>
> config XEN_PVH
> - bool "Support for running as a PVH guest"
> + bool "Support for running
On Tue, Dec 11, 2018 at 11:29:21AM -0800, Maran Wilson wrote:
> Is your question about what options you need to provide to Qemu? Or is your
> question about the SW implementation choices?
>
> Assuming the former...
Yeah, that's what I wanted to know. But looking at it, I'm booting
bzImage here ju
On Fri, Apr 13, 2018 at 10:57:46AM -0700, Raj, Ashok wrote:
> > I'm afraid I don't fully agree - not applying an ucode update to the online
> > CPUs because some are offline isn't any better. Plus (while updating)
> > there's always going to be some discrepancy between ucode versions.
> > As long a
On Sat, Jun 09, 2018 at 09:20:10PM +0800, Pu Wen wrote:
> As a new x86 CPU Vendor, Chengdu Haiguang IC Design Co., Ltd (Hygon)
> is a Joint Venture between AMD and Haiguang Information Technology Co.,
> Ltd., and aims at providing high performance x86 processor for China
> server market.
>
> The f
Hi Bart,
On Tue, Oct 16, 2018 at 03:42:16PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for vi
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 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 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 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 Mon, Apr 13, 2020 at 02:35:35PM +0200, Frédéric Pierret (fepitre) wrote:
> The change fixes boot failure on VM where kernel (at least v5.4 and v5.6)
> is built with gcc-10 and STACKPROTECTOR_STRONG enabled:
>
> ```
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
>
On Mon, Apr 13, 2020 at 05:03:14PM +0200, Frédéric Pierret (fepitre) wrote:
> The change fixes boot failure on VM where kernel (at least v5.4 and v5.6)
> is built with gcc-10 and STACKPROTECTOR_STRONG enabled:
>
> ```
> Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
>
On Tue, Jan 19, 2021 at 12:35:42PM +0100, Jürgen Groß wrote:
> In fact this should rather be named "X86_FEATURE_TRUE", as this is its
> semantics.
>
> And I think I can define it to the value 0x instead of using a
> "real" bit for it.
A real bit is cheap - a special value to pay attention to i
On Wed, Jan 20, 2021 at 02:55:47PM +0100, Juergen Gross wrote:
> The time pvops functions are the only ones left which might be
> used in 32-bit mode and which return a 64-bit value.
>
> Switch them to use the static_call() mechanism instead of pvops, as
> this allows quite some simplification of
On Mon, Apr 25, 2022 at 11:38:36PM +0300, Oleksandr wrote:
> diff --git a/include/linux/cc_platform.h b/include/linux/cc_platform.h
> index efd8205..d06bc7a 100644
> --- a/include/linux/cc_platform.h
> +++ b/include/linux/cc_platform.h
> @@ -72,6 +72,19 @@ enum cc_attr {
> * Examples inclu
On Tue, Oct 26, 2021 at 10:13:34PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan
>
> While in the native case, PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is the
> trampoline stack. But XEN pv doesn't use trampoline stack, so
> PER_CPU_VAR(cpu_tss_rw + TSS_sp0) is also the kernel stack. Hence source
On Tue, Nov 02, 2021 at 05:19:46PM +0800, Lai Jiangshan wrote:
> It will add a 5-byte NOP at the beginning of the native
> swapgs_restore_regs_and_return_to_usermode.
So?
> I avoided adding unneeded code in the native code even if it is NOPs
> and avoided melting xenpv-one into the native one whi
On Tue, Nov 02, 2021 at 12:22:50PM +0100, H. Peter Anvin wrote:
> It would be interesting to have an "override function with jmp"
> alternatives macro. It doesn't require any changes to the alternatives
> mechanism proper (but possibly to objtool): it would just insert an
> alternatives entry witho
From: Borislav Petkov
Avoid homegrown notifier registration checks.
No functional changes.
Signed-off-by: Borislav Petkov
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/enlighten.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86
From: Borislav Petkov
Avoid homegrown notifier registration checks.
No functional changes.
Signed-off-by: Borislav Petkov
Cc: xen-devel@lists.xenproject.org
---
drivers/xen/manage.c | 3 ++-
drivers/xen/xenbus/xenbus_probe.c | 8 +---
2 files changed, 7 insertions(+), 4
From: Borislav Petkov
The notifier registration routine doesn't return a proper error value
when a callback has already been registered, leading people to track
whether that registration has happened at the call site:
https://lore.kernel.org/amd-gfx/20210512013058.6827-1-mukul.jo...@am
From: Borislav Petkov
Hi all,
this is a huge patchset for something which is really trivial - it
changes the notifier registration routines to return an error value
if a notifier callback is already present on the respective list of
callbacks. For more details scroll to the last patch
On Mon, Nov 08, 2021 at 03:07:03PM +0100, Geert Uytterhoeven wrote:
> I think the addition of __must_check is overkill, leading to the
> addition of useless error checks and message printing.
See the WARN in notifier_chain_register() - it will already do "message
printing".
> Many callers call th
On Mon, Nov 08, 2021 at 09:17:03AM -0500, Alan Stern wrote:
> What reason is there for moving the check into the callers? It seems
> like pointless churn. Why not add the error return code, change the
> WARN to pr_warn, and leave the callers as they are? Wouldn't that end
> up having exactly
On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote:
> I guess I can add another indirection to notifier_chain_register() and
> avoid touching all the call sites.
IOW, something like this below.
This way I won't have to touch all the callsites and the registration
rou
On Mon, Nov 08, 2021 at 04:25:47PM +0100, Geert Uytterhoeven wrote:
> I'm not against returning proper errors codes. I'm against forcing
> callers to check things that cannot fail and to add individual error
> printing to each and every caller.
If you're against checking things at the callers, th
On Mon, Nov 08, 2021 at 05:12:16PM +0100, Geert Uytterhoeven wrote:
> Returning void is the other extreme ;-)
>
> There are 3 levels (ignoring BUG_ON()/panic () inside the callee):
> 1. Return void: no one can check success or failure,
> 2. Return an error code: up to the caller to decide,
>
On Mon, Nov 08, 2021 at 11:23:13AM -0500, Steven Rostedt wrote:
> Question, how often does this warning trigger? Is it common to see in
> development?
Yeah, haven't seen it myself yet.
But we hashed it out over IRC. :-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-ne
On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
> Is there really any reason for returning an error code? For example, is
> it anticipated that at some point in the future these registration calls
> might fail?
>
> Currently, the only reason for failing...
Right, I believe with not
On Tue, Nov 16, 2021 at 10:39:21AM -0500, Tianyu Lan wrote:
> diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
> index 35487305d8af..65bc385ae07a 100644
> --- a/arch/x86/mm/mem_encrypt.c
> +++ b/arch/x86/mm/mem_encrypt.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
>
On Sat, Aug 13, 2022 at 12:56:44PM -0400, Chuck Zmudzinski wrote:
> Why has Juergen not at least responded in some way to the
> comments that Boris has made here? Why has Boris not
> pinged Juergen by now,
How about: it is summer here and people usually take their vacations
during that time and ev
On Sat, Aug 13, 2022 at 05:40:34PM -0400, Chuck Zmudzinski wrote:
> I did a search for Juergen Gross on lkml and he is active submitting and
> reviewing patches during the past few weeks. However, he is ignoring
> comments on his patch to fix this regression.
Please stop this non-sense and be pati
On Sat, Aug 20, 2022 at 11:25:24AM +0200, Juergen Gross wrote:
> When booting or resuming the system MTRR state is saved on the boot
> processor and then this state is loaded into MTRRs of all other cpus.
s/cpu/CPU/g
Pls check all commit messages.
> During update of the MTRRs the MTRR mechanism
On Sun, Aug 21, 2022 at 02:25:59PM +0200, Borislav Petkov wrote:
> > Fix that by using percpu variables for saving the MSR contents.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Juergen Gross
> > ---
> > I thought adding a "Fixes:" tag for t
On Mon, Aug 22, 2022 at 07:17:40AM +0200, Juergen Gross wrote:
> And then there is mtrr_state_warn() in arch/x86/kernel/cpu/mtrr/generic.c
> which has a comment saying:
>
> /* Some BIOS's are messed up and don't set all MTRRs the same! */
That thing also says:
pr_info("mtrr: probably you
On Thu, Aug 25, 2022 at 12:41:05PM +0200, Juergen Gross wrote:
> Maybe the alternative reasoning is much faster to understand: if the
> Cyrix set_all() could be called, the AMD and Centaur ones would be callable,
> too.
Right.
> Those being called would result in a NULL deref, so why should we ke
On Mon, Sep 12, 2022 at 11:10:29AM +0200, Juergen Gross wrote:
> In the end this variable doesn't specify which caching types are available,
> but the ways to select/control the caching types.
>
> So what about "memory_caching_select" or "memory_caching_control" instead?
_control sounds like the
On Thu, Sep 08, 2022 at 10:49:09AM +0200, Juergen Gross wrote:
> Split generic_set_all() into multiple parts, while moving the main
> function body into cacheinfo.c.
>
> This prepares the support of PAT without needing MTRR support by
"Prepare PAT support without ... "
> moving the main function
On Mon, Jan 16, 2023 at 03:25:35PM +0100, Peter Zijlstra wrote:
> Per the comment it is important to call sev_verify_cbit() before the
> first RET instruction, this means we can delay calling this until more
Make that "... this means that this can be delayed until... "
And I believe this is not a
On Mon, Jan 16, 2023 at 03:25:36PM +0100, Peter Zijlstra wrote:
> Since Xen PV doesn't use restore_processor_state(), and we're going to
> have to avoid CALL/RET until at least GS is restored,
Drop the "we":
"..., and CALL/RET cannot happen before GS has been restored, ..."
--
Regards/Gruss,
On Mon, Jan 16, 2023 at 03:25:37PM +0100, Peter Zijlstra wrote:
> Since we can't do CALL/RET until GS is restored and CR[04] pinning is
^^
Ditto like for the previous one.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Feb 27, 2023 at 02:29:29PM -0800, Rick Edgecombe wrote:
> [0]
> https://lore.kernel.org/lkml/0e29a2d0-08d8-bcd6-ff26-4bea0e403...@redhat.com/#t
I guess that sub-thread about how you arrived at this "pass a VMA"
decision should be in the Link tag. But that's for the committer, I'd
say.
Th
On Tue, Jul 05, 2022 at 05:56:36PM +0200, Jan Beulich wrote:
> Re-using pat_disabled like you do in your suggestion below won't
> work, because mtrr_bp_init() calls pat_disable() when MTRRs
> appear to be disabled (from the kernel's view). The goal is to
> honor "nopat" without honoring any other c
On Thu, Jul 07, 2022 at 08:38:44AM +0200, Jan Beulich wrote:
> Well, right now the pvops hook for Xen swallows #GP anyway (wrongly
> so imo, but any of my earlier pointing out of that has been left
> unheard, despite even the code comments there saying "It may be worth
> changing that").
Oh great.
On Sat, Jul 16, 2022 at 07:32:46AM -0400, Chuck Zmudzinski wrote:
> Can you confirm that with this patch series you are trying
> to fix that regression?
Yes, this patchset is aimed to fix the whole situation but please don't
do anything yet - I need to find time and look at the whole approach
befo
On Fri, Jul 15, 2022 at 04:25:47PM +0200, Juergen Gross wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 736262a76a12..e43322f8a4ef 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
I guess the move's ok but not into cpu/commo
On Fri, Jul 15, 2022 at 04:25:49PM +0200, Juergen Gross wrote:
> Today PAT is usable only with MTRR being active, with some nasty tweaks
> to make PAT usable when running as Xen PV guest, which doesn't support
> MTRR.
>
> The reason for this coupling is, that both, PAT MSR changes and MTRR
> chang
On Thu, Feb 23, 2023 at 04:05:51PM +0100, Juergen Gross wrote:
> x86 maintainers, I think this patch should be carried via the tip tree.
You missed a spot. I'll whack it.
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index a8b323266179..c3ad8a526378 100644
On Mon, Mar 06, 2023 at 05:34:18PM +0100, Juergen Gross wrote:
> + for (reg = 0; reg < MTRR_MAX_VAR_RANGES; reg++) {
> + op.u.read_memtype.reg = reg;
> + if (HYPERVISOR_platform_op(&op))
> + break;
> +
> + /*
> + * Only called
On Wed, Nov 23, 2022 at 12:45:23PM +0100, Juergen Gross wrote:
> When running as a Xen PV guest there is no need for setting up the
> realmode trampoline, as realmode isn't supported in this environment.
>
> Trying to setup the trampoline has been proven to be problematic in
> some cases, especial
On Thu, Nov 24, 2022 at 02:30:39PM +0100, Juergen Gross wrote:
> Looking at the date when 084ee1c641a0 went in I don't think it _needs_
> to go in now, but I wouldn't complain ...
So if you don't have a particular and specific reason, I won't queue it
for stable at all.
--
Regards/Gruss,
Bor
On Thu, Nov 10, 2022 at 08:07:53AM -0800, Dave Hansen wrote:
> On 11/10/22 07:45, Ross Philipson wrote:
> > dt = early_memremap(initial_dtb, map_len);
> > + if (!dt) {
> > + pr_warn("failed to memremap initial dtb\n");
> > + return;
> > + }
>
> Are all of these new pr_w
On Sun, May 30, 2021 at 11:06:20AM -0400, Tianyu Lan wrote:
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index 156cd235659f..a82975600107 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -29,6 +29,8 @@
> #include
> #include
>
On Thu, May 23, 2024 at 03:59:43PM +0200, Thomas Gleixner wrote:
> On Wed, Apr 10 2024 at 15:48, Jason Andryuk wrote:
> > ---
> > arch/x86/kernel/head_64.S| 22 ++
> > arch/x86/kernel/pgtable_64_helpers.h | 28
>
> That's the wrong place
On Wed, May 31, 2023 at 11:31:37AM +0200, Juergen Gross wrote:
> What it did would have been printed if pr_debug() would have been
> active. :-(
Lemme turn those into pr_info(). pr_debug() is nuts.
> Did you check whether CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT was the same in
> both
> kernels you'
On Thu, Jun 01, 2023 at 08:39:17AM +0200, Juergen Gross wrote:
> Does this translate to: "we should remove that cleanup crap"? I'd be
> positive to that. :-)
Why, what's wrong with that thing?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Jun 01, 2023 at 10:19:01AM +0200, Juergen Gross wrote:
> Patch 2 wants this diff on top:
Obviously. :-)
That fixes it, thx.
Now lemme restart testing.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Jun 01, 2023 at 03:22:33PM +0200, Borislav Petkov wrote:
> Now lemme restart testing.
This is from another box, with the latest changes incorporated:
https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=rc1-mtrr
--- proc-mtrr.before2011-03-04 01:03:35.243994733 +0
On Thu, Oct 19, 2023 at 11:15:16AM +0200, Juergen Gross wrote:
> +/* Low-level backend functions usable from alternative code replacements. */
> +DEFINE_ASM_FUNC(x86_nop, "", .entry.text);
> +EXPORT_SYMBOL_GPL(x86_nop);
This is all x86 code so you don't really need the "x86_" prefix - "nop"
is per
On Wed, Oct 25, 2023 at 03:31:07PM +0200, Juergen Gross wrote:
> There is
>
> #define nop() asm volatile ("nop")
>
> in arch/x86/include/asm/special_insns.h already.
Then call it "nop_func" or so.
> It might not be needed now, but are you sure we won't need it in future?
No, I'm not.
What I'm
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 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, 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 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 Tue, Apr 26, 2022 at 11:36:40AM +0200, Juergen Gross wrote:
> As the suggestion was to add another flag this wouldn't be a problem IMO.
We had a problem already with adding one flag would break the same flag
on the other guest type. That's why we added cc_vendor too. So it can be
tricky.
> pla
On Mon, Oct 02, 2023 at 11:24:36PM -0700, Xin Li wrote:
> -/* Return frame for iretq */
> +
> + /* The IRETQ return frame starts here */
> unsigned long ip;
> - unsigned long cs;
> +
> + union {
> + u64 csx;// The full 64-bit data slot containing CS
> +
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
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:44PM -0700, Xin Li wrote:
> From: "H. Peter Anvin (Intel)"
>
> On a FRED system, the faulting address (CR2) is passed on the stack,
> to avoid the problem of transient state. Thus we get the page fault
^^
Please use pa
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 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 Tue, Dec 19, 2023 at 04:49:14PM +0800, kernel test robot wrote:
> [ 13.481107][ T48] WARNING: CPU: 0 PID: 48 at int80_emulation
> (arch/x86/entry/common.c:164)
> [ 13.481454][ T48] Modules linked in:
> [ 13.481655][ T48] CPU: 0 PID: 48 Comm: init Tainted: G N
> 6.7.0-r
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, 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: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, 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
2 --
> arch/x86/kernel/asm-offsets_64.c | 1 -
> arch/x86/kernel/paravirt.c| 1 -
> arch/x86/kernel/paravirt_patch.c | 3 ---
> arch/x86/xen/enlighten_pv.c | 3 ---
> 8 files changed, 13 insertions(+), 47 deletions(-)
I love patches like this one!
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 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 0x0(%rax,%rax
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 +237,9
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
>
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 boil
On Thu, Dec 17, 2020 at 10:31:24AM +0100, Juergen Gross wrote:
> The time pvops functions are the only ones left which might be
> used in 32-bit mode and which return a 64-bit value.
>
> Switch them to use the static_call() mechanism instead of pvops, as
> this allows quite some simplification of
On Thu, Dec 17, 2020 at 05:31:50PM +, Michael Kelley wrote:
> These Hyper-V changes are problematic as we want to keep hyperv_timer.c
> architecture independent. While only the code for x86/x64 is currently
> accepted upstream, code for ARM64 support is in progress. So we need
> to use hv_se
On Thu, Dec 17, 2020 at 10:31:25AM +0100, Juergen Gross wrote:
> Instead of only supporting to modify instructions when a specific
> feature is set, support doing so for the case a feature is not set.
>
> As today a feature is specified using a 16 bit quantity and the highest
> feature number in u
On Thu, Dec 17, 2020 at 09:12:57PM +0800, kernel test robot wrote:
>ld: arch/x86/kernel/alternative.o: in function `paravirt_set_cap':
> >> arch/x86/kernel/alternative.c:605: undefined reference to
> >> `pv_is_native_spin_unlock'
> >> ld: arch/x86/kernel/alternative.c:608: undefined reference
1 - 100 of 144 matches
Mail list logo
