[edk2] [PATCH] BaseTools/Conf: Support LLVM39 and LLVM40 in CLANG38 toolchain

[Shi Steven]

From: "Shi, Steven" 

Add LLVM39 and LLVM40 support in CLANG38 toolchain

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi 
---
 BaseTools/Conf/tools_def.template | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 1fa3ca3..2f83341 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -380,7 +380,8 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
Files/CodeSourcery/Sourcery G
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
 #   CLANG38  -Linux-  Requires:
-# Clang v3.8 or later, LLVMgold plugin and GNU 
binutils 2.26 targeting x86_64-linux-gnu
+# Clang v3.8, LLVMgold plugin and GNU binutils 
2.26 targeting x86_64-linux-gnu
+# Clang v3.9 or later, LLVMgold plugin and GNU 
binutils 2.28 targeting x86_64-linux-gnu
 #Optional:
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
@@ -5512,7 +5513,7 @@ DEFINE CLANG38_X64_PREFIX   = ENV(CLANG38_BIN)
 DEFINE CLANG38_IA32_TARGET  = -target i686-pc-linux-gnu
 DEFINE CLANG38_X64_TARGET   = -target x86_64-pc-linux-gnu
 
-DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body 
-fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value 
-Wno-parentheses-equality -Wno-unknown-pragmas 
-Wno-tautological-constant-out-of-range-compare 
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables 
-mno-sse -mno-mmx -msoft-float -mno-implicit-float  
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
-funsigned-char -fno-ms-extensions -Wno-null-dereference 
-Wno-tautological-compare -Wno-unknown-warning-option
+DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body 
-fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value 
-Wno-parentheses-equality -Wno-unknown-pragmas 
-Wno-tautological-constant-out-of-range-compare 
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables 
-mno-sse -mno-mmx -msoft-float -mno-implicit-float  
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
-funsigned-char -fno-ms-extensions -Wno-null-dereference 
-Wno-tautological-compare -Wno-unknown-warning-option -Wno-varargs
 
 ###
 # CLANG38 IA32 definitions
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] PeiCore: Support pre memory page allocation

[Gao, Liming]

Reviewed-by: Star Zeng 

>-Original Message-
>From: Zeng, Star
>Sent: Saturday, August 19, 2017 12:01 AM
>To: edk2-devel@lists.01.org
>Cc: Zeng, Star ; Gao, Liming ; Ni,
>Ruiyu 
>Subject: [PATCH 0/5] PeiCore: Support pre memory page allocation
>
>Follow PI 1.6 spec to support pre memory page allocation
>and support FreePages.
>
>Cc: Liming Gao 
>Cc: Ruiyu Ni 
>
>Star Zeng (5):
>  MdePkg PiPeiCis.h: Add FreePages definition
>  MdePkg PeiServicesLib: Add PeiServicesFreePages
>  MdePkg PeiMemoryAllocationLib: Update Free(Aligned)Pages
>  MdePkg PeiMemoryAllocationLib: Update InternalAllocateAlignedPages
>  MdeModule PeiCore: Support pre memory page allocation
>
> MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c  |  27 +-
> MdeModulePkg/Core/Pei/Memory/MemoryServices.c  | 559
>-
> MdeModulePkg/Core/Pei/PeiMain.h|  89 +++-
> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c|   8 +-
> MdeModulePkg/Core/Pei/Ppi/Ppi.c|  16 +-
> MdePkg/Include/Library/PeiServicesLib.h|  31 +-
> MdePkg/Include/Pi/PiPeiCis.h   |  27 +
> .../PeiMemoryAllocationLib/MemoryAllocationLib.c   | 188 ++-
> MdePkg/Library/PeiServicesLib/PeiServicesLib.c |  35 +-
> 9 files changed, 777 insertions(+), 203 deletions(-)
>
>--
>2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/5] PeiCore: Support pre memory page allocation

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao,
>Liming
>Sent: Wednesday, August 23, 2017 3:54 PM
>To: Zeng, Star ; edk2-devel@lists.01.org
>Cc: Ni, Ruiyu 
>Subject: Re: [edk2] [PATCH 0/5] PeiCore: Support pre memory page allocation
>
>Reviewed-by: Star Zeng 
>
>>-Original Message-
>>From: Zeng, Star
>>Sent: Saturday, August 19, 2017 12:01 AM
>>To: edk2-devel@lists.01.org
>>Cc: Zeng, Star ; Gao, Liming ;
>Ni,
>>Ruiyu 
>>Subject: [PATCH 0/5] PeiCore: Support pre memory page allocation
>>
>>Follow PI 1.6 spec to support pre memory page allocation
>>and support FreePages.
>>
>>Cc: Liming Gao 
>>Cc: Ruiyu Ni 
>>
>>Star Zeng (5):
>>  MdePkg PiPeiCis.h: Add FreePages definition
>>  MdePkg PeiServicesLib: Add PeiServicesFreePages
>>  MdePkg PeiMemoryAllocationLib: Update Free(Aligned)Pages
>>  MdePkg PeiMemoryAllocationLib: Update InternalAllocateAlignedPages
>>  MdeModule PeiCore: Support pre memory page allocation
>>
>> MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c  |  27 +-
>> MdeModulePkg/Core/Pei/Memory/MemoryServices.c  | 559
>>-
>> MdeModulePkg/Core/Pei/PeiMain.h|  89 +++-
>> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c|   8 +-
>> MdeModulePkg/Core/Pei/Ppi/Ppi.c|  16 +-
>> MdePkg/Include/Library/PeiServicesLib.h|  31 +-
>> MdePkg/Include/Pi/PiPeiCis.h   |  27 +
>> .../PeiMemoryAllocationLib/MemoryAllocationLib.c   | 188 ++-
>> MdePkg/Library/PeiServicesLib/PeiServicesLib.c |  35 +-
>> 9 files changed, 777 insertions(+), 203 deletions(-)
>>
>>--
>>2.7.0.windows.1
>
>___
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] BaseTools: Add the missing -pie link option in GCC tool chain

[Liming Gao]

GCC tool chain uses -fpie in CC_FLAGS. So, add -pie in DLINK_FLAGS.

More discussion in
https://lists.01.org/pipermail/edk2-devel/2017-August/013508.html

3.13 Options for Linking

'-pie'
 Produce a position independent executable on targets that support
 it.  For predictable results, you must also specify the same set
 of options used for compilation ('-fpie', '-fPIE', or model
 suboptions) when you specify this linker option.

3.18 Options for Code Generation Conventions

'-fpie'
'-fPIE'
 These options are similar to '-fpic' and '-fPIC', but generated
 position independent code can be only linked into executables.
 Usually these options are used when '-pie' GCC option is used
 during linking.
 '-fpie' and '-fPIE' both define the macros '__pie__' and
 '__PIE__'. The macros have the value 1 for '-fpie' and 2 for
 '-fPIE'.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
---
 BaseTools/Conf/tools_def.template | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 6076a69..aff0cbd 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4502,7 +4502,7 @@ DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib 
-Wl,-n,-q,--gc-sections -z comm
 DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
-Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
 DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
-Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) 
-Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC44_IA32_DLINK2_FLAGS   = -Wl,--defsym=PECOFF_HEADER_SIZE=0x220 
DEF(GCC_DLINK2_FLAGS_COMMON)
-DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) 
-Wl,-melf_x86_64,--oformat=elf64-x86-64
+DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) 
-Wl,-melf_x86_64,--oformat=elf64-x86-64,-pie
 DEFINE GCC44_X64_DLINK2_FLAGS= -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 
DEF(GCC_DLINK2_FLAGS_COMMON)
 DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
 
@@ -4582,7 +4582,7 @@ DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib 
-Wl,-n,-q,--gc-sections -z comm
 DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
-Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
 DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC49_IA32_X64_DLINK_COMMON) 
-Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) 
-Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
 DEFINE GCC49_IA32_DLINK2_FLAGS   = DEF(GCC48_IA32_DLINK2_FLAGS)
-DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) 
-Wl,-melf_x86_64,--oformat=elf64-x86-64
+DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) 
-Wl,-melf_x86_64,--oformat=elf64-x86-64,-pie
 DEFINE GCC49_X64_DLINK2_FLAGS= DEF(GCC48_X64_DLINK2_FLAGS)
 DEFINE GCC49_ASM_FLAGS   = DEF(GCC48_ASM_FLAGS)
 DEFINE GCC49_ARM_ASM_FLAGS   = DEF(GCC48_ARM_ASM_FLAGS)
-- 
2.8.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Maintainers.txt: update OvmfPkg maintainership

[Laszlo Ersek]

Hello Konrad,

On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 17, 2017 at 01:47:59AM +0200, Laszlo Ersek wrote:
>> On 08/17/17 00:37, Jordan Justen wrote:
>>> On 2017-08-16 12:23:49, Leif Lindholm wrote:
>>
>> [snip]
>>
 - the value proposition
 for Linaro is that having maintainer parity ArmVirtPkg/OvmfPkg
 simplifies the task of maintaining feature parity between the two.
 (It is no secret that I would love to see them as a single package,
 making it easier to clean up the way EDK2-for-qemu gets packaged by
 Linux distributions.)
>>>
>>> I would also prefer to have OVMF support ARM and eventually RISC-V as
>>> well. I don't think Laszlo feels as confident about this though.
>>
>> I have two concerns:
>>
>> (1) Reorganizing OvmfPkg for this would take an immense amount of time
>> (with possible regressions).
>>
>> (2) Sharing more code between modules that aren't inherently
>> architecture-independent (and virtualization platform-independent) is risky.
>>
>> By "sharing more code", I mean extracting further library classes and
>> then unifying originally separate drivers. I also mean extracting common
>> files from separate library instances, and then unifying the lib
>> instances in a common directory, with multiple INF files, or with
>> arch-dependent sections in the one resultant INF file. Another method is
>> to control the same set of drivers / library instances differently, via
>> dynamic PCDs.
>>
>> While all this is great for code de-duplication, the chance of
>> regressions skyrockets if the code de-dup is not matched by a similar
>> overlap in maintenance (that is, review and testing).
>>
>> Personally I use QEMU/KVM (and occasionally QEMU/TCG) on x86 and
>> aarch64. I don't use 32-bit ARM (even guests, on aarch64 hosts), or any
>> kind of Xen. I've never seen RISC-V hardware (and probably won't --
>> nested TCG with QEMU doesn't count).
>>
>> The best counter-indication for this kind of increased sharing is the
>> *numerous* Xen-related regressions that have slipped through in the
>> past, simply because none of the OvmfPkg maintainers use Xen. (And the
>> Xen project seems to be unwilling or unable to delegate an official
>> reviewer or co-maintainer for the Xen-related code in OvmfPkg, despite
>> my repeated requests.) This has happened under ArmVirtPkg too (I recall
> 
> Who did you email/speak to? I hadn't seen any emails sent by
> you to xen-devel mailing list, but perhaps I missed them?

These emails are not easy to find (even in my own mailbox) because my
calls for help / suggestions for co-maintenance have been scattered over
time, loosely tied to OVMF regressions on Xen, or new Xen features in OVMF.

Keyword searches didn't help much, but I managed to find this email, for
example:

http://mid.mail-archive.com/f5e03398-33ca-c90d-743f-691d927657d3@redhat.com

Anthony, Gary, and xen-devel were addressed (among others). On 09/08/16
12:24, I wrote:

> Now, if you create a new platform (DSC + FDF) for Xen, that sort of
> forces someone from the Xen community to assume co-maintainership for
> the Xen bits. (Hopefully those bits would be easily identifiable by
> pathname.) I'd welcome that *very much*.

I remember more (for example I distinctly remember inviting Gary), but I
can't locate that message now.

On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote:
> It should be fairly simple to expand the 0-day OSSTest to build
> TianoCore and launch guests with it as a nice regression test.

The point is to catch regressions before they are merged. This requires
someone who uses Xen every day to review and/or test patches posted to
edk2-devel that affect Xen code in OVMF.

(If the OSSTest tool can identify and pick such patches from edk2-devel
automatically, that would work too, of course.)

Thanks,
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Iscsi Specification Document

[Karunakar P]

Hello All,

Do we have any specific Document for Iscsi?
Any document that describes the standard iscsi behavior.

Thanks,
karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Maintainers.txt: update OvmfPkg maintainership

[Wei Liu]

On Wed, Aug 23, 2017 at 11:04:06AM +0200, Laszlo Ersek wrote:
> On 08/23/17 03:30, Konrad Rzeszutek Wilk wrote:
> > It should be fairly simple to expand the 0-day OSSTest to build
> > TianoCore and launch guests with it as a nice regression test.
> 
> The point is to catch regressions before they are merged. This requires
> someone who uses Xen every day to review and/or test patches posted to
> edk2-devel that affect Xen code in OVMF.
> 
> (If the OSSTest tool can identify and pick such patches from edk2-devel
> automatically, that would work too, of course.)
> 

We have been testing OVMF in osstest since two or three years ago,
albeit the test cases are limited to booting and installing a guest.

The regression is going to be caught after patches are merged though
because we're pulling from the official OVMF tree.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] BaseTools: Add the missing -pie link option in GCC tool chain

[Laszlo Ersek]

Hi Liming,

On 08/23/17 10:04, Liming Gao wrote:
> GCC tool chain uses -fpie in CC_FLAGS. So, add -pie in DLINK_FLAGS.
> 
> More discussion in
> https://lists.01.org/pipermail/edk2-devel/2017-August/013508.html
> 
> 3.13 Options for Linking
> 
> '-pie'
>  Produce a position independent executable on targets that support
>  it.  For predictable results, you must also specify the same set
>  of options used for compilation ('-fpie', '-fPIE', or model
>  suboptions) when you specify this linker option.
> 
> 3.18 Options for Code Generation Conventions
> 
> '-fpie'
> '-fPIE'
>  These options are similar to '-fpic' and '-fPIC', but generated
>  position independent code can be only linked into executables.
>  Usually these options are used when '-pie' GCC option is used
>  during linking.
>  '-fpie' and '-fPIE' both define the macros '__pie__' and
>  '__PIE__'. The macros have the value 1 for '-fpie' and 2 for
>  '-fPIE'.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> ---
>  BaseTools/Conf/tools_def.template | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 6076a69..aff0cbd 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -4502,7 +4502,7 @@ DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib 
> -Wl,-n,-q,--gc-sections -z comm
>  DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
> -Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
>  DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
> -Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) 
> -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
>  DEFINE GCC44_IA32_DLINK2_FLAGS   = -Wl,--defsym=PECOFF_HEADER_SIZE=0x220 
> DEF(GCC_DLINK2_FLAGS_COMMON)
> -DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) 
> -Wl,-melf_x86_64,--oformat=elf64-x86-64
> +DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) 
> -Wl,-melf_x86_64,--oformat=elf64-x86-64,-pie
>  DEFINE GCC44_X64_DLINK2_FLAGS= -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 
> DEF(GCC_DLINK2_FLAGS_COMMON)
>  DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
>  
> @@ -4582,7 +4582,7 @@ DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib 
> -Wl,-n,-q,--gc-sections -z comm
>  DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
> -Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
>  DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC49_IA32_X64_DLINK_COMMON) 
> -Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) 
> -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
>  DEFINE GCC49_IA32_DLINK2_FLAGS   = DEF(GCC48_IA32_DLINK2_FLAGS)
> -DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) 
> -Wl,-melf_x86_64,--oformat=elf64-x86-64
> +DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) 
> -Wl,-melf_x86_64,--oformat=elf64-x86-64,-pie
>  DEFINE GCC49_X64_DLINK2_FLAGS= DEF(GCC48_X64_DLINK2_FLAGS)
>  DEFINE GCC49_ASM_FLAGS   = DEF(GCC48_ASM_FLAGS)
>  DEFINE GCC49_ARM_ASM_FLAGS   = DEF(GCC48_ARM_ASM_FLAGS)
> 

(1) you forgot to CC the participants of the previous thread :)

(2) Please add a reference to
 to the commit message.

(3) I tested the GCC49_X64_DLINK_FLAGS change with the following
commands, on Fedora 26 (the gcc version is "7.1.1 20170622 (Red Hat
7.1.1-3)"):

$ git clean -fdx
$ git reset --hard
$ . edksetup.sh --reconfig
$ make -C "$EDK_TOOLS_PATH"
$ build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -t GCC5 -n 6 -b DEBUG
$ qemu-system-x86_64 \
-m 5120 \
-smp 8 \
-pflash Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd \
-enable-kvm \
-global isa-debugcon.iobase=0x402 \
-debugcon file:debug-gcc5-64.fd.log \
-net none

The resultant OVMF binary works fine. (The UEFI shell is reached OK.)

(4) I regression-tested the GCC44_X64_DLINK_FLAGS change on RHEL-7.4,
using "gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)". No regressions were
found.

Tested-by: Laszlo Ersek 
Reviewed-by: Laszlo Ersek 

(5) When you push the patch (possibly after receiving comments from
others), please send a reminder for me to revert commit ca56256d5e0b
("OvmfPkg/build.sh: select the GCC49 toolchain settings for gcc-7.*",
2017-08-15).

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms] Maintainers.txt: Add Ard Biesheuvel

[Leif Lindholm]

On Tue, Aug 22, 2017 at 10:46:38PM +, Kinney, Michael D wrote:
> Reviewed-by: Michael D Kinney 

Thanks! Puched (together with Contributions.txt update) as
b263c30e5..98c7d7520.

/
Leif

> Mike
> 
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Tuesday, August 22, 2017 3:23 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ard Biesheuvel ; Kinney, Michael
> > D 
> > Subject: [PATCH edk2-platforms] Maintainers.txt: Add Ard
> > Biesheuvel
> > 
> > Initial version contained only myself and Mike. While a more
> > granular
> > structure will be needed long-term, let's have two ARM-
> > maintainers for now.
> > 
> > Cc: Ard Biesheuvel 
> > Cc: Michael D Kinney 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Leif Lindholm 
> > ---
> >  Maintainers.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index 0dd5b3743..6477591e6 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -39,9 +39,11 @@ EDK II Packages:
> >  
> > 
> >  Platform
> > +M: Ard Biesheuvel 
> >  M: Leif Lindholm 
> >  M: Michael D Kinney 
> > 
> >  Silicon
> > +M: Ard Biesheuvel 
> >  M: Leif Lindholm 
> >  M: Michael D Kinney 
> > --
> > 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 03/23] OvmfPkg/VirtioPciDeviceDxe: implement IOMMU-like member functions

[Brijesh Singh]

The patch implements the newly added IOMMU-like member functions by
respectively delegating the job to:

- VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages () ->
MemoryAllocationLib.AllocatePages()

- VIRTIO_DEVICE_PROTOCOL.FreeSharedPages () ->
MemoryAllocationLib.FreePages ()

- VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer () -> no-op

- VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer () -> no-op

Suggested-by: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h| 34 
 OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c|  7 ++-
 OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c | 58 
 3 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h 
b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h
index 6f51f816ef0f..41df5a98e560 100644
--- a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h
+++ b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h
@@ -3,6 +3,7 @@
   Internal definitions for the VirtIo PCI Device driver
 
   Copyright (C) 2013, ARM Ltd
+  Copyright (c) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -156,4 +157,37 @@ VirtioPciSetDeviceStatus (
   IN  UINT8  DeviceStatus
   );
 
+EFI_STATUS
+EFIAPI
+VirtioPciAllocateSharedPages (
+  IN  VIRTIO_DEVICE_PROTOCOL*This,
+  IN  UINTN NumPages,
+  OUT VOID  **HostAddress
+  );
+
+VOID
+EFIAPI
+VirtioPciFreeSharedPages (
+  IN  VIRTIO_DEVICE_PROTOCOL*This,
+  IN  UINTN NumPages,
+  IN  VOID  *HostAddress
+  );
+
+EFI_STATUS
+EFIAPI
+VirtioPciMapSharedBuffer (
+  IN  VIRTIO_DEVICE_PROTOCOL*This,
+  IN  VIRTIO_MAP_OPERATION  Operation,
+  IN  VOID  *HostAddress,
+  IN OUT  UINTN *NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
+  OUT VOID  **Mapping
+  );
+
+EFI_STATUS
+EFIAPI
+VirtioPciUnmapSharedBuffer (
+  IN  VIRTIO_DEVICE_PROTOCOL*This,
+  IN  VOID  *Mapping
+  );
 #endif // _VIRTIO_PCI_DEVICE_DXE_H_
diff --git a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c 
b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c
index 8aae58e8b482..d4b4ec21c34d 100644
--- a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c
+++ b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c
@@ -5,6 +5,7 @@
   Copyright (C) 2012, Red Hat, Inc.
   Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
   Copyright (C) 2013, ARM Ltd.
+  Copyright (C) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -40,7 +41,11 @@ STATIC VIRTIO_DEVICE_PROTOCOL mDeviceProtocolTemplate = {
   VirtioPciGetDeviceStatus, // GetDeviceStatus
   VirtioPciSetDeviceStatus, // SetDeviceStatus
   VirtioPciDeviceWrite, // WriteDevice
-  VirtioPciDeviceRead   // ReadDevice
+  VirtioPciDeviceRead,  // ReadDevice
+  VirtioPciAllocateSharedPages, // AllocateSharedPages
+  VirtioPciFreeSharedPages, // FreeSharedPages
+  VirtioPciMapSharedBuffer, // MapSharedBuffer
+  VirtioPciUnmapSharedBuffer,   // UnmapSharedBuffer
 };
 
 /**
diff --git a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c 
b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c
index 5f86914265ea..bd912cca9b29 100644
--- a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c
+++ b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c
@@ -5,6 +5,7 @@
   Copyright (C) 2012, Red Hat, Inc.
   Copyright (c) 2012, Intel Corporation. All rights reserved.
   Copyright (C) 2013, ARM Ltd.
+  Copyright (C) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -271,3 +272,60 @@ VirtioPciSetDeviceStatus (
   return VirtioPciIoWrite (Dev, VIRTIO_PCI_OFFSET_QUEUE_DEVICE_STATUS,
   sizeof (UINT8), DeviceStatus);
 }
+
+EFI_STATUS
+EFIAPI
+VirtioPciAllocateSharedPages (
+  IN  VIRTIO_DEVICE_PROTOCOL  *This,
+  IN  UINTN   NumPages,
+  OUT VOID**HostAddress
+  )
+{
+  VOID*Buffer;
+
+  Buffer = AllocatePages (NumPages);
+  if (Buffer == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  *HostAddress = Buffer;
+  return EFI_SUCCESS;
+}
+
+VOID
+EFIAPI
+VirtioPciFreeSharedPages (
+  IN  VIRTIO_DEVICE_PROTOCOL  *This,
+  IN  UINTN   NumPages,
+  IN  VOID*HostA

[edk2] [PATCH v3 07/23] OvmfPkg/Virtio: take RingBaseShift in SetQueueAddress()

[Brijesh Singh]

For the case when an IOMMU is used for translating system physical
addresses to DMA bus master addresses, the transport-independent
virtio device drivers will be required to map their VRING areas to
bus addresses with VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() calls.

VirtioRingMap() maps the ring buffer system physical to a bus address.
When an IOMMU is used for translating the address then bus address can
start at a different offset from the system physical address.

- MMIO and legacy virtio transport do not support IOMMU to translate the
  addresses hence RingBaseShift will always be set to zero.

- modern virtio transport supports IOMMU to translate the address, in
  next patch we will update the Virtio10Dxe to use RingBaseShift offset.

Suggested-by: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Include/Protocol/VirtioDevice.h | 19 
+--
 OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h  |  3 ++-
 OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h|  3 ++-
 OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c |  5 -
 OvmfPkg/Virtio10Dxe/Virtio10.c  |  5 -
 OvmfPkg/VirtioBlkDxe/VirtioBlk.c|  2 +-
 OvmfPkg/VirtioGpuDxe/Commands.c |  6 +-
 OvmfPkg/VirtioNetDxe/SnpInitialize.c|  2 +-
 OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c |  5 -
 OvmfPkg/VirtioRngDxe/VirtioRng.c|  2 +-
 OvmfPkg/VirtioScsiDxe/VirtioScsi.c  |  2 +-
 11 files changed, 42 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/Include/Protocol/VirtioDevice.h 
b/OvmfPkg/Include/Protocol/VirtioDevice.h
index 9a01932958a2..2e3a6d6edf04 100644
--- a/OvmfPkg/Include/Protocol/VirtioDevice.h
+++ b/OvmfPkg/Include/Protocol/VirtioDevice.h
@@ -156,7 +156,21 @@ EFI_STATUS
   @param[in] This This instance of VIRTIO_DEVICE_PROTOCOL
 
   @param[in] Ring The initialized VRING object to take the
-  addresses from.
+  addresses from. The caller is responsible for
+  ensuring that on input, all Ring->NumPages pages,
+  starting at Ring->Base, have been successfully
+  mapped with a single call to
+  This->MapSharedBuffer() for CommonBuffer bus
+  master operation..
+
+  @param[in] RingBaseShiftAdding this value using UINT64 arithmetic to the
+  addresses found in Ring translates them from
+  system memory to bus addresses. The caller shall
+  calculate RingBaseShift as
+  (DeviceAddress - (UINT64)(UINTN)HostAddress),
+  where DeviceAddress and HostAddress (i.e.,
+  Ring->Base) were output and input parameters of
+  This->MapSharedBuffer(), respectively.
 
   @retval EFI_SUCCESS The data was written successfully.
   @retval EFI_UNSUPPORTED The underlying IO device doesn't support the
@@ -166,7 +180,8 @@ typedef
 EFI_STATUS
 (EFIAPI *VIRTIO_SET_QUEUE_ADDRESS) (
   IN VIRTIO_DEVICE_PROTOCOL  *This,
-  IN VRING   *Ring
+  IN VRING   *Ring,
+  IN UINT64  RingBaseShift
   );
 
 /**
diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h 
b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h
index e5881d537f09..e6279159f8ba 100644
--- a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h
+++ b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h
@@ -115,7 +115,8 @@ VirtioMmioSetQueueSel (
 EFI_STATUS
 VirtioMmioSetQueueAddress (
   IN VIRTIO_DEVICE_PROTOCOL  *This,
-  IN VRING   *Ring
+  IN VRING   *Ring,
+  IN UINT64  RingBaseShift
   );
 
 EFI_STATUS
diff --git a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h 
b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h
index 41df5a98e560..1f0dc45d501e 100644
--- a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h
+++ b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h
@@ -126,7 +126,8 @@ EFI_STATUS
 EFIAPI
 VirtioPciSetQueueAddress (
   IN VIRTIO_DEVICE_PROTOCOL  *This,
-  IN VRING   *Ring
+  IN VRING   *Ring,
+  IN UINT64  RingBaseShift
   );
 
 EFI_STATUS
diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c 
b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
index 644ec65e1788..67458e56231b 100644
--- a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
+++ b/OvmfPkg/Lib

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

[Brijesh Singh]

Currently, virtio drivers provides the system physical address to the device.
However, some systems may feature an IOMMU that requires the drivers to pass
the device addresses to the device - which are then translated by the IOMMU 
into physical addresses in memory. The patch series introduces new member
functions in VIRTIO_DEVICE_PROTOCOL which can be used for mapping a system
physical address to device address.

The approach that this patch series takes is to maps the system physical
address to device address for buffers (including rings, device specifc
request and response  pointed by vring descriptor, and any further memory 
reference by those request and response).

Patch 1 - 4:
 Defines and implements new member functions to map a system physical address
 to device address. The patch implements Laszlo's suggestion [1].

[1] 841bec5f-6f6e-8b1f-25ba-0fd37a915b72@redhat.com">http://mid.mail-archive.com/841bec5f-6f6e-8b1f-25ba-0fd37a915b72@redhat.com

Patch 5 - 12:
 Add some helper functions and allocate the vring using newly added member
 functions.

Patch 13:
 Update the virtio-rng driver to use newly added member functions to map the
 addresses.
 Verified using the following qemu cli

 # $QEMU \
-device virtio-rng-pci

 # $QEMU \
-device virtio-rng-pci,disable-legacy=on

 # $QEMU \
-device virtio-rng-pci,disable-legacy=on,iommu_platform=true

 And succesfully ran RngTest.efi from SecurityPkg/Application and also
 verified that /dev/hwrng get created after Linux guest boot

Patch 14:
 Update the virtio-blk driver to use newly added member functions to map the
 addresses.
 Verified using the following qemu cli

 # $QEMU \
-drive file=${IMAGE},if=none,id=disk0 \
-device virtio-blk-pci,drive=disk0

 # $QEMU \
-drive file=${IMAGE},if=none,id=disk0 \
-device virtio-blk-pci,drive=disk0,disable-legacy=on

 # $QEMU \
-drive file=${IMAGE},if=none,id=disk0 \
-device virtio-blk-pci,drive=disk0,disable-legacy=on,iommu_platform=true

Patch 15:
 Update the virtio-scsi driver to use newly added member functions to map the
 addresses.
 Verified using the following qemu cli

 # $QEMU \
-drive file=${IMAGE},if=none,id=disk0 \
-device scsi-hd,drive=disk0 \
-device virtio-scsi-pci,id=scsi 

 # $QEMU \
-drive file=${IMAGE},if=none,id=disk0 \
-device scsi-hd,drive=disk0 \
-device virtio-scsi-pci,id=scsi,disable-legacy=on 

 # $QEMU \
-drive file=${IMAGE},if=none,id=disk0 \
-device scsi-hd,drive=disk0 \
-device virtio-scsi-pci,id=scsi,disable-legacy=on,iommu_platform=true

Patch 16 - 19:
 Update the virtio-net driver to use newly added member functions to map the
 addresses.
 Verified using the following qemu cli

 # $QEMU \
-netdev type=tap,id=net0 \
-device virtio-net-pci,netdev=net0,romfile=

 # $QEMU \
-netdev type=tap,id=net0 \
-device virtio-net-pci,netdev=net0,disable-legacy=on,romfile=

 # $QEMU \
-netdev type=tap,id=net0 \
-device 
virtio-net-pci,netdev=net0,disable-legacy=on,iommu_platform=true,romfile=

Patch 20 - 23:
 Add support for VIRTIO_F_IOMMU_FEATURE bit

Repo: https://github.com/codomania/edk2
Branch: virtio-support-v3

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 

TODO:
 * add VirtioGpuDxe (i will take Laszlo's offer that he can help with this 
driver)
 * I did minimal test on aarch64 - I was running into some Linux
   bootup issues with Fedora aarch64 iso. The issue does not appear to
   be releated to virtio changes. If anyone can help doing additional
   test with their aarch images that will be great ! thanks

Changes since v2:
 * changes to address v2 feedbacks
 * split the iommu_platform support into multiple patches

Changes since v1:
 * changes to address v1 feedbacks
 * add VIRTIO_F_IOMMU_PLATFORM feature bit

Brijesh Singh (23):
  OvmfPkg: introduce IOMMU-like member functions to
VIRTIO_DEVICE_PROTOCOL
  OvmfPkg/Virtio10Dxe: implement IOMMU-like member functions
  OvmfPkg/VirtioPciDeviceDxe: implement IOMMU-like member functions
  OvmfPkg/VirtioMmioDeviceLib: implement IOMMU-like member functions
  OvmfPkg/VirtioLib: add VirtioMapAllBytesInSharedBuffer() helper
function
  OvmfPkg/VirtioLib: take VirtIo instance in
VirtioRingInit/VirtioRingUninit
  OvmfPkg/Virtio: take RingBaseShift in SetQueueAddress()
  OvmfPkg/Virtio10Dxe: add the RingBaseShift offset
  OvmfPkg/VirtioLib: add function to map VRING
  OvmfPkg/VirtioLib: alloc VRING buffer with AllocateSharedPages()
  OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to
UINT64
  OvmfPkg/VirtioRngDxe: map host address to device address
  OvmfPkg/VirtioBlkDxe: map host address to device address
  OvmfPkg/VirtioScsiDxe: map host address to device address
  OvmfPkg/VirtioNetDxe: alloc Tx and Rx rings using AllocateSharedPage()
  OvmfPkg/VirtioNetDxe: alloc RxBuf using AllocateSharedPages()
  OvmfPkg/VirtioNetDxe: dynamically alloc transmit header
  OvmfPkg/VirtioNetDxe: map transmit buffer host addr

[edk2] [PATCH v3 08/23] OvmfPkg/Virtio10Dxe: add the RingBaseShift offset

[Brijesh Singh]

virtio drivers use VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() to map the
ring buffer host address to a device address. If an IOMMU is present then
RingBaseShift contains the offset from the host address.

Suggested-by: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Virtio10Dxe/Virtio10.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Virtio10Dxe/Virtio10.c b/OvmfPkg/Virtio10Dxe/Virtio10.c
index ef9a00710668..e9b50b6e437b 100644
--- a/OvmfPkg/Virtio10Dxe/Virtio10.c
+++ b/OvmfPkg/Virtio10Dxe/Virtio10.c
@@ -498,11 +498,10 @@ Virtio10SetQueueAddress (
   UINT64 Address;
   UINT16 Enable;
 
-  ASSERT (RingBaseShift == 0);
-
   Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
 
   Address = (UINTN)Ring->Desc;
+  Address += RingBaseShift;
   Status = Virtio10Transfer (Dev->PciIo, &Dev->CommonConfig, TRUE,
  OFFSET_OF (VIRTIO_PCI_COMMON_CFG, QueueDesc),
  sizeof Address, &Address);
@@ -511,6 +510,7 @@ Virtio10SetQueueAddress (
   }
 
   Address = (UINTN)Ring->Avail.Flags;
+  Address += RingBaseShift;
   Status = Virtio10Transfer (Dev->PciIo, &Dev->CommonConfig, TRUE,
  OFFSET_OF (VIRTIO_PCI_COMMON_CFG, QueueAvail),
  sizeof Address, &Address);
@@ -519,6 +519,7 @@ Virtio10SetQueueAddress (
   }
 
   Address = (UINTN)Ring->Used.Flags;
+  Address += RingBaseShift;
   Status = Virtio10Transfer (Dev->PciIo, &Dev->CommonConfig, TRUE,
  OFFSET_OF (VIRTIO_PCI_COMMON_CFG, QueueUsed),
  sizeof Address, &Address);
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 01/23] OvmfPkg: introduce IOMMU-like member functions to VIRTIO_DEVICE_PROTOCOL

[Brijesh Singh]

The patch extends VIRTIO_DEVICE_PROTOCOL to provide the following new
member functions:

- AllocateSharedPages : allocate a memory region suitable for sharing
   between guest and hypervisor (e.g ring buffer).

- FreeSharedPages: free the memory allocated using AllocateSharedPages ().

- MapSharedBuffer: map a host address to device address suitable to share
   with device for bus master operations.

- UnmapSharedBuffer: unmap the device address obtained through the
   MapSharedBuffer().

We're free to extend the protocol structure without changing the protocol
GUID, or bumping any protocol version fields (of which we currently have
none), because VIRTIO_DEVICE_PROTOCOL is internal to edk2 by design --
see the disclaimers in "VirtioDevice.h".

The patch implements Laszlo's recommendation [1].

[1] 841bec5f-6f6e-8b1f-25ba-0fd37a915b72@redhat.com">http://mid.mail-archive.com/841bec5f-6f6e-8b1f-25ba-0fd37a915b72@redhat.com

Suggested-by: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Include/Protocol/VirtioDevice.h | 143 
 1 file changed, 143 insertions(+)

diff --git a/OvmfPkg/Include/Protocol/VirtioDevice.h 
b/OvmfPkg/Include/Protocol/VirtioDevice.h
index fc166bd1a2b4..9a01932958a2 100644
--- a/OvmfPkg/Include/Protocol/VirtioDevice.h
+++ b/OvmfPkg/Include/Protocol/VirtioDevice.h
@@ -5,6 +5,7 @@
   and should not be used outside of the EDK II tree.
 
   Copyright (c) 2013, ARM Ltd. All rights reserved.
+  Copyright (c) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -33,6 +34,25 @@
 
 typedef struct _VIRTIO_DEVICE_PROTOCOL  VIRTIO_DEVICE_PROTOCOL;
 
+//
+// VIRTIO Operation for VIRTIO_MAP_SHARED
+//
+typedef enum {
+  //
+  // A read operation from system memory by a bus master
+  //
+  VirtioOperationBusMasterRead,
+  //
+  // A write operation to system memory by a bus master
+  //
+  VirtioOperationBusMasterWrite,
+  //
+  // Provides both read and write access to system memory by both the
+  // processor and a bus master
+  //
+  VirtioOperationBusMasterCommonBuffer,
+} VIRTIO_MAP_OPERATION;
+
 /**
 
   Read a word from the device-specific I/O region of the Virtio Header.
@@ -321,6 +341,121 @@ EFI_STATUS
   IN UINT8   DeviceStatus
   );
 
+/**
+
+  Allocates pages that are suitable for an VirtioOperationBusMasterCommonBuffer
+  mapping. This means that the buffer allocated by this function supports
+  simultaneous access by both the processor and the bus master. The device
+  address that the bus master uses to access the buffer must be retrieved with
+  a call to VIRTIO_MAP_SHARED.
+
+  @param[in]  This  The protocol instance pointer.
+
+  @param[in]  Pages The number of pages to allocate.
+
+  @param[in,out]  HostAddress   A pointer to store the system memory base
+address of the allocated range.
+
+  @retval EFI_SUCCESS   The requested memory pages were allocated.
+  @retval EFI_OUT_OF_RESOURCES  The memory pages could not be allocated.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *VIRTIO_ALLOCATE_SHARED)(
+  IN VIRTIO_DEVICE_PROTOCOL   *This,
+  IN UINTNPages,
+  IN OUT VOID **HostAddress
+  );
+
+/**
+  Frees memory that was allocated with VIRTIO_ALLOCATE_SHARED.
+
+  @param[in]  This   The protocol instance pointer.
+
+  @param[in]  Pages  The number of pages to free.
+
+  @param[in]  HostAddressThe system memory base address of the allocated
+ range.
+
+**/
+typedef
+VOID
+(EFIAPI *VIRTIO_FREE_SHARED)(
+  IN  VIRTIO_DEVICE_PROTOCOL   *This,
+  IN  UINTNPages,
+  IN  VOID *HostAddress
+  );
+
+/**
+  Provides the virtio device address required to access system memory from a
+  DMA bus master.
+
+  The interface follows the same usage pattern as defined in UEFI spec 2.6
+  (Section 13.2 PCI Root Bridge I/O Protocol)
+
+  @param[in] This The protocol instance pointer.
+
+  @param[in] OperationIndicates if the bus master is going to
+  read or write to system memory.
+
+  @param[in] HostAddress  The system memory address to map to shared
+  buffer address.
+
+  @param[in,out] NumberOfBytesOn input the number of bytes to map.
+  On output the number of bytes that were
+  mapped.
+
+  @param[out]DeviceAddressThe resulting shared map address for the
+  bus master to access th

[edk2] [PATCH v3 10/23] OvmfPkg/VirtioLib: alloc VRING buffer with AllocateSharedPages()

[Brijesh Singh]

The VRING buffer is a communication area between guest and hypervisor.
Allocate it using VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages() so that
it can be mapped later with VirtioRingMap() for bi-directional access.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Library/VirtioLib/VirtioLib.inf |  1 -
 OvmfPkg/Include/Library/VirtioLib.h |  5 ++---
 OvmfPkg/Library/VirtioLib/VirtioLib.c   | 22 +---
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.inf 
b/OvmfPkg/Library/VirtioLib/VirtioLib.inf
index fb5897a88ecf..e33856de38c4 100644
--- a/OvmfPkg/Library/VirtioLib/VirtioLib.inf
+++ b/OvmfPkg/Library/VirtioLib/VirtioLib.inf
@@ -32,5 +32,4 @@ [LibraryClasses]
   BaseLib
   BaseMemoryLib
   DebugLib
-  MemoryAllocationLib
   UefiBootServicesTableLib
diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
b/OvmfPkg/Include/Library/VirtioLib.h
index 3d9314b3acaf..c3e56ea23b89 100644
--- a/OvmfPkg/Include/Library/VirtioLib.h
+++ b/OvmfPkg/Include/Library/VirtioLib.h
@@ -42,9 +42,8 @@
 
   @param[out] Ring  The virtio ring to set up.
 
-  @retval EFI_OUT_OF_RESOURCES  AllocatePages() failed to allocate contiguous
-pages for the requested QueueSize. Fields of
-Ring have indeterminate value.
+  @retval   Status codes propagated from
+VirtIo->AllocateSharedPages().
 
   @retval EFI_SUCCESS   Allocation and setup successful. Ring->Base
 (and nothing else) is responsible for
diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
b/OvmfPkg/Library/VirtioLib/VirtioLib.c
index 535635ac0ba8..e5366e385f5d 100644
--- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
+++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -44,9 +43,8 @@
 
   @param[out] Ring  The virtio ring to set up.
 
-  @retval EFI_OUT_OF_RESOURCES  AllocatePages() failed to allocate contiguous
-pages for the requested QueueSize. Fields of
-Ring have indeterminate value.
+  @retval   Status codes propagated from
+VirtIo->AllocateSharedPages().
 
   @retval EFI_SUCCESS   Allocation and setup successful. Ring->Base
 (and nothing else) is responsible for
@@ -61,6 +59,7 @@ VirtioRingInit (
   OUT VRING  *Ring
   )
 {
+  EFI_STATUS Status;
   UINTN  RingSize;
   volatile UINT8 *RingPagesPtr;
 
@@ -79,10 +78,17 @@ VirtioRingInit (
 sizeof *Ring->Used.AvailEvent,
 EFI_PAGE_SIZE);
 
+  //
+  // Allocate a shared ring buffer
+  //
   Ring->NumPages = EFI_SIZE_TO_PAGES (RingSize);
-  Ring->Base = AllocatePages (Ring->NumPages);
-  if (Ring->Base == NULL) {
-return EFI_OUT_OF_RESOURCES;
+  Status = VirtIo->AllocateSharedPages (
+ VirtIo,
+ Ring->NumPages,
+ &Ring->Base
+ );
+  if (EFI_ERROR (Status)) {
+return Status;
   }
   SetMem (Ring->Base, RingSize, 0x00);
   RingPagesPtr = Ring->Base;
@@ -143,7 +149,7 @@ VirtioRingUninit (
   IN OUT VRING  *Ring
   )
 {
-  FreePages (Ring->Base, Ring->NumPages);
+  VirtIo->FreeSharedPages (VirtIo, Ring->NumPages, Ring->Base);
   SetMem (Ring, sizeof *Ring, 0x00);
 }
 
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 05/23] OvmfPkg/VirtioLib: add VirtioMapAllBytesInSharedBuffer() helper function

[Brijesh Singh]

The function can be used for mapping the system physical address to virtio
device address using VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer (). The
function helps with centralizing error handling, and it allows the caller
to pass in constant or other evaluated expressions for NumberOfBytes.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Include/Library/VirtioLib.h   | 52 
 OvmfPkg/Library/VirtioLib/VirtioLib.c | 85 
 2 files changed, 137 insertions(+)

diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
b/OvmfPkg/Include/Library/VirtioLib.h
index 5badfb32917f..9ec9b91b59bb 100644
--- a/OvmfPkg/Include/Library/VirtioLib.h
+++ b/OvmfPkg/Include/Library/VirtioLib.h
@@ -3,6 +3,7 @@
   Declarations of utility functions used by virtio device drivers.
 
   Copyright (C) 2012-2016, Red Hat, Inc.
+  Copyright (C) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -235,4 +236,55 @@ Virtio10WriteFeatures (
   IN OUT UINT8  *DeviceStatus
   );
 
+/**
+  Provides the virtio device address required to access system memory from a
+  DMA bus master.
+
+  The interface follows the same usage pattern as defined in UEFI spec 2.6
+  (Section 13.2 PCI Root Bridge I/O Protocol)
+
+  The VirtioMapAllBytesInSharedBuffer() is similar to VIRTIO_MAP_SHARED
+  with exception that NumberOfBytes is IN-only parameter. The function
+  maps all the bytes specified in NumberOfBytes param in one consecutive
+  range.
+
+  @param[in] This The virtio device for which the mapping is
+  requested.
+
+  @param[in] OperationIndicates if the bus master is going to
+  read or write to system memory.
+
+  @param[in] HostAddress  The system memory address to map to shared
+  buffer address.
+
+  @param[in] NumberOfBytesNumber of bytes to map.
+
+  @param[out]DeviceAddressThe resulting shared map address for the
+  bus master to access the hosts HostAddress.
+
+  @param[out]Mapping  A resulting token to pass to
+  VIRTIO_UNMAP_SHARED.
+
+
+  @retval EFI_SUCCESS The NumberOfBytes is succesfully mapped.
+  @retval EFI_UNSUPPORTED The HostAddress cannot be mapped as a
+  common buffer.
+  @retval EFI_INVALID_PARAMETER   One or more parameters are invalid.
+  @retval EFI_OUT_OF_RESOURCESThe request could not be completed due to
+  a lack of resources. This includes the case
+  when NumberOfBytes bytes cannot be mapped
+  in one consecutive range.
+  @retval EFI_DEVICE_ERRORThe system hardware could not map the
+  requested address.
+**/
+EFI_STATUS
+EFIAPI
+VirtioMapAllBytesInSharedBuffer (
+  IN  VIRTIO_DEVICE_PROTOCOL  *VirtIo,
+  IN  VIRTIO_MAP_OPERATIONOperation,
+  IN  VOID*HostAddress,
+  IN  UINTN   NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS*DeviceAddress,
+  OUT VOID**Mapping
+  );
 #endif // _VIRTIO_LIB_H_
diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
b/OvmfPkg/Library/VirtioLib/VirtioLib.c
index 845f206369a3..c85cd8dba569 100644
--- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
+++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
@@ -4,6 +4,7 @@
 
   Copyright (C) 2012-2016, Red Hat, Inc.
   Portion of Copyright (C) 2013, ARM Ltd.
+  Copyright (C) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -414,3 +415,87 @@ Virtio10WriteFeatures (
 
   return Status;
 }
+
+/**
+  Provides the virtio device address required to access system memory from a
+  DMA bus master.
+
+  The interface follows the same usage pattern as defined in UEFI spec 2.6
+  (Section 13.2 PCI Root Bridge I/O Protocol)
+
+  The VirtioMapAllBytesInSharedBuffer() is similar to VIRTIO_MAP_SHARED
+  with exception that NumberOfBytes is IN-only parameter. The function
+  maps all the bytes specified in NumberOfBytes param in one consecutive
+  range.
+
+  @param[in] This The virtio device for which the mapping is
+  requested.
+
+  @param[in] OperationIndicates if the bus master is going to
+  read or write to system memory.
+
+  @param[in] HostAddress  The system memory address to map to shared
+  buffer address.
+
+  @param[in] NumberOf

[edk2] [PATCH v3 12/23] OvmfPkg/VirtioRngDxe: map host address to device address

[Brijesh Singh]

patch maps the host address to a device address for buffers (including
rings, device specifc request and response pointed by vring descriptor,
and any further memory reference by those request and response).

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioRngDxe/VirtioRng.h |  1 +
 OvmfPkg/VirtioRngDxe/VirtioRng.c | 82 +---
 2 files changed, 74 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/VirtioRngDxe/VirtioRng.h b/OvmfPkg/VirtioRngDxe/VirtioRng.h
index 998f9fae48c2..389c8ddc8d31 100644
--- a/OvmfPkg/VirtioRngDxe/VirtioRng.h
+++ b/OvmfPkg/VirtioRngDxe/VirtioRng.h
@@ -38,6 +38,7 @@ typedef struct {
   EFI_EVENT ExitBoot;   // DriverBindingStart   0
   VRING Ring;   // VirtioRingInit   2
   EFI_RNG_PROTOCOL  Rng;// VirtioRngInit1
+  VOID  *RingMap;   // VirtioRingMap2
 } VIRTIO_RNG_DEV;
 
 #define VIRTIO_ENTROPY_SOURCE_FROM_RNG(RngPointer) \
diff --git a/OvmfPkg/VirtioRngDxe/VirtioRng.c b/OvmfPkg/VirtioRngDxe/VirtioRng.c
index 0abca488e6cd..59f32d343179 100644
--- a/OvmfPkg/VirtioRngDxe/VirtioRng.c
+++ b/OvmfPkg/VirtioRngDxe/VirtioRng.c
@@ -140,6 +140,8 @@ VirtioRngGetRNG (
   UINT32Len;
   UINT32BufferSize;
   EFI_STATUSStatus;
+  EFI_PHYSICAL_ADDRESS  DeviceAddress;
+  VOID  *Mapping;
 
   if (This == NULL || RNGValueLength == 0 || RNGValue == NULL) {
 return EFI_INVALID_PARAMETER;
@@ -159,6 +161,20 @@ VirtioRngGetRNG (
   }
 
   Dev = VIRTIO_ENTROPY_SOURCE_FROM_RNG (This);
+  //
+  // Map Buffer's system phyiscal address to device address
+  //
+  Status = VirtioMapAllBytesInSharedBuffer (
+ Dev->VirtIo,
+ VirtioOperationBusMasterWrite,
+ (VOID *)Buffer,
+ RNGValueLength,
+ &DeviceAddress,
+ &Mapping
+ );
+  if (EFI_ERROR (Status)) {
+goto FreeBuffer;
+  }
 
   //
   // The Virtio RNG device may return less data than we asked it to, and can
@@ -170,7 +186,7 @@ VirtioRngGetRNG (
 
 VirtioPrepare (&Dev->Ring, &Indices);
 VirtioAppendDesc (&Dev->Ring,
-  (UINTN)Buffer + Index,
+  DeviceAddress + Index,
   BufferSize,
   VRING_DESC_F_WRITE,
   &Indices);
@@ -178,17 +194,35 @@ VirtioRngGetRNG (
 if (VirtioFlush (Dev->VirtIo, 0, &Dev->Ring, &Indices, &Len) !=
 EFI_SUCCESS) {
   Status = EFI_DEVICE_ERROR;
-  goto FreeBuffer;
+  goto UnmapBuffer;
 }
 ASSERT (Len > 0);
 ASSERT (Len <= BufferSize);
   }
 
+  //
+  // Unmap the device buffer before accessing it.
+  //
+  Status = Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Mapping);
+  if (EFI_ERROR (Status)) {
+Status = EFI_DEVICE_ERROR;
+goto FreeBuffer;
+  }
+
   for (Index = 0; Index < RNGValueLength; Index++) {
 RNGValue[Index] = Buffer[Index];
   }
   Status = EFI_SUCCESS;
 
+UnmapBuffer:
+  //
+  // If we are reached here due to the error then unmap the buffer otherwise
+  // the buffer is already unmapped after VirtioFlush().
+  //
+  if (EFI_ERROR (Status)) {
+Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Mapping);
+  }
+
 FreeBuffer:
   FreePool ((VOID *)Buffer);
   return Status;
@@ -205,6 +239,7 @@ VirtioRngInit (
   EFI_STATUS Status;
   UINT16 QueueSize;
   UINT64 Features;
+  UINT64 RingBaseShift;
 
   //
   // Execute virtio-0.9.5, 2.2.1 Device Initialization Sequence.
@@ -282,25 +317,42 @@ VirtioRngInit (
   }
 
   //
+  // If anything fails from here on, we must release the ring resources.
+  //
+  Status = VirtioRingMap (
+ Dev->VirtIo,
+ &Dev->Ring,
+ &RingBaseShift,
+ &Dev->RingMap
+ );
+  if (EFI_ERROR (Status)) {
+goto ReleaseQueue;
+  }
+
+  //
   // Additional steps for MMIO: align the queue appropriately, and set the
-  // size. If anything fails from here on, we must release the ring resources.
+  // size. If anything fails from here on, we must unmap the ring resources.
   //
   Status = Dev->VirtIo->SetQueueNum (Dev->VirtIo, QueueSize);
   if (EFI_ERROR (Status)) {
-goto ReleaseQueue;
+goto UnmapQueue;
   }
 
   Status = Dev->VirtIo->SetQueueAlign (Dev->VirtIo, EFI_PAGE_SIZE);
   if (EFI_ERROR (Status)) {
-goto ReleaseQueue;
+goto UnmapQueue;
   }
 
   //
   // step 4c -- Report GPFN (guest-physical frame number) of queue.
   //
-  Status = Dev->VirtIo->SetQueueAddress (Dev->VirtIo, &Dev->Ring, 0);
+  Status = Dev->VirtIo->SetQueueAddress (
+  Dev->VirtIo,
+  &Dev->Ring,
+  RingBaseShift
+  );
   if (EFI_ERROR (Status)) {
-goto ReleaseQueue;
+goto UnmapQueue;
   }
 
   //
@@ -310,7 +362,7 @@ VirtioRngInit (
 Features &= ~(UINT64)VI

[edk2] [PATCH v3 15/23] OvmfPkg/VirtioNetDxe: alloc Tx and Rx rings using AllocateSharedPage()

[Brijesh Singh]

The Tx and Rx rings are accessed by both guest and hypervisor, allocate
the rings using newly added VirtIo->AllocateSharedPages() and map it with
BusMasterCommonBuffer so that it can be accessed by both guest and
hypervisor.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioNetDxe/VirtioNet.h |  2 +
 OvmfPkg/VirtioNetDxe/Events.c|  7 
 OvmfPkg/VirtioNetDxe/SnpInitialize.c | 40 
 OvmfPkg/VirtioNetDxe/SnpShutdown.c   |  2 +
 4 files changed, 43 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/VirtioNetDxe/VirtioNet.h b/OvmfPkg/VirtioNetDxe/VirtioNet.h
index 710859bc6115..d80d441b50a4 100644
--- a/OvmfPkg/VirtioNetDxe/VirtioNet.h
+++ b/OvmfPkg/VirtioNetDxe/VirtioNet.h
@@ -82,10 +82,12 @@ typedef struct {
   EFI_HANDLE  MacHandle; // VirtioNetDriverBindingStart
 
   VRING   RxRing;// VirtioNetInitRing
+  VOID*RxRingMap;// VirtioRingMap
   UINT8   *RxBuf;// VirtioNetInitRx
   UINT16  RxLastUsed;// VirtioNetInitRx
 
   VRING   TxRing;// VirtioNetInitRing
+  VOID*TxRingMap;// VirtioRingMap
   UINT16  TxMaxPending;  // VirtioNetInitTx
   UINT16  TxCurPending;  // VirtioNetInitTx
   UINT16  *TxFreeStack;  // VirtioNetInitTx
diff --git a/OvmfPkg/VirtioNetDxe/Events.c b/OvmfPkg/VirtioNetDxe/Events.c
index 5be1af6ffbee..6950c4d56df1 100644
--- a/OvmfPkg/VirtioNetDxe/Events.c
+++ b/OvmfPkg/VirtioNetDxe/Events.c
@@ -88,4 +88,11 @@ VirtioNetExitBoot (
   if (Dev->Snm.State == EfiSimpleNetworkInitialized) {
 Dev->VirtIo->SetDeviceStatus (Dev->VirtIo, 0);
   }
+
+  //
+  // Unmap Tx and Rx rings so that hypervisor will not be able get readable 
data
+  // after device is reset.
+  //
+  Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Dev->TxRingMap);
+  Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Dev->RxRingMap);
 }
diff --git a/OvmfPkg/VirtioNetDxe/SnpInitialize.c 
b/OvmfPkg/VirtioNetDxe/SnpInitialize.c
index 0ecfe044a977..803a38bd4239 100644
--- a/OvmfPkg/VirtioNetDxe/SnpInitialize.c
+++ b/OvmfPkg/VirtioNetDxe/SnpInitialize.c
@@ -35,11 +35,13 @@
the network device.
   @param[out]Ring  The virtio-ring inside the VNET_DEV structure,
corresponding to Selector.
+  @param[out]Mapping   A token return from the VirtioRingMap().
 
   @retval EFI_UNSUPPORTED  The queue size reported by the virtio-net device is
too small.
   @return  Status codes from VIRTIO_CFG_WRITE(),
-   VIRTIO_CFG_READ() and VirtioRingInit().
+   VIRTIO_CFG_READ(), VirtioRingInit() and
+   VirtioRingMap().
   @retval EFI_SUCCESS  Ring initialized.
 */
 
@@ -49,11 +51,13 @@ EFIAPI
 VirtioNetInitRing (
   IN OUT VNET_DEV *Dev,
   IN UINT16   Selector,
-  OUTVRING*Ring
+  OUTVRING*Ring,
+  OUTVOID **Mapping
   )
 {
   EFI_STATUS Status;
   UINT16 QueueSize;
+  UINT64 RingBaseShift;
 
   //
   // step 4b -- allocate selected queue
@@ -79,30 +83,38 @@ VirtioNetInitRing (
 return Status;
   }
 
+  Status = VirtioRingMap (Dev->VirtIo, Ring, &RingBaseShift, Mapping);
+  if (EFI_ERROR (Status)) {
+goto ReleaseQueue;
+  }
+
   //
   // Additional steps for MMIO: align the queue appropriately, and set the
   // size. If anything fails from here on, we must release the ring resources.
   //
   Status = Dev->VirtIo->SetQueueNum (Dev->VirtIo, QueueSize);
   if (EFI_ERROR (Status)) {
-goto ReleaseQueue;
+goto UnmapQueue;
   }
 
   Status = Dev->VirtIo->SetQueueAlign (Dev->VirtIo, EFI_PAGE_SIZE);
   if (EFI_ERROR (Status)) {
-goto ReleaseQueue;
+goto UnmapQueue;
   }
 
   //
   // step 4c -- report GPFN (guest-physical frame number) of queue
   //
-  Status = Dev->VirtIo->SetQueueAddress (Dev->VirtIo, Ring, 0);
+  Status = Dev->VirtIo->SetQueueAddress (Dev->VirtIo, Ring, RingBaseShift);
   if (EFI_ERROR (Status)) {
-goto ReleaseQueue;
+goto UnmapQueue;
   }
 
   return EFI_SUCCESS;
 
+UnmapQueue:
+  Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Mapping);
+
 ReleaseQueue:
   VirtioRingUninit (Dev->VirtIo, Ring);
 
@@ -456,12 +468,22 @@ VirtioNetInitialize (
   //
   // step 4b, 4c -- allocate and report virtqueues
   //
-  Status = VirtioNetInitRing (Dev, VIRTIO_NET_Q_RX, &Dev->RxRing);
+  Status = VirtioNetInitRing (
+ Dev,
+ VIRTIO_NET_Q_RX,
+ &Dev->RxRing,
+ &Dev->RxRingMap
+ );
   if (EFI_ERROR (Status)) {
 goto DeviceFailed;
   }
 
-  Status = VirtioNetInitRing (Dev, VIRTIO_NET_Q_TX, &Dev->TxRing);
+  Status = 

[edk2] [PATCH v3 04/23] OvmfPkg/VirtioMmioDeviceLib: implement IOMMU-like member functions

[Brijesh Singh]

The patch implements the newly added IOMMU-like member functions by
respectively delegating the job to:

- VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages () ->
MemoryAllocationLib.AllocatePages()

- VIRTIO_DEVICE_PROTOCOL.FreeSharedPages () ->
MemoryAllocationLib.FreePages ()

- VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer () -> no-op

- VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer () -> no-op

Suggested-by: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h  | 36 
+
 OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c  |  8 ++-
 OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c | 57 

 3 files changed, 99 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h 
b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h
index bedd635e1a86..e5881d537f09 100644
--- a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h
+++ b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h
@@ -3,6 +3,7 @@
   Internal definitions for the VirtIo MMIO Device driver
 
   Copyright (C) 2013, ARM Ltd
+  Copyright (C) 2017, AMD Inc. All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define VIRTIO_MMIO_DEVICE_SIGNATURE  SIGNATURE_32 ('V', 'M', 'I', 'O')
 
@@ -137,4 +139,38 @@ VirtioMmioSetGuestFeatures (
   IN UINT64  Features
   );
 
+EFI_STATUS
+EFIAPI
+VirtioMmioAllocateSharedPages (
+  IN  VIRTIO_DEVICE_PROTOCOL*This,
+  IN  UINTN NumPages,
+  OUT VOID  **HostAddress
+  );
+
+VOID
+EFIAPI
+VirtioMmioFreeSharedPages (
+  IN  VIRTIO_DEVICE_PROTOCOL*This,
+  IN  UINTN NumPages,
+  IN  VOID  *HostAddress
+  );
+
+EFI_STATUS
+EFIAPI
+VirtioMmioMapSharedBuffer (
+  IN  VIRTIO_DEVICE_PROTOCOL*This,
+  IN  VIRTIO_MAP_OPERATION  Operation,
+  IN  VOID  *HostAddress,
+  IN OUT  UINTN *NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
+  OUT VOID  **Mapping
+  );
+
+EFI_STATUS
+EFIAPI
+VirtioMmioUnmapSharedBuffer (
+  IN  VIRTIO_DEVICE_PROTOCOL*This,
+  IN  VOID  *Mapping
+  );
+
 #endif // _VIRTIO_MMIO_DEVICE_INTERNAL_H_
diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c 
b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c
index b1d443ea7007..fce934e1e953 100644
--- a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c
+++ b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c
@@ -3,6 +3,7 @@
   This driver produces Virtio Device Protocol instances for Virtio Mmio 
devices.
 
   Copyright (C) 2013, ARM Ltd.
+  Copyright (C) 2017, AMD Inc. All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -15,7 +16,6 @@
 **/
 
 #include 
-#include 
 #include 
 
 #include "VirtioMmioDevice.h"
@@ -35,7 +35,11 @@ static VIRTIO_DEVICE_PROTOCOL mMmioDeviceProtocolTemplate = {
 VirtioMmioGetDeviceStatus, // GetDeviceStatus
 VirtioMmioSetDeviceStatus, // SetDeviceStatus
 VirtioMmioDeviceWrite, // WriteDevice
-VirtioMmioDeviceRead   // ReadDevice
+VirtioMmioDeviceRead,  // ReadDevice
+VirtioMmioAllocateSharedPages, // AllocateSharedPages
+VirtioMmioFreeSharedPages, // FreeSharedPages
+VirtioMmioMapSharedBuffer, // MapSharedBuffer
+VirtioMmioUnmapSharedBuffer// UnmapSharedBuffer
 };
 
 /**
diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c 
b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
index 9142d4a162c0..644ec65e1788 100644
--- a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
+++ b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
@@ -293,3 +293,60 @@ VirtioMmioDeviceRead (
 
   return EFI_SUCCESS;
 }
+
+EFI_STATUS
+EFIAPI
+VirtioMmioAllocateSharedPages (
+  IN  VIRTIO_DEVICE_PROTOCOL  *This,
+  IN  UINTN   NumPages,
+  OUT VOID**HostAddress
+  )
+{
+  VOID*Buffer;
+
+  Buffer = AllocatePages (NumPages);
+  if (Buffer == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  *HostAddress = Buffer;
+  return EFI_SUCCESS;
+}
+
+VOID
+EFIAPI
+VirtioMmioFreeSharedPages (
+  IN  VIRTIO_DEVICE_PROTOCOL  *This,
+  IN  UINTN   NumPages,
+  IN  VOID*HostAddress

[edk2] [PATCH v3 06/23] OvmfPkg/VirtioLib: take VirtIo instance in VirtioRingInit/VirtioRingUninit

[Brijesh Singh]

Passing the VirtIo protocol instance will allow the vring to use
VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages () to allocate vring buffer.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Reviewed-by: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Include/Library/VirtioLib.h   | 14 ++
 OvmfPkg/Library/VirtioLib/VirtioLib.c | 14 ++
 OvmfPkg/VirtioBlkDxe/VirtioBlk.c  |  7 ---
 OvmfPkg/VirtioGpuDxe/Commands.c   |  7 ---
 OvmfPkg/VirtioNetDxe/SnpInitialize.c  |  9 +
 OvmfPkg/VirtioNetDxe/SnpShutdown.c|  5 +++--
 OvmfPkg/VirtioRngDxe/VirtioRng.c  |  7 ---
 OvmfPkg/VirtioScsiDxe/VirtioScsi.c|  7 ---
 8 files changed, 44 insertions(+), 26 deletions(-)

diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
b/OvmfPkg/Include/Library/VirtioLib.h
index 9ec9b91b59bb..40c51a2b3305 100644
--- a/OvmfPkg/Include/Library/VirtioLib.h
+++ b/OvmfPkg/Include/Library/VirtioLib.h
@@ -35,6 +35,8 @@
   - 1.1 Virtqueues,
   - 2.3 Virtqueue Configuration.
 
+  @param[in]  VirtIoThe virtio device which will use the ring.
+
   @param[in]The number of descriptors to allocate for the
 virtio ring, as requested by the host.
 
@@ -52,8 +54,9 @@
 EFI_STATUS
 EFIAPI
 VirtioRingInit (
-  IN  UINT16 QueueSize,
-  OUT VRING  *Ring
+  IN  VIRTIO_DEVICE_PROTOCOL *VirtIo,
+  IN  UINT16 QueueSize,
+  OUT VRING  *Ring
   );
 
 
@@ -65,13 +68,16 @@ VirtioRingInit (
   invoking this function: the VSTAT_DRIVER_OK bit must be clear in
   VhdrDeviceStatus.
 
-  @param[out] Ring  The virtio ring to clean up.
+  @param[in]  VirtIo  The virtio device which was using the ring.
+
+  @param[out] RingThe virtio ring to clean up.
 
 **/
 VOID
 EFIAPI
 VirtioRingUninit (
-  IN OUT VRING *Ring
+  IN VIRTIO_DEVICE_PROTOCOL *VirtIo,
+  IN OUT VRING  *Ring
   );
 
 
diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
b/OvmfPkg/Library/VirtioLib/VirtioLib.c
index c85cd8dba569..8bc5b9aea4fc 100644
--- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
+++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
@@ -37,6 +37,8 @@
   - 1.1 Virtqueues,
   - 2.3 Virtqueue Configuration.
 
+  @param[in]  VirtIoThe virtio device which will use the ring.
+
   @param[in]The number of descriptors to allocate for the
 virtio ring, as requested by the host.
 
@@ -54,8 +56,9 @@
 EFI_STATUS
 EFIAPI
 VirtioRingInit (
-  IN  UINT16 QueueSize,
-  OUT VRING  *Ring
+  IN  VIRTIO_DEVICE_PROTOCOL *VirtIo,
+  IN  UINT16 QueueSize,
+  OUT VRING  *Ring
   )
 {
   UINTN  RingSize;
@@ -128,13 +131,16 @@ VirtioRingInit (
   invoking this function: the VSTAT_DRIVER_OK bit must be clear in
   VhdrDeviceStatus.
 
-  @param[out] Ring  The virtio ring to clean up.
+  @param[in]  VirtIo  The virtio device which was using the ring.
+
+  @param[out] RingThe virtio ring to clean up.
 
 **/
 VOID
 EFIAPI
 VirtioRingUninit (
-  IN OUT VRING *Ring
+  IN VIRTIO_DEVICE_PROTOCOL *VirtIo,
+  IN OUT VRING  *Ring
   )
 {
   FreePages (Ring->Base, Ring->NumPages);
diff --git a/OvmfPkg/VirtioBlkDxe/VirtioBlk.c b/OvmfPkg/VirtioBlkDxe/VirtioBlk.c
index 3ce72281c204..61b9cab4ff02 100644
--- a/OvmfPkg/VirtioBlkDxe/VirtioBlk.c
+++ b/OvmfPkg/VirtioBlkDxe/VirtioBlk.c
@@ -12,6 +12,7 @@
 
   Copyright (C) 2012, Red Hat, Inc.
   Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -722,7 +723,7 @@ VirtioBlkInit (
 goto Failed;
   }
 
-  Status = VirtioRingInit (QueueSize, &Dev->Ring);
+  Status = VirtioRingInit (Dev->VirtIo, QueueSize, &Dev->Ring);
   if (EFI_ERROR (Status)) {
 goto Failed;
   }
@@ -811,7 +812,7 @@ VirtioBlkInit (
   return EFI_SUCCESS;
 
 ReleaseQueue:
-  VirtioRingUninit (&Dev->Ring);
+  VirtioRingUninit (Dev->VirtIo, &Dev->Ring);
 
 Failed:
   //
@@ -848,7 +849,7 @@ VirtioBlkUninit (
   //
   Dev->VirtIo->SetDeviceStatus (Dev->VirtIo, 0);
 
-  VirtioRingUninit (&Dev->Ring);
+  VirtioRingUninit (Dev->VirtIo, &Dev->Ring);
 
   SetMem (&Dev->BlockIo,  sizeof Dev->BlockIo,  0x00);
   SetMem (&Dev->BlockIoMedia, sizeof Dev->BlockIoMedia, 0x00);
diff --git a/OvmfPkg/VirtioGpuDxe/Commands.c b/OvmfPkg/VirtioGpuDxe/Commands.c
index 962087cfec97..c2e4d72feb67 100644
--- a/OvmfPkg/VirtioGpuDxe/Commands.c
+++ b/OvmfPkg/VirtioGpuDxe/Commands.c
@@ -3,6 +3,7 @@
   VirtIo GPU initialization, and commands (primitives) for the GPU device.
 
   Copyright (C) 2016, Red Hat, Inc.
+  Copyright (c) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   und

[edk2] [PATCH v3 02/23] OvmfPkg/Virtio10Dxe: implement IOMMU-like member functions

[Brijesh Singh]

The patch implements the newly added IOMMU-like member functions by
respectively delegating the job to:

- VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages() ->
EFI_PCI_IO_PROTOCOL.AllocateBuffer()

- VIRTIO_DEVICE_PROTOCOL.FreeSharedPages() ->
EFI_PCI_IO_PROTOCOL.FreeBuffer()

- VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() ->
EFI_PCI_IO_PROTOCOL.Map()

- VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() ->
EFI_PCI_IO_PROTOCOL.Unmap()

Suggested-by: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Virtio10Dxe/Virtio10.c | 122 +++-
 1 file changed, 120 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/Virtio10Dxe/Virtio10.c b/OvmfPkg/Virtio10Dxe/Virtio10.c
index d7ea4432bcb6..89ccac8c1c04 100644
--- a/OvmfPkg/Virtio10Dxe/Virtio10.c
+++ b/OvmfPkg/Virtio10Dxe/Virtio10.c
@@ -2,6 +2,7 @@
   A non-transitional driver for VirtIo 1.0 PCI devices.
 
   Copyright (C) 2016, Red Hat, Inc.
+  Copyright (C) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -15,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -772,6 +774,117 @@ Virtio10ReadDevice (
   return Status;
 }
 
+STATIC
+EFI_STATUS
+EFIAPI
+Virtio10AllocateSharedPages (
+  IN VIRTIO_DEVICE_PROTOCOL  *This,
+  IN UINTN   Pages,
+  IN OUT VOID**HostAddress
+  )
+{
+  VIRTIO_1_0_DEV *Dev;
+  EFI_STATUS Status;
+
+  Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
+
+  Status = Dev->PciIo->AllocateBuffer (
+ Dev->PciIo,
+ AllocateAnyPages,
+ EfiBootServicesData,
+ Pages,
+ HostAddress,
+ EFI_PCI_ATTRIBUTE_MEMORY_CACHED
+ );
+  return Status;
+}
+
+STATIC
+VOID
+EFIAPI
+Virtio10FreeSharedPages (
+  IN  VIRTIO_DEVICE_PROTOCOL  *This,
+  IN  UINTN   Pages,
+  IN  VOID*HostAddress
+  )
+{
+  VIRTIO_1_0_DEV *Dev;
+
+  Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
+
+  Dev->PciIo->FreeBuffer (
+Dev->PciIo,
+Pages,
+HostAddress
+);
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+Virtio10MapSharedBuffer (
+  IN VIRTIO_DEVICE_PROTOCOL  *This,
+  IN VIRTIO_MAP_OPERATIONOperation,
+  IN VOID*HostAddress,
+  IN OUT UINTN   *NumberOfBytes,
+  OUTEFI_PHYSICAL_ADDRESS*DeviceAddress,
+  OUTVOID**Mapping
+  )
+{
+  EFI_STATUSStatus;
+  VIRTIO_1_0_DEV*Dev;
+  EFI_PCI_IO_PROTOCOL_OPERATION PciIoOperation;
+
+  Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
+
+  //
+  // Map VIRTIO_MAP_OPERATION to EFI_PCI_IO_PROTOCOL_OPERATION
+  //
+  switch (Operation) {
+  case VirtioOperationBusMasterRead:
+PciIoOperation = EfiPciIoOperationBusMasterRead;
+break;
+  case VirtioOperationBusMasterWrite:
+PciIoOperation = EfiPciIoOperationBusMasterWrite;
+break;
+  case VirtioOperationBusMasterCommonBuffer:
+PciIoOperation = EfiPciIoOperationBusMasterCommonBuffer;
+break;
+  default:
+return EFI_INVALID_PARAMETER;
+  }
+
+  Status = Dev->PciIo->Map (
+ Dev->PciIo,
+ PciIoOperation,
+ HostAddress,
+ NumberOfBytes,
+ DeviceAddress,
+ Mapping
+ );
+  return Status;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+Virtio10UnmapSharedBuffer (
+  IN  VIRTIO_DEVICE_PROTOCOL  *This,
+  IN  VOID*Mapping
+  )
+{
+  EFI_STATUS  Status;
+  VIRTIO_1_0_DEV  *Dev;
+
+  Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
+
+  Status = Dev->PciIo->Unmap (
+ Dev->PciIo,
+ Mapping
+ );
+
+  return Status;
+}
 
 STATIC CONST VIRTIO_DEVICE_PROTOCOL mVirtIoTemplate = {
   VIRTIO_SPEC_REVISION (1, 0, 0),
@@ -788,7 +901,11 @@ STATIC CONST VIRTIO_DEVICE_PROTOCOL mVirtIoTemplate = {
   Virtio10GetDeviceStatus,
   Virtio10SetDeviceStatus,
   Virtio10WriteDevice,
-  Virtio10ReadDevice
+  Virtio10ReadDevice,
+  Virtio10AllocateSharedPages,
+  Virtio10FreeSharedPages,
+  Virtio10MapSharedBuffer,
+  Virtio10UnmapSharedBuffer
 };
 
 
@@ -906,7 +1023,8 @@ Virtio10BindingStart (
 goto ClosePciIo;
   }
 
-  SetAttributes = EFI_PCI_IO_ATTRIBUTE_BUS_MASTER;
+  SetAttributes = (EFI_PCI_IO_ATTRIBUTE_BUS_MASTER |
+   EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE);
   UpdateAttributes (&Device->CommonConfig, &SetAttributes);
   UpdateAttributes (&Device->NotifyConfig, &SetAttributes);
   UpdateAttributes (&Device->Specifi

[edk2] [PATCH v3 11/23] OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to UINT64

[Brijesh Singh]

The patch change the "BufferPhysAddr" parameter of VirtioAppendDesc()
from type UINTN to UINT64.

UINTN is appropriate as long as we pass system memory references. After
the introduction of this feature, that's no longer the case in general.
Should we implement "real" IOMMU support at some point, UINTN could
break in 32-bit builds of OVMF.

Suggested-by: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Include/Library/VirtioLib.h   | 35 +-
 OvmfPkg/Library/VirtioLib/VirtioLib.c | 38 ++--
 2 files changed, 37 insertions(+), 36 deletions(-)

diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
b/OvmfPkg/Include/Library/VirtioLib.h
index c3e56ea23b89..a966311ac941 100644
--- a/OvmfPkg/Include/Library/VirtioLib.h
+++ b/OvmfPkg/Include/Library/VirtioLib.h
@@ -151,33 +151,34 @@ VirtioPrepare (
   The caller is responsible for initializing *Indices with VirtioPrepare()
   first.
 
-  @param[in,out] RingThe virtio ring to append the buffer to, as a
- descriptor.
+  @param[in,out] Ring   The virtio ring to append the buffer to,
+as a descriptor.
 
-  @param[in] BufferPhysAddr  (Guest pseudo-physical) start address of the
- transmit / receive buffer.
+  @param[in] BufferDeviceAddress(Bus master device)) start address of the
+transmit / receive buffer.
 
-  @param[in] BufferSize  Number of bytes to transmit or receive.
+  @param[in] BufferSize Number of bytes to transmit or receive.
 
-  @param[in] Flags   A bitmask of VRING_DESC_F_* flags. The caller
- computes this mask dependent on further buffers to
- append and transfer direction.
- VRING_DESC_F_INDIRECT is unsupported. The
- VRING_DESC.Next field is always set, but the host
- only interprets it dependent on VRING_DESC_F_NEXT.
+  @param[in] Flags  A bitmask of VRING_DESC_F_* flags. The
+caller computes this mask dependent on
+further buffers to append and transfer
+direction. VRING_DESC_F_INDIRECT is
+unsupported. The VRING_DESC.Next field is
+always set, but the host only interprets
+it dependent on VRING_DESC_F_NEXT.
 
-  @param[in,out] Indices Indices->HeadDescIdx is not accessed.
- On input, Indices->NextDescIdx identifies the next
- descriptor to carry the buffer. On output,
- Indices->NextDescIdx is incremented by one, modulo
- 2^16.
+  @param[in,out] IndicesIndices->HeadDescIdx is not accessed.
+On input, Indices->NextDescIdx identifies
+the next descriptor to carry the buffer.
+On output, Indices->NextDescIdx is
+incremented by one, modulo 2^16.
 
 **/
 VOID
 EFIAPI
 VirtioAppendDesc (
   IN OUT VRING*Ring,
-  IN UINTNBufferPhysAddr,
+  IN UINT64   BufferDeviceAddress,
   IN UINT32   BufferSize,
   IN UINT16   Flags,
   IN OUT DESC_INDICES *Indices
diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
b/OvmfPkg/Library/VirtioLib/VirtioLib.c
index e5366e385f5d..fcd484fffada 100644
--- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
+++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
@@ -189,7 +189,6 @@ VirtioPrepare (
   Indices->NextDescIdx = Indices->HeadDescIdx;
 }
 
-
 /**
 
   Append a contiguous buffer for transmission / reception via the virtio ring.
@@ -205,33 +204,34 @@ VirtioPrepare (
   The caller is responsible for initializing *Indices with VirtioPrepare()
   first.
 
-  @param[in,out] RingThe virtio ring to append the buffer to, as a
- descriptor.
+  @param[in,out] Ring   The virtio ring to append the buffer to,
+as a descriptor.
 
-  @param[in] BufferPhysAddr  (Guest pseudo-physical) start address of the
- transmit / receive buffer.
+  @param[in] BufferDeviceAddress(Bus master device)) start address of the
+transmit / receive buffer.
 
-  @param[in] BufferSize  Number of bytes to transmit or receive.
+  @param[in] BufferSize Number of bytes to transmit or receive.
 
-  @param[in] Flags   A bitmask of VRING_DESC_F_* flags. The caller
- computes th

[edk2] [PATCH v3 13/23] OvmfPkg/VirtioBlkDxe: map host address to device address

[Brijesh Singh]

The SynchronousRequest() function, programs the vring descriptor with the
buffers pointed-by virtio-blk requests, status and memory that is
referenced inside the request header.

The patch uses VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() function to map
host address to device address and programs the vring descriptor with
device addresses.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioBlkDxe/VirtioBlk.h |   1 +
 OvmfPkg/VirtioBlkDxe/VirtioBlk.c | 201 +---
 2 files changed, 180 insertions(+), 22 deletions(-)

diff --git a/OvmfPkg/VirtioBlkDxe/VirtioBlk.h b/OvmfPkg/VirtioBlkDxe/VirtioBlk.h
index 6c402ca88ea4..9ec0b956b818 100644
--- a/OvmfPkg/VirtioBlkDxe/VirtioBlk.h
+++ b/OvmfPkg/VirtioBlkDxe/VirtioBlk.h
@@ -41,6 +41,7 @@ typedef struct {
   VRING  Ring; // VirtioRingInit  2
   EFI_BLOCK_IO_PROTOCOL  BlockIo;  // VirtioBlkInit   1
   EFI_BLOCK_IO_MEDIA BlockIoMedia; // VirtioBlkInit   1
+  VOID   *RingMap; // VirtioRingMap   2
 } VBLK_DEV;
 
 #define VIRTIO_BLK_FROM_BLOCK_IO(BlockIoPointer) \
diff --git a/OvmfPkg/VirtioBlkDxe/VirtioBlk.c b/OvmfPkg/VirtioBlkDxe/VirtioBlk.c
index bff15fe3add1..e23762743f75 100644
--- a/OvmfPkg/VirtioBlkDxe/VirtioBlk.c
+++ b/OvmfPkg/VirtioBlkDxe/VirtioBlk.c
@@ -232,7 +232,8 @@ VerifyReadWriteRequest (
 
   @retval EFI_DEVICE_ERROR Failed to notify host side via VirtIo write, or
unable to parse host response, or host response
-   is not VIRTIO_BLK_S_OK.
+   is not VIRTIO_BLK_S_OK or failed to map Buffer
+   for a bus master operation.
 
 **/
 
@@ -249,8 +250,16 @@ SynchronousRequest (
 {
   UINT32  BlockSize;
   volatile VIRTIO_BLK_REQ Request;
-  volatile UINT8  HostStatus;
+  volatile UINT8  *HostStatus;
+  VOID*HostStatusBuffer;
   DESC_INDICESIndices;
+  VOID*RequestMapping;
+  VOID*StatusMapping;
+  VOID*BufferMapping;
+  EFI_PHYSICAL_ADDRESSBufferDeviceAddress;
+  EFI_PHYSICAL_ADDRESSHostStatusDeviceAddress;
+  EFI_PHYSICAL_ADDRESSRequestDeviceAddress;
+  EFI_STATUS  Status, Ret;
 
   BlockSize = Dev->BlockIoMedia.BlockSize;
 
@@ -278,9 +287,88 @@ SynchronousRequest (
   VirtioPrepare (&Dev->Ring, &Indices);
 
   //
+  // Host status is bi-directional (we preset with a value and expect the 
device
+  // to update it). Allocate a host status buffer which can be mapped to
+  // access equally by both processor and the device.
+  //
+  Status = Dev->VirtIo->AllocateSharedPages (
+  Dev->VirtIo,
+  EFI_SIZE_TO_PAGES (sizeof *HostStatus),
+  &HostStatusBuffer
+  );
+  if (EFI_ERROR (Status)) {
+return EFI_DEVICE_ERROR;
+  }
+
+  //
+  // Map virtio-blk request header
+  //
+  Status = VirtioMapAllBytesInSharedBuffer (
+ Dev->VirtIo,
+ VirtioOperationBusMasterRead,
+ (VOID *) &Request,
+ sizeof Request,
+ &RequestDeviceAddress,
+ &RequestMapping
+ );
+  if (EFI_ERROR (Status)) {
+Status = EFI_DEVICE_ERROR;
+goto FreeHostStatusBuffer;
+  }
+
+  //
+  // Map data buffer
+  //
+  if (BufferSize > 0) {
+if (RequestIsWrite) {
+  Status = VirtioMapAllBytesInSharedBuffer (
+ Dev->VirtIo,
+ VirtioOperationBusMasterRead,
+ (VOID *) Buffer,
+ BufferSize,
+ &BufferDeviceAddress,
+ &BufferMapping
+ );
+} else {
+  Status = VirtioMapAllBytesInSharedBuffer (
+ Dev->VirtIo,
+ VirtioOperationBusMasterWrite,
+ (VOID *) Buffer,
+ BufferSize,
+ &BufferDeviceAddress,
+ &BufferMapping
+ );
+}
+
+if (EFI_ERROR (Status)) {
+  Status = EFI_DEVICE_ERROR;
+  goto UnmapRequestBuffer;
+}
+  }
+
+  //
+  // Map the Status Buffer with VirtioOperationBusMasterCommonBuffer so that
+  // both processor and device can access it.
+  //
+  Status = VirtioMapAllBytesInSharedBuffer (
+ Dev->VirtIo,
+ VirtioOperationBusMasterCommonBuffer,
+ HostStatusBuffer,
+ sizeof *HostStatus,
+ &HostStatusDeviceAddress,
+ &StatusMapping
+ );
+  if (EFI_ERROR (Status)) {
+Status = EFI_DEVICE_ERROR;
+goto UnmapDataBuffer;
+  }
+
+  HostStatus = HostStatusBuffer;
+
+  //
   // preset a host status for ourselves that we do not accept as success
   //
-  HostStatus = VIRTIO_BLK_S_IOERR;
+  *Hos

[edk2] [PATCH v3 09/23] OvmfPkg/VirtioLib: add function to map VRING

[Brijesh Singh]

Add functions to map the ring buffer with BusMasterCommonBuffer so that
ring can be accessed by both guest and hypervisor.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Include/Library/VirtioLib.h   | 26 +++
 OvmfPkg/Library/VirtioLib/VirtioLib.c | 45 
 2 files changed, 71 insertions(+)

diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
b/OvmfPkg/Include/Library/VirtioLib.h
index 40c51a2b3305..3d9314b3acaf 100644
--- a/OvmfPkg/Include/Library/VirtioLib.h
+++ b/OvmfPkg/Include/Library/VirtioLib.h
@@ -62,6 +62,32 @@ VirtioRingInit (
 
 /**
 
+  Map the ring buffer so that it can be accessed equally by both guest
+  and hypervisor.
+
+  @param[in]  VirtIo  The virtio device instance.
+
+  @param[in]  RingThe virtio ring to map.
+
+  @param[out] RingBaseShift   A resulting translation offset, to be
+  passed to VirtIo->SetQueueAddress().
+
+  @param[out] Mapping A resulting token to pass to
+  VirtIo->UnmapSharedBuffer().
+
+  @return Status code from VirtIo->MapSharedBuffer()
+**/
+EFI_STATUS
+EFIAPI
+VirtioRingMap (
+  IN  VIRTIO_DEVICE_PROTOCOL *VirtIo,
+  IN  VRING  *Ring,
+  OUT UINT64 *RingBaseShift,
+  OUT VOID   **Mapping
+  );
+
+/**
+
   Tear down the internal resources of a configured virtio ring.
 
   The caller is responsible to stop the host from using this ring before
diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
b/OvmfPkg/Library/VirtioLib/VirtioLib.c
index 8bc5b9aea4fc..535635ac0ba8 100644
--- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
+++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
@@ -505,3 +505,48 @@ Failed:
   VirtIo->UnmapSharedBuffer (VirtIo, MapInfo);
   return EFI_OUT_OF_RESOURCES;
 }
+
+/**
+
+  Map the ring buffer so that it can be accessed equally by both guest
+  and hypervisor.
+
+  @param[in]  VirtIo  The virtio device instance.
+
+  @param[in]  RingThe virtio ring to map.
+
+  @param[out] RingBaseShift   A resulting translation offset, to be
+  passed to VirtIo->SetQueueAddress().
+
+  @param[out] Mapping A resulting token to pass to
+  VirtIo->UnmapSharedBuffer().
+
+  @return Status code from VirtIo->MapSharedBuffer()
+**/
+EFI_STATUS
+EFIAPI
+VirtioRingMap (
+  IN  VIRTIO_DEVICE_PROTOCOL *VirtIo,
+  IN  VRING  *Ring,
+  OUT UINT64 *RingBaseShift,
+  OUT VOID   **Mapping
+  )
+{
+  EFI_STATUSStatus;
+  EFI_PHYSICAL_ADDRESS  DeviceAddress;
+
+  Status = VirtioMapAllBytesInSharedBuffer (
+ VirtIo,
+ VirtioOperationBusMasterCommonBuffer,
+ Ring->Base,
+ EFI_PAGES_TO_SIZE (Ring->NumPages),
+ &DeviceAddress,
+ Mapping
+ );
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  *RingBaseShift = DeviceAddress - (UINT64)(UINTN)Ring->Base;
+  return EFI_SUCCESS;
+}
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 17/23] OvmfPkg/VirtioNetDxe: dynamically alloc transmit header

[Brijesh Singh]

A network packets are transmitted by placing them into a transmit queue,
each packet is preceded by a VIRTIO_1_0_NET_REQ header. VirtioNetInitTx(),
builds the header once and fills the vring descriptors with the system
physical address of the VIRTIO_1_0_NET_REQ header.

The patch uses VirtIo->AllocateSharedPages() to allocate the header buffer
and map it with BusMasterCommonBuffer so that it can be equally accessed by
both processor and device.

We could map it with  BusMasterRead but since the header pointer is
used after it was added into vring hence I choose to dynamically allocate
it and map it with BusMasterCommonBuffer to avoid the code complexity.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioNetDxe/VirtioNet.h|  3 +-
 OvmfPkg/VirtioNetDxe/Events.c   |  6 ++
 OvmfPkg/VirtioNetDxe/SnpInitialize.c| 65 +---
 OvmfPkg/VirtioNetDxe/SnpSharedHelpers.c |  7 +++
 4 files changed, 72 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/VirtioNetDxe/VirtioNet.h b/OvmfPkg/VirtioNetDxe/VirtioNet.h
index 7df51bd044f5..3efe95a735d8 100644
--- a/OvmfPkg/VirtioNetDxe/VirtioNet.h
+++ b/OvmfPkg/VirtioNetDxe/VirtioNet.h
@@ -94,7 +94,8 @@ typedef struct {
   UINT16  TxMaxPending;  // VirtioNetInitTx
   UINT16  TxCurPending;  // VirtioNetInitTx
   UINT16  *TxFreeStack;  // VirtioNetInitTx
-  VIRTIO_1_0_NET_REQ  TxSharedReq;   // VirtioNetInitTx
+  VIRTIO_1_0_NET_REQ  *TxSharedReq;  // VirtioNetInitTx
+  VOID*TxSharedReqMap;   // VirtioMapSharedBuffer
   UINT16  TxLastUsed;// VirtioNetInitTx
 } VNET_DEV;
 
diff --git a/OvmfPkg/VirtioNetDxe/Events.c b/OvmfPkg/VirtioNetDxe/Events.c
index 0586a82cdf09..9366aa00a1b3 100644
--- a/OvmfPkg/VirtioNetDxe/Events.c
+++ b/OvmfPkg/VirtioNetDxe/Events.c
@@ -101,4 +101,10 @@ VirtioNetExitBoot (
   // device is reset.
   //
   Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Dev->RxBufMap);
+
+  //
+  // Unmap shared Tx request mapping so that hypervisor will not be able to get
+  // readable data after device is reset.
+  //
+  Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Dev->TxSharedReqMap);
 }
diff --git a/OvmfPkg/VirtioNetDxe/SnpInitialize.c 
b/OvmfPkg/VirtioNetDxe/SnpInitialize.c
index bdc3fd7ac6a2..3d4eb70aa630 100644
--- a/OvmfPkg/VirtioNetDxe/SnpInitialize.c
+++ b/OvmfPkg/VirtioNetDxe/SnpInitialize.c
@@ -18,6 +18,7 @@
 **/
 
 #include 
+#include 
 #include 
 #include 
 
@@ -151,8 +152,12 @@ VirtioNetInitTx (
   IN OUT VNET_DEV *Dev
   )
 {
-  UINTN TxSharedReqSize;
-  UINTN PktIdx;
+  UINTN TxSharedReqSize;
+  UINTN PktIdx;
+  EFI_STATUSStatus;
+  EFI_PHYSICAL_ADDRESS  DeviceAddress;
+  UINT64BufBaseShift;
+  VOID  *TxSharedReqBuffer;
 
   Dev->TxMaxPending = (UINT16) MIN (Dev->TxRing.QueueSize / 2,
  VNET_MAX_PENDING);
@@ -164,24 +169,60 @@ VirtioNetInitTx (
   }
 
   //
+  // Allocate TxSharedReq header and map with BusMasterCommonBuffer so that it
+  // can be accessed equally by both processor and device.
+  //
+  Status = Dev->VirtIo->AllocateSharedPages (
+  Dev->VirtIo,
+  EFI_SIZE_TO_PAGES (sizeof *(Dev->TxSharedReq)),
+  &TxSharedReqBuffer
+  );
+  if (EFI_ERROR (Status)) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  Status = VirtioMapAllBytesInSharedBuffer (
+ Dev->VirtIo,
+ VirtioOperationBusMasterCommonBuffer,
+ TxSharedReqBuffer,
+ sizeof *(Dev->TxSharedReq),
+ &DeviceAddress,
+ &Dev->TxSharedReqMap
+ );
+  if (EFI_ERROR (Status)) {
+Status = EFI_OUT_OF_RESOURCES;
+goto FreeBuffer;
+  }
+
+  Dev->TxSharedReq = TxSharedReqBuffer;
+
+  BufBaseShift = (UINT64) (UINTN)Dev->TxSharedReq - (UINT64) DeviceAddress;
+
+  ZeroMem ((VOID *) Dev->TxSharedReq, sizeof *(Dev->TxSharedReq));
+
+  //
   // In VirtIo 1.0, the NumBuffers field is mandatory. In 0.9.5, it depends on
   // VIRTIO_NET_F_MRG_RXBUF, which we never negotiate.
   //
   TxSharedReqSize = (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) ?
-sizeof Dev->TxSharedReq.V0_9_5 :
-sizeof Dev->TxSharedReq;
+sizeof ((Dev->TxSharedReq)->V0_9_5) :
+sizeof *(Dev->TxSharedReq);
 
   for (PktIdx = 0; PktIdx < Dev->TxMaxPending; ++PktIdx) {
 UINT16 DescIdx;
+UINT64 Address;
 
 DescIdx = (UINT16) (2 * PktIdx);
 Dev->TxFreeStack[PktIdx] = DescIdx;
 
+Address = (UINTN) Dev->TxSharedReq;
+Address += BufBaseShift;
+
 //
 // For each possibly pending packet, lay out the descriptor for the common
 // (unmodified by

[edk2] [PATCH v3 18/23] OvmfPkg/VirtioNetDxe: map transmit buffer host address to device address

[Brijesh Singh]

Update VirtioNetTransmit() function, to map the callers transmit buffer
host address to a device address.

Since the transmit buffers are returned back to caller in
VirtioNetGetStatus() hence we maintain a simple list to maintain 1:1
mapping between host address to device address. The list is consulted
when we return back the callers buffer after data is successfully
transmitted.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioNetDxe/VirtioNet.h|  17 +++
 OvmfPkg/VirtioNetDxe/SnpGetStatus.c |  29 -
 OvmfPkg/VirtioNetDxe/SnpSharedHelpers.c | 119 
 OvmfPkg/VirtioNetDxe/SnpTransmit.c  |  30 +++--
 4 files changed, 184 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/VirtioNetDxe/VirtioNet.h b/OvmfPkg/VirtioNetDxe/VirtioNet.h
index 3efe95a735d8..ac75bdeeb449 100644
--- a/OvmfPkg/VirtioNetDxe/VirtioNet.h
+++ b/OvmfPkg/VirtioNetDxe/VirtioNet.h
@@ -269,6 +269,23 @@ VirtioNetShutdownTx (
   IN OUT VNET_DEV *Dev
   );
 
+EFI_STATUS
+EFIAPI
+VirtioMapTxBuf (
+  IN  VNET_DEV  *Dev,
+  IN  EFI_PHYSICAL_ADDRESS  HostAddress,
+  IN  UINTN NumberOfBytes,
+  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress
+  );
+
+EFI_STATUS
+EFIAPI
+VirtioUnmapTxBuf (
+  IN  VNET_DEV  *Dev,
+  OUT EFI_PHYSICAL_ADDRESS  *HostAddress,
+  IN  EFI_PHYSICAL_ADDRESS  DeviceAddress
+  );
+
 //
 // event callbacks
 //
diff --git a/OvmfPkg/VirtioNetDxe/SnpGetStatus.c 
b/OvmfPkg/VirtioNetDxe/SnpGetStatus.c
index 694940ea1d97..d532551456d0 100644
--- a/OvmfPkg/VirtioNetDxe/SnpGetStatus.c
+++ b/OvmfPkg/VirtioNetDxe/SnpGetStatus.c
@@ -5,6 +5,7 @@
 
   Copyright (C) 2013, Red Hat, Inc.
   Copyright (c) 2006 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -47,7 +48,8 @@
   @retval EFI_INVALID_PARAMETER One or more of the parameters has an
 unsupported value.
   @retval EFI_DEVICE_ERROR  The command could not be sent to the network
-interface.
+interface or failed to map TxBuf to bus master
+address.
   @retval EFI_UNSUPPORTED   This function is not supported by the network
 interface.
 
@@ -126,8 +128,10 @@ VirtioNetGetStatus (
   *TxBuf = NULL;
 }
 else {
-  UINT16 UsedElemIdx;
-  UINT32 DescIdx;
+  UINT16UsedElemIdx;
+  UINT32DescIdx;
+  EFI_PHYSICAL_ADDRESS  BufferAddress;
+  EFI_PHYSICAL_ADDRESS  DeviceAddress;
 
   //
   // fetch the first descriptor among those that the hypervisor reports
@@ -141,9 +145,26 @@ VirtioNetGetStatus (
   ASSERT (DescIdx < (UINT32) (2 * Dev->TxMaxPending - 1));
 
   //
+  // Ring descriptor contains the device address of buffer.
+  // Lets unmap the device address and get its corresponding
+  // host buffer address.
+  //
+  DeviceAddress = Dev->TxRing.Desc[DescIdx + 1].Addr;
+  Status = VirtioUnmapTxBuf (
+ Dev,
+ &BufferAddress,
+ DeviceAddress
+ );
+  if (EFI_ERROR (Status)) {
+Status = EFI_DEVICE_ERROR;
+goto Exit;
+  }
+
+  //
+  //
   // report buffer address to caller that has been enqueued by caller
   //
-  *TxBuf = (VOID *)(UINTN) Dev->TxRing.Desc[DescIdx + 1].Addr;
+  *TxBuf = (VOID *)(UINTN) BufferAddress;
 
   //
   // now this descriptor can be used again to enqueue a transmit buffer
diff --git a/OvmfPkg/VirtioNetDxe/SnpSharedHelpers.c 
b/OvmfPkg/VirtioNetDxe/SnpSharedHelpers.c
index aeb9e6605f0d..5e1c610c4a18 100644
--- a/OvmfPkg/VirtioNetDxe/SnpSharedHelpers.c
+++ b/OvmfPkg/VirtioNetDxe/SnpSharedHelpers.c
@@ -14,10 +14,29 @@
 
 **/
 
+#include 
 #include 
 
 #include "VirtioNet.h"
 
+#define PRIVATE_TXBUF_SIGNATURE  SIGNATURE_32 ('t', 'x', 'b', 'f')
+typedef struct {
+  UINT32Signature;
+  LIST_ENTRYLink;
+  EFI_PHYSICAL_ADDRESS  HostAddress;
+  EFI_PHYSICAL_ADDRESS  DeviceAddress;
+  VOID  *Mapping;
+} PRIVATE_TXBUF_ENTRY;
+#define PRIVATE_TXBUF_FROM_LINK(a) CR (a, PRIVATE_TXBUF_ENTRY, Link, \
+   PRIVATE_TXBUF_SIGNATURE)
+
+//
+// List of Txbuf queued
+//
+STATIC LIST_ENTRY mTxBufMapList = INITIALIZE_LIST_HEAD_VARIABLE (
+mTxBufMapList
+);
+
 /**
   Release RX and TX resources on the boundary of the
   EfiSimpleNetworkInitialized state.
@@ -63,3 +82,103 @@ VirtioNetShutdownTx (
 
   FreePool (Dev->TxFreeStack);
 }
+
+EFI_STATUS
+EFIAPI
+VirtioMapTxB

[edk2] [PATCH v3 14/23] OvmfPkg/VirtioScsiDxe: map host address to device address

[Brijesh Singh]

The VirtioScsiPassThru() function, programs the vring descriptor using
the host addresses pointed-by virtio-scsi request, response and memory
that is referenced inside the request and response header.

The patch uses newly introduced VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer()
function to map system memory to device address and programs the vring
descriptors with device addresses.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioScsiDxe/VirtioScsi.h |   1 +
 OvmfPkg/VirtioScsiDxe/VirtioScsi.c | 210 +---
 2 files changed, 186 insertions(+), 25 deletions(-)

diff --git a/OvmfPkg/VirtioScsiDxe/VirtioScsi.h 
b/OvmfPkg/VirtioScsiDxe/VirtioScsi.h
index 6d00567e8cb8..05a6bf567263 100644
--- a/OvmfPkg/VirtioScsiDxe/VirtioScsi.h
+++ b/OvmfPkg/VirtioScsiDxe/VirtioScsi.h
@@ -60,6 +60,7 @@ typedef struct {
   VRING   Ring;   // VirtioRingInit  2
   EFI_EXT_SCSI_PASS_THRU_PROTOCOL PassThru;   // VirtioScsiInit  1
   EFI_EXT_SCSI_PASS_THRU_MODE PassThruMode;   // VirtioScsiInit  1
+  VOID*RingMap;   // VirtioRingMap   2
 } VSCSI_DEV;
 
 #define VIRTIO_SCSI_FROM_PASS_THRU(PassThruPointer) \
diff --git a/OvmfPkg/VirtioScsiDxe/VirtioScsi.c 
b/OvmfPkg/VirtioScsiDxe/VirtioScsi.c
index a983b3df7b9c..ed7fd1dd58a8 100644
--- a/OvmfPkg/VirtioScsiDxe/VirtioScsi.c
+++ b/OvmfPkg/VirtioScsiDxe/VirtioScsi.c
@@ -409,11 +409,19 @@ VirtioScsiPassThru (
   UINT16TargetValue;
   EFI_STATUSStatus;
   volatile VIRTIO_SCSI_REQ  Request;
-  volatile VIRTIO_SCSI_RESP Response;
+  volatile VIRTIO_SCSI_RESP *Response;
+  VOID  *ResponseBuffer;
   DESC_INDICES  Indices;
+  VOID  *RequestMapping;
+  VOID  *ResponseMapping;
+  VOID  *InDataMapping;
+  VOID  *OutDataMapping;
+  EFI_PHYSICAL_ADDRESS  RequestDeviceAddress;
+  EFI_PHYSICAL_ADDRESS  ResponseDeviceAddress;
+  EFI_PHYSICAL_ADDRESS  InDataDeviceAddress;
+  EFI_PHYSICAL_ADDRESS  OutDataDeviceAddress;
 
   ZeroMem ((VOID*) &Request, sizeof (Request));
-  ZeroMem ((VOID*) &Response, sizeof (Response));
 
   Dev = VIRTIO_SCSI_FROM_PASS_THRU (This);
   CopyMem (&TargetValue, Target, sizeof TargetValue);
@@ -423,12 +431,93 @@ VirtioScsiPassThru (
 return Status;
   }
 
+  //
+  // Response header is bi-direction (we preset with host status and expect the
+  // device to update it). Allocate a response buffer which can be mapped to
+  // access equally by both processor and device.
+  //
+  Status = Dev->VirtIo->AllocateSharedPages (
+  Dev->VirtIo,
+  EFI_SIZE_TO_PAGES (sizeof *Response),
+  &ResponseBuffer
+  );
+  if (EFI_ERROR (Status)) {
+return EFI_DEVICE_ERROR;
+  }
+
+  Status = VirtioMapAllBytesInSharedBuffer (
+ Dev->VirtIo,
+ VirtioOperationBusMasterCommonBuffer,
+ ResponseBuffer,
+ sizeof (*Response),
+ &ResponseDeviceAddress,
+ &ResponseMapping
+ );
+  if (EFI_ERROR (Status)) {
+Status = EFI_DEVICE_ERROR;
+goto FreeResponseBuffer;
+  }
+
+  Response = ResponseBuffer;
+
+  //
+  // Map the scsi-blk Request header buffer host address to device address
+  //
+  Status = VirtioMapAllBytesInSharedBuffer (
+ Dev->VirtIo,
+ VirtioOperationBusMasterRead,
+ (VOID *) &Request,
+ sizeof Request,
+ &RequestDeviceAddress,
+ &RequestMapping);
+  if (EFI_ERROR (Status)) {
+Status = EFI_DEVICE_ERROR;
+goto UnmapResponseBuffer;
+  }
+
+  //
+  // Map the input buffer host address to a device address
+  //
+  if (Packet->InTransferLength > 0) {
+Status = VirtioMapAllBytesInSharedBuffer (
+   Dev->VirtIo,
+   VirtioOperationBusMasterWrite,
+   Packet->InDataBuffer,
+   Packet->InTransferLength,
+   &InDataDeviceAddress,
+   &InDataMapping
+   );
+if (EFI_ERROR (Status)) {
+  Status = EFI_DEVICE_ERROR;
+  goto UnmapRequestBuffer;
+}
+  }
+
+  //
+  // Map the output buffer host address to a device address
+  //
+  if (Packet->OutTransferLength > 0) {
+Status = VirtioMapAllBytesInSharedBuffer (
+   Dev->VirtIo,
+   VirtioOperationBusMasterRead,
+   Packet->OutDataBuffer,
+   Packet->OutTransferLength,
+   &OutDataDeviceAddress,
+   &OutDataMapping
+   );
+if (EFI_ERROR (Status)) {
+  Status = EFI_DEVICE_ERROR;
+  goto UnmapInDataBuffer;
+}
+  }
+
+
   VirtioPrepare (&Dev->Ring, &Indices);
 
   //
   // preset a host status for ourselves tha

[edk2] [PATCH v3 16/23] OvmfPkg/VirtioNetDxe: alloc RxBuf using AllocateSharedPages()

[Brijesh Singh]

RxBuf is shared between guest and hypervisor, use
VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages() to allocate this memory
region and map it with BusMasterCommonBuffer operation so that it can be
accessed by both guest and hypervisor.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioNetDxe/VirtioNet.h|  3 +
 OvmfPkg/VirtioNetDxe/Events.c   |  6 ++
 OvmfPkg/VirtioNetDxe/SnpInitialize.c| 76 
 OvmfPkg/VirtioNetDxe/SnpSharedHelpers.c |  7 +-
 4 files changed, 78 insertions(+), 14 deletions(-)

diff --git a/OvmfPkg/VirtioNetDxe/VirtioNet.h b/OvmfPkg/VirtioNetDxe/VirtioNet.h
index d80d441b50a4..7df51bd044f5 100644
--- a/OvmfPkg/VirtioNetDxe/VirtioNet.h
+++ b/OvmfPkg/VirtioNetDxe/VirtioNet.h
@@ -4,6 +4,7 @@
   Protocol instances for virtio-net devices.
 
   Copyright (C) 2013, Red Hat, Inc.
+  Copyright (c) 2017, AMD Inc, All rights reserved.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -85,6 +86,8 @@ typedef struct {
   VOID*RxRingMap;// VirtioRingMap
   UINT8   *RxBuf;// VirtioNetInitRx
   UINT16  RxLastUsed;// VirtioNetInitRx
+  UINTN   RxBufNoPages;  // VirtioNetInitRx
+  VOID*RxBufMap; // VirtioMapSharedBuffer
 
   VRING   TxRing;// VirtioNetInitRing
   VOID*TxRingMap;// VirtioRingMap
diff --git a/OvmfPkg/VirtioNetDxe/Events.c b/OvmfPkg/VirtioNetDxe/Events.c
index 6950c4d56df1..0586a82cdf09 100644
--- a/OvmfPkg/VirtioNetDxe/Events.c
+++ b/OvmfPkg/VirtioNetDxe/Events.c
@@ -95,4 +95,10 @@ VirtioNetExitBoot (
   //
   Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Dev->TxRingMap);
   Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Dev->RxRingMap);
+
+  //
+  // Unmap Rx buffer so that hypervisor will not be able get readable data 
after
+  // device is reset.
+  //
+  Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Dev->RxBufMap);
 }
diff --git a/OvmfPkg/VirtioNetDxe/SnpInitialize.c 
b/OvmfPkg/VirtioNetDxe/SnpInitialize.c
index 803a38bd4239..bdc3fd7ac6a2 100644
--- a/OvmfPkg/VirtioNetDxe/SnpInitialize.c
+++ b/OvmfPkg/VirtioNetDxe/SnpInitialize.c
@@ -249,13 +249,17 @@ VirtioNetInitRx (
   IN OUT VNET_DEV *Dev
   )
 {
-  EFI_STATUS Status;
-  UINTN  VirtioNetReqSize;
-  UINTN  RxBufSize;
-  UINT16 RxAlwaysPending;
-  UINTN  PktIdx;
-  UINT16 DescIdx;
-  UINT8  *RxPtr;
+  EFI_STATUSStatus;
+  UINTN VirtioNetReqSize;
+  UINTN RxBufSize;
+  UINT16RxAlwaysPending;
+  UINTN PktIdx;
+  UINT16DescIdx;
+  UINT8 *RxPtr;
+  UINTN NumBytes;
+  EFI_PHYSICAL_ADDRESS  RxBufDeviceAddress;
+  UINT64BufBaseShift;
+  VOID  *RxBuffer;
 
   //
   // In VirtIo 1.0, the NumBuffers field is mandatory. In 0.9.5, it depends on
@@ -280,11 +284,41 @@ VirtioNetInitRx (
   //
   RxAlwaysPending = (UINT16) MIN (Dev->RxRing.QueueSize / 2, VNET_MAX_PENDING);
 
-  Dev->RxBuf = AllocatePool (RxAlwaysPending * RxBufSize);
-  if (Dev->RxBuf == NULL) {
-return EFI_OUT_OF_RESOURCES;
+  //
+  // The RxBuf is shared between guest and hypervisor, use SharedPages() to
+  // allocate this memory region and map it with BusMasterCommonBuffer
+  // operation so that it can be accessed equally by both guest and
+  // hypervisor.
+  //
+  NumBytes = RxAlwaysPending * RxBufSize;
+  Dev->RxBufNoPages = EFI_SIZE_TO_PAGES (NumBytes);
+  Status = Dev->VirtIo->AllocateSharedPages (
+  Dev->VirtIo,
+  Dev->RxBufNoPages,
+  &RxBuffer
+  );
+  if (EFI_ERROR (Status)) {
+Status = EFI_OUT_OF_RESOURCES;
+return Status;
   }
 
+  Status = VirtioMapAllBytesInSharedBuffer (
+ Dev->VirtIo,
+ VirtioOperationBusMasterCommonBuffer,
+ RxBuffer,
+ NumBytes,
+ &RxBufDeviceAddress,
+ &Dev->RxBufMap
+ );
+  if (EFI_ERROR (Status)) {
+Status = EFI_OUT_OF_RESOURCES;
+goto FreeSharedBuffer;
+  }
+
+  Dev->RxBuf = RxBuffer;
+
+  BufBaseShift = (UINT64) (UINTN)Dev->RxBuf - (UINT64) RxBufDeviceAddress;
+
   //
   // virtio-0.9.5, 2.4.2 Receiving Used Buffers From the Device
   //
@@ -306,6 +340,11 @@ VirtioNetInitRx (
   DescIdx = 0;
   RxPtr = Dev->RxBuf;
   for (PktIdx = 0; PktIdx < RxAlwaysPending; ++PktIdx) {
+UINT64Address;
+
+Address = (UINTN) RxPtr;
+Address += BufBaseShift;
+
 //
 // virtio-0.9.5, 2.4.1.2 Updating the Available Ring
 // invisible to the host until we update the Index Field
@@ -315,13 +35

[edk2] [PATCH v3 20/23] OvmfPkg/VirtioRngDxe: negotiate VIRITO_F_IOMMU_PLATFORM

[Brijesh Singh]

In previous patches, we have implemented IOMMU-like member functions in
VIRTIO_DEVICE_PROTOCOL to translate the physical address to bus address
and virtio drivers are updated to use those member functions. 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: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioRngDxe/VirtioRng.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/VirtioRngDxe/VirtioRng.c b/OvmfPkg/VirtioRngDxe/VirtioRng.c
index 59f32d343179..32512d882f7d 100644
--- a/OvmfPkg/VirtioRngDxe/VirtioRng.c
+++ b/OvmfPkg/VirtioRngDxe/VirtioRng.c
@@ -278,7 +278,7 @@ VirtioRngInit (
 goto Failed;
   }
 
-  Features &= VIRTIO_F_VERSION_1;
+  Features &= VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM;
 
   //
   // In virtio-1.0, feature negotiation is expected to complete before queue
@@ -359,7 +359,7 @@ VirtioRngInit (
   // step 5 -- Report understood features and guest-tuneables.
   //
   if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
-Features &= ~(UINT64)VIRTIO_F_VERSION_1;
+Features &= ~(UINT64)VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM;
 Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
 if (EFI_ERROR (Status)) {
   goto UnmapQueue;
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 19/23] OvmfPkg/Virtio10: define VIRITO_F_IOMMU_PLATFORM feature bit

[Brijesh Singh]

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 more infromation

[1] https://lists.oasis-open.org/archives/virtio-dev/201610/msg00121.html

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/Include/IndustryStandard/Virtio10.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/Include/IndustryStandard/Virtio10.h 
b/OvmfPkg/Include/IndustryStandard/Virtio10.h
index 4c9b62a3cf59..c5efb5cfcb8a 100644
--- a/OvmfPkg/Include/IndustryStandard/Virtio10.h
+++ b/OvmfPkg/Include/IndustryStandard/Virtio10.h
@@ -2,6 +2,7 @@
   Definitions from the VirtIo 1.0 specification (csprd05).
 
   Copyright (C) 2016, Red Hat, Inc.
+  Copyright (C) 2017, AMD, Inc.
 
   This program and the accompanying materials are licensed and made available
   under the terms and conditions of the BSD License which accompanies this
@@ -81,6 +82,7 @@ typedef struct {
 //
 // VirtIo 1.0 reserved (device-independent) feature bits
 //
-#define VIRTIO_F_VERSION_1 BIT32
+#define VIRTIO_F_VERSION_1  BIT32
+#define VIRTIO_F_IOMMU_PLATFORM BIT33
 
 #endif // _VIRTIO_1_0_H_
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 23/23] OvmfPkg/VirtioNetDxe: negotiate VIRITO_F_IOMMU_PLATFORM

[Brijesh Singh]

In previous patches, we have implemented IOMMU-like member functions in
VIRTIO_DEVICE_PROTOCOL to translate the physical address to bus address
and virtio drivers are updated to use those member functions. 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: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioNetDxe/SnpInitialize.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/VirtioNetDxe/SnpInitialize.c 
b/OvmfPkg/VirtioNetDxe/SnpInitialize.c
index 3d4eb70aa630..750cea10abe7 100644
--- a/OvmfPkg/VirtioNetDxe/SnpInitialize.c
+++ b/OvmfPkg/VirtioNetDxe/SnpInitialize.c
@@ -551,7 +551,8 @@ VirtioNetInitialize (
   ASSERT (Dev->Snm.MediaPresentSupported ==
 !!(Features & VIRTIO_NET_F_STATUS));
 
-  Features &= VIRTIO_NET_F_MAC | VIRTIO_NET_F_STATUS | VIRTIO_F_VERSION_1;
+  Features &= VIRTIO_NET_F_MAC | VIRTIO_NET_F_STATUS | VIRTIO_F_VERSION_1 |
+  VIRTIO_F_IOMMU_PLATFORM;
 
   //
   // In virtio-1.0, feature negotiation is expected to complete before queue
@@ -591,7 +592,7 @@ VirtioNetInitialize (
   // step 5 -- keep only the features we want
   //
   if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
-Features &= ~(UINT64)VIRTIO_F_VERSION_1;
+Features &= ~(UINT64)VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM;
 Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
 if (EFI_ERROR (Status)) {
   goto ReleaseTxRing;
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 22/23] OvmfPkg/VirtioScsiDxe: negotiate VIRITO_F_IOMMU_PLATFORM

[Brijesh Singh]

In previous patches, we have implemented IOMMU-like member functions in
VIRTIO_DEVICE_PROTOCOL to translate the physical address to bus address
and virtio drivers are updated to use those member functions. 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: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioScsiDxe/VirtioScsi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/VirtioScsiDxe/VirtioScsi.c 
b/OvmfPkg/VirtioScsiDxe/VirtioScsi.c
index ed7fd1dd58a8..91a008b2caa4 100644
--- a/OvmfPkg/VirtioScsiDxe/VirtioScsi.c
+++ b/OvmfPkg/VirtioScsiDxe/VirtioScsi.c
@@ -934,7 +934,8 @@ VirtioScsiInit (
 goto Failed;
   }
 
-  Features &= VIRTIO_SCSI_F_INOUT | VIRTIO_F_VERSION_1;
+  Features &= VIRTIO_SCSI_F_INOUT | VIRTIO_F_VERSION_1 |
+  VIRTIO_F_IOMMU_PLATFORM;
 
   //
   // In virtio-1.0, feature negotiation is expected to complete before queue
@@ -1014,7 +1015,7 @@ VirtioScsiInit (
   // step 5 -- Report understood features and guest-tuneables.
   //
   if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
-Features &= ~(UINT64)VIRTIO_F_VERSION_1;
+Features &= ~(UINT64)VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM;
 Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
 if (EFI_ERROR (Status)) {
   goto UnmapQueue;
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 21/23] OvmfPkg/VirtioBlkDxe: negotiate VIRITO_F_IOMMU_PLATFORM

[Brijesh Singh]

In previous patches, we have implemented IOMMU-like member functions in
VIRTIO_DEVICE_PROTOCOL to translate the physical address to bus address
and virtio drivers are updated to use those member functions. 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: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
---
 OvmfPkg/VirtioBlkDxe/VirtioBlk.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/VirtioBlkDxe/VirtioBlk.c b/OvmfPkg/VirtioBlkDxe/VirtioBlk.c
index e23762743f75..fa6c527c0d28 100644
--- a/OvmfPkg/VirtioBlkDxe/VirtioBlk.c
+++ b/OvmfPkg/VirtioBlkDxe/VirtioBlk.c
@@ -824,7 +824,8 @@ VirtioBlkInit (
   }
 
   Features &= VIRTIO_BLK_F_BLK_SIZE | VIRTIO_BLK_F_TOPOLOGY | VIRTIO_BLK_F_RO |
-  VIRTIO_BLK_F_FLUSH | VIRTIO_F_VERSION_1;
+  VIRTIO_BLK_F_FLUSH | VIRTIO_F_VERSION_1 |
+  VIRTIO_F_IOMMU_PLATFORM;
 
   //
   // In virtio-1.0, feature negotiation is expected to complete before queue
@@ -902,7 +903,7 @@ VirtioBlkInit (
   // step 5 -- Report understood features.
   //
   if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
-Features &= ~(UINT64)VIRTIO_F_VERSION_1;
+Features &= ~(UINT64)VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM;
 Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
 if (EFI_ERROR (Status)) {
   goto UnmapQueue;
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms] Silicon/Openmoko: add driver for ChaosKey RNG USB device

[Ard Biesheuvel]

This is a continuation of the work carried out by Leif Lindholm to
implement a driver for the ChaosKey USB device. This driver uses the
UEFI driver model, which is a slightly awkward fit, due to the fact
that a UEFI implementation may legally only instantiate those protocols
that are needed to access the device path that the active Boot
options refers to.

However, it is expected that UEFI implementations typically instantiate
all USB I/O protocols and connect them as well, as those are required
for a USB keyboard to be able to control the boot sequence. This should
result in this driver being connected and given the opportunity to
produce the EFI_RNG_PROTOCOL.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.c | 346 
 Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.h |  61 
 Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDxe.inf  |  48 +++
 Silicon/Openmoko/ChaosKeyDxe/ComponentName.c  | 205 
 Silicon/Openmoko/ChaosKeyDxe/DriverBinding.c  | 256 +++
 5 files changed, 916 insertions(+)

diff --git a/Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.c 
b/Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.c
new file mode 100644
index ..1870080d2c70
--- /dev/null
+++ b/Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.c
@@ -0,0 +1,346 @@
+/** @file
+  Device driver for the ChaosKey hardware random number generator.
+
+  Copyright (c) 2016 - 2017, Linaro Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD
+  License which accompanies this distribution. The full text of the license may
+  be found at  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "ChaosKeyDriver.h"
+
+#include 
+#include 
+#include 
+
+STATIC
+BOOLEAN
+IsBulkInEndpoint (
+  IN  EFI_USB_ENDPOINT_DESCRIPTOR *Endpoint
+  )
+{
+  if ((Endpoint->Attributes & USB_ENDPOINT_TYPE_MASK) == USB_ENDPOINT_BULK) {
+if (Endpoint->EndpointAddress & USB_ENDPOINT_DIR_IN) {
+  return TRUE;
+}
+  }
+  return FALSE;
+}
+
+
+STATIC
+EFI_STATUS
+FindEndpoint (
+  IN  CHAOSKEY_DEV *ChaosKey
+  )
+{
+  EFI_USB_IO_PROTOCOL *UsbIo;
+  EFI_STATUS  Status;
+  UINTN   Index;
+  EFI_USB_INTERFACE_DESCRIPTORInterfaceDescriptor;
+
+  UsbIo = ChaosKey->UsbIo;
+
+  //
+  // Get interface & endpoint descriptor
+  //
+  Status = UsbIo->UsbGetInterfaceDescriptor (UsbIo, &InterfaceDescriptor);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  //
+  // The ChaosKey provides two endpoints:
+  // - The first one is the 'cooked' one, to be used as random data input
+  // - The second one is the raw bitstream from the generator, higher
+  //   throughput, but lower randomness.
+  // So locate the first bulk IN endpoint and save it for later use.
+  //
+  for (Index = 0; Index < InterfaceDescriptor.NumEndpoints; Index++) {
+EFI_USB_ENDPOINT_DESCRIPTOR  Endpoint;
+
+Status = UsbIo->UsbGetEndpointDescriptor (UsbIo, Index, &Endpoint);
+if (EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_ERROR, "UsbGetEndPointDescriptor(%d) failed!\n", Index));
+  return Status;
+}
+
+if (IsBulkInEndpoint(&Endpoint)) {
+  ChaosKey->EndpointAddress = Endpoint.EndpointAddress;
+  ChaosKey->EndpointSize = Endpoint.MaxPacketSize;
+  return EFI_SUCCESS;
+}
+  }
+
+  DEBUG ((DEBUG_ERROR, "Failed to locate suitable BULK IN USB endpoint!\n"));
+  return EFI_DEVICE_ERROR;
+}
+
+
+/**
+  Returns information about the random number generation implementation.
+
+  @param[in] This   A pointer to the EFI_RNG_PROTOCOL instance.
+  @param[in,out] AlgorithmListSize  On input, the size in bytes of 
AlgorithmList
+On output with a return code of 
EFI_SUCCESS,
+the size in bytes of the data returned in
+AlgorithmList. On output with a return
+code of EFI_BUFFER_TOO_SMALL, the size of
+AlgorithmList required to obtain the list.
+  @param[out] AlgorithmList A caller-allocated memory buffer filled by
+the driver with one EFI_RNG_ALGORITHM
+element for each supported RNG algorithm.
+The list must not change across multiple
+calls to the same driver. The first
+algorithm in the list is the default
+algorithm for the driver.
+
+  @retval EFI_SUCCESS   The RNG algorithm list was returned
+  

Re: [edk2] [PATCH] ArmVirtPkg: remove QemuVideoDxe from ArmVirtQemu and ArmVirtQemuKernel

[Leif Lindholm]

On Tue, Aug 22, 2017 at 06:16:56PM +0100, Ard Biesheuvel wrote:
> On 22 August 2017 at 18:02, Laszlo Ersek  wrote:
> > On 08/22/17 18:30, Ard Biesheuvel wrote:
> >> One of the reasons for introducing virtio-gpu support to OvmfPkg and
> >> ArmVirtpkg was the fact that under KVM virtualization on ARM, the
> >> legacy VGA cannot be used reliably. This is due to an implementation
> >> detail of QEMU+KVM, which remaps cached host memory into the guest
> >> address space as a framebuffer behind a PCI BAR. Given that the purpose
> >> of a memory mapped framebuffer is its side effects, such BARs should
> >> never be mapped cacheable in the guest, and the mismatched attributes
> >> between host and guest result in a loss of coherency, visible as
> >> corruption in the framebuffer image.
> >>
> >> This issue does not occur under TCG emulation, nor did we expect it to
> >> actually bring down the guest under KVM, and so it was deemed harmless
> >> to keep support for the VGA device as well. However, as it turns out,
> >> the fact that the framebuffer BAR is mapped using device semantics by
> >> default may result in unalignment faults when we use the ordinary string
> >> copy routines on the contents. In theory, we could work around this by
> >> remapping the BAR as write combining, but it appears the generic PCI
> >> bus driver does not actually implement this.
> >>
> >> So let's remove the QemuVideoDxe driver altogether. This may result
> >> in loss of functionality for use cases that rely on the framebuffer
> >> to be directly addressable (such as EFIFB), but given that this never
> >> worked reliably under KVM in the first place, let's not let that stop
> >> us from dropping support for it.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ard Biesheuvel 
> >> ---
> >>  ArmVirtPkg/ArmVirtQemu.dsc   | 2 --
> >>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 -
> >>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 --
> >>  3 files changed, 5 deletions(-)
> >>
> >> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> >> index e23a6d17bc44..2e6e76224987 100644
> >> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> >> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> >> @@ -57,7 +57,6 @@
> >>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> >>
> >> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> >>
> >> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> >> -  
> >> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
> >>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> >>FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> >>
> >> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
> >> @@ -357,7 +356,6 @@
> >>#
> >># Video support
> >>#
> >> -  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >>OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> >>OvmfPkg/PlatformDxe/Platform.inf
> >>
> >> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
> >> b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> >> index 237b2d03a714..3194aa3edc8e 100644
> >> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> >> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> >> @@ -167,7 +167,6 @@ READ_LOCK_STATUS   = TRUE
> >>#
> >># Video support
> >>#
> >> -  INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >>INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> >>INF OvmfPkg/PlatformDxe/Platform.inf
> >>
> >> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> >> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> >> index aa01debfda69..69de887277cb 100644
> >> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> >> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> >> @@ -57,7 +57,6 @@
> >>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> >>
> >> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> >>
> >> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> >> -  
> >> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
> >>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
> >>FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> >>
> >> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
> >> @@ -348,7 +347,6 @@
> >>#
> >># Video support
> >>#
> >> -  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >>OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> >>OvmfPkg/PlatformDxe/Platform.inf
> >>
> >>
> >
> > (My R-b stands; these are comments for a possible followup patch.)
> >
> > Please see:
> >
> > - commit 84a75f70e903 ("OvmfPkg/QemuVideoDxe: enable ARM builds",
> > 2015-02-23),
> >
> > - commit 05a537945872 ("OvmfPkg/QemuVideoDxe: Helper functions for
> > unaligned port I/O.", 2017-04-07)?
> >
> > In my opinion, we should now revert parts of these commits,

Re: [edk2] [PATCH] ArmVirtPkg: remove QemuVideoDxe from ArmVirtQemu and ArmVirtQemuKernel

[Ard Biesheuvel]

On 23 August 2017 at 14:15, Leif Lindholm  wrote:
> On Tue, Aug 22, 2017 at 06:16:56PM +0100, Ard Biesheuvel wrote:
>> On 22 August 2017 at 18:02, Laszlo Ersek  wrote:
>> > On 08/22/17 18:30, Ard Biesheuvel wrote:
>> >> One of the reasons for introducing virtio-gpu support to OvmfPkg and
>> >> ArmVirtpkg was the fact that under KVM virtualization on ARM, the
>> >> legacy VGA cannot be used reliably. This is due to an implementation
>> >> detail of QEMU+KVM, which remaps cached host memory into the guest
>> >> address space as a framebuffer behind a PCI BAR. Given that the purpose
>> >> of a memory mapped framebuffer is its side effects, such BARs should
>> >> never be mapped cacheable in the guest, and the mismatched attributes
>> >> between host and guest result in a loss of coherency, visible as
>> >> corruption in the framebuffer image.
>> >>
>> >> This issue does not occur under TCG emulation, nor did we expect it to
>> >> actually bring down the guest under KVM, and so it was deemed harmless
>> >> to keep support for the VGA device as well. However, as it turns out,
>> >> the fact that the framebuffer BAR is mapped using device semantics by
>> >> default may result in unalignment faults when we use the ordinary string
>> >> copy routines on the contents. In theory, we could work around this by
>> >> remapping the BAR as write combining, but it appears the generic PCI
>> >> bus driver does not actually implement this.
>> >>
>> >> So let's remove the QemuVideoDxe driver altogether. This may result
>> >> in loss of functionality for use cases that rely on the framebuffer
>> >> to be directly addressable (such as EFIFB), but given that this never
>> >> worked reliably under KVM in the first place, let's not let that stop
>> >> us from dropping support for it.
>> >>
>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>> >> Signed-off-by: Ard Biesheuvel 
>> >> ---
>> >>  ArmVirtPkg/ArmVirtQemu.dsc   | 2 --
>> >>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 -
>> >>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 --
>> >>  3 files changed, 5 deletions(-)
>> >>
>> >> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> >> index e23a6d17bc44..2e6e76224987 100644
>> >> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> >> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> >> @@ -57,7 +57,6 @@
>> >>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>> >>
>> >> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>> >>
>> >> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>> >> -  
>> >> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>> >>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>> >>
>> >> FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
>> >>
>> >> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
>> >> @@ -357,7 +356,6 @@
>> >>#
>> >># Video support
>> >>#
>> >> -  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>> >>OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>> >>OvmfPkg/PlatformDxe/Platform.inf
>> >>
>> >> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
>> >> b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
>> >> index 237b2d03a714..3194aa3edc8e 100644
>> >> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
>> >> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
>> >> @@ -167,7 +167,6 @@ READ_LOCK_STATUS   = TRUE
>> >>#
>> >># Video support
>> >>#
>> >> -  INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>> >>INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>> >>INF OvmfPkg/PlatformDxe/Platform.inf
>> >>
>> >> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
>> >> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> >> index aa01debfda69..69de887277cb 100644
>> >> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> >> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> >> @@ -57,7 +57,6 @@
>> >>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>> >>
>> >> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>> >>
>> >> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
>> >> -  
>> >> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>> >>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>> >>
>> >> FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
>> >>
>> >> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
>> >> @@ -348,7 +347,6 @@
>> >>#
>> >># Video support
>> >>#
>> >> -  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>> >>OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>> >>OvmfPkg/PlatformDxe/Platform.inf
>> >>
>> >>
>> >
>> > (My R-b stands; these are comments for a possible followup patch.)
>> >
>> > Please see:
>> >
>> > - commit 84a75f70e903 ("OvmfPkg/QemuVideoDxe: enable ARM builds",
>> > 2015-02-23),
>> >
>> > 

Re: [edk2] [PATCH] ArmVirtPkg: remove QemuVideoDxe from ArmVirtQemu and ArmVirtQemuKernel

[Laszlo Ersek]

On 08/23/17 15:17, Ard Biesheuvel wrote:
> On 23 August 2017 at 14:15, Leif Lindholm  wrote:
>> On Tue, Aug 22, 2017 at 06:16:56PM +0100, Ard Biesheuvel wrote:
>>> On 22 August 2017 at 18:02, Laszlo Ersek  wrote:
 On 08/22/17 18:30, Ard Biesheuvel wrote:
> One of the reasons for introducing virtio-gpu support to OvmfPkg and
> ArmVirtpkg was the fact that under KVM virtualization on ARM, the
> legacy VGA cannot be used reliably. This is due to an implementation
> detail of QEMU+KVM, which remaps cached host memory into the guest
> address space as a framebuffer behind a PCI BAR. Given that the purpose
> of a memory mapped framebuffer is its side effects, such BARs should
> never be mapped cacheable in the guest, and the mismatched attributes
> between host and guest result in a loss of coherency, visible as
> corruption in the framebuffer image.
>
> This issue does not occur under TCG emulation, nor did we expect it to
> actually bring down the guest under KVM, and so it was deemed harmless
> to keep support for the VGA device as well. However, as it turns out,
> the fact that the framebuffer BAR is mapped using device semantics by
> default may result in unalignment faults when we use the ordinary string
> copy routines on the contents. In theory, we could work around this by
> remapping the BAR as write combining, but it appears the generic PCI
> bus driver does not actually implement this.
>
> So let's remove the QemuVideoDxe driver altogether. This may result
> in loss of functionality for use cases that rely on the framebuffer
> to be directly addressable (such as EFIFB), but given that this never
> worked reliably under KVM in the first place, let's not let that stop
> us from dropping support for it.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmVirtPkg/ArmVirtQemu.dsc   | 2 --
>  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 -
>  ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 --
>  3 files changed, 5 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index e23a6d17bc44..2e6e76224987 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -57,7 +57,6 @@
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>
> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> -  
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>
> FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
>
> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
> @@ -357,7 +356,6 @@
>#
># Video support
>#
> -  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>OvmfPkg/PlatformDxe/Platform.inf
>
> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc 
> b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> index 237b2d03a714..3194aa3edc8e 100644
> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> @@ -167,7 +167,6 @@ READ_LOCK_STATUS   = TRUE
>#
># Video support
>#
> -  INF OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>INF OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>INF OvmfPkg/PlatformDxe/Platform.inf
>
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc 
> b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index aa01debfda69..69de887277cb 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -57,7 +57,6 @@
>BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
>
> PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>
> CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> -  
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
>QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
>
> FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
>
> PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
> @@ -348,7 +347,6 @@
>#
># Video support
>#
> -  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>OvmfPkg/PlatformDxe/Platform.inf
>
>

 (My R-b stands; these are comments for a possible followup patch.)

 Please see:

 - commit 84a75f70e903 ("OvmfPkg/QemuVideoDxe: ena

Re: [edk2] [Patch] BaseTools: Add the missing -pie link option in GCC tool chain

[Gao, Liming]

Laszlo:
  Thanks for your quick test. I will add Bugzilla in commit log. And, I will 
let you know once I push this patch. 

Thanks
Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, August 23, 2017 6:27 PM
> To: Gao, Liming 
> Cc: edk2-devel@lists.01.org; Shi, Steven ; Paolo 
> Bonzini ; Ard Biesheuvel
> ; Justen, Jordan L ; 
> Kinney, Michael D 
> Subject: Re: [edk2] [Patch] BaseTools: Add the missing -pie link option in 
> GCC tool chain
> 
> Hi Liming,
> 
> On 08/23/17 10:04, Liming Gao wrote:
> > GCC tool chain uses -fpie in CC_FLAGS. So, add -pie in DLINK_FLAGS.
> >
> > More discussion in
> > https://lists.01.org/pipermail/edk2-devel/2017-August/013508.html
> >
> > 3.13 Options for Linking
> > 
> > '-pie'
> >  Produce a position independent executable on targets that support
> >  it.  For predictable results, you must also specify the same set
> >  of options used for compilation ('-fpie', '-fPIE', or model
> >  suboptions) when you specify this linker option.
> >
> > 3.18 Options for Code Generation Conventions
> > 
> > '-fpie'
> > '-fPIE'
> >  These options are similar to '-fpic' and '-fPIC', but generated
> >  position independent code can be only linked into executables.
> >  Usually these options are used when '-pie' GCC option is used
> >  during linking.
> >  '-fpie' and '-fPIE' both define the macros '__pie__' and
> >  '__PIE__'. The macros have the value 1 for '-fpie' and 2 for
> >  '-fPIE'.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Liming Gao 
> > ---
> >  BaseTools/Conf/tools_def.template | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/BaseTools/Conf/tools_def.template 
> > b/BaseTools/Conf/tools_def.template
> > index 6076a69..aff0cbd 100755
> > --- a/BaseTools/Conf/tools_def.template
> > +++ b/BaseTools/Conf/tools_def.template
> > @@ -4502,7 +4502,7 @@ DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib 
> > -Wl,-n,-q,--gc-sections -z comm
> >  DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
> > -Wl,--entry,ReferenceAcpiTable -u
> ReferenceAcpiTable
> >  DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
> > -Wl,--entry,$(IMAGE_ENTRY_POINT) -u
> $(IMAGE_ENTRY_POINT) -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
> >  DEFINE GCC44_IA32_DLINK2_FLAGS   = 
> > -Wl,--defsym=PECOFF_HEADER_SIZE=0x220 DEF(GCC_DLINK2_FLAGS_COMMON)
> > -DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) 
> > -Wl,-melf_x86_64,--oformat=elf64-x86-64
> > +DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS)
> -Wl,-melf_x86_64,--oformat=elf64-x86-64,-pie
> >  DEFINE GCC44_X64_DLINK2_FLAGS= 
> > -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 DEF(GCC_DLINK2_FLAGS_COMMON)
> >  DEFINE GCC44_ASM_FLAGS   = DEF(GCC_ASM_FLAGS)
> >
> > @@ -4582,7 +4582,7 @@ DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib 
> > -Wl,-n,-q,--gc-sections -z comm
> >  DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
> > -Wl,--entry,ReferenceAcpiTable -u
> ReferenceAcpiTable
> >  DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC49_IA32_X64_DLINK_COMMON) 
> > -Wl,--entry,$(IMAGE_ENTRY_POINT) -u
> $(IMAGE_ENTRY_POINT) -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
> >  DEFINE GCC49_IA32_DLINK2_FLAGS   = DEF(GCC48_IA32_DLINK2_FLAGS)
> > -DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) 
> > -Wl,-melf_x86_64,--oformat=elf64-x86-64
> > +DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS)
> -Wl,-melf_x86_64,--oformat=elf64-x86-64,-pie
> >  DEFINE GCC49_X64_DLINK2_FLAGS= DEF(GCC48_X64_DLINK2_FLAGS)
> >  DEFINE GCC49_ASM_FLAGS   = DEF(GCC48_ASM_FLAGS)
> >  DEFINE GCC49_ARM_ASM_FLAGS   = DEF(GCC48_ARM_ASM_FLAGS)
> >
> 
> (1) you forgot to CC the participants of the previous thread :)
> 
> (2) Please add a reference to
>  to the commit message.
> 
> (3) I tested the GCC49_X64_DLINK_FLAGS change with the following
> commands, on Fedora 26 (the gcc version is "7.1.1 20170622 (Red Hat
> 7.1.1-3)"):
> 
> $ git clean -fdx
> $ git reset --hard
> $ . edksetup.sh --reconfig
> $ make -C "$EDK_TOOLS_PATH"
> $ build -a X64 -p OvmfPkg/OvmfPkgX64.dsc -t GCC5 -n 6 -b DEBUG
> $ qemu-system-x86_64 \
> -m 5120 \
> -smp 8 \
> -pflash Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd \
> -enable-kvm \
> -global isa-debugcon.iobase=0x402 \
> -debugcon file:debug-gcc5-64.fd.log \
> -net none
> 
> The resultant OVMF binary works fine. (The UEFI shell is reached OK.)
> 
> (4) I regression-tested the GCC44_X64_DLINK_FLAGS change on RHEL-7.4,
> using "gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)". No regressions were
> found.
> 
> Tested-by: Laszlo Ersek 
> Reviewed-by: Laszlo Ersek 
> 
> (5) When you p

Re: [edk2] [PATCH] ArmVirtPkg: remove QemuVideoDxe from ArmVirtQemu and ArmVirtQemuKernel

[Leif Lindholm]

On Wed, Aug 23, 2017 at 03:36:37PM +0200, Laszlo Ersek wrote:
> On 08/23/17 15:17, Ard Biesheuvel wrote:
>  (My R-b stands; these are comments for a possible followup patch.)
> 
>  Please see:
> 
>  - commit 84a75f70e903 ("OvmfPkg/QemuVideoDxe: enable ARM builds",
>  2015-02-23),
> 
>  - commit 05a537945872 ("OvmfPkg/QemuVideoDxe: Helper functions for
>  unaligned port I/O.", 2017-04-07)?
> 
>  In my opinion, we should now revert parts of these commits, in one
>  followup patch:
> 
>  - from the first commit, we should revert only the "VALID_ARCHITECTURES"
>  comment change (the rest is built upon by the second commit, and should
>  be preserved)
> 
>  - from the second commit, we should revert the addition of [Sources.ARM,
>  Sources.AARCH64].
> 
>  This boils down to removing ARM and AARCH64 references from the
>  QemuVideoDxe.inf file. If you agree, could you please submit such a
>  followup patch?
> >>>
> >>> Sure, but pending the graphical GRUB discussion.
> >>
> >> So, after looking at the GRUB code, I am leaning towards agreeing that
> >> this is actually not a problem at all ... probably. The efi_gop driver
> >> does a Blt() of the entire screen from an off-screen buffer for all
> >> updates _unless_ it fails to allocate that off-screen buffer.
> >>
> >> So, basically, if you run out of memory at that point, it will try to
> >> preserve a way to get messages out about that. I will send a question
> >> out to grub-devel regarding this behaviour.
> >>
> >> However, looking at the specification, a question remains over how
> >> software can determine whether direct FB access is possible. I mean, a
> >> value of 0 seems like a decent hint, but the spec says nothing on the
> >> topic.
> >>
> > 
> > It will assume the FB is accessible unless the pixel format is PixelBltOnly
> > 
> 
> Correct, the UEFI spec (v2.7) says in "12.9 Graphics Output Protocol":
> 
>   PixelBltOnly  This mode does not support a physical frame buffer.
> 
> and
> 
>   PixelFormat   Enumeration that defines the physical format of the
> pixel. A value of PixelBltOnly implies that a linear
> frame buffer is not available for this mode.

-ETOOMANYLEVELSOFINDIRECTION
Right, so that's a non-issue.

Hopefully, that means other operating systems can also deal with the
lack.

> IIRC simply recognizing and accepting this enum constant was the point
> of Alex's patch.

Ah, yes, that makes sense now.
It's a bit surprising things work without this patch, but GRUBs
fallback seems to match anyway.

/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V2] IntelFsp2Pkg: Fix build error with WHOLEARCHIVE option

[Kinney, Michael D]

Liming,

Yes. "empty" is a better term to use.

Mike

> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, August 22, 2017 7:35 PM
> To: Kinney, Michael D ; Song, BinX
> ; Yao, Jiewen ;
> Kinney, Michael D 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [PATCH V2] IntelFsp2Pkg: Fix build error with
> WHOLEARCHIVE option
> 
> Mike:
>   TempRamInitApi() is referred in
> Library\SecFspSecPlatformLibNull\Ia32\Flat32.nasm. FspSecCoreM,
> FspSecCoreS and FspSecCoreT all link this library.
> 
>   How about describe this function as the empty implementation?
> 
> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> Behalf Of
> >Kinney, Michael D
> >Sent: Wednesday, August 23, 2017 6:27 AM
> >To: Song, BinX ; Yao, Jiewen
> ;
> >Kinney, Michael D 
> >Cc: edk2-devel@lists.01.org
> >Subject: Re: [edk2] [PATCH V2] IntelFsp2Pkg: Fix build error
> with
> >WHOLEARCHIVE option
> >
> >Bell Song,
> >
> >Why is it documented as a "Dummy" function?
> >
> >There must be a reference to this symbol somewhere or it would
> >not generate a link error.  The implementation is an empty
> >function.  Is that a better way to describe this function?
> >
> >Mike
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> >> Behalf Of Song, BinX
> >> Sent: Sunday, August 20, 2017 11:35 PM
> >> To: Yao, Jiewen 
> >> Cc: edk2-devel@lists.01.org
> >> Subject: [edk2] [PATCH V2] IntelFsp2Pkg: Fix build error
> with
> >> WHOLEARCHIVE option
> >>
> >> V2:
> >> - Recover TempRamInitApi API and add dummy TempRamInitApi
> >> function to fix
> >>   build error with WHOLEARCHIVE option
> >>
> >> V1:
> >> - Delete useless external TempRamInitApi API to fix
> >> /WHOLEARCHIVE build
> >>   error with VS2015 tool chain
> >>
> >> Cc: Jiewen Yao 
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Bell Song 
> >> ---
> >>  IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm | 10
> ++
> >>  IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryS.nasm | 10
> ++
> >>  2 files changed, 20 insertions(+)
> >>
> >> diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm
> >> b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm
> >> index 9744e16..81b531e 100644
> >> --- a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm
> >> +++ b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryM.nasm
> >> @@ -195,6 +195,16 @@ ASM_PFX(AsmGetPeiCoreOffset):
> >> ret
> >>
> >>  ;--
> 
> >> --
> >> +; TempRamInit API
> >> +;
> >> +; Dummy function for VS2015 WHOLEARCHIVE build option
> >> +;
> >> +;--
> 
> >> --
> >> +global ASM_PFX(TempRamInitApi)
> >> +ASM_PFX(TempRamInitApi):
> >> +  ret
> >> +
> >> +;--
> 
> >> --
> >>  ; Module Entrypoint API
> >>  ;--
> 
> >> --
> >>  global ASM_PFX(_ModuleEntryPoint)
> >> diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryS.nasm
> >> b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryS.nasm
> >> index cdc1149..06a791f 100644
> >> --- a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryS.nasm
> >> +++ b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryS.nasm
> >> @@ -54,6 +54,16 @@ ASM_PFX(FspApiCommonContinue):
> >>ret
> >>
> >>  ;--
> 
> >> --
> >> +; TempRamInit API
> >> +;
> >> +; Dummy function for VS2015 WHOLEARCHIVE build option
> >> +;
> >> +;--
> 
> >> --
> >> +global ASM_PFX(TempRamInitApi)
> >> +ASM_PFX(TempRamInitApi):
> >> +  ret
> >> +
> >> +;--
> 
> >> --
> >>  ; Module Entrypoint API
> >>  ;--
> 
> >> --
> >>  global ASM_PFX(_ModuleEntryPoint)
> >> --
> >> 2.10.2.windows.1
> >>
> >> ___
> >> edk2-devel mailing list
> >> edk2-devel@lists.01.org
> >> https://lists.01.org/mailman/listinfo/edk2-devel
> >___
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 01/23] OvmfPkg: introduce IOMMU-like member functions to VIRTIO_DEVICE_PROTOCOL

[Laszlo Ersek]

On 08/23/17 14:22, Brijesh Singh wrote:
> The patch extends VIRTIO_DEVICE_PROTOCOL to provide the following new
> member functions:
> 
> - AllocateSharedPages : allocate a memory region suitable for sharing
>between guest and hypervisor (e.g ring buffer).
> 
> - FreeSharedPages: free the memory allocated using AllocateSharedPages ().
> 
> - MapSharedBuffer: map a host address to device address suitable to share
>with device for bus master operations.
> 
> - UnmapSharedBuffer: unmap the device address obtained through the
>MapSharedBuffer().
> 
> We're free to extend the protocol structure without changing the protocol
> GUID, or bumping any protocol version fields (of which we currently have
> none), because VIRTIO_DEVICE_PROTOCOL is internal to edk2 by design --
> see the disclaimers in "VirtioDevice.h".
> 
> The patch implements Laszlo's recommendation [1].
> 
> [1] 
> 841bec5f-6f6e-8b1f-25ba-0fd37a915b72@redhat.com">http://mid.mail-archive.com/841bec5f-6f6e-8b1f-25ba-0fd37a915b72@redhat.com
> 
> Suggested-by: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Include/Protocol/VirtioDevice.h | 143 
>  1 file changed, 143 insertions(+)

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> diff --git a/OvmfPkg/Include/Protocol/VirtioDevice.h 
> b/OvmfPkg/Include/Protocol/VirtioDevice.h
> index fc166bd1a2b4..9a01932958a2 100644
> --- a/OvmfPkg/Include/Protocol/VirtioDevice.h
> +++ b/OvmfPkg/Include/Protocol/VirtioDevice.h
> @@ -5,6 +5,7 @@
>and should not be used outside of the EDK II tree.
>  
>Copyright (c) 2013, ARM Ltd. All rights reserved.
> +  Copyright (c) 2017, AMD Inc, All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -33,6 +34,25 @@
>  
>  typedef struct _VIRTIO_DEVICE_PROTOCOL  VIRTIO_DEVICE_PROTOCOL;
>  
> +//
> +// VIRTIO Operation for VIRTIO_MAP_SHARED
> +//
> +typedef enum {
> +  //
> +  // A read operation from system memory by a bus master
> +  //
> +  VirtioOperationBusMasterRead,
> +  //
> +  // A write operation to system memory by a bus master
> +  //
> +  VirtioOperationBusMasterWrite,
> +  //
> +  // Provides both read and write access to system memory by both the
> +  // processor and a bus master
> +  //
> +  VirtioOperationBusMasterCommonBuffer,
> +} VIRTIO_MAP_OPERATION;
> +
>  /**
>  
>Read a word from the device-specific I/O region of the Virtio Header.
> @@ -321,6 +341,121 @@ EFI_STATUS
>IN UINT8   DeviceStatus
>);
>  
> +/**
> +
> +  Allocates pages that are suitable for an 
> VirtioOperationBusMasterCommonBuffer
> +  mapping. This means that the buffer allocated by this function supports
> +  simultaneous access by both the processor and the bus master. The device
> +  address that the bus master uses to access the buffer must be retrieved 
> with
> +  a call to VIRTIO_MAP_SHARED.
> +
> +  @param[in]  This  The protocol instance pointer.
> +
> +  @param[in]  Pages The number of pages to allocate.
> +
> +  @param[in,out]  HostAddress   A pointer to store the system memory base
> +address of the allocated range.
> +
> +  @retval EFI_SUCCESS   The requested memory pages were 
> allocated.
> +  @retval EFI_OUT_OF_RESOURCES  The memory pages could not be allocated.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *VIRTIO_ALLOCATE_SHARED)(
> +  IN VIRTIO_DEVICE_PROTOCOL   *This,
> +  IN UINTNPages,
> +  IN OUT VOID **HostAddress
> +  );
> +
> +/**
> +  Frees memory that was allocated with VIRTIO_ALLOCATE_SHARED.
> +
> +  @param[in]  This   The protocol instance pointer.
> +
> +  @param[in]  Pages  The number of pages to free.
> +
> +  @param[in]  HostAddressThe system memory base address of the allocated
> + range.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *VIRTIO_FREE_SHARED)(
> +  IN  VIRTIO_DEVICE_PROTOCOL   *This,
> +  IN  UINTNPages,
> +  IN  VOID *HostAddress
> +  );
> +
> +/**
> +  Provides the virtio device address required to access system memory from a
> +  DMA bus master.
> +
> +  The interface follows the same usage pattern as defined in UEFI spec 2.6
> +  (Section 13.2 PCI Root Bridge I/O Protocol)
> +
> +  @param[in] This The protocol instance pointer.
> +
> +  @param[in] OperationIndicates if the bus master is going to
> +  read or write to system memory.
> +
> +  @param[in] HostAddress  The system memory address to map to shared
> +  

Re: [edk2] [PATCH v3 02/23] OvmfPkg/Virtio10Dxe: implement IOMMU-like member functions

[Laszlo Ersek]

On 08/23/17 14:22, Brijesh Singh wrote:
> The patch implements the newly added IOMMU-like member functions by
> respectively delegating the job to:
> 
> - VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages() ->
> EFI_PCI_IO_PROTOCOL.AllocateBuffer()
> 
> - VIRTIO_DEVICE_PROTOCOL.FreeSharedPages() ->
> EFI_PCI_IO_PROTOCOL.FreeBuffer()
> 
> - VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() ->
> EFI_PCI_IO_PROTOCOL.Map()
> 
> - VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() ->
> EFI_PCI_IO_PROTOCOL.Unmap()
> 
> Suggested-by: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Virtio10Dxe/Virtio10.c | 122 +++-
>  1 file changed, 120 insertions(+), 2 deletions(-)

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> diff --git a/OvmfPkg/Virtio10Dxe/Virtio10.c b/OvmfPkg/Virtio10Dxe/Virtio10.c
> index d7ea4432bcb6..89ccac8c1c04 100644
> --- a/OvmfPkg/Virtio10Dxe/Virtio10.c
> +++ b/OvmfPkg/Virtio10Dxe/Virtio10.c
> @@ -2,6 +2,7 @@
>A non-transitional driver for VirtIo 1.0 PCI devices.
>  
>Copyright (C) 2016, Red Hat, Inc.
> +  Copyright (C) 2017, AMD Inc, All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -15,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -772,6 +774,117 @@ Virtio10ReadDevice (
>return Status;
>  }
>  
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +Virtio10AllocateSharedPages (
> +  IN VIRTIO_DEVICE_PROTOCOL  *This,
> +  IN UINTN   Pages,
> +  IN OUT VOID**HostAddress
> +  )
> +{
> +  VIRTIO_1_0_DEV *Dev;
> +  EFI_STATUS Status;
> +
> +  Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
> +
> +  Status = Dev->PciIo->AllocateBuffer (
> + Dev->PciIo,
> + AllocateAnyPages,
> + EfiBootServicesData,
> + Pages,
> + HostAddress,
> + EFI_PCI_ATTRIBUTE_MEMORY_CACHED
> + );
> +  return Status;
> +}
> +
> +STATIC
> +VOID
> +EFIAPI
> +Virtio10FreeSharedPages (
> +  IN  VIRTIO_DEVICE_PROTOCOL  *This,
> +  IN  UINTN   Pages,
> +  IN  VOID*HostAddress
> +  )
> +{
> +  VIRTIO_1_0_DEV *Dev;
> +
> +  Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
> +
> +  Dev->PciIo->FreeBuffer (
> +Dev->PciIo,
> +Pages,
> +HostAddress
> +);
> +}
> +
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +Virtio10MapSharedBuffer (
> +  IN VIRTIO_DEVICE_PROTOCOL  *This,
> +  IN VIRTIO_MAP_OPERATIONOperation,
> +  IN VOID*HostAddress,
> +  IN OUT UINTN   *NumberOfBytes,
> +  OUTEFI_PHYSICAL_ADDRESS*DeviceAddress,
> +  OUTVOID**Mapping
> +  )
> +{
> +  EFI_STATUSStatus;
> +  VIRTIO_1_0_DEV*Dev;
> +  EFI_PCI_IO_PROTOCOL_OPERATION PciIoOperation;
> +
> +  Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
> +
> +  //
> +  // Map VIRTIO_MAP_OPERATION to EFI_PCI_IO_PROTOCOL_OPERATION
> +  //
> +  switch (Operation) {
> +  case VirtioOperationBusMasterRead:
> +PciIoOperation = EfiPciIoOperationBusMasterRead;
> +break;
> +  case VirtioOperationBusMasterWrite:
> +PciIoOperation = EfiPciIoOperationBusMasterWrite;
> +break;
> +  case VirtioOperationBusMasterCommonBuffer:
> +PciIoOperation = EfiPciIoOperationBusMasterCommonBuffer;
> +break;
> +  default:
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  Status = Dev->PciIo->Map (
> + Dev->PciIo,
> + PciIoOperation,
> + HostAddress,
> + NumberOfBytes,
> + DeviceAddress,
> + Mapping
> + );
> +  return Status;
> +}
> +
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +Virtio10UnmapSharedBuffer (
> +  IN  VIRTIO_DEVICE_PROTOCOL  *This,
> +  IN  VOID*Mapping
> +  )
> +{
> +  EFI_STATUS  Status;
> +  VIRTIO_1_0_DEV  *Dev;
> +
> +  Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
> +
> +  Status = Dev->PciIo->Unmap (
> + Dev->PciIo,
> + Mapping
> + );
> +
> +  return Status;
> +}
>  
>  STATIC CONST VIRTIO_DEVICE_PROTOCOL mVirtIoTemplate = {
>VIRTIO_SPEC_REVISION (1, 0, 0),
> @@ -788,7 +901,11 @@ STATIC CONST VIRTIO_DEVICE_PROTOCOL mVirtIoTemplate = {
>Virtio10GetDeviceStatus,
>Virtio10SetDeviceStatus,
>Virtio10WriteDevice,
> -  Virtio10ReadDevice
> +  Virtio10ReadDevice,
> +  Virtio10AllocateSharedPages,
> +  Virtio10FreeSharedPages,
> +  Virtio10MapSharedBuffer,
> +  Virt

Re: [edk2] [PATCH v3 03/23] OvmfPkg/VirtioPciDeviceDxe: implement IOMMU-like member functions

[Laszlo Ersek]

On 08/23/17 14:22, Brijesh Singh wrote:
> The patch implements the newly added IOMMU-like member functions by
> respectively delegating the job to:
> 
> - VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages () ->
> MemoryAllocationLib.AllocatePages()
> 
> - VIRTIO_DEVICE_PROTOCOL.FreeSharedPages () ->
> MemoryAllocationLib.FreePages ()
> 
> - VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer () -> no-op
> 
> - VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer () -> no-op
> 
> Suggested-by: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h| 34 
>  OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c|  7 ++-
>  OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c | 58 
>  3 files changed, 98 insertions(+), 1 deletion(-)

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> diff --git a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h 
> b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h
> index 6f51f816ef0f..41df5a98e560 100644
> --- a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h
> +++ b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h
> @@ -3,6 +3,7 @@
>Internal definitions for the VirtIo PCI Device driver
>  
>Copyright (C) 2013, ARM Ltd
> +  Copyright (c) 2017, AMD Inc, All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -156,4 +157,37 @@ VirtioPciSetDeviceStatus (
>IN  UINT8  DeviceStatus
>);
>  
> +EFI_STATUS
> +EFIAPI
> +VirtioPciAllocateSharedPages (
> +  IN  VIRTIO_DEVICE_PROTOCOL*This,
> +  IN  UINTN NumPages,
> +  OUT VOID  **HostAddress
> +  );
> +
> +VOID
> +EFIAPI
> +VirtioPciFreeSharedPages (
> +  IN  VIRTIO_DEVICE_PROTOCOL*This,
> +  IN  UINTN NumPages,
> +  IN  VOID  *HostAddress
> +  );
> +
> +EFI_STATUS
> +EFIAPI
> +VirtioPciMapSharedBuffer (
> +  IN  VIRTIO_DEVICE_PROTOCOL*This,
> +  IN  VIRTIO_MAP_OPERATION  Operation,
> +  IN  VOID  *HostAddress,
> +  IN OUT  UINTN *NumberOfBytes,
> +  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
> +  OUT VOID  **Mapping
> +  );
> +
> +EFI_STATUS
> +EFIAPI
> +VirtioPciUnmapSharedBuffer (
> +  IN  VIRTIO_DEVICE_PROTOCOL*This,
> +  IN  VOID  *Mapping
> +  );
>  #endif // _VIRTIO_PCI_DEVICE_DXE_H_
> diff --git a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c 
> b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c
> index 8aae58e8b482..d4b4ec21c34d 100644
> --- a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c
> +++ b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.c
> @@ -5,6 +5,7 @@
>Copyright (C) 2012, Red Hat, Inc.
>Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
>Copyright (C) 2013, ARM Ltd.
> +  Copyright (C) 2017, AMD Inc, All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -40,7 +41,11 @@ STATIC VIRTIO_DEVICE_PROTOCOL mDeviceProtocolTemplate = {
>VirtioPciGetDeviceStatus, // GetDeviceStatus
>VirtioPciSetDeviceStatus, // SetDeviceStatus
>VirtioPciDeviceWrite, // WriteDevice
> -  VirtioPciDeviceRead   // ReadDevice
> +  VirtioPciDeviceRead,  // ReadDevice
> +  VirtioPciAllocateSharedPages, // AllocateSharedPages
> +  VirtioPciFreeSharedPages, // FreeSharedPages
> +  VirtioPciMapSharedBuffer, // MapSharedBuffer
> +  VirtioPciUnmapSharedBuffer,   // UnmapSharedBuffer
>  };
>  
>  /**
> diff --git a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c 
> b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c
> index 5f86914265ea..bd912cca9b29 100644
> --- a/OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c
> +++ b/OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c
> @@ -5,6 +5,7 @@
>Copyright (C) 2012, Red Hat, Inc.
>Copyright (c) 2012, Intel Corporation. All rights reserved.
>Copyright (C) 2013, ARM Ltd.
> +  Copyright (C) 2017, AMD Inc, All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -271,3 +272,60 @@ VirtioPciSetDeviceStatus (
>return VirtioPciIoWrite (Dev, VIRTIO_PCI_OFFSET_QUEUE_DEVICE_STATUS,
>sizeof (UINT8), DeviceStatus);
>  }
> +
> +EFI_STATUS
> +EFIAPI
> +VirtioPciAllocateSharedPages (
> +  IN  VIRTIO_DEVICE_PROTOCOL  *This,
> +  IN  UINTN   NumPages,
> +  OUT VOID**HostAddress
> +  )
> +{
> 

Re: [edk2] [PATCH v3 04/23] OvmfPkg/VirtioMmioDeviceLib: implement IOMMU-like member functions

[Laszlo Ersek]

On 08/23/17 14:22, Brijesh Singh wrote:
> The patch implements the newly added IOMMU-like member functions by
> respectively delegating the job to:
> 
> - VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages () ->
> MemoryAllocationLib.AllocatePages()
> 
> - VIRTIO_DEVICE_PROTOCOL.FreeSharedPages () ->
> MemoryAllocationLib.FreePages ()
> 
> - VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer () -> no-op
> 
> - VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer () -> no-op
> 
> Suggested-by: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h  | 36 
> +
>  OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c  |  8 ++-
>  OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c | 57 
> 
>  3 files changed, 99 insertions(+), 2 deletions(-)

Reviewed-by: Laszlo Ersek 

Thanks,
Laszlo

> diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h 
> b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h
> index bedd635e1a86..e5881d537f09 100644
> --- a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h
> +++ b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h
> @@ -3,6 +3,7 @@
>Internal definitions for the VirtIo MMIO Device driver
>  
>Copyright (C) 2013, ARM Ltd
> +  Copyright (C) 2017, AMD Inc. All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -25,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define VIRTIO_MMIO_DEVICE_SIGNATURE  SIGNATURE_32 ('V', 'M', 'I', 'O')
>  
> @@ -137,4 +139,38 @@ VirtioMmioSetGuestFeatures (
>IN UINT64  Features
>);
>  
> +EFI_STATUS
> +EFIAPI
> +VirtioMmioAllocateSharedPages (
> +  IN  VIRTIO_DEVICE_PROTOCOL*This,
> +  IN  UINTN NumPages,
> +  OUT VOID  **HostAddress
> +  );
> +
> +VOID
> +EFIAPI
> +VirtioMmioFreeSharedPages (
> +  IN  VIRTIO_DEVICE_PROTOCOL*This,
> +  IN  UINTN NumPages,
> +  IN  VOID  *HostAddress
> +  );
> +
> +EFI_STATUS
> +EFIAPI
> +VirtioMmioMapSharedBuffer (
> +  IN  VIRTIO_DEVICE_PROTOCOL*This,
> +  IN  VIRTIO_MAP_OPERATION  Operation,
> +  IN  VOID  *HostAddress,
> +  IN OUT  UINTN *NumberOfBytes,
> +  OUT EFI_PHYSICAL_ADDRESS  *DeviceAddress,
> +  OUT VOID  **Mapping
> +  );
> +
> +EFI_STATUS
> +EFIAPI
> +VirtioMmioUnmapSharedBuffer (
> +  IN  VIRTIO_DEVICE_PROTOCOL*This,
> +  IN  VOID  *Mapping
> +  );
> +
>  #endif // _VIRTIO_MMIO_DEVICE_INTERNAL_H_
> diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c 
> b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c
> index b1d443ea7007..fce934e1e953 100644
> --- a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c
> +++ b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.c
> @@ -3,6 +3,7 @@
>This driver produces Virtio Device Protocol instances for Virtio Mmio 
> devices.
>  
>Copyright (C) 2013, ARM Ltd.
> +  Copyright (C) 2017, AMD Inc. All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -15,7 +16,6 @@
>  **/
>  
>  #include 
> -#include 
>  #include 
>  
>  #include "VirtioMmioDevice.h"
> @@ -35,7 +35,11 @@ static VIRTIO_DEVICE_PROTOCOL mMmioDeviceProtocolTemplate 
> = {
>  VirtioMmioGetDeviceStatus, // GetDeviceStatus
>  VirtioMmioSetDeviceStatus, // SetDeviceStatus
>  VirtioMmioDeviceWrite, // WriteDevice
> -VirtioMmioDeviceRead   // ReadDevice
> +VirtioMmioDeviceRead,  // ReadDevice
> +VirtioMmioAllocateSharedPages, // AllocateSharedPages
> +VirtioMmioFreeSharedPages, // FreeSharedPages
> +VirtioMmioMapSharedBuffer, // MapSharedBuffer
> +VirtioMmioUnmapSharedBuffer// UnmapSharedBuffer
>  };
>  
>  /**
> diff --git a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c 
> b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
> index 9142d4a162c0..644ec65e1788 100644
> --- a/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
> +++ b/OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c
> @@ -293,3 +293,60 @@ VirtioMmioDeviceRead (
>  
>return EFI_SUCCESS;
>  }
> +
> +EFI_STATUS
> +EFIAPI
> +VirtioMmioAllocateSharedPages (
> +  IN  VIRTIO_DEVICE_PROTOCOL  *This,
> +  IN  UINTN   NumPages,
> +  OUT VOID**HostAdd

Re: [edk2] [PATCH v3 05/23] OvmfPkg/VirtioLib: add VirtioMapAllBytesInSharedBuffer() helper function

[Laszlo Ersek]

There are two trivial omissions in this patch:

On 08/23/17 14:22, Brijesh Singh wrote:
> The function can be used for mapping the system physical address to virtio
> device address using VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer (). The
> function helps with centralizing error handling, and it allows the caller
> to pass in constant or other evaluated expressions for NumberOfBytes.
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Include/Library/VirtioLib.h   | 52 
>  OvmfPkg/Library/VirtioLib/VirtioLib.c | 85 
>  2 files changed, 137 insertions(+)
> 
> diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
> b/OvmfPkg/Include/Library/VirtioLib.h
> index 5badfb32917f..9ec9b91b59bb 100644
> --- a/OvmfPkg/Include/Library/VirtioLib.h
> +++ b/OvmfPkg/Include/Library/VirtioLib.h
> @@ -3,6 +3,7 @@
>Declarations of utility functions used by virtio device drivers.
>  
>Copyright (C) 2012-2016, Red Hat, Inc.
> +  Copyright (C) 2017, AMD Inc, All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -235,4 +236,55 @@ Virtio10WriteFeatures (
>IN OUT UINT8  *DeviceStatus
>);
>  
> +/**
> +  Provides the virtio device address required to access system memory from a
> +  DMA bus master.
> +
> +  The interface follows the same usage pattern as defined in UEFI spec 2.6
> +  (Section 13.2 PCI Root Bridge I/O Protocol)
> +
> +  The VirtioMapAllBytesInSharedBuffer() is similar to VIRTIO_MAP_SHARED
> +  with exception that NumberOfBytes is IN-only parameter. The function
> +  maps all the bytes specified in NumberOfBytes param in one consecutive
> +  range.
> +
> +  @param[in] This The virtio device for which the mapping is
> +  requested.

(1) The parameter is called "VirtIo", not "This". (In my previous
review, I proposed a replacement that covered both the parameter name
and the parameter documentation, and I think you updated only the
documentation.)

> +
> +  @param[in] OperationIndicates if the bus master is going to
> +  read or write to system memory.
> +
> +  @param[in] HostAddress  The system memory address to map to shared
> +  buffer address.
> +
> +  @param[in] NumberOfBytesNumber of bytes to map.
> +
> +  @param[out]DeviceAddressThe resulting shared map address for the
> +  bus master to access the hosts HostAddress.
> +
> +  @param[out]Mapping  A resulting token to pass to
> +  VIRTIO_UNMAP_SHARED.
> +
> +
> +  @retval EFI_SUCCESS The NumberOfBytes is succesfully mapped.
> +  @retval EFI_UNSUPPORTED The HostAddress cannot be mapped as a
> +  common buffer.
> +  @retval EFI_INVALID_PARAMETER   One or more parameters are invalid.
> +  @retval EFI_OUT_OF_RESOURCESThe request could not be completed due to
> +  a lack of resources. This includes the case
> +  when NumberOfBytes bytes cannot be mapped
> +  in one consecutive range.
> +  @retval EFI_DEVICE_ERRORThe system hardware could not map the
> +  requested address.
> +**/
> +EFI_STATUS
> +EFIAPI
> +VirtioMapAllBytesInSharedBuffer (
> +  IN  VIRTIO_DEVICE_PROTOCOL  *VirtIo,
> +  IN  VIRTIO_MAP_OPERATIONOperation,
> +  IN  VOID*HostAddress,
> +  IN  UINTN   NumberOfBytes,
> +  OUT EFI_PHYSICAL_ADDRESS*DeviceAddress,
> +  OUT VOID**Mapping
> +  );
>  #endif // _VIRTIO_LIB_H_
> diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
> b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> index 845f206369a3..c85cd8dba569 100644
> --- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
> +++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> @@ -4,6 +4,7 @@
>  
>Copyright (C) 2012-2016, Red Hat, Inc.
>Portion of Copyright (C) 2013, ARM Ltd.
> +  Copyright (C) 2017, AMD Inc, All rights reserved.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -414,3 +415,87 @@ Virtio10WriteFeatures (
>  
>return Status;
>  }
> +
> +/**
> +  Provides the virtio device address required to access system memory from a
> +  DMA bus master.
> +
> +  The interface follows the same usage pattern as defined in UEFI spec 2.6
> +  (Section 13.2 PCI Root Bridge I/O Protocol)
> +
> +  The VirtioMapAllBytesInSharedBuffer() is similar to VIRTIO_MAP_SHARED
> +  with exception that NumberOfBytes is IN-only param

Re: [edk2] [PATCH v3 09/23] OvmfPkg/VirtioLib: add function to map VRING

[Laszlo Ersek]

There's one trivial omission in this patch, wrt. the previous review
comments:

On 08/23/17 14:22, Brijesh Singh wrote:
> Add functions to map the ring buffer with BusMasterCommonBuffer so that

(1) s/functions/a function/

I'll fix it up before I push the initial subsequence.

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> ring can be accessed by both guest and hypervisor.
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Include/Library/VirtioLib.h   | 26 +++
>  OvmfPkg/Library/VirtioLib/VirtioLib.c | 45 
>  2 files changed, 71 insertions(+)
> 
> diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
> b/OvmfPkg/Include/Library/VirtioLib.h
> index 40c51a2b3305..3d9314b3acaf 100644
> --- a/OvmfPkg/Include/Library/VirtioLib.h
> +++ b/OvmfPkg/Include/Library/VirtioLib.h
> @@ -62,6 +62,32 @@ VirtioRingInit (
>  
>  /**
>  
> +  Map the ring buffer so that it can be accessed equally by both guest
> +  and hypervisor.
> +
> +  @param[in]  VirtIo  The virtio device instance.
> +
> +  @param[in]  RingThe virtio ring to map.
> +
> +  @param[out] RingBaseShift   A resulting translation offset, to be
> +  passed to VirtIo->SetQueueAddress().
> +
> +  @param[out] Mapping A resulting token to pass to
> +  VirtIo->UnmapSharedBuffer().
> +
> +  @return Status code from VirtIo->MapSharedBuffer()
> +**/
> +EFI_STATUS
> +EFIAPI
> +VirtioRingMap (
> +  IN  VIRTIO_DEVICE_PROTOCOL *VirtIo,
> +  IN  VRING  *Ring,
> +  OUT UINT64 *RingBaseShift,
> +  OUT VOID   **Mapping
> +  );
> +
> +/**
> +
>Tear down the internal resources of a configured virtio ring.
>  
>The caller is responsible to stop the host from using this ring before
> diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
> b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> index 8bc5b9aea4fc..535635ac0ba8 100644
> --- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
> +++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> @@ -505,3 +505,48 @@ Failed:
>VirtIo->UnmapSharedBuffer (VirtIo, MapInfo);
>return EFI_OUT_OF_RESOURCES;
>  }
> +
> +/**
> +
> +  Map the ring buffer so that it can be accessed equally by both guest
> +  and hypervisor.
> +
> +  @param[in]  VirtIo  The virtio device instance.
> +
> +  @param[in]  RingThe virtio ring to map.
> +
> +  @param[out] RingBaseShift   A resulting translation offset, to be
> +  passed to VirtIo->SetQueueAddress().
> +
> +  @param[out] Mapping A resulting token to pass to
> +  VirtIo->UnmapSharedBuffer().
> +
> +  @return Status code from VirtIo->MapSharedBuffer()
> +**/
> +EFI_STATUS
> +EFIAPI
> +VirtioRingMap (
> +  IN  VIRTIO_DEVICE_PROTOCOL *VirtIo,
> +  IN  VRING  *Ring,
> +  OUT UINT64 *RingBaseShift,
> +  OUT VOID   **Mapping
> +  )
> +{
> +  EFI_STATUSStatus;
> +  EFI_PHYSICAL_ADDRESS  DeviceAddress;
> +
> +  Status = VirtioMapAllBytesInSharedBuffer (
> + VirtIo,
> + VirtioOperationBusMasterCommonBuffer,
> + Ring->Base,
> + EFI_PAGES_TO_SIZE (Ring->NumPages),
> + &DeviceAddress,
> + Mapping
> + );
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  *RingBaseShift = DeviceAddress - (UINT64)(UINTN)Ring->Base;
> +  return EFI_SUCCESS;
> +}
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 07/23] OvmfPkg/Virtio: take RingBaseShift in SetQueueAddress()

[Laszlo Ersek]

On 08/23/17 14:22, Brijesh Singh wrote:
> For the case when an IOMMU is used for translating system physical
> addresses to DMA bus master addresses, the transport-independent
> virtio device drivers will be required to map their VRING areas to
> bus addresses with VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() calls.
> 
> VirtioRingMap() maps the ring buffer system physical to a bus address.
> When an IOMMU is used for translating the address then bus address can
> start at a different offset from the system physical address.

(1) The paragraph that you now have as first paragraph above was my
suggestion, so thank you for picking it up. However, the second
paragraph should have been deleted; I suggested the now-first paragraph
as a replacement for the now-second one.

I wrote, "to keep our references within the virtio device protocol".
VirtioRingMap() is a VirtioLib function, which is a utility layer on top
of the virtio device protocol. So, as I said, VirtioLib patches may
refer to both VirtioLib and the protocol, but protocol patches should
preferably only refer to the protocol, and not VirtioLib.

  VirtioLib --+
   |  ^   |
   |  |   |
   |  +---+
   |
   v
  VirtioDeviceProtocol --+
^|
||
++

This is also consistent with the reordering of the patches that I asked
for (and that you implemented well in v3, thank you for it).

So, apologies if I wasn't clear enough of this -- it's not a big deal at
all, I can remove the second paragraph when I push this.

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> 
> - MMIO and legacy virtio transport do not support IOMMU to translate the
>   addresses hence RingBaseShift will always be set to zero.
> 
> - modern virtio transport supports IOMMU to translate the address, in
>   next patch we will update the Virtio10Dxe to use RingBaseShift offset.
> 
> Suggested-by: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Include/Protocol/VirtioDevice.h | 19 
> +--
>  OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h  |  3 ++-
>  OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h|  3 ++-
>  OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c |  5 -
>  OvmfPkg/Virtio10Dxe/Virtio10.c  |  5 -
>  OvmfPkg/VirtioBlkDxe/VirtioBlk.c|  2 +-
>  OvmfPkg/VirtioGpuDxe/Commands.c |  6 +-
>  OvmfPkg/VirtioNetDxe/SnpInitialize.c|  2 +-
>  OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c |  5 -
>  OvmfPkg/VirtioRngDxe/VirtioRng.c|  2 +-
>  OvmfPkg/VirtioScsiDxe/VirtioScsi.c  |  2 +-
>  11 files changed, 42 insertions(+), 12 deletions(-)
> 
> diff --git a/OvmfPkg/Include/Protocol/VirtioDevice.h 
> b/OvmfPkg/Include/Protocol/VirtioDevice.h
> index 9a01932958a2..2e3a6d6edf04 100644
> --- a/OvmfPkg/Include/Protocol/VirtioDevice.h
> +++ b/OvmfPkg/Include/Protocol/VirtioDevice.h
> @@ -156,7 +156,21 @@ EFI_STATUS
>@param[in] This This instance of VIRTIO_DEVICE_PROTOCOL
>  
>@param[in] Ring The initialized VRING object to take the
> -  addresses from.
> +  addresses from. The caller is responsible for
> +  ensuring that on input, all Ring->NumPages 
> pages,
> +  starting at Ring->Base, have been successfully
> +  mapped with a single call to
> +  This->MapSharedBuffer() for CommonBuffer bus
> +  master operation..
> +
> +  @param[in] RingBaseShiftAdding this value using UINT64 arithmetic to 
> the
> +  addresses found in Ring translates them from
> +  system memory to bus addresses. The caller 
> shall
> +  calculate RingBaseShift as
> +  (DeviceAddress - (UINT64)(UINTN)HostAddress),
> +  where DeviceAddress and HostAddress (i.e.,
> +  Ring->Base) were output and input parameters of
> +  This->MapSharedBuffer(), respectively.
>  
>@retval EFI_SUCCESS The data was written successfully.
>@retval EFI_UNSUPPORTED The underlying IO device doesn't support the
> @@ -166,7 +180,8 @@ typedef
>  EFI_STATUS
>  (EFIAPI *VIRTIO_SET_QUEUE_ADDRESS) (
>IN VIRTIO_DEVICE_PROTOCOL  *This,
> -  IN VRING   *Ring
> +  IN VRING   *Ring,
> +  IN UINT64  RingBaseShift
>);
>  
>  /**
> diff --git a/OvmfPkg/Library

Re: [edk2] [PATCH v3 07/23] OvmfPkg/Virtio: take RingBaseShift in SetQueueAddress()

[Laszlo Ersek]

On 08/23/17 22:41, Laszlo Ersek wrote:
> On 08/23/17 14:22, Brijesh Singh wrote:
>> For the case when an IOMMU is used for translating system physical
>> addresses to DMA bus master addresses, the transport-independent
>> virtio device drivers will be required to map their VRING areas to
>> bus addresses with VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() calls.
>>
>> VirtioRingMap() maps the ring buffer system physical to a bus address.
>> When an IOMMU is used for translating the address then bus address can
>> start at a different offset from the system physical address.
> 
> (1) The paragraph that you now have as first paragraph above was my
> suggestion, so thank you for picking it up. However, the second
> paragraph should have been deleted; I suggested the now-first paragraph
> as a replacement for the now-second one.
> 
> I wrote, "to keep our references within the virtio device protocol".
> VirtioRingMap() is a VirtioLib function, which is a utility layer on top
> of the virtio device protocol. So, as I said, VirtioLib patches may
> refer to both VirtioLib and the protocol, but protocol patches should
> preferably only refer to the protocol, and not VirtioLib.
> 
>   VirtioLib --+
>|  ^   |
>|  |   |
>|  +---+
>|
>v
>   VirtioDeviceProtocol --+
> ^|
> ||
> ++
> 
> This is also consistent with the reordering of the patches that I asked
> for (and that you implemented well in v3, thank you for it).
> 
> So, apologies if I wasn't clear enough of this -- it's not a big deal at
> all, I can remove the second paragraph when I push this.
> 
> Reviewed-by: Laszlo Ersek 
> 
> Thanks!
> Laszlo
> 
>>
>> - MMIO and legacy virtio transport do not support IOMMU to translate the
>>   addresses hence RingBaseShift will always be set to zero.
>>
>> - modern virtio transport supports IOMMU to translate the address, in
>>   next patch we will update the Virtio10Dxe to use RingBaseShift offset.
>>
>> Suggested-by: Laszlo Ersek 
>> Cc: Ard Biesheuvel 
>> Cc: Jordan Justen 
>> Cc: Tom Lendacky 
>> Cc: Laszlo Ersek 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Brijesh Singh 
>> ---
>>  OvmfPkg/Include/Protocol/VirtioDevice.h | 19 
>> +--
>>  OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDevice.h  |  3 ++-
>>  OvmfPkg/VirtioPciDeviceDxe/VirtioPciDevice.h|  3 ++-
>>  OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceFunctions.c |  5 -
>>  OvmfPkg/Virtio10Dxe/Virtio10.c  |  5 -
>>  OvmfPkg/VirtioBlkDxe/VirtioBlk.c|  2 +-
>>  OvmfPkg/VirtioGpuDxe/Commands.c |  6 +-
>>  OvmfPkg/VirtioNetDxe/SnpInitialize.c|  2 +-
>>  OvmfPkg/VirtioPciDeviceDxe/VirtioPciFunctions.c |  5 -
>>  OvmfPkg/VirtioRngDxe/VirtioRng.c|  2 +-
>>  OvmfPkg/VirtioScsiDxe/VirtioScsi.c  |  2 +-
>>  11 files changed, 42 insertions(+), 12 deletions(-)
>>
>> diff --git a/OvmfPkg/Include/Protocol/VirtioDevice.h 
>> b/OvmfPkg/Include/Protocol/VirtioDevice.h
>> index 9a01932958a2..2e3a6d6edf04 100644
>> --- a/OvmfPkg/Include/Protocol/VirtioDevice.h
>> +++ b/OvmfPkg/Include/Protocol/VirtioDevice.h
>> @@ -156,7 +156,21 @@ EFI_STATUS
>>@param[in] This This instance of VIRTIO_DEVICE_PROTOCOL
>>  
>>@param[in] Ring The initialized VRING object to take the
>> -  addresses from.
>> +  addresses from. The caller is responsible for
>> +  ensuring that on input, all Ring->NumPages 
>> pages,
>> +  starting at Ring->Base, have been successfully
>> +  mapped with a single call to
>> +  This->MapSharedBuffer() for CommonBuffer bus
>> +  master operation..

(2) I'll also remove one of the periods.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 07/23] OvmfPkg/Virtio: take RingBaseShift in SetQueueAddress()

[Brijesh Singh]

On 08/23/2017 03:43 PM, Laszlo Ersek wrote:

On 08/23/17 22:41, Laszlo Ersek wrote:

On 08/23/17 14:22, Brijesh Singh wrote:

For the case when an IOMMU is used for translating system physical
addresses to DMA bus master addresses, the transport-independent
virtio device drivers will be required to map their VRING areas to
bus addresses with VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() calls.

VirtioRingMap() maps the ring buffer system physical to a bus address.
When an IOMMU is used for translating the address then bus address can
start at a different offset from the system physical address.


(1) The paragraph that you now have as first paragraph above was my
suggestion, so thank you for picking it up. However, the second
paragraph should have been deleted; I suggested the now-first paragraph
as a replacement for the now-second one.

I wrote, "to keep our references within the virtio device protocol".
VirtioRingMap() is a VirtioLib function, which is a utility layer on top
of the virtio device protocol. So, as I said, VirtioLib patches may
refer to both VirtioLib and the protocol, but protocol patches should
preferably only refer to the protocol, and not VirtioLib.

   VirtioLib --+
|  ^   |
|  |   |
|  +---+
|
v
   VirtioDeviceProtocol --+
 ^|
 ||
 ++

This is also consistent with the reordering of the patches that I asked
for (and that you implemented well in v3, thank you for it).

So, apologies if I wasn't clear enough of this -- it's not a big deal at
all, I can remove the second paragraph when I push this.

Reviewed-by: Laszlo Ersek 



Thanks Laszlo, Sorry I did not realize that second paragraph should have been
deleted. Thanks for fixing.

-Brijesh

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 08/23] OvmfPkg/Virtio10Dxe: add the RingBaseShift offset

[Laszlo Ersek]

On 08/23/17 14:22, Brijesh Singh wrote:
> virtio drivers use VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() to map the
> ring buffer host address to a device address. If an IOMMU is present then
> RingBaseShift contains the offset from the host address.
> 
> Suggested-by: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Virtio10Dxe/Virtio10.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

> diff --git a/OvmfPkg/Virtio10Dxe/Virtio10.c b/OvmfPkg/Virtio10Dxe/Virtio10.c
> index ef9a00710668..e9b50b6e437b 100644
> --- a/OvmfPkg/Virtio10Dxe/Virtio10.c
> +++ b/OvmfPkg/Virtio10Dxe/Virtio10.c
> @@ -498,11 +498,10 @@ Virtio10SetQueueAddress (
>UINT64 Address;
>UINT16 Enable;
>  
> -  ASSERT (RingBaseShift == 0);
> -
>Dev = VIRTIO_1_0_FROM_VIRTIO_DEVICE (This);
>  
>Address = (UINTN)Ring->Desc;
> +  Address += RingBaseShift;
>Status = Virtio10Transfer (Dev->PciIo, &Dev->CommonConfig, TRUE,
>   OFFSET_OF (VIRTIO_PCI_COMMON_CFG, QueueDesc),
>   sizeof Address, &Address);
> @@ -511,6 +510,7 @@ Virtio10SetQueueAddress (
>}
>  
>Address = (UINTN)Ring->Avail.Flags;
> +  Address += RingBaseShift;
>Status = Virtio10Transfer (Dev->PciIo, &Dev->CommonConfig, TRUE,
>   OFFSET_OF (VIRTIO_PCI_COMMON_CFG, QueueAvail),
>   sizeof Address, &Address);
> @@ -519,6 +519,7 @@ Virtio10SetQueueAddress (
>}
>  
>Address = (UINTN)Ring->Used.Flags;
> +  Address += RingBaseShift;
>Status = Virtio10Transfer (Dev->PciIo, &Dev->CommonConfig, TRUE,
>   OFFSET_OF (VIRTIO_PCI_COMMON_CFG, QueueUsed),
>   sizeof Address, &Address);
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 10/23] OvmfPkg/VirtioLib: alloc VRING buffer with AllocateSharedPages()

[Laszlo Ersek]

On 08/23/17 14:22, Brijesh Singh wrote:
> The VRING buffer is a communication area between guest and hypervisor.
> Allocate it using VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages() so that
> it can be mapped later with VirtioRingMap() for bi-directional access.
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Library/VirtioLib/VirtioLib.inf |  1 -
>  OvmfPkg/Include/Library/VirtioLib.h |  5 ++---
>  OvmfPkg/Library/VirtioLib/VirtioLib.c   | 22 +---
>  3 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.inf 
> b/OvmfPkg/Library/VirtioLib/VirtioLib.inf
> index fb5897a88ecf..e33856de38c4 100644
> --- a/OvmfPkg/Library/VirtioLib/VirtioLib.inf
> +++ b/OvmfPkg/Library/VirtioLib/VirtioLib.inf
> @@ -32,5 +32,4 @@ [LibraryClasses]
>BaseLib
>BaseMemoryLib
>DebugLib
> -  MemoryAllocationLib
>UefiBootServicesTableLib
> diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
> b/OvmfPkg/Include/Library/VirtioLib.h
> index 3d9314b3acaf..c3e56ea23b89 100644
> --- a/OvmfPkg/Include/Library/VirtioLib.h
> +++ b/OvmfPkg/Include/Library/VirtioLib.h
> @@ -42,9 +42,8 @@
>  
>@param[out] Ring  The virtio ring to set up.
>  
> -  @retval EFI_OUT_OF_RESOURCES  AllocatePages() failed to allocate contiguous
> -pages for the requested QueueSize. Fields of
> -Ring have indeterminate value.
> +  @retval   Status codes propagated from
> +VirtIo->AllocateSharedPages().

(1) The documentation has been updated (thanks for that), but I also
requested "@return", not "@retval". Can be fixed up on push.

>  
>@retval EFI_SUCCESS   Allocation and setup successful. Ring->Base
>  (and nothing else) is responsible for
> diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
> b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> index 535635ac0ba8..e5366e385f5d 100644
> --- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
> +++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> @@ -19,7 +19,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> @@ -44,9 +43,8 @@
>  
>@param[out] Ring  The virtio ring to set up.
>  
> -  @retval EFI_OUT_OF_RESOURCES  AllocatePages() failed to allocate contiguous
> -pages for the requested QueueSize. Fields of
> -Ring have indeterminate value.
> +  @retval   Status codes propagated from
> +VirtIo->AllocateSharedPages().

(2) Same as (1), should be @return.

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo

>  
>@retval EFI_SUCCESS   Allocation and setup successful. Ring->Base
>  (and nothing else) is responsible for
> @@ -61,6 +59,7 @@ VirtioRingInit (
>OUT VRING  *Ring
>)
>  {
> +  EFI_STATUS Status;
>UINTN  RingSize;
>volatile UINT8 *RingPagesPtr;
>  
> @@ -79,10 +78,17 @@ VirtioRingInit (
>  sizeof *Ring->Used.AvailEvent,
>  EFI_PAGE_SIZE);
>  
> +  //
> +  // Allocate a shared ring buffer
> +  //
>Ring->NumPages = EFI_SIZE_TO_PAGES (RingSize);
> -  Ring->Base = AllocatePages (Ring->NumPages);
> -  if (Ring->Base == NULL) {
> -return EFI_OUT_OF_RESOURCES;
> +  Status = VirtIo->AllocateSharedPages (
> + VirtIo,
> + Ring->NumPages,
> + &Ring->Base
> + );
> +  if (EFI_ERROR (Status)) {
> +return Status;
>}
>SetMem (Ring->Base, RingSize, 0x00);
>RingPagesPtr = Ring->Base;
> @@ -143,7 +149,7 @@ VirtioRingUninit (
>IN OUT VRING  *Ring
>)
>  {
> -  FreePages (Ring->Base, Ring->NumPages);
> +  VirtIo->FreeSharedPages (VirtIo, Ring->NumPages, Ring->Base);
>SetMem (Ring, sizeof *Ring, 0x00);
>  }
>  
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Iscsi Specification Document

[Blibbet]

On 08/23/2017 02:04 AM, Karunakar P wrote:
> Do we have any specific Document for Iscsi?
> Any document that describes the standard iscsi behavior.

I'm not aware of any 'design specification', that may be hoping for too
much.

http://uefi.org/uefi points to 4 [i]SCSI-related URLs:

[RFC 3720] Internet Small Computer Systems Interface (iSCSI)

[RFC 4173] Bootstrapping Clients using the Internet Small Computer
System Interface (iSCSI) Protocol

iSCSI Boot Firmware Table (iBFT) 
http://www.microsoft.com/whdc/system/platform/firmware/ibft.mspx

SCSI Block Commands:
 http://www.t10.org

However this may be the best doc for UEFI iSCSI:
https://github.com/tianocore/edk2/search?utf8=%E2%9C%93&q=iscsi&type=

BTW, iSCSI is up to RFC 7143 these years, RFC 3720 is now OBSOLETE. I
wonder if UEFI's iSCSI is RFC 7143-compatiable?
https://tools.ietf.org/html/rfc7143

HTH,
Thanks,
Lee Fisher
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 11/23] OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to UINT64

[Laszlo Ersek]

On 08/23/17 14:22, Brijesh Singh wrote:
> The patch change the "BufferPhysAddr" parameter of VirtioAppendDesc()
> from type UINTN to UINT64.
> 
> UINTN is appropriate as long as we pass system memory references. After
> the introduction of this feature, that's no longer the case in general.

(1) s/this feature/bus master device addresses/

> Should we implement "real" IOMMU support at some point, UINTN could
> break in 32-bit builds of OVMF.
> 
> Suggested-by: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Include/Library/VirtioLib.h   | 35 +-
>  OvmfPkg/Library/VirtioLib/VirtioLib.c | 38 ++--
>  2 files changed, 37 insertions(+), 36 deletions(-)
> 
> diff --git a/OvmfPkg/Include/Library/VirtioLib.h 
> b/OvmfPkg/Include/Library/VirtioLib.h
> index c3e56ea23b89..a966311ac941 100644
> --- a/OvmfPkg/Include/Library/VirtioLib.h
> +++ b/OvmfPkg/Include/Library/VirtioLib.h
> @@ -151,33 +151,34 @@ VirtioPrepare (
>The caller is responsible for initializing *Indices with VirtioPrepare()
>first.
>  
> -  @param[in,out] RingThe virtio ring to append the buffer to, as a
> - descriptor.
> +  @param[in,out] Ring   The virtio ring to append the buffer to,
> +as a descriptor.
>  
> -  @param[in] BufferPhysAddr  (Guest pseudo-physical) start address of the
> - transmit / receive buffer.
> +  @param[in] BufferDeviceAddress(Bus master device)) start address of the

(2) Unbalanced parentheses

> +transmit / receive buffer.
>  
> -  @param[in] BufferSize  Number of bytes to transmit or receive.
> +  @param[in] BufferSize Number of bytes to transmit or receive.
>  
> -  @param[in] Flags   A bitmask of VRING_DESC_F_* flags. The caller
> - computes this mask dependent on further buffers 
> to
> - append and transfer direction.
> - VRING_DESC_F_INDIRECT is unsupported. The
> - VRING_DESC.Next field is always set, but the 
> host
> - only interprets it dependent on 
> VRING_DESC_F_NEXT.
> +  @param[in] Flags  A bitmask of VRING_DESC_F_* flags. The
> +caller computes this mask dependent on
> +further buffers to append and transfer
> +direction. VRING_DESC_F_INDIRECT is
> +unsupported. The VRING_DESC.Next field is
> +always set, but the host only interprets
> +it dependent on VRING_DESC_F_NEXT.
>  
> -  @param[in,out] Indices Indices->HeadDescIdx is not accessed.
> - On input, Indices->NextDescIdx identifies the 
> next
> - descriptor to carry the buffer. On output,
> - Indices->NextDescIdx is incremented by one, 
> modulo
> - 2^16.
> +  @param[in,out] IndicesIndices->HeadDescIdx is not accessed.
> +On input, Indices->NextDescIdx identifies
> +the next descriptor to carry the buffer.
> +On output, Indices->NextDescIdx is
> +incremented by one, modulo 2^16.
>  
>  **/
>  VOID
>  EFIAPI
>  VirtioAppendDesc (
>IN OUT VRING*Ring,
> -  IN UINTNBufferPhysAddr,
> +  IN UINT64   BufferDeviceAddress,
>IN UINT32   BufferSize,
>IN UINT16   Flags,
>IN OUT DESC_INDICES *Indices
> diff --git a/OvmfPkg/Library/VirtioLib/VirtioLib.c 
> b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> index e5366e385f5d..fcd484fffada 100644
> --- a/OvmfPkg/Library/VirtioLib/VirtioLib.c
> +++ b/OvmfPkg/Library/VirtioLib/VirtioLib.c
> @@ -189,7 +189,6 @@ VirtioPrepare (
>Indices->NextDescIdx = Indices->HeadDescIdx;
>  }
>  
> -
>  /**
>  
>Append a contiguous buffer for transmission / reception via the virtio 
> ring.
> @@ -205,33 +204,34 @@ VirtioPrepare (
>The caller is responsible for initializing *Indices with VirtioPrepare()
>first.
>  
> -  @param[in,out] RingThe virtio ring to append the buffer to, as a
> - descriptor.
> +  @param[in,out] Ring   The virtio ring to append the buffer to,
> +as a descriptor.
>  
> -  @param[in] BufferPhysAddr  (Guest pseudo-physical) start address of the
> - transmit / receive buffer.
> +  @param[in] BufferDeviceAddress(Bus master device)) start addres

Re: [edk2] [Patch] UefiCpuPkg/MpLib: fix potential overflow issue.

[Kinney, Michael D]

Hi Eric,

With this patch GetPerformanceCounterProperties() is called 
twice.  I think you can use TimestampCounterFreq in the else
clause.

Also, the comment blocks are no longer correct.  The original
comment block goes with the else clause, and you need a new
comment block for the if statement that describes the check
for an overflow.

Mike

> -Original Message-
> From: Dong, Eric
> Sent: Tuesday, August 22, 2017 10:30 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> 
> Subject: [Patch] UefiCpuPkg/MpLib: fix potential overflow
> issue.
> 
> Current calculate timeout logic may have overflow if the input
> timeout value too large. This patch fix this potential overflow
> issue.
> 
> Cc: Michael Kinney 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 30
> +++---
>  1 file changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index ed1f55e..005dec4 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1001,6 +1001,9 @@ CalculateTimeout (
>OUT UINT64  *CurrentTime
>)
>  {
> +  UINT64 TimeoutInSeconds;
> +  UINT64 TimestampCounterFreq;
> +
>//
>// Read the current value of the performance counter
>//
> @@ -1019,13 +1022,26 @@ CalculateTimeout (
>// in Hz. So multiply the return value with
> TimeoutInMicroseconds and then divide
>// it by 1,000,000, to get the number of ticks for the
> timeout value.
>//
> -  return DivU64x32 (
> -   MultU64x64 (
> - GetPerformanceCounterProperties (NULL, NULL),
> - TimeoutInMicroseconds
> - ),
> -   100
> -   );
> +  TimestampCounterFreq = GetPerformanceCounterProperties
> (NULL, NULL);
> +  if (DivU64x64Remainder (MAX_UINT64, TimeoutInMicroseconds,
> NULL) < TimestampCounterFreq) {
> +//
> +// Convert microseconds into seconds if direct
> multiplication overflows
> +//
> +TimeoutInSeconds = DivU64x32 (TimeoutInMicroseconds,
> 100);
> +//
> +// Assertion if the final tick count exceeds MAX_UINT64
> +//
> +ASSERT (DivU64x64Remainder (MAX_UINT64, TimeoutInSeconds,
> NULL) >= TimestampCounterFreq);
> +return MultU64x64 (TimestampCounterFreq,
> TimeoutInSeconds);
> +  } else {
> +return DivU64x32 (
> + MultU64x64 (
> +   GetPerformanceCounterProperties (NULL, NULL),

Use TimestampCounterFreq instead.

> +   TimeoutInMicroseconds
> +   ),
> + 100
> + );
> +  }
>  }
> 
>  /**
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 2/2] UefiCpuPkg: Update default for PcdCpuProcTraceMemSize/PcdCpuProcTraceOutputScheme.

[Kinney, Michael D]

Eric,

Some Comments embedded below.  

Please make sure the UNI file is updated to match the DEC file.

For the enum PROC_TRACE_MEM_SIZE, I would prefer the enum values
have more than just "Enum" in the beginning.  It would be better
to use names like "ProcTraceMemSize" so the first enum value would
be "ProcTraceMemSize4KB".

Same for PROC_TRACE_OUTPUT_SCHEME.  Use "ProcTraceOutputScheme".

Thanks,

Mike

> -Original Message-
> From: Dong, Eric
> Sent: Tuesday, August 22, 2017 7:31 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> 
> Subject: [Patch 2/2] UefiCpuPkg: Update default for
> PcdCpuProcTraceMemSize/PcdCpuProcTraceOutputScheme.
> 
> These two definitions have redundant definition which can be
> handle by code.
> This patch update them to follow new code definitions.
> 
> Cc: Michael Kinney 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/UefiCpuPkg.dec | 14 ++
>  UefiCpuPkg/UefiCpuPkg.uni |  8 +++-
>  2 files changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec
> b/UefiCpuPkg/UefiCpuPkg.dec
> index b4e099d..51ae0e2 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -286,7 +286,7 @@
>gUefiCpuPkgTokenSpaceGuid.PcdCpuFeaturesSetting|{0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}|VOID*|0x0019
> 
>## Contains the size of memory required when CPU processor
> trace is enabled.

Add a reference to the PCD and bit that enables/disables CPU 
Processor trace and describe that this PCD is ignored if
CPU processor trace is disabled.


> -  #  Default value is 0x10 which disables the processor
> trace.
> +  #  Default value is 0x0 which use 4K memory size.

"Default value is 0x00 which means 4KB of memory is allocated if CPU processor 
trace is enabled."


>#  0x0  -  4K.
>#  0x1  -  8K.
>#  0x2  -  16K.
> @@ -303,19 +303,17 @@
>#  0xD  -  32M.
>#  0xE  -  64M.
>#  0xF  -  128M.
> -  #  0x10 -  ProcTraceMemDisable.
># @Prompt The memory size used for processor trace.
> -  # @ValidRange  0x8001 | 0 - 0x10
> -
> gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceMemSize|0x10|UINT32|0x
> 6012
> +  # @ValidRange  0x8001 | 0 - 0xF
> +
> gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceMemSize|0x0|UINT32|0x6
> 012
> 
>## Contains the processor trace output scheme when CPU
> processor trace is enabled.

Add a reference to the PCD and bit that enables/disable CPU 
Processor trace and describe that this PCD is ignored if
CPU processor trace is disabled.

> -  #  Default value is 2 which disables the processor
> trace.
> +  #  Default value is 1 which use single range output
> scheme.

The default value in the statement below is 0, not 1.
The UNI file looks correct.

>#  0 - Single Range output scheme.
>#  1 - ToPA(Table of physical address) scheme.
> -  #  2 - Invalid scheme.
># @Prompt The processor trace output scheme.
> -  # @ValidRange  0x8001 | 0 - 2
> -
> gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceOutputScheme|0x2|UINT8
> |0x6015
> +  # @ValidRange  0x8001 | 0 - 1
> +
> gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceOutputScheme|0x0|UINT8
> |0x6015
> 
>  [UserExtensions.TianoCore."ExtraFiles"]
>UefiCpuPkgExtra.uni
> diff --git a/UefiCpuPkg/UefiCpuPkg.uni
> b/UefiCpuPkg/UefiCpuPkg.uni
> index 858e4a7..f3be041 100644
> --- a/UefiCpuPkg/UefiCpuPkg.uni
> +++ b/UefiCpuPkg/UefiCpuPkg.uni
> @@ -198,7 +198,7 @@
>  #string
> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuProcTraceMemSize_PROMPT
> #language en-US "Memory size used by Processor Trace feature."
> 
>  #string
> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuProcTraceMemSize_HELP
> #language en-US "User input the memory size can be used by
> processor trace feature.\n"
> -
> "Default value is 0x10 which disables the processor memory
> trace.\n"
> +
> "Default value is 0x0 which use 4K memory size.\n"
> 
> "0x0  -  4K.\n"
> 
> "0x1  -  8K.\n"
> 
> "0x2  -  16K.\n"
> @@ -215,12 +215,10 @@
> 
> "0xD  -  32M.\n"
> 
> "0xE  -  64M.\n"
> 
> "0xF  -  128M.\n"
> -
> "0x10 -  ProcTraceMemDisable.\n"
> 
>  #string
> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuProcTraceOutputScheme_PROMP
> T  #language en-US "Processor Trace output scheme type."
> 
>  #string
> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuProcTraceOutputScheme_HELP
> #language en-US "User input the processor trace output scheme
> type.\n"
> -
> "Default value is 2 which disables the processor memory
> trace.\n"
> 
> +
> "Default value is 0 which use single range output
> scheme.\n"
> 
> 
> "0 - Single Range output scheme.\n"
> 
> -
> "1 - ToPA(Table of physical address) scheme.\n"
> 
> -
> "2 - Invalid scheme.\n"
> \ No newline at end of file
> +
> "1 - ToPA(Table of physical address) scheme.\n"
> \ No newline at end of file
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Questions about Open Compute Project Server BIOS

[Richardson, Brian]

At this point, there is not an OCP project in TianoCore. If one is developed in 
the future, it will be added as a branch of the edk2-platforms repo: 
https://github.com/tianocore/edk2-platforms 

Thanks … br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richard...@intel.com -- @intel_brian (Twitter & WeChat)
https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson
 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tiger Liu
Sent: Wednesday, August 23, 2017 12:29 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Questions about Open Compute Project Server BIOS

Hi, experts:
There is an Open Compute Project(OCP).
They provided open server design guide, and reference schematic.

I have a question about its bios.

Is there open source uefi bios for this project?

Thanks

best wishes,


保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 12/23] OvmfPkg/VirtioRngDxe: map host address to device address

[Laszlo Ersek]

On 08/23/17 14:22, Brijesh Singh wrote:
> patch maps the host address to a device address for buffers (including
> rings, device specifc request and response pointed by vring descriptor,
> and any further memory reference by those request and response).
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/VirtioRngDxe/VirtioRng.h |  1 +
>  OvmfPkg/VirtioRngDxe/VirtioRng.c | 82 +---
>  2 files changed, 74 insertions(+), 9 deletions(-)
> 
> diff --git a/OvmfPkg/VirtioRngDxe/VirtioRng.h 
> b/OvmfPkg/VirtioRngDxe/VirtioRng.h
> index 998f9fae48c2..389c8ddc8d31 100644
> --- a/OvmfPkg/VirtioRngDxe/VirtioRng.h
> +++ b/OvmfPkg/VirtioRngDxe/VirtioRng.h
> @@ -38,6 +38,7 @@ typedef struct {
>EFI_EVENT ExitBoot;   // DriverBindingStart   0
>VRING Ring;   // VirtioRingInit   2
>EFI_RNG_PROTOCOL  Rng;// VirtioRngInit1
> +  VOID  *RingMap;   // VirtioRingMap2
>  } VIRTIO_RNG_DEV;
>  
>  #define VIRTIO_ENTROPY_SOURCE_FROM_RNG(RngPointer) \
> diff --git a/OvmfPkg/VirtioRngDxe/VirtioRng.c 
> b/OvmfPkg/VirtioRngDxe/VirtioRng.c
> index 0abca488e6cd..59f32d343179 100644
> --- a/OvmfPkg/VirtioRngDxe/VirtioRng.c
> +++ b/OvmfPkg/VirtioRngDxe/VirtioRng.c
> @@ -140,6 +140,8 @@ VirtioRngGetRNG (
>UINT32Len;
>UINT32BufferSize;
>EFI_STATUSStatus;
> +  EFI_PHYSICAL_ADDRESS  DeviceAddress;
> +  VOID  *Mapping;
>  
>if (This == NULL || RNGValueLength == 0 || RNGValue == NULL) {
>  return EFI_INVALID_PARAMETER;
> @@ -159,6 +161,20 @@ VirtioRngGetRNG (
>}
>  
>Dev = VIRTIO_ENTROPY_SOURCE_FROM_RNG (This);
> +  //
> +  // Map Buffer's system phyiscal address to device address
> +  //
> +  Status = VirtioMapAllBytesInSharedBuffer (
> + Dev->VirtIo,
> + VirtioOperationBusMasterWrite,
> + (VOID *)Buffer,
> + RNGValueLength,
> + &DeviceAddress,
> + &Mapping
> + );
> +  if (EFI_ERROR (Status)) {
> +goto FreeBuffer;
> +  }

(1) Sorry, I missed this in my previous review:

According to the interface contract of this protocol member function, we
should set Status to EFI_DEVICE_ERROR here, before jumping to the
FreeBuffer label. (Both old code, and new code other than this, do it.)

I can fix this up.

With that:

Reviewed-by: Laszlo Ersek 

Thanks,
Laszlo

>  
>//
>// The Virtio RNG device may return less data than we asked it to, and can
> @@ -170,7 +186,7 @@ VirtioRngGetRNG (
>  
>  VirtioPrepare (&Dev->Ring, &Indices);
>  VirtioAppendDesc (&Dev->Ring,
> -  (UINTN)Buffer + Index,
> +  DeviceAddress + Index,
>BufferSize,
>VRING_DESC_F_WRITE,
>&Indices);
> @@ -178,17 +194,35 @@ VirtioRngGetRNG (
>  if (VirtioFlush (Dev->VirtIo, 0, &Dev->Ring, &Indices, &Len) !=
>  EFI_SUCCESS) {
>Status = EFI_DEVICE_ERROR;
> -  goto FreeBuffer;
> +  goto UnmapBuffer;
>  }
>  ASSERT (Len > 0);
>  ASSERT (Len <= BufferSize);
>}
>  
> +  //
> +  // Unmap the device buffer before accessing it.
> +  //
> +  Status = Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Mapping);
> +  if (EFI_ERROR (Status)) {
> +Status = EFI_DEVICE_ERROR;
> +goto FreeBuffer;
> +  }
> +
>for (Index = 0; Index < RNGValueLength; Index++) {
>  RNGValue[Index] = Buffer[Index];
>}
>Status = EFI_SUCCESS;
>  
> +UnmapBuffer:
> +  //
> +  // If we are reached here due to the error then unmap the buffer otherwise
> +  // the buffer is already unmapped after VirtioFlush().
> +  //
> +  if (EFI_ERROR (Status)) {
> +Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, Mapping);
> +  }
> +
>  FreeBuffer:
>FreePool ((VOID *)Buffer);
>return Status;
> @@ -205,6 +239,7 @@ VirtioRngInit (
>EFI_STATUS Status;
>UINT16 QueueSize;
>UINT64 Features;
> +  UINT64 RingBaseShift;
>  
>//
>// Execute virtio-0.9.5, 2.2.1 Device Initialization Sequence.
> @@ -282,25 +317,42 @@ VirtioRngInit (
>}
>  
>//
> +  // If anything fails from here on, we must release the ring resources.
> +  //
> +  Status = VirtioRingMap (
> + Dev->VirtIo,
> + &Dev->Ring,
> + &RingBaseShift,
> + &Dev->RingMap
> + );
> +  if (EFI_ERROR (Status)) {
> +goto ReleaseQueue;
> +  }
> +
> +  //
>// Additional steps for MMIO: align the queue appropriately, and set the
> -  // size. If anything fails from here on, we must release the ring 
> resources.
> +  // size. If anything fails from here on, we must unmap the ring resources.
>//
>Status = Dev->VirtIo->SetQueueNum (Dev->VirtIo, QueueSize);
>if (EFI_ERROR (Status)) {
> -goto ReleaseQueue;
> +goto 

Re: [edk2] [Patch 1/2] UefiCpuPkg/CpuCommonFeaturesLib: Remove redundant definition.

[Kinney, Michael D]

Eric,

Comment below.

Mike

> -Original Message-
> From: Dong, Eric
> Sent: Tuesday, August 22, 2017 7:31 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> 
> Subject: [Patch 1/2] UefiCpuPkg/CpuCommonFeaturesLib: Remove
> redundant definition.
> 
> The EnumProcTraceMemDisable/OutputSchemeInvalid are redundant
> definitions. These definitions can be handled by other code,
> so remove them.
> 
> Cc: Michael Kinney 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c | 14 
> --
>  1 file changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
> b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
> index a90dd4e..6524882 100644
> --- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
> +++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
> @@ -35,8 +35,7 @@ typedef enum {
>Enum16M,
>Enum32M,
>Enum64M,
> -  Enum128M,
> -  EnumProcTraceMemDisable
> +  Enum128M
>  } PROC_TRACE_MEM_SIZE;
> 
>  ///
> @@ -44,8 +43,7 @@ typedef enum {
>  ///
>  typedef enum {
>OutputSchemeSingleRange = 0,
> -  OutputSchemeToPA,
> -  OutputSchemeInvalid
> +  OutputSchemeToPA
>  } PROC_TRACE_OUTPUT_SCHEME;
> 
>  typedef struct  {
> @@ -134,10 +132,6 @@ ProcTraceSupport (
>// Check if ProcTraceMemorySize option is enabled (0xFF means
> disable by user)
>//
>ProcTraceData = (PROC_TRACE_DATA *) ConfigData;
> -  if ((ProcTraceData->ProcTraceMemSize >=
> EnumProcTraceMemDisable) ||
> -  (ProcTraceData->ProcTraceOutputScheme >=
> OutputSchemeInvalid)) {
> -return FALSE;
> -  }

I see the ProcTraceOutputScheme values are checked below.
Do we need to keep the check for a valid ProcTraceMemSize value?

> 
>//
>// Check if Processor Trace is supported
> @@ -151,8 +145,8 @@ ProcTraceSupport (
>AsmCpuidEx (CPUID_INTEL_PROCESSOR_TRACE,
> CPUID_INTEL_PROCESSOR_TRACE_MAIN_LEAF, NULL, NULL, &Ecx.Uint32,
> NULL);
>ProcTraceData->ProcessorData[ProcessorNumber].TopaSupported =
> (BOOLEAN) (Ecx.Bits.RTIT == 1);
>ProcTraceData-
> >ProcessorData[ProcessorNumber].SingleRangeSupported = (BOOLEAN)
> (Ecx.Bits.SingleRangeOutput == 1);
> -  if (ProcTraceData->ProcessorData[ProcessorNumber].TopaSupported
> ||
> -  ProcTraceData-
> >ProcessorData[ProcessorNumber].SingleRangeSupported) {
> +  if ((ProcTraceData-
> >ProcessorData[ProcessorNumber].TopaSupported && (ProcTraceData-
> >ProcTraceOutputScheme == OutputSchemeToPA)) ||
> +  (ProcTraceData-
> >ProcessorData[ProcessorNumber].SingleRangeSupported &&
> (ProcTraceData->ProcTraceOutputScheme ==
> OutputSchemeSingleRange))) {
>  return TRUE;
>}
> 
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 19/23] OvmfPkg/Virtio10: define VIRITO_F_IOMMU_PLATFORM feature bit

[Laszlo Ersek]

(1) The subject line contains a super-sneaky typo which I missed in my
previous review: VIR-I-T-O vs. VIR-T-I-O.

 vv
  VIRITO_F_IOMMU_PLATFORM
  VIRTIO_F_IOMMU_PLATFORM
 ^^

The code is correct.

With the subject fixed (which I plan to do):

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo



On 08/23/17 14:22, Brijesh Singh wrote:
> 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 more infromation
> 
> [1] https://lists.oasis-open.org/archives/virtio-dev/201610/msg00121.html
> 
> Cc: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/Include/IndustryStandard/Virtio10.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/Include/IndustryStandard/Virtio10.h 
> b/OvmfPkg/Include/IndustryStandard/Virtio10.h
> index 4c9b62a3cf59..c5efb5cfcb8a 100644
> --- a/OvmfPkg/Include/IndustryStandard/Virtio10.h
> +++ b/OvmfPkg/Include/IndustryStandard/Virtio10.h
> @@ -2,6 +2,7 @@
>Definitions from the VirtIo 1.0 specification (csprd05).
>  
>Copyright (C) 2016, Red Hat, Inc.
> +  Copyright (C) 2017, AMD, Inc.
>  
>This program and the accompanying materials are licensed and made available
>under the terms and conditions of the BSD License which accompanies this
> @@ -81,6 +82,7 @@ typedef struct {
>  //
>  // VirtIo 1.0 reserved (device-independent) feature bits
>  //
> -#define VIRTIO_F_VERSION_1 BIT32
> +#define VIRTIO_F_VERSION_1  BIT32
> +#define VIRTIO_F_IOMMU_PLATFORM BIT33
>  
>  #endif // _VIRTIO_1_0_H_
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 20/23] OvmfPkg/VirtioRngDxe: negotiate VIRITO_F_IOMMU_PLATFORM

[Laszlo Ersek]

(1) Please replace "VIRITO_F_IOMMU_PLATFORM" with
"VIRTIO_F_IOMMU_PLATFORM" in the subjects of the remaining patches
(including this one).

On 08/23/17 14:22, Brijesh Singh wrote:
> In previous patches, we have implemented IOMMU-like member functions in
> VIRTIO_DEVICE_PROTOCOL to translate the physical address to bus address
> and virtio drivers are updated to use those member functions. 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: Ard Biesheuvel 
> Cc: Jordan Justen 
> Cc: Tom Lendacky 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Brijesh Singh 
> ---
>  OvmfPkg/VirtioRngDxe/VirtioRng.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/VirtioRngDxe/VirtioRng.c 
> b/OvmfPkg/VirtioRngDxe/VirtioRng.c
> index 59f32d343179..32512d882f7d 100644
> --- a/OvmfPkg/VirtioRngDxe/VirtioRng.c
> +++ b/OvmfPkg/VirtioRngDxe/VirtioRng.c
> @@ -278,7 +278,7 @@ VirtioRngInit (
>  goto Failed;
>}
>  
> -  Features &= VIRTIO_F_VERSION_1;
> +  Features &= VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM;
>  
>//
>// In virtio-1.0, feature negotiation is expected to complete before queue
> @@ -359,7 +359,7 @@ VirtioRngInit (
>// step 5 -- Report understood features and guest-tuneables.
>//
>if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
> -Features &= ~(UINT64)VIRTIO_F_VERSION_1;
> +Features &= ~(UINT64)VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM;

While all of the VIRTIO_F_VERSION_1 locations in this driver are covered
now, this change is invalid:

The bitwise-complement operator "~" has stronger binding than the
bitwise-or operator "|". The cast operator "(type)" also binds more
strongly than the bitwise-or operator "|".

The purpose of the above assignment is to clear both of the listed bits.
Therefore,

(2) parentheses are necessary tightly around the bitwise-or operator,
like I suggested in
<82cb5dda-f02d-9e38-c47e-3723184dea08@redhat.com">http://mid.mail-archive.com/82cb5dda-f02d-9e38-c47e-3723184dea08@redhat.com>,
point (4):

Features &= ~(UINT64)(VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM);

I think this comment too applies to the rest of the patches.

Thanks,
Laszlo

>  Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
>  if (EFI_ERROR (Status)) {
>goto UnmapQueue;
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 20/23] OvmfPkg/VirtioRngDxe: negotiate VIRITO_F_IOMMU_PLATFORM

[Brijesh Singh]

On 8/23/17 6:21 PM, Laszlo Ersek wrote:
> (1) Please replace "VIRITO_F_IOMMU_PLATFORM" with
> "VIRTIO_F_IOMMU_PLATFORM" in the subjects of the remaining patches
> (including this one).

I will fix it in v4.

> On 08/23/17 14:22, Brijesh Singh wrote:
>> In previous patches, we have implemented IOMMU-like member functions in
>> VIRTIO_DEVICE_PROTOCOL to translate the physical address to bus address
>> and virtio drivers are updated to use those member functions. 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: Ard Biesheuvel 
>> Cc: Jordan Justen 
>> Cc: Tom Lendacky 
>> Cc: Laszlo Ersek 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Brijesh Singh 
>> ---
>>  OvmfPkg/VirtioRngDxe/VirtioRng.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/OvmfPkg/VirtioRngDxe/VirtioRng.c 
>> b/OvmfPkg/VirtioRngDxe/VirtioRng.c
>> index 59f32d343179..32512d882f7d 100644
>> --- a/OvmfPkg/VirtioRngDxe/VirtioRng.c
>> +++ b/OvmfPkg/VirtioRngDxe/VirtioRng.c
>> @@ -278,7 +278,7 @@ VirtioRngInit (
>>  goto Failed;
>>}
>>  
>> -  Features &= VIRTIO_F_VERSION_1;
>> +  Features &= VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM;
>>  
>>//
>>// In virtio-1.0, feature negotiation is expected to complete before queue
>> @@ -359,7 +359,7 @@ VirtioRngInit (
>>// step 5 -- Report understood features and guest-tuneables.
>>//
>>if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
>> -Features &= ~(UINT64)VIRTIO_F_VERSION_1;
>> +Features &= ~(UINT64)VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM;
> While all of the VIRTIO_F_VERSION_1 locations in this driver are covered
> now, this change is invalid:
>
> The bitwise-complement operator "~" has stronger binding than the
> bitwise-or operator "|". The cast operator "(type)" also binds more
> strongly than the bitwise-or operator "|".
>
> The purpose of the above assignment is to clear both of the listed bits.
> Therefore,
>
> (2) parentheses are necessary tightly around the bitwise-or operator,
> like I suggested in
> <82cb5dda-f02d-9e38-c47e-3723184dea08@redhat.com">http://mid.mail-archive.com/82cb5dda-f02d-9e38-c47e-3723184dea08@redhat.com>,
> point (4):
>
> Features &= ~(UINT64)(VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM);

Agreed, thanks. I will fix it in v4.

> I think this comment too applies to the rest of the patches.
>
> Thanks,
> Laszlo
>
>>  Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
>>  if (EFI_ERROR (Status)) {
>>goto UnmapQueue;
>>

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch v2 1/2] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA table entry definition.

[Kinney, Michael D]

Hi Eric,

I see that the legal values for the Size field of 
RTIT_TOPA_TABLE_ENTRY are documented in the SDM.

I think we should add the enum for PROC_TRACE_MEM_SIZE
into ArchitecturalMsr.h next to RTIT_TOPA_TABLE_ENTRY.
Maybe rename it to RTIT_TOPA_MEMORY_SIZE with enum names
that start with "RtitTopaMemorySize".

The Copyright date in ArchitecturalMsr.h also needs to 
be updated.

The #define for MAX_TOPA_ENTRY_COUNT need a comment block
that describes what it is and why it has a value of 2.  I see
2 entries are needed because the list of entries must be terminated
by an entry with the END bit set to 1, so 2 entries are required
to use a single valid entry.

ProcTrace.c: Please update programming of MSR_IA32_RTIT_OUTPUT_BASE
to use the named bit fields from the structure.

ProcTrace.c: Please update programming of MSR_IA32_RTIT_OUTPUT_MASK_PTRS
to use the named bit fields from the structure.

ProcTrace.c: I am confused by the programming
MSR_IA32_RTIT_OUTPUT_MASK_PTRS to 0x7f.  That sets a Reserved
field to all 1s.

ProcTrace.c: I see a mix of setting TopaEntryPtr using both
bit fields and the Uint64 field.  Can we change to use only
the bit fields.  Do we really need to set the address field 
in entry #1?  Isn't setting END to 1 enough?

Thanks,

Mike

> -Original Message-
> From: Dong, Eric
> Sent: Thursday, August 17, 2017 8:29 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> 
> Subject: [Patch v2 1/2] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT
> TOPA table entry definition.
> 
> Add RTIT TOPA table entry definition to architecturalMsr.h file.
> 
> Cc: Michael Kinney 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Include/Register/ArchitecturalMsr.h | 55
> ++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
> b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
> index 4f9c103..40c4383 100644
> --- a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
> +++ b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
> @@ -4534,6 +4534,61 @@ typedef union {
>UINT64  Uint64;
>  } MSR_IA32_RTIT_OUTPUT_MASK_PTRS_REGISTER;
> 
> +/**
> +  Format of ToPA table entries.
> +**/
> +typedef union {
> +  ///
> +  /// Individual bit fields
> +  ///
> +  struct {
> +///
> +/// [Bit 0] END. See Section 35.2.6.2, "Table of Physical
> Addresses (ToPA)".
> +///
> +UINT32  END:1;
> +UINT32  Reserved1:1;
> +///
> +/// [Bit 2] INT. See Section 35.2.6.2, "Table of Physical
> Addresses (ToPA)".
> +///
> +UINT32  INT:1;
> +UINT32  Reserved2:1;
> +///
> +/// [Bit 4] STOP. See Section 35.2.6.2, "Table of Physical
> Addresses (ToPA)".
> +///
> +UINT32  STOP:1;
> +UINT32  Reserved3:1;
> +///
> +/// [Bit 6:9] Indicates the size of the associated output
> region. See Section
> +/// 35.2.6.2, "Table of Physical Addresses (ToPA)".
> +///
> +UINT32  Size:4;
> +UINT32  Reserved4:2;
> +///
> +/// [Bit 12:31] Output Region Base Physical Address low part.
> +/// [Bit 12:31] Output Region Base Physical Address [12:63]
> value to match.
> +/// ATTENTION: The size of the address field is determined by
> the processor's
> +/// physical-address width (MAXPHYADDR) in bits, as reported
> in
> +/// CPUID.8008H:EAX[7:0]. the above part of address
> reserved.
> +/// True address field is [12:MAXPHYADDR-1], [MAXPHYADDR:63]
> is reserved part.
> +/// Detail see Section 35.2.6.2, "Table of Physical Addresses
> (ToPA)".
> +///
> +UINT32  Base:20;
> +///
> +/// [Bit 32:63] Output Region Base Physical Address high
> part.
> +/// [Bit 32:63] Output Region Base Physical Address [12:63]
> value to match.
> +/// ATTENTION: The size of the address field is determined by
> the processor's
> +/// physical-address width (MAXPHYADDR) in bits, as reported
> in
> +/// CPUID.8008H:EAX[7:0]. the above part of address
> reserved.
> +/// True address field is [12:MAXPHYADDR-1], [MAXPHYADDR:63]
> is reserved part.
> +/// Detail see Section 35.2.6.2, "Table of Physical Addresses
> (ToPA)".
> +///
> +UINT32  BaseHi:32;
> +  } Bits;
> +  ///
> +  /// All bit fields as a 64-bit value
> +  ///
> +  UINT64  Uint64;
> +} RTIT_TOPA_TABLE_ENTRY;
> 
>  /**
>Trace Control Register (R/W). If (CPUID.(EAX=07H,
> ECX=0):EBX[25] = 1).
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms] Silicon/Openmoko: add driver for ChaosKey RNG USB device

[Leif Lindholm]

On Wed, Aug 23, 2017 at 02:12:06PM +0100, Ard Biesheuvel wrote:
> This is a continuation of the work carried out by Leif Lindholm to
> implement a driver for the ChaosKey USB device. This driver uses the
> UEFI driver model, which is a slightly awkward fit, due to the fact
> that a UEFI implementation may legally only instantiate those protocols
> that are needed to access the device path that the active Boot
> options refers to.
> 
> However, it is expected that UEFI implementations typically instantiate
> all USB I/O protocols and connect them as well, as those are required
> for a USB keyboard to be able to control the boot sequence. This should
> result in this driver being connected and given the opportunity to
> produce the EFI_RNG_PROTOCOL.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.c | 346 
>  Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.h |  61 
>  Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDxe.inf  |  48 +++
>  Silicon/Openmoko/ChaosKeyDxe/ComponentName.c  | 205 
>  Silicon/Openmoko/ChaosKeyDxe/DriverBinding.c  | 256 +++
>  5 files changed, 916 insertions(+)

This is all a bit new territory, so I don't know what the best way of
dealing with this is, but I think we could do with a .dsc somewhere to
enable building this driver standalone. My gut feel is that an
Openmoko/Openmoko.dsc would be a reasonable candidate.

> diff --git a/Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.c 
> b/Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.c
> new file mode 100644
> index ..1870080d2c70
> --- /dev/null
> +++ b/Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.c
> @@ -0,0 +1,346 @@
> +/** @file
> +  Device driver for the ChaosKey hardware random number generator.
> +
> +  Copyright (c) 2016 - 2017, Linaro Ltd. All rights reserved.
> +
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD
> +  License which accompanies this distribution. The full text of the license 
> may
> +  be found at  http://opensource.org/licenses/bsd-license.php.
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> +
> +**/
> +
> +#include "ChaosKeyDriver.h"
> +
> +#include 
> +#include 
> +#include 
> +
> +STATIC
> +BOOLEAN
> +IsBulkInEndpoint (
> +  IN  EFI_USB_ENDPOINT_DESCRIPTOR *Endpoint
> +  )
> +{
> +  if ((Endpoint->Attributes & USB_ENDPOINT_TYPE_MASK) == USB_ENDPOINT_BULK) {
> +if (Endpoint->EndpointAddress & USB_ENDPOINT_DIR_IN) {
> +  return TRUE;
> +}
> +  }
> +  return FALSE;
> +}
> +
> +
> +STATIC
> +EFI_STATUS
> +FindEndpoint (
> +  IN  CHAOSKEY_DEV *ChaosKey
> +  )
> +{
> +  EFI_USB_IO_PROTOCOL *UsbIo;
> +  EFI_STATUS  Status;
> +  UINTN   Index;
> +  EFI_USB_INTERFACE_DESCRIPTORInterfaceDescriptor;
> +
> +  UsbIo = ChaosKey->UsbIo;
> +
> +  //
> +  // Get interface & endpoint descriptor
> +  //
> +  Status = UsbIo->UsbGetInterfaceDescriptor (UsbIo, &InterfaceDescriptor);
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  //
> +  // The ChaosKey provides two endpoints:
> +  // - The first one is the 'cooked' one, to be used as random data input
> +  // - The second one is the raw bitstream from the generator, higher
> +  //   throughput, but lower randomness.
> +  // So locate the first bulk IN endpoint and save it for later use.
> +  //
> +  for (Index = 0; Index < InterfaceDescriptor.NumEndpoints; Index++) {
> +EFI_USB_ENDPOINT_DESCRIPTOR  Endpoint;
> +
> +Status = UsbIo->UsbGetEndpointDescriptor (UsbIo, Index, &Endpoint);
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "UsbGetEndPointDescriptor(%d) failed!\n", Index));
> +  return Status;
> +}
> +
> +if (IsBulkInEndpoint(&Endpoint)) {
> +  ChaosKey->EndpointAddress = Endpoint.EndpointAddress;
> +  ChaosKey->EndpointSize = Endpoint.MaxPacketSize;
> +  return EFI_SUCCESS;
> +}
> +  }
> +
> +  DEBUG ((DEBUG_ERROR, "Failed to locate suitable BULK IN USB endpoint!\n"));
> +  return EFI_DEVICE_ERROR;
> +}
> +
> +
> +/**
> +  Returns information about the random number generation implementation.
> +
> +  @param[in] This   A pointer to the EFI_RNG_PROTOCOL 
> instance.
> +  @param[in,out] AlgorithmListSize  On input, the size in bytes of 
> AlgorithmList
> +On output with a return code of 
> EFI_SUCCESS,
> +the size in bytes of the data returned in
> +AlgorithmList. On output with a return
> +code of EFI_BUFFER_TOO_SMALL, the size of
> +AlgorithmList required to obtain the 
> list.
> +  @param[out] AlgorithmLi

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

[Laszlo Ersek]

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 member functions
>   OvmfPkg/VirtioPciDeviceDxe: implement IOMMU-like member functions
>   OvmfPkg/VirtioMmioDeviceLib: implement IOMMU-like member functions
>   OvmfPkg/VirtioLib: add VirtioMapAllBytesInSharedBuffer() helper
> function
>   OvmfPkg/VirtioLib: take VirtIo instance in
> VirtioRingInit/VirtioRingUninit
>   OvmfPkg/Virtio: take RingBaseShift in SetQueueAddress()
>   OvmfPkg/Virtio10Dxe: add the RingBaseShift offset
>   OvmfPkg/VirtioLib: add function to map VRING
>   OvmfPkg/VirtioLib: alloc VRING buffer with AllocateSharedPages()
>   OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to
> UINT64

(1) I'll take the first 11 patches (which work on the transports and
VirtioLib), fix up the trivial stuff I've found in the v3 review, and
add my R-b tags.


>   OvmfPkg/VirtioRngDxe: map host address to device address

(2) I'll do the same for the VirtioRngDxe driver.


(3) I'll test this initial sequence in various scenarios. I think that
the protocol / transport / VirtioLib changes are good at this point, and
the simplest driver (VirtioRngDxe) demonstrates how to put those new
features to use. It also enables regression testing.

Importantly, I also plan to regression-test the remaining (not yet
converted) drivers at this point. Those drivers are affected only by the
"alloc VRING buffer with AllocateSharedPages" patch, as follows:

- On legacy virtio-pci and virtio-mmio transports, the change is a
no-op, because the AllocateSharedPages() and FreeSharedPages() VirtIo
members are backed by MemoryAllocationLib's AllocatePages() /
FreePages(). So the behavior of VirtioRingInit() / VirtioRingUninit()
remains identical.

- On the virtio-1.0 transport, the direct AllocatePages() call in
VirtioRingInit() will be replaced with VirtIo.AllocateSharedPages ->
PciIo.AllocateBuffer -> PciRootBridgeIo.AllocateBuffer.

- The last function will either branch to gBS->AllocatePages -- if
there's no IoMmu protocol, i.e. no SEV -- which is identical to current
behavior, or branch to IoMmu.AllocateBuffer.

- in IoMmuAllocateBuffer(), we'll allocate StashBuffer on the side
(which is no problem), and the actual allocation (for HostAddress) will
be done with gBS->AllocatePages().

The end result is that at this point, the unconverted drivers won't yet
work on SEV, but they will continue working if SEV is absent. The only
difference is (dependent on transport) longer call chains to memory
allocation and freeing, and larger memory footprint. But, no regressions
in functionality.

If I'm satisfied with the above test results, I'll add my
Regression-tested-by tags as well, and push the first 12 patches.

This will provide a foundation for further driver work (incl. my
VirtioGpuDxe work).


>   OvmfPkg/VirtioBlkDxe: map host address to device address
>   OvmfPkg/VirtioScsiDxe: map host address to device address

(4) I've looked at these patches briefly. They are possibly fine now,
but they've grown way too big. I struggled with the verification of the
VirtioRngDxe driver patch, and each of these two is more than twice as big.

So please, split *each* of these two patches in two parts (a logical
build-up):
- the first part should map and unmap the vring (all relevant contexts),
- the second part should map the requests.


(5) (I think this is my most important point), with the foundation in
place, I suggest we switch to one series per driver. For each driver, I
have to look at the virtio spec, and "page-in" how the requests are
structured, what they do etc. It's not a mechanical process. All that
virtio stuff is easier to re-digest if we proceed device by device.

Should we need later tweaks for the foundation, then at this point I
prefer small incremental patches for that.


>   OvmfPkg/VirtioNetDxe: alloc Tx and Rx rings using AllocateSharedPage()
>   OvmfPkg/VirtioNetDxe: alloc RxBuf using AllocateSharedPages()
>   OvmfPkg/VirtioNetDxe: dynamically alloc transmit header
>   OvmfPkg/VirtioNetDxe: map transmit buffer host address to device
> address

(6) This is obviously the most complex driver. I've only snuck a peek. I
have one comment at this point: *if* we have to do random lookups, then
lists aren't optimal.

Please consider using the following library class:

  MdePkg/Include/Library/OrderedCollectionLib.h

It is already resolved in the OVMF DSC files to the following instance:

  MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/

Examples for use:
- various modules in OvmfPkg,
- AppPkg/Applications/OrderedCollectionTest


>   OvmfPkg/Virtio10: define VIRITO_F_IOMMU_PLATFORM feature bit
>   OvmfPkg/VirtioRngDxe: negotiate VIRITO_F_IOMMU_PLATFORM

(7) I would have liked to include these two patches in my "initial
push", but minimally the second patch n

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

[Brijesh Singh]

Hi Laszlo,


On 8/23/17 7:26 PM, 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 member functions
>>   OvmfPkg/VirtioPciDeviceDxe: implement IOMMU-like member functions
>>   OvmfPkg/VirtioMmioDeviceLib: implement IOMMU-like member functions
>>   OvmfPkg/VirtioLib: add VirtioMapAllBytesInSharedBuffer() helper
>> function
>>   OvmfPkg/VirtioLib: take VirtIo instance in
>> VirtioRingInit/VirtioRingUninit
>>   OvmfPkg/Virtio: take RingBaseShift in SetQueueAddress()
>>   OvmfPkg/Virtio10Dxe: add the RingBaseShift offset
>>   OvmfPkg/VirtioLib: add function to map VRING
>>   OvmfPkg/VirtioLib: alloc VRING buffer with AllocateSharedPages()
>>   OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to
>> UINT64
> (1) I'll take the first 11 patches (which work on the transports and
> VirtioLib), fix up the trivial stuff I've found in the v3 review, and
> add my R-b tags.

Thanks

>
>>   OvmfPkg/VirtioRngDxe: map host address to device address
> (2) I'll do the same for the VirtioRngDxe driver.
>

Thanks

> (3) I'll test this initial sequence in various scenarios. I think that
> the protocol / transport / VirtioLib changes are good at this point, and
> the simplest driver (VirtioRngDxe) demonstrates how to put those new
> features to use. It also enables regression testing.
>
> Importantly, I also plan to regression-test the remaining (not yet
> converted) drivers at this point. Those drivers are affected only by the
> "alloc VRING buffer with AllocateSharedPages" patch, as follows:
>
> - On legacy virtio-pci and virtio-mmio transports, the change is a
> no-op, because the AllocateSharedPages() and FreeSharedPages() VirtIo
> members are backed by MemoryAllocationLib's AllocatePages() /
> FreePages(). So the behavior of VirtioRingInit() / VirtioRingUninit()
> remains identical.
>
> - On the virtio-1.0 transport, the direct AllocatePages() call in
> VirtioRingInit() will be replaced with VirtIo.AllocateSharedPages ->
> PciIo.AllocateBuffer -> PciRootBridgeIo.AllocateBuffer.
>
> - The last function will either branch to gBS->AllocatePages -- if
> there's no IoMmu protocol, i.e. no SEV -- which is identical to current
> behavior, or branch to IoMmu.AllocateBuffer.
>
> - in IoMmuAllocateBuffer(), we'll allocate StashBuffer on the side
> (which is no problem), and the actual allocation (for HostAddress) will
> be done with gBS->AllocatePages().
>
> The end result is that at this point, the unconverted drivers won't yet
> work on SEV, but they will continue working if SEV is absent. The only
> difference is (dependent on transport) longer call chains to memory
> allocation and freeing, and larger memory footprint. But, no regressions
> in functionality.
>
> If I'm satisfied with the above test results, I'll add my
> Regression-tested-by tags as well, and push the first 12 patches.
>
> This will provide a foundation for further driver work (incl. my
> VirtioGpuDxe work).

I agree with you. Sounds like a good plan.
>
>>   OvmfPkg/VirtioBlkDxe: map host address to device address
>>   OvmfPkg/VirtioScsiDxe: map host address to device address
> (4) I've looked at these patches briefly. They are possibly fine now,
> but they've grown way too big. I struggled with the verification of the
> VirtioRngDxe driver patch, and each of these two is more than twice as big.
Great thanks, I agree the series is getting bigger. After v1 feedbacks,
I was almost tempted to say that lets work to enable the base first then
will do one driver at a time. I was repeating the same mistake in each
patch and that was causing trouble to you and also I had to rework the
all drivers.

> So please, split *each* of these two patches in two parts (a logical
> build-up):
> - the first part should map and unmap the vring (all relevant contexts),
> - the second part should map the requests.
>
>
> (5) (I think this is my most important point), with the foundation in
> place, I suggest we switch to one series per driver. For each driver, I
> have to look at the virtio spec, and "page-in" how the requests are
> structured, what they do etc. It's not a mechanical process. All that
> virtio stuff is easier to re-digest if we proceed device by device.
>
> Should we need later tweaks for the foundation, then at this point I
> prefer small incremental patches for that.
>
>
>>   OvmfPkg/VirtioNetDxe: alloc Tx and Rx rings using AllocateSharedPage()
>>   OvmfPkg/VirtioNetDxe: alloc RxBuf using AllocateSharedPages()
>>   OvmfPkg/VirtioNetDxe: dynamically alloc transmit header
>>   OvmfPkg/VirtioNetDxe: map transmit buffer host address to device
>> address
> (6) This is obviously the most complex driver. I've only snuck a peek. I
> have one comment at this point: *if* we have to do random lookups, then
> lists aren't optimal.

Re: [edk2] Iscsi Specification Document

[Ye, Ting]

UEFI iSCSI is RFC3720 compatible. It is not updated yet.

Thanks,
Ting Ye

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Blibbet
Sent: Thursday, August 24, 2017 5:23 AM
To: edk2-devel@lists.01.org
Subject: Re: [edk2] Iscsi Specification Document

On 08/23/2017 02:04 AM, Karunakar P wrote:
> Do we have any specific Document for Iscsi?
> Any document that describes the standard iscsi behavior.

I'm not aware of any 'design specification', that may be hoping for too much.

http://uefi.org/uefi points to 4 [i]SCSI-related URLs:

[RFC 3720] Internet Small Computer Systems Interface (iSCSI)

[RFC 4173] Bootstrapping Clients using the Internet Small Computer System 
Interface (iSCSI) Protocol

iSCSI Boot Firmware Table (iBFT)
http://www.microsoft.com/whdc/system/platform/firmware/ibft.mspx

SCSI Block Commands:
 http://www.t10.org

However this may be the best doc for UEFI iSCSI:
https://github.com/tianocore/edk2/search?utf8=%E2%9C%93&q=iscsi&type=

BTW, iSCSI is up to RFC 7143 these years, RFC 3720 is now OBSOLETE. I wonder if 
UEFI's iSCSI is RFC 7143-compatiable?
https://tools.ietf.org/html/rfc7143

HTH,
Thanks,
Lee Fisher
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Laszlo Ersek]

On 08/24/17 02:54, Brijesh Singh wrote:
> On 8/23/17 7:26 PM, Laszlo Ersek wrote:
>> On 08/23/17 14:22, Brijesh Singh wrote:

>>>   OvmfPkg/VirtioBlkDxe: map host address to device address
>>>   OvmfPkg/VirtioScsiDxe: map host address to device address

>> (4) I've looked at these patches briefly. They are possibly fine now,
>> but they've grown way too big. I struggled with the verification of the
>> VirtioRngDxe driver patch, and each of these two is more than twice as big.

> Great thanks, I agree the series is getting bigger. After v1 feedbacks,
> I was almost tempted to say that lets work to enable the base first then
> will do one driver at a time. I was repeating the same mistake in each
> patch and that was causing trouble to you and also I had to rework the
> all drivers.

Unfortunately (for both of us! :) ), this churn is unavoidable in the
first few versions of a large set -- the foundation is not dictated by
some "divine design", it is dictated only by what the higher level
drivers need. And we only find out what the higher level drivers need if
you at least prototype the patches for them, and I at least skim-review
those patches.

It's regrettable that it requires so much wasted work, but I don't know
how to do it better, save for knowing the future. :)

I trust at this point the base has stabilized enough, and if we need
further changes, we can solve that with small incremental patches.

>> (6) This is obviously the most complex driver. I've only snuck a peek. I
>> have one comment at this point: *if* we have to do random lookups, then
>> lists aren't optimal.
>>
>> Please consider using the following library class:
>>
>>   MdePkg/Include/Library/OrderedCollectionLib.h
>>
>> It is already resolved in the OVMF DSC files to the following instance:
>>
>>   MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/
>>
>> Examples for use:
>> - various modules in OvmfPkg,
>> - AppPkg/Applications/OrderedCollectionTest
> 
> Okay, I will look into it - thanks for the tip. I wanted to actually use
> the Simple array (because we know the maximum number of buffer we can
> queue) but was  not sure about your preferences hence I went to with
> list. If you are okay then I can use array's too.

My concern isn't about memory consumption (if our queue is full (64
elements, IIRC), we just reject the transmit request and let the caller
deal with the error).

Instead, I'd like to avoid an O(n) lookup time (where n is the number of
pending requests), for whatever lookup is necessary now (I haven't
checked the specifics yet). BaseOrderedCollectionRedBlackTreeLib would
give you O(log n) lookup time.

Without having looked at the details, I think an array would have O(n)
lookup time as well (linear search, right?).

(Let's not try to do O(1) with a hash function -- that's quite out of
scope for now, and with a hash table, one has to think about collisions
too, etc. When I contributed BaseOrderedCollectionRedBlackTreeLib, I
wanted it to become *the* go-to associative data structure for edk2 --
at least in such DXE and UEFI driver contexts where frequent pool
allocations and releases are not a problem. Plus, RB trees double as
fast priority queues, can be used for one-off sorting, have worst-case
(not just on-average) O(log n) time guarantees... I think they're
versatile.)

Cheers
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Brijesh Singh]

On 8/23/17 8:22 PM, Laszlo Ersek wrote:Okay, I will look into it -
thanks for the tip. I wanted to actually use
>> the Simple array (because we know the maximum number of buffer we can
>> queue) but was  not sure about your preferences hence I went to with
>> list. If you are okay then I can use array's too.
> My concern isn't about memory consumption (if our queue is full (64
> elements, IIRC), we just reject the transmit request and let the caller
> deal with the error).
>
> Instead, I'd like to avoid an O(n) lookup time (where n is the number of
> pending requests), for whatever lookup is necessary now (I haven't
> checked the specifics yet). BaseOrderedCollectionRedBlackTreeLib would
> give you O(log n) lookup time.
>
> Without having looked at the details, I think an array would have O(n)
> lookup time as well (linear search, right?).
>
> (Let's not try to do O(1) with a hash function -- that's quite out of
> scope for now, and with a hash table, one has to think about collisions
> too, etc. When I contributed BaseOrderedCollectionRedBlackTreeLib, I
> wanted it to become *the* go-to associative data structure for edk2 --
> at least in such DXE and UEFI driver contexts where frequent pool
> allocations and releases are not a problem. Plus, RB trees double as
> fast priority queues, can be used for one-off sorting, have worst-case
> (not just on-average) O(log n) time guarantees... I think they're
> versatile.)

To my understanding the network packet enqueued in the transmit ring
will be completed in same order, hence I was thinking about the queue
data structure and was not concern about the search time. I was mostly
concerned about the memory consumption but if my understanding is wrong
then I agree that we need to pick right data structure. Since the
RedBlack tree is already implemented hence I have no issue using it. thanks

-Brijesh
 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] UefiCpuPkg/MpLib: fix potential overflow issue.

[Eric Dong]

Current calculate timeout logic may have overflow if the input
timeout value too large. This patch fix this potential overflow
issue.

V2: Use local variable instead of call GetPerformanceCounterProperties
twice. Also correct some comments.

Cc: Michael Kinney 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 UefiCpuPkg/Library/MpInitLib/MpLib.c | 43 +++-
 1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index ed1f55e..8394572 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -1001,6 +1001,9 @@ CalculateTimeout (
   OUT UINT64  *CurrentTime
   )
 {
+  UINT64 TimeoutInSeconds;
+  UINT64 TimestampCounterFreq;
+
   //
   // Read the current value of the performance counter
   //
@@ -1016,16 +1019,36 @@ CalculateTimeout (
 
   //
   // GetPerformanceCounterProperties () returns the timestamp counter's 
frequency
-  // in Hz. So multiply the return value with TimeoutInMicroseconds and then 
divide
-  // it by 1,000,000, to get the number of ticks for the timeout value.
-  //
-  return DivU64x32 (
-   MultU64x64 (
- GetPerformanceCounterProperties (NULL, NULL),
- TimeoutInMicroseconds
- ),
-   100
-   );
+  // in Hz. 
+  //
+  TimestampCounterFreq = GetPerformanceCounterProperties (NULL, NULL);
+
+  //
+  // Check the potential overflow before calculate the number of ticks for the 
timeout value.
+  //
+  if (DivU64x64Remainder (MAX_UINT64, TimeoutInMicroseconds, NULL) < 
TimestampCounterFreq) {
+//
+// Convert microseconds into seconds if direct multiplication overflows
+//
+TimeoutInSeconds = DivU64x32 (TimeoutInMicroseconds, 100);
+//
+// Assertion if the final tick count exceeds MAX_UINT64
+//
+ASSERT (DivU64x64Remainder (MAX_UINT64, TimeoutInSeconds, NULL) >= 
TimestampCounterFreq);
+return MultU64x64 (TimestampCounterFreq, TimeoutInSeconds);
+  } else {
+//
+// No overflow case, multiply the return value with TimeoutInMicroseconds 
and then divide
+// it by 1,000,000, to get the number of ticks for the timeout value.
+//
+return DivU64x32 (
+ MultU64x64 (
+   TimestampCounterFreq,
+   TimeoutInMicroseconds
+   ),
+ 100
+ );
+  }
 }
 
 /**
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 2/4] UefiCpuPkg/CpuCommonFeaturesLib: Use MSR data structure when change MSR value.

[Eric Dong]

When update MSR values, current code use BITxx to modify it. Enhance the code
to use corresponding MSR's data structures to make it more user friendly.

V2: Move architecturalMsr.h file. definition to architecturalMsr.h file.
Use structure members to do value assignment.

Cc: Michael Kinney 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 .../Library/CpuCommonFeaturesLib/ProcTrace.c   | 116 +++--
 1 file changed, 61 insertions(+), 55 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
index 40e6321..e4636b2 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
@@ -14,30 +14,17 @@
 
 #include "CpuCommonFeatures.h"
 
-#define MAX_TOPA_ENTRY_COUNT 2
-
 ///
-/// Processor trace buffer size selection.
+/// This macro define the max entries in the Topa table.
+/// Each entry in the table contains some attribute bits, a pointer to an 
output region, and the size of the region. 
+/// The last entry in the table may hold a pointer to the next table. This 
pointer can either point to the top of the 
+/// current table (for circular array) or to the base of another table. 
+/// At least 2 entries are needed because the list of entries must 
+/// be terminated by an entry with the END bit set to 1, so 2 
+/// entries are required to use a single valid entry.
 ///
-typedef enum {
-  Enum4K= 0,
-  Enum8K,
-  Enum16K,
-  Enum32K,
-  Enum64K,
-  Enum128K,
-  Enum256K,
-  Enum512K,
-  Enum1M,
-  Enum2M,
-  Enum4M,
-  Enum8M,
-  Enum16M,
-  Enum32M,
-  Enum64M,
-  Enum128M,
-  EnumProcTraceMemDisable
-} PROC_TRACE_MEM_SIZE;
+#define MAX_TOPA_ENTRY_COUNT 2
+
 
 ///
 /// Processor trace output scheme selection.
@@ -70,7 +57,7 @@ typedef struct  {
 } PROC_TRACE_DATA;
 
 typedef struct {
-  UINT64   TopaEntry[MAX_TOPA_ENTRY_COUNT];
+  RTIT_TOPA_TABLE_ENTRYTopaEntry[MAX_TOPA_ENTRY_COUNT];
 } PROC_TRACE_TOPA_TABLE;
 
 /**
@@ -134,8 +121,8 @@ ProcTraceSupport (
   // Check if ProcTraceMemorySize option is enabled (0xFF means disable by 
user)
   //
   ProcTraceData = (PROC_TRACE_DATA *) ConfigData;
-  if ((ProcTraceData->ProcTraceMemSize >= EnumProcTraceMemDisable) ||
-  (ProcTraceData->ProcTraceOutputScheme >= OutputSchemeInvalid)) {
+  if ((ProcTraceData->ProcTraceMemSize > RtitTopaMemorySize128M) ||
+  (ProcTraceData->ProcTraceOutputScheme > ProcTraceOutputSchemeToPA)) {
 return FALSE;
   }
 
@@ -186,7 +173,6 @@ ProcTraceInitialize (
   IN BOOLEAN   State
   )
 {
-  UINT64   MsrValue;
   UINT32   MemRegionSize;
   UINTNPages;
   UINTNAlignment;
@@ -199,6 +185,11 @@ ProcTraceInitialize (
   PROC_TRACE_TOPA_TABLE*TopaTable;
   PROC_TRACE_DATA  *ProcTraceData;
   BOOLEAN  FirstIn;
+  MSR_IA32_RTIT_CTL_REGISTER   CtrlReg;
+  MSR_IA32_RTIT_STATUS_REGISTERStatusReg;
+  MSR_IA32_RTIT_OUTPUT_BASE_REGISTER   OutputBaseReg;
+  MSR_IA32_RTIT_OUTPUT_MASK_PTRS_REGISTER  OutputMaskPtrsReg;
+  RTIT_TOPA_TABLE_ENTRY*TopaEntryPtr;
 
   ProcTraceData = (PROC_TRACE_DATA *) ConfigData;
 
@@ -221,29 +212,28 @@ ProcTraceInitialize (
   //
   // Clear MSR_IA32_RTIT_CTL[0] and IA32_RTIT_STS only if 
MSR_IA32_RTIT_CTL[0]==1b
   //
-  MsrValue = AsmReadMsr64 (MSR_IA32_RTIT_CTL);
-  if ((MsrValue & BIT0) != 0) {
+  CtrlReg.Uint64 = AsmReadMsr64 (MSR_IA32_RTIT_CTL);
+  if (CtrlReg.Bits.TraceEn != 0) {
 ///
 /// Clear bit 0 in MSR IA32_RTIT_CTL (570)
 ///
-MsrValue &= (UINT64) ~BIT0;
+CtrlReg.Bits.TraceEn = 0;
 CPU_REGISTER_TABLE_WRITE64 (
   ProcessorNumber,
   Msr,
   MSR_IA32_RTIT_CTL,
-  MsrValue
+  CtrlReg.Uint64
   );
 
 ///
 /// Clear MSR IA32_RTIT_STS (571h) to all zeros
 ///
-MsrValue = AsmReadMsr64 (MSR_IA32_RTIT_STATUS);
-MsrValue &= 0x0;
+StatusReg.Uint64 = 0x0;
 CPU_REGISTER_TABLE_WRITE64 (
   ProcessorNumber,
   Msr,
   MSR_IA32_RTIT_STATUS,
-  MsrValue
+  StatusReg.Uint64
   );
   }
 
@@ -309,37 +299,38 @@ ProcTraceInitialize (
 //
 // Clear MSR IA32_RTIT_CTL (0x570) ToPA (Bit 8)
 //
-MsrValue = AsmReadMsr64 (MSR_IA32_RTIT_CTL);
-MsrValue &= (UINT64) ~BIT8;
+CtrlReg.Uint64 = AsmReadMsr64 (MSR_IA32_RTIT_CTL);
+CtrlReg.Bits.ToPA = 0;
 CPU_REGISTER_TABLE_WRITE64 (
   ProcessorNumber,
   Msr,
   MSR_IA32_RTIT_CTL,
-  MsrValue
+  CtrlReg.Uint64
   );
 
 //
-// Program MSR IA32_RTIT_OUTPUT_BASE (0x560) bits[47:12] with the 
allocated Memory Region
+// Program MSR IA32_RTIT_OUTPUT_BASE (0x560) bits[63:7] with the allocated 
Memory Region
 //
-MsrValue = (UINT64) MemRegionBaseAddr;
+Out

[edk2] [Patch 0/4] Enhance the implementation for Proc Trace feature.

[Eric Dong]

V2:
1. Move RTIT_TOPA_MEMORY_SIZE definition to architecturalMsr.h file.
2. Use strcture menbers to do value assignment.
3. Enhance the comments for PCD PcdCpuProcTraceMemSize and 
PcdCpuProcTraceOutputScheme.

Eric Dong (4):
  UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA table entry definition.
  UefiCpuPkg/CpuCommonFeaturesLib: Use MSR data structure when change
MSR value.
  UefiCpuPkg/CpuCommonFeaturesLib: Remove redundant definition.
  UefiCpuPkg: Update default for
PcdCpuProcTraceMemSize/PcdCpuProcTraceOutputScheme.

 UefiCpuPkg/Include/Register/ArchitecturalMsr.h |  79 -
 .../Library/CpuCommonFeaturesLib/ProcTrace.c   | 131 +++--
 UefiCpuPkg/UefiCpuPkg.dec  |  22 ++--
 UefiCpuPkg/UefiCpuPkg.uni  |  16 +--
 5 files changed, 200 insertions(+), 91 deletions(-)

-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 3/4] UefiCpuPkg/CpuCommonFeaturesLib: Remove redundant definition.

[Eric Dong]

The EnumProcTraceMemDisable/OutputSchemeInvalid are redundant
definitions. These definitions can be handled by other code,
so remove them.

V2: Change enum members name.

Cc: Michael Kinney 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c 
b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
index e4636b2..167c1be 100644
--- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
+++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
@@ -30,10 +30,9 @@
 /// Processor trace output scheme selection.
 ///
 typedef enum {
-  OutputSchemeSingleRange = 0,
-  OutputSchemeToPA,
-  OutputSchemeInvalid
-} PROC_TRACE_OUTPUT_SCHEME;
+  RtitOutputSchemeSingleRange = 0,
+  RtitOutputSchemeToPA
+} RTIT_OUTPUT_SCHEME;
 
 typedef struct  {
   BOOLEAN  ProcTraceSupported;
@@ -122,7 +121,7 @@ ProcTraceSupport (
   //
   ProcTraceData = (PROC_TRACE_DATA *) ConfigData;
   if ((ProcTraceData->ProcTraceMemSize > RtitTopaMemorySize128M) ||
-  (ProcTraceData->ProcTraceOutputScheme > ProcTraceOutputSchemeToPA)) {
+  (ProcTraceData->ProcTraceOutputScheme > RtitOutputSchemeToPA)) {
 return FALSE;
   }
 
@@ -138,8 +137,8 @@ ProcTraceSupport (
   AsmCpuidEx (CPUID_INTEL_PROCESSOR_TRACE, 
CPUID_INTEL_PROCESSOR_TRACE_MAIN_LEAF, NULL, NULL, &Ecx.Uint32, NULL);
   ProcTraceData->ProcessorData[ProcessorNumber].TopaSupported = (BOOLEAN) 
(Ecx.Bits.RTIT == 1);
   ProcTraceData->ProcessorData[ProcessorNumber].SingleRangeSupported = 
(BOOLEAN) (Ecx.Bits.SingleRangeOutput == 1);
-  if (ProcTraceData->ProcessorData[ProcessorNumber].TopaSupported || 
-  ProcTraceData->ProcessorData[ProcessorNumber].SingleRangeSupported) {
+  if ((ProcTraceData->ProcessorData[ProcessorNumber].TopaSupported && 
(ProcTraceData->ProcTraceOutputScheme == RtitOutputSchemeToPA)) ||
+  (ProcTraceData->ProcessorData[ProcessorNumber].SingleRangeSupported && 
(ProcTraceData->ProcTraceOutputScheme == RtitOutputSchemeSingleRange))) {
 return TRUE;
   }
 
@@ -291,7 +290,7 @@ ProcTraceInitialize (
   //  Single Range output scheme
   //
   if (ProcTraceData->ProcessorData[ProcessorNumber].SingleRangeSupported && 
-  (ProcTraceData->ProcTraceOutputScheme == OutputSchemeSingleRange)) {
+  (ProcTraceData->ProcTraceOutputScheme == RtitOutputSchemeSingleRange)) {
 if (FirstIn) {
   DEBUG ((DEBUG_INFO, "ProcTrace: Enabling Single Range Output scheme 
\n"));
 }
@@ -337,7 +336,7 @@ ProcTraceInitialize (
   //  ToPA(Table of physical address) scheme
   //
   if (ProcTraceData->ProcessorData[ProcessorNumber].TopaSupported && 
-  (ProcTraceData->ProcTraceOutputScheme == OutputSchemeToPA)) {
+  (ProcTraceData->ProcTraceOutputScheme == RtitOutputSchemeToPA)) {
 //
 //  Create ToPA structure aligned at 4KB for each logical thread
 //  with at least 2 entries by 8 bytes size each. The first entry
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 1/4] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA table entry definition.

[Eric Dong]

Add RTIT TOPA table entry definition to architecturalMsr.h file.

V2: Add RTIT_TOPA_MEMORY_SIZE definition to architecturalMsr.h file.

Cc: Michael Kinney 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 UefiCpuPkg/Include/Register/ArchitecturalMsr.h | 79 +-
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h 
b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
index 4f9c103..34fdf5b 100644
--- a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
+++ b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h
@@ -6,7 +6,7 @@
   returned is a single 32-bit or 64-bit value, then a data structure is not
   provided for that MSR.
 
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -4534,6 +4534,83 @@ typedef union {
   UINT64  Uint64;
 } MSR_IA32_RTIT_OUTPUT_MASK_PTRS_REGISTER;
 
+/**
+  Format of ToPA table entries.
+**/
+typedef union {
+  ///
+  /// Individual bit fields
+  ///
+  struct {
+///
+/// [Bit 0] END. See Section 35.2.6.2, "Table of Physical Addresses 
(ToPA)".
+///
+UINT32  END:1;
+UINT32  Reserved1:1;
+///
+/// [Bit 2] INT. See Section 35.2.6.2, "Table of Physical Addresses 
(ToPA)".
+///
+UINT32  INT:1;
+UINT32  Reserved2:1;
+///
+/// [Bit 4] STOP. See Section 35.2.6.2, "Table of Physical Addresses 
(ToPA)".
+///
+UINT32  STOP:1;
+UINT32  Reserved3:1;
+///
+/// [Bit 6:9] Indicates the size of the associated output region. See 
Section
+/// 35.2.6.2, "Table of Physical Addresses (ToPA)".
+///
+UINT32  Size:4;
+UINT32  Reserved4:2;
+///
+/// [Bit 12:31] Output Region Base Physical Address low part.
+/// [Bit 12:31] Output Region Base Physical Address [12:63] value to match.
+/// ATTENTION: The size of the address field is determined by the 
processor's
+/// physical-address width (MAXPHYADDR) in bits, as reported in
+/// CPUID.8008H:EAX[7:0]. the above part of address reserved.
+/// True address field is [12:MAXPHYADDR-1], [MAXPHYADDR:63] is reserved 
part.
+/// Detail see Section 35.2.6.2, "Table of Physical Addresses (ToPA)".
+///
+UINT32  Base:20;
+///
+/// [Bit 32:63] Output Region Base Physical Address high part.
+/// [Bit 32:63] Output Region Base Physical Address [12:63] value to match.
+/// ATTENTION: The size of the address field is determined by the 
processor's
+/// physical-address width (MAXPHYADDR) in bits, as reported in
+/// CPUID.8008H:EAX[7:0]. the above part of address reserved.
+/// True address field is [12:MAXPHYADDR-1], [MAXPHYADDR:63] is reserved 
part.
+/// Detail see Section 35.2.6.2, "Table of Physical Addresses (ToPA)".
+///
+UINT32  BaseHi:32;
+  } Bits;
+  ///
+  /// All bit fields as a 64-bit value
+  ///
+  UINT64  Uint64;
+} RTIT_TOPA_TABLE_ENTRY;
+
+///
+/// The size of the associated output region usd by Topa.
+///
+typedef enum {
+  RtitTopaMemorySize4K = 0,
+  RtitTopaMemorySize8K,
+  RtitTopaMemorySize16K,
+  RtitTopaMemorySize32K,
+  RtitTopaMemorySize64K,
+  RtitTopaMemorySize128K,
+  RtitTopaMemorySize256K,
+  RtitTopaMemorySize512K,
+  RtitTopaMemorySize1M,
+  RtitTopaMemorySize2M,
+  RtitTopaMemorySize4M,
+  RtitTopaMemorySize8M,
+  RtitTopaMemorySize16M,
+  RtitTopaMemorySize32M,
+  RtitTopaMemorySize64M,
+  RtitTopaMemorySize128M
+} RTIT_TOPA_MEMORY_SIZE;
 
 /**
   Trace Control Register (R/W). If (CPUID.(EAX=07H, ECX=0):EBX[25] = 1).
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 4/4] UefiCpuPkg: Update default for PcdCpuProcTraceMemSize/PcdCpuProcTraceOutputScheme.

[Eric Dong]

These two definitions have redundant definition which can be handle by code.
This patch update them to follow new code definitions.

V2: Add more comments for the PCDs and keep consistent in .dec and .uni files.

Cc: Michael Kinney 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 UefiCpuPkg/UefiCpuPkg.dec | 22 --
 UefiCpuPkg/UefiCpuPkg.uni | 16 +---
 2 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index b4e099d..3bd8740 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -286,7 +286,9 @@
   gUefiCpuPkgTokenSpaceGuid.PcdCpuFeaturesSetting|{0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00}|VOID*|0x0019
 
   ## Contains the size of memory required when CPU processor trace is 
enabled.
-  #  Default value is 0x10 which disables the processor trace.
+  #  Processor trace is enabled through set BIT44(CPU_FEATURE_PROC_TRACE) in 
PcdCpuFeaturesSetting.
+  #  This PCD is ignored if CPU processor trace is disabled.
+  #  Default value is 0x00 which means 4KB of memory is allocated if CPU 
processor trace is enabled.
   #  0x0  -  4K.
   #  0x1  -  8K.
   #  0x2  -  16K.
@@ -303,19 +305,19 @@
   #  0xD  -  32M.
   #  0xE  -  64M.
   #  0xF  -  128M.
-  #  0x10 -  ProcTraceMemDisable.
-  # @Prompt The memory size used for processor trace.
-  # @ValidRange  0x8001 | 0 - 0x10
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceMemSize|0x10|UINT32|0x6012
+  # @Prompt The memory size used for processor trace if processor trace is 
enabled.
+  # @ValidRange  0x8001 | 0 - 0xF
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceMemSize|0x0|UINT32|0x6012
 
   ## Contains the processor trace output scheme when CPU processor trace is 
enabled.
-  #  Default value is 2 which disables the processor trace.
+  #  Processor trace is enabled through set BIT44(CPU_FEATURE_PROC_TRACE) in 
PcdCpuFeaturesSetting.
+  #  This PCD is ignored if CPU processor trace is disabled.
+  #  Default value is 0 which means single range output scheme will be used if 
CPU processor trace is enabled.
   #  0 - Single Range output scheme.
   #  1 - ToPA(Table of physical address) scheme.
-  #  2 - Invalid scheme.
-  # @Prompt The processor trace output scheme.
-  # @ValidRange  0x8001 | 0 - 2
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceOutputScheme|0x2|UINT8|0x6015
+  # @Prompt The processor trace output scheme used when processor trace is 
enabled.
+  # @ValidRange  0x8001 | 0 - 1
+  gUefiCpuPkgTokenSpaceGuid.PcdCpuProcTraceOutputScheme|0x0|UINT8|0x6015
 
 [UserExtensions.TianoCore."ExtraFiles"]
   UefiCpuPkgExtra.uni
diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
index 858e4a7..9472b18 100644
--- a/UefiCpuPkg/UefiCpuPkg.uni
+++ b/UefiCpuPkg/UefiCpuPkg.uni
@@ -197,8 +197,10 @@
 
 #string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuProcTraceMemSize_PROMPT  #language 
en-US "Memory size used by Processor Trace feature."
 
-#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuProcTraceMemSize_HELP  #language 
en-US "User input the memory size can be used by processor trace 
feature.\n"
-   
"Default value is 0x10 which disables the processor memory trace.\n"
+#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuProcTraceMemSize_HELP  #language 
en-US "User input the size of memory required when CPU processor trace is 
enabled.\n"
+   
"Processor trace is enabled through set BIT44(CPU_FEATURE_PROC_TRACE) in 
PcdCpuFeaturesSetting.\n"
+   
"This PCD is ignored if CPU processor trace is disabled.\n"
+   
"Default value is 0x00 which means 4KB of memory is allocated if CPU 
processor trace is enabled.\n"

"0x0  -  4K.\n"

"0x1  -  8K.\n"

"0x2  -  16K.\n"
@@ -215,12 +217,12 @@

"0xD  -  32M.\n"

"0xE  -  64M.\n"

"0xF  -  128M.\n"
-   
"0x10 -  ProcTraceMemDisable.\n"
 
 #string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuProcTraceOutputScheme_PROMPT  
#language en-US "Processor Trace output scheme type."
 
-#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuProcTraceOutputScheme_HELP  
#language en-U

Re: [edk2] [Patch] UefiCpuPkg/MpLib: fix potential overflow issue.

[Dong, Eric]

Mike, 

Thanks for the comments, I updated the patch, please help to review the new 
patch.

Thanks,
Eric
-Original Message-
From: Kinney, Michael D 
Sent: Thursday, August 24, 2017 5:51 AM
To: Dong, Eric ; edk2-devel@lists.01.org; Kinney, Michael 
D 
Cc: Ni, Ruiyu 
Subject: RE: [Patch] UefiCpuPkg/MpLib: fix potential overflow issue.

Hi Eric,

With this patch GetPerformanceCounterProperties() is called twice.  I think you 
can use TimestampCounterFreq in the else clause.

Also, the comment blocks are no longer correct.  The original comment block 
goes with the else clause, and you need a new comment block for the if 
statement that describes the check for an overflow.

Mike

> -Original Message-
> From: Dong, Eric
> Sent: Tuesday, August 22, 2017 10:30 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu 
> 
> Subject: [Patch] UefiCpuPkg/MpLib: fix potential overflow issue.
> 
> Current calculate timeout logic may have overflow if the input timeout 
> value too large. This patch fix this potential overflow issue.
> 
> Cc: Michael Kinney 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Library/MpInitLib/MpLib.c | 30
> +++---
>  1 file changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index ed1f55e..005dec4 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1001,6 +1001,9 @@ CalculateTimeout (
>OUT UINT64  *CurrentTime
>)
>  {
> +  UINT64 TimeoutInSeconds;
> +  UINT64 TimestampCounterFreq;
> +
>//
>// Read the current value of the performance counter
>//
> @@ -1019,13 +1022,26 @@ CalculateTimeout (
>// in Hz. So multiply the return value with TimeoutInMicroseconds 
> and then divide
>// it by 1,000,000, to get the number of ticks for the timeout 
> value.
>//
> -  return DivU64x32 (
> -   MultU64x64 (
> - GetPerformanceCounterProperties (NULL, NULL),
> - TimeoutInMicroseconds
> - ),
> -   100
> -   );
> +  TimestampCounterFreq = GetPerformanceCounterProperties
> (NULL, NULL);
> +  if (DivU64x64Remainder (MAX_UINT64, TimeoutInMicroseconds,
> NULL) < TimestampCounterFreq) {
> +//
> +// Convert microseconds into seconds if direct
> multiplication overflows
> +//
> +TimeoutInSeconds = DivU64x32 (TimeoutInMicroseconds,
> 100);
> +//
> +// Assertion if the final tick count exceeds MAX_UINT64
> +//
> +ASSERT (DivU64x64Remainder (MAX_UINT64, TimeoutInSeconds,
> NULL) >= TimestampCounterFreq);
> +return MultU64x64 (TimestampCounterFreq,
> TimeoutInSeconds);
> +  } else {
> +return DivU64x32 (
> + MultU64x64 (
> +   GetPerformanceCounterProperties (NULL, NULL),

Use TimestampCounterFreq instead.

> +   TimeoutInMicroseconds
> +   ),
> + 100
> + );
> +  }
>  }
> 
>  /**
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 1/2] UefiCpuPkg/CpuCommonFeaturesLib: Remove redundant definition.

[Dong, Eric]

Mike,

The new check for ProcTraceOutputScheme is for the functionality which is 
missed before. the user selection and hardware capability may not consistent. 
So I add this new check.

I agree to keep the validate check. Please check the new patch.

Thanks,
Eric
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, 
Michael D
Sent: Thursday, August 24, 2017 7:03 AM
To: Dong, Eric ; edk2-devel@lists.01.org; Kinney, Michael 
D 
Cc: Ni, Ruiyu 
Subject: Re: [edk2] [Patch 1/2] UefiCpuPkg/CpuCommonFeaturesLib: Remove 
redundant definition.

Eric,

Comment below.

Mike

> -Original Message-
> From: Dong, Eric
> Sent: Tuesday, August 22, 2017 7:31 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu 
> 
> Subject: [Patch 1/2] UefiCpuPkg/CpuCommonFeaturesLib: Remove redundant 
> definition.
> 
> The EnumProcTraceMemDisable/OutputSchemeInvalid are redundant 
> definitions. These definitions can be handled by other code, so remove 
> them.
> 
> Cc: Michael Kinney 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c | 14 
> --
>  1 file changed, 4 insertions(+), 10 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
> b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
> index a90dd4e..6524882 100644
> --- a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
> +++ b/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
> @@ -35,8 +35,7 @@ typedef enum {
>Enum16M,
>Enum32M,
>Enum64M,
> -  Enum128M,
> -  EnumProcTraceMemDisable
> +  Enum128M
>  } PROC_TRACE_MEM_SIZE;
> 
>  ///
> @@ -44,8 +43,7 @@ typedef enum {
>  ///
>  typedef enum {
>OutputSchemeSingleRange = 0,
> -  OutputSchemeToPA,
> -  OutputSchemeInvalid
> +  OutputSchemeToPA
>  } PROC_TRACE_OUTPUT_SCHEME;
> 
>  typedef struct  {
> @@ -134,10 +132,6 @@ ProcTraceSupport (
>// Check if ProcTraceMemorySize option is enabled (0xFF means 
> disable by user)
>//
>ProcTraceData = (PROC_TRACE_DATA *) ConfigData;
> -  if ((ProcTraceData->ProcTraceMemSize >=
> EnumProcTraceMemDisable) ||
> -  (ProcTraceData->ProcTraceOutputScheme >=
> OutputSchemeInvalid)) {
> -return FALSE;
> -  }

I see the ProcTraceOutputScheme values are checked below.
Do we need to keep the check for a valid ProcTraceMemSize value?

> 
>//
>// Check if Processor Trace is supported @@ -151,8 +145,8 @@ 
> ProcTraceSupport (
>AsmCpuidEx (CPUID_INTEL_PROCESSOR_TRACE, 
> CPUID_INTEL_PROCESSOR_TRACE_MAIN_LEAF, NULL, NULL, &Ecx.Uint32, NULL);
>ProcTraceData->ProcessorData[ProcessorNumber].TopaSupported =
> (BOOLEAN) (Ecx.Bits.RTIT == 1);
>ProcTraceData-
> >ProcessorData[ProcessorNumber].SingleRangeSupported = (BOOLEAN)
> (Ecx.Bits.SingleRangeOutput == 1);
> -  if (ProcTraceData->ProcessorData[ProcessorNumber].TopaSupported
> ||
> -  ProcTraceData-
> >ProcessorData[ProcessorNumber].SingleRangeSupported) {
> +  if ((ProcTraceData-
> >ProcessorData[ProcessorNumber].TopaSupported && (ProcTraceData- 
> >ProcTraceOutputScheme == OutputSchemeToPA)) ||
> +  (ProcTraceData-
> >ProcessorData[ProcessorNumber].SingleRangeSupported &&
> (ProcTraceData->ProcTraceOutputScheme ==
> OutputSchemeSingleRange))) {
>  return TRUE;
>}
> 
> --
> 2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 01/1 BroxtonPlatformPkg: Add SueCreek.asl

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../Common/Acpi/AcpiTablesPCAT/Platform.asl| 10 +++---
 .../AcpiTablesPCAT/PlatformSsdt/PlatformSsdt.asl   |  3 +-
 .../PlatformSsdt/SueCreek/SueCreek.asl | 42 ++
 3 files changed, 50 insertions(+), 5 deletions(-)
 create mode 100644 
Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/SueCreek/SueCreek.asl

diff --git 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/Platform.asl 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/Platform.asl
index 5c3b726..4674f70 100644
--- a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/Platform.asl
+++ b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/Platform.asl
@@ -708,10 +708,12 @@ Scope(\_SB)
 Return (RBUF)
   }
 
-  Method (_STA, 0x0, NotSerialized)
-  {
-
- Return (0xF)
+  Method (_STA, 0x0, NotSerialized) {
+If (LEqual (OSYS, 2015)) {
+  Return (0x0)
+} else {
+  Return (0xF)
+}
   }
 }
   }//end scope
diff --git 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/PlatformSsdt.asl
 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/PlatformSsdt.asl
index 0455c4b..1f9da76 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/PlatformSsdt.asl
+++ 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/PlatformSsdt.asl
@@ -1,5 +1,5 @@
 /** @file
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -65,5 +65,6 @@ DefinitionBlock (
   include ("Nfc/Nfc.asl")
 
   include ("Fingerprint/Fingerprint_FPC.asl")
+  include ("SueCreek/SueCreek.asl")
 }
 
diff --git 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/SueCreek/SueCreek.asl
 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/SueCreek/SueCreek.asl
new file mode 100644
index 000..d67b3c4
--- /dev/null
+++ 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/PlatformSsdt/SueCreek/SueCreek.asl
@@ -0,0 +1,42 @@
+/** @file
+
+Copyright (c) 2017 Intel Corporation.
+
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+Scope (\_SB.PCI0.SPI1) {
+  Device (TP0) {
+Name (_HID, "SPT0001")
+Name (_DDN, "SueCreek - SPI0, CS0")
+Name (_CRS, ResourceTemplate () {
+  SpiSerialBus (
+0,  // Chip select (0, 1, 2)
+PolarityLow,// Chip select is active low
+FourWireMode,   // Full duplex
+8,  // Bits per word is 8 (byte)
+ControllerInitiated,// Don't care
+100,// 1 MHz
+ClockPolarityLow,   // SPI mode 0
+ClockPhaseFirst,// SPI mode 0
+"\\_SB.PCI0.SPI1",  // SPI host controller
+0   // Must be 0
+  )
+})
+Method (_STA, 0x0, NotSerialized) {
+  If (LEqual (OSYS, 2015)) {
+Return (0x0)
+  } else {
+Return (0xF)
+  }
+}
+  }
+}
+
-- 
2.10.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 04/1 BroxtonPlatformPkg: Change MaxPkgCState default value

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../Common/PlatformSettings/PlatformSetupDxe/CpuPower.vfi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/CpuPower.vfi
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/CpuPower.vfi
index c28b03f..e15973a 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/CpuPower.vfi
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/CpuPower.vfi
@@ -64,9 +64,9 @@ form formid = CPU_PWR_CONFIGURATION_FORM_ID,
 oneof varid = Setup.MaxPkgCState,
   prompt  = STRING_TOKEN(STR_MAX_PKG_CSTATE_SUPPORT_PROMPT),
   help= STRING_TOKEN(STR_MAX_PKG_CSTATE_STATE_SUPPORT_HELP),
-  option text = STRING_TOKEN(STR_MAX_PKG_CSTATE_C2),  value = 2, flags = 
RESET_REQUIRED;
+  option text = STRING_TOKEN(STR_MAX_PKG_CSTATE_C2),  value = 2, flags = 
DEFAULT | MANUFACTURING | RESET_REQUIRED;
   option text = STRING_TOKEN(STR_MAX_PKG_CSTATE_C1),  value = 1, flags = 
RESET_REQUIRED;
-  option text = STRING_TOKEN(STR_MAX_PKG_CSTATE_C0),  value = 0, flags = 
DEFAULT | MANUFACTURING | RESET_REQUIRED;
+  option text = STRING_TOKEN(STR_MAX_PKG_CSTATE_C0),  value = 0, flags = 
RESET_REQUIRED;
 endoneof;
   endif;
   
-- 
2.10.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 02/1 BroxtonPlatformPkg: Code cleanup

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../BensonGlacier/BoardInitPreMem/BoardInit.c  | 11 +--
 .../BensonGlacier/BoardInitPreMem/BoardInit.h  | 16 +++--
 .../Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h |  4 +--
 .../Common/Acpi/AcpiTablesPCAT/ScLpss.asl  | 38 +-
 .../PlatformPreMemPei/BoardGpiosPreMem.c   |  4 +--
 .../PlatformPreMemPei/PlatformInitPreMem.c |  2 +-
 .../PlatformSetupDxe/PlatformSetupDxe.c|  1 +
 7 files changed, 22 insertions(+), 54 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInit.c 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInit.c
index 122ed9a..24cfaf3 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInit.c
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInit.c
@@ -13,16 +13,7 @@
 
 **/
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include "BoardInit.h"
-#include "PlatformId.h"
-#include "BoardInitMiscs.h"
 
 EFI_STATUS
 EFIAPI
@@ -60,7 +51,7 @@ BensonGlacierPreMemInit (
   UINT8FabId;
 
   BoardId = 0;
-  FabId = 0;
+  FabId   = 0;
   Status = PeiServicesLocatePpi (
  &gBoardPreMemInitDoneGuid,
  0,
diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInit.h 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInit.h
index 0a549c2..3153776 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInit.h
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInit.h
@@ -18,10 +18,22 @@
 #define _BENSON_BOARDINIT_H_
 
 #include 
-#include 
+
+#include 
+
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
-#include 
+
+#include 
+
+#include "BoardInitMiscs.h"
+#include "PlatformId.h"
 
 VOID BensonGpioTest (VOID);
 
diff --git 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h
index f588165..73e1dda 100644
--- a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h
+++ b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h
@@ -2,7 +2,7 @@
   This file describes the contents of the ACPI Fixed ACPI Description Table
   (FADT).
 
-  Copyright (c) 1999 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 1999 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -23,7 +23,7 @@
 // ACPI table information used to initialize tables.
 //
 #define EFI_ACPI_OEM_ID   'I','N','T','E','L',' '   // OEMID 6 bytes 
long
-#define EFI_ACPI_OEM_TABLE_ID 
SIGNATURE_64('L','A','N','F','O','R','D','C') // OEM table id 8 bytes long
+#define EFI_ACPI_OEM_TABLE_ID 
SIGNATURE_64('M','I','N','N','O','W','v','3') // OEM table id 8 bytes long
 #define EFI_ACPI_OEM_REVISION 0x0005
 #define EFI_ACPI_CREATOR_ID   SIGNATURE_32('M','S','F','T')
 #define EFI_ACPI_CREATOR_REVISION 0x010D
diff --git a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/ScLpss.asl 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/ScLpss.asl
index 9ad39c8..bb462b7 100644
--- a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/ScLpss.asl
+++ b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/ScLpss.asl
@@ -1,7 +1,7 @@
 /** @file
   ACPI DSDT table
 
-  Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2012 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -47,24 +47,6 @@ scope (\_SB.PCI0) {
   Return (RBUF)
 }
 
-  Device (VUT0) {
-Name (_HID, "INT3511")
-Method (_STA, 0x0, NotSerialized)
-{
-  If(LEqual(OSYS,2015)) {
-Return(0xf)
-  }
-  else {
-Return(0)
-  }
-}
-Method(_CRS, 0x0, NotSerialized){
-Name(SBUF, ResourceTemplate (){
-UARTSerialBus(115200,,,0xfc32,32,"\\_SB.PCI0.URT1" )
-})
-Return (SBUF)
-}
-  } //Device (VUT0)
 
   } //  Device (URT1)
 
@@ -91,24 +73,6 @@ scope (\_SB.PCI0) {
   PSAT,   32
 }
 
-  Device (VUT1) {
-Name (_HID, "INT3512")
-Method (_STA, 0x0, NotSerialized)
-{
-  If(LEqual(OSYS,2015)) {
-Return(0xf)
-  }
-  else {
-Return(0)
-  }
-}
-Method(_CRS, 0x0, NotSerialized){
-Name(SBUF, ResourceTemplate (){
-UARTSerialBus(115200,,,0xfc32,32,"\\_SB.PCI0.URT2" )
-})
-Return (SBUF)
-}
-  } // Device(VUT1)
   } // Device (URT2)
 
   //
diff --git 
a/Platform/BroxtonPlatformPkg/Comm

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 03/1 BroxtonPlatformPkg: Change reset type

[Guo, Mang]

Change reset type from code reset to warm reset.

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../Common/PlatformSettings/PlatformSetupDxe/SystemComponent.vfi| 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SystemComponent.vfi
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SystemComponent.vfi
index 0893b59..16822f6 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SystemComponent.vfi
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SystemComponent.vfi
@@ -1,7 +1,7 @@
 // /** @file
 //  System Component Setup formset.
 //
-//  Copyright (c) 1999 - 2016, Intel Corporation. All rights reserved.
+//  Copyright (c) 1999 - 2017, Intel Corporation. All rights reserved.
 //
 //  This program and the accompanying materials
 //  are licensed and made available under the terms and conditions of the BSD 
License
@@ -48,8 +48,8 @@ form formid = SYSTEM_COMPONENT_FORM_ID,
   oneof varid   = Setup.ResetSelect,
 prompt  = STRING_TOKEN(STR_RESET_SELECT),
 help= STRING_TOKEN(STR_RESET_SELECT_HELP),
-option text = STRING_TOKEN(STR_WARM_RESET), value = 0x6, flags = 
RESET_REQUIRED;
-option text = STRING_TOKEN(STR_COLD_RESET), value = 0xE, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+option text = STRING_TOKEN(STR_WARM_RESET), value = 0x6, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+option text = STRING_TOKEN(STR_COLD_RESET), value = 0xE, flags = 
RESET_REQUIRED;
   endoneof;
 
   // Embedded Power Instrumentation
-- 
2.10.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 05/1 BroxtonPlatformPkg: Disable ISH

[Guo, Mang]

1. Disable ISH
2. Coding style

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../PlatformSettings/PlatformSetupDxe/SouthClusterConfig.vfi | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SouthClusterConfig.vfi
 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SouthClusterConfig.vfi
index 866dff5..35aeb34 100644
--- 
a/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SouthClusterConfig.vfi
+++ 
b/Platform/BroxtonPlatformPkg/Common/PlatformSettings/PlatformSetupDxe/SouthClusterConfig.vfi
@@ -266,8 +266,8 @@ form formid = ISH_OPTIONS_FORM_ID,
   oneof varid  = Setup.ScIshEnabled,
   prompt   = STRING_TOKEN(STR_ISH_PROMPT),
   help = STRING_TOKEN(STR_ISH_HELP),
-  option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = 
RESET_REQUIRED;
-  option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+  option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+  option text = STRING_TOKEN(STR_ENABLE),  value = 1, flags = 
RESET_REQUIRED;
 endoneof;
 
 endform; // End of ISH Configurations
@@ -2395,7 +2395,7 @@ form formid = USB_OPTIONS_FORM_ID,
   prompt  = STRING_TOKEN(STR_PCH_USB3_PORT5_PROMPT),
   help= STRING_TOKEN(STR_PCH_USB_PORT_DIS_HELP),
   option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = 
RESET_REQUIRED;
-  option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+  option text = STRING_TOKEN(STR_ENABLE),  value = 1, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
 endoneof;
   endif;
 
@@ -2411,7 +2411,7 @@ form formid = USB_OPTIONS_FORM_ID,
 prompt  = STRING_TOKEN(STR_XHCI_COMPLIANCE_PROMPT),
 help= STRING_TOKEN(STR_XHCI_COMPLIANCE_HELP),
 option text = STRING_TOKEN(STR_XHCI_COMPLIANCE_FALSE), value = 0, flags = 
DEFAULT | MANUFACTURING | RESET_REQUIRED;
-option text = STRING_TOKEN(STR_XHCI_COMPLIANCE_TRUE), value = 1, flags = 
RESET_REQUIRED;
+option text = STRING_TOKEN(STR_XHCI_COMPLIANCE_TRUE),  value = 1, flags = 
RESET_REQUIRED;
   endoneof;
   
 endform; // end of USB_OPTIONS_FORM_ID
@@ -2677,14 +2677,14 @@ form formid = HDAUDIO_OPTIONS_FORM_ID,
 prompt  = STRING_TOKEN(STR_HDA_PROMPT),
 help= STRING_TOKEN(STR_HDA_HELP),
 option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = RESET_REQUIRED;
-option text = STRING_TOKEN(STR_ENABLE), value= 1, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+option text = STRING_TOKEN(STR_ENABLE),  value = 1, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
   endoneof;
 
   oneof varid   = Setup.ScHdAudioDsp,
 prompt  = STRING_TOKEN(STR_HDA_DSP_PROMPT),
 help= STRING_TOKEN(STR_HDA_DSP_HELP),
 option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = RESET_REQUIRED;
-option text = STRING_TOKEN(STR_ENABLE), value= 1, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
+option text = STRING_TOKEN(STR_ENABLE),  value = 1, flags = DEFAULT | 
MANUFACTURING | RESET_REQUIRED;
   endoneof;
 
  suppressif ideqval Setup.ScHdAudioDsp == 0;
-- 
2.10.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 06/1BroxtonSiPkg: Add I2CLibPei

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../PlatformDsc/Components.IA32.dsc|   1 +
 .../SouthCluster/Include/Library/I2CLib.h  | 106 +---
 .../SouthCluster/Include/ScRegs/RegsI2c.h  | 143 +
 .../SouthCluster/Library/I2CLibPei/I2CAccess.h |  51 ++
 .../SouthCluster/Library/I2CLibPei/I2CDelayPei.c   |  49 ++
 .../SouthCluster/Library/I2CLibPei/I2CDelayPei.h   |  34 ++
 .../SouthCluster/Library/I2CLibPei/I2CIoLibPei.c   | 175 ++
 .../SouthCluster/Library/I2CLibPei/I2CIoLibPei.h   | 146 +
 .../SouthCluster/Library/I2CLibPei/I2CLibPei.c | 665 +
 .../SouthCluster/Library/I2CLibPei/I2CLibPei.inf   |  51 ++
 10 files changed, 1322 insertions(+), 99 deletions(-)
 create mode 100644 
Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Include/ScRegs/RegsI2c.h
 create mode 100644 
Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Library/I2CLibPei/I2CAccess.h
 create mode 100644 
Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Library/I2CLibPei/I2CDelayPei.c
 create mode 100644 
Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Library/I2CLibPei/I2CDelayPei.h
 create mode 100644 
Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Library/I2CLibPei/I2CIoLibPei.c
 create mode 100644 
Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Library/I2CLibPei/I2CIoLibPei.h
 create mode 100644 
Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Library/I2CLibPei/I2CLibPei.c
 create mode 100644 
Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Library/I2CLibPei/I2CLibPei.inf

diff --git a/Platform/BroxtonPlatformPkg/PlatformDsc/Components.IA32.dsc 
b/Platform/BroxtonPlatformPkg/PlatformDsc/Components.IA32.dsc
index f8900ea..cdbba2a 100644
--- a/Platform/BroxtonPlatformPkg/PlatformDsc/Components.IA32.dsc
+++ b/Platform/BroxtonPlatformPkg/PlatformDsc/Components.IA32.dsc
@@ -116,6 +116,7 @@

NULL|$(PLATFORM_NAME)/Board/MinnowBoard3/BoardInitPostMem/BoardInitPostMem.inf

NULL|$(PLATFORM_NAME)/Board/LeafHill/BoardInitPostMem/BoardInitPostMem.inf

NULL|$(PLATFORM_NAME)/Board/BensonGlacier/BoardInitPostMem/BoardInitPostMem.inf
+   
I2cLibPei|$(PLATFORM_SI_PACKAGE)/SouthCluster/Library/I2CLibPei/I2CLibPei.inf
 
   gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x803805c6
   }
diff --git 
a/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Include/Library/I2CLib.h 
b/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Include/Library/I2CLib.h
index b593620..b897cb9 100644
--- a/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Include/Library/I2CLib.h
+++ b/Silicon/BroxtonSoC/BroxtonSiPkg/SouthCluster/Include/Library/I2CLib.h
@@ -1,7 +1,7 @@
 /** @file
   Register Definitions for I2C Library.
 
-  Copyright (c) 1999 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 1999 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -18,111 +18,19 @@
 
 #include 
 #include 
-
 //
 // FIFO write workaround value.
 //
 #define FIFO_WRITE_DELAY2
 
-//
-// MMIO Register Definitions
-//
-#defineR_IC_CON  (0x00)  ///< I2C Control
-#defineB_IC_RESTART_EN  BIT5
-#defineB_IC_SLAVE_DISABLE   BIT6
-#defineV_SPEED_STANDARD 0x02
-#defineV_SPEED_FAST 0x04
-#defineV_SPEED_HIGH 0x06
-#defineB_MASTER_MODEBIT0
-
-#defineR_IC_TAR (0x04)  ///< I2C Target Address
-#defineIC_TAR_10BITADDR_MASTER  BIT12
-
-#defineR_IC_SAR (0x08)  ///< I2C Slave Address
-#defineR_IC_HS_MADDR(0x0C)  ///< I2C HS MasterMode 
Code Address
-#defineR_IC_DATA_CMD(0x10)  ///< I2C Rx/Tx Data Buffer 
and Command
-
-#defineB_READ_CMDBIT8   ///< 1 = read, 0 = write
-#defineB_CMD_STOPBIT9   ///< 1 = STOP
-#defineB_CMD_RESTART BIT10  ///< 1 = IC_RESTART_EN
-
-#defineV_WRITE_CMD_MASK  (0xFF)
-
-#defineR_IC_SS_SCL_HCNT  (0x14)  ///< Standard Speed I2C 
Clock SCL High Count
-#defineR_IC_SS_SCL_LCNT  (0x18)  ///< Standard Speed I2C 
Clock SCL Low Count
-#defineR_IC_FS_SCL_HCNT  (0x1C)  ///< Full Speed I2C Clock 
SCL High Count
-#defineR_IC_FS_SCL_LCNT  (0x20)  ///< Full Speed I2C Clock 
SCL Low Count
-#defineR_IC_HS_SCL_HCNT  (0x24)  ///< High Speed I2C Clock 
SCL High Count
-#defineR_IC_HS_SCL_LCNT  (0x28)  ///< High Speed I2C Clock 
SCL Low Count
-#defineR_IC_INTR_STAT(0x2C)  ///< I2C Inetrrupt Status
-#defineR_IC_INTR_MASK(0x30)  ///< I2C Interrupt Mask
-#defineI2C_INTR_GEN_CALL BIT11   ///< General call rece

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 07/1 BroxtonPlatformPkg: Add BensonTypeC support

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../BensonGlacier/BoardInitPostMem/BoardInit.c |   8 -
 .../BensonGlacier/BoardInitPostMem/BoardInit.h |  15 +-
 .../BoardInitPostMem/BoardInitMiscs.c  |  37 ++-
 .../BoardInitPostMem/BoardInitMiscs.h  |  68 +++--
 .../BoardInitPostMem/BoardInitPostMem.inf  |   6 +-
 .../Board/BensonGlacier/BoardInitPostMem/TypeC.c   | 288 +
 .../Board/BensonGlacier/BoardInitPostMem/TypeC.h   |  79 ++
 7 files changed, 463 insertions(+), 38 deletions(-)
 create mode 100644 
Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/TypeC.c
 create mode 100644 
Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/TypeC.h

diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.c 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.c
index 7c44a63..729a158 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.c
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.c
@@ -13,15 +13,7 @@
 
 **/
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include "BoardInit.h"
-#include "BoardInitMiscs.h"
 
 EFI_STATUS
 EFIAPI
diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.h 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.h
index 0a549c2..870f9c3 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.h
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInit.h
@@ -18,10 +18,21 @@
 #define _BENSON_BOARDINIT_H_
 
 #include 
-#include 
+
+#include 
+
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
-#include 
+
+#include 
+
+#include "BoardInitMiscs.h"
 
 VOID BensonGpioTest (VOID);
 
diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInitMiscs.c
 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInitMiscs.c
index e10ab84..49c8b60 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInitMiscs.c
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInitMiscs.c
@@ -15,7 +15,6 @@
 
 #include "BoardInitMiscs.h"
 
-
 /**
   Configure GPIO group GPE tier.
 
@@ -49,6 +48,7 @@ BensonMultiPlatformInfoInit (
   IN OUT EFI_PLATFORM_INFO_HOB  *PlatformInfoHob
   )
 {
+  UINT8  Data8;
   EFI_STATUS Status;
 
 #if (ENBDT_PF_ENABLE == 1)
@@ -128,6 +128,39 @@ BensonMultiPlatformInfoInit (
   Status = BensonInitializeBoardOemId (PeiServices, PlatformInfoHob);
   Status = BensonInitializeBoardSsidSvid (PeiServices, PlatformInfoHob);
 
+  //
+  // TypeC MUX AUX mode
+  //
+
+  //
+  // Set P0-P4 to input mode
+  //
+  Data8  = 0x1F;
+  Status = ByteWriteI2C (0x05, 0x38, 0x03, 1, &Data8);
+  DEBUG ((DEBUG_INFO, "%a(#%d) - Setting button MUX into GPI mode returned 
%r\n", __FUNCTION__, __LINE__, Status));
+
+  //
+  // Set P0-P4 to inverted mode
+  //
+  Data8  = 0x1F;
+  Status = ByteWriteI2C (0x05, 0x38, 0x02, 1, &Data8);
+  DEBUG ((DEBUG_INFO, "%a(#%d) - Setting button MUX into inverted mode 
returned %r\n", __FUNCTION__, __LINE__, Status));
+
+  //
+  // Dump switch state
+  //
+  Data8  = 0x00;
+  Status = ByteReadI2C (0x05, 0x38, 0x00, 1, &Data8);
+  DEBUG ((DEBUG_INFO, "%a(#%d) - ByteReadI2C[0] returned %r\n", __FUNCTION__, 
__LINE__, Status));
+  if (!EFI_ERROR (Status)) {
+DEBUG ((DEBUG_INFO, "%a(#%d) - Input register = %02x\n", 
__FUNCTION__, __LINE__, Data8));
+DEBUG ((DEBUG_INFO, "%a(#%d) -   Volume + = %a\n", 
__FUNCTION__, __LINE__, (Data8 & BIT0) ? "Pressed" : "Not pressed"));
+DEBUG ((DEBUG_INFO, "%a(#%d) -   Volume - = %a\n", 
__FUNCTION__, __LINE__, (Data8 & BIT1) ? "Pressed" : "Not pressed"));
+DEBUG ((DEBUG_INFO, "%a(#%d) -BT Pair = %a\n", 
__FUNCTION__, __LINE__, (Data8 & BIT2) ? "Pressed" : "Not pressed"));
+DEBUG ((DEBUG_INFO, "%a(#%d) -   Mic Mute = %a\n", 
__FUNCTION__, __LINE__, (Data8 & BIT3) ? "Pressed" : "Not pressed"));
+DEBUG ((DEBUG_INFO, "%a(#%d) -   Speaker Mute = %a\n", 
__FUNCTION__, __LINE__, (Data8 & BIT4) ? "Pressed" : "Not pressed"));
+  }
+
   return EFI_SUCCESS;
 }
 
@@ -151,7 +184,7 @@ BensonInitializeBoardOemId (
   break;
   }
 
-  PlatformInfoHob->AcpiOemId = OemId;
+  PlatformInfoHob->AcpiOemId  = OemId;
   PlatformInfoHob->AcpiOemTableId = OemTableId;
 
   return  EFI_SUCCESS;
diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInitMiscs.h
 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInitMiscs.h
index b9844ef..2cf4810 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardInitMiscs.h
+++ 
b/Platform/BroxtonPlatfo

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 08/1VBT change for TypeC

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../Common/Binaries/Vbt/VbtBxtMipi.bin| Bin 5632 -> 5632 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/Platform/BroxtonPlatformPkg/Common/Binaries/Vbt/VbtBxtMipi.bin 
b/Platform/BroxtonPlatformPkg/Common/Binaries/Vbt/VbtBxtMipi.bin
index 
cc6f2e509af449b0f2eb8adf9536cb1bc6d17702..23b52baea1f7ab470ad7f6c375893e453ba9cb42
 100644
GIT binary patch
delta 56
zcmZqBY0#M<#XOtAU~(X%@J54aj0)Eh7z6|u{%|lbC@?TE04WdUU~(X%@J54aj0%?$7z6|u{%|lbC@?TEFo6++0D}Uf0wa*mz_9rl
Hqm&2$VG;@c

-- 
2.10.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 10/1 BroxtonPlatformPkg: Disable NPK based on DciEn

[Guo, Mang]

Disable NPK based on DciEn

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../BensonGlacier/BoardInitPreMem/BoardInitMiscs.c | 56 ++
 1 file changed, 37 insertions(+), 19 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInitMiscs.c
 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInitMiscs.c
index 0b602bd..afad081 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInitMiscs.c
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInitMiscs.c
@@ -36,14 +36,16 @@ BgUpdateFspmUpd (
   IN FSPM_UPD*FspUpdRgn
   )
 {
-  EFI_PEI_HOB_POINTERS   Hob;
-  EFI_PLATFORM_INFO_HOB  *PlatformInfo = NULL;
-  DRAM_POLICY_PPI*DramPolicy;
-  EFI_STATUS Status;
- MRC_NV_DATA_FRAME *MrcNvData;
-
-  MRC_PARAMS_SAVE_RESTORE*MrcParamsHob;
-  BOOT_VARIABLE_NV_DATA  *BootVariableNvDataHob;
+  EFI_PEI_HOB_POINTERS   Hob;
+  EFI_PLATFORM_INFO_HOB *PlatformInfo = NULL;
+  DRAM_POLICY_PPI   *DramPolicy;
+  EFI_STATUS Status;
+  MRC_NV_DATA_FRAME *MrcNvData;
+  MRC_PARAMS_SAVE_RESTORE   *MrcParamsHob;
+  BOOT_VARIABLE_NV_DATA *BootVariableNvDataHob;
+  SYSTEM_CONFIGURATION   SystemConfiguration;
+  UINTN  VariableSize;
+  EFI_PEI_READ_ONLY_VARIABLE2_PPI   *VariablePpi;
 
   Status = (*PeiServices)->LocatePpi (
  PeiServices,
@@ -115,7 +117,7 @@ BgUpdateFspmUpd (
   FspUpdRgn->FspmConfig.Profile   = 0x0B; // LPDDR4_2400_24_22_22
   FspUpdRgn->FspmConfig.MemoryDown= 0x01;
   FspUpdRgn->FspmConfig.DualRankSupportEnable = 0x01;
-  
+
   FspUpdRgn->FspmConfig.Ch0_RankEnable= 0x03; // [0]: Rank 0 [1]: Rank 
1
   FspUpdRgn->FspmConfig.Ch0_DeviceWidth   = 0x01; // x16
   FspUpdRgn->FspmConfig.Ch0_DramDensity   = 0x02; // 8Gb
@@ -146,6 +148,31 @@ BgUpdateFspmUpd (
 CopyMem (&(FspUpdRgn->FspmConfig.Ch3_Bit_swizzling), ChSwizzle_BG[3], 
DRAM_POLICY_NUMBER_BITS * sizeof(UINT8));
   }
 
+  //
+  // Disable NPK based on DciEn
+  //
+  Status = PeiServicesLocatePpi (&gEfiPeiReadOnlyVariable2PpiGuid, 0, NULL, 
(VOID **) &VariablePpi);
+  if (!EFI_ERROR (Status)) {
+VariableSize = sizeof (SYSTEM_CONFIGURATION);
+Status = VariablePpi->GetVariable (
+VariablePpi,
+PLATFORM_SETUP_VARIABLE_NAME,
+&gEfiSetupVariableGuid,
+NULL,
+&VariableSize,
+&SystemConfiguration
+);
+if (!EFI_ERROR (Status)) {
+  if (SystemConfiguration.DciEn == 0) {
+FspUpdRgn->FspmConfig.NpkEn = 0;
+  } else if (SystemConfiguration.DciAutoDetect == 1) {
+FspUpdRgn->FspmConfig.NpkEn = 3;
+  } else {
+FspUpdRgn->FspmConfig.NpkEn = 1;
+  }
+}
+  }
+
   return EFI_SUCCESS;
 }
 
@@ -290,16 +317,7 @@ BgDramCreatePolicyDefaults (
 CopyMem (DramPolicy->ChSwizzle, ChSwizlePtr, sizeof 
(DramPolicy->ChSwizzle));
   }
 
-  Status = VariablePpi->GetVariable (
-  VariablePpi,
-  PLATFORM_SETUP_VARIABLE_NAME,
-  &gEfiSetupVariableGuid,
-  NULL,
-  &VariableSize,
-  &SystemConfiguration
-  );
-
-  if (!EFI_ERROR (Status)) {
+  if (ReadSetupVars) {
 if (SystemConfiguration.Max2G == 0) {
   DramPolicy->SystemMemorySizeLimit = 0x800;
 }
-- 
2.10.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 09/1 BroxtonPlatformPkg: Fix MRC param issue

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../BensonGlacier/BoardInitPreMem/BoardInitMiscs.c  | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInitMiscs.c
 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInitMiscs.c
index d0987bb..0b602bd 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInitMiscs.c
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPreMem/BoardInitMiscs.c
@@ -40,8 +40,8 @@ BgUpdateFspmUpd (
   EFI_PLATFORM_INFO_HOB  *PlatformInfo = NULL;
   DRAM_POLICY_PPI*DramPolicy;
   EFI_STATUS Status;
-  MRC_PARAMS_SAVE_RESTORE*MrcNvData;
-  BOOT_VARIABLE_NV_DATA  *BootVariableNvData;
+ MRC_NV_DATA_FRAME *MrcNvData;
+
   MRC_PARAMS_SAVE_RESTORE*MrcParamsHob;
   BOOT_VARIABLE_NV_DATA  *BootVariableNvDataHob;
 
@@ -84,18 +84,13 @@ BgUpdateFspmUpd (
 CopyMem (&(FspUpdRgn->FspmConfig.Ch0_Bit_swizzling), 
&DramPolicy->ChSwizzle, sizeof (DramPolicy->ChSwizzle));
 
 if (((VOID *)(UINT32)DramPolicy->MrcTrainingDataPtr != 0) &&
-   ((VOID *)(UINT32)DramPolicy->MrcBootDataPtr != 0)) {
-  DEBUG ((DEBUG_INFO, "UpdateFspmUpd - NvsBufferPtr\n"));
-  MrcNvData  = (MRC_PARAMS_SAVE_RESTORE *) AllocateZeroPool 
(sizeof (MRC_PARAMS_SAVE_RESTORE));
-  BootVariableNvData = (BOOT_VARIABLE_NV_DATA *) AllocateZeroPool (sizeof 
(BOOT_VARIABLE_NV_DATA));
-
-  MrcParamsHob  = 
(MRC_PARAMS_SAVE_RESTORE*)((UINT32)DramPolicy->MrcTrainingDataPtr);
+((VOID *)(UINT32)DramPolicy->MrcBootDataPtr != 0)) {
+  MrcNvData = (MRC_NV_DATA_FRAME *) AllocateZeroPool (sizeof 
(MRC_NV_DATA_FRAME));
+  MrcParamsHob = 
(MRC_PARAMS_SAVE_RESTORE*)((UINT32)DramPolicy->MrcTrainingDataPtr);
   BootVariableNvDataHob = 
(BOOT_VARIABLE_NV_DATA*)((UINT32)DramPolicy->MrcBootDataPtr);
-
-  CopyMem(MrcNvData, MrcParamsHob, sizeof (MRC_PARAMS_SAVE_RESTORE));
-  CopyMem(BootVariableNvData, BootVariableNvDataHob, sizeof 
(BOOT_VARIABLE_NV_DATA));
-  FspUpdRgn->FspmArchUpd.NvsBufferPtr= (VOID *)(UINT32)MrcNvData;
-  FspUpdRgn->FspmConfig.VariableNvsBufferPtr = (VOID 
*)(UINT32)BootVariableNvData;
+  CopyMem(&(MrcNvData->MrcParamsSaveRestore), MrcParamsHob, sizeof 
(MRC_PARAMS_SAVE_RESTORE));
+  CopyMem(&(MrcNvData->BootVariableNvData), BootVariableNvDataHob, sizeof 
(BOOT_VARIABLE_NV_DATA));
+  FspUpdRgn->FspmArchUpd.NvsBufferPtr = (VOID *)(UINT32)MrcNvData;
 }
 
   }
-- 
2.10.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017 11/1 BroxtonPlatformPkg: Remove EFI_ACPI_5_0_SLP_BUTTON

[Guo, Mang]

Contributed-under: TianoCore Contribution Agreement 1.0

Signed-off-by: Guo Mang 
---
 .../BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h 
b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h
index 73e1dda..cc66d08 100644
--- a/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h
+++ b/Platform/BroxtonPlatformPkg/Common/Acpi/AcpiTablesPCAT/AcpiTablePlatform.h
@@ -60,7 +60,7 @@
 #define DAY_ALRM0x0D
 #define MON_ALRM0x00
 #define CENTURY 0x32
-#define FLAG(EFI_ACPI_5_0_WBINVD | EFI_ACPI_5_0_SLP_BUTTON | 
EFI_ACPI_5_0_RESET_REG_SUP | EFI_ACPI_5_0_RTC_S4)
+#define FLAG(EFI_ACPI_5_0_WBINVD | EFI_ACPI_5_0_RESET_REG_SUP | 
EFI_ACPI_5_0_RTC_S4)
 #define IAPC_BOOT_ARCH  (EFI_ACPI_5_0_8042 | EFI_ACPI_5_0_LEGACY_DEVICES)
 #define RESERVED0x00
 
-- 
2.10.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Star Zeng]

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 is not supported at Ia32 build.

This patch is to get the PhysicalAddressBits that is used
to build in PageTbl.c(Ia32/X64), and use it to check whether
the address is supported or not in ConvertMemoryPageAttributes().

With this patch, the debug messages will be like below.
UefiMemory protection: 0x0 - 0x9F000 Success
UefiMemory protection: 0x10 - 0x807000 Success
UefiMemory protection: 0x808000 - 0x81 Success
UefiMemory protection: 0x818000 - 0x82 Success
UefiMemory protection: 0x151 - 0x7B798000 Success
UefiMemory protection: 0x7B79B000 - 0x7E538000 Success
UefiMemory protection: 0x7E539000 - 0x7E545000 Success
UefiMemory protection: 0x7E55A000 - 0x7E61F000 Success
UefiMemory protection: 0x7E62B000 - 0x7F6AB000 Success
UefiMemory protection: 0x7F703000 - 0x7F70B000 Success
UefiMemory protection: 0x7F70F000 - 0x7F778000 Success
UefiMemory protection: 0x1 - 0x18000 Unsupported

Cc: Jiewen Yao 
Cc: Laszlo Ersek 
Cc: Eric Dong 
Originally-suggested-by: Jiewen Yao 
Reported-by: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |  4 +++
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h |  1 +
 UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 31 +-
 3 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index 32ce5958c59c..e88b42d73343 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -16,6 +16,8 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 #include "PiSmmCpuDxeSmm.h"
 
+UINT8   mPhysicalAddressBits;
+
 /**
   Create PageTable for SMM use.
 
@@ -36,6 +38,8 @@ SmmInitPageTable (
   //
   InitializeSpinLock (mPFLock);
 
+  mPhysicalAddressBits = 32;
+
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 //
 // Set own Page Fault entry instead of the default one, because SMM Profile
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
index dbce9ec520fe..1cf85c1481a7 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
@@ -419,6 +419,7 @@ extern SPIN_LOCK   
*mConfigSmmCodeAccessCheckLock;
 extern SPIN_LOCK   *mMemoryMappedLock;
 extern EFI_SMRAM_DESCRIPTOR*mSmmCpuSmramRanges;
 extern UINTN   mSmmCpuSmramRangeCount;
+extern UINT8   mPhysicalAddressBits;
 
 //
 // Copy of the PcdPteMemoryEncryptionAddressOrMask
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
index a535389c26ce..3ad5256f1e03 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2016, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -380,6 +380,7 @@ ConvertMemoryPageAttributes (
   PAGE_ATTRIBUTESplitAttribute;
   RETURN_STATUS Status;
   BOOLEAN   IsEntryModified;
+  EFI_PHYSICAL_ADDRESS  MaximumSupportMemAddress;
 
   ASSERT (Attributes != 0);
   ASSERT ((Attributes & ~(EFI_MEMORY_RP | EFI_MEMORY_RO | EFI_MEMORY_XP)) == 
0);
@@ -391,6 +392,17 @@ ConvertMemoryPageAttributes (
 return RETURN_INVALID_PARAMETER;
   }
 
+  MaximumSupportMemAddress = (EFI_PHYSICAL_ADDRESS)(UINTN)(LShiftU64 (1, 
mPhysicalAddressBits) - 1);
+  if (BaseAddress > MaximumSupportMemAddress) {
+return RETURN_UNSUPPORTED;
+  }
+  if (Length > MaximumSupportMemAddress) {
+return RETURN_UNSUPPORTED;
+  }
+  if ((Length != 0) && (BaseAddress > MaximumSupportMemAddress - (Length - 
1))) {
+return RETURN_UNSUPPORTED;
+  }
+
 //  DEBUG ((DEBUG_ERROR, "ConvertMemoryPageAttributes(%x) - %016lx, %016lx, 
%02lx\n", IsSet, BaseAddress, Length, Attributes));
 
   if (IsSplitted != NULL) {
@@ -1037,6 +1049,7 @@ SetUefiMemMapAttributes (
   VOID
   )
 {
+  EFI_STATUSStatus;
   EFI_MEMORY_DESCRIPTOR *MemoryMap;
   UINTN MemoryMapEntryCount;
   UINTN Index;
@@ -1052,12 +1065,18 @@ SetUefiMemMapAttributes (
   MemoryMap = mUefiMemoryMap;
   for (Index = 0; Index < MemoryMapEntryCount; In

Re: [edk2] [Patch v2 1/2] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA table entry definition.

[Dong, Eric]

Mike,



Add my comments below.



-Original Message-
From: Kinney, Michael D
Sent: Thursday, August 24, 2017 7:45 AM
To: Dong, Eric ; edk2-devel@lists.01.org; Kinney, Michael 
D 
Cc: Ni, Ruiyu 
Subject: RE: [Patch v2 1/2] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA table 
entry definition.



Hi Eric,



I see that the legal values for the Size field of RTIT_TOPA_TABLE_ENTRY are 
documented in the SDM.



I think we should add the enum for PROC_TRACE_MEM_SIZE into ArchitecturalMsr.h 
next to RTIT_TOPA_TABLE_ENTRY.

Maybe rename it to RTIT_TOPA_MEMORY_SIZE with enum names that start with 
"RtitTopaMemorySize".

[[Eric]] agree, update in the new patch.



The Copyright date in ArchitecturalMsr.h also needs to be updated.

[[Eric]] agree, update in the new patch.



The #define for MAX_TOPA_ENTRY_COUNT need a comment block that describes what 
it is and why it has a value of 2.  I see

2 entries are needed because the list of entries must be terminated by an entry 
with the END bit set to 1, so 2 entries are required to use a single valid 
entry.

[[Eric]] agree, update in the new patch.



ProcTrace.c: Please update programming of MSR_IA32_RTIT_OUTPUT_BASE to use the 
named bit fields from the structure.

ProcTrace.c: Please update programming of MSR_IA32_RTIT_OUTPUT_MASK_PTRS to use 
the named bit fields from the structure.

[[Eric]] I think current code is easy to write but it may touch the reserve 
bits. Agree to change to use the bit fields. Update in the new patches.



ProcTrace.c: I am confused by the programming MSR_IA32_RTIT_OUTPUT_MASK_PTRS to 
0x7f.  That sets a Reserved field to all 1s.
[[Eric]] Copy from the sdm, default value is all 1. Write to it is ignored. So 
I think the original code is same as set the others bits all 0. I have update 
code to directly set other bits to 0. Please check the new patch.

[cid:image001.jpg@01D31CCB.2A4EEA30]





ProcTrace.c: I see a mix of setting TopaEntryPtr using both bit fields and the 
Uint64 field.  Can we change to use only the bit fields.

[[Eric]] same reason as before, use Uint64 is easy to write but may touch the 
reserved bits. Update code to use bit fields.



Do we really need to set the address field in entry #1?  Isn't setting END to 1 
enough?

[[Eric]] Copy below from sdm. This code point to the current table for a 
circular case.

[cid:image002.jpg@01D31CCB.2A4EEA30]





Thanks,

Mike



> -Original Message-

> From: Dong, Eric

> Sent: Thursday, August 17, 2017 8:29 PM

> To: edk2-devel@lists.01.org

> Cc: Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>; Ni, Ruiyu

> mailto:ruiyu...@intel.com>>

> Subject: [Patch v2 1/2] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA

> table entry definition.

>

> Add RTIT TOPA table entry definition to architecturalMsr.h file.

>

> Cc: Michael Kinney 
> mailto:michael.d.kin...@intel.com>>

> Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>

> Contributed-under: TianoCore Contribution Agreement 1.1

> Signed-off-by: Eric Dong mailto:eric.d...@intel.com>>

> ---

>  UefiCpuPkg/Include/Register/ArchitecturalMsr.h | 55

> ++

>  1 file changed, 55 insertions(+)

>

> diff --git a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h

> b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h

> index 4f9c103..40c4383 100644

> --- a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h

> +++ b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h

> @@ -4534,6 +4534,61 @@ typedef union {

>UINT64  Uint64;

>  } MSR_IA32_RTIT_OUTPUT_MASK_PTRS_REGISTER;

>

> +/**

> +  Format of ToPA table entries.

> +**/

> +typedef union {

> +  ///

> +  /// Individual bit fields

> +  ///

> +  struct {

> +///

> +/// [Bit 0] END. See Section 35.2.6.2, "Table of Physical

> Addresses (ToPA)".

> +///

> +UINT32  END:1;

> +UINT32  Reserved1:1;

> +///

> +/// [Bit 2] INT. See Section 35.2.6.2, "Table of Physical

> Addresses (ToPA)".

> +///

> +UINT32  INT:1;

> +UINT32  Reserved2:1;

> +///

> +/// [Bit 4] STOP. See Section 35.2.6.2, "Table of Physical

> Addresses (ToPA)".

> +///

> +UINT32  STOP:1;

> +UINT32  Reserved3:1;

> +///

> +/// [Bit 6:9] Indicates the size of the associated output

> region. See Section

> +/// 35.2.6.2, "Table of Physical Addresses (ToPA)".

> +///

> +UINT32  Size:4;

> +UINT32  Reserved4:2;

> +///

> +/// [Bit 12:31] Output Region Base Physical Address low part.

> +/// [Bit 12:31] Output Region Base Physical Address [12:63]

> value to match.

> +/// ATTENTION: The size of the address field is determined by

> the processor's

> +/// physical-address width (MAXPHYADDR) in bits, as reported

> in

> +/// CPUID.8008H:EAX[7:0]. the above part of address

> reserved.

> +/// True address field is [12:MAXPHYADDR-1], [MAXPHYADDR:63]

> is reserved part.

> +/// Detail see Section 35.2.6.2, "Table of Physical Address

[edk2] [Patch] BaseTools: Update tools_def to remove /Gw option in VS NOOPT target

[Liming Gao]

To remove /Gw option is to disable size optimization.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
Cc: Yonghong Zhu 
---
 BaseTools/Conf/tools_def.template | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index e0ef4b1..24956e4 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -3171,7 +3171,7 @@ NOOPT_VS2012x86xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT
   *_VS2013_IA32_MAKE_FLAGS= /nologo
   DEBUG_VS2013_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Gw
 RELEASE_VS2013_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gw
-NOOPT_VS2013_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od /Gw
+NOOPT_VS2013_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od
 
   DEBUG_VS2013_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 RELEASE_VS2013_IA32_ASM_FLAGS = /nologo /c /WX /W3 /Cx /coff /Zd
@@ -3203,7 +3203,7 @@ NOOPT_VS2013_IA32_DLINK_FLAGS = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF
 
   DEBUG_VS2013_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Gw
 RELEASE_VS2013_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Gw
-NOOPT_VS2013_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od /Gw
+NOOPT_VS2013_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D UNICODE 
/Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od
 
   DEBUG_VS2013_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 RELEASE_VS2013_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
@@ -3289,7 +3289,7 @@ NOOPT_VS2013_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT
   *_VS2013xASL_IA32_MAKE_FLAGS  = /nologo
   DEBUG_VS2013xASL_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Gw
 RELEASE_VS2013xASL_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gw
-NOOPT_VS2013xASL_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od /Gw
+NOOPT_VS2013xASL_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od
 
   DEBUG_VS2013xASL_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 RELEASE_VS2013xASL_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd
@@ -3321,7 +3321,7 @@ NOOPT_VS2013xASL_IA32_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:RE
 
   DEBUG_VS2013xASL_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Gw
 RELEASE_VS2013xASL_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Gw
-NOOPT_VS2013xASL_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od /Gw
+NOOPT_VS2013xASL_X64_CC_FLAGS   = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Od
 
   DEBUG_VS2013xASL_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd /Zi
 RELEASE_VS2013xASL_X64_ASM_FLAGS= /nologo /c /WX /W3 /Cx /Zd
@@ -3405,7 +3405,7 @@ NOOPT_VS2013xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:RE
   *_VS2013x86_IA32_MAKE_FLAGS  = /nologo
   DEBUG_VS2013x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Gw
 RELEASE_VS2013x86_IA32_CC_FLAGS= /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /O1b2 /GL /FIAutoGen.h /EHs-c- /GR- /GF /Gw
-NOOPT_VS2013x86_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od /Gw
+NOOPT_VS2013x86_IA32_CC_FLAGS  = /nologo /arch:IA32 /c /WX /GS- /W4 
/Gs32768 /D UNICODE /FIAutoGen.h /EHs-c- /GR- /GF /Gy /Zi /Gm /Od
 
   DEBUG_VS2013x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd /Zi
 RELEASE_VS2013x86_IA32_ASM_FLAGS   = /nologo /c /WX /W3 /Cx /coff /Zd
@@ -3437,7 +3437,7 @@ NOOPT_VS2013x86_IA32_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 
   DEBUG_VS2013x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /GF /Zi /Gm /Gw
 RELEASE_VS2013x86_X64_CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /D 
UNICODE /O1b2s /GL /Gy /FIAutoGen.h /EHs-c- /GR- /

Re: [edk2] [Patch v2 1/2] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA table entry definition.

[Dong, Eric]

Mike,

I found the attach pic can't show up. Append the content directly from sdm.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dong, 
Eric
Sent: Thursday, August 24, 2017 11:22 AM
To: Kinney, Michael D ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu 
Subject: Re: [edk2] [Patch v2 1/2] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA 
table entry definition.

Mike,

Add my comments below.

-Original Message-
From: Kinney, Michael D
Sent: Thursday, August 24, 2017 7:45 AM
To: Dong, Eric ; edk2-devel@lists.01.org; Kinney, Michael 
D 
Cc: Ni, Ruiyu 
Subject: RE: [Patch v2 1/2] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA table 
entry definition.



Hi Eric,



I see that the legal values for the Size field of RTIT_TOPA_TABLE_ENTRY are 
documented in the SDM.



I think we should add the enum for PROC_TRACE_MEM_SIZE into ArchitecturalMsr.h 
next to RTIT_TOPA_TABLE_ENTRY.

Maybe rename it to RTIT_TOPA_MEMORY_SIZE with enum names that start with 
"RtitTopaMemorySize".

[[Eric]] agree, update in the new patch.



The Copyright date in ArchitecturalMsr.h also needs to be updated.

[[Eric]] agree, update in the new patch.



The #define for MAX_TOPA_ENTRY_COUNT need a comment block that describes what 
it is and why it has a value of 2.  I see

2 entries are needed because the list of entries must be terminated by an entry 
with the END bit set to 1, so 2 entries are required to use a single valid 
entry.

[[Eric]] agree, update in the new patch.



ProcTrace.c: Please update programming of MSR_IA32_RTIT_OUTPUT_BASE to use the 
named bit fields from the structure.

ProcTrace.c: Please update programming of MSR_IA32_RTIT_OUTPUT_MASK_PTRS to use 
the named bit fields from the structure.

[[Eric]] I think current code is easy to write but it may touch the reserve 
bits. Agree to change to use the bit fields. Update in the new patches.



ProcTrace.c: I am confused by the programming MSR_IA32_RTIT_OUTPUT_MASK_PTRS to 
0x7f.  That sets a Reserved field to all 1s.
[[Eric]] Copy from the sdm, default value is all 1. Write to it is ignored. So 
I think the original code is same as set the others bits all 0. I have update 
code to directly set other bits to 0. Please check the new patch.

[cid:image001.jpg@01D31CCB.2A4EEA30]

[[Eric]] Found the attached pic can't show, copy the context like below:

Table 35-9. IA32_RTIT_OUTPUT_MASK_PTRS MSR
Position Bit Name  At Reset   Bit 
Description
6:0LowerMask  7FH 
Forced to 1, writes are ignored


ProcTrace.c: I see a mix of setting TopaEntryPtr using both bit fields and the 
Uint64 field.  Can we change to use only the bit fields.

[[Eric]] same reason as before, use Uint64 is easy to write but may touch the 
reserved bits. Update code to use bit fields.


Do we really need to set the address field in entry #1?  Isn't setting END to 1 
enough?

[[Eric]] Copy below from sdm. This code point to the current table for a 
circular case.

[cid:image002.jpg@01D31CCB.2A4EEA30]

[[Eric]] Found the attached pic can't show, copy the context like below:

35.2.6.2 Table of Physical Addresses (ToPA)
When IA32_RTIT_CTL.ToPA is set and IA32_RTIT_CTL.FabricEn is clear, the ToPA 
output mechanism is utilized. The
ToPA mechanism uses a linked list of tables; see Figure 35-1 for an 
illustrative example. Each entry in the table
contains some attribute bits, a pointer to an output region, and the size of 
the region. The last entry in the table
may hold a pointer to the next table. This pointer can either point to the top 
of the current table (for circular array)
or to the base of another table. The table size is not fixed, since the link to 
the next table can exist at any entry.




Thanks,

Mike



> -Original Message-

> From: Dong, Eric

> Sent: Thursday, August 17, 2017 8:29 PM

> To: edk2-devel@lists.01.org

> Cc: Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>; Ni, Ruiyu

> mailto:ruiyu...@intel.com>>

> Subject: [Patch v2 1/2] UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA

> table entry definition.

>

> Add RTIT TOPA table entry definition to architecturalMsr.h file.

>

> Cc: Michael Kinney 
> mailto:michael.d.kin...@intel.com>>

> Cc: Ruiyu Ni mailto:ruiyu...@intel.com>>

> Contributed-under: TianoCore Contribution Agreement 1.1

> Signed-off-by: Eric Dong mailto:eric.d...@intel.com>>

> ---

>  UefiCpuPkg/Include/Register/ArchitecturalMsr.h | 55

> ++

>  1 file changed, 55 insertions(+)

>

> diff --git a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h

> b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h

> index 4f9c103..40c4383 100644

> --- a/UefiCpuPkg/Include/Register/ArchitecturalMsr.h

> +++ b/UefiCpuPkg/Include/Register/ArchitecturalMsr.h

> @@ -4534,6 +4534,61 @@ typedef union {

>UINT64  Uint64;

>  } MSR_IA32_RTIT_OUTPUT_MASK_PTRS_REGISTER;

>

> +/

[edk2] [Patch] BaseTools: Support /WHOLEARCHIVE option in VS2015 tool chain

[Liming Gao]

https://bugzilla.tianocore.org/show_bug.cgi?id=582

Don't enable this option in the default setting, because it may cause VS2015
linker crash. Platform can enable this option in PlatformPkg.dsc like below:
[BuildOptions]
*_*_*_DLINK2_FLAGS = /WHOLEARCHIVE

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
Cc: Yonghong Zhu 
---
 BaseTools/Conf/build_rule.template | 1 +
 BaseTools/Conf/tools_def.template  | 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 1db94b6..d8c8253 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -289,6 +289,7 @@
 $(DEBUG_DIR)(+)$(MODULE_NAME).dll
 
 
+"$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK2_FLAGS) $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST)
 "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST)
 
 
diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 1fa3ca3..e0ef4b1 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -575,7 +575,7 @@ DEFINE SOURCERY_CYGWIN_TOOLS = /cygdrive/c/Program 
Files/CodeSourcery/Sourcery G
 #   Intel(r) ACPI Compiler (iasl.exe) from
 #   https://acpica.org/downloads
 #   VS2015x86   -win64-  Requires:
-# Microsoft Visual Studio 2015 (x86) Professional 
Edition
+# Microsoft Visual Studio 2015 (x86) Update 2 or 
above
 # Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
 #Optional:
 # Required to build platforms or ACPI tables:
@@ -3605,6 +3605,7 @@ NOOPT_VS2013x86xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT
 *_VS2015_*_APP_FLAGS  = /nologo /E /TC
 *_VS2015_*_PP_FLAGS   = /nologo /E /TC /FIAutoGen.h
 *_VS2015_*_VFRPP_FLAGS= /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
+*_VS2015_*_DLINK2_FLAGS   =
 
 *_VS2015_*_ASM16_PATH = DEF(VS2015_BIN)\ml.exe
 
@@ -3723,6 +3724,7 @@ NOOPT_VS2015_X64_DLINK_FLAGS  = /NOLOGO /NODEFAULTLIB 
/IGNORE:4001 /OPT:REF /OPT
 *_VS2015xASL_*_APP_FLAGS   = /nologo /E /TC
 *_VS2015xASL_*_PP_FLAGS= /nologo /E /TC /FIAutoGen.h
 *_VS2015xASL_*_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
+*_VS2015xASL_*_DLINK2_FLAGS=
 
 *_VS2015xASL_*_ASM16_PATH  = DEF(VS2015_BIN)\ml.exe
 
@@ -3839,6 +3841,7 @@ NOOPT_VS2015xASL_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:RE
 *_VS2015x86_*_APP_FLAGS   = /nologo /E /TC
 *_VS2015x86_*_PP_FLAGS= /nologo /E /TC /FIAutoGen.h
 *_VS2015x86_*_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
+*_VS2015x86_*_DLINK2_FLAGS=
 
 *_VS2015x86_*_ASM16_PATH  = DEF(VS2015x86_BIN)\ml.exe
 
@@ -3954,6 +3957,7 @@ NOOPT_VS2015x86_X64_DLINK_FLAGS= /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2015x86xASL_*_APP_FLAGS   = /nologo /E /TC
 *_VS2015x86xASL_*_PP_FLAGS= /nologo /E /TC /FIAutoGen.h
 *_VS2015x86xASL_*_VFRPP_FLAGS = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
+*_VS2015x86xASL_*_DLINK2_FLAGS=
 
 *_VS2015x86xASL_*_ASM16_PATH  = DEF(VS2015x86_BIN)\ml.exe
 
-- 
2.8.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

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

[Liming Gao]

https://bugzilla.tianocore.org/show_bug.cgi?id=581

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
Cc: Yonghong Zhu 
---
 BaseTools/Conf/tools_def.template | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 24956e4..a85afd5 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -4377,7 +4377,7 @@ DEFINE GCC44_IA32_CC_FLAGS   = 
DEF(GCC44_ALL_CC_FLAGS) -m32 -march=i586
 DEFINE GCC44_X64_CC_FLAGS= DEF(GCC44_ALL_CC_FLAGS) -m64 
-fno-stack-protector "-DEFIAPI=__attribute__((ms_abi))" 
-maccumulate-outgoing-args -mno-red-zone -Wno-address -mcmodel=small -fpie 
-fno-asynchronous-unwind-tables
 DEFINE GCC44_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z 
common-page-size=0x20
 DEFINE GCC44_IA32_X64_ASLDLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_COMMON) 
-Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
-DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
-Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) 
-Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+DEFINE GCC44_IA32_X64_DLINK_FLAGS= DEF(GCC44_IA32_X64_DLINK_COMMON) 
-Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) 
-Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive
 DEFINE GCC44_IA32_DLINK2_FLAGS   = -Wl,--defsym=PECOFF_HEADER_SIZE=0x220 
DEF(GCC_DLINK2_FLAGS_COMMON)
 DEFINE GCC44_X64_DLINK_FLAGS = DEF(GCC44_IA32_X64_DLINK_FLAGS) 
-Wl,-melf_x86_64,--oformat=elf64-x86-64
 DEFINE GCC44_X64_DLINK2_FLAGS= -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 
DEF(GCC_DLINK2_FLAGS_COMMON)
@@ -4457,7 +4457,7 @@ DEFINE GCC49_IA32_CC_FLAGS   = 
DEF(GCC48_IA32_CC_FLAGS)
 DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS)
 DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-n,-q,--gc-sections -z 
common-page-size=0x40
 DEFINE GCC49_IA32_X64_ASLDLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_COMMON) 
-Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
-DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC49_IA32_X64_DLINK_COMMON) 
-Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) 
-Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map
+DEFINE GCC49_IA32_X64_DLINK_FLAGS= DEF(GCC49_IA32_X64_DLINK_COMMON) 
-Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) 
-Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive
 DEFINE GCC49_IA32_DLINK2_FLAGS   = DEF(GCC48_IA32_DLINK2_FLAGS)
 DEFINE GCC49_X64_DLINK_FLAGS = DEF(GCC49_IA32_X64_DLINK_FLAGS) 
-Wl,-melf_x86_64,--oformat=elf64-x86-64
 DEFINE GCC49_X64_DLINK2_FLAGS= DEF(GCC48_X64_DLINK2_FLAGS)
-- 
2.8.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] SecurityPkg/Tcg2Dxe: Properly shutdown TPM before reset

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Chao B Zhang 
---
 SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c   | 43 +
 SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf |  1 +
 2 files changed, 44 insertions(+)

diff --git a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c 
b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
index c2c52e32b8..e4be8f75a8 100644
--- a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
+++ b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c
@@ -31,6 +31,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -2437,6 +2438,36 @@ InstallTcg2 (
 }
 
 /**
+ This routine is called to properly shutdown the TPM per TCG spec.
+
+  @param[in]  ResetType The type of reset to perform.
+  @param[in]  ResetStatus   The status code for the reset.
+  @param[in]  DataSize  The size, in bytes, of ResetData.
+  @param[in]  ResetData For a ResetType of EfiResetCold, EfiResetWarm, 
or
+EfiResetShutdown the data buffer starts with a 
Null-terminated
+string, optionally followed by additional 
binary data.
+The string is a description that the caller 
may use to further
+indicate the reason for the system reset. 
ResetData is only
+valid if ResetStatus is something other than 
EFI_SUCCESS
+unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.
+For a ResetType of EfiResetPlatformSpecific 
the data buffer
+also starts with a Null-terminated string that 
is followed
+by an EFI_GUID that describes the specific 
type of reset to perform.
+**/
+VOID
+EFIAPI
+ShutdownTpmOnReset (
+  IN EFI_RESET_TYPE   ResetType,
+  IN EFI_STATUS   ResetStatus,
+  IN UINTNDataSize,
+  IN VOID *ResetData OPTIONAL
+  )
+{
+  Tpm2Shutdown (TPM_SU_CLEAR);
+}
+
+/**
   The driver's entry point. It publishes EFI Tcg2 Protocol.
 
   @param[in] ImageHandle  The firmware allocated handle for the EFI image.  
@@ -2461,6 +2492,7 @@ DriverEntry (
   EFI_TCG2_EVENT_ALGORITHM_BITMAP   TpmHashAlgorithmBitmap;
   UINT32ActivePCRBanks;
   UINT32NumberOfPCRBanks;
+  EFI_RESET_NOTIFICATION_PROTOCOL   *ResetNotify;
 
   mImageHandle = ImageHandle;
 
@@ -2609,6 +2641,17 @@ DriverEntry (
 // may update SecureBoot value based on last setting.
 //
 EfiCreateProtocolNotifyEvent (&gEfiVariableWriteArchProtocolGuid, 
TPL_CALLBACK, MeasureSecureBootPolicy, NULL, &Registration);
+
+//
+// Hook the system reset to properly shutdown TPM.
+//
+Status = gBS->LocateProtocol (&gEfiResetNotificationProtocolGuid, NULL, 
(VOID **) &ResetNotify);
+if (!EFI_ERROR (Status)) {
+  Status = ResetNotify->RegisterResetNotify (ResetNotify, 
ShutdownTpmOnReset);
+  ASSERT_EFI_ERROR (Status);
+} else {
+  DEBUG ((DEBUG_WARN, "TCG2: ResetNotification absent! Shutdown 
notification cannot be performed!\n"));
+}
   }
 
   //
diff --git a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf 
b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
index 85415e8bc1..59d6dc3dfb 100644
--- a/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
+++ b/SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
@@ -95,6 +95,7 @@ [Protocols]
   gEfiAcpiTableProtocolGuid  ## NOTIFY
   gEfiMpServiceProtocolGuid  ## SOMETIMES_CONSUMES
   gEfiVariableWriteArchProtocolGuid  ## NOTIFY
+  gEfiResetNotificationProtocolGuid  ## CONSUMES
 
 [Pcd]
   gEfiSecurityPkgTokenSpaceGuid.PcdTpmPlatformClass ## 
SOMETIMES_CONSUMES
-- 
2.12.2.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel