On Tue, Jun 24, 2025 at 02:12:58PM +0200, Hans-Jörg Höxer wrote:
> Hi,
>
> On Sat, Jun 21, 2025 at 10:43:23PM -0700, Mike Larkin wrote:
> > ...
> > I think this locore diff below looks ok to me but it changes some very
> > fundamental early boot behavior. I was asking before what your plan is for
> > testing this before commit. I don't think testing this on just a handful
> > of machines is sufficient. It's particularly tough with this one as if it
> > breaks someone, the machine will pretty much be bricked and require fixing
> > via install media. That's why I'm hesitant.
> >
> > If you are ready to handle any fallout, then sure. It's probably the right
> > time in the release process for this. ok mlarkin on the diff itself in that
> > case. There are a few things we can change later (like using .Lxxx in all
> > symbols in locore0 and there are a few style(9) things) but nothing that
> > warrants fixing now.
> >
> > P.S. hshoexer: The locore0 page gets unmapped right after we are done with it;
> > can you please verify that the #VC traps and locore0 IDTs aren't needed after
> > that unmapping?
>
> yes, the locore0 #VC trap handler will not be needed after we are reach
> init_x86_64().  The next diffs will deal with this:  init_x86_64()
> will setups a temporary "early" IDT right away to deal with #VC during
> bootstrap.  And when init_x86_64() sets up the actual IDT an entry for
> #VC is included.
>
> Fwiw:  I have some experimental proof-of-concept code, that uses
> paravirtualisation to completely avoid #VC as soon as the kernel is up
> and running (and SEV-ES/SNP is enabled).
>
> Take care,
> Hans-Joerg

sure. I just wanted to make sure someone looked at the lifecycle of the IDT
set up during locore0 since that gets unmapped pretty early. Sounds like that
was already looked at.

-ml