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
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
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
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 either
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
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
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
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 I
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 cook in
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 (it
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 then using
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.
Thanks!
Rusty.
-
To unsubscribe from this list: send the line
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.
Thanks!
Rusty.
-
To unsubscribe from this list: send the line
14 matches
Mail list logo
