Re: x86: move the LAPIC va

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 29/12/2016 à 19:52, David Laight a écrit :
> On Sat, Oct 08, 2016 at 05:14:43PM +0200, Maxime Villard wrote:
> > On x86 there's a set of memory-mapped registers that are per-cpu and called
> > the
> > LAPIC. They reside at a fixed one-page-sized physical address, and in order
> > to
> > read or write to them the kernel has to allocate a virtual address and then
> > kenter it to the aforementioned physical one.
> >
> > In the NetBSD kernel, however, we do something a little bizarre: instead of
> > following this model, the kernel has a blank page at the beginning of the
> > data
> > segment, and it then directly kenters the va of this page into the LAPIC pa.
> >
> > The issue with this design is that it implies the first page of .data does
> > not
> > actually belong to .data, and therefore it is not possible to map the
> > beginning
> > of .data with large pages. In addition to this, without going into useless
> > details, it creates an inconsistency in the low memory map, because the
> > pa<->va
> > translation is not linear, even if it seemingly is harmless.
>
> If you are going to change it, why not pick a more appropriate fixed virtual
> address?

Which more appropriate magic address? On i386 for example, the VA bounds are
variable-sized, and there is no place where you could hard-code the lapic. We
would have to split the kernel VA space in two around that page, etc.

I would tend to say that generally speaking, having hard-coded VAs/PAs is a
bad idea. By the way, I've already committed the patch.

> The smp code will already be using one for things like curproc.

If you're talking about thread local storage, it is done with %fs/%gs, which
always points to a dynamically-allocated cpu_info structure - except for cpu0,
but it's in the data segment so no one cares.

If you are talking about the smp trampoline used to boot the secondary CPUs, we
use a hard-coded PA precisely because the CPU operates in a low memory mode. And
the associated VAs get unmapped once we are done anyway.

> That way you don't need to add all the indirections to the asm code
> and don't need asm #defines that use temporary registers.
> You'll still need a physica page for non LAPIC cpu (probably
> not smp-capable designs).

Yes, I was told that after committing the patch, and had to add a kenter for
those CPUs.