Rusty Russell wrote:
> Hmm, this invalidated my assumption that write_gdt_entry is always a
> write to this cpu's active gdt. Better fix is not to call it twice
> anyway...
>
No, I don't think that's true. I implemented the write_*_entry
functions with the assumption they could be called eith
On Tue, 2007-03-13 at 13:48 -0700, Jeremy Fitzhardinge wrote:
> * init_gdt should always use write_gdt_entry when touching the gdt;
> if it doesn't and it ends up touching an already-installed gdt
> under Xen, it will get a write fault. This happens because
> init_gdt ends up
On Tue, 2007-03-13 at 21:39 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > This is called "pissing in the corners". Don't do it: we don't need to
> > touch that code and I actually prefer the original anyway (explicit is
> > *good*).
> >
> > The habit of extracting cpu number once
Rusty Russell wrote:
> This is called "pissing in the corners". Don't do it: we don't need to
> touch that code and I actually prefer the original anyway (explicit is
> *good*).
>
> The habit of extracting cpu number once then using it is an optimization
> which we should be aiming to get rid of
On Tue, 2007-03-13 at 13:48 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > Hi all,
> >
> > The GDT stuff on x86 is a little more complex than it need be, but
> > playing with boot code is always dangerous. These compile and boot on
> > UP and SMP for me, but Andrew should let the
Rusty Russell wrote:
> Hi all,
>
> The GDT stuff on x86 is a little more complex than it need be, but
> playing with boot code is always dangerous. These compile and boot on
> UP and SMP for me, but Andrew should let the cook in -mm for a while.
>
Hi Rusty,
This is my rough hacking patch
6 matches
Mail list logo
