Re: [edk2] [PATCH v2 00/20] BaseTools: One step toward python3

On 01/02/2018 09:35, Gary Lin wrote: > v2 changes: > - Rebase to the current git HEAD (821807bcefb9a36e598d71a8004fae5aab2052a0) > - Apply "futurize -f libfuturize.fixes.fix_absolute_import" and > refactor some python scripts to break the circular imports. > > This patch series is also

Re: [edk2] [PATCH] UefiCpuPkg/LocalApicLib: Exclude second SendIpi sequence on AMD processors.

On 14/06/2018 07:39, Ni, Ruiyu wrote: > > > Thanks/Ray > >> -Original Message- >> From: edk2-devel On Behalf Of Paolo >> Bonzini >> Sent: Thursday, June 14, 2018 4:52 AM >> To: Laszlo Ersek ; Leo Duran ; >> edk2-devel@lists.01.org >&

Re: [edk2] [PATCH] UefiCpuPkg/LocalApicLib: Exclude second SendIpi sequence on AMD processors.

On 13/06/2018 22:49, Laszlo Ersek wrote: > Hello Leo, > > On 06/13/18 22:11, Leo Duran wrote: >> On AMD processors the second SendIpi in the SendInitSipiSipi and >> SendInitSipiSipiAllExcludingSelf routines is not required, and may cause >> undesired side-effects during MP initialization. >> >>

Re: [edk2] [PATCH 0/3] UefiCpuPkg/PiSmmCpuDxeSmm: fix IA32 SmmStartup() regression on KVM

d patch is the fix. > > Cc: Eric Dong <eric.d...@intel.com> > Cc: Jian J Wang <jian.j.w...@intel.com> > Cc: Jiewen Yao <jiewen@intel.com> > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Ruiyu Ni <ruiyu...@intel.com> Reviewed-by: Paolo Bonzini &l

Re: [edk2] [PATCH] OvmfPkg/VirtioScsiDxe: Allocate all required vrings at VirtioScsiInit

On 14/12/2017 07:55, zhengxiang (A) wrote: > Hello Laszlo and Paolo, > > Thanks for your review! > > On 2017/12/13 19:16, Laszlo Ersek wrote: >> On 12/13/17 10:29, Paolo Bonzini wrote: >>> On 13/12/2017 09:35, Laszlo Ersek wrote: >>>> Perhaps you can upd

Re: [edk2] [PATCH] OvmfPkg/VirtioScsiDxe: Allocate all required vrings at VirtioScsiInit

On 13/12/2017 09:35, Laszlo Ersek wrote: > I consider the lack of a "VIRTIO_SCSI_F_MQ" feature bit an issue with > the virtio specification (and consequently with vhost-scsi), not with > the guest driver(s). VIRTIO_SCSI_F_MQ does not exist because virtio-scsi has _always_ supported multiqueue and

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: disable only BM-DMA at ExitBootServices()

On 23/11/2017 14:08, Laszlo Ersek wrote: > On 11/23/17 03:20, Ni, Ruiyu wrote: >> I cannot explain precisely why the S4 resume fails. >> I can just guess: Windows might have some assumptions on the BM bit. > Can we make this configurable on the platform level somehow? > > On one hand, I certainly

[edk2] [PATCH v3 3/3] OvmfPkg: save on I/O port accesses when the debug port is not in use

ssage is still a win. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <ler...@redhat.com> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.jus...@intel.com> Signed-off-by: Paolo Bonzini <pbonz...@re

[edk2] [PATCH v3 0/3] OvmfPkg: save on I/O port accesses when the debug port is not in use

This is version 3 of the series to skip debug port I/O port writes when the debug port device wasn't added to the virtual machine. The differences from v2 are entirely cosmetic, and I'm including them at the end of this message for ease of review. Thanks, Paolo Paolo Bonzini (3): OvmfPkg

[edk2] [PATCH v3 2/3] OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC

biesheu...@linaro.org> Cc: Jordan Justen (Intel address) <jordan.l.jus...@intel.com> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- OvmfPkg/OvmfPkgIa32.dsc | 2 +- OvmfPkg/OvmfPkgIa32X64.dsc

[edk2] [PATCH v3 1/3] OvmfPkg: make PlatformDebugLibIoPort a proper BASE library

org> Cc: Jordan Justen (Intel address) <jordan.l.jus...@intel.com> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort

[edk2] [PATCH v2 0/2] OvmfPkg: save on I/O port accesses when the debug port is not in use

that the non-SEC version will be able to use a writable global variable. Patch 2 then adds the detection machinery to both library instances. The commit messages in both patches liberally pillage Laszlo's v1 review. Thanks, Paolo Paolo Bonzini (2): OvmfPkg: create a separate PlatformDebugLibIoPort

[edk2] [PATCH 1/2] OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC

address) <jordan.l.jus...@intel.com> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 15 --- .../PlatformDebugLibIoPort/DebugLibDetect.c| 32 + .../PlatformDebugLibI

[edk2] [PATCH] OvmfPkg: PlatformDebugLibIoPort: save on I/O port accesses when the debug port is not in use

ted-under: TianoCore Contribution Agreement 1.0 Cc: Laszlo Ersek <ler...@redhat.com> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/OvmfPkg/Library/P

Re: [edk2] Why do we use -g option of gcc even for RELEASE build?

On 08/11/2017 03:25, Heyi Guo wrote: > From gcc manual, -g option seems to produce debugging information. In > tools_def.template, -g is included in GCC_ALL_CC_FLAGS, so it will also > be enabled for RELEASE build with gcc tool chain. Any special reason to > do that? Why *not* actually? Debug

Re: [edk2] [PATCH v5 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Use global variables to replace macros

On 17/10/2017 16:50, Duran, Leo wrote: > To me, > - This proposed library function seems appropriate in the context of CPU > features (i..e, this is not a hack) > - I'd argue having to save & restore 512 "unused" bytes per SMI is > significant overheard that can be avoided. Can it be measured,

Re: [edk2] [PATCH v5 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Use global variables to replace macros

On 17/10/2017 16:23, Laszlo Ersek wrote: >> For the SRAM_SAVE_STATE_MAP_OFFSET: >> I propose returning the value by a function in SmmCpuFeaturesLib... > This has crossed my mind (superficially :) ), and I support your idea. > > Paolo, can you please comment? I don't see a reason why AMD must use

Re: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based x86 systems.

On 13/10/2017 03:52, Yao, Jiewen wrote: > I recommend we move AMD_SMRAM_SAVE_STATE_MAP_OFFSET to > UefiCpuPkg\Include\Register\Amd\SmramSaveStateMap.h, because it is standard. > +// > +// Definitions for AMD systems are based on contents of the > +// AMD64 Architecture Programmer's Manual > +//

Re: [edk2] [PATCH v5 0/2] Enhanced SMM support for AMD-based x86 systems.

On 16/10/2017 19:06, Laszlo Ersek wrote: > git log --reverse -- OvmfPkg/Library/SmmCpuFeaturesLib > > At this point I cannot determine if this patch set should ignore OvmfPkg > completely, or else patch #1 should be duplicated for > "OvmfPkg/Library/SmmCpuFeaturesLib" as well. (I guess I don't

Re: [edk2] [PATCH v5 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Use global variables to replace macros

On 14/10/2017 17:51, Duran, Leo wrote: >>> + // Override PSD offset for AMD >>> + // >>> + if (SmmStandardSignatureIsAuthenticAMD ()) { >>> +gStmPsdOffset = AMD_SMM_PSD_OFFSET; } >>> + >> I think the right thing to do here would be to use the SMM state save map >> revision; in the case of

Re: [edk2] [PATCH v5 1/2] UefiCpuPkg/SmmCpuFeaturesLib: Use global variables to replace macros

On 11/10/2017 21:45, Leo Duran wrote: > + // Override PSD offset for AMD > + // > + if (SmmStandardSignatureIsAuthenticAMD ()) { > +gStmPsdOffset = AMD_SMM_PSD_OFFSET; > + } > + I think the right thing to do here would be to use the SMM state save map revision; in the case of AMD, the low

Re: [edk2] [PATCH 5/6] MdeModulePkg/Crc32: Fix possible out of range left shift

On 19/09/2017 13:43, Hao Wu wrote: >NewValue = 0; >for (Index = 0; Index < 32; Index++) { > -if ((Value & (1 << Index)) != 0) { > - NewValue = NewValue | (1 << (31 - Index)); > +if ((Value & (((UINT32)1) << Index)) != 0) { > + NewValue = NewValue | (((UINT32)1) << (31 -

Re: [edk2] [PATCH 4/6] MdeModulePkg/DxeNetLib: Fix negative value left shift

On 19/09/2017 13:43, Hao Wu wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=698 > > Within function NetRandomInitSeed(), left shift a negative value is used > in: > "~Time.Hour << 24" > > which involves undefined behavior. > > Since Time.Hour is of type UINT8 (range from 0 to 23),

Re: [edk2] [PATCH 3/6] MdeModulePkg/Tpl: Fix negative value left shift

On 19/09/2017 13:43, Hao Wu wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=695 > > Within function CoreRestoreTpl(), left shift a negative value -2 is used > in: > "while (((-2 << NewTpl) & gEventPending) != 0) {" > > which involves undefined behavior. > > According to the C11

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] [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 13:59, Laszlo Ersek wrote: > This seems to suggest that "-pie" is the *master* switch (used only when > linking), and "-fpie" is a *prerequisite* for it (to be used both when > linking and compiling). Is this right? > > If so, then I think this is a gcc usability bug. We don't

Re: [edk2] allocation zone extensions for the firmware linker/loader

On 08/06/2017 19:44, Michael S. Tsirkin wrote: > On Tue, Jun 06, 2017 at 08:10:17PM +0200, Laszlo Ersek wrote: >> On 06/05/17 18:02, Michael S. Tsirkin wrote: >>> On Sat, Jun 03, 2017 at 09:36:23AM +0200, Laszlo Ersek wrote: On 06/02/17 17:45, Laszlo Ersek wrote: > The patches can

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

Re: [edk2] SMRAM sizes on large hosts

On 03/05/2017 15:14, Laszlo Ersek wrote: > I'd prefer a solution that would keep the fw logic / code flow related > to register configuration intact, and would just replace a few numbers / > constants if possible. I see. In my other answer I tried to keep it as intact as possible. I'm a bit

Re: [edk2] SMRAM sizes on large hosts

On 03/05/2017 08:57, Gerd Hoffmann wrote: > qemu implements what physical q35 support. The extended smram register > has two bits for the tseg size, three out of the four values are used > (for 1, 2, 8 MB sizes). "11" is reserved in the specs. We could use > "11" to implement a bigger tseg.

[edk2] CFP: KVM Forum 2017

KVM Forum 2017: Call For Participation October 25-27, 2017 - Hilton Prague - Prague, Czech Republic (All submissions must be received before midnight June 15, 2017) =

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] 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/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] [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 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 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 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 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 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 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/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.

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.

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 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 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] [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] 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] 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] 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] 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 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 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] 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] 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] 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] 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] 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] [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] [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

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 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] [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] [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] 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 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 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 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] 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

[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] 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] 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] [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 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

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] 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 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] [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 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 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 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 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 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

  1   2   >