On 19 October 2018 at 13:25, Zeng, Star wrote:
> Be honest, I am not clear about the history why EfiBootServicesData is
> required for ESRT. But OS indeed cares about ESRT table, for example, I guess
> the Firmware in Device Manager for Windows is built based on ESRT table. In
> fact, I think
Be honest, I am not clear about the history why EfiBootServicesData is required
for ESRT. But OS indeed cares about ESRT table, for example, I guess the
Firmware in Device Manager for Windows is built based on ESRT table. In fact,
I think OS loader can access either EfiBootServicesData or
On 19 October 2018 at 13:01, Ard Biesheuvel wrote:
> On 19 October 2018 at 12:48, Zeng, Star wrote:
>> Ok, thanks and got the case.
>>
>> DxeCapsuleLibVirtualAddressChangeEvent may be too late as it could not
>> allocate pool to do caching.
>> I meant registering gEfiSystemResourceTableGuid
On 19 October 2018 at 12:48, Zeng, Star wrote:
> Ok, thanks and got the case.
>
> DxeCapsuleLibVirtualAddressChangeEvent may be too late as it could not
> allocate pool to do caching.
> I meant registering gEfiSystemResourceTableGuid event group
> notification(installconfigurationtable will
Ok, thanks and got the case.
DxeCapsuleLibVirtualAddressChangeEvent may be too late as it could not allocate
pool to do caching.
I meant registering gEfiSystemResourceTableGuid event group
notification(installconfigurationtable will trigger event group) and do caching
in the notification
On 19 October 2018 at 12:39, Zeng, Star wrote:
> Ard,
>
> What is the real case you met that has firmware to access ESRT configuration
> table at runtime?
>
When called from the OS, UpdateCapsule() crashes when IsFmpCapsule()
is invoked, because it attempts to access the ESRT. The driver uses
Ard,
What is the real case you met that has firmware to access ESRT configuration
table at runtime?
I am thinking about a possible solution with current situation.
The consumer can cache ESRT configuration table by a
gEfiSystemResourceTableGuid even group notification.
Thanks,
Star
On 18 October 2018 at 14:25, Leif Lindholm wrote:
> On Thu, Oct 18, 2018 at 02:09:33PM +0800, Ard Biesheuvel wrote:
>> Enable support for HTTPS boot by incorporating the TLS DXE driver into
>> the build, and the driver that permits enrolling the TLS certificates.
>>
>> Contributed-under:
Hi Brian,
I've started having a look at this, and have a few comments:
- There is no Readme.md at the top level, as set out in
https://github.com/tianocore/edk2-staging/blob/about/README
Mainly, this means I don't know who I should cc on any comments I have.
- There have been substantial
(+ Peter)
On 19 October 2018 at 11:46, Zeng, Star wrote:
> Hi Ard,
>
> Thanks for the patch.
>
> Cc more people who knows ESRT.
>
> UEFI 2.7 chapter 23.3:
> The ESRT shall be stored in memory of type EfiBootServicesData.
>
> Seeming, we need update UEFI spec if firmware really needs access ESRT
Hi Ard,
Thanks for the patch.
Cc more people who knows ESRT.
UEFI 2.7 chapter 23.3:
The ESRT shall be stored in memory of type EfiBootServicesData.
Seeming, we need update UEFI spec if firmware really needs access ESRT
configuration table at runtime.
Thanks,
Star
-Original Message-
On 19 October 2018 at 10:54, Ard Biesheuvel wrote:
> Given that the firmware itself may access the ESRT table when the OS
> invokes the UpdateCapsule () boot service,
*runtime* service
> it requires a virtual mapping
> and so it needs to be allocated from RtServicesData memory.
>
>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1262
Current implementation of BaseLib APIs:
AsciiStrToUnicodeStr()
AsciiStrToUnicodeStrS()
AsciiStrnToUnicodeStrS()
do not handle EASCII properly.
More specifically, if the value of ASCII character is larger than 0x7F,
then the converted
Given that the firmware itself may access the ESRT table when the OS
invokes the UpdateCapsule () boot service, it requires a virtual mapping
and so it needs to be allocated from RtServicesData memory.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Because MSR has scope attribute, driver has no needs to set
MSR for all APs if MSR scope is core or package type. This patch
updates code to base on the MSR scope value to add MSR to the register
table.
Cc: Ruiyu Ni
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
AcpiCpuData add new fields, keep these fields if old data already existed.
Cc: Ruiyu Ni
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
Reviewed-by: Ruiyu Ni
---
UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c | 2 ++
1 file changed, 2 insertions(+)
V4 changes:
1. Serial console log for different threads when program register table.
2. Check the AcpiCpuData before use it to avoid potential ASSERT.
V3 changes:
1. Use global variable instead of internal function to return string for
register type
and dependence type.
2. Add comments for
V4 changes include:
1. Serial debug message for different threads when program the register table.
V3 changes include:
1. Use global variable instead of internal function to return string for
register type
and dependence type.
2. Add comments for some complicated logic.
V2 changes include:
V4 changes:
1. Update comments.
v3 changes:
1. Move CPU_FEATURE_DEPENDENCE_TYPE definition to AcpiCpuData.h.
2. Add comments for CPU_FEATURE_BEFORE/CPU_FEATURE_AFTER.
v1 changes:
Add new core/package dependence types which consumed by different MSRs.
Cc: Ruiyu Ni
Cc: Laszlo Ersek
v3 changes:
1. Move CPU_FEATURE_DEPENDENCE_TYPE definition here from
RegisterCpuFeaturesLib.h file.
2. Add Invalid type for REGISTER_TYPE which will be used in code.
v2 changes:
1. Add more description about why we do this change.
2. Change structure field type from pointer to
V4 changes include:
1. Add SpinLock to serial console log for different threads when set register
table.
2. For PiSmmCpuDxeSmm driver, check the AcpiCpuData structure data before use
it to
avoid potential assert case.
V3 changes include:
1. Add comments for some complicate logic.
2. Use
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1240
Tests:
a. Access freed pages in shell to see if it triggers #PF
b. Use debugger to verify page table attributes matching freed pages
c. Exhaust memory space to see if the BIOS still works
Regards,
Jian
> -Original Message-
>
UAF (Use-After-Free) memory detection is new feature introduced to
detect illegal access to memory which has been freed.
Jian J Wang (3):
MdeModulePkg/MdeModulePkg.dec: add new PCD for UAF detection feature
UefiCpuPkg/CpuDxe: fix an infinite loop issue
MdeModulePkg/Core: add use-after-free
The UAF (Use-After-Free) memory detection feature will cause an
infinite calling of InitializePageTablePool(). This is due to a
fact that AllocateAlignedPages() is used to allocate page table
pool memory. This function will most likely call gBS->FreePages
to free unaligned pages and then cause
UAF (Use-After-Free) memory detection is new feature introduced to
detect illegal access to memory which has been freed. The principle
behind is similar to heap guard feature, that is the core turn all pool
memory allocation to page allocation and mark them to be not-present
once they are freed.
UAF (Use-After-Free) memory detection is new feature introduced to
detect illegal access to memory which has been freed. The principle
behind is similar to heap guard feature, that is we'll turn all pool
memory allocation to page allocation and mark them to be not-present
once they are freed.
Mike,
The code originate from Jiewen's work done years before. I think he validated
related implementation. In addition, I also used following ways to verify those
APIs:
a. Use debugger to verify the parameters passed in is as expected.
b. Disassemble the efi image to see if the calling
Hi Marvin Häuser,
Liming sent some mail to notice that we drop the support of BaseTools Python
run from the freeze binary in Windows OS, and he also sent patch to remove the
steps to freeze python tool. So I don't think we need this patch now, please
check it. Thanks.
Jian,
Please add the list of VSxxx tool chain tags you
tested with in the commit message.
Mike
> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, October 17, 2018 11:36 PM
> To: Kinney, Michael D ; Gao,
> Liming ; edk2-devel boun...@lists.01.org>; edk2-devel@lists.01.org
>
Got you. Thanks.
I will send out FDF spec update patch in recent days.
After that, you can get the latest draft revisions from
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Draft-Specification
Best Regards,
Zhu Yonghong
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Thursday,
Jian,
I do not see a description of the parameters, return
values or required behavior for those APIs in the header
files. How do you know if they are implemented correctly?
How would we write tests for these APIs?
Mike
> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday,
I would also hope that most (if not all) patches do have
an associated BZ. For either a feature request or a bug
fix.
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of stephano
> Sent: Thursday, October 18, 2018 10:21 AM
> To: Andrew
Hi All,
On 10/16/18 04:41, Star Zeng wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=415
>
> When SetVariable() to a time based auth variable with APPEND_WRITE
> attribute, and if the EFI_VARIABLE_AUTHENTICATION_2.TimeStamp in
> the input Data is earlier than current value, it will
Hi Eric,
On 10/18/18 09:34, Eric Dong wrote:
> V3 changes:
> 1. Use global variable instead of internal function to return string for
> register type
>and dependence type.
> 2. Add comments for some complicated logic.
>
> V1 changes:
> Because this driver needs to set MSRs saved in normal
On 10/18/2018 6:11 PM, Andrew Fish wrote:> What I've done in the past on
a branch based github PR flow is have a naming convention for the
branch. For example eng/PR--. Then we have a
git hook that looks at the branch name and if it sees a Bugzilla number
it inserts the Bugzilla reference in
> On Oct 18, 2018, at 9:43 AM, stephano wrote:
>
> On 10/18/2018 4:49 PM, Andrew Fish wrote:
>>> On Oct 18, 2018, at 7:22 AM, Carsey, Jaben wrote:
>>>
>>> I would like to know when a patch fixes a BZ. Subject/body I have less
>>> strong opinion about.
>>>
>> +1
>> Thanks,
>> Andrew Fish
>
Hi Eric,
On 10/18/18 09:34, Eric Dong wrote:
> AcpiCpuData add new fields, keep these fields if old data already existed.
>
> Cc: Ruiyu Ni
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> Reviewed-by: Ruiyu Ni
> ---
>
On 10/18/2018 4:49 PM, Andrew Fish wrote:
On Oct 18, 2018, at 7:22 AM, Carsey, Jaben wrote:
I would like to know when a patch fixes a BZ. Subject/body I have less strong
opinion about.
+1
Thanks,
Andrew Fish
This is always a point of contention with mailing list style
patch-workflows
On 10/18/18 09:34, Eric Dong wrote:
> v3 changes:
> 1. Move CPU_FEATURE_DEPENDENCE_TYPE definition here from
> RegisterCpuFeaturesLib.h file.
> 2. Add Invalid type for REGISTER_TYPE which will be used in code.
>
> v2 changes:
> 1. Add more description about why we do this change.
> 2. Change
On 10/18/18 15:43, Zeng, Star wrote:
> Hi Laszlo,
>
> On 2018/10/18 21:09, Laszlo Ersek wrote:
>> On a tangent:
>>
>> On 10/18/18 04:45, Zeng, Star wrote:
>>> On 2018/10/18 2:27, Laszlo Ersek wrote:
>>
>>
On 10/18/18 15:36, Gao, Liming wrote:
> Laszlo and Star:
> Thank your notes. I will add CVE number in patch subject although it
> will make subject long than 80 characters.
I agree the subject will be overlong, but I also think that including
the CVE numbers is important enough for that.
>
> On Oct 18, 2018, at 7:22 AM, Carsey, Jaben wrote:
>
> I would like to know when a patch fixes a BZ. Subject/body I have less strong
> opinion about.
>
+1
Thanks,
Andrew Fish
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>
Zhu Yonghong,
I was about to file one and then saw that one already exists:
https://bugzilla.tianocore.org/show_bug.cgi?id=551
This was created in May 2017. So I guess my original question still applies:
is there a plan (namely "when") for when this will get updated? :)
Thanks,
Eugene
Yes. Thanks for the comment. I will update it when push it.
Best Regards,
Zhu Yonghong
-Original Message-
From: Carsey, Jaben
Sent: Thursday, October 18, 2018 10:36 PM
To: Zhu, Yonghong ; edk2-devel@lists.01.org
Subject: RE: [edk2] [Patch] BaseTools: Fix one crash bug in the report for
Reviewed-by: Jaben Carsey
Note that you could change your first 2 lines (of the new content in both
places) to:
for Data in OverrideValues.values():
since you don't ever use the key later on...
-Jaben
> -Original Message-
> From: edk2-devel
The case is:
in the DSC file:
SKUID_IDENTIFIER = ALL
[SkuIds]
0|DEFAULT
1|A
[PcdsFixedAtBuild.common.A]
TokenSpaceGuid.Test401|{0x0F, 0x12}
TokenSpaceGuid.Test401.TEST401INT8ARRAY[0]|'B'
in the build report, Data = OverrideValues[Keys[0]], but the Keys[0]
is the keyword
I would like to know when a patch fixes a BZ. Subject/body I have less strong
opinion about.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> stephano
> Sent: Thursday, October 18, 2018 2:13 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2]
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Gao, Liming
> Sent: Wednesday, October 17, 2018 6:04 PM
> To: Zhu, Yonghong ; edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch] BaseTools: Fix a bug --pcd option
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> BobCF
> Sent: Wednesday, October 17, 2018 10:43 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [edk2] [Patch] BaseTools: Remove Arch specific build
Reviewed-by: Jaben Carsey
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Zhaozh1x
> Sent: Wednesday, October 17, 2018 10:09 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [edk2] [PATCH V2] BaseTools: Convert "Unicode
Hi Laszlo,
On 2018/10/18 21:09, Laszlo Ersek wrote:
On a tangent:
On 10/18/18 04:45, Zeng, Star wrote:
On 2018/10/18 2:27, Laszlo Ersek wrote:
e62f7104-e341-6c7f-1af5-2130f161f111@redhat.com">http://mid.mail-archive.com/e62f7104-e341-6c7f-1af5-2130f161f111@redhat.com
Sorry, I could not
Laszlo and Star:
Thank your notes. I will add CVE number in patch subject although it will
make subject long than 80 characters. Here is my proposed patch subject:
CVE-2017-5731..5735 MdePkg: Add more checker in UefiDecompressLib to access the
valid buffer only.
In PEI phase, the recovery
On a tangent:
On 10/18/18 04:45, Zeng, Star wrote:
> On 2018/10/18 2:27, Laszlo Ersek wrote:
e62f7104-e341-6c7f-1af5-2130f161f111@redhat.com">http://mid.mail-archive.com/e62f7104-e341-6c7f-1af5-2130f161f111@redhat.com
>>> Sorry, I could not access it.
>>
>> I'm unsure if you mean that you
On 10/18/18 05:04, Zeng, Star wrote:
> On 2018/10/16 10:06, Liming Gao wrote:
>> https://bugzilla.tianocore.org/show_bug.cgi?id=686
>>
>> Liming Gao (3):
>> MdePkg: Add more checker in UefiDecompressLib to access the valid
>> buffer only
>> IntelFrameworkModulePkg: Add more checker in
Reviewed-by: Yonghong Zhu
Best Regards,
Zhu Yonghong
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming
Gao
Sent: Tuesday, October 16, 2018 10:06 AM
To: edk2-devel@lists.01.org
Cc: Holtsclaw, Brent
Subject: [edk2] [Patch 3/3] BaseTools:
On Thu, 18 Oct 2018 at 14:54, Leif Lindholm wrote:
>
> On Thu, Oct 18, 2018 at 02:43:37PM +0530, Sumit Garg wrote:
> > On Thu, 18 Oct 2018 at 14:04, Leif Lindholm
> > wrote:
> > >
> > > On Thu, Oct 18, 2018 at 12:59:32PM +0530, Sumit Garg wrote:
> > > > > So, looking at the OpTee sources,
On Thu, Oct 18, 2018 at 02:43:37PM +0530, Sumit Garg wrote:
> On Thu, 18 Oct 2018 at 14:04, Leif Lindholm wrote:
> >
> > On Thu, Oct 18, 2018 at 12:59:32PM +0530, Sumit Garg wrote:
> > > > So, looking at the OpTee sources, TEE_UUID is defined as a struct, to
> > > > exactly the same layout as the
On Thu, 18 Oct 2018 at 14:04, Leif Lindholm wrote:
>
> On Thu, Oct 18, 2018 at 12:59:32PM +0530, Sumit Garg wrote:
> > > So, looking at the OpTee sources, TEE_UUID is defined as a struct, to
> > > exactly the same layout as the EFI_GUID type (which is a typedef of
> > > the GUID struct). Could we
This discussion was tabled as it will probably be its own meeting rather
than part of our general discussions this month.
Recently on the list Laszlo and Star agreed that we should be adding the
CVE to the subject of any patch that fixes a CVE. I will be documenting
this in the wiki as well
Andrew got this conversation started on the meeting minutes email. I
wanted to be sure it didn't get lost in the daily noise of the list.
I'll be pulling out some other discussions as well to give folks a
chance to comment before our next Community Meeting (happening next
week, invite coming
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1251
*v2: Correct the type of parameters in Ikev2ParseProposalData(), and refined
the corresponding description.
IpSecDxe failed to create the Child SA during parsing SA Payload, the issue
was caused by the below commit:
SHA-1:
> -Original Message-
> From: Yao, Jiewen
> Sent: Thursday, October 18, 2018 11:00 AM
> To: Zhang, Shenglei ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen
> Subject: RE: [edk2] [PATCH v2] Edk2Platforms: Replace FatBinPkg with FatPkg
>
> Hi
> Would you please share what test has been done?
On Thu, Oct 18, 2018 at 12:59:32PM +0530, Sumit Garg wrote:
> > So, looking at the OpTee sources, TEE_UUID is defined as a struct, to
> > exactly the same layout as the EFI_GUID type (which is a typedef of
> > the GUID struct). Could we add a OPTEE_UUID typedef for the same
> > struct in
On 10/18/2018 3:34 PM, Eric Dong wrote:
V3 changes:
1. Use global variable instead of internal function to return string for
register type
and dependence type.
2. Add comments for some complicated logic.
V1 changes:
Because this driver needs to set MSRs saved in normal boot phase, sync
On 10/18/2018 3:34 PM, Eric Dong wrote:
V3 changes include:
1. Use global variable instead of internal function to return string for
register type
and dependence type.
2. Add comments for some complicated logic.
V2 changes include:
1. Add more description for the code part which need easy
On 10/18/2018 3:34 PM, Eric Dong wrote:
v3 changes:
1. Move CPU_FEATURE_DEPENDENCE_TYPE definition to AcpiCpuData.h.
2. Add comments for CPU_FEATURE_BEFORE/CPU_FEATURE_AFTER.
v1 changes:
Add new core/package dependence types which consumed by different MSRs.
Cc: Ruiyu Ni
Cc: Laszlo
On 10/18/2018 3:34 PM, Eric Dong wrote:
v3 changes:
1. Move CPU_FEATURE_DEPENDENCE_TYPE definition here from
RegisterCpuFeaturesLib.h file.
2. Add Invalid type for REGISTER_TYPE which will be used in code.
v2 changes:
1. Add more description about why we do this change.
2. Change structure
Hi Laszlo,
Thanks for your notes. I have updated V2 changes based on Ray's comments.
Please help to check the V3 changes.
Thanks,
Eric
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, October 18, 2018 1:34 AM
> To: Dong, Eric
> Cc: Ni, Ruiyu ;
AcpiCpuData add new fields, keep these fields if old data already existed.
Cc: Ruiyu Ni
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
Reviewed-by: Ruiyu Ni
---
UefiCpuPkg/CpuS3DataDxe/CpuS3Data.c | 2 ++
1 file changed, 2 insertions(+)
V3 changes:
1. Use global variable instead of internal function to return string for
register type
and dependence type.
2. Add comments for some complicated logic.
V1 changes:
Because this driver needs to set MSRs saved in normal boot phase, sync
semaphore logic from RegisterCpuFeaturesLib
Because MSR has scope attribute, driver has no needs to set
MSR for all APs if MSR scope is core or package type. This patch
updates code to base on the MSR scope value to add MSR to the register
table.
Cc: Ruiyu Ni
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
v3 changes:
1. Move CPU_FEATURE_DEPENDENCE_TYPE definition to AcpiCpuData.h.
2. Add comments for CPU_FEATURE_BEFORE/CPU_FEATURE_AFTER.
v1 changes:
Add new core/package dependence types which consumed by different MSRs.
Cc: Ruiyu Ni
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution
V3 changes include:
1. Use global variable instead of internal function to return string for
register type
and dependence type.
2. Add comments for some complicated logic.
V2 changes include:
1. Add more description for the code part which need easy to understand.
2. Refine some code base on
v3 changes:
1. Move CPU_FEATURE_DEPENDENCE_TYPE definition here from
RegisterCpuFeaturesLib.h file.
2. Add Invalid type for REGISTER_TYPE which will be used in code.
v2 changes:
1. Add more description about why we do this change.
2. Change structure field type from pointer to
V3 changes include:
1. Add comments for some complicate logic.
2. Use global variable instead of internal function to return string for
register type
and dependence type.
3. Verify the solution with internal server platform(2 socket/56 Core/112
thread), set
MSRs costs time change from
Hi Leif,
On Thu, 18 Oct 2018 at 11:53, Leif Lindholm wrote:
>
> Hi Sumit,
>
> I have some further comments/suggestions on UUID/GUID handling below.
>
> On Wed, Oct 10, 2018 at 10:48:53AM +0530, Sumit Garg wrote:
> > Add following APIs to communicate with OP-TEE pseudo/early TAs:
> > 1. OpteeInit
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Chiu, Chasel
> Sent: Thursday, October 18, 2018 2:52 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Desimone, Nathaniel L
> ; Chiu, Chasel
> Subject: [PATCH v3] IntelFsp2Pkg: Support FSP Dispatch mode
>
> REF:
V2:
Make the code of patch both compatible for Python2 and Python3.
V1:
If different PCDs refer to the same EFI variable, then do EFI variable
combination, according to the VariableOffset of different PCDS.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: ZhiqiangX Zhao
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1241
Add support for both API (original mode) and DISPATCH mode:
1. Add FspMode field from reserved byte of Global
Data Structure to tell which mode is selected by boot
loader. If boot loader invoking FSP-M API this field
will remain as
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1259
According to the the NVM Express spec Revision 1.1, for some commands,
command-related information will be stored in the Dword 0 of the
completion queue entry.
One case is for the Get Features Command (Section 5.9.2 of the spec),
Dword 0 of
The series will address a couple of bugs within the NvmExpressPassThru()
function. Please refer to the log messages of each commit for more
details.
Cc: Liangcheng Tang
Cc: Jiewen Yao
Cc: Ruiyu Ni
Cc: Star Zeng
Hao Wu (3):
MdeModulePkg/NvmExpressDxe: Refine data buffer & len check in
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1260
For the PassThru() service of NVM Express Pass Through Protocol, the
current implementation (function NvmExpressPassThru()) will only use the
IO Completion/Submission queues created internally by this driver during
the controller
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1142
According to the the NVM Express spec Revision 1.1, for some commands
(like Get/Set Feature Command, Figure 89 & 90 of the spec), the Memory
Buffer maybe optional although the command opcode indicates there is a
data transfer between host &
Mike,
I tested the lib with all supported MSFT toolchains. No difference found so far.
Regards,
Jian
> -Original Message-
> From: Kinney, Michael D
> Sent: Thursday, October 18, 2018 9:36 AM
> To: Gao, Liming ; Wang, Jian J ;
> edk2-devel ; edk2-devel@lists.01.org;
> Kinney, Michael D
On Thu, Oct 18, 2018 at 02:09:33PM +0800, Ard Biesheuvel wrote:
> Enable support for HTTPS boot by incorporating the TLS DXE driver into
> the build, and the driver that permits enrolling the TLS certificates.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard
Hi Sumit,
I have some further comments/suggestions on UUID/GUID handling below.
On Wed, Oct 10, 2018 at 10:48:53AM +0530, Sumit Garg wrote:
> Add following APIs to communicate with OP-TEE pseudo/early TAs:
> 1. OpteeInit
> 2. OpteeOpenSession
> 3. OpteeCloseSession
> 4. OpteeInvokeFunc
>
> Cc:
Enable support for HTTPS boot by incorporating the TLS DXE driver into
the build, and the driver that permits enrolling the TLS certificates.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 5 -
On 10/17/2018 10:16 AM, Eric Dong wrote:
Because MSR has scope attribute, driver has no needs to set
MSR for all APs if MSR scope is core or package type. This patch
updates code to base on the MSR scope value to add MSR to the register
table.
Cc: Ruiyu Ni
Cc: Laszlo Ersek
Contributed-under:
88 matches
Mail list logo
