On 5/28/21 12:42 PM, Heinrich Schuchardt wrote:
Am 27. Mai 2021 16:41:13 MESZ schrieb Sunil V L :
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3096
This patch adds support for R_RISCV_CALL_PLT and R_RISCV_GOT_HI20
relocations.
gnu-efi tries to avoid GOT based relocations on ARM using
Am 27. Mai 2021 16:41:13 MESZ schrieb Sunil V L :
>Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3096
>
>This patch adds support for R_RISCV_CALL_PLT and R_RISCV_GOT_HI20
>relocations.
>
gnu-efi tries to avoid GOT based relocations on ARM using
#if defined(__GNUC__) && !__STDC_HOSTED__
Acked-by: Abner Chang
> -Original Message-
> From: Schaefer, Daniel
> Sent: Friday, May 28, 2021 11:24 AM
> To: Sunil V L ; devel@edk2.groups.io
> Cc: sunil...@gmail.com; Chang, Abner (HPS SW/FW Technologist)
> ; Heinrich Schuchardt ; Bob
> Feng ; Liming Gao ;
> Yuwei Chen
> Subject:
+Maintainers and Reviewers of BaseTools
See my reply below.
On 5/27/21 10:41 PM, Sunil V L wrote:
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3096
This patch adds support for R_RISCV_CALL_PLT and R_RISCV_GOT_HI20
relocations.
Signed-off-by: Sunil V L
Cc: Abner Chang
Cc: Daniel
Reviewed-by: Liming Gao
> -邮件原件-
> 发件人: Chen, Christine
> 发送时间: 2021年5月27日 13:57
> 收件人: Feng, Bob C ; devel@edk2.groups.io
> 抄送: Liming Gao
> 主题: RE: [Patch] [edk2-staging] BaseTools: Add checkpoint for that there
is
> no fv ext_header
>
> Reviewed-by: Yuwei Chen
>
> >
Zhiguang:
MdePkg definitions are from Industry Standards.
Universalpayload definitions are from its documentation 0.75 version. I don't
think it belongs to the formal industry standards. Can you provide more
information to show Universalpayload is the public industry standard?
Ray:
I would like to suggest CLANGDWARF also generate EFI image. If so, the
people can use this tool chain for EFI development with DWARF format debug
symbol.
In dll generation phase, CLANGDWARF still generates dll image, then copy
dll image to elf image. In EFI generation phase, dll image
You may be right, I've seen that the EFI_DEVICE_ERROR comes from
UsbIoControlTransfer() where there is a conflict between the data length
requested vs. received.
Thanks,
Jack
From: Desimone, Nathaniel L
Sent: Thursday, May 27, 2021 11:06 AM
To: Little, Jack ; devel@edk2.groups.io
Cc:
Hi Nate,
The same FTDI device works with the source from around 05/23/2018, unsure of
which chip is in there.
Thanks,
Jack
From: Desimone, Nathaniel L
Sent: Thursday, May 27, 2021 3:17 AM
To: devel@edk2.groups.io; Little, Jack
Cc: Desimone, Ashley E
Subject: RE: FtdiUsbSerialDxe
Hi Jack,
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3096
This patch adds support for R_RISCV_CALL_PLT and R_RISCV_GOT_HI20
relocations.
Signed-off-by: Sunil V L
Cc: Abner Chang
Cc: Daniel Schaefer
Cc: Heinrich Schuchardt
---
BaseTools/Source/C/GenFw/Elf64Convert.c | 45
*TianoCore Design Meeting - APAC/NAMO*
*When:*
05/28/2021
9:30am to 10:30am
(UTC+08:00) Asia/Shanghai
*Where:*
Microsoft Teams
*Organizer:* Ray Ni ray...@intel.com (
ray...@intel.com?subject=Re:%20Event:%20TianoCore%20Design%20Meeting%20-%20APAC%2FNAMO
)
View Event (
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:PUBLISH
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Asia/Shanghai
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Shanghai
X-LIC-LOCATION:Asia/Shanghai
BEGIN:STANDARD
TZNAME:CST
I’m fielding a series of questions coming out of our compatriot team that deals
with virtual FW (for HyperV). They’re seeing ARM64 systems that have lots of
RAM vastly exceeding the TempRam that’s passed into the system due to HOB
allocations to create all the 4k entries for the early page
On 05/27/21 15:07, Leif Lindholm wrote:
> On Wed, May 26, 2021 at 22:14:03 +0200, Laszlo Ersek wrote:
>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
>> Repo: https://pagure.io/lersek/edk2.git
>> Branch: xen_split_bz_2122
>>
>> This patch set removes dynamic Xen
Hi Jack,
To my knowledge, the code hasn't been touched at all since 2013 other than
being moved from edk2 to edk2-platforms. The move from edk2 to edk2-platforms
did happen in 2019, so perhaps something broke during that move but it seems
unlikely. The only other explanation I can think of for
Got it. Thanks!
Liming
发件人: Sami Mujawar
发送时间: 2021年5月27日 18:13
收件人: devel@edk2.groups.io; Laszlo Ersek ; gaoliming
抄送: a...@kernel.org; l...@nuviainc.com; Matteo Carlini
; Andreas Sandberg ; Joey
Gouly ; nd ; phi...@redhat.com
主题: Re: 回复: [edk2-devel] [edk2-devel202105 PATCH v2 1/1]
Hi Nate,
I am out of office most of this week and I will look into that next week.
Would you consider that a requirement to extend onto this patch series?
Or could it be a follow up series? Asking due to to the length of this
series.
Thanks,
Michael
On 5/26/2021 4:57 PM, Desimone,
On Thu, May 27, 2021 at 2:07 PM Leif Lindholm wrote:
>
> On Wed, May 26, 2021 at 22:14:03 +0200, Laszlo Ersek wrote:
> > Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
> > Repo: https://pagure.io/lersek/edk2.git
> > Branch: xen_split_bz_2122
> >
> > This patch set removes
On Wed, May 26, 2021 at 22:14:03 +0200, Laszlo Ersek wrote:
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
> Repo: https://pagure.io/lersek/edk2.git
> Branch: xen_split_bz_2122
>
> This patch set removes dynamic Xen enlightenment from the following
> platforms:
>
>
Hi Nhi,
Many thanks for this. Just as a warning - Monday is a bank holiday in the UK,
and I have a personal holiday tomorrow. So I'm unlikely to get to it until
Tuesday. It is kind of big :)
Best Regards,
Leif
On Wed, May 26, 2021 at 17:06:51 +0700, Nhi Pham wrote:
> This patch series adds the
Steven,
Thanks for the comments. Yes, it's a general toolchain that can generate ELF
executable.
I also received your comments to 1/4.
I will post V2 of 1/4 as a separate patch with your comments addressed.
Thanks,
Ray
> -Original Message-
> From: Shi, Steven
> Sent: Wednesday, May 26,
Hi Ling,
Many apologies for delay. I have been juggling too many things and making
little progress on any of them. I owe you some of the good 白酒 when we
meet in person.
I have now looked over all of v3, and have some feedback, but most of it is
minor.
First of all, some process comments:
I
Main Changes :
Check data length first, if data length equals to 0, then set TRT to 0.
Wenyi Xie (1):
MdeModulePkg/Xhci: Fix TRT when data length is 0
MdeModulePkg/Bus/Pci/XhciDxe/XhciSched.c | 13 +
MdeModulePkg/Bus/Pci/XhciPei/XhciSched.c | 13 +
2 files changed, 18
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3418
According to xhci spec, at USB packet level, a Control Transfer
consists of multiple transactions partitioned into stages: a
setup stage, an optional data stage, and a terminating status
stage. If Data Stage does not exist, the Transfer
Reviewed-by: Jiewen Yao
Hi Scottie
Please remember to add Wang, Jian J as reviewer too.
Thank you
Yao Jiewen
> -Original Message-
> From: Kuo, Scottie
> Sent: Monday, May 24, 2021 2:41 PM
> To: devel@edk2.groups.io
> Cc: Kuo, Scottie ; Zhang, Qi1 ;
> Kumar, Rahul1 ; Yao, Jiewen
> ;
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The "OvmfPkg/Library/PciHostBridgeLibScan/PciHostBridgeLibScan.inf"
> instance is used in the following platforms in edk2:
>
> OvmfPkg/Bhyve/BhyveX64.dsc
> OvmfPkg/OvmfXen.dsc
>
> Both platforms define "PcdPciDisableBusEnumeration" with
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The entry point function of "OvmfPkg/IncompatiblePciDeviceSupportDxe",
> namely DriverInitialize()
> [OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c],
> bails out immediately if "PcdPciDisableBusEnumeration" is TRUE.
>
> The Bhyve
Hi Ard, Jordan,
On 05/27/21 12:14, Laszlo Ersek wrote:
> On 05/27/21 12:12, Laszlo Ersek wrote:
>> On 05/26/21 19:08, Devon Bautista wrote:
>>> Currently, the largest volume size for building OVMF images is 4MB. With
>>> the growth of the Linuxboot project, maintainers have had to maintain a
>>>
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> With the Xen-dependent PcdSetBoolS() call removed from
> OvmfPkg/PlatformPei, the "AmdSevX64.dsc" platform never writes
> "PcdPciDisableBusEnumeration". This means we don't need a dynamic default
> for the PCD in the DSC file; it could be declared
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The "OvmfPkg/PlatformPei/PlatformPei.inf" module is used by the following
> platform DSCs:
>
> OvmfPkg/AmdSev/AmdSevX64.dsc
> OvmfPkg/OvmfPkgIa32.dsc
> OvmfPkg/OvmfPkgIa32X64.dsc
> OvmfPkg/OvmfPkgX64.dsc
>
> Remove Xen support from
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The "OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf" module is no longer
> referenced in any platform DSC file; remove it.
>
> That orphans the "AcpiPlatform.c", "Qemu.c" and "Xen.c" files in the
> "OvmfPkg/AcpiPlatformDxe/" directory; remove them.
>
>
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Create an almost verbatim copy of the
> "OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf" driver for the OvmfXen
> platform. We're going to trim the driver in subsequent patches.
> Ultimately, the XenAcpiPlatformDxe driver will duplicate a negligible
> amount
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> For consistency with the historical OvmfPkg* platforms, switch the
> remotely attested, QEMU/KVM-only, AmdSev platform from the AcpiPlatformDxe
> driver to the QemuFwCfgAcpiPlatformDxe driver.
>
> No module remains dependent on XenPlatformLib, so remove
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Switch the historical OvmfPkg* platforms from the AcpiPlatformDxe driver
> to the QemuFwCfgAcpiPlatformDxe driver. (The latter is used by the
> ArmVirtQemu* platforms as well.)
>
> The change effectively replaces the following call tree:
>
>
On 05/27/21 12:12, Laszlo Ersek wrote:
> On 05/26/21 19:08, Devon Bautista wrote:
>> Currently, the largest volume size for building OVMF images is 4MB. With
>> the growth of the Linuxboot project, maintainers have had to maintain a
>> fork containing this patch which allows larger image sizes in
Hi All,
I have pushed this change to edk2 master at cfa6ffb113f2..e1999b264f1f
Regards,
Sami Mujawar
On 27/05/2021 10:19 AM, Sami Mujawar via groups.io wrote:
Hi Laszlo, Liming,
Apologies for not doing it earlier. I was not sure if it was within my
right to merge the change.
I will
On 05/26/21 19:08, Devon Bautista wrote:
> Currently, the largest volume size for building OVMF images is 4MB. With
> the growth of the Linuxboot project, maintainers have had to maintain a
> fork containing this patch which allows larger image sizes in order for
> Linuxboot developers/users to
On 05/27/21 01:10, Brijesh Singh wrote:
> (I missed adding devel@edk2.groups.io, resending the series)
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
>
> SEV-SNP builds upon existing SEV and SEV-ES functionality while adding
> new hardware-based memory protections. SEV-SNP adds
On 05/25/21 07:31, Dov Murik wrote:
> Booting with SEV prevented the loading of kernel, initrd, and kernel
> command-line via QEMU fw_cfg interface because they arrive from the VMM
> which is untrusted in SEV.
>
> However, in some cases the kernel, initrd, and cmdline are not secret
> but should
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The InstallAcpiTable() helper function buys us nothing. Reduce code
> complexity by removing the function.
>
> This patch is best viewed with "git show -b".
>
> Cc: Anthony Perard
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: Julien Grall
> Cc:
On 5/24/21 3:01 PM, Sami Mujawar wrote:
> From: Andreas Sandberg
>
> Bugzilla: 3415 (https://bugzilla.tianocore.org/show_bug.cgi?id=3415)
>
> The GICv3 architecture supports up to 1020 ordinary interrupt
> lines. The actual number of interrupts supported is described by the
> ITLinesNumber
Hi Laszlo, Liming,
Apologies for not doing it earlier. I was not sure if it was within my right to
merge the change.
I will merge this in the next 2 hours.
Regards,
Sami Mujawar
From: Laszlo Ersek
Date: Thursday, 27 May 2021 at 09:50
To: gaoliming , devel@edk2.groups.io
, Sami Mujawar
Cc:
On 05/27/21 10:24, Philippe Mathieu-Daudé wrote:
> On 5/26/21 10:14 PM, Laszlo Ersek wrote:
>> Due to switching to the QemuFwCfgAcpiPlatformDxe driver earlier in this
>> series, require QEMU version 1.7.1 in the "OvmfPkg/README" file, and
>> require 1.7 or later machine types too.
>>
>> Cc: Ard
On 05/27/21 09:34, Ard Biesheuvel wrote:
> On Wed, 26 May 2021 at 22:15, Laszlo Ersek wrote:
>>
>> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
>> Repo: https://pagure.io/lersek/edk2.git
>> Branch: xen_split_bz_2122
>>
>> This patch set removes dynamic Xen enlightenment
Hi Liming,
On 05/27/21 04:32, gaoliming wrote:
> If no objection, I will merge this patch today. Then, tomorrow, I will create
> stable tag 202105.
yes, please do that -- TBH, I thought Sami would merge it sooner, as
Sami does have maintainer access through DynamicTablesPkg and
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> According to the function-top comment, SmbiosTablePublishEntry() is
> supposed to return an error code if no SMBIOS data is found, from either
> GetXenSmbiosTables() or GetQemuSmbiosTables(). Currently the function
> returns EFI_SUCCESS in this case
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The Bhyve platform specifies the dynamic access method for
> "PcdPciDisableBusEnumeration" needlessly.
>
> After the DSC file sets the PCD to TRUE by default, the PCD is never
> written again. In particular, the
>
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The OvmfXen platform specifies the dynamic access method for
> "PcdPciDisableBusEnumeration" needlessly.
>
> After the DSC file sets the PCD to TRUE by default, the InitializeXen()
> function in XenPlatformPei superfluously sets the PCD to TRUE again.
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> - #include only such public headers in "AcpiPlatform.h" that are required
> by the function declarations and type definitions introduced in
> "AcpiPlatform.h". Don't use "AcpiPlatform.h" as a convenience #include
> file.
>
> - In every file, list
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The built-in ACPI tables for Bhyve are located in the
> "OvmfPkg/Bhyve/AcpiTables" module, not in the "OvmfPkg/AcpiTables" module.
> Correct the typo in a code comment.
>
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: Peter Grehan
> Cc: Philippe
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Xen is an advanced hypervisor; no Xen guest can function correctly without
> the hypervisor's dynamically provided ACPI tables. Remove the built-in
> (fallback) tables from XenAcpiPlatformDxe -- and the OvmfXen platform.
>
> Remove any dependencies from
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The QemuDetected() function wraps QemuFwCfgIsAvailable(); it always fails
> on Xen. Because of that, we can eliminate the QemuDetected() call itself
> from the Xen ACPI platform driver, and then the rest of "Qemu.c" becomes
> useless -- the workhorse
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The root of the QEMU ACPI linker/loader client in XenAcpiPlatformDxe is
> the InstallQemuFwCfgTables() function. This function always fails on Xen,
> due to its top-most QemuFwCfgFindFile() call.
>
> Remove the InstallQemuFwCfgTables() function call from
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Locate the SMBIOS protocol internally to the InstallAllStructures()
> function. This has no performance impact (InstallAllStructures() is only
> called once), but moving the code from the entry point function makes the
> latter smaller. And that will be
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> - Sort all sections in the INF file.
>
> - Remove unused packages (MdeModulePkg) and lib classes (BaseMemoryLib)
> from the INF file.
>
> - Restrict some lib classes (BaseLib, HobLib) and GUIDs (gEfiXenInfoGuid)
> to IA32 and X64, in the INF file;
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Rename "XenSupport.c" to "ScanForRootBridges.c", after the main function
> in it.
>
> Update the file-top comments; refer to both Bhyve and Xen.
>
> Cc: Anthony Perard
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: Julien Grall
> Cc: Peter Grehan
>
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The "OvmfPkg/Library/PciHostBridgeLibScan/PciHostBridgeLibScan.inf"
> instance is used in the following platforms in edk2:
>
> OvmfPkg/Bhyve/BhyveX64.dsc
> OvmfPkg/OvmfXen.dsc
>
> Neither Bhyve nor Xen provide a Q35 board, therefore the expression
>
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The "OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf" instance is
> used by the following platforms in edk2:
>
> OvmfPkg/AmdSev/AmdSevX64.dsc
> OvmfPkg/OvmfPkgIa32.dsc
> OvmfPkg/OvmfPkgIa32X64.dsc
> OvmfPkg/OvmfPkgX64.dsc
>
> All these
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Switch the OvmfXen platform from the "OvmfPkg/PciHostBridgeLib" instance
> to the "OvmfPkg/PciHostBridgeLibScan" instance. Currently this is a no-op
> functionally; we'll customize the "PciHostBridgeLibScan" instance later.
>
> Cc: Anthony Perard
> Cc:
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Switch the Bhyve platform from the "OvmfPkg/PciHostBridgeLib" instance to
> the "OvmfPkg/PciHostBridgeLibScan" instance. Currently this is a no-op
> functionally; we'll customize the "PciHostBridgeLibScan" instance later.
>
> Cc: Ard Biesheuvel
> Cc:
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> - In every C file, list every necessary public #include individually, with
> an example identifier that's actually consumed.
>
> - Place all public #includes first, all module-private #includes second.
> Separate them with a single empty line. Keep
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> At this point, the IncompatiblePciDeviceSupportDxe driver is included in
> the following platforms in edk2:
>
> OvmfPkg/AmdSev/AmdSevX64.dsc
> OvmfPkg/OvmfPkgIa32.dsc
> OvmfPkg/OvmfPkgIa32X64.dsc
> OvmfPkg/OvmfPkgX64.dsc
>
> All those platforms
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The entry point function of "OvmfPkg/IncompatiblePciDeviceSupportDxe",
> namely DriverInitialize()
> [OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c],
> bails out immediately if "PcdPciDisableBusEnumeration" is TRUE.
>
> The
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> With the Xen-dependent PcdSetBoolS() call removed from
> OvmfPkg/PlatformPei, the "OvmfPkgIa32.dsc", "OvmfPkgIa32X64.dsc",
> "OvmfPkgX64.dsc" platforms never write "PcdPciDisableBusEnumeration". This
> means we don't need a dynamic default for the PCD in
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Because "PcdPciDisableBusEnumeration" is always TRUE in the OvmfXen
> platform, we can remove the delayed ACPI table installation from
> XenAcpiPlatformDxe. A number of dependencies become useless this way;
> remove them too.
>
> (Note that, conversely,
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> The "OvmfPkg/AcpiTables/AcpiTables.inf" module is no longer used by any
> module in edk2; remove it.
>
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: Philippe Mathieu-Daudé
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
> Signed-off-by:
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Turn the "QemuLoader.h" header into a public (IndustryStandard) one. The
> QEMU ACPI linker-loader interface is stable between QEMU and multiple
> guest firmwares.
>
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: Philippe Mathieu-Daudé
> Ref:
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> "QemuLoader.h" needs the QEMU_FW_CFG_FNAME_SIZE macro. This macro used to
> live in the QemuFwCfgLib class header, but we moved it to the more
> foundational IndustryStandard include file called "QemuFwCfg.h" in commit
> 5583a8a4ffd0
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Place all public #includes first, all module-private #includes second.
> Separate them with a single empty line. Keep each section sorted in
> itself.
>
> Sort all sections in both INF files.
>
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: Philippe
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> - Remove the leading underscores from the #include guard macro names;
> clean up the names in general.
>
> - Remove the useless "Include/" directory prefix from the public header
> pathnames.
>
> - Fix incorrect file-top comment.
>
> Cc: Ard
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Due to switching to the QemuFwCfgAcpiPlatformDxe driver earlier in this
> series, require QEMU version 1.7.1 in the "OvmfPkg/README" file, and
> require 1.7 or later machine types too.
>
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: Philippe
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> For symmetry with the historical OvmfPkg* platforms, remove the three Xen
> drivers from the remotely attested, QEMU/KVM-only, AmdSev platform. Xen
> (HVM and PVH) guests are supported by the dedicated OvmfXen platform.
>
> No module remains dependent on
On 5/26/21 10:14 PM, Laszlo Ersek wrote:
> Remove the three Xen drivers as the first step for removing Xen support
> from the historical OvmfPkg* platforms. Xen (HVM and PVH) guests are
> supported by the dedicated OvmfXen platform.
>
> No module remains dependent on XenHypercallLib, so remove
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3397
Current Ppi/MmControl.h file has structure definition of "struct
_PEI_MM_CONTROL_PPI". This name mismatches with its definition in PI
Specification v1.7 (Errata) as "struct _EFI_PEI_MM_CONTROL_PPI".
In addition, field types
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3397
The current MdePkg/Include/Ppi/MmControl.h file contains function and
structure definitions mismatch with those in Platform Initialization
Specification v1.7 (Errata A). These discrepancies will cause build
failure during usage.
This
Hi Jack,
I believe that driver has only been tested with the FT232AM, which has not been
manufactured for several years now. Ashley (cc'd) implemented it as an intern
project in 2013: https://github.com/tianocore/edk2/commit/3f1484f
There probably needs to be some work done to get it running
Hi Grant,
Edkrepo has a similar high level objective of enabling multi-repository
workflows in git. However, it is more feature rich than repo. Here is an
unexhaustive list of features it provides above and beyond repo:
1. Simplified project discovery - The "edkrepo manifest" shows a
On Wed, 26 May 2021 at 22:15, Laszlo Ersek wrote:
>
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
> Repo: https://pagure.io/lersek/edk2.git
> Branch: xen_split_bz_2122
>
> This patch set removes dynamic Xen enlightenment from the following
> platforms:
>
>
Hi Laszlo,
Based on comments from Sami, maybe I need remove this patch and reuse the qemu
memory initialization lib code. Thank for your comments.
Thanks
Jianyong
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, May 19, 2021 2:12 PM
> To: devel@edk2.groups.io; Jianyong Wu
Hi Sami, Laszlo,
Sorry for late reply, thanks for nice review work from both of you. Very
helpful for me.
Thanks
Jianyong
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, May 19, 2021 2:55 PM
> To: Sami Mujawar ; Jianyong Wu
> ; devel@edk2.groups.io;
>
Hi Laszlo,
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, May 19, 2021 2:37 PM
> To: devel@edk2.groups.io; Jianyong Wu ;
> ardb+tianoc...@kernel.org; Sami Mujawar
> Cc: hao.a...@intel.com; Justin He ; Leif Lindholm
>
> Subject: Re: [edk2-devel] [PATCH v2 4/5] ArmVirtPkg:
Hi Sami,
> -Original Message-
> From: Sami Mujawar
> Sent: Wednesday, May 19, 2021 4:27 AM
> To: Jianyong Wu ; devel@edk2.groups.io;
> ler...@redhat.com; ardb+tianoc...@kernel.org
> Cc: hao.a...@intel.com; Justin He ; Leif Lindholm
> ; nd
> Subject: Re: [PATCH v2 4/5] ArmVirtPkg:
82 matches
Mail list logo
