On 02/28/20 19:58, Leo Duran wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2556
>
> This patch uses CPUID signature check to skip reading the PlatformId MSR,
> which is not implemented on AMD processors.
>
> The PlatformId is used for loading microcode patches, which is also not
>
> -Original Message-
> From: Ni, Ray [mailto:ray...@intel.com]
> Sent: Friday, February 28, 2020 1:47 AM
> To: Duran, Leo ; Laszlo Ersek ;
> devel@edk2.groups.io; Wu, Hao A ; Fu, Siyuan
>
> Cc: Dong, Eric
> Subject: RE: [edk2-devel] [PATCH 0/2] UefiCpuPkg/Library: Fix bug in
>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2556
This patch uses CPUID signature check to skip reading the PlatformId MSR,
which is not implemented on AMD processors.
The PlatformId is used for loading microcode patches, which is also not
supported and AMD-based platforms. To mitigate
This patch fixes an issue introduced recently in MpInitLib, where we read
a PlatformId MSR that is not implemented on AMD processors. The patch uses
CPUID signature check to skip reading the PlatformId MSR.
Changes since v2:
Fix typo (PCD name) on commit log.
Leo Duran (1):
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2556
This patch uses CPUID signature check to skip reading the PlatformId MSR,
which is not implemented on AMD processors.
The PlatformId is used for loading microcode patches, which is also not
supported and AMD-based platforms. To mitigate
Hi Laszlo,
> -Original Message-
> From: Qemu-devel
> [mailto:qemu-devel-bounces+jianjay.zhou=huawei@nongnu.org] On Behalf
> Of Laszlo Ersek
> Sent: Wednesday, February 26, 2020 5:42 PM
> To: Andrew Fish ; devel@edk2.groups.io
> Cc: berra...@redhat.com; qemu-de...@nongnu.org; Dr. David
> -Original Message-
> From: Ni, Ray [mailto:ray...@intel.com]
> Sent: Thursday, February 27, 2020 12:55 AM
> To: Duran, Leo ; Laszlo Ersek ;
> devel@edk2.groups.io; Wu, Hao A ; Fu, Siyuan
>
> Cc: Dong, Eric
> Subject: RE: [edk2-devel] [PATCH 0/2] UefiCpuPkg/Library: Fix bug in
>
This patch fixes an issue introduced recently in MpInitLib, where we read
a PlatformId MSR that is not implemented on AMD processors. The patch uses
CPUID signature check to skip reading the PlatformId MSR.
Changes since v1:
- Undo changes to LocalApicLib to not export CPUID signature check.
-
I have successfully tested this on a machine with TPM 1.2, using passthrough
mode to enable Bitlocker on the Windows 10 guest.
-Original Message-
From: marcandre.lur...@redhat.com [mailto:marcandre.lur...@redhat.com]
Sent: 26 February 2020 15:24
To: devel@edk2.groups.io
Cc:
On 02/28/20 16:44, Simon Hardy wrote:
> I have successfully tested this on a machine with TPM 1.2, using passthrough
> mode to enable Bitlocker on the Windows 10 guest.
Thank you, Simon!
Can I take it as:
Tested-by: Simon Hardy
for the whole series?
Thanks!
Laszlo
>
> -Original
BZ:2562 - EDK CI for RISC-V architecture
Add RISC-V architecture on RISC-V EDK2 CI.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by: Abner Chang
---
BZ:2562 - EDK CI for RISC-V architecture
Add RISC-V architecture on RISC-V EDK2 CI testing.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by: Abner Chang
---
BZ:2562 - EDK CI for RISC-V architecture
Enable RISC-V architecture for RISC-V EDK2 CI testing.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Bob Feng
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by:
BZ:2562 - EDK CI for RISC-V architecture
Revise yaml file for EDK2 CI testing on RISC-V architecture.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by: Abner Chang
BZ:2562 - EDK CI for RISC-V architecture
Add yaml file for EDK2 CI testing on RiscVPlatformPkg.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by: Abner Chang
---
BZ:2562 - EDK CI for RISC-V architecture.
This set of patches enale RISC-V architecture on EDK2 CI test process.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Abner Chang
BZ:2562 - EDK CI for RISC-V architecture
Add yaml file for EDK2 CI testing on RiscVPkg.
Signed-off-by: Abner Chang
Cc: Bret Barkelew
Cc: Sean Brogan
Cc: Leif Lindholm
Cc: Gilbert Chen
Cc: Daniel Helmut Schaefer
Signed-off-by: Abner Chang
---
RiscVPkg/RiscVPkg.ci.yaml | 80
On Fri, Feb 28, 2020 at 04:13:09 +, Gao, Liming wrote:
> > > I agree it needs to catch the stable tag. If it affects only VS builds
> > > then I am not going to insist on extending the hard freeze, but I
> > > (technically on holiday today/tomorrow) don't have time to dig much
> > > deeper
Liming,
I assume that CVE-2019-14559 relates to problems with network drivers
within NetworkPkg.
BZ 2032 and this patch fix address incorrect usage of IP4 protocol by
ShellPkg 'ping' command (signalling packet recycling after triggering
Ip4->Receive() on the same Rx token).
This issue was
Ard:
I think this change is OK. Ack-by: Liming Gao
Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Ard Biesheuvel
> Sent: Friday, February 28, 2020 1:11 AM
> To: edk2-devel-groups-io ; Wu, Hao A
> ; Wang, Jian J ; Gao,
> Zhichao ; Ni, Ray
> Cc: Laszlo
On 02/28/20 12:47, Laszlo Ersek wrote:
> On 02/28/20 05:04, Andrew Fish wrote:
>> Given the above it seems like the 2 options are:
>> 1) Pad OVMF_CODE.fd to be very large so there is room to grow.
>
> There's already room to grow, *inside* OVMF_CODE.fd. As I've shown
> elsewhere in this thread,
Maciej:
I see you submit the patch. So, you are in the loop. I don't invite you
again.
Yes. I also want to get your opinion for this change. Do you think whether
this fix is in CVE scope? If no, this change will be merged after this stable
tag 202002. Is it OK to you?
Thanks
Liming
>
On 02/28/20 05:04, Andrew Fish wrote:
> Maybe I was overcomplicating this. Given your explanation I think the part
> I'm missing is OVMF is implying FLASH layout, in this split model, based on
> the size of the OVMF_CODE.fd and OVMF_VARS.fd. Given that if OVMF_CODE.fd
> gets bigger the
Laszlo,
Thanks for the detailed response on the patch. Always happy to learn
about stuff from the past.
Liming,
I am currently the maintainer of NetworkPkg :) If you require additional
feedback from Siyuan or/and Jiaxin, that's ok.
Please let me know if any corrections to the patch (like
On 02/28/20 04:20, Zhoujian (jay) wrote:
> Hi Laszlo,
>
>> -Original Message-
>> From: Qemu-devel
>> [mailto:qemu-devel-bounces+jianjay.zhou=huawei@nongnu.org] On Behalf
>> Of Laszlo Ersek
>> Sent: Wednesday, February 26, 2020 5:42 PM
>> To: Andrew Fish ; devel@edk2.groups.io
>> Cc:
On 2020.02.28 10:58, Ard Biesheuvel wrote:
On Fri, 28 Feb 2020 at 11:51, Pete Batard wrote:
Hi Ard,
On 2020.02.28 10:45, Ard Biesheuvel wrote:
On Fri, 28 Feb 2020 at 11:39, Pete Batard wrote:
Remove unneeded extra parenthesis on PCD, which can cause problems
when used with ACPI ASL
On Fri, 28 Feb 2020 at 11:51, Pete Batard wrote:
>
> Hi Ard,
>
> On 2020.02.28 10:45, Ard Biesheuvel wrote:
> > On Fri, 28 Feb 2020 at 11:39, Pete Batard wrote:
> >>
> >> Remove unneeded extra parenthesis on PCD, which can cause problems
> >> when used with ACPI ASL macros and add an [Includes]
Hi Ard,
On 2020.02.28 10:45, Ard Biesheuvel wrote:
On Fri, 28 Feb 2020 at 11:39, Pete Batard wrote:
Remove unneeded extra parenthesis on PCD, which can cause problems
when used with ACPI ASL macros and add an [Includes] section to the
.inf, so that the Genet.h header can be referenced where
On 02/28/20 04:05, Dong, Eric wrote:
> Hi Laszlo,
>
> Thanks for your patch. The change make sense base on the comments in the data
> structure header file.
>
> I also checked all the code related to this data structure. The inputs for
> this data structure are CpuS3DataDxe and
On Fri, 28 Feb 2020 at 11:39, Pete Batard wrote:
>
> Remove unneeded extra parenthesis on PCD, which can cause problems
> when used with ACPI ASL macros and add an [Includes] section to the
> .inf, so that the Genet.h header can be referenced where required.
>
> Signed-off-by: Pete Batard
> ---
The ACPI interrupts are not the same across different Raspberry Pi
platforms therefore moving them into AcpiTables.h will help with ACPI
code factorization.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/AcpiTables/AcpiTables.h | 26 +++
With the ACPI source for the Pi 3 and Pi 4 being identical, we can
finally factorize it.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/{RPi3 => }/AcpiTables/AcpiTables.h | 0
Platform/RaspberryPi/{RPi3 => }/AcpiTables/AcpiTables.inf | 0
Platform/RaspberryPi/{RPi3 =>
The FADT and GTDT tables are virtually identical to the ones we use for
the Pi 4, except for the RPI_SYSTEM_TIMER_BASE_ADDRESS in Gtdt.aslc.
However, 2 changes are required for these tables to work with Windows:
1. The ACPI OEM ID for the FADT table MUST be "BC2836" (else Windows 10
fails to
Since there are multiple Raspberry Pi Models and a lot of the code we use
can be factorized, it is useful to have an RPI_MODEL build time constant,
set to the platform model number, that can be referenced in the source.
Make use this new constant to replace the PL011_ENABLE feature check.
This basically copies all of the RPi4 platform ACPI source into RPi3
since the last commit updates the code to serve both platforms.
No alteration of original ACPI source files were applied.
Whereas this commit is pretty much superfluous (apart from the .dsc
changes), since these files will be
* Update the OEM IDs and base revision numbers.
* Move RPI_SYSTEM_TIMER_BASE_ADDRESS to AcpiTables.h.
* Add RPi3 constants and conditional blocks according to model.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h | 48 +---
The ACPI interrupts are not the same across different Raspberry Pi
platforms therefore moving them into AcpiTables.h will help with ACPI
code factorization.
We also take this opportunity to move the serial interrupt definitions
away from Silicon, since the ones defined in Bcm2836.h only applied
Apart from the serial interrupt constants, the SPCR and DBG2 .aslc
we use for the Pi 4 platform can be applied as is for the Pi 3.
As a result, we replace the existing binary blobs with formal ASLC.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/RPi3/AcpiTables/AcpiTables.inf | 3 +-
With the new constants added, remove some of the hardcoded values from
the ACPI tables.
Note that because the ASL compiler is very limited in terms of macro
processing, we can not use any arithmetic constants (e.g BASE + OFFSET)
as parameters to MEMORY32FIXED (), and instead must alter the base
With the new constants added, remove some of the hardcoded values from
the ACPI tables.
Note that because the ASL compiler is very limited in terms of macro
processing, we can not use any arithmetic constants (e.g BASE + OFFSET)
as parameters to MEMORY32FIXED (), and instead must alter the base
In order to be able to reference them in ACPI tables and elsewhere
we add some missing constants to be the Bcm283x headers.
These include:
* I2C, SPI and DMA constants
* Length of the peripherals register space
We also take this opportunity to clean up and harmonize the headers.
Signed-off-by:
Most of the ACPI sources being used for the Raspberry Pi 4 are
actually very similar to the Raspberty Pi 3 ones, barring a few
constant changes (base addresses, interrupts) or leftover binary
blobs that could be converted to formal ASLC.
As a result, with the goal of simplifying maintenance as
Remove unneeded extra parenthesis on PCD, which can cause problems
when used with ACPI ASL macros and add an [Includes] section to the
.inf, so that the Genet.h header can be referenced where required.
Signed-off-by: Pete Batard
---
Silicon/Broadcom/Drivers/Net/BcmGenetDxe/Genet.h | 3 ++-
Whereas these devices are not explicitly described in the BCM2835
ARM Peripheral guide, they come as standard with the SoC and their
constants can easily be found in the Device Trees for Bcm283x based
devices.
Create 2 new Silicon headers to host these constants.
Signed-off-by: Pete Batard
---
The official BCM2835 ARM Peripherals guide lists the DW USB
controller as standard SoC device.
Treat is as such by adding its base address to Silicon.
Signed-off-by: Pete Batard
---
Platform/RaspberryPi/Drivers/DwUsbHostDxe/DwUsbHostDxe.c| 3 ++-
On 02/28/20 10:50, Laszlo Ersek wrote:
> In particular, in patch "OvmfPkg/MptScsiDxe: Install stubbed
> EXT_SCSI_PASS_THRU", the pattern should be laid out like this:
>
> ---
> Status = gBS->InstallProtocolInterface (...);
> if (EFI_ERROR (Status)) {
> goto FreeDev;
> }
>
On 02/26/20 17:41, Nikita Leshenko wrote:
> This will give us an exclusive access to the PciIo of this device
> after it was started and until is will be stopped.
(1) s/is/it/
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Contributed-under: TianoCore Contribution Agreement 1.1
On 2/27/20 10:39 PM, Laszlo Ersek wrote:
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1659
Repo: https://github.com/lersek/edk2.git
Branch: crlf_bz_1659
Future patches for some Arm*Pkg source files would either introduce CRLF
lines into LF files, or add more LF lines. The
On 02/26/20 17:41, Nikita Leshenko wrote:
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Nikita Leshenko
> Reviewed-by: Konrad Rzeszutek Wilk
> Reviewed-by: Aaron Young
> Reviewed-by: Liran Alon
(1) Please
On 02/26/20 17:41, Nikita Leshenko wrote:
> Used to identify the individual disks in the hardware tree
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Nikita Leshenko
> Reviewed-by: Konrad Rzeszutek Wilk
>
On 02/26/20 17:41, Nikita Leshenko wrote:
> Support for multiple targets will be implemented in a later commit in
> this series.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Nikita Leshenko
> Reviewed-by:
On 02/26/20 17:41, Nikita Leshenko wrote:
> Support dynamic insertion and removal of the protocol
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Nikita Leshenko
> Reviewed-by: Konrad Rzeszutek Wilk
>
On 02/26/20 17:41, Nikita Leshenko wrote:
> The MptScsiControllerSupported function is called on handles passed in
> by the ConnectController() boot service and if the handle is the
> lsi53c1030 controller the function would return success. A successful
> return value will attach our driver to the
Hi, all
Yesterday, one critical issue was reported. Its fix required more time to be
reviewed and verified. Here is the discussion
https://edk2.groups.io/g/devel/message/55047. So, two stewards suggested to
extend Hard Feature Freeze by a few days. Now, we are still in Hard Feature
Freeze
On 02/26/20 17:41, Nikita Leshenko wrote:
> Install Component Name protocols to have a nice display name for the
> driver in places such as UEFI shell.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Nikita
On 02/26/20 17:41, Nikita Leshenko wrote:
> In order to probe and connect to the MptScsi device we need this
> protocol. Currently it does nothing.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Nikita
On 02/26/20 17:41, Nikita Leshenko wrote:
> In preparation for implementing LSI Fusion MPT SCSI devices, create a
> basic scaffolding for a driver.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Nikita
On 02/28/20 08:51, Laszlo Ersek wrote:
> On 02/26/20 17:41, Nikita Leshenko wrote:
>> This series adds driver support for:
>> - LSI53C1030
>> - SAS1068
>> - SAS1068E
>>
>> These controllers are widely supported by QEMU, VirtualBox and VMWare. This
>> work
>> is part of the more general agenda of
58 matches
Mail list logo
