[edk2] [PATCH 2/3] Ovmfpkg/VirtioBlkDxe: map virtio-blk request and response buffers

When device is behind the IOMMU, driver is require to pass the device address of virtio request, response and any memory referenced by those request/response to the bus master. The patch uses IOMMU-like member functions from VIRTIO_DEVICE_PROTOCOL to map request and response buffers system

[edk2] [PATCH 1/3] OvmfPkg/VirtioBlkDxe: map VRING using VirtioRingMap()

When device is behind the IOMMU then driver need to pass the device address when programing the bus master. The patch uses VirtioRingMap() to map the VRING system physical address to device address. Cc: Ard Biesheuvel Cc: Jordan Justen Cc:

[edk2] [PATCH 3/3] OvmfPkg/VirtioBlkDxe: negotiate VIRTIO_F_IOMMU_PLATFORM

VirtioBlkDxe driver has been updated to use IOMMU-like member functions from VIRTIO_DEVICE_PROTOCOL to translate the system physical address to device address. We do not need to do anything special when VIRTIO_F_IOMMU_PLATFORM bit is present hence treat it in parallel with VIRTIO_F_VERSION_1. Cc:

[edk2] [PATCH 0/3] OvmfPkg/VirtioBlkDxe: map host address to device address

The patch updates the VirtioBlkDxe to use IOMMU-like member functions to map the system physical address to device address for buffers (including vring, device specific request and response pointed by vring descriptor, and any furter memory reference by those request and response). Cc: Ard

[edk2] [PATCH] MdeModulePkg/PciBusDxe: Enable Bus Master on P2P bridges on demand

From: Ruiyu Ni The patch dynamically enables Bus Master on P2P bridges only when requested by a device driver through PciIo.Attribute() to enable the Bus Master. Signed-off-by: Sean Brogan Signed-off-by: Ruiyu Ni Cc:

[edk2] [PATCH v2 3/5] MdePkg/PciSegmentInfoLib: Add PciSegmentInfoLib class and instance.

The patch adds PciSegmentInfoLib library class which is used by PciSegmentLib (commit in next patch) to support multiple segment PCI configuration access. BasePciSegmentInfoLibNull instance is added but it shouldn't be used by any real platform. Any single segment platform that wants to use

[edk2] [PATCH v2 5/5] MdePkg/S3PciSegmentLib: Add S3PciSegmentLib class and instance.

The patch adds the new library class S3PciSegmentLib to carry out PCI configuration and enable the PCI operations to be replayed during an S3 resume. This library class maps directly on top of the PciSegmentLib class. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni

[edk2] [PATCH v2 4/5] MdePkg/PciSegmentLib: Add instances that consumes PciSegmentInfoLib

The patch adds two PciSegmentLib instances that consumes PciSegmentInfoLib to provide multiple segments PCI configuration access. BasePciSegmentLibSegmentInfo instance is a BASE library. DxeRuntimePciSegmentLibSegmentInfo instance is to be linked with runtime drivers to provide not only boot time

[edk2] [PATCH v2 2/5] MdePkg/PciExpress: Add macro PCI_ECAM_ADDRESS

The patch adds new macro PCI_ECAM_ADDRESS into PciExpress21.h, to align to the PCIE spec, and also update PciExpressLib.h to redirect PCI_EXPRESS_LIB_ADDRESS to the new macro. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Liming Gao

[edk2] [PATCH v2 1/5] MdePkg/PciSegmentLib: Fix typo in function header comments

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Cc: Liming Gao --- MdePkg/Include/Library/PciSegmentLib.h | 102 +-- .../Library/BasePciSegmentLibPci/PciSegmentLib.c | 136 +++

Re: [edk2] [PATCH v3 00/21] OvmfPkg/Virtio: introduce IOMMU-like member functions

On 08/24/17 02:26, Laszlo Ersek wrote: > Hi Brijesh, > > so here's what I'd like to do with v3: > > On 08/23/17 14:22, Brijesh Singh wrote: >> Brijesh Singh (23): >> OvmfPkg: introduce IOMMU-like member functions to >> VIRTIO_DEVICE_PROTOCOL >> OvmfPkg/Virtio10Dxe: implement IOMMU-like

[edk2] [PATCH v2 0/5] Add multiple PCI segments configuration access support

v2: Add missing function header and file header. Correct all incorrect file headers. Ruiyu Ni (5): MdePkg/PciSegmentLib: Fix typo in function header comments MdePkg/PciExpress: Add macro PCI_ECAM_ADDRESS MdePkg/PciSegmentInfoLib: Add PciSegmentInfoLib class and instance.

Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Fix memory protection crash

Star, On 08/24/17 05:20, Star Zeng wrote: > https://bugzilla.tianocore.org/show_bug.cgi?id=624 reports > memory protection crash in PiSmmCpuDxeSmm, Ia32 build with > RAM above 4GB (of which 2GB are placed in 64-bit address). > It is because UEFI builds identity mapping page tables, >> 4G address

Re: [edk2] HiiSetToDefaults behavior

Hello Dandan, Thanks for the clarification. So I assume there is no way that will cause this call to leave certain fields as they are. Is this correct? Best Regards, Wim Vervoorn Eltan B.V. Ambachtstraat 23 5481 SM Schijndel The Netherlands T : +31-(0)73-594 46 64 E : wvervo...@eltan.com W

Re: [edk2] [Patch 1/2] MdePkg: Add new definitions for Management Mode.

Eric: I have two comments. 1) New ppi/protocol should be placed below PI1.6 comment in MdePkg.dec 2) MdePkg\Include\Pi\PiMmCis.h still has SMM word in description. It should use MM instead of SMM. Thanks Liming >-Original Message- >From: Dong, Eric >Sent: Monday, August 14, 2017 4:33

Re: [edk2] [PATCH 3/3] IntelSiliconPkg/PlatformVTdSample: update ExceptionDevice

PLATFORM_EXCEPTION_DEVICE_SCOPE_STRUCT is used in mExceptionPciDeviceIdList, that is wrong and should be PLATFORM_EXCEPTION_PCI_DEVICE_ID_STRUCT. Others are good to me. Reviewed-by: Star Zeng +PLATFORM_EXCEPTION_PCI_DEVICE_ID_STRUCT mExceptionPciDeviceIdList[] = +{ + { +

Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Fix memory protection crash

Laszlo, X64 defined mPhysicalAddressBits already before the patch, and has the code below to assign it. mPhysicalAddressBits = CalculateMaximumSupportAddress (); Thanks, Star -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek

Re: [edk2] [Patch] BaseTools: Enable --whole-archive in GCC tool chain as the default option

On 08/24/17 08:28, Liming Gao wrote: > https://bugzilla.tianocore.org/show_bug.cgi?id=581 (1) I suggest adding one sentence (before you push the patch): "The --whole-archive linker option helps us catch multiply defined symbols." > Contributed-under: TianoCore Contribution Agreement 1.1 >

[edk2] [PATCH] Revert "OvmfPkg/build.sh: select the GCC49 toolchain settings for gcc-7.*"

This reverts commit ca56256d5e0b7e63325b049e90a6bd03f90e3598: TianoCore BZ#671 has been fixed in commit 2f7f1e73c10f ("BaseTools: Add the missing -pie link option in GCC tool chain", 2017-08-23), so we can return to the GCC5 toolchain with

Re: [edk2] [Patch] BaseTools: Enable --whole-archive in GCC tool chain as the default option

On 25 August 2017 at 11:28, Laszlo Ersek wrote: > On 08/24/17 08:28, Liming Gao wrote: >> https://bugzilla.tianocore.org/show_bug.cgi?id=581 > > (1) I suggest adding one sentence (before you push the patch): > > "The --whole-archive linker option helps us catch multiply defined

[edk2] [PATCH 0/2] OvmfPkg/VirtioRngDxe: negotiate VIRTIO_F_IOMMU_PLATFORM

The series adds support to neogtiate iommu_platform feature bit. The feature bit available for morden-only device Qemu cli: # $QEMU \ ... \ -device virtio-rng-pci,disable-legacy=on,iommu_platform=true ... Repo: https://github.com/codomania/edk2 Branch: virtio-rng-1 Brijesh Singh (2):

[edk2] [PATCH 1/2] OvmfPkg/Virtio10: define VIRTIO_F_IOMMU_PLATFORM feature bit

This feature indicates that the device is behind an IOMMU that translates bus addresses from the device into physical addresses in memory. If this feature bit is set to 0, then the device emits physical addresses which are not translated further, even though an IOMMU may be present. see [1] for

[edk2] [PATCH 2/2] OvmfPkg/VirtioRngDxe: negotiate VIRTIO_F_IOMMU_PLATFORM

VirtioRngDxe driver has been updated to use IOMMU-like member functions from VIRTIO_DEVICE_PROTOCOL to translate the system physical address to device address. We do not need to do anything special when VIRTIO_F_IOMMU_PLATFORM bit is present hence treat it in parallel with VIRTIO_F_VERSION_1. Cc:

Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Fix memory protection crash

Laszlo, I am ok to centralize the definition in the patch(V2 will cover it), how about PiSmmCpuDxeSmm.c? Have you helped get the test result with the patch? Thanks, Star -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Friday, August 25, 2017 7:52 PM To: Zeng,

Re: [edk2] [Patch] BaseTools: Enable --whole-archive in GCC tool chain as the default option

On 08/25/17 12:30, Ard Biesheuvel wrote: > On 25 August 2017 at 11:28, Laszlo Ersek wrote: >> On 08/24/17 08:28, Liming Gao wrote: >>> https://bugzilla.tianocore.org/show_bug.cgi?id=581 >> >> (1) I suggest adding one sentence (before you push the patch): >> >> "The

Re: [edk2] [Patch] BaseTools: Update toolsetup.bat to support the case without EDK_TOOLS_BIN

Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: Gao, Liming Sent: Friday, August 25, 2017 4:52 PM To: edk2-devel@lists.01.org Cc: Zhu, Yonghong Subject: [Patch] BaseTools: Update toolsetup.bat to support

Re: [edk2] [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Fix memory protection crash

On 08/25/17 11:53, Zeng, Star wrote: > Laszlo, > > X64 defined mPhysicalAddressBits already before the patch, and has the code > below to assign it. > > mPhysicalAddressBits = CalculateMaximumSupportAddress (); Thanks. Do you think it would make sense to centralize the definition (i.e., the

[edk2] [PATCH 4/5] Omap35xxPkg: remove bogus UncachedMemoryAllocationLib dependency

Remove a false dependency on UncachedMemoryAllocationLib, and fix the broken build while we're at it. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- Omap35xxPkg/Library/DebugAgentTimerLib/DebugAgentTimerLib.inf | 1 +

[edk2] [PATCH] Platform/Armada/Pp2Dxe: switch to ArmDmaLib

Instead of hardcoding the non-cache coherent nature of this device by invoking UncachedMemoryAllocationLib directly for allocating shared buffers, switch to DmaLib, which encapsulates this at a more abstract level. This allows the driver to be shared with platforms that are cache coherent (by

[edk2] [PATCH 3/5] BeagleBoardPkg: remove UncachedMemoryAllocationLib resolutions

ArmDmaLib no longer depends on UncachedMemoryAllocationLib, so we can remove the library class resolutions for it. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- BeagleBoardPkg/BeagleBoardPkg.dsc | 2 -- 1 file changed, 2

[edk2] [PATCH 0/5] ArmPkg et al: remove UncachedMemoryallocationLib

This series is a followup to 'ArmPkg/ArmDmaLib: remove dependency on UncachedMemoryAllocationLib' sent out yesterday, and removes library entirely. There are two reasons for this: - UncachedMemoryAllocationLib is often abused by drivers that should be using DMA abstractions instead. It is up to

[edk2] [PATCH 5/5] ArmPkg: remove UncachedMemoryAllocationLib

Now that ArmDmaLib can take care of its own memory allocation needs, let's get rid of UncachedMemoryAllocationLib entirely. This forces platforms to declare the required semantics (non-cache coherent DMA, whichever way it is implemented), rather than using uncached memory allocations directly,

[edk2] [PATCH 1/5] EmbeddedPkg/DmaLib: add routine to allocate aligned buffers

DmaLib's purpose is to manage memory that is shared between the host and DMA capable devices. In some cases, this requires a larger alignment than page size, and we currently don't cater for that in DmaLib. So add a variant of DmaAllocateBuffer () that takes an alignment parameter.

[edk2] [PATCH 2/5] ArmPkg/ArmDmaLib: implement DmaAllocateAlignedBuffer()

Implement the new DmaLib routine that returns DMA'able buffers at a specified minimum alignment. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- ArmPkg/Library/ArmDmaLib/ArmDmaLib.c | 42 ++-- 1 file changed,

Re: [edk2] HiiSetToDefaults behavior

Hi Wim Vervoorn, Current behavior of HiiSetToDefaults(): 1. For Question has the specified type default value, will set the default value to storage for the Question. 2. For Question without the specified type default, other type default value can be shared.(such as: standard default doesn't

[edk2] [PATCH 2/3] IntelSiliconPkg/IntelVTd: update PlatformVtdPolicy

1. Handle flexible exception list format. 1.1 Handle DeviceScope based device info. 1.2 Handle PciDeviceId based device info. 2. Reorg the PCI_DEVICE_INFORMATION 2.1 Merge data pointer reduce allocation times 2.2 Add PCI device id to PCI_DEVICE_INFORMATION 2.3 Rename PciDescriptor to avoid

[edk2] [PATCH 0/3] Add flexible exception device reporting

During VTd enabling, we notice a platform may want to add exception device based upon VendorId/DeviceId. We update GetExceptionDeviceList() function to support both style. 1) Support Device scope based reporting: Such as, Seg:0/StartBus:0/(Dev:1C|Func:0)/(Dev:0|Func:0) 2) Support PCI

[edk2] [PATCH 3/3] IntelSiliconPkg/PlatformVTdSample: update ExceptionDevice

Add sample for device scope based exception list and PCI vendor id based exception list. Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao --- IntelSiliconPkg/PlatformVTdSampleDxe/PlatformVTdSampleDxe.c |

[edk2] [PATCH 1/3] IntelSiliconPkg/header: update PlatformVtdPolicy

Add flexible exception list format: 1) Support Device scope based reporting: Such as, Seg:0/StartBus:0/(Dev:1C|Func:0)/(Dev:0|Func:0) 2) Support PCI VendorId/DeviceId based reporting Such as, VID:8086|DID:9D2F|Rev:21|SVID:8086|SDID:7270 Cc: Star Zeng Contributed-under:

[edk2] HiiSetToDefaults behavior

Hello, I have a question about the expect behavior of HiiSetToDefaults(). So far I haven't been able to find a clear definition of what this should do. What I expect is that this call would only touch the items that have a default defined. So what I would think is that Test2OfValue below would

[edk2] [Patch] BaseTools: Update toolsetup.bat to support the case without EDK_TOOLS_BIN

When EDK_TOOLS_BIN is not set, %EDK_TOOLS_PATH%\Bin\Win32 will be used as the binary tool directory. But, %EDK_TOOLS_PATH%\Bin\Win32 may not exist. On this case, toolsetup.bat should continue to do the other setting, such VS tool chain and tool conf file copy. Contributed-under: TianoCore

Re: [edk2] HiiSetToDefaults behavior

Hi Wim Vervoorn, Yes, it's correct for some Questions like oneof, numeric, if they don't have default value, this call will take first option value, minimum value as their default value. But for Question like String opcode, if it doesn't have default, the value of this question will be

Re: [edk2] [PATCH 3/3] IntelSiliconPkg/PlatformVTdSample: update ExceptionDevice

Yes. Typical copy-paste issue. Thanks to correct me. > -Original Message- > From: Zeng, Star > Sent: Friday, August 25, 2017 5:39 PM > To: Yao, Jiewen ; edk2-devel@lists.01.org > Cc: Zeng, Star > Subject: RE: [PATCH 3/3]

Re: [edk2] [PATCH 0/2] OvmfPkg/VirtioRngDxe: negotiate VIRTIO_F_IOMMU_PLATFORM

On 08/25/17 12:37, Brijesh Singh wrote: > The series adds support to neogtiate iommu_platform feature bit. The feature > bit available for morden-only device > > Qemu cli: > > # $QEMU \ > ... \ > -device virtio-rng-pci,disable-legacy=on,iommu_platform=true > ... > > Repo:

Re: [edk2] [PATCH] Revert "OvmfPkg/build.sh: select the GCC49 toolchain settings for gcc-7.*"

Reviewed-by: Jordan Justen On 2017-08-25 02:34:54, Laszlo Ersek wrote: > This reverts commit ca56256d5e0b7e63325b049e90a6bd03f90e3598: > > TianoCore BZ#671 has > been fixed in commit 2f7f1e73c10f ("BaseTools: Add

Re: [edk2] [PATCH] Revert "OvmfPkg/build.sh: select the GCC49 toolchain settings for gcc-7.*"

On 08/25/17 17:42, Jordan Justen wrote: > Reviewed-by: Jordan Justen Thank you, pushed as commit 656ac0c7d8ea. Laszlo > On 2017-08-25 02:34:54, Laszlo Ersek wrote: >> This reverts commit ca56256d5e0b7e63325b049e90a6bd03f90e3598: >> >> TianoCore BZ#671