Re: [edk2] OVMF Xen ACPI tables

Subject: Re: [edk2] OVMF Xen ACPI tables

From: Bei Guan <>

To: Andrei Warkentin <>

Date: 2011-07-29 23:25:08

Hi Andrei,

I have done the layout of Xen Hypercall inside OVMF. The patches based on the latest edk2 (r12056) are available at
(Xen PV Protocol Dxe)
(A simple test of Xen PV Protocol)
(Changes for OVMF config files)

A short description:
1)OvmfPkg/ParaVirtualizationDxe installs the Xen Pv protocol EFI_XEN_HV_PROTOCOL. OtherDxe can consume the protocol in itself. This isdemonstratedinOvmfPkg/HypercallTestDxe.
2) Theprotocol EFI_XEN_HV_PROTOCOL is implemented inOvmfPkg/Include/Protocol/Hypercall.h. I put all the Xen hypercalls (38+8) in protocol struct as its methods.
3) InOvmfPkg/ParaVirtualizationDxe/Hypercall.c, I just added one hypercall implementation (HypervisorXenVersion) as an example. Later, we can add more in this file when we need them. All the hypercall call one EFI ABI fucntion, which take 7 parameters like this
Hypercall (
IN VOID *HypercallPageAddress, // Address of hypercall page
IN UINTN HypercallOffset, // Hypercall Offset ( = hypercall num * 32)
IN UINTN Arg1, // parameters
IN UINTN Arg2, //
IN UINTN Arg3, //
IN UINTN Arg4, //
IN UINTN Arg5 //

This function is implemented in X64 and IA32. SeeOvmfPkg/ParaVirtualizationDxe/[Ia32 | X64]/GasketHypercall.S.
Is we need to write the .asm files? When the .asm file will be used?

4) I just test one hypercall (HypervisorXenVersion) in OVMF, and from the boot tracing message (see below) we can see that we can get the xen version correctly.

Boot Tracing Message:
Loading driver at 0x0001F721000 EntryPoint=0x0001F721240 ParaVirtualizationDxe.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F544790
[TestInfo_CallHypercallInsideXenPvDXE]OVMF is running on Xen version: 4.2
[TestInfo_CallHypercallInsideXenPvDXE]Detected Xen -unstable
InstallProtocolInterface: 90D9933F-0F3F-4027-AA7C-0544B662385F 1F7230BC
Loading driver 9169E45E-5DB7-4B5C-9D1E-016FEC787C2C
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 1F5A94A8
Loading driver at 0x0001F71E000 EntryPoint=0x0001F71E240 HypercallTestDxe.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F544210
[TestInfo_CallHypercallFromOtherDXE]OVMF is running on Xen version: 4.2
[TestInfo_CallHypercallFromOtherDXE]Detected Xen -unstable
Loading driver F80697E9-7FD6-4665-8646-88E33EF71DFC
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 1F5A9328


2011/7/22 Andrei Warkentin <>
On Thu, Jul 21, 2011 at 11:41 AM, Bei Guan <> wrote:
> Secondly, now I know the inline assembler _hypercall2(type, name,
> hypercall_page, a1, a2) cannot be used in edk2. So, as Andrew and Jordan
> said, I need to create .S/.asm assembly files, in which a function like this
> ASM_GLOBAL ASM_PFX(Hypercall2)
> ASM_PFX(Hypercall2):
> <assembler instruction>
> does the same thing as _hypercall2(type, name, hypercall_page, a1, a2).
> But, I am not sure how to write the <assembler instruction> for function
> Hypercall2. Do I need to use the "objdump" to see the the assembler
> instruction of the _hypercall2(type, name, hypercall_page, a1, a2) first?
> Would you give me some suggestions on this?

You would do something similar to what Andrew suggested. I recommend you write
1 function that takes 7 parameters -
1) Hypercall page.
2) Hypercall #.
3) Hypercall parameters 1 through 5.

And does (for X64) -
0) Save callee-save registers.
1) Move hypercall parameters into %rdi, %rsi, %rdx, %r10, %r8
2) Computes actual call address from hypercall # and page, placing it into RAX
3) Call through *rax.
4) Restore calee-save registers.