Re: [VERY RFC PATCH] x86_64: Rework storing segment registers

[Luca]

Il 15/06/23 19:41, Sergey Bugaev ha scritto:
> On Thu, Jun 15, 2023 at 8:02 PM Luca <luca@orpolo.org> wrote:
> > That's a bit strange, with my kernel I can now successfully end the
> > second stage, and without these warnings. Strangely, I don't see the
> > "Setting up translators: " line...
>
> Check /debootstrap/debootatrap.log :)
>
> The output I posted was from both debootstrap std{out,err} and the
> log, interleaved. I'm launching tail -f /debootstrap/debootatrap.log
> in parallel with deboostrap itself, following Samuel's instructions.

ah yes, now it makes sense :D I saw that, but then I forgot...

> > > +#if !defined(__x86_64__) || defined(USER32)
> >
> > I'm wondering if we could simplify this case by defining USER32 also on
> > i386.
>
> Perhaps, but then you'd need to go over the other usages of USER32 and
> verify they don't imply x86_64.

from a quick look It seems indeed that most cases assume x86_64. Maybe 
it would make sense to define USER64 as defined(__x86_64__) && 
!defined(USER32) since that seems the most common case.

> > > +#if defined(__x86_64__) && !defined(USER32)
> > > +struct i386_saved_fsgs_base_state {
> > > +     unsigned long   fsbase;
> > > +     unsigned long   gsbase;
> > > +};
> > > +#endif
> > > +
> >
> > These can maybe be placed in the i386_machine_state below
>
> Yeah, that'd probably be better.
>
> > Why did you remove these? The idea was that they could now be empty on
> > full 64-bit, and encapsulating the segment handling code for 32-bit,
> > which is repeated in various places... One addition could also be to set
> > the kernel segments after saving the user ones, or are there some more
> > variations of them?
>
> Because there's no longer a need to do anything special for fs/gs,
> they are now handled the same way as es/ds, namely ifdef'ed out on
> !USER32.
>
> Maybe it would make sense to define new macros like PUSH_SEGS and
> POP_SEGS that would push/pop all of (ds, es, fs, gs), but that'd be a
> separate change from this patch.

ok, in any case I would keep PUSH_SEGS and SET_KERNEL_SEGMENTS 
separated, as I think they need to be split in all_intrs.


Luca