Subject: Re: [edk2] Xen OVMF early discussions
From: Bei Guan <email@example.com>
To: Andrei Warkentin <firstname.lastname@example.org>
Date: 2011-06-10 02:56:08
2011/5/30 Andrei Warkentin <email@example.com>Bei,
I'm not sure what the confusion is here. If you attach a disk image,
> Is there any way to read the file in a device with blk mapping? If not, do
> we need to add this functionality to OVMF? Because Xen can't not support the
> FAT partition just like qemu, we can't run EFI applications in EFI Shell. If
> we have to add this function, how about the workload of its? Could you have
> any advice on this work?
which contains a fat partition with your files, you will have an
fs-mapping provided you've built the FAT filesystem driver into the
So create a disk image that contains an MBR partition table, and a
single FAT partition on it, format the later, and add some files to
it. You should be able to "dir fs0:" in EFI shell.
Depending on the version of your Dom0 kernel, you either have
partionable loop devices (i.e. you get entries like
/dev/block/loop0p1, etc...), or you have to play offset tricks with
mounting. This is a good start - http://wiki.osdev.org/Loopback_Device
This isn't an OVMF task. When you pass "-hda fat:/root/tmp" QEMU fakes
> Andrei, what's your opinion about extending OVMF to support reading files
> from a device with blk mapping, which I have give the reason for before?
> Alternatively, maybe we can extending Xen to supporting FAT partition like
> qemu. That's to implement a functionality like supporting "-hda
> fat:/root/tmp/" in qemu. However, I also don't know any about the workload.
> What's your opinion about this?Is there any other good way to run EFI
> applications in EFI Shell for OVMF on Xen?
a disk images with a FAT partition containing the directory structure
specified. As far as UEFI is concerned it's still and ATA disk with a
You could, of course, aim to backport said feature to the Xen QEMU if
that's not there already, but this isn't really related to OVMF.
Additionally, I'm sure someone on Xen is already working on moving to
latest QEMU branch, Tim can comment better on this :-).
After you verify HD, you can verify CDROM. You will need to find a
UEFI-bootable CD, something like
On 64-bit OVMF of course. You can also try booting via that if you're
brave ;-). You should verify all OVMF-on-QEMU functionality on
After that there are several things to do -
1) Pass-through hvmloader's SMBIOS and ACPI tables (publish them
inside UEFI, so booted OSes can use them)Do you mean that we need toenablehvmloader'sSMBIOS and ACPI tables, and then make UEFI can access them through paravirtualized?There is also SMBIOS and ACPI tables in OVMF. Is it? So, what we need to do is1) tomake UEFI can accesshvmloader'sSMBIOS and ACPI tablesthrough paravirtualized;2)toset the OVMF's SMBIOS and ACPI tables according to thehvmloader'sSMBIOS and ACPI tables.Is it right?2) Start working on making OVMF more Xen aware as per your timeline
(Hypercall interface, xenbus, etc...)I think this task is similar to any other projects that has used the Xen PV divers. At least the the main frame is very similar to, is it? So maybe I can refer to them.Thanks,Bei