On Thursday 22 June 2006 01:18, Rohit Seth wrote:
> On Thu, 2006-06-22 at 01:05 +0200, Andi Kleen wrote:
> > On Thursday 22 June 2006 00:59, Rohit Seth wrote:
>
> > > I was thinking of storing it is base address part of the descriptor and
> > > then using the memory load to read it in vsyscall. (Keeping the p bit
> > > to zero in the descriptor).
> >
> > I'm still not sure where and for what you want to use this. In user space
> > or in kernel space? And what information should be stored in there?
> >
>
> Store the kernel virtual pointer in gdt to access pda in (proposed)
> vgetcpu in vsyscall.
> Using this pointer we can easily reach the cpu and
> node numbers and any other information that is there in pda. For the
> cpu and node numbers this will get rid of the need to do a serializing
> operation cpuid.
>
> Does it make any sense?
Ok to spell it out (please correct me if I misinterpreted you). You want to:
- Split PDA into kernel part and user exportable part
- Export user exportable part to ring 3
- Put base address of user exportable part into GDT
- Access it using that.
I don't think it can work because the GDT only supports 32bit
base addresses for code/data segments in long mode and you can't put
a kernel virtual address into 32bit (only user space there)
And you can't get at at the base address anyways because they
are ignored in long mode (except for fs/gs). For fs/gs you would
need to save/restore them to reuse them which would be slow.
You can't also just put them into fs/gs because those are
already reserved for user space.
Also I don't know what other information other than cpu/node
would be useful, so just using the 20 bits of limit seems plenty to me.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
