Reviewed-by: Anthony PERARD <anthony.perard@...> Thanks,

Acked-by: Anthony PERARD <anthony.perard@...> Thanks,

From: Anthony PERARD <anthony.perard@...> VerifyBlob() has been added recently to QemuKernelLoaderFsDxe, also QemuKernelLoaderFsDxe has also been added recently to OvmfXen but without an implem

Reviewed-by: Anthony PERARD <anthony.perard@...> Thanks,

Acked-by: Anthony PERARD <anthony.perard@...> Thanks,

The part about acpi_s3 isn't true, it doesn't affect fw_cfg. Maybe this paragraph would be better: This issue mainly affects "HVM Direct Kernel Boot". When used, "fw_cfg" is enabled in QEMU and QemuFw

It doesn't. "acpi_s3" doesn't have any control over PcdAcpiS3Enable, and doesn't have any control over QEMU, so QEMU would probably always say S3 is available. What happen when "acpi_s3" is set or not

It would have been nice to have this patch in a patch series with "OvmfPkg/OvmfXen: add QemuKernelLoaderFsDxe", mostly to make it simpler to understand the problem needed to be fixed. This sounds like

Acked-by: Anthony PERARD <anthony.perard@...> And now I understand what the patch "OvmfPkg/OvmfXen: set PcdAcpiS3Enable at initialization" is about. "HVM Direct Kernel Boot" with OVMF simply do

QemuFwCfgS3Enabled() should always return false as we don't enable QEMU's fwcfg interface in most case when running a Xen guest. So I don't expect "PcdAcpiS3Enable" to ever been set via this patch. No

From: Anthony PERARD <anthony.perard@...> Unfortunately, Xen isn't ready to deal with mapping at the top of the physical address space, so we relocate the mapping after the LAPIC location. See

Hi Laszlo, OvmfXen seems to be working fine with that branch applied. Thanks,

Calculate the frequency of the APIC timer that Xen provides. Even though the frequency is currently hard-coded, it isn't part of the public ABI that Xen provides and thus may change at any time. OVMF

Some information available in a Xen guest can be mapped anywhere in the physical address space and they don't need to be backed by RAM. For example, the shared info page. While it's easier to put thos

Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct value when SecPeiDxeTimerLibCpu start to use it for the APIC timer. Currently, nothing appear to use the value in PcdFSBClock bef

We are going to use the page table structure in yet another place, collect the types and macro that can be used from another module rather than making yet another copy. Ref: https://bugzilla.tianocore

We are going to use new fields from the Xen headers. Apply the EDK2 coding style so that the code that is going to use it doesn't look out of place. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id

We are going to want to change the value of PcdFSBClock at run time in OvmfXen, so move it to the PcdsDynamic section. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony P

To avoid nasm generating a warning, replace the macro by the value expected to be stored in eax. Ia32/XenPVHMain.asm:76: warning: dword data exceeds bounds Reported-by: Laszlo Ersek <lersek@...

Patch series available in this git branch: git://xenbits.xen.org/people/aperard/ovmf.git br.apic-timer-freq-v3 Changes in v3: - typos and codying style Changes in v2: - main change is to allow mapping