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

On 10/21/15 17:11, Paolo Bonzini wrote: > > > On 21/10/2015 17:04, Laszlo Ersek wrote: >> Now, on TCG, reading the APIC ID register (for device "apic") happens in: >> >> apic_mem_readl() [hw/intc/apic.c] >> val = s->id << 24 >> >> Whereas on KVM, the same occurs in: >> >> kvm_apic_mem_read()

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

On 10/21/15 14:10, 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] [PATCH v3 00/52] OvmfPkg: support SMM for better security (steps towards MP and X64)

On 10/21/15 12:27, Paolo Bonzini wrote: > > > On 21/10/2015 12:22, Laszlo Ersek wrote: >> On 10/21/15 11:51, Paolo Bonzini wrote: >>> >>> >>> On 20/10/2015 12:08, Laszlo Ersek wrote: >> >> 64 KVM>=1"KVM: entry failed, hardware error 0x8021" >>

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

On 10/21/15 17:04, Laszlo Ersek wrote: > On 10/21/15 14:10, 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

Re: [edk2] style question/Omap3530Gpio

> On Oct 21, 2015, at 8:31 AM, Laszlo Ersek wrote: > > On 10/21/15 17:13, Leif Lindholm wrote: >> Hi Andrew, (list on cc) >> >> Having a look at rewriting the ARM PL061Gpio driver since I find the >> current version too complicated to review Haojian's patches against. >>

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

Laszlo, We have the PCD that specifies the max CPUs. ## Specifies max supported number of Logical Processors. # @Prompt Configure max supported number of Logical Processors gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64|UINT32|0x0002 We could exit the wait loop as soon

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

On 2015-10-21 14:19:40, Kinney, Michael D wrote: > Laszlo, > > We have the PCD that specifies the max CPUs. > > ## Specifies max supported number of Logical Processors. > # @Prompt Configure max supported number of Logical Processors > >

[edk2] [MdeModulePkg] MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf will not compile with Xcode 6.3.2

"/usr/bin/clang" -target x86_64-pc-win32-macho -c -g -Os -Wall -Werror -Wextra -include AutoGen.h -funsigned-char -fno-ms-extensions -fno-stack-protector -fno-builtin -fshort-wchar -mno-implicit-float -mms-bitfields -Wno-unused-parameter -Wno-missing-braces -Wno-missing-field-initializers

Re: [edk2] [PATCH] UefiCpuPkg: PiSmmCpuDxeSmm: Remove unused references to SmmLib

Looks good. Reviewed by jiewen@inter.com -Original Message- From: Kinney, Michael D Sent: Thursday, October 22, 2015 7:26 AM To: edk2-devel@lists.01.org Cc: Yao, Jiewen; Fan, Jeff Subject: [PATCH] UefiCpuPkg: PiSmmCpuDxeSmm: Remove unused references to SmmLib The PiSmmCpuDxeSmm

[edk2] [PATCH] UefiCpuPkg: PiSmmCpuDxeSmm: Remove unused references to SmmLib

The PiSmmCpuDxeSmm module does not use any services from the SmmLib. This change removes the SmmLib from PiSmmCpuDxeSmm module and also removes the lib mapping in the UefiCpuPkg DSC file because no other modules in the UefiCpuPkg use the SmmLib. Contributed-under: TianoCore Contribution Agreement

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

Jordan, CPU ID only could get the max logical processor number supported in current socket. It cannot handle multi-sockets case. Yes. We could promote PcdCpuMaxLogicalProcessorNumber to dynamic type. But we need find one reliable way like you said to set it before CPU MP PEI not only CPU MP

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

Adding Jordan. On 10/21/15 03:14, Kinney, Michael D wrote: > 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?

[edk2] [PATCH] MdeModulePkg Variable: Enhance variable performance by reading from existed memory cache.

Current variable driver already have memory cache to improve performance. Change the code which read from physical MMIO address to read from memory cache. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Derek Lin ---

Re: [edk2] Porting UEFI to a ARM platform

I can confirm that the tutorial on the tianocore wiki works just fine because I've just finished a port using that(it's a ARM-2ndstage platform though). On Wed, Oct 21, 2015 at 9:43 AM, Laszlo Ersek wrote: > On 10/21/15 04:44, Yehuda Yitschak wrote: > > Hello everyone > > > >

Re: [edk2] Porting UEFI to a ARM platform

Hi Yehuda, On Wed, Oct 21, 2015 at 02:44:19AM +, Yehuda Yitschak wrote: > 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

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

On 21/10/2015 12:22, Laszlo Ersek wrote: > On 10/21/15 11:51, Paolo Bonzini wrote: >> >> >> On 20/10/2015 12:08, Laszlo Ersek wrote: > > 64 KVM>=1"KVM: entry failed, hardware error 0x8021" > while guest in SMBASE relocation >>> Tracing KVM

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

On 10/21/15 13:39, 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 > error instead from XenPvBlockFrontInitialization(). Detect an > empty cdrom by looking at the "params" node on

[edk2] [PATCH v2] OvmfPkg: XenPvBlkDxe: 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 error instead from XenPvBlockFrontInitialization(). Detect an empty cdrom by looking at the "params" node on xenstore, which is set to "" or "aio:" for empty drives

Re: [edk2] [Patch] MdeModulePkg SetupBrowserDxe: Save global variable values before nest function called.

Reviewed-by: Liming Gao -Original Message- From: Dong, Eric Sent: Friday, October 16, 2015 9:34 AM To: edk2-devel@lists.01.org Cc: Gao, Liming; Bi, Dandan Subject: [Patch] MdeModulePkg SetupBrowserDxe: Save global variable values before nest function called. The

Re: [edk2] Porting UEFI to a ARM platform

On 10/21/15 04:44, Yehuda Yitschak wrote: > 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

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

CC'ing Eduardo On 10/20/15 23:39, Jordan Justen wrote: > On 2015-10-20 12:27:42, Laszlo Ersek wrote: >> 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

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

On 10/20/15 22:09, Janusz wrote: > W dniu 20.10.2015 o 21:27, Laszlo Ersek pisze: >> 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 >>