similar to: [PATCH RFC v2 0/7] Make OVMF fully working with Xen

Regarding patches 5-7, it seems like the mem-map code flow could be more shared. It is a bit challenging to unravel things though. I guess the only specific thing I can really point out is that PcdPciAllowFullEnumeration should be initialized in a different patch, and not within the mem-map init path. -Jordan On Tue, Nov 19, 2013 at 12:38 PM, Wei Liu <wei.liu2@citrix.com> wrote: > This

EFI_XEN_OVMF_INFO is defined to accept configurations from hvmloader. It must match the definition on Xen side. XenInfo is extended to include necessary bits as well. Currently only E820 map is in use. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- OvmfPkg/Include/Guid/XenInfo.h | 7 +++++++ OvmfPkg/PlatformPei/Xen.h | 44

On Sat, Nov 16, 2013 at 3:31 AM, Jordan Justen <jljusten@gmail.com> wrote: > When I try to boot this on qemu or kvm, it asserts because the video > framebuffer address is NULL. > That''s expected because of the hack. ;-) > On Fri, Nov 15, 2013 at 7:58 AM, Wei Liu <wei.liu2@citrix.com> wrote: >> This is a quick hack I pulled together last night to make OVMF

On Fri, Jul 21, 2017 at 06:17:15AM -0500, Brijesh Singh wrote: > > On 7/20/17 10:24 PM, Jason Wang wrote: > > > > > > On 2017?07?20? 06:09, Brijesh Singh wrote: > >> I have found that OVMF fails to detect the disk when iommu_platform > >> is set from > >> qemu cli. The failure occurs during the feature bit negotiation. > >> > >>

On Fri, Jul 21, 2017 at 06:17:15AM -0500, Brijesh Singh wrote: > > On 7/20/17 10:24 PM, Jason Wang wrote: > > > > > > On 2017?07?20? 06:09, Brijesh Singh wrote: > >> I have found that OVMF fails to detect the disk when iommu_platform > >> is set from > >> qemu cli. The failure occurs during the feature bit negotiation. > >> > >>

E820 definitions copied from IntelFrameworkModulePkg/Csm/ LegacyBiosDxe/LegacyBiosInterface.h. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> --- OvmfPkg/Include/IndustryStandard/E820.h | 46 +++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode

On Thu, Nov 14, 2013 at 08:42:39AM -0800, Andrew Fish wrote: [...] > > > > >From a UEFI spec perspective you only need to produce EFI_PCI_ROOT_BRIGE_IO_PROTOCOL and a EFI_PCI_IO_PROTOCOL per device. This is all that is required to make generic UEFI code (all the PCI drivers, shell commands, etc.) work. > > The

On 09/09/20 10:27, Ard Biesheuvel wrote: > (adding Laszlo and Brijesh) > > On Tue, 8 Sep 2020 at 20:46, Borislav Petkov <bp at alien8.de> wrote: >> >> + Ard so that he can ack the efi bits. >> >> On Mon, Sep 07, 2020 at 03:16:12PM +0200, Joerg Roedel wrote: >>> From: Tom Lendacky <thomas.lendacky at amd.com> >>> >>> Calling

Hi Rui, I still fail to enable the lld in my Uefi firmware build to replace ld, and I found it is related to the wrong symbol values in the .data section, which are pointed by R_X86_64_64 relocation entries. I need your advices. My firmware uses a linker script https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/GccBase.lds to do the linking. We use position independent code with

Hi Rui, > but why don't you use lld-link (lld for Windows target) instead of ld.lld (lld for Unix target) to create UEFI applications? I need support both PE/COFF and ELF format tools. I’m also working on the lld-link enabling (clang-cl + lld-link) in both Linux and windows. The ld.lld enabling (clang + ld.lld) is for ELF format native users. E.g.

Hi Rui, A quick question: Does lld-link only work with clang-cl with windows-msvc option? Can lld-link work with clang with linux-gnu option? Thanks Steven Shi Intel\SSG\FID\Firmware Infrastructure From: Shi, Steven Sent: Tuesday, January 29, 2019 1:32 PM To: 'Rui Ueyama' <ruiu at google.com> Cc: llvm-dev at lists.llvm.org Subject: RE: lld write wrong symbol value in .data

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz> --- tools/firmware/ovmf-makefile | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/tools/firmware/ovmf-makefile b/tools/firmware/ovmf-makefile index 073ed44..efb4fb1 100644 --- a/tools/firmware/ovmf-makefile +++ b/tools/firmware/ovmf-makefile @@ -1,3 +1,6 @@ +XEN_ROOT = $(CURDIR)/../../.. +include

On Sat, Jun 8, 2013 at 7:39 PM, Laszlo Ersek <lersek at redhat.com> wrote: > Patches before the last are small cleanups. > > In the last patch I'm trying to extract / generalize an idea from Stefan > Hajnoczi's review of my virtio-net driver for OVMF. > > Unfortunately I can't find Stefan's email on any mailing list archive > (sourceforge, gmane,

Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz> Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- tools/firmware/ovmf-makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/firmware/ovmf-makefile b/tools/firmware/ovmf-makefile index c3cd466..073ed44 100644 --- a/tools/firmware/ovmf-makefile +++ b/tools/firmware/ovmf-makefile @@ -10,7 +10,7

> It is a "generic example" which differs from the "actual example" on Fedora. ;) > Someone may favor wiki style, then again someone graces the source doc style. > What is important, none of them is a redundant, that is, they complement each other. > Patching for Fedora (or for whichever other distro) in upstream Syslinux should only be done when it would affect

On 07.03.2016 19:24, Ady via Syslinux wrote: >> doc: keytab-lilo example on Fedora >> >> --- >> doc/keytab-lilo.txt | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/doc/keytab-lilo.txt b/doc/keytab-lilo.txt >> index cdbea0f..f35b3e8 100644 >> --- a/doc/keytab-lilo.txt >> +++ b/doc/keytab-lilo.txt >> @@ -83,3 +83,7 @@

Patches before the last are small cleanups. In the last patch I'm trying to extract / generalize an idea from Stefan Hajnoczi's review of my virtio-net driver for OVMF. Unfortunately I can't find Stefan's email on any mailing list archive (sourceforge, gmane, mail-archive etc. all have only my response), so I'll quote it here. The patch Stefan was reviewing is

Patches before the last are small cleanups. In the last patch I'm trying to extract / generalize an idea from Stefan Hajnoczi's review of my virtio-net driver for OVMF. Unfortunately I can't find Stefan's email on any mailing list archive (sourceforge, gmane, mail-archive etc. all have only my response), so I'll quote it here. The patch Stefan was reviewing is

On Tue, 7 Apr 2015, Laszlo Ersek wrote: > Whereas syslinux.efi apparently uses the embedded gpxe/ tree, and that > one uses TCP timestamps. See tcp_xmit() in gpxe/src/net/tcp.c: Actually syslinux.efi seems to be using the implementation calling into UEFI via these functions: http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/efi/tcp.c I've tried to add debug messages to these

Hi, Didier Spaier wrote: > The issue is the inability of booting of a *physical* (not virtual) optical > media, like for instance a DVD or a CD, using syslinux.efi. Actually firmware cannot find any UEFI specified booting starting points in an ISO 9660 filesystem that was created with mkisofs -b and -hard-disk-boot, but without a boot image which was marked as EFI System Partition. The