Re: [PATCH v2 22/23] x86: make Xen early boot code relocatable

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> > >  trampoline_bios_setup:
> > > +        mov     %ebp,%esi
> > > +
> > > +        /* Initialise GDT and basic data segments. */
> > > +        add     %ebp,sym_offset(gdt_boot_descr_addr)(%esi)
> > > +        lgdt    sym_offset(gdt_boot_descr)(%esi)
> > > +
> > > +        mov     $BOOT_DS,%ecx
> > > +        mov     %ecx,%ds
> > > +        mov     %ecx,%es
> > > +        mov     %ecx,%fs
> > > +        mov     %ecx,%gs
> > > +        mov     %ecx,%ss
> > > +
> >
> >
> > The non-EFI boot path is now:
> >
> > start
> >  \- __start
> >      \- multiboot2_proto
> >      |    jmp trampoline_bios_setup
> >      |
> >      \-and if not MB2: jmp trampoline_bios_setup.
> >
> >
> > In here you tweak the GDT and reload the %ds - but during
> > this call chain we do touch the %ds - via:
> >
> > __start+27>:        testb  $0x1,(%rbx)
> > __start+30>:        cmovne 0x4(%rbx),%edx
> >
> > which is OK (as MB1 says that the %ds has to cover up to 4GB).
> > But I wonder why the __start code had the segments reloaded so early?
> > Was the bootloader not setting the proper segments?
> 
> This is very good question. I was asking myself about that thing at
> least once. Sadly, I cannot find real explanation.
> 
> > Let me double-check what SYSLINUX's mboot.c32 does. Perhaps
> > it had done something odd in the past.
> 
> Good idea!

Nope, the mboot.c32 COMBOOT images are booted with:

  %ds,%es,%fs,%gs : 32-bit data segment with zero base and 4GB limit  

So that is OK. Perhaps this code used to be shared with trampoline
startup and got copied over.

Anyhow not worried about it.

.. snip..
> > > +        /* Initialize %fs and later use it to access Xen data if possible. */
> > > +        mov     $BOOT_FS,%edx
> > > +        mov     %edx,%fs
> > > +
> >
> > We just modified the GDT. Should we reload it (lgdt?)?
> 
> I do not think it is needed.
> 
> Intel 64 and IA-32 Architectures Software Developer’s Manual,
> Volume 2 (2A, 2B & 2C): Instruction Set Reference, A-Z says:
> 
> LGDT ... Loads the values in the source operand into the global
> descriptor table register (GDTR)...
> 
> ...and ...
> 
> MOV ... If the destination operand is a segment register (DS, ES,
> FS, GS, or SS), the source operand must be a valid segment selector.
> In protected mode, moving a segment selector into a segment register
> automatically causes the segment descriptor information associated
> with that segment selector to be loaded into the hidden (shadow) part
> of the segment register. While loading this information, the segment

.. snip..
> "shadow register.") When a segment selector is loaded into the visible
> part of a segment register, the processor also loads the hidden part
> of the segment register with the base address, segment limit, and access
> control information from the segment descriptor pointed to by the segment
> selector. The information cached in the segment register (visible and

Excellent!

> hidden) allows the processor to translate addresses without taking
> extra bus cycles to read the base address and limit from the segment
> descriptor. In systems in which multiple processors have access to the
> same descriptor tables, it is the responsibility of software to reload
> the segment registers when the descriptor tables are modified (side note:
> GDTR reload is not required! probably the same applies to UP systems
> and if CPU update own active GDT). If this is not done, an old segment
> descriptor cached in a segment register might be used after its
> memory-resident version has been modified.
> 
> AIUI, only GDT address and limit are loaded into GDTR when lgdt is executed.
> Segment descriptor is loaded directly from memory into segment register
> (hiden part) only when relevant load instruction is used (e.g. mov %edx,%fs).

Yeey!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel