Re: [Xen-devel] [ipxe-devel] Tips on how to debug EFI code (iPXE) from within KVM after ipxe.efi has crashed with #GP?

On 09/28/17 20:04, Michael Brown wrote: > On 28/09/17 18:37, Konrad Rzeszutek Wilk wrote: >> !!! X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - >> >> ExceptionData - >> RIP  - BEC2949C, CS  - 0038, RFLAGS - >> 00210216 >>

Re: [Xen-devel] [edk2] [PATCH] Maintainers.txt: update OvmfPkg maintainership

Hello Konrad, On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote: > On Thu, Aug 17, 2017 at 01:47:59AM +0200, Laszlo Ersek wrote: >> On 08/17/17 00:37, Jordan Justen wrote: >>> On 2017-08-16 12:23:49, Leif Lindholm wrote: >> >> [snip] >> >>>> - the

Re: [Xen-devel] Is: Fix for 4MB BIOS payload in hvmloader. Was:Re: [edk2] [PATCH 0/5] OvmfPkg: complete the 4MB flash image support ("-bios" / emulated variables)

On 05/23/17 17:02, Julien Grall wrote: > Hi, > > On 23/05/17 15:12, Konrad Rzeszutek Wilk wrote: The primary location for reporting bugs against the hypervisor and associated bundled tools [...] is by posting to the xen-devel mailing list (list info). Please tag your subject line wi

Re: [Xen-devel] Is: Fix for 4MB BIOS payload in hvmloader. Was:Re: [edk2] [PATCH 0/5] OvmfPkg: complete the 4MB flash image support ("-bios" / emulated variables)

On 05/23/17 17:01, Jan Beulich wrote: >>>> On 23.05.17 at 16:12, wrote: >> On Thu, May 18, 2017 at 02:36:33PM +0200, Laszlo Ersek wrote: >>> The situation is further hampered by the fact that Xen is (apparently) >>> right at 4.9.0-rc5, so they likely won'

Re: [Xen-devel] [edk2] [PATCH RFC 06/14] OvmfPkg/XenPlatformPei: Add xen PVH specific code

On 01/10/17 17:18, Anthony PERARD wrote: > On Thu, Jan 05, 2017 at 11:30:32AM +0100, Laszlo Ersek wrote: >> On 12/08/16 16:33, Anthony PERARD wrote: >>> - learn about memory size from the E820 >>> - ignore error if host bridge devid is 0x, PVH does not have

Re: [Xen-devel] [edk2] [PATCH RFC 14/14] XenOvmf: Use a different RTC

On 12/08/16 16:33, Anthony PERARD wrote: > --- > OvmfPkg/XenOvmf.dsc | 5 - > OvmfPkg/XenOvmf.fdf | 2 +- > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc > index a7a884e..345157b 100644 > --- a/OvmfPkg/XenOvmf.dsc > +++ b/OvmfPkg/X

Re: [Xen-devel] [edk2] [PATCH RFC 13/14] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables

On 12/08/16 16:33, Anthony PERARD wrote: > This "device" use XenIoMmioLib to reserve some space to be use by grant > tables. It's use 0xfc00, which might not be a good choice... > > There is probably a better way that using a device for this. > --- > OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c | 263

Re: [Xen-devel] [edk2] [PATCH RFC 12/14] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn

On 12/08/16 16:33, Anthony PERARD wrote: > and add OvmfPkg/XenConsoleIo/XenConsoleIo to XenOvmf platform. > > It actually look for gEfiSerialIoProtocolGuid. > --- > .../Library/PlatformBootManagerLib/BdsPlatform.c | 33 > ++ > .../PlatformBootManagerLib.inf

Re: [Xen-devel] [edk2] [PATCH RFC 11/14] OvmfPkg/XenOvmf: Adding XenTimerLocalApic

On 12/08/16 16:33, Anthony PERARD wrote: > And replacing the ACPI Timer by this one based on the local APIC. > > ACPI Timer does not work in a PVH guest, but local APIC works on both > PVH and HVM. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Anthony PERARD > ---

Re: [Xen-devel] [edk2] [PATCH RFC 09/14] OvmfPkg/ResetSystemLib: Add missing dependency on PciLib

On 12/08/16 16:33, Anthony PERARD wrote: > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/OvmfPkg/Library/ResetSystemLib/ResetSystemLib.inf

Re: [Xen-devel] [edk2] [PATCH RFC 08/14] OvmfPkg/PlatformBootManagerLib: Workaround missing PCI bus on Xen PVH

On 12/08/16 16:33, Anthony PERARD wrote: > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPla

Re: [Xen-devel] [edk2] [PATCH RFC 07/14] OvmfPkg/XenResetVector: Add new entry point for Xen PVH

On 12/08/16 16:33, Anthony PERARD wrote: > This one enter directly in 32bits > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/XenResetVector/Ia16/ResetVectorVtf0.asm | 79 > + > OvmfPkg/XenResetVector/Ia32/XenPVH

Re: [Xen-devel] [edk2] [PATCH RFC 06/14] OvmfPkg/XenPlatformPei: Add xen PVH specific code

On 12/08/16 16:33, Anthony PERARD wrote: > - learn about memory size from the E820 > - ignore error if host bridge devid is 0x, PVH does not have PCI and > reading from unexisting device return -1. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Anthony PERARD >

Re: [Xen-devel] [edk2] [PATCH RFC 05/14] OvmfPkg/Library: add XenPciHostBridgeLib

On 12/08/16 16:33, Anthony PERARD wrote: > A copy of OvmfPkg/Library/PciHostBridgeLib > > Removing support for pci bus enumeration, I think, and only use scan of > already enumerated pci bus. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Anthony PERARD > --- > ...

Re: [Xen-devel] [edk2] [PATCH RFC 04/14] OvmfPkg: Introduce XenPlatformPei

On 12/08/16 16:33, Anthony PERARD wrote: > A copy of OvmfPkg/PlatformPei without some of QEMU specific > initialization, Xen does not support QemuFwCfg. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/XenOvmf.dsc |

Re: [Xen-devel] [edk2] [PATCH RFC 00/14] Specific platform to run OVMF in Xen PVH and HVM guests

On 12/08/16 16:33, Anthony PERARD wrote: > Hi, > > I've started to create a Xen specifig plaform, in OvmfPkg/XenOvmf.dsc > with the goal to make it work on both Xen HVM and Xen PVHv2 Does this mean we can ultimately move all Xen roles from the current platform DSC files to the new Xen DSC file en

Re: [Xen-devel] [edk2] [PATCH RFC 03/14] OvmfPkg/XenOvmf.dsc: Introduce XenResetVector

(1) I think the subject line should just say: OvmfPkg: Introduce XenResetVector (2) New files are added in this patch; you might want to tag them with a Citrix copyright notice. (3) When formatting the next version of this series for posting, please pass the "-C --find-copies-harder" options t

Re: [Xen-devel] [edk2] [PATCH RFC 02/14] OvmfPkg/XenOvmf: Update debug IO port for Xen

ibIoPort > + gUefiOvmfPkgTokenSpaceGuid.PcdDebugIoPort|0xe9 > + > > > # > # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this > Platform > This patch looks good to me: Reviewed-by: Laszlo Ersek But I ask that in the next po

Re: [Xen-devel] [edk2] [PATCH RFC 01/14] OvmfPkg: Create platform XenOvmf

On 12/08/16 16:33, Anthony PERARD wrote: > This is a copy of OvmfX64, removing VirtIO and some SMM. (1) Please provide more details in the commit message: - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION - removed: VirtioLib class resolution - removed: DXE_SMM_DRIVER and SMM_CORE lib

Re: [Xen-devel] [PATCH v3] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

ly GCC < 4.4, like GCC 1. > > Reviewed-by: Laszlo Ersek > Reviewed-by: Jordan Justen > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=62 > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Konrad Rzeszutek Wilk > --- > v1: Initial > v2: Redo it

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

On 11/23/16 16:01, Konrad Rzeszutek Wilk wrote: > On Wed, Nov 23, 2016 at 03:55:11PM +0100, Laszlo Ersek wrote: >> On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote: >>> From Laszlo: >>> " change the catch-all (*) to GCC5, from GCC44 >>> - remove the (5.*

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

On 11/23/16 15:55, Laszlo Ersek wrote: > On 11/23/16 03:36, Konrad Rzeszutek Wilk wrote: >> From Laszlo: >> " change the catch-all (*) to GCC5, from GCC44 >> - remove the (5.*.*) pattern from GCC49 >> - add a branch (with multiple patterns if necessary) for gcc-4.3

Re: [Xen-devel] [PATCH v2] OvmfPkg/build.sh: Make GCC5 the default toolchain, catch GCC43 and earlier

are you okay if I replace it with a plain 0 on commit? * Also, IIRC, Olaf considered pre-4.0 gcc releases as well (rejecting them of course), which is sort of meant as part of "gcc-4.3 and earlier". But, given your extensive testing with old distros (thanks for that!), I think it's safe

Re: [Xen-devel] [edk2] [PATCH RESEND] OvmfPkg/build.sh: Use GCC49 toolchain with GCC 6.*

On 11/21/16 17:20, Ard Biesheuvel wrote: > On 21 November 2016 at 15:56, Konrad Rzeszutek Wilk wrote: >> Without this I cannot build it under Fedora Core 25. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Konrad Rzeszutek Wilk >> --- >> OvmfPkg/build.sh | 2 +- >>

Re: [Xen-devel] [edk2] edk2 compile error

On 09/18/16 05:38, Chen, Farrah wrote: > Hi, > > When I compile xen with the latest commit in RHEL 6.7, it failed when make > tools. Errors showed when running edk2 build for OvmfPkgX64. > Bisected and this error occurred from commit > 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2. > > commit 8c8b6f

Re: [Xen-devel] OVMF for Xen PVH

On 09/08/16 11:38, Anthony PERARD wrote: > Hello, > > We are introducing a new virtualisation mode in Xen called PVHv2 (also > called hvmlite in the past). We would like to have a UEFI firmware > running on it to make it easier to start a guest. (Right now, I think it > involves supplying the gues

Re: [Xen-devel] [PATCH] OvmfPkg: Add ACPI support for Virt Xen ARM

On 05/31/16 06:59, Shannon Zhao wrote: > From: Shannon Zhao > > Add ACPI support for Virt Xen ARM and it gets the ACPI tables through > Xen ARM multiboot protocol. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Shannon Zhao > --- > The corresponding Xen patches can

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

On 04/28/16 07:08, Ni, Ruiyu wrote: Do you know whether Xen passes the PCI device resource information to firmware? >> >> I don't think so, no. >> >> But, given that the previous PciHostBridgeDxe driver was working on Xen, >> can we perhaps emulate that behavior in >> "OvmfPkg/Library/P

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

On 04/27/16 11:50, Ni, Ruiyu wrote: > Copying Mike. > > Regards, > Ray > >> -Original Message- >> From: Ni, Ruiyu >> Sent: Wednesday, April 27, 2016 5:49 PM >> To: 'Gary Lin' >> Cc: edk2-de...@lists.01.org; Xen Devel ; Laszlo >

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

On 04/22/16 16:47, Anthony PERARD wrote: > Hi, > > Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root > bridge does not finish to initialize and breaks under Xen. (Adding Ray Ni) > There are several issue probably due to the use of > PcdPciDisableBusEnumeration=TRUE. >

Re: [Xen-devel] [Qemu-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

Including Igor & MST Thanks Laszlo On 02/02/16 17:31, Kevin O'Connor wrote: > On Tue, Feb 02, 2016 at 09:56:20AM +0100, Gerd Hoffmann wrote: >> Hi, >> I'd have qemu copy the data on 0xfc write then, so things continue to work without updating seabios. So, the firmware has to allocate

Re: [Xen-devel] [SeaBIOS] [SEABIOS] Plans for either 1.9.1 or 1.10.0?

On 01/14/16 17:36, Gerd Hoffmann wrote: > On Do, 2016-01-14 at 14:50 +, Ian Campbell wrote: >> Hello, >> >> The xen.git development branch currently points to SeaBIOS rel-1.9.0, but >> Roger has tripped over a build issue which is fixed by 3b8c5378dfe2 "build: >> fix typo in buildversion.py". >

Re: [Xen-devel] [edk2] [PATCH v2] OvmfPkg: XenPvBlkDxe: handle empty cdrom drives

FreePool (Params); > + DEBUG ((EFI_D_INFO, "%a: Empty cdrom\n", __FUNCTION__)); > + goto Error; > +} > +FreePool (Params); > + } > + > Status = XenBusReadUint64 (XenBusIo, "backend-id", FALSE, &Value); >if (St

Re: [Xen-devel] [PATCH] XenPvBlk: handle empty cdrom drives

(1) Please make the subject line say: OvmfPkg: XenPvBlkDxe: handle empty cdrom drives On 10/20/15 17:03, Stefano Stabellini wrote: > Empty cdroms are not going to connect, avoid waiting for the backend to > switch to state 4, which is never going to happen, and return > EFI_NO_MEDIA instead. (

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

On 10/20/15 13:59, Stefano Stabellini wrote: > On Mon, 19 Oct 2015, Laszlo Ersek wrote: >> On 10/16/15 21:09, Laszlo Ersek wrote: >>> On 10/16/15 13:34, Fabio Fantoni wrote: >>>> Il 16/10/2015 12:47, Stefano Stabellini ha scritto: >>>>> On Fri, 16 O

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

On 10/16/15 21:09, Laszlo Ersek wrote: > On 10/16/15 13:34, Fabio Fantoni wrote: >> Il 16/10/2015 12:47, Stefano Stabellini ha scritto: >>> On Fri, 16 Oct 2015, Fabio Fantoni wrote: >>>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: >>>>> On Fri, Oc

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

On 10/19/15 20:29, Fabio Fantoni wrote: > 2015-10-19 18:57 GMT+02:00 Stefano Stabellini > >: > > On Mon, 19 Oct 2015, John Snow wrote: > > On 10/19/2015 07:44 AM, Stefano Stabellini wrote: > > > On Mon, 19 Oct 2015, Gerd Hoffmann wrote: > >

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

On 10/16/15 13:34, Fabio Fantoni wrote: > Il 16/10/2015 12:47, Stefano Stabellini ha scritto: >> On Fri, 16 Oct 2015, Fabio Fantoni wrote: >>> Il 16/10/2015 12:13, Anthony PERARD ha scritto: On Fri, Oct 16, 2015 at 10:32:44AM +0200, Fabio Fantoni wrote: > Il 15/10/2015 20:02, Anthony PERAR

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

On 10/16/15 11:06, Stefano Stabellini wrote: > On Thu, 15 Oct 2015, Kevin O'Connor wrote: >> On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: >>> On 10/14/15 13:27, Ian Campbell wrote: >>>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

On 10/16/15 04:38, Kevin O'Connor wrote: > On Fri, Oct 16, 2015 at 01:10:54AM +0200, Laszlo Ersek wrote: >> On 10/14/15 13:27, Ian Campbell wrote: >>> On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: >>>>> Can't you just teach SeaBIOS how to

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

On 10/14/15 14:48, Paul Durrant wrote: >> -Original Message- >> From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz] >> Sent: 14 October 2015 12:12 >> To: Kevin Wolf; Stefano Stabellini >> Cc: John Snow; Anthony Perard; qemu-de...@nongnu.org; xen- >> de...@lists.xen.org; qemu-bl...@nongnu.org

Re: [Xen-devel] [Qemu-devel] Question about xen disk unplug support for ahci missed in qemu

CC'ing Kevin O'Connor On 10/14/15 13:27, Ian Campbell wrote: > On Wed, 2015-10-14 at 12:06 +0100, Stefano Stabellini wrote: >>> Can't you just teach SeaBIOS how to deal with your PV disks and then >>> only add that to your VM and forget about IDE/AHCI? I mean, that's how >>> it's done for virtio-b

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/14/15 11:22, Ian Campbell wrote: > On Fri, 2015-09-11 at 17:28 +0200, Laszlo Ersek wrote: >> > [...] >> For me that's not so clear-cut. OVMF is frequently used as a UEFI >> development environment (it's better to brick a virtual machine than >> your

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/12/15 01:06, Josh Triplett wrote: > On Fri, Sep 11, 2015 at 11:27:32PM +0200, Laszlo Ersek wrote: >> On 09/11/15 21:30, Josh Triplett wrote: >>> On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote: >>>> Breaking Debian Wheezy's and BITS&#x

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/11/15 21:30, Josh Triplett wrote: > On Fri, Sep 11, 2015 at 05:28:06PM +0200, Laszlo Ersek wrote: >> On 09/11/15 16:10, Josh Triplett wrote: >>> On Fri, Sep 11, 2015 at 01:43:53PM +0200, Laszlo Ersek wrote: >>>> On 09/09/15 12:48, Laszlo Ersek wrote: >>

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/11/15 16:10, Josh Triplett wrote: > On Fri, Sep 11, 2015 at 01:43:53PM +0200, Laszlo Ersek wrote: >> On 09/09/15 12:48, Laszlo Ersek wrote: >>> On 09/09/15 11:37, Ian Campbell wrote: >>>> On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote: >>>>&g

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 12:48, Laszlo Ersek wrote: > On 09/09/15 11:37, Ian Campbell wrote: >> On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote: >>>>>> On 09.09.15 at 00:23, wrote: >>>> On 09/08/15 19:26, Anthony PERARD wrote: >>>>>

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 09/10/15 08:19, Alexander Graf wrote: > > >> Am 10.09.2015 um 07:32 schrieb Jordan Justen : >> Laszlo's email raised the GPL question, but I was not sure what the >> EDK II community would accept with regards to GPL. Thus ... I asked. I >> guess I'm getting a better idea with regards to Apple

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/10/15 05:05, Zeng, Star wrote: > On 2015/9/9 18:48, Laszlo Ersek wrote: >> me neither :) >> >>> but if this (executable code on stack) is >>> happening in grub is there something which is explicitly forbidden to >>> UEFI >>> apps by the

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

On 09/09/15 18:34, Ian Campbell wrote: > On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary ta

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

On 09/09/15 18:34, Ian Campbell wrote: > On Wed, 2015-09-09 at 10:57 +0200, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary ta

Re: [Xen-devel] EDK II & GPL - Re: [edk2] OVMF BoF @ KVM Forum 2015

On 09/09/15 18:17, Jordan Justen wrote: > On 2015-09-09 01:57:51, Laszlo Ersek wrote: >> On 08/10/15 18:24, Laszlo Ersek wrote: >>> Hi. >>> >>> Let's do an OVMF BoF at this year's KVM Forum too. >> >> Here's a preliminary task

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 14:08, Jan Beulich wrote: On 09.09.15 at 12:48, wrote: >> Personally I think that this dynamic approach is overkill (mainly >> because I'm fine with being unable to install Debian Wheezy guests, both >> wearing and not wearing my red fedora; and because the properties table >> fea

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 13:30, Paolo Bonzini wrote: > > > On 09/09/2015 13:07, Ian Campbell wrote: >> I have a question: What attack vector is setting the stack as Nx in OVMF >> (or even UEFI generally) trying to protect against? Or is this being done >> for a reason other than security? >> >> I understand w

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 13:07, Ian Campbell wrote: > On Wed, 2015-09-09 at 12:48 +0200, Laszlo Ersek wrote: > > Thanks for all the info, I think I get it (although its not clear to me > whether how an app can claim to be UEFI 2.5 capable and what the transition > plan for legacy applications

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 11:37, Ian Campbell wrote: > On Wed, 2015-09-09 at 01:06 -0600, Jan Beulich wrote: > On 09.09.15 at 00:23, wrote: >>> On 09/08/15 19:26, Anthony PERARD wrote: And I get this on the console: Welcome to GRUB! X64 Exception Type - 0E(#PF - Page-Fault) CPU Api

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/09/15 09:06, Jan Beulich wrote: On 09.09.15 at 00:23, wrote: >> On 09/08/15 19:26, Anthony PERARD wrote: >>> And I get this on the console: >>> Welcome to GRUB! >>> >>> X64 Exception Type - 0E(#PF - Page-Fault) CPU Apic ID - >>> RIP - 0F5F8918, CS - 000

Re: [Xen-devel] OVMF BoF @ KVM Forum 2015

On 08/10/15 18:24, Laszlo Ersek wrote: > Hi. > > Let's do an OVMF BoF at this year's KVM Forum too. Here's a preliminary task list, after some off-list discussion (I tried to incorporate comments): - create GPL'd fork called "ovmf" for expediting

Re: [Xen-devel] OVMF/Xen, Debian wheezy can't boot with NX on stack (Was: Re: [edk2] [PATCH] OvmfPkg: prevent code execution from DXE stack)

On 09/08/15 19:26, Anthony PERARD wrote: > On Fri, Aug 28, 2015 at 10:17:28AM +0200, Laszlo Ersek wrote: >> On 08/08/15 02:02, Zeng, Star wrote: >>>> -Original Message- >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>>

[Xen-devel] OVMF BoF @ KVM Forum 2015

Hi. Let's do an OVMF BoF at this year's KVM Forum too. Paolo will present Securing secure boot: system management mode in KVM and Tiano Core on Thursday, August 20, in the 5:00pm - 5:30pm time slot. Right after that, the BoF section starts at 5:30pm: http://events.linuxfoundation.org/even

Re: [Xen-devel] [edk2] The size of memory is wrong inside of virtual machine(VM) when using OVMF

On 06/07/15 14:29, Wei Liu wrote: > On Mon, Jun 01, 2015 at 09:13:08AM +, Maoming wrote: >> Hi all: >>I encountered a troublesome problem about OVMF. >>I used OVMF.fd as a BIOS of virtual machine(VM). >> >>1、my environment: >>xen_version: 4.6-unstable

Re: [Xen-devel] [edk2] A problem about the memory size of virtual machine(VM) when using OVMF

I have the impression that this is HTML mail. Please don't post HTML mail; it falls apart when it is quoted. That said, On 06/04/15 16:07, Maoming wrote: > Hi all： > >I started a virtual machine(VM) (redhat6.3_64bit) using OVMF in XEN4.6. > > And the memory of the VM is 64G. > >But I o

Re: [Xen-devel] [edk2] Question about PEX boot on Xen with OVMF as bios

On 05/25/15 03:50, lidonglin wrote: > Hi all: > Recentlly, I want to use PXE boot on Xen with OVMF as bios. At > beginning, I just add rtl8139 as guest nic device, and I compile a > release ovmf. When I enter into uefi, I can't find network boot menu. > According to edk2/OvmfPkg/README file, I kno

Re: [Xen-devel] [edk2] 答复: Windows 2008 r2 smp guest booting hang with viridian=true on ovmf(xen latest version 4.5.1-rc1 + latest edk2)

On 05/20/15 09:24, Fanhenglong wrote: > Can anyone have idea about how to boot window 2008 r2 smp guest in ovmf > with viridian flag is true? I had to confirm first that "viridian" means "Hyper-V", : "Hyper-V, codenamed Viridian, ..." With that out of the

Re: [Xen-devel] [edk2] Windows 8 64bit Guest BSOD when using OVMF to boot and *install* from CDROM(when configured with more than 4G memory)

On 05/07/15 11:29, Ian Campbell wrote: > On Thu, 2015-05-07 at 09:02 +0200, Laszlo Ersek wrote: >> (Plus, you are cloning a git repo that may or may not be >> identical to the (semi-)official edk2 git repo.) > > FWIW git://xenbits.xen.org/ovmf.git is a direct desc

Re: [Xen-devel] [edk2] Windows 8 64bit Guest BSOD when using OVMF to boot and *install* from CDROM(when configured with more than 4G memory)

On 05/07/15 08:47, lidonglin wrote: > Dear all： > New issue： > Guest BSOD and restart when using OVMF to boot and install windows8 > 64bit OS(which owns more than 4G memmory)。 > My environment as below: > xen 4.5.0 > qemu 2.2.1 > ovmf git clone from git://xenbits.xen.org/ovmf.git (comm

Re: [Xen-devel] [PATCH v5 00/29] Xen/ARM guest support

On 02/24/15 20:01, Ard Biesheuvel wrote: > On 24 February 2015 at 18:41, Laszlo Ersek wrote: >> On 02/24/15 19:37, Ard Biesheuvel wrote: >>> On 24 February 2015 at 18:34, Laszlo Ersek wrote: >>>> On 02/24/15 19:02, Ard Biesheuvel wrote: >>>&

Re: [Xen-devel] [PATCH v5 00/29] Xen/ARM guest support

On 02/24/15 19:37, Ard Biesheuvel wrote: > On 24 February 2015 at 18:34, Laszlo Ersek wrote: >> On 02/24/15 19:02, Ard Biesheuvel wrote: >> >>> Changes since v4: >>> - rename InterlockedCompareExchange16 () patch as suggested by Jordan, and >>> adde

Re: [Xen-devel] [PATCH v5 00/29] Xen/ARM guest support

On 02/24/15 19:02, Ard Biesheuvel wrote: > Changes since v4: > - rename InterlockedCompareExchange16 () patch as suggested by Jordan, and > added > his ack > - fix a bug spotted by Anthony in the TestAndClearBit () implementation > - added more acks and R-b's - Are there any patches missing re

Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled

On 02/14/15 21:03, Jordan Justen wrote: > On 2015-02-14 08:38:37, Laszlo Ersek wrote: >> On 02/12/15 21:53, Jordan Justen wrote: >>> I think gEfiPciEnumerationCompleteProtocolGuid should be installed by >>> MdeModulePkg/Bus/Pci/PciBusDxe, even when PcdPciDisab

Re: [Xen-devel] [edk2] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled

steer clear of drivers that are central to edk2, like PciBusDxe. What do you guys think? Thanks! Laszlo > > -Jordan > > On 2015-02-12 04:16:07, Laszlo Ersek wrote: >> SVN r16411 delayed ACPI table installation until PCI enumeration was >> complete, because on QEMU the AC

Re: [Xen-devel] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled

On 02/12/15 13:29, Wei Liu wrote: > On Thu, Feb 12, 2015 at 01:16:07PM +0100, Laszlo Ersek wrote: >> SVN r16411 delayed ACPI table installation until PCI enumeration was >> complete, because on QEMU the ACPI-related fw_cfg files should only be >> downloaded after PCI enume

[Xen-devel] [PATCH] OvmfPkg: AcpiPlatformDxe: PCI enumeration may be disabled

case. When PCI enumeration is disabled (ie. when running on Xen), AcpiPlatformDxe doesn't wait for EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 4 +- OvmfPkg/AcpiP

Re: [Xen-devel] [PATCH] MdeModulePkg: mark completion of PCI enumeration in PciEnumeratorLight

is, in > combination with 66b280df2, makes AcpiPlatformDxe not able to be loaded, > resulting in guest crash. > > The fix is to install gEfiPciEnumerationCompleteProtocolGuid in > PciEnumeratorLight. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Wei Li

Re: [Xen-devel] [PATCH v3 25/27] ArmVirtualizationPkg: add XenIoMmioLib

ypo "if if" in this patch. In case you send a v4, please fix that. Reviewed-by: Laszlo Ersek I'm done with the v3 review; you addressed all my v2 comments. Thanks! Laszlo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 23/27] Ovmf/Xen: implement dummy RealTimeClockLib for Xen

lizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c > create mode 100644 > ArmPlatformPkg/ArmVirtualizationPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf Moved to ArmPlatformPkg/ArmVirtualizationPkg/Library/, hence Acked-by: Laszlo Ersek ___ X

Re: [Xen-devel] [PATCH v3 22/27] Ovmf/Xen: add Xen PV console SerialPortLib driver

lPortLib.inf You added the comment I asked for, hence Acked-by: Laszlo Ersek ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 18/27] Ovmf/Xen: add separate driver for Xen PCI device

ed, 412 insertions(+) > create mode 100644 OvmfPkg/XenIoPciDxe/XenIoPciDxe.c > create mode 100644 OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf Reviewed-by: Laszlo Ersek ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 29/29] ArmVirtualizationPkg: add platform description for Xen guests

ted as well. I won't check the rest of the patch now; you got several notes from Julien. Please eyeball this patch for any leftovers from the QEMU files. You can add my Acked-by: Laszlo Ersek then. Also, I think I finished reviewing the series. (Some patches I didn't

Re: [Xen-devel] [PATCH v2 28/29] ArmVirtualizationPkg/VirtFdtDxe: wire up XenBusDxe to "xen, xen" DT node

ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf > b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf > index 1392c7c3fa45..f8a58238c37b 100644 > --- a/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf > +++ b/ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf > @@ -41,6 +41,7 @@ >FdtLib >VirtioMmioDeviceLib >HobLib > + XenIoMmioLib > > [Guids] >gFdtTableGuid > With those changes: Reviewed-by: Laszlo Ersek Thanks Laszlo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 27/29] ArmVirtualizationPkg: add XenIoMmioLib

On 02/03/15 12:45, Laszlo Ersek wrote: > comments below > > On 01/26/15 20:03, Ard Biesheuvel wrote: >> +EFI_STATUS >> +XenIoMmioInstall ( >> + IN EFI_HANDLE *Handle, >> + IN UINT64 GrantTableAddress >> + ) >> +{ >> + EFI_STAT

Re: [Xen-devel] [PATCH v2 27/29] ArmVirtualizationPkg: add XenIoMmioLib

On 01/26/15 20:03, Ard Biesheuvel wrote: > +EFI_STATUS > +XenIoMmioInstall ( > + IN EFI_HANDLE *Handle, > + IN UINT64 GrantTableAddress > + ); Sorry I had another (pedantic) remark here -- consider EFI_PHYSICAL_ADDRESS instead of UINT64. (It looks better and that's what's in your proto

Re: [Xen-devel] [PATCH v2 27/29] ArmVirtualizationPkg: add XenIoMmioLib

comments below On 01/26/15 20:03, Ard Biesheuvel wrote: > This adds a XenIoMmioLib declaration and implementation that can > be invoked to install the XENIO_PROTOCOL and a corresponding > grant table address on a EFI handle. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off

Re: [Xen-devel] [PATCH v2 25/29] Ovmf/Xen: implement dummy RealTimeClockLib for Xen

On 01/26/15 20:03, Ard Biesheuvel wrote: > This implements a dummy RealTimeClockLib for Xen, as there is no > guest interface to access the time kept by Xen that can be shared > between UEFI and the OS. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel >

Re: [Xen-devel] [PATCH v2 26/29] Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus root

x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}} > > [Protocols] >gVirtioDeviceProtocolGuid = {0xfa920010, 0x6785, 0x4941, {0xb6, > 0xec, 0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}} > Reviewed-by: Laszlo Ersek ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 24/29] Ovmf/Xen: add Xen PV console SerialPortLib driver

Unless I'm wrong, please: On 01/26/15 20:03, Ard Biesheuvel wrote: > This implements a SerialPortLib instance that wires up to the > PV console ring used by domU guests. Also imports the required > upstream Xen io/console.h header. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Sig

Re: [Xen-devel] [PATCH v2 21/29] Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOL

t; // > -#include > +#include > > > // > @@ -73,10 +73,6 @@ extern EFI_COMPONENT_NAME_PROTOCOL > gXenBusDxeComponentName; > // > #include > > -#define PCI_VENDOR_ID_XEN0x5853 > -#define PCI_DEVICE_ID_XEN_PLATFORM 0x0001 &g

Re: [Xen-devel] [PATCH v2 20/29] Ovmf/Xen: add separate driver for Xen PCI device

This code brings back memories :) It even has my earliest edk2 comments whose vocabulary (in retrospect) is not entirely correct. :) But, they're not the reason I'll ask for a respin here: On 01/26/15 20:03, Ard Biesheuvel wrote: > Prepare for making XenBusDxe suitable for use with non-PCI devices

Re: [Xen-devel] [PATCH v2 19/29] Ovmf/Xen: introduce XENIO_PROTOCOL

{0xa6, > 0x34, 0xf7, 0xfe, 0x72, 0xad, 0xbe, 0x84}} >gXenBusProtocolGuid = {0x3d3ca290, 0xb9a5, 0x11e3, {0xb7, > 0x5d, 0xb8, 0xac, 0x6f, 0x7d, 0x65, 0xe6}} > + gXenIoProtocolGuid = {0x6efac84f, 0x0ab0, 0x4747, {0x81, > 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}} > > [PcdsFixedAtBuild] >gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0 > Reviewed-by: Laszlo Ersek ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 18/29] Ovmf/Xen: move XenBusDxe hypercall code to separate library

enHypercall.h > +++ b/OvmfPkg/Include/Library/XenHypercallLib.h > @@ -13,8 +13,8 @@ > > **/ > > -#ifndef __XENBUS_DXE_HYPERCALL_H__ > -#define __XENBUS_DXE_HYPERCALL_H__ > +#ifndef __XEN_HYPERCALL_LIB_H_ > +#define __XEN_HYPERCALL_LIB_H_ I guess if you lead it with &

Re: [Xen-devel] [PATCH v2 17/29] Ovmf/Xen: refactor XenBusDxe hypercall implementation

>>>> - ASSERT (Dev->Hyperpage != NULL); >>>> - >>>>Parameter.domid = DOMID_SELF; >>>>Parameter.index = Index; >>>> - Error = XenHypercall2 ((UINT8*)Dev->Hyperpage + __HYPERVISOR_hvm_op * >>>> 32, >>>> + Error = XenHypercall2 (__HYPERVISOR_hvm_op, >>>> HVMOP_get_param, (INTN) &Parameter); >>>>if (Error != 0) { >>>> DEBUG ((EFI_D_ERROR, >>>> @@ -66,53 +64,33 @@ XenHypercallHvmGetParam ( >>>> >>>> INTN >>>> XenHypercallMemoryOp ( >>>> - IN XENBUS_DEVICE *Dev, >>>>IN UINTN Operation, >>>>IN OUT VOID *Arguments >>>>) >>>> { >>>> - ASSERT (Dev->Hyperpage != NULL); >>>> - return XenHypercall2 ((UINT8*)Dev->Hyperpage + __HYPERVISOR_memory_op * >>>> 32, >>>> + return XenHypercall2 (__HYPERVISOR_memory_op, >>>> Operation, (INTN) Arguments); >>>> } >>>> >>>> INTN >>>> XenHypercallEventChannelOp ( >>>> - IN XENBUS_DEVICE *Dev, >>>>IN INTN Operation, >>>>IN OUT VOID *Arguments >>>>) >>>> { >>>> - ASSERT (Dev->Hyperpage != NULL); >>>> - return XenHypercall2 ((UINT8*)Dev->Hyperpage + >>>> __HYPERVISOR_event_channel_op * 32, >>>> + return XenHypercall2 (__HYPERVISOR_event_channel_op, >>>> Operation, (INTN) Arguments); >>>> } >>>> >>>> -EFI_STATUS >>>> -XenGetSharedInfoPage ( >>>> - IN OUT XENBUS_DEVICE *Dev >>>> +INTN >>>> +EFIAPI >>>> +XenHypercall2 ( >>>> + IN INTN HypercallID, >>>> + IN OUT INTN Arg1, >>>> + IN OUT INTN Arg2 >>>>) >>>> { >>>> - xen_add_to_physmap_t Parameter; >>>> - >>>> - ASSERT (Dev->SharedInfo == NULL); >>>> + ASSERT (HyperPage != NULL); >>>> >>>> - Parameter.domid = DOMID_SELF; >>>> - Parameter.space = XENMAPSPACE_shared_info; >>>> - Parameter.idx = 0; >>>> - >>>> - // >>>> - // using reserved page because the page is not released when Linux is >>>> - // starting because of the add_to_physmap. QEMU might try to access the >>>> - // page, and fail because it have no right to do so (segv). >>>> - // >>>> - Dev->SharedInfo = AllocateReservedPages (1); >>>> - Parameter.gpfn = (UINTN) Dev->SharedInfo >> EFI_PAGE_SHIFT; >>>> - if (XenHypercallMemoryOp (Dev, XENMEM_add_to_physmap, &Parameter) != 0) >>>> { >>>> -FreePages (Dev->SharedInfo, 1); >>>> -Dev->SharedInfo = NULL; >>>> -return EFI_LOAD_ERROR; >>>> - } >>>> - >>>> - return EFI_SUCCESS; >>>> + return __XenHypercall2 ((UINT8*)HyperPage + HypercallID * 32, Arg1, >>>> Arg2); >>> ^ shouldn't it be Hyperpage? >>> >> >> Yes, you are quite right. My build test on x86 should have spotted >> this, so apparently I screwed that up in some way as well. >> > > Turns out this was a refactoring error that got cleaned up by the next > patch, and I did not perform the x86 build test on each patch in > isolation. > Will be fixed in v3 > I skimmed this patch. It makes sense to me as preparation for librarizing the hypercall machinery (as you say in the commit message), if the Xen guys don't have any objections. I peeked forward at patch 18. The librarization is certainly possible given that the origin of your info is the GUID HOB with gEfiXenInfoGuid. So, I got curious about the data pointed-to by the gEfiXenInfoGuid HOB... It's set up in OvmfPkg/PlatformPei/Xen.c. I froze for a second, but then I noticed it uses BuildGuidDataHob(), *not* BuildGuidHob(); ie. it *copies* mXenInfo into the HOB. Good. I think this patch (and the next one) improve OVMF/Xen even in isolation (== without thinking of ARM at all). For v3: Acked-by: Laszlo Ersek Thanks Laszlo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 16/29] Ovmf/Xen: fix pointer to int cast in XenBusDxe

bindings. Most of the time, the above means ((type)expr1) expr2 and not (type)(expr1 expr2) as the space would incorrectly suggest. Your patch is fine, but I had to think thrice. :) Reviewed-by: Laszlo Ersek ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 14/29] ArmVirtualizationPkg: Xen/PV relocatable platformlib instance

Lib/XenVirtMem.c > | 83 + > 5 files changed, 606 insertions(+) Five new files; it appears impossible that this patch regress QEMU VMs. Hence Acked-by: Laszlo Ersek ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 13/29] ArmVirtualizationPkg: allow patchable PCD for FV base address

dress > > [Guids] >gEarlyPL011BaseAddressGuid > It also seems to change the PCD type of PcdDeviceTreeInitialBaseAddress. Care to mention that too in the commit message, just for completeness? Reviewed-by: Laszlo Ersek Thanks Laszlo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 12/29] ArmVirtualizationPkg: implement custom MemoryInitPeiLib

uid.PcdMemoryTypeEfiReservedMemoryType > + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData > + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode > + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode > + gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesD

Re: [Xen-devel] [PATCH v2 08/29] ArmVirtualizationPkg: add padding to FDT allocation

> Some platforms might want to have a larger FDT padding. >> > > Agreed. Will add it to v3 I think using a FixedPcd will be okay. With that change, you can add Reviewed-by: Laszlo Ersek Thanks Laszlo > > >> >>> -Original Message- >>> From

Re: [Xen-devel] [PATCH v2 07/29] ArmVirtualizationPkg: use a HOB to store device tree blob

>> armlink : error L6218: Undefined symbol AllocatePages (referred from >> ArmVirtualizationPlatformLib.lib). >> armlink : Not enough information to list image symbols. >> armlink : Finished: 1 information, 0 warning and 1 error messages. >> > > Probably just

Re: [Xen-devel] [PATCH v2 05/29] ArmVirtualizationPkg: allow patchable PCD for device tree base address

ArmVirtualizationPkg/Library/ArmVirtualizationPlatformLib/Virt.c > @@ -96,7 +96,7 @@ ArmPlatformInitializeSystemMemory ( >ASSERT (HobData != NULL); >*HobData = 0; > > - DeviceTreeBase = (VOID *)(UINTN)FixedPcdGet64 > (PcdDeviceTreeInitialBaseAddress); > + De

Re: [Xen-devel] [PATCH v2 02/29] ArmPkg: allow patchable PCDs for memory, FD and FV addresses

l be > declared ># to UEFI by ArmPlatformLib >gArmTokenSpaceGuid.PcdSystemMemoryBase|0|UINT64|0x0029 >gArmTokenSpaceGuid.PcdSystemMemorySize|0|UINT64|0x002A > > +[PcdsFixedAtBuild.common, PcdsDynamic.common] ># ># ARM Architectural Timer ># > Acked-by: Laszlo Ersek ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 01/29] ArmPkg: allow HYP timer interrupt to be omitted

pe ? 16 : 0); >VirtIntrNum = fdt32_to_cpu (InterruptProp[2].Number) > + (InterruptProp[2].Type ? 16 : 0); > - HypIntrNum = fdt32_to_cpu (InterruptProp[3].Number) > - + (InterruptProp[3].Type ? 16 : 0); > + HypIntrNum = Len < 48 ? 0 : f

  1   2   >