Re: [edk2] Xen OVMF early discussions

Subject: Re: [edk2] Xen OVMF early discussions

From: Bei Guan <gbtju85@gmail.com>

To: Andrei Warkentin <andreiw@motorola.com>

Date: 2011-06-10 02:56:08

Hi,

In our project, OVMF is loaded on the high memory under 4G by xen hvmloader. In this case, does OVMF can access to the lower memory 0x00000 - 0xF0000 where Xen SMBIOS has been loaded?

Thanks,
Bei Guan



2011/6/2 Bei Guan <gbtju85@gmail.com>


2011/5/30 Andrei Warkentin <andreiw@motorola.com>
Bei,

> 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?

I'm not sure what the confusion is here. If you attach a disk image,
which contains a fat partition with your files, you will have an
fs-mapping provided you've built the FAT filesystem driver into the
firmware.

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

> 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?
>

This isn't an OVMF task. When you pass "-hda fat:/root/tmp" QEMU fakes
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
FAT partition.

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
http://ftp.ussg.iu.edu/linux/fedora/linux//releases/15/Fedora/x86_64/iso/Fedora-15-x86_64-netinst.iso.
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
OVMF-on-XEN.

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 is
1) 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

A