Re: [edk2] [PATCH v2 00/16] unify GCC command line options

On 18/08/2015 08:52, Ard Biesheuvel wrote: Personally, I would not mind deprecating GCC44, but the biggest question I would have is what toolchains do the latest UDK releases claim to support. We also have the issue that every time I ask about deprecating a toolchain, Larry looks at

Re: [edk2] BaseTools features: multiple workspaces

On 03/08/2015 05:56, Gao, Liming wrote: Hi, all We will update BaseTools feature to allow more than one workspaces. The detail design in the below. Please help review it. If you have any comments, please let me know. 1. Keep $(WORKSPACE) environment as is a. $(WORKSPACE)

Re: [edk2] [PATCH 11/58] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

On 28/07/2015 20:44, Laszlo Ersek wrote: I have a significant update for this patch. On S3 resume, the APMC_EN bit (and other bits) are cleared in SMI_EN (which is necessary, see qemu commit be66680e). For the trigger method to work right after S3 resume, the APMC_EN bit must be set again

Re: [edk2] apparent SMBASE relocation issue with noexec enabled [was: MdeModulePkg DxeIpl: Add stack NX support]

On 07/08/2015 01:02, Laszlo Ersek wrote: The trace covers the full lifetime of the guest (I started tracing before launching the guest, and I passed -no-reboot to qemu, so when the guest crashed, QEMU exited.) This was on 3.10.0-299.el7.x86_64. I repeated the test with EPT off. The

Re: [edk2] apparent SMBASE relocation issue with noexec enabled [was: MdeModulePkg DxeIpl: Add stack NX support]

On 06/08/2015 16:31, Laszlo Ersek wrote: kvm_cpuid:func 8001 rax 6e8 rbx 0 rcx 0 rdx 10 kvm_enter_smm:vcpu 0: leaving SMM, smbase 0x7ffc kvm_entry:vcpu 0 kvm_exit: reason TRIPLE_FAULT rip 0x7ffdb6b2 info 0 0 kvm_userspace_exit:

Re: [edk2] [PATCH v3 27/52] OvmfPkg: use relaxed AP SMM synchronization mode

On 23/10/2015 17:29, Laszlo Ersek wrote: > I plan to drop this patch, dependent on testing, and on how a new QEMU > patch I've written will be received on qemu-devel. I'm not sure why it can't be fixed within the firmware. Your patch to QEMU to use current_cpu obviously makes sense (that's why

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 03/11/2015 15:35, Xiao Guangrong wrote: > > -if ((cr0 ^ old_cr0) & X86_CR0_CD) > +if (!kvm_check_has_quirk(vcpu->kvm, KVM_X86_QUIRK_CD_NW_CLEARED) && > +(cr0 ^ old_cr0) & X86_CR0_CD) > kvm_zap_gfn_range(vcpu->kvm, 0, ~0ULL); > >

Re: [edk2] [PATCH v4 18/41] OvmfPkg: select LocalApicLib instance with x2apic support if SMM_REQUIRE

On 04/11/2015 21:08, Laszlo Ersek wrote: > On 11/04/15 17:55, Kinney, Michael D wrote: >> Laszlo, >> >> BaseXApicX2ApicLib is intended to be used by platforms that support more >> >=256 CPUs. >> >> If the current system configuration is < 256 CPUs, then the platform will >> typically stay in

Re: [edk2] [PATCH v4 18/41] OvmfPkg: select LocalApicLib instance with x2apic support if SMM_REQUIRE

On 05/11/2015 02:04, Laszlo Ersek wrote: > On 11/04/15 22:35, Kinney, Michael D wrote: >> Laszlo, >> >> Yes. They are compatible. And I do recommend switching to >> BaseXApicX2ApicLib unconditionally. > > Thanks everyone for the feedback, I'll update the patch. > > Paolo, in case this turns

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 03/11/2015 20:42, Jordan Justen wrote: > On 2015-11-03 05:45:52, Paolo Bonzini wrote: >> >> >> On 03/11/2015 14:25, Laszlo Ersek wrote: >>> - Agreement between Paolo, Jordan and Mike about implementing >>> broadcast SMIs.

Re: [edk2] [Patch 3/3] UefiCpuPkg/CpuDxe: Place APs into protected mode when ExitBootService

On 26/10/2015 23:31, Laszlo Ersek wrote: > > If QEMU could evaluate the AP state and not send an SMI to an AP in > > Wait-forSIPI, then updating SMIs to broadcast to all AP should work > > for SeaBios and OVMF. Yup, this has to be fixed in both QEMU and KVM (separately). I'm not 100% sure of

Re: [edk2] [Patch 3/3] UefiCpuPkg/CpuDxe: Place APs into protected mode when ExitBootService

On 27/10/2015 03:12, Fan, Jeff wrote: > Yes. On physical hw, Aps will not response SMI if Aps received SMI in > WFSI state. But Aps will have one pending SMI and will enter into SMM > once Aps receive Startup IPI. Interesting... so if the BIOS doesn't do SMBASE relocation, an INIT-SMI-SIPI

Re: [edk2] [PATCH v4 13/41] OvmfPkg: LockBox: -D SMM_REQUIRE excludes our fake lockbox

ryAllocationHob ( > +(EFI_PHYSICAL_ADDRESS)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageBase), > +(UINT64)(UINTN) PcdGet32 (PcdOvmfLockBoxStorageSize), > +mS3Supported ? EfiACPIMemoryNVS : EfiBootServicesData > +); > +} > > if (FeaturePcdGet (PcdSmmSmramRequire)) { >UINT32 TsegSize; > Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 12/41] OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE

+Status = gBS->InstallMultipleProtocolInterfaces ( > +, > + , NULL, > +NULL > +); > +ASSERT_EFI_ERROR (Status); > + } > >Status = gBS->CreateEventEx ( >EVT_NOTIFY_SIGNAL, > Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 35/41] OvmfPkg: port CpuS3DataDxe to X64

On 03/11/2015 22:01, Laszlo Ersek wrote: > From: Paolo Bonzini <pbonz...@redhat.com> > > The descriptor format is different and the assembly source is > converted to nasm, but otherwise there is no difference. > > Contributed-under: TianoCore Contribution Agreement 1.

Re: [edk2] [PATCH 6/6] OvmfPkg/PlatformPei: Set PcdCpuMaxLogicalProcessorNumber using QEMU fw_cfg

On 03/11/2015 14:25, Laszlo Ersek wrote: > - Agreement between Paolo, Jordan and Mike about implementing > broadcast SMIs. I am willing to code up whatever design is > agreed upon. Can everyone involved please prioritize this > discussion a little? Actually, I was

Re: [edk2] [PATCH v3 26/52] OvmfPkg: SmmCpuFeaturesLib: customize state save map format

On 18/10/2015 09:38, Jordan Justen wrote: > > This adjusts the previously introduced state save map access functions, to > > account for QEMU and KVM's 64-bit state save map following the AMD spec > > rather than the Intel one. > > Shouldn't this layout match the processor being emulated? I

Re: [edk2] [PATCH v2 11/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

On 13/10/2015 15:26, Laszlo Ersek wrote: >>// >> + // The write to the control register is synchronous and only affects the >> + // current CPU, so bring in the APs first. The SMI handler expects that >> + // all APs will rendez-vous within one PcdCpuSmmApSyncTimeout (though it >> + //

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

On 15/10/2015 03:31, Fan, Jeff wrote: > Ersek & Bonzini, > > From SDM 34.5.2, SMI Handler Operating Mode Switching. > "Any required change to operating mode is performed by the RSM instruction; > there is no need for the SMI > handler to change modes explicitly prior to executing RSM." > >

Re: [edk2] [PATCH v3 03/52] UefiCpuPkg: PiSmmCpuDxeSmm: do not execute RSM from 64-bit mode

On 16/10/2015 09:41, Yao, Jiewen wrote: > Hello According to "IA32 SDM, page 1428, 4-330 Vol. 2B, RSM?Resume > from System Management Mode", I do not find word say: 64bit mode is > invalid. Would you please point out where you find "RSM is invalid in > 64-bit mode "? It's in the heading. It

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" >>>>

[edk2] [PATCH 5/4] OvmfPkg: use relaxed AP SMM synchronization mode

virtual platform does not have problems with cacheability of SMRAM, so we can use "directed" SMIs instead. To do this, just set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode to 1 (aka SmmCpuSyncModeRelaxedAp). This fixes SMM on multiprocessor virtual machines. Signed-off-by: Paolo Bonz

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

On 05/10/2015 01:57, Michael Kinney wrote: > Add module that initializes a CPU for the SMM envirnment and > installs the first level SMI handler. This module along with the > SMM IPL and SMM Core provide the services required for > DXE_SMM_DRIVERS to register hardware and software SMI handlers.

Re: [edk2] [PATCH v2 11/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

s. This could also be fixed by setting gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode to 1 (aka SmmCpuSyncModeRelaxedAp), but this only takes effect on X64 CPUs which also ironically we don't support yet. Therefore, the following seems to be the correct fix. With it, TCG still takes a whil

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

On 12/10/2015 18:23, Paolo Bonzini wrote: > > > On 05/10/2015 01:57, Michael Kinney wrote: >> Add module that initializes a CPU for the SMM envirnment and >> installs the first level SMI handler. This module along with the >> SMM IPL and SMM Core pr

Re: [edk2] [PATCH v2 11/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

On 13/10/2015 15:26, Laszlo Ersek wrote: > On the other hand, I don't know if Quark is a UP vs. MP system to begin > with. Quark is UP only. It's so UP that it triggers an erratum if you use lock-prefixed instructions. :) > Either the EFI_SMM_CONTROL2_PROTOCOL.Trigger() > spec is incomplete

[edk2] [PATCH 2/4] OvmfPkg: SmmCpuFeaturesLib: remove unnecessary bits

SMRR and MTRR support is not needed on a virtual platform. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- .../Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 180 +++-- .../SmmCpuFeaturesLib/SmmCpuFeaturesL

[edk2] [PATCH 4/4] OvmfPkg: SmmCpuFeaturesLib: customize state save map format

This adjusts the previously introduced state save map access functions, to account for QEMU and KVM's 64-bit state save map following the AMD spec rather than the Intel one. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- O

Re: [edk2] [PATCH v2 11/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

On 13/10/2015 15:43, Laszlo Ersek wrote: > I'll squash your fix into the next version, with many thanks. :) It's > our platform after all, and we can do in OvmfPkg whatever needs to be > done on it. :) Indeed. Though, since the OVMF SmmCpuFeaturesLib will not require configuring the MTRRs on

Re: [edk2] [PATCH v2 11/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

On 13/10/2015 18:35, Brian J. Johnson wrote: > > Traditionally, SMI handling has been global. If the h/w didn't > broadcast the SMI to all CPUs, the SMI handler did so itself. The BSP > would wait for all APs to "check in" to SMM, then it would do whatever > work the SMI required, and signal

Re: [edk2] [PATCH v2 11/41] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER

On 13/10/2015 18:49, Laszlo Ersek wrote: >> > >> > However, this (obviously) doesn't scale well, so Intel has been moving >> > towards signaling SMI to only a single processor, and avoiding the >> > machine-wide rendezvous when it isn't necessary. BIOS implementations >> > may be lagging

Re: [edk2] [PATCH] MdeModulePkg: ScsiDiskDxe: adapt SectorCount when shortening transfers

On 08/09/2015 09:02, Tian, Feng wrote: > Hi, Laszlo > > 1. I don't think the code in VirtioScsi.c is correct. It hardcodes > the block size as 512bytes. The driver should send READ_CAPACITY cmd to get > block size, then convert it to InTransferLength & OutTransferLength. This is the

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

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 why it is done for kernels and apps, but where

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

On 10/09/2015 16:24, Kevin Davis wrote: > Further leading me to guess that any actual use of those > implementations could lead to you actually needing to hire a real > attorney and not one that you find on YouTube. The good thing is that attorneys have already figured it out. IBM figured out

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

On 01/10/2015 16:12, Janusz wrote: > Now, I can also add, that the problem is only when I allow VM to use > more than one core, so with option for example: > -smp 8,cores=4,threads=2,sockets=1 and other combinations like -smp > 4,threads=1 its not working, and without it I am always running VM

Re: [edk2] TFTP issue, Ping 1st packet reply missing

On 28/09/2015 12:24, Leekha Shaveta wrote: > Hi Laszlo, > > Please find the detailed "tcpdump" on my setup: You still aren't following Laszlo's instructions: "your dump is missing the DHCP packets that should be captured while the ifconfig program (launched from the UEFI shell) brings up the

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

r Graf <ag...@suse.de>; qemu devel list <qemu-de...@nongnu.org>; Hannes Reinecke <h...@suse.de>; Gabriel L. Somlo (GMail) <gso...@gmail.com>; Peter Jones <pjo...@redhat.com>; Peter Batard <p...@akeo.ie>; Gerd Hoffmann <kra...@redhat.com>;

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

On 18/09/2015 11:37, Janusz wrote: > Hello, > > I am writting about this patch that was posted by Xiao: > http://www.spinics.net/lists/kvm/msg119044.html and this: > http://www.spinics.net/lists/kvm/msg119045.html > I've tested both kernel 4.2 and 4.3 and problem still exists when I use > OVMF

Re: [edk2] [PATCH v4 05/10] OvmfPkg: SataControllerDxe: enable IO / mem access and DMA when binding

On 16/09/2015 04:57, Laszlo Ersek wrote: > (OvmfPkg's copy of SataControllerDxe must differ from the same in DuetPkg > because Duet inherits a pre-configured SATA controller from the BIOS, as > explained by Feng.) It's not true that it _must_ differ. Duet _may_ avoid setting the bits because

Re: [edk2] [PATCH] BaseTools GCC: avoid the use of COMMON symbols

On 04/12/2015 11:39, Laszlo Ersek wrote: > (4) Linking those two files into a complete program is a violation of > "6.7 External definitions": > > [...] If an identifier declared with external linkage is used in an > expression (other than as part of the operand of a *sizeof* >

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

On 09/12/2015 12:16, Ni, Ruiyu wrote: > Scott, I debugged the issue further and had the below findings: > According to the ACPI spec 6.0 5.2.9 Fixed ACPI Description Table > (FADT), the FADT.Century can be set to 0 indicating the RTC doesn't > support to store century value. But the Win7 boot

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

On 09/12/2015 18:37, Laszlo Ersek wrote: > - A DXE driver that runs before *both* the ACPI platform DXE driver, and > this runtime DXE driver -- to be ordered by any means necessary --, *or* > a PEIM, sets a dynamic PCD that keys off *both* the ACPI platform DXE > driver and this runtime DXE

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

On 09/12/2015 18:11, Kinney, Michael D wrote: > Paolo, > > I agree SetTime() is not called in very many places. But since the > SetTime() service is added to Runtime Services Table when the RTC > driver runs, the logic in SetTime() must be implemented to handle > case where SetTime() is called

Re: [edk2] [patch 2/2] UefiCpuPkg/PiSmmCpu: Always set WP in CR0.

On 27/11/2015 02:14, Yao, Jiewen wrote: > [Jiewen] Do you mean KVM reject SMM write BIT16 of CR0 ? It is odd, > because my patch sets W+P bit page table entries. That's odd indeed. All common OSes run with CR0.WP=1. I'll try to reproduce... Paolo

Re: [edk2] [patch 1/2] UefiCpuPkg/PiSmmCpu: Always set RW+P bit for page table by default.

On 27/11/2015 15:21, Laszlo Ersek wrote: > On 11/27/15 15:07, Yao, Jiewen wrote: >> > So quick! >> > Thank you very much to catch this! > You'll get used to Paolo... the only reason he opens the SDM is not > because he needs to look up the details. He remembers those. He looks at > the SDM in

Re: [edk2] [patch 1/2] UefiCpuPkg/PiSmmCpu: Always set RW+P bit for page table by default.

On 25/11/2015 13:34, jiewen yao wrote: > @@ -785,7 +785,7 @@ Gen4GPageTable ( >// Set Page Directory Pointers >// >for (Index = 0; Index < 4; Index++) { > -Pte[Index] = (UINTN)PageTable + EFI_PAGE_SIZE * (Index + 1) + IA32_PG_P; > +Pte[Index] = (UINTN)PageTable +

[edk2] [PATCH] UefiCpuPkg/PiSmmCpu: fix generation of 32-bit PAE page tables

Reported-by: Laszlo Ersek <ler...@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Yao, Jiewen <jiewen@intel.com> Cc: Michael D Kinney <michael.d.kin...@intel.com> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Pa

Re: [edk2] please DO NOT commit unreviewed patches to subversion!

On 27/11/2015 13:07, Laszlo Ersek wrote: > On 11/27/15 12:31, Yao, Jiewen wrote: >> Hi Laszlo and Ard >> First of all, I apologize the confusing brought. >> You are right. I am still using SVN to commit patch, until it is finally >> moved to GIT. :-( >> The patch is reviewed and I did adopt the

Re: [edk2] [Patch] PcAtChipsetPkg/Rtc: Fix a UEFI Win7 boot hang issue

On 18/11/2015 06:08, Zeng, Star wrote: > > @@ -508,6 +509,7 @@ PcRtcSetTime ( > RtcWrite (RTC_ADDRESS_DAY_OF_THE_MONTH, RtcTime.Day); > RtcWrite (RTC_ADDRESS_MONTH, RtcTime.Month); > RtcWrite (RTC_ADDRESS_YEAR, (UINT8) RtcTime.Year); > + RtcWrite (RTC_ADDRESS_CENTURY, Century);

Re: [edk2] An unkempt git guide for edk2 contributors and maintainers

On 12/02/2016 02:09, Laszlo Ersek wrote: > (23) Now we'll format the patches as email messages, and send them to > the list. Standing in the root of your edk2 directory, run the > following (note that the "-O" option needs customization: please > update the pathname to the file

Re: [edk2] [patch 1/2] MdeModulePkg/Ide: return correct status when DRQ is not ready for ATAPI

On 19/01/2016 00:29, Laszlo Ersek wrote: >> INQUIRY works slightly different from other commands. It has a maximum >> length instead of a deterministic length; once HCYL/LCYL are read back, >> should RequiredBytes not be adjusted in this case? (This way we don't >> short the loop, we just finish

[edk2] [PATCH] MdeModulePkg/.../IdeMode: correctly report length of returned data

, and adds a further sanity check to DRQClear. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- ***UNTESTED*** MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c | 32 ++--- 1 file changed, 18 insertions(

Re: [edk2] [PATCH] MdeModulePkg/.../IdeMode: correctly report length of returned data

On 21/01/2016 02:27, Tian, Feng wrote: > Paolo, > > I think for short write case it means the data length to be written in > AtaPacketReadWrite, that is ByteCount, is less than the one shipped in ATA > cmd, for example, CDB (READ10.byte7&8). > > For such case, it should jump out the while

[edk2] KVM Forum 2016: Call For Participation

= KVM Forum 2016: Call For Participation August 24-26, 2016 - Westin Harbor Castle - Toronto, Canada (All submissions must be received before midnight May 1, 2016) =

Re: [edk2] Software SMI STS bit is not set when writing port B2 in QEMU Q35

On 15/03/2016 10:10, Ni, Ruiyu wrote: > Paolo, Laszlo, > As I mentioned in previous mail, the EAX I got from CpuSaveState > is different from what I set before entering SMM. > Because the failure was seen in a QEMU launched in Windows > using the following command: > qemu-system-x86_64.exe \ >

Re: [edk2] Software SMI STS bit is not set when writing port B2 in QEMU Q35

On 15/03/2016 12:59, Ni, Ruiyu wrote: >> > I'm not sure. The above command line works for me after building OVMF >> > like this: >> > >> >build -p OvmfPkg/OvmfPkgIa32X64.dsc -a IA32 -a X64 -b DEBUG -t GCC49 -n >> > 4 >> > >> > I'm using commit 89a8115 ("BaseTools: Support recent versions

Re: [edk2] Software SMI STS bit is not set when writing port B2 in QEMU Q35

On 15/03/2016 16:48, Ni, Ruiyu wrote: > I don't think CSM matters and the bin I am using cannot be > distributed. Does the qemu build steps matters? I ran configure > --target-list=x86_64-softmmu. I traced the code and found the code > hung when SMM is relocating. The code was waiting for

Re: [edk2] Software SMI STS bit is not set when writing port B2 in QEMU Q35

On 14/03/2016 09:18, Ni, Ruiyu wrote: > I tried to hook a software SMI (triggered by B2) but the handler/callback > was never called. > > I know that when booting to ACPI OS, OS writes to B2 with certain value > to tell firmware to enable SCI. That is achieved through the software SMI. > The

Re: [edk2] Software SMI STS bit is not set when writing port B2 in QEMU Q35

On 14/03/2016 10:51, Ni, Ruiyu wrote: > > The layout of CpuSaveState is different from what is described in > Intel IA32 manual. Seems QEMU specific. > The CpuSaveState pointer is correct. > I dumped the CpuSaveState content. The SMMBase and SMMRevId > is correct. But EAX is incorrect. I have

Re: [edk2] [PATCH v2] OvmfPkg/PlatformPei: Fix VS2008 build breakage

On 18/03/2016 22:53, Laszlo Ersek wrote: > > The correct character to use in that situation is the emdash, If you > > *absolutely* must, then rewrite the whole sentence to avoid using it. > > Do *not* replace it with hyphens. > > Okay. I've googled the use of emdash in the English language, and

Re: [edk2] [PATCH 00/62] Add FatPkg with 2-clause BSD license

On 30/03/2016 10:42, Laszlo Ersek wrote: >> > Contributed-under: TianoCore Contribution Agreement 1.0 >> > Signed-off-by: Jordan Justen > This is huge. It will enable Fedora to ship OvmfPkg and ArmVirtPkg > builds. It will enable RHEL to ship OVMF in Main. > > Of

Re: [edk2] [RFC] Proposal to organize packages into directories

On 18/05/2016 01:57, Kinney, Michael D wrote: > Core > CorebootModulePkg > CorebootPayloadPkg I think that anything with a .fdf file should be under Platform. CorebootPayloadPkg is the only outlier in your proposal. > Emulated > DuetPkg > EmulatorPkg > Nt32Pkg >

Re: [edk2] [RFC] Proposal to organize packages into directories

On 19/05/2016 18:03, Ryan Harkin wrote: > > IA32X64 is not a great name, but neither is Intel. X86 suggests 32-bit > > only. > > I prefer the idea of separating by vendor. One vendor may have > multiple architectures, for example. That's exactly why I want to separate by architecture. :)

Re: [edk2] [RFC] Proposal to organize packages into directories

On 19/05/2016 18:21, Kinney, Michael D wrote: > This is one of the reasons I wanted to have both a "Silicon" and a "Driver" > top level directory. > > We can change names, but the idea is that the "Silicon" one would contains > CPU/Chipset/SoC content that is usually contains the drivers to

Re: [edk2] [RFC] Proposal to organize packages into directories

et's keep it and make sure we > add new content to the right directory going forward. > > Mike > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo >> Bonzini >> Sent: Thursday, May 19, 2016 10:21 AM >&

Re: [edk2] a "strange" branch taken in the SMM fault handler in PiSmmCpuDxe

On 01/06/2016 12:50, Laszlo Ersek wrote: > In other words, the fault is raised and delivered (== the handler is > entered) entirely within non-root operation, inside the VM. I find this > amazing. (Amazingly annoying.) It is indeed. You can try using ept=0 to see the page faults. Paolo

Re: [edk2] a "strange" branch taken in the SMM fault handler in PiSmmCpuDxe

On 01/06/2016 14:26, Laszlo Ersek wrote: > On 06/01/16 13:30, Paolo Bonzini wrote: >> >> >> On 01/06/2016 12:50, Laszlo Ersek wrote: >>> In other words, the fault is raised and delivered (== the handler is >>> entered) entirely within non-root operation,

Re: [edk2] KVM Forum 2016: Call For Participation

On 10/03/2016 19:09, Paolo Bonzini wrote: > === > IMPORTANT DATES > === > Notification: May 27, 2015 On behalf of the program committee, I apologize for the delay in sending out the notifications. If you need to know in advance whether your talk has b

Re: [edk2] minimum NASM version

On 14/07/2016 19:11, Laszlo Ersek wrote: > * I didn't say, but I also tried "mov ax, ds". The SDM writes, "The > upper 56 bits or 48 bits (respectively) of the destination > general-purpose register are not modified by the operation". In this > context, those bits were known to be zero,

Re: [edk2] minimum NASM version

On 14/07/2016 13:19, Laszlo Ersek wrote: > The problem is that NASM wouldn't support segment register MOVs in > 64-bit mode until the following commit: > > http://repo.or.cz/nasm.git/commitdiff/21d4ccc3c338 > > Wed, 25 Aug 2010 02:28:00 +0200 (24 17:28 -0700) > > However, that change was

Re: [edk2] minimum NASM version

On 14/07/2016 19:25, Laszlo Ersek wrote: >> > Ugh, this is so wrong. :) I guess you could also use a macro that >> > expands to >> > >> >bits 32 >> >mov src, dst >> >bits 64 >> > >> > because the encoding is the same in 32-bit and 64-bit. > Nice trick :), but the point of using

Re: [edk2] [PATCH] PcAtChipsetPkg AcpiTimerLib: Get more accurate TSC Frequency

On 11/08/2016 04:37, Star Zeng wrote: > Minimize the code overhead between the two TSC reads by adding > new internal API to calculate TSC Frequency instead of reusing > MicroSecondDelay (). > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Paul

Re: [edk2] [PATCH 0/5] MdePkg BaseTools: GCC optimization for X64

On 14/07/2016 16:57, Ard Biesheuvel wrote: >> > On patch 5, I don't see any change for IA32 arch. is there no mode for >> > IA32 arch? Here, small and pic must be enabled together, right? Otherwise, >> > the assumption is to load driver below 2G address. Have you collected size >> > data

Re: [edk2] [PATCH v2 3/5] BaseTools/tools_def: enable Os optimization for GCC X64 builds

On 16/07/2016 14:29, Laszlo Ersek wrote: > > However, I recall from the thread that -Os enables -fomit-frame-pointer, > which might make source level debugging impossible (according to the GCC > manual). This is only with very old debuggers. Current debuggers use DWARF annotations which

Re: [edk2] [PATCH] PcAtChipsetPkg AcpiTimerLib: Wait 363 ACPI timer counts to get TSC Freq

bration time of 101.4 uS. > > The idea comes from Michael and Paolo. > > Cc: Michael D Kinney <michael.d.kin...@intel.com> > Cc: Liming Gao <liming@intel.com> > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Paul A Lohr <paul.a.l...@intel.com> > Contribu

Re: [edk2] [PATCH] VfrCompile: fix invalid comparison between pointer and integer

On 15/02/2017 09:46, Zhu, Yonghong wrote: > > "-s ''" is an error, current the error message is not same as no option, > because the content after the " all be treated as -s 's input. > May I know what's your comment on Nikolai SAOUKH's patch ? > > - if (mStringFileName == '\0' ) { > + if

Re: [edk2] [PATCH] VfrCompile: fix invalid comparison between pointer and integer

On 13/02/2017 14:55, Zhu, Yonghong wrote: > Hi Paolo Bonzini, > > We already had another patch for this issue. Please help to check the > attachment. Thanks. Is it intended that "-s ''" is not an error, rather it is the same as no option at all? Paolo > Bes

[edk2] [PATCH] VfrCompile: fix invalid comparison between pointer and integer

This would be valid C but is not valid C++, so change the comparison to do what it has always been doing. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/BaseTools/So

Re: [edk2] [PATCH V2 0/6] Enable SMM page level protection.

On 09/11/2016 16:54, Paolo Bonzini wrote: >> > and 2) AP is in protected mode with paging disabled. > It is not clear to me what the (4) SIPI done is there for, and why it is > triggered in S3Resume.c rather than CpuS3.c. And why does it take so > much for APs to complete

Re: [edk2] [PATCH V2 0/6] Enable SMM page level protection.

On 09/11/2016 16:01, Yao, Jiewen wrote: > 1) CpuS3.c – EarlyInitializeCpu() > 2) CpuS3.c – SmmRelocateBases() > 3) CpuS3.c – InitializeCpu() > 4) S3Resume.c – SendSmiIpiAllExcludingSelf() > > I believe we can guarantee 1/2/3 is good, because I found we check BSP > check

Re: [edk2] [PATCH V2 0/6] Enable SMM page level protection.

> Another question I have -- and I feel I should really know it, but I > don't... -- is *why* the APs are executing code from the page at > 0x9f000. This I can answer. :) The APs have done their INIT-SIPI-SIPI, and then went into the CLI;HLT;JMP loop. When the AP exits SMM, it is in the JMP

Re: [edk2] [PATCH V2 0/6] Enable SMM page level protection.

> * Second, the instruction that causes things to blow up is <0f aa>, > i.e., RSM. I have absolutely no clue why RSM is executed: It's probably not RSM. RSM is probably the last instruction executed before, and it's still in the buffer because, as you said, there's no way that you can

Re: [edk2] [PATCH V2 0/6] Enable SMM page level protection.

On 09/11/2016 07:25, Yao, Jiewen wrote: > Current BSP just uses its own context to initialize AP. So that AP > takes BSP CR3, which is SMM CR3, unfortunately. After BSP initialized > APs, the AP is put to HALT-LOOP in X64 mode. It is the last straw, > because X64 mode halt still need paging. >

Re: [edk2] [PATCH v2 3/3] UefiCpuPkg/PiSmmCpuDxeSmm: Decrease mNumberToFinish in AP safe code

BSP could wait for all APs are running in safe code. > > https://bugzilla.tianocore.org/show_bug.cgi?id=216 > > Reported-by: Paolo Bonzini <pbonz...@redhat.com> > Cc: Laszlo Ersek <ler...@redhat.com> > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Jiewen Yao <ji

Re: [edk2] [PATCH 0/2] Put AP into safe hlt-loop code on S3 path

On 10/11/2016 11:41, Laszlo Ersek wrote: > Here's an excerpt from the KVM trace: > >> CPU-23509 [002] 8406.908787: kvm_enter_smm:vcpu 1: entering SMM, >> smbase 0x3 >> CPU-23509 [002] 8406.908836: kvm_enter_smm:vcpu 1: leaving SMM, >> smbase 0x7ffb3000 >> CPU-23510

Re: [edk2] [PATCH V2 0/6] Enable SMM page level protection.

#3 enter SMM, please let us know. > > > Thank you > Yao Jiewen > > > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, November 10, 2016 4:46 AM > To: Yao, Jiewen <jiewen@intel.com> > Cc: Tian, Feng <feng.t...@intel.com>; ed

Re: [edk2] [PATCH V2 0/6] Enable SMM page level protection.

> And, in my recent KVM / QEMU usage instructions for Jiewen: > > https://www.mail-archive.com/edk2-devel@lists.01.org/msg19446.html > > I provided the following settings: > > > # Settings for Ia32 only: > > [...] > > QEMU_COMMAND="qemu-system-i386 -cpu coreduo,-nx" > > > > # Settings for

Re: [edk2] [PATCH V2 0/6] Enable SMM page level protection.

On 10/11/2016 15:48, Yao, Jiewen wrote: > I cannot reproduce it before, because all my real hardware supports XD. > My Windows QEMU also supports XD (to my surprise.) QEMU can be configured to support XD or not. Possibly Laszlo was using some different default, or testing both cases. Paolo

Re: [edk2] [PATCH 0/2] Put AP into safe hlt-loop code on S3 path

> +++ > 4 files changed, 128 insertions(+) > Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> It would be slightly more robust to do the "InterlockedDecrement ();" while in safe state, but the race window is really really small. Paolo

Re: [edk2] [PATCH v2 0/3] Put AP into safe hlt-loop code on S3 path

On 14/11/2016 11:39, Laszlo Ersek wrote: > You've tried that: > > https://www.mail-archive.com/edk2-devel@lists.01.org/msg02840.html > https://www.mail-archive.com/edk2-devel@lists.01.org/msg02923.html Uh, right. :) > Do you suggest to make the LocalApicLib instances usable at runtime? > For

Re: [edk2] [PATCH v2 0/3] Put AP into safe hlt-loop code on S3 path

On 14/11/2016 12:27, Laszlo Ersek wrote: > Well... > > http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05658.html > http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg00125.html > http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg00563.html > > Are you suggesting

Re: [edk2] [PATCH v2 0/3] Put AP into safe hlt-loop code on S3 path

On 14/11/2016 19:07, Laszlo Ersek wrote: > On 11/14/16 13:00, Paolo Bonzini wrote: >> >> >> On 14/11/2016 12:27, Laszlo Ersek wrote: >>> Well... >>> >>> http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg05658.html >>> http://lists

Re: [edk2] using UEFI logo as part of another logo

On 31/10/2016 05:59, Michael Zimmermann wrote: > Hi, > > since the uefi logo guidlines are mainly targeted at "pure logo" usage I'm > not sure if the following would be legal: >

Re: [edk2] [PATCH 0/6] Enable SMM page level protection.

On 04/11/2016 14:28, Yao, Jiewen wrote: > I tried below way. But it does not help too much. It still takes more > than 1 minutes to boot with SMP=8. > > SendSmiIpiAllExcludingSelf (); > IoWrite8 (ICH9_APM_STS, DataPort== NULL ? 0 : *DataPort); > IoWrite8 (ICH9_APM_CNT, CommandPort ==

Re: [edk2] [PATCH 0/6] Enable SMM page level protection.

On 04/11/2016 16:22, Laszlo Ersek wrote: >> > What does this *KVM internal error. Suberror: 1* mean? > The key message is "emulation failure" -- it means that the processor > exits to the hypervisor (KVM) because it finds some code that it cannot > execute in guest mode natively, so the

Re: [edk2] SmmCommunicationCommunicate question?

On 13/10/2016 11:07, Laszlo Ersek wrote: > > Instead, once the first CPU enters SMM, it brings all the other CPUs > into SMM as well, where they will be executing known, secure code -- > i.e., the first CPU to enter SMM forces the other CPUs to temporarily > abandon any (possibly malicious)

Re: [edk2] [PATCH] MdeModulePkg: ScsiDiskDxe: fix to support EFI_ERASE_BLOCK_PROTOCOL

On 15/04/2017 15:44, Haojian Zhuang wrote: > If bit TPZ and bit TPRZ are set, the erase feature is implemented. > If bit TPZ is set and bit TPRZ is clear, the discard feature is > implemented. And discard is a non-secure variant of the erase > functionality. > > So the detecting operation of

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

On 22/08/2017 16:03, Ard Biesheuvel wrote: > On 22 August 2017 at 14:27, Paolo Bonzini <pbonz...@redhat.com> wrote: >> On 22/08/2017 13:59, Laszlo Ersek wrote: >>> This seems to suggest that "-pie" is the *master* switch (used only when >>&g

Re: [edk2] [PATCH 1/1] BaseTools/tools_def.template: revert to large code model for X64/GCC5/LTO

On 22/08/2017 18:04, Laszlo Ersek wrote: >> That said, the extra "-Wl," in "-Wl,-pie" is not necessary; the compiler >> driver knows "-pie" and swallows it when compiling (and passes it to the >> linker). > Now *that* I can get behind. If this works, then please let us do it -- > replace "-fpie"

Re: [edk2] SMRAM sizes on large hosts

On 03/05/2017 15:35, Laszlo Ersek wrote: >> I see. In my other answer I tried to keep it as intact as possible. >> >> I'm a bit worried about the limits on the number of fw-cfg files. > We've promoted that to a device property in QEMU commit e12f3a13e2e1 > ("fw-cfg: turn FW_CFG_FILE_SLOTS into

  1   2   >