Re: [edk2] OVMF Xen ACPI tables

Subject: Re: [edk2] OVMF Xen ACPI tables

From: Andrei Warkentin <>

To: Tim Deegan <>

Date: 2011-07-21 00:21:15

On Wed, Jul 20, 2011 at 3:17 PM, Tim Deegan  wrote:
> Hi,
> At 20:32 +0100 on 20 Jul (1311193957), Andrei Warkentin wrote:
>> On Wed, Jul 20, 2011 at 2:24 PM, Andrew Fish  wrote:
>> > OK I think the __asm__ code is massively complex, as it has been optim=
ized for speed. =A0The call instruction to a label is a relative offset, an=
d that is what is driving the complexity in this macro. If you are willing =
to add a few more instructions it can be done from C code.
>> >
> If I'm following this correctly, this was taken from the hypercall code
> in hvmloader, right? =A0In that case I should point out this changeset
> from today which fixes it up to avoid relative offsets, and avoids the
> ugly STR()s:
>> > I agree with Jordan, write a C library to make the calls. You don't ne=
ed inline assembler. You can typedef function prototypes for the various ca=
lls, like my HYPER_CALL typedef in the example. Then if you know the magic =
address you can just make a call.
>> Agreeing with Andrew and Jordan. Bei, think first about what the code
>> is trying to accomplish. Does the calling interface match the
>> architecture ABI - i.e. are parameters passed the same way as they
>> would to a function?
> For 32-bit x86 the C calling convention depends on what system you're
> compiling it on, so you can't rely on it in portable code. =A0The Xen ABI
> is like this:
> /*
> =A0* Hypercall interface:
> =A0* =A0Input: =A0%ebx, %ecx, %edx, %esi, %edi (arguments 1-5)
> =A0* =A0Output: %eax
> =A0* Access is via hypercall page (set up by guest loader or via a Xen MS=
> =A0* =A0call hypercall_page + hypercall-number * 32
> =A0* Clobbered: Argument registers (e.g., 2-arg hypercall clobbers %ebx,%=
> =A0*/

And for X64 it's:
Input: %rdi, %rsi, %rdx, %r10, %r8
Output: %rax
 Access is via hypercall page (set up by guest loader or via a Xen MSR):
 call hypercall_page + hypercall-number * 32

Clobbered: argument registers.

> Is there a particular coding-style problem with using asm in OVMF? =A0Are
> you trying to avoid GCCisms? =A0Or is it just that you'd prefer C-function
> wrappers to #defines?

EDK, due to compiler independence, doesn't use inline assembly. So in
OVMF case an assembly stub
(in .S and .asm) should be sufficient, that take the arguments per ABI
(as well as hypercall number and hypercall page addy) and invokes the

>> You've mentioned in a previous email to me that the Xen-UNSTABLE tree
>> has diverged sufficiently that your current patches do not apply.
>> Jordan and Tim - should reworking the Xen hvmloader patches be a
>> higher priority than making OVMF aware of virtualization? I would say
>> yes, after all, one of the main goals of this GSoC was to integrate
>> booting OVMF inside HVM into Xen.
> I think now would be a good time to post your hvmloader patches to
> xen-devel for feedback; if they still need work then post them as RFC.
> There's been some work on getting SeaBIOS to work with Xen as well so
> the engineers who did that may have some useful feedback.

Bei, I would strongly advise -
1) Get feedback from xen-devel.
2) Refactor the xen-unstable changes on top of Xen-UNSTABLE.
3) Seek timely inclusion of these in Xen-UNSTABLE.

I would love for you to be able to complete OVMF enhancements to use
virtual over emulated devices, but
not at the expense of finishing this GSoC without at least basic
OVMF-on-Xen support merged.


10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
edk2-devel mailing list