Re: [edk2] qemu + osx + smp vs. dee9376ffc6e5522bb5e50512b521952a5421fa5

On 2014-11-13 23:18:43, Fan, Jeff wrote: > Yes. > > Placing APs in one hlt-loop is better in one ExitBootServices > callback function registered by CpuDxe driver. > > In long mode, page table still be required to run hlt-loop > instruction. To avoid page table (in Boot Service Data range also) >

Re: [edk2] SecurityPkg: TPM2_SetPrimaryPolicy command

Hi Stefan I think it might OK to add commands to Tpm2CommandLib, as long as there is valid usage. Would you please help to describe more on a whole picture on below 2 cases? E.g. Why and how TPM firmware upgrade use this command in BIOS? Why and how OEM delegate TPM_RH_PLATFORM role, and for whic

Re: [edk2] qemu + osx + smp vs. dee9376ffc6e5522bb5e50512b521952a5421fa5

Yes. Placing APs in one hlt-loop is better in one ExitBootServices callback function registered by CpuDxe driver. In long mode, page table still be required to run hlt-loop instruction. To avoid page table (in Boot Service Data range also) crashed, we could place APs hlt in protected mode. J

Re: [edk2] qemu + osx + smp vs. dee9376ffc6e5522bb5e50512b521952a5421fa5

On 2014-11-13 22:10:42, Fan, Jeff wrote: > Gabriel, > > After APs initialized, APs will run one loop in > ProcessorToIdleState() to check the if BSP assigned task to them. > > After ExitBootService() invoked, the boot services data will not be > safe and the AP running code maybe corrupted. > >

Re: [edk2] qemu + osx + smp vs. dee9376ffc6e5522bb5e50512b521952a5421fa5

Gabriel, After APs initialized, APs will run one loop in ProcessorToIdleState() to check the if BSP assigned task to them. After ExitBootService() invoked, the boot services data will not be safe and the AP running code maybe corrupted. Could you check if ExitBootService() is invoked or not w

[edk2] qemu + osx + smp vs. dee9376ffc6e5522bb5e50512b521952a5421fa5

Jordan, Commit dee9376ffc6e5522bb5e50512b521952a5421fa5 appears to break osx smp mode (single-cpu on Mavericks seems to still work fine). Fedora 20 and 21 live still work fine in either single- or multi-cpu configurations. I realize this must be an annoying bug report, since starting a qemu osx

Re: [edk2] [PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type

Jordan Justen [mailto:jordan.l.jus...@intel.com] wrote: ]On 2014-11-13 12:12:54, Gabriel L. Somlo wrote: ]> New in v.6: ]> ]> - ASSERT(FALSE) in default branch of HostBridgeDevID switch followed ]> by return statement to suppress unused variable gcc warnings ]> (Jordan, thanks for being

[edk2] [PATCH v7] OvmfPkg: PlatformBdsLib: Dynamic PCI Interrupt Line register setup

Remove hard-coded list of PCI devices for which the Interrupt Line register is initialized. Instead, provide a "visitor" function to initialize the register only for present and applicable PCI devices. At this time, we match the behavior of SeaBIOS (file src/fw/pciinit.c, functions *_pci_slot_get_

Re: [edk2] [PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type

On Thu, Nov 13, 2014 at 04:50:05PM -0800, Jordan Justen wrote: > On 2014-11-13 12:12:54, Gabriel L. Somlo wrote: > > New in v.6: > > > > - ASSERT(FALSE) in default branch of HostBridgeDevID switch followed > > by return statement to suppress unused variable gcc warnings > > (Jordan, than

Re: [edk2] [RFC PATCH V7 00/27] Introduce Mp Service protocol to UefiCpuPkg

On Thu, 2014-11-13 at 10:42 -0800, Jordan Justen wrote: > On 2014-11-06 17:23:01, Fan, Jeff wrote: > > Chen, > > > > Thanks your contribution. I will check-in your patch if there is no > > further comments from other guys. > > > > Reviewed-by: Jeff Fan > > Chen, > > I committed your series (r

Re: [edk2] [PATCH v2 0/7] CryptoPkg and OvmfPkg build fixes for gcc and VS2010

> Qin Long, can you please look at the CryptoPkg patches? They are > simple, and it's not possible to build OVMF with Secure Boot support without > them. Reviewed-by: Qin Long Laszlo, thanks for catching this build issue. Best Regards & Thanks, LONG, Qin -Original Message- From: J

Re: [edk2] [PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type

On 2014-11-13 12:12:54, Gabriel L. Somlo wrote: > New in v.6: > > - ASSERT(FALSE) in default branch of HostBridgeDevID switch followed > by return statement to suppress unused variable gcc warnings > (Jordan, thanks for being OK with that, I really believe if we ever > do end up wit

Re: [edk2] [PATCH] MdeModulePkg: update poor wording in MdeModulePkg UNI file

Reviewed-by: Erik Bjorge From: Carsey, Jaben Sent: Thursday, November 13, 2014 12:41 PM To: Bjorge, Erik C; Gao, Liming Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben Subject: [PATCH] MdeModulePkg: update poor wording in MdeModulePkg UNI file Erik and Liming, Can you check this? The follo

[edk2] [PATCH v6 7/9] OvmfPkg: AcpiTimerLib: Switch additional stages to PCD-based Dxe instance

Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against a valid, non-asserting version of PcdLib, then switch them over to using the "Dxe" instance of AcpiTimerLib (instead of the "Base" version). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo

[edk2] [PATCH v6 3/9] OvmfPkg: Add PCD for Host Bridge dev. ID (PcdOvmfHostBridgePciDevId)

Set from PEI, this PCD allows subsequent stages (specifically DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform type (e.g. PIIX4 or Q35/MCH) without the need to further query the Host Bridge for its Device ID. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by:

[edk2] [PATCH v6 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may utilize global variables, use the "Base" AcpiTimerLib instance (instead of BaseRom) to take advantage of the improved efficiency of storing the timer register IO address in a global variable. This leaves only SEC using the BaseRomAcpi

[edk2] [PATCH v6 1/9] OvmfPkg: Factor out platform detection (q35 vs. piix4)

Introduce macros to detect the underlying platform and access its ACPI power management registers, based on querying the host bridge device ID. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo Reviewed-by: Paolo Bonzini Reviewed-by: Jordan Justen Reviewed-by:

[edk2] [PATCH v6 8/9] OvmfPkg: PlatformBdsLib: Platform dependent PCI/IRQ initialization

Merge PciInitialization() and AcpiInitialization() into a single function, PciAcpiInitialization(), and use a PCD set during PEI to detect the underlying platform type (PIIX4 or Q35/MCH) and therefore the addresses of the registers to be initialized. Add LNK[A-H] routing target initialization for

[edk2] [PATCH v6 5/9] OvmfPkg: AcpiTimerLib: Split into multiple phase-specific instances

Remove local power management register access macros in favor of factored-out ones in OvmfPkg/Include/OvmfPlatforms.h Next, AcpiTimerLib is split out into three instances, for use during various stages: - BaseRom: used during SEC, PEI_CORE, and PEIM; - Dxe: used during DXE_DRIVER and DXE_

[edk2] [PATCH v6 4/9] OvmfPkg: CsmSupportLib: Set/use platform specific legacy interrupt device

Use a PCD set from PEI to determine the legacy interrupt device number appropriate for the underlying platform type during protocol initialization. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo Reviewed-by: Paolo Bonzini Reviewed-by: Jordan Justen Reviewed

[edk2] [PATCH v6 2/9] OvmfPkg: PlatformPei: Platform specific ACPI power management setup

Set up ACPI power management using registers determined based on the underlying (PIIX4 or Q35/MCH) platform type. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo Reviewed-by: Paolo Bonzini Reviewed-by: Jordan Justen Reviewed-by: Gerd Hoffmann Reviewed-by: L

[edk2] [PATCH v6 0/9] OVMF: Add support for Qemu Q35 machine type

New in v.6: - ASSERT(FALSE) in default branch of HostBridgeDevID switch followed by return statement to suppress unused variable gcc warnings (Jordan, thanks for being OK with that, I really believe if we ever do end up with a dev ID other than PIIX4 or Q35 we do want to be mad

[edk2] [PATCH v6 9/9] OvmfPkg: PlatformBdsLib: Dynamic PCI Interrupt Line register setup

Remove hard-coded list of PCI devices for which the Interrupt Line register is initialized. Instead, provide a "visitor" function to initialize the register only for present and applicable PCI devices. At this time, we match the behavior of SeaBIOS (file src/fw/pciinit.c, functions *_pci_slot_get_

Re: [edk2] [PATCH v5 2/9] OvmfPkg: PlatformPei: Platform specific ACPI power management setup

Sent from my iPhone > On Nov 13, 2014, at 11:14 AM, Jordan Justen wrote: > >> On 2014-11-13 09:46:29, Laszlo Ersek wrote: >>> On 11/13/14 18:40, Gabriel Somlo wrote: On Thu, 13 Nov 2014 09:27:09 -0600, Scott Duplichan wrote: Gabriel Somlo [mailto:gso...@gmail.com] wrote: ]On Sun

Re: [edk2] [PATCH v5 2/9] OvmfPkg: PlatformPei: Platform specific ACPI power management setup

On 2014-11-13 09:46:29, Laszlo Ersek wrote: > On 11/13/14 18:40, Gabriel Somlo wrote: > > On Thu, 13 Nov 2014 09:27:09 -0600, Scott Duplichan wrote: > >> Gabriel Somlo [mailto:gso...@gmail.com] wrote: > >> ]On Sun, Nov 09, 2014 at 05:00:38PM -0800, Jordan Justen wrote: > >> ]> On 2014-11-08 14:01:5

Re: [edk2] [PATCH v2 0/7] CryptoPkg and OvmfPkg build fixes for gcc and VS2010

On 2014-11-13 08:56:40, Laszlo Ersek wrote: > Jordan, do you intend to review this? If so, I'll wait. (Take your time.) Series Reviewed-by: Jordan Justen > Qin Long, can you please look at the CryptoPkg patches? They are simple, > and it's not possible to build OVMF with Secure Boot support with

Re: [edk2] [RFC PATCH V7 00/27] Introduce Mp Service protocol to UefiCpuPkg

On 2014-11-06 17:23:01, Fan, Jeff wrote: > Chen, > > Thanks your contribution. I will check-in your patch if there is no > further comments from other guys. > > Reviewed-by: Jeff Fan Chen, I committed your series (r16345-r16371) for Jeff (to preserve the separate patches). Thanks for all your

Re: [edk2] [PATCH v2 6/6] OvmfPkg XenBusDxe: Convert X64/TestAndClearBit.asm to NASM

On Thu, Nov 13, 2014 at 07:00:18PM +0100, Laszlo Ersek wrote: > On 11/13/14 18:55, Anthony PERARD wrote: > > On Thu, Nov 13, 2014 at 12:13:23PM +0100, Laszlo Ersek wrote: > > >> But nasm emits the same warning. Any ideas? > > > > Yes, put lock and btr on the same line ... > > ASM_PFX(TestAndClea

[edk2] [PATCH 5/4] OvmfPkg/XenBusDxe: Fix a nasm warning about instruction not lockable.

The fix, having "lock" and the locked instruction on the same line in the source. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD --- OvmfPkg/XenBusDxe/X64/TestAndClearBit.nasm | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/OvmfPkg/Xen

Re: [edk2] [PATCH v2 6/6] OvmfPkg XenBusDxe: Convert X64/TestAndClearBit.asm to NASM

On 11/13/14 18:55, Anthony PERARD wrote: > On Thu, Nov 13, 2014 at 12:13:23PM +0100, Laszlo Ersek wrote: >> But nasm emits the same warning. Any ideas? > > Yes, put lock and btr on the same line ... > ASM_PFX(TestAndClearBit): > - lock > - btr [rdx], ecx > + lock btr [rdx], ecx > sbb e

Re: [edk2] [PATCH v2 6/6] OvmfPkg XenBusDxe: Convert X64/TestAndClearBit.asm to NASM

On Thu, Nov 13, 2014 at 12:13:23PM +0100, Laszlo Ersek wrote: > Anthony, > > On 11/06/14 12:24, Anthony PERARD wrote: > > The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert > > X64/TestAndClearBit.asm to X64/TestAndClearBit.nasm > > > > Contributed-under: TianoCore Contribution

Re: [edk2] [PATCH v5 2/9] OvmfPkg: PlatformPei: Platform specific ACPI power management setup

On 11/13/14 18:40, Gabriel Somlo wrote: > On Thu, 13 Nov 2014 09:27:09 -0600, Scott Duplichan wrote: >> Gabriel Somlo [mailto:gso...@gmail.com] wrote: >> ]On Sun, Nov 09, 2014 at 05:00:38PM -0800, Jordan Justen wrote: >> ]> On 2014-11-08 14:01:56, Gabriel L. Somlo wrote: >> ]> > @@ -228,6 +229,11 @

Re: [edk2] [PATCH v5 2/9] OvmfPkg: PlatformPei: Platform specific ACPI power management setup

On Thu, 13 Nov 2014 09:27:09 -0600, Scott Duplichan wrote: > Gabriel Somlo [mailto:gso...@gmail.com] wrote: > ]On Sun, Nov 09, 2014 at 05:00:38PM -0800, Jordan Justen wrote: > ]> On 2014-11-08 14:01:56, Gabriel L. Somlo wrote: > ]> > @@ -228,6 +229,11 @@ MiscInitialization ( > ]> >VOID > ]> >

[edk2] [PATCH 2/4] OvmfPkg/XenBusDxe: Fix some types.

This patch replace some types in GrantTable and the argument Index of XenHypercallHvmGetParam to what the types should be. This avoid to have type cast in code. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD --- OvmfPkg/XenBusDxe/GrantTable.c | 4 ++-- O

[edk2] [PATCH 0/4] OvmfPkg/Xen* build fix for VS2010

Hi, I've took ovmf-ia32-msft-xen.patch from Scott Duplichan and made a few changes. So the first two patchs of this series changes the type of some variables/arguments/fields in order to avoid to have to cast them to a different type. Then, the last two patchs are what's left from Scott patch an

[edk2] [PATCH 3/4] OvmfPkg/XenBusDxe: fix VS2010 build failures

From: Scott Duplichan This patch contain only type cast. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan Signed-off-by: Anthony PERARD --- OvmfPkg/XenBusDxe/EventChannel.c | 6 +++--- OvmfPkg/XenBusDxe/GrantTable.c | 4 ++-- OvmfPkg/XenBusDxe/XenBus.

[edk2] [PATCH 4/4] OvmfPkg/XenPvBlkDxe: fix VS2010 build failures

From: Scott Duplichan This patch contain type casts and replace one * operation by a MultU64x32() call. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan Signed-off-by: Anthony PERARD --- OvmfPkg/XenPvBlkDxe/BlockFront.c | 16 OvmfPkg/XenP

[edk2] [PATCH 1/4] OvmfPkg/XenBusDxe: In XenStore, replace type of Len from UINTN to UINT32.

Since a message to XenStore have a lenght of type UINT32, have XenStore.c deal only with UINT32 instead of a mixmatch with UINTN. This patch replaces the type of Len in WRITE_REQUEST and the type of the argument Len of XenStoreWriteStore and XenStoreReadStore. This patch should avoid to have type

Re: [edk2] [PATCH 2/2] ArmGicLib: select GICv2 mode if SRE is present but unavailable

On 13 November 2014 17:47, Olivier Martin wrote: > Ard, I have just reviewed and committed your patch (SVN rev16344). > > I removed the reference to Linux kernel to answer Christoffer comment. > I also replaced 'lower levels' by 'higher privilege levels'. > OK, thanks! For the record, the origin

Re: [edk2] [PATCH v2 0/7] CryptoPkg and OvmfPkg build fixes for gcc and VS2010

On 11/13/14 17:47, Scott Duplichan wrote: > Laszlo Ersek [mailto:ler...@redhat.com] wrote: > > > ]Version 2 of > ], with a > ]fix squashed in patch #2, for Scott's report in > ]

Re: [edk2] [PATCH v2 0/7] CryptoPkg and OvmfPkg build fixes for gcc and VS2010

Laszlo Ersek [mailto:ler...@redhat.com] wrote: ]Version 2 of ], with a ]fix squashed in patch #2, for Scott's report in ]. ] ]Laszlo Ersek (4): ] OvmfPg: flas

Re: [edk2] [PATCH 2/2] ArmGicLib: select GICv2 mode if SRE is present but unavailable

Ard, I have just reviewed and committed your patch (SVN rev16344). I removed the reference to Linux kernel to answer Christoffer comment. I also replaced 'lower levels' by 'higher privilege levels'. Christoffer, yes ArmGicV3SetControlSystemRegisterEnable() does an isb() after changing the system

[edk2] UDK2014.SP1 issue with DHCP6 Driver

The UDK2014.SP1 has an issue with the DHCP6 driver from the NetworkPkg. When using LLT method to calculate the DHCP6 DUID, function Dhcp6GenerateClientId() will write data to the pointer's pointer &Duid incorrectly, which cause system crash during every boot and possible data corruption. Curre

[edk2] SecurityPkg: TPM2_SetPrimaryPolicy command

Hello! Would it be possible to add the command TPM2_SetPrimaryPolicy to Tpm2CommandLib? The command is required to set platformPolicy and use cases are: * OEM/BIOS sets platformPolicy to authorize TPM firmware upgrade. * OEM/BIOS delegates the TPM_RH_PLATFORM role for a specific TPM co

Re: [edk2] [PATCH v5 2/9] OvmfPkg: PlatformPei: Platform specific ACPI power management setup

Gabriel Somlo [mailto:gso...@gmail.com] wrote: ]On Sun, Nov 09, 2014 at 05:00:38PM -0800, Jordan Justen wrote: ]> On 2014-11-08 14:01:56, Gabriel L. Somlo wrote: ]> > @@ -228,6 +229,11 @@ MiscInitialization ( ]> >VOID ]> >) ]> > { ]> > + UINT16 HostBridgeDevId; ]> > + UINTN PmCmd; ]> >

Re: [edk2] [PATCH v5 2/9] OvmfPkg: PlatformPei: Platform specific ACPI power management setup

On Wed, Nov 12, 2014 at 11:41:54AM -0800, Jordan Justen wrote: > On 2014-11-12 05:38:28, Gabriel Somlo wrote: > > On Tue, Nov 11, 2014 at 07:54:30PM -0800, Jordan Justen wrote: > > > > > When I build IA32 (OvmfPkg/build.sh -a IA32) I get warnings about > > > > > possibly uninitialized variables. >

[edk2] [PATCH v2 1/7] OvmfPg: flash driver: fix type of EFI_SIZE_TO_PAGES argument (VS2010)

The MarkMemoryRangeForRuntimeAccess() function passes the Length parameter (of type UINT64) to the macro EFI_SIZE_TO_PAGES(). When building for the Ia32 platform, this violates the interface contract of the macro: [...] Passing in a parameter that is larger than UINTN may produce unexpecte

[edk2] [PATCH v2 4/7] OvmfPkg: QemuVideoDxe: the VBE shim needs no 64-bit shifts (VS2010)

From: Scott Duplichan The SegmentC local variable has type EFI_PHYSICAL_ADDRESS for (justified) style reasons. However, the 64-bit bit-shifts that it undergoes result in intrinsic calls when built with VS2010 for Ia32 / NOOPT. The concrete value of SegmentC, 0xC, and the results of the bito

[edk2] [PATCH v2 6/7] CryptoPkg: TimestampTokenVerify(): fix gcc-4.8 / Ia32 build failure

SVN r16339 ("CryptoPkg Updates to support RFC3161 timestamp signature verification.") introduced the following build failure: > CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c: In function > 'TimestampTokenVerify': > CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c:538:3: error: passing > argument 2 of 'd2

[edk2] [PATCH v2 3/7] OvmfPkg: flash driver: drop needlessly wide multiplication (VS2010)

From: Scott Duplichan The current types of subexpressions used in QemuFlashPtr() are as follows. (We also show the types of "larger" subexpressions, according to operator binding.) mFlashBase + (Lba * mFdBlockSize) + Offset ^ ^ ^^ | | |

[edk2] [PATCH v2 7/7] CryptoPkg: OpenSslSupport.h: edk2-ize offsetof() macro for gcc-4.8 / X64

Code added in SVN r16339 ("CryptoPkg Updates to support RFC3161 timestamp signature verification.") introduced many new uses of the offsetof() macro. Since the offsetof() macro in "OpenSslSupport.h" casts a pointer to an "int", it triggers a large number of error: cast from pointer to integer of

[edk2] [PATCH v2 0/7] CryptoPkg and OvmfPkg build fixes for gcc and VS2010

Version 2 of , with a fix squashed in patch #2, for Scott's report in . Laszlo Ersek (4): OvmfPg: flash driver: fix type of EFI_SIZE_TO_PAGES argument (VS2010

[edk2] [PATCH v2 5/7] OvmfPkg: VirtioScsiDxe: drop 64-bit shift in PopulateRequest() (VS2010)

From: Scott Duplichan "Lun" has type UINT64 in this function. The result of the expression (UINT8) ((Lun >> 8) | 0x40) depends only on bits [15:8] of "Lun", therefore we can cast "Lun" to UINT32 before shifting it. This eliminates an intrinsic when building with VS2010 for Ia32 / NOOPT. Con

[edk2] [PATCH v2 2/7] OvmfPg: flash driver: drop gratuitous 64-by-32 bit divisions (VS2010)

In the InitializeVariableFvHeader() function, all three of "Offset", "Start" and "BlockSize" have type UINTN. Therefore the (Offset / BlockSize) and (Start / BlockSize) divisions can be compiled on all platforms without intrinsics. In the current expressions (EFI_LBA) Offset / BlockSize (EFI_

Re: [edk2] [PATCH v2 6/6] OvmfPkg XenBusDxe: Convert X64/TestAndClearBit.asm to NASM

Anthony, On 11/06/14 12:24, Anthony PERARD wrote: > The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert > X64/TestAndClearBit.asm to X64/TestAndClearBit.nasm > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Anthony PERARD > --- > OvmfPkg/XenBusDxe/X

Re: [edk2] [PATCH v5 6/9] OvmfPkg: AcpiTimerLib: Use global variable during PEI_CORE and PEIM

On 11/13/14 00:22, Andrew Fish wrote: > >> On Nov 12, 2014, at 2:26 PM, Jordan Justen wrote: >> Too bad the DebugAgent isn't actually useful for all the trouble it >> causes. :) > > 1st question what is wrong with the DebugAgent? Why is int not useful? There's nothing wrong with it, it's just t