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 ava
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
>&
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.
>>
>> Th
d patch is the fix.
>
> Cc: Eric Dong
> Cc: Jian J Wang
> Cc: Jiewen Yao
> Cc: Paolo Bonzini
> Cc: Ruiyu Ni
Reviewed-by: Paolo Bonzini
Paolo
> Thanks
> Laszlo
>
> Laszlo Ersek (3):
> UefiCpuPkg/PiSmmCpuDxeSmm: update comments in IA32 SmmStartup()
> Ue
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
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
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
of
writing a full message is still a win.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen (Intel address)
Signed-off-by: Paolo Bonzini
---
.../PlatformDebugLibIoPort/DebugLibDetect.h| 57 ++
OvmfPkg/Library
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):
"
for the SEC library instance, separating the INF files and
moving the constructor to a separate C source file.
Contributed-under: TianoCore Contribution Agreement 1.1
Tested-by: Laszlo Ersek
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen (Intel address)
Signed-off-by: Pao
Remove Uefi.h, which includes UefiSpec.h, and change the
return value to match the RETURN_STATUS type.
Contributed-under: TianoCore Contribution Agreement 1.1
Tested-by: Laszlo Ersek
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen (Intel address)
Signed-off-by: Paolo Bonzini
C, so
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 Platfor
"
for the SEC library instance, separating the INF files and
moving the constructor to a separate C source file.
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen (Intel address)
Signed-off-by: Paolo Bonzini
---
OvmfP
of
writing a full message is still a win.
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen (Intel address)
Signed-off-by: Paolo Bonzini
---
OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 26 --
.../PlatformDeb
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Laszlo Ersek
Signed-off-by: Paolo Bonzini
---
OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/Library/PlatformDebugLibIoPort
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 inf
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,
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
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
> +// Vo
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 u
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 A
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
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 - In
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), h
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 spec
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" wi
On 22/08/2017 16:03, Ard Biesheuvel wrote:
> On 22 August 2017 at 14:27, Paolo Bonzini wrote:
>> 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" i
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 genera
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 c
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 a
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 wo
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. C
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)
=
K
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 EFI
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 (
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
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
---
BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BaseTools/Source/C/VfrCompile
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
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 tha
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 t
>
> Thanks
> Laszlo
>
>>
>> I could follow up to fix "AP Lost" issue.
>>
>> Thanks!
>> Jeff
>>
>>
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Saturday, November 12, 2016 3
could wait for all APs are running in safe code.
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=216
>
> Reported-by: Paolo Bonzini
> Cc: Laszlo Ersek
> Cc: Paolo Bonzini
> Cc: Jiewen Yao
> Cc: Michael D Kinney
> Contributed-under: TianoCore Contributi
> 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 Ia32
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
___
hy and how #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
> Cc: Tian, Feng ; edk2-de...@ml01.01.org; Kinney, Michael
> D ; Paolo B
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 [00
> +++
> 4 files changed, 128 insertions(+)
>
Reviewed-by: Paolo Bonzini
It would be slightly more robust to do the "InterlockedDecrement
(&mNumberToFinish);" while in safe state, but the race window is really
really small.
Paolo
> 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 ins
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
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 mNumb
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.
>
>
> * 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 fetc
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 hyperviso
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 == N
On 04/11/2016 04:20, Yao, Jiewen wrote:
> Good info. Thanks!
>
> I do not understand below word. I still see a **huge** performance gap.
>
> I am confused on how is it resolved in previous patch. Or do I need
> configure something for my QEMU?
The delay you're seeing comes from SmmWaitForApArr
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:
> https://raw.githubusercontent.com/efidroid/android_app_efidroidmanager/9d364dc4e8d59381d6c60404153c5dbf5aa4711a/app/sr
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) code
tion time of 101.4 uS.
>
> The idea comes from Michael and Paolo.
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Paolo Bonzini
> Cc: Paul A Lohr
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng
> ---
> PcAtChipse
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 A Lohr
> Contributed-under: TianoCore Contributio
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 suppor
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 bef
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 NA
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, and
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 f
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
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,
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
___
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
>
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 in
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. :)
When
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
>
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 course other GNU/Linux distros
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
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 mRebase
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
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 \
>
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 a
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 sof
=
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)
=
KVM
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 cre
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 loo
On 20/01/2016 19:15, Laszlo Ersek wrote:
> If you think it's unnecessary to test the *short* write case
> specifically, then I'm willing to give my T-b. Thanks for the patch!
Your testing is enough. The only way to test the short write case would
probably be by writing a custom application.
Pa
not missed, and
adds a further sanity check to DRQClear.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini
---
***UNTESTED***
MdeModulePkg/Bus/Ata/AtaAtapiPassThru/IdeMode.c | 32 ++---
1 file changed, 18 insertions(+), 14 deletion
On 19/01/2016 11:48, Laszlo Ersek wrote:
> Committed to SVN as r19684 and r19685.
That was a bit too fast... see my suggestion in the other thread.
Paolo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-de
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
On 09/12/2015 18:55, Kinney, Michael D wrote:
> 1) RTC driver use info from FADT in SetTime() when FADT is available.
> Add event notification to RTC driver to capture FADT info before
> ExitBootServices().
> 2) Use PCD in RTC driver and in ACPI FADT table.
>
> Advantage of (1) is that it is com
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 driv
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
Time, and that is not used at any place other than
SetupBrowserDxe. The ACPI tables should be available by then, shouldn't
they?
Paolo
> Mike
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Paolo
>> Bonzin
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 lo
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*
> opera
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 ord
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 + EFI_PAGE_SIZE
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
eported-by: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Yao, Jiewen
Cc: Michael D Kinney
Signed-off-by: Paolo Bonzini
---
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c| 2 +-
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmProfileArch.c | 2 +-
UefiCpuPkg/PiSmmCpuDxeSmm/M
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
__
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);
Sho
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
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 AP
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 seque
1 - 100 of 147 matches
Mail list logo
