Jordan:
I have no other comment. Reviewed-by: Liming Gao
Thanks
Liming
-Original Message-
From: Justen, Jordan L
Sent: Thursday, October 22, 2015 6:03 AM
To: Zhu, Yonghong; Gao, Liming
Cc: Bjorge, Erik C; edk2-devel@lists.01.org
Subject: Re: [PATCH] BaseTools/Scripts: Add PatchCheck.py
On 2015/10/22 7:02, Andrew Fish wrote:
"/usr/bin/clang" -target x86_64-pc-win32-macho -c -g -Os -Wall -Werror -Wextra
-include AutoGen.h -funsigned-char -fno-ms-extensions -fno-stack-protector -fno-builtin
-fshort-wchar -mno-implicit-float -mms-bitfields -Wno-unused-parameter
-Wno-missing-brac
Jordan,
CPU ID only could get the max logical processor number supported in current
socket. It cannot handle multi-sockets case.
Yes. We could promote PcdCpuMaxLogicalProcessorNumber to dynamic type. But we
need find one reliable way like you said to set it before CPU MP PEI not only
CPU MP DX
Looks good. Reviewed by jiewen@inter.com
-Original Message-
From: Kinney, Michael D
Sent: Thursday, October 22, 2015 7:26 AM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Fan, Jeff
Subject: [PATCH] UefiCpuPkg: PiSmmCpuDxeSmm: Remove unused references to SmmLib
The PiSmmCpuDxeSmm modu
The PiSmmCpuDxeSmm module does not use any services from the SmmLib.
This change removes the SmmLib from PiSmmCpuDxeSmm module and also
removes the lib mapping in the UefiCpuPkg DSC file because no other
modules in the UefiCpuPkg use the SmmLib.
Contributed-under: TianoCore Contribution Agreement
"/usr/bin/clang" -target x86_64-pc-win32-macho -c -g -Os -Wall -Werror -Wextra
-include AutoGen.h -funsigned-char -fno-ms-extensions -fno-stack-protector
-fno-builtin -fshort-wchar -mno-implicit-float -mms-bitfields
-Wno-unused-parameter -Wno-missing-braces -Wno-missing-field-initializers
-Wno-
Yonghong, Liming,
I have gotten two reviews for this patch. Do either of you have
concerns with me committing this change to BaseTools?
-Jordan
On 2015-10-07 19:53:18, Jordan Justen wrote:
> This script can be used to check some expected rules for EDK II
> patches. It only works on git formatted
On 2015-10-21 14:19:40, Kinney, Michael D wrote:
> Laszlo,
>
> We have the PCD that specifies the max CPUs.
>
> ## Specifies max supported number of Logical Processors.
> # @Prompt Configure max supported number of Logical Processors
>
> gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorN
Laszlo,
We have the PCD that specifies the max CPUs.
## Specifies max supported number of Logical Processors.
# @Prompt Configure max supported number of Logical Processors
gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber|64|UINT32|0x0002
We could exit the wait loop as soon as
On 2015-10-21 01:44:39, Laszlo Ersek wrote:
> On 10/20/15 22:09, Janusz wrote:
> > W dniu 20.10.2015 o 21:27, Laszlo Ersek pisze:
> >> Due to Linux kernel commit b18d5431acc7 ("KVM: x86: fix CR0.CD
> >> virtualization"), vCPUs need more time to start up, because:
> >>
> >> - KVM now zaps all the ma
On 10/21/15 17:04, Laszlo Ersek wrote:
> On 10/21/15 14:10, Laszlo Ersek wrote:
>> On 10/15/15 00:25, Laszlo Ersek wrote:
>>
>>> Test environment and results:
>>>
>>> Host kernel:
>>> - latest RHEL-7 development kernel (3.10.0-323.el7), with Paolo's
>>> following patches backported by yours truly
> On Oct 21, 2015, at 8:31 AM, Laszlo Ersek wrote:
>
> On 10/21/15 17:13, Leif Lindholm wrote:
>> Hi Andrew, (list on cc)
>>
>> Having a look at rewriting the ARM PL061Gpio driver since I find the
>> current version too complicated to review Haojian's patches against.
>> Now, it has a PL061Gpio
I can second that tianocore wiki works (with few modifications) after having
just finished a port on ARM platform.
Also, going forward, need to update the wiki with details from what Leif has
suggested.
Thanks,
Supreeth
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@ml01
On 10/21/15 17:13, Leif Lindholm wrote:
> Hi Andrew, (list on cc)
>
> Having a look at rewriting the ARM PL061Gpio driver since I find the
> current version too complicated to review Haojian's patches against.
> Now, it has a PL061Gpio.h in ArmPlatformPkg/Include/Drivers/ - but
> since the driver
On Wed, 21 Oct 2015, Fabio Fantoni wrote:
> Il 21/10/2015 14:45, Laszlo Ersek ha scritto:
> > On 10/21/15 13:39, Stefano Stabellini wrote:
> > > Empty cdroms are not going to connect, avoid waiting for the backend to
> > > switch to state 4, which is never going to happen, and return
> > > error in
On 10/21/15 17:11, Paolo Bonzini wrote:
>
>
> On 21/10/2015 17:04, Laszlo Ersek wrote:
>> Now, on TCG, reading the APIC ID register (for device "apic") happens in:
>>
>> apic_mem_readl() [hw/intc/apic.c]
>> val = s->id << 24
>>
>> Whereas on KVM, the same occurs in:
>>
>> kvm_apic_mem_read() [h
On 10/21/15 12:27, Paolo Bonzini wrote:
>
>
> On 21/10/2015 12:22, Laszlo Ersek wrote:
>> On 10/21/15 11:51, Paolo Bonzini wrote:
>>>
>>>
>>> On 20/10/2015 12:08, Laszlo Ersek wrote:
>>
>> 64 KVM>=1"KVM: entry failed, hardware error 0x8021"
>>
On 2015/10/21 14:46, Derek Lin wrote:
Current variable driver already have memory cache to improve performance.
Change the code which read from physical MMIO address to read from memory cache.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Derek Lin
---
.../Universal/V
Hi Andrew, (list on cc)
Having a look at rewriting the ARM PL061Gpio driver since I find the
current version too complicated to review Haojian's patches against.
Now, it has a PL061Gpio.h in ArmPlatformPkg/Include/Drivers/ - but
since the driver is registered via the EmbeddedGpio interface, this
h
On 21/10/2015 17:04, Laszlo Ersek wrote:
> Now, on TCG, reading the APIC ID register (for device "apic") happens in:
>
> apic_mem_readl() [hw/intc/apic.c]
> val = s->id << 24
>
> Whereas on KVM, the same occurs in:
>
> kvm_apic_mem_read() [hw/i386/kvm/apic.c]
> return ~(uint64_t)0;
>
> Ho
On 10/21/15 14:10, Laszlo Ersek wrote:
> On 10/15/15 00:25, Laszlo Ersek wrote:
>
>> Test environment and results:
>>
>> Host kernel:
>> - latest RHEL-7 development kernel (3.10.0-323.el7), with Paolo's
>> following patches backported by yours truly:
>> - KVM: x86: clean up kvm_arch_vcpu_runna
On 21/10/2015 14:10, Laszlo Ersek wrote:
> [...] The first message appears in the log:
>
>
> SMRAM TileSize = 0800
> CPU[000] APIC ID= SMBASE=7FFC1000 SaveState=7FFD0C00 Size=0400
> CPU[001] APIC ID=0001 SMBASE=7FFC1800 SaveState=7FFD1400 Size=0400
> SmmReloc
Adding Jordan.
On 10/21/15 03:14, Kinney, Michael D wrote:
> Bruce,
>
> No. Different ASSERT().
>
> That looks like a new bug, and it is in the new code I added to force BSP to
> wait for all APs to enter sleeping state before StartupAllAPs() is called.
>
> How did you reproduce this?
Actual
On 10/21/15 13:39, Stefano Stabellini wrote:
> Empty cdroms are not going to connect, avoid waiting for the backend to
> switch to state 4, which is never going to happen, and return
> error instead from XenPvBlockFrontInitialization(). Detect an
> empty cdrom by looking at the "params" node on xen
On 10/15/15 00:25, Laszlo Ersek wrote:
> Test environment and results:
>
> Host kernel:
> - latest RHEL-7 development kernel (3.10.0-323.el7), with Paolo's
> following patches backported by yours truly:
> - KVM: x86: clean up kvm_arch_vcpu_runnable
> - KVM: x86: fix SMI to halted VCPU
>
>
Empty cdroms are not going to connect, avoid waiting for the backend to
switch to state 4, which is never going to happen, and return
error instead from XenPvBlockFrontInitialization(). Detect an
empty cdrom by looking at the "params" node on xenstore, which is set to
"" or "aio:" for empty drives
I just want to say that this is one of the best reviews I have ever
received, very clear and useful. Thanks Laszlo!
On Tue, 20 Oct 2015, Laszlo Ersek wrote:
> (1) Please make the subject line say:
>
> OvmfPkg: XenPvBlkDxe: handle empty cdrom drives
>
> On 10/20/15 17:03, Stefano Stabellini wro
I can confirm that the tutorial on the tianocore wiki works just fine
because I've just finished a port using that(it's a ARM-2ndstage platform
though).
On Wed, Oct 21, 2015 at 9:43 AM, Laszlo Ersek wrote:
> On 10/21/15 04:44, Yehuda Yitschak wrote:
> > Hello everyone
> >
> >
> > i started readi
On 10/21/15 12:27, Paolo Bonzini wrote:
>
>
> On 21/10/2015 12:22, Laszlo Ersek wrote:
>> On 10/21/15 11:51, Paolo Bonzini wrote:
>>>
>>>
>>> On 20/10/2015 12:08, Laszlo Ersek wrote:
>>
>> 64 KVM>=1"KVM: entry failed, hardware error 0x8021"
>>
On 21/10/2015 12:22, Laszlo Ersek wrote:
> On 10/21/15 11:51, Paolo Bonzini wrote:
>>
>>
>> On 20/10/2015 12:08, Laszlo Ersek wrote:
>
> 64 KVM>=1"KVM: entry failed, hardware error 0x8021"
> while guest in SMBASE relocation
>>> Tracing KVM
On 10/21/15 11:51, Paolo Bonzini wrote:
>
>
> On 20/10/2015 12:08, Laszlo Ersek wrote:
64 KVM>=1"KVM: entry failed, hardware error 0x8021"
while guest in SMBASE relocation
>> Tracing KVM shows the following:
>>
>> qemu-system-x86-3236
On 20/10/2015 12:08, Laszlo Ersek wrote:
>> >
>> > 64 KVM>=1"KVM: entry failed, hardware error 0x8021"
>> > while guest in SMBASE relocation
> Tracing KVM shows the following:
>
> qemu-system-x86-3236 [001] 10586.857752: kvm_enter_smm:vcpu
Hi Yehuda,
On Wed, Oct 21, 2015 at 02:44:19AM +, Yehuda Yitschak wrote:
> i started reading and experimenting with UEFI a month ago and i'm
> now considering to start porting it to one of Marvell's Aarch64 SOCs
>
> as a first stage i only want to get a basic shell running and start
> adding d
On 10/20/15 22:09, Janusz wrote:
> W dniu 20.10.2015 o 21:27, Laszlo Ersek pisze:
>> Due to Linux kernel commit b18d5431acc7 ("KVM: x86: fix CR0.CD
>> virtualization"), vCPUs need more time to start up, because:
>>
>> - KVM now zaps all the mappings for the guest memory in EPT or shadow page
>> t
CC'ing Eduardo
On 10/20/15 23:39, Jordan Justen wrote:
> On 2015-10-20 12:27:42, Laszlo Ersek wrote:
>> Due to Linux kernel commit b18d5431acc7 ("KVM: x86: fix CR0.CD
>> virtualization"), vCPUs need more time to start up, because:
>>
>> - KVM now zaps all the mappings for the guest memory in EPT o
On 21 October 2015 at 15:43, Laszlo Ersek wrote:
> On 10/21/15 04:44, Yehuda Yitschak wrote:
>> Hello everyone
>>
>>
>> i started reading and experimenting with UEFI a month ago and i'm
>> now considering to start porting it to one of Marvell's Aarch64 SOCs
>>
>> as a first stage i only want to ge
On 10/21/15 04:44, Yehuda Yitschak wrote:
> Hello everyone
>
>
> i started reading and experimenting with UEFI a month ago and i'm
> now considering to start porting it to one of Marvell's Aarch64 SOCs
>
> as a first stage i only want to get a basic shell running and start
> adding drivers with
37 matches
Mail list logo
