From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Dave Hansen <dave.hansen@intel.com>, X86 ML <x86@kernel.org>,
Borislav Petkov <bpetkov@suse.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Brian Gerst <brgerst@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2] x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
Date: Sun, 26 Nov 2017 16:58:37 +0100 [thread overview]
Message-ID: <20171126155837.ludnd6va4rqy5d37@gmail.com> (raw)
In-Reply-To: <CALCETrUNM_xsxMKbw1nrvgaF-_bRJtfFCFFrjook0zJ=6urq-Q@mail.gmail.com>
* Andy Lutomirski <luto@kernel.org> wrote:
> On Sun, Nov 26, 2017 at 5:48 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Dave Hansen <dave.hansen@intel.com> wrote:
> >
> >> On 11/10/2017 08:05 PM, Andy Lutomirski wrote:
> >> > -struct tss_struct doublefault_tss __cacheline_aligned = {
> >> > - .x86_tss = {
> >> > - .sp0 = STACK_START,
> >> > - .ss0 = __KERNEL_DS,
> >> > - .ldt = 0,
> >> ...
> >> > +struct x86_hw_tss doublefault_tss __cacheline_aligned = {
> >> > + .sp0 = STACK_START,
> >> > + .ss0 = __KERNEL_DS,
> >> > + .ldt = 0,
> >> > + .io_bitmap_base = INVALID_IO_BITMAP_OFFSET,
> >>
> >> FWIW, I really like the trend of renaming the hardware structures in
> >> such a way that it's clear that they *are* hardware structures.
> >>
> >> It might also be nice to reference the relevant SDM sections on the
> >> topic, or even to include a comment along the lines of how it get used.
> >> This chunk from the SDM is particularly relevant:
> >>
> >> "The TSS holds information important to 64-bit mode and that is not
> >> directly related to the task-switch mechanism."
> >
> > That makes sense - I've updated this patch with the following description added to
> > struct x86_hw_tss:
>
> I've folded this in along with all the reviews so far, and a few misc
> fixes from Boris' review. I was planning to resend the whole series
> today after I track down the kbuild error. Does that sound good?
Could you please do a delta to the very latest WIP.x86/mm instead?
In the latest I have included the review tags already, and all the easy-to-do
review feedback as well, so the delta should be rasonably small.
These entry bits are destined for x86/urgent real soon, so Thomas and me are
trying to pin the tree down and do delta changes only.
If it's a simple full interdiff between your latest and WIP.x86/mm that's fine as
well, can backmerge everything accordingly.
Thanks,
Ingo
next prev parent reply other threads:[~2017-11-26 15:58 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-11 4:05 [RFC 0/7] Prep code for better stack switching Andy Lutomirski
2017-11-11 4:05 ` [RFC 1/7] x86/asm/64: Allocate and enable the SYSENTER stack Andy Lutomirski
2017-11-13 19:07 ` Dave Hansen
2017-11-14 2:17 ` Andy Lutomirski
2017-11-14 7:15 ` Ingo Molnar
2017-11-11 4:05 ` [RFC 2/7] x86/gdt: Put per-cpu GDT remaps in ascending order Andy Lutomirski
2017-11-11 4:05 ` [RFC 3/7] x86/fixmap: Generalize the GDT fixmap mechanism Andy Lutomirski
2017-11-11 4:05 ` [RFC 4/7] x86/asm: Fix assumptions that the HW TSS is at the beginning of cpu_tss Andy Lutomirski
2017-11-13 17:01 ` Dave Hansen
2017-11-26 13:48 ` [PATCH v2] x86/entry: " Ingo Molnar
2017-11-26 15:41 ` Andy Lutomirski
2017-11-26 15:58 ` Ingo Molnar [this message]
2017-11-26 16:00 ` Ingo Molnar
2017-11-26 16:05 ` Andy Lutomirski
2017-11-26 16:43 ` Ingo Molnar
2017-11-11 4:05 ` [RFC 5/7] x86/asm: Rearrange struct cpu_tss to enlarge SYSENTER_stack and fix alignment Andy Lutomirski
2017-11-11 4:11 ` Andy Lutomirski
2017-11-13 19:19 ` Dave Hansen
2017-11-11 4:05 ` [RFC 6/7] x86/asm: Remap the TSS into the cpu entry area Andy Lutomirski
2017-11-13 19:22 ` Dave Hansen
2017-11-13 19:36 ` Linus Torvalds
2017-11-14 2:25 ` Andy Lutomirski
2017-11-14 2:28 ` Linus Torvalds
2017-11-14 2:30 ` Andy Lutomirski
2017-11-14 2:27 ` Andy Lutomirski
2017-11-11 4:05 ` [RFC 7/7] x86/unwind/64: Add support for the SYSENTER stack Andy Lutomirski
2017-11-13 22:46 ` Josh Poimboeuf
2017-11-14 2:13 ` Andy Lutomirski
2017-11-11 10:58 ` [RFC 0/7] Prep code for better stack switching Borislav Petkov
2017-11-12 2:59 ` Andy Lutomirski
2017-11-12 4:25 ` Andy Lutomirski
2017-11-13 4:37 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171126155837.ludnd6va4rqy5d37@gmail.com \
--to=mingo@kernel.org \
--cc=bpetkov@suse.de \
--cc=brgerst@gmail.com \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).