Re: [edk2] [PATCH 3/4] ArmPkg/Mmu: Fix literal number left shift bug

On 6 September 2015 at 14:22, Leif Lindholm wrote: > On 6 September 2015 at 13:05, Ard Biesheuvel > wrote: >> On 6 September 2015 at 14:04, Leif Lindholm wrote: >>> On 6 September 2015 at 12:52, Ard Biesheuvel

Re: [edk2] [PATCH 4/4] ArmPkg/Mmu: Increase PageLevel when table found at the targeted level

On 09/06/2015 09:42 PM, Ard Biesheuvel wrote: On 6 September 2015 at 10:15, Heyi Guo wrote: Below code has bug since *BlockEntrySize and *TableLevel are not updated accordingly: if (IndexLevel == PageLevel) { // And get the appropriate BlockEntry at the next level

[edk2] [NvmExpressDxe] Why update cq head even if command timeout

Hi, The following code is from NvmExpressPassthru.c, at line 592, the cq head is updated even if the command timeout. Is there any reason for this? If completion queue is empty, this operation may corrupt the queue. Thanks, -Wenbo Code Copied from the latest NvmExpressPassthru.c

Re: [edk2] [PATCH 4/4] ArmPkg/Mmu: Increase PageLevel when table found at the targeted level

On 7 September 2015 at 11:16, Heyi Guo wrote: > > > On 09/06/2015 09:42 PM, Ard Biesheuvel wrote: >> >> On 6 September 2015 at 10:15, Heyi Guo wrote: >>> >>> Below code has bug since *BlockEntrySize and *TableLevel are not >>> updated accordingly: >>>

Re: [edk2] [PATCH 06/58] OvmfPkg: decompress FVs on S3 resume if SMM_REQUIRE is set

On 09/07/15 01:55, Jordan Justen wrote: > On 2015-07-24 16:00:12, Laszlo Ersek wrote: >> If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is >> not trusted and we should defend against it tampering with the firmware's >> data. >> >> One such datum is the PEI firmware volume

Re: [edk2] [PATCH 4/4] ArmPkg/Mmu: Increase PageLevel when table found at the targeted level

On 6 September 2015 at 10:15, Heyi Guo wrote: > Below code has bug since *BlockEntrySize and *TableLevel are not > updated accordingly: > > if (IndexLevel == PageLevel) { > // And get the appropriate BlockEntry at the next level > BlockEntry =

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

On 09/06/15 08:09, Tian, Feng wrote: > Hi, Laszlo > > Thanks for root cause this issue. > > We ever met the same issue when installing windows 8 32bit through > cdrom and we found: > > 1) Why 32bit UEFI win8 OS installation fails with some DVD-Only > devices is because OS would invoke a single

Re: [edk2] [PATCH 3/4] ArmPkg/Mmu: Fix literal number left shift bug

On 09/07/15 09:34, Ard Biesheuvel wrote: > On 6 September 2015 at 14:22, Leif Lindholm wrote: >> On 6 September 2015 at 13:05, Ard Biesheuvel >> wrote: >>> On 6 September 2015 at 14:04, Leif Lindholm >>> wrote:

[edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Madt.aslc: Fix MADT header version

Currently the MADT signature and revision is mapped to v1.0 macros which results in MADT with incorrect entries in the header for Juno. This patch fixes these EFI_ACPI_*_0_MULTIPLE_APIC_DESCRIPTION_TABLE macros by using appropriate v5.0 versions. Contributed-under: TianoCore Contribution

Re: [edk2] [PATCH] ArmPlatformPkg/ArmJunoPkg/Madt.aslc: Fix MADT header version

Hi Sudeep, I'm not involved in ACPI development, so am not able to review this. Regards, Ryan. On 7 September 2015 at 17:07, Sudeep Holla wrote: > Currently the MADT signature and revision is mapped to v1.0 macros > which results in MADT with incorrect entries in the

Re: [edk2] [NvmExpressDxe] Why update cq head even if command timeout

Hi, Wenbo Here "queue handling" what I meant is s/w SQ/CQ handling in EDKII NvmExpressDxe driver, we don't check command ID. We just check PT to know if there is a new completion queue entry. So with current logic, if there is a timeout happen and the upper layer send another command again,

Re: [edk2] [Patch] NetworkPkg: Fix suspicious dereference of pointer 'FieldCount'

Reviewed-by: Fu Siyuan -Original Message- From: Wu, Jiaxin Sent: Tuesday, September 8, 2015 9:41 AM To: edk2-devel@lists.01.org Cc: Ye, Ting ; Fu, Siyuan Subject: [Patch] NetworkPkg: Fix suspicious dereference of pointer

Re: [edk2] [NvmExpressDxe] Why update cq head even if command timeout

Because each command has an unique command ID, queue handling shall not miss up even if the completion is returned after timeout. -Original Message- From: Wenbo Wang [mailto:wenbo.w...@memblaze.com] Sent: Tuesday, September 8, 2015 10:23 AM To: 'Tian, Feng'; 'edk2-devel@lists.01.org'

Re: [edk2] [NvmExpressDxe] Why update cq head even if command timeout

Hi Feng, I am OK with step #1, it shall solve our problem. For step #2, it is good but a little complex, if sending the abort command after timeout, there are following possible results: 1. The last command's completion comes first. 2. The abort command's completion comes first. 3. No

Re: [edk2] [NvmExpressDxe] Why update cq head even if command timeout

Thanks Feng. In our test, when the command timeout, the completion queue is empty (head == tail), in this case if the driver moves head (head++), it corrupts the completion queue, the NVMe controller generates error. I think the HW behavior is correct because the driver shall not move head if

Re: [edk2] [NvmExpressDxe] Why update cq head even if command timeout

Hi, Wenbo Why we advanced one CQ entry in line 592 whatever the execution result of SQ is because there are two cases: 1. If timeout happens and no new completion queue entry is added, the CQH get updated to point to next entry. Nvme controller would know a new entry of completion queue is

Re: [edk2] [PATCH 05/58] OvmfPkg: Sec: assert the build-time calculated end of the scratch buffer

On 09/06/15 21:56, Jordan Justen wrote: > On 2015-07-24 16:00:11, Laszlo Ersek wrote: >> The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more >> memory, temporarily, than what PEIFV and DXEFV will ultimately need. >> First, it uses an output buffer for decompression, second, the >>