Skip to content

Conversation

@jongwu
Copy link

@jongwu jongwu commented Apr 9, 2021

UEFI image for virtual platform on arm64 is not formatted,
so I add a specific loader for it here.

Signed-off-by: Jianyong Wu jianyong.wu@arm.com

@aghecenco @andreeaflorescu

Copy link
Member

@andreeaflorescu andreeaflorescu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really know much about UEFI. Do you also have an example of how this is used?

Can you also add some tests?

Comment on lines 184 to 185
/// uefi image for virtual machine on arm64 is not formatted, so
/// a special loader for it is needed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this needs to be part of the public interface documentation.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I will remove it.

}
}

/// load uefi for aarch64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: can you format the comment similar to how other comments are formatted: Load UEFI image in guest memory.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, thanks

/// * `guest_addr` - The offset in guest_mem from which the UEFI image will be loaded.
/// * `uefi_image` - The UEFI image
#[cfg(target_arch = "aarch64")]
pub fn load_uefi<F, M: GuestMemory>(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code of this functions is rather similar to load_dtb, can you refactor to reduce some duplicate code?

@jongwu
Copy link
Author

jongwu commented Apr 13, 2021

@andreeaflorescu -, Thanks for reply.
Yeah, It's fine to use this UEFI image loader even having little knowledge about it. You can simply take UEFI image like a kernel image and load it. As the kernel image format is different from the UEFI image on arm64, we need some twists on the kernel loader. Roughly, remove the header check and set the entry point of UEFI image as its very beginning then we get a new loader. That is what this patch does. So easy isn't? Here is an example of how to use it:
let entry_point = linux_loader::loader::pe::load_uefi(
mem.deref(), // Guest memory where UEFI image should be loaded
GuestAddress(arch::get_uefi_start()), // The offset in guest memory from which the UEFI image will be loaded
&uefi_image,
)
we load the uefi_image to mem.deref() at GuestAddress(arch::get_uefi_start()) and get the entry point in "entry_point", then we can set the PC in guest as entry_point and begin to run.

@rbradford
Copy link
Collaborator

For loading a UEFI/OVMF on Cloud Hypervisor with x86-64 we used the PVH (like Xen) support so that we didn't need to modify linux-loader or the VMM. I see that ArmVirtPkg also supports Xen: https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtXen.fdf

If you can make that work then I think that would a a cleaner approach.

@rbradford
Copy link
Collaborator

For loading a UEFI/OVMF on Cloud Hypervisor with x86-64 we used the PVH (like Xen) support so that we didn't need to modify linux-loader or the VMM. I see that ArmVirtPkg also supports Xen: https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtXen.fdf

If you can make that work then I think that would a a cleaner approach.

Oh, I think i misunderstood. This is a loader for the UEFI PE format rather than for a UEFI firmware blob. What's your use case for this?

@jongwu
Copy link
Author

jongwu commented Apr 13, 2021

Hello @rbradford -, for now, the UEFI image on arm64 virtual platform (eg, qemu, kvmtool) is not formatted, not a pe or elf. Unfortunately, we have no such a loader to load a file without header in it.
In my case, I want to introduce UEFI support in cloud-hypervisor on arm64, but I can't load the UEFI as there is lack of a suitable loader. That's why I want to introduce a new one here.

UEFI image for virtual platform on arm64 is not formatted,
so we add a specific loader for it here.

Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
@jongwu
Copy link
Author

jongwu commented Apr 19, 2021

Hi @andreeaflorescu -, any comments?
I have updated this patch, adding a test for load_uefi and amending the annotation.

@andreeaflorescu
Copy link
Member

Hi @andreeaflorescu -, any comments?
I have updated this patch, adding a test for load_uefi and amending the annotation.

Thanks, I can take another look in a couple of days. Can you share an example of how this is used in practice? Do you happen to have a patch that adds this support in Cloud Hypervisor?

@rbradford since it looks like this support is going to end up in Cloud Hypervisor, can you also please take a look at this PR?

@michael2012z
Copy link

@andreeaflorescu , there is a PR in Cloud-hypervisor that includes the WIP commits for UEFI & ACPI support for AArch64.

The code to call this new function is like this: cloud-hypervisor/cloud-hypervisor@9742ecd#diff-9c91c6326e9d86ef107a59aed3f13a9bb91790f9f4be1668d22cda12a28bc28cR905

The UEFI binary is header-less, it's impossible to recognize it by format.
So the logic is: At first try to load the binary as PE; if the format is wrong, try to load it as UEFI.

@jongwu
Copy link
Author

jongwu commented Jun 2, 2021

Hello @andreeaflorescu -, could you please take a look of this patch? We have a PR in Cloud Hypervisor to enable Acpi on arm64 which depends on this patch. Also, you can find the use case of the new handler added in this patch here

We have blocked here so long, thus I'm very appreciate if there is any progress on this PR. Thanks!

@andreeaflorescu
Copy link
Member

@jongwu I can only provide high level feedback, and that might not be very meaningful. Can someone from Cloud Hypervisor review this since it is going to be used there? You should not block on my approval as I really do not have enough context.

Copy link
Collaborator

@rbradford rbradford left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like it doesn't do much more than read the file into guest memory. Maybe it makes sense to just do that in CH?

@jongwu
Copy link
Author

jongwu commented Jun 3, 2021

Thanks @rbradford @andreeaflorescu -, since we can do this change in CLH, I will close this.

@jongwu jongwu closed this Jun 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants