On 15/04/2019 12:25, Anthony PERARD wrote: > On Thu, Apr 11, 2019 at 01:52:27PM +0100, Andrew Cooper wrote: >> On 09/04/2019 12:08, Anthony PERARD wrote: >>> diff --git a/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm >>> b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm >>> new file mode 100644 >>> index 0000000000..c4802bf4d1 >>> --- /dev/null >>> +++ b/OvmfPkg/XenResetVector/Ia32/XenPVHMain.asm >>> @@ -0,0 +1,47 @@ >>> +;------------------------------------------------------------------------------ >>> +; @file >>> +; An entry point use by Xen when a guest is started in PVH mode. >>> +; >>> +; Copyright (c) 2019, Citrix Systems, Inc. >>> +; >>> +; This program and the accompanying materials are licensed and made >>> available >>> +; under the terms and conditions of the BSD License which accompanies this >>> +; distribution. The full text of the license may be found at >>> +; http://opensource.org/licenses/bsd-license.php >>> +; >>> +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, >>> WITHOUT >>> +; WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. >>> +; >>> +;------------------------------------------------------------------------------ >>> + >>> +BITS 32 >>> + >>> +xenPVHMain: >>> + mov di, 'BP' >>> + >>> + ; ESP - Initial value of the EAX register (BIST: Built-in Self Test) >>> + mov esp, eax >> Where is the ABI described? Xen has no BIST, so this will always have >> the value 0. Stashing it in the stack pointer seems like a weird choice, >> and a recipe for subtle bugs. > I've just copied over what was done in the HVM case. I'll change that > and ignore the value in `eax'.
The ASCII BP in %di is also bizarre without an explanation of where it is intended to be used. >>> + >>> + mov eax, SEC_DEFAULT_CR0 >>> + mov cr0, eax >>> + >>> + jmp LINEAR_CODE_SEL:ADDR_OF(.jmpToNewCodeSeg) >>> +.jmpToNewCodeSeg: >>> + >>> + mov eax, SEC_DEFAULT_CR4 >>> + mov cr4, eax >>> + >>> + mov ax, LINEAR_SEL >>> + mov ds, ax >>> + mov es, ax >>> + mov fs, ax >>> + mov gs, ax >>> + mov ss, ax >>> + >>> + ; return to the Main16 >>> + OneTimeCallRet TransitionFromReal16To32BitFlat >> Is there any description of what OneTimeCallRet is, and why a simple jmp >> wont do? > That's is used to return to where the `OneTimeCall' macro has been > used. In this assembly, they don't use `call' and `ret', instead there > is a set of two macros: > > %macro OneTimeCall 1 > jmp %1 > %1 %+ OneTimerCallReturn: > %endmacro > > %macro OneTimeCallRet 1 > jmp %1 %+ OneTimerCallReturn > %endmacro I found these, but the complete lack of any documentation makes them entirely opaque, especially as they are not actually call/ret instructions. Even if they are suppose to be used in matching pairs, OneTimeCall hasn't been used so far in the PVH code, so where is this going to actually go to? ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
