Re: [edk2] [PATCH v3 00/52] OvmfPkg: support SMM for better security (steps towards MP and X64)

On 10/15/15 00:25, Laszlo Ersek wrote: > Test environment and results: > > Host kernel: > - latest RHEL-7 development kernel (3.10.0-323.el7), with Paolo's > following patches backported by yours truly: > - KVM: x86: clean up kvm_arch_vcpu_runnable > - KVM: x86: fix SMI to halted VCPU > >

Re: [edk2] [PATCH v3 00/52] OvmfPkg: support SMM for better security (steps towards MP and X64)

On 10/15/15 00:25, Laszlo Ersek wrote: > Test environment and results: > > Host kernel: > - latest RHEL-7 development kernel (3.10.0-323.el7), with Paolo's > following patches backported by yours truly: > - KVM: x86: clean up kvm_arch_vcpu_runnable > - KVM: x86: fix SMI to halted VCPU > >

Re: [edk2] [PATCH v2] MdeModulePkg: Make the BmFindLoadOption function public

Reviewed-by: Ruiyu Ni -Original Message- From: Wang, Sunny (HPS SW) [mailto:sunnyw...@hpe.com] Sent: Monday, October 19, 2015 3:46 PM To: edk2-devel@lists.01.org; Ni, Ruiyu Cc: El-Haj-Mahmoud, Samer ; Wang, Sunny

Re: [edk2] [PATCH v3 00/52] OvmfPkg: support SMM for better security (steps towards MP and X64)

On 10/20/15 10:52, Laszlo Ersek wrote: > On 10/15/15 00:25, Laszlo Ersek wrote: > >> Test environment and results: >> >> Host kernel: >> - latest RHEL-7 development kernel (3.10.0-323.el7), with Paolo's >> following patches backported by yours truly: >> - KVM: x86: clean up

Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

Hi, On 10/20/15 19:27, Janusz wrote: > W dniu 15.10.2015 o 20:46, Laszlo Ersek pisze: >> On 10/15/15 18:53, Kinney, Michael D wrote: >>> Laszlo, >>> >>> There is already a PCD for this timeout that is used by CpuMpPei. >>> >>> gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds >>>

Re: [edk2] [PATCH v3 00/52] OvmfPkg: support SMM for better security (steps towards MP and X64)

On 10/20/15 18:27, Laszlo Ersek wrote: > On 10/20/15 18:24, Laszlo Ersek wrote: >> On 10/20/15 16:37, Laszlo Ersek wrote: >> >>> The variable access fails *iff* the access is made by a VCPU that is >>> *not* VCPU#0. >>> >>> I added a bunch of debug messages to the following functions: >>> >>> -

Re: [edk2] KVM: MTRR: fix memory type handling if MTRR is completely disabled

W dniu 15.10.2015 o 20:46, Laszlo Ersek pisze: > On 10/15/15 18:53, Kinney, Michael D wrote: >> Laszlo, >> >> There is already a PCD for this timeout that is used by CpuMpPei. >> >> gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds >> >> I noticed that CpuDxe is using a hard coded

Re: [edk2] [PATCH v4 00/19] UefiCpuPkg: Add CPU SMM and SecCore

On 10/19/15 09:44, Michael Kinney wrote: > Laszlo, > > I have addressed the MP race conditions and have timeouts > configurable using a PCD in the CpuDxe module in this revised patch > series. I picked up the patch from your series to sync MTRRs. I > have also removed trailing spaces from all

[edk2] [PATCH] OvmfPkg: increase MP services startup timeout

Due to Linux kernel commit b18d5431acc7 ("KVM: x86: fix CR0.CD virtualization"), vCPUs need more time to start up, because: - KVM now zaps all the mappings for the guest memory in EPT or shadow page table, hence more VM exits are required to rebuild the mappings for all memory accesses. - If

Re: [edk2] [PATCH v3 00/52] OvmfPkg: support SMM for better security (steps towards MP and X64)

On 10/20/15 16:37, Laszlo Ersek wrote: > The variable access fails *iff* the access is made by a VCPU that is > *not* VCPU#0. > > I added a bunch of debug messages to the following functions: > > - InitCommunicateBuffer(), SendCommunicateBuffer() >

Re: [edk2] [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: [edk2] [PATCH v3 00/52] OvmfPkg: support SMM for better security (steps towards MP and X64)

On 10/20/15 18:24, Laszlo Ersek wrote: > On 10/20/15 16:37, Laszlo Ersek wrote: > >> The variable access fails *iff* the access is made by a VCPU that is >> *not* VCPU#0. >> >> I added a bunch of debug messages to the following functions: >> >> - InitCommunicateBuffer(), SendCommunicateBuffer()

[edk2] Is the edk2 FV INF format documented?

Is the FV inf format documented? It looks like we have crisp specifications for the other files (module inf, dsc, dec, fdf, etc) but I didn't see anything about the FV .INF files. I realize the intent may be that this is a private definition between build.py and GenFv but we have some

Re: [edk2] Is the edk2 FV INF format documented?

> On Oct 20, 2015, at 1:48 PM, Cohen, Eugene wrote: > > Is the FV inf format documented? It looks like we have crisp specifications > for the other files (module inf, dsc, dec, fdf, etc) but I didn't see > anything about the FV .INF files. > I think they are just generate

[edk2] [PATCH] XenPvBlk: handle empty cdrom drives

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. Detect an empty cdrom by looking at the "params" node on xenstore, which is set to "" or "aio:" for empty drives by libxl.

Re: [edk2] [PATCH v3 01/52] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU detected

On 10/14/15 4:25 PM, Laszlo Ersek wrote: From: Michael Kinney When only 1 CPU is detected and the max CPUs is greater than 1, an ASSERT() is generated because the pages associated with the AP stack have already been freed. Only do this FreePages() call if there is

Re: [edk2] [PATCH v3 01/52] UefiCpuPkg: CpuDxe: Fix ASSERT() when only 1 CPU detected

Bruce, No. Different ASSERT(). That looks like a new bug, and it is in the new code I added to force BSP to wait for all APs to enter sleeping state before StartupAllAPs() is called. How did you reproduce this? Thanks, Mike >-Original Message- >From: edk2-devel

[edk2] Porting UEFI to a ARM platform

Hello everyone i started reading and experimenting with UEFI a month ago and i'm now considering to start porting it to one of Marvell's Aarch64 SOCs as a first stage i only want to get a basic shell running and start adding drivers with time. i'm wondering if there is any documentation or