Hello all,
I've some questions regarding iSCSI. Please help me out.
1. If I have added two attempts and are enabled for the same MAC, if the
first attempt fails to connect, will the second attempt be tried?
2. If answer to the above is YES, then what's the difference between
ISCSI
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=681
For string opcode,when checking the valid string length,
it should exclude the Null-terminated character.
And for string in NameValue storage, need to exclude
the varname and also need to convert the Config string
length to Unicode string len
Dandan,
Please add more comments why " / 4" is correct here.
+// e.g Config String: "0041004200430044", Unicode String: "ABCD".
Unicode String length = Config String length / 4.
//
-if (StrSize (StringPtr) > Width) {
+if (StrLen (StringPtr) / 4 >
Reviewed-by: Jordan Justen
On 2017-08-28 08:39:28, Laszlo Ersek wrote:
> There's a small window between
>
> - AllocFwCfgDmaAccessBuffer() mapping the new FW_CFG_DMA_ACCESS object for
> common buffer operation (i.e., decrypting it), and
>
> - InternalQemuFwCfgDmaBytes() setting the fields of t
Hao,
Thanks for helping to fix this issue.
Reviewed-by: Eric Dong
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao Wu
Sent: Tuesday, August 29, 2017 11:09 AM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Dong, Eric
Subject: [edk2] [PATCH] Uefi
Cc: Eric Dong
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu
---
UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/UefiCpuPkg/Library/CpuCommonFeaturesLib/ProcTrace.c
b/UefiCpuPkg/Library/CpuCom
On 08/28/2017 10:23 AM, Andrew Fish wrote:
For X64 (x86-64) systems it is common for PEI to run in 32-bit mode with paging
disabled. This means the DXE Core gets loaded under 4GB and and the HOBs and such are
< 4GB. So having the initial memory map < 4GB helps with preventing
fragmentation.
On 08/28/17 18:23, Andrew Fish wrote:
> For X64 (x86-64) systems it is common for PEI to run in 32-bit mode
> with paging disabled. This means the DXE Core gets loaded under 4GB
> and and the HOBs and such are < 4GB. So having the initial memory map
> < 4GB helps with preventing fragmentation.
Hmm
On 28 August 2017 at 04:27, Gao, Liming wrote:
> Laszlo:
> I will update the patch with your comments.
>
> Ard:
> We collect the size impact in Ovmf platform. Its impact is small. So, my
> patch enable this option for all targets. Below is the data collected on
> OvmfIa32X64.dsc with GCC5 to
For X64 (x86-64) systems it is common for PEI to run in 32-bit mode with paging
disabled. This means the DXE Core gets loaded under 4GB and and the HOBs and
such are < 4GB. So having the initial memory map < 4GB helps with preventing
fragmentation.
There is also architectural cruft on x86. His
OK, got it. Thanks.
For the why the 64bits DXE usually prefer allocations below 4GB, there is a
good white paper elaborate the memory service initialization flows and can
explain the reason. Please see the page 23 in below white paper (I have mark
the answer in red).
https://github.com/tia
On 08/28/17 16:25, Shi, Steven wrote:
> Hi Laszlo,
>
> I happen to have a question about how to correctly get the system memory size
> on Qemu.
>
> In the QemuInitializeRam() of OvmfPkg\PlatformPei\MemDetect.c, I add debug
> info as below to trace the GetSystemMemorySizeBelow4gb() and
> GetSys
Hi Laszlo,
I happen to have a question about how to correctly get the system memory size
on Qemu.
In the QemuInitializeRam() of OvmfPkg\PlatformPei\MemDetect.c, I add debug info
as below to trace the GetSystemMemorySizeBelow4gb() and
GetSystemMemorySizeAbove4gb() output. But the output results
Every virtio GPU command used by VirtioGpuDxe is synchronous and formatted
as a two-descriptor chain: request, response. The internal workhorse
function that all the command-specific functions call for such messaging
is VirtioGpuSendCommand().
In VirtioGpuSendCommand(), map the request from system
Introduce the VirtioGpuAllocateZeroAndMapBackingStore() and
VirtioGpuUnmapAndFreeBackingStore() helper functions. These functions tie
together the allocation, zeroing and mapping, and unmapping and
deallocation, respectively, of memory that the virtio GPU will permanently
reference after receiving
VirtioGpuDxe is now IOMMU-clean; it translates system memory addresses to
bus master device addresses. Negotiate VIRTIO_F_IOMMU_PLATFORM in parallel
with VIRTIO_F_VERSION_1. (Note: the VirtIo GPU device, and this driver,
are virtio-1.0 only (a.k.a. "modern-only").)
Cc: Ard Biesheuvel
Cc: Brijesh
VirtioGpuDxe is a UEFI Bus driver (not a Device driver). This is because a
UEFI graphics driver is expected to produce its GraphicsOutput protocol
instance(s) on new child handle(s) of the video controller handle, one
child handle (plus GOP) per video output (or, one child handle plus GOP
per combi
The RESOURCE_ATTACH_BACKING virtio GPU command assigns guest-side backing
pages to a host-side resource that was created earlier with the
RESOURCE_CREATE_2D command.
We compose the RESOURCE_ATTACH_BACKING command in the
VirtioGpuResourceAttachBacking() function. Currently this function takes
the p
VirtioGpuDxe uses one virtio ring, for VIRTIO_GPU_CONTROL_QUEUE.
Map it for bus master common buffer operation with VirtioRingMap(), so
that it can be accessed equally by both guest and hypervisor even if an
IOMMU is used. (VirtioRingInit() already allocates the ring suitably for
this, see commit
Repo: https://github.com/lersek/edk2.git
Branch: virtio_gpu_map
This series brings IOMMU support to VirtioGpuDxe. The interesting part
is patch#5.
I formatted the patches with function context, for easier review.
I regression-tested this series in various environments; IA32, X64,
AARCH64. My a
There's a small window between
- AllocFwCfgDmaAccessBuffer() mapping the new FW_CFG_DMA_ACCESS object for
common buffer operation (i.e., decrypting it), and
- InternalQemuFwCfgDmaBytes() setting the fields of the object.
In this window, earlier garbage in the object is "leaked" to the
hypervis
This crossed my mind previously in
<1d6bade7-578e-c0e7-5aa6-2ca6af1185e6@redhat.com">http://mid.mail-archive.com/1d6bade7-578e-c0e7-5aa6-2ca6af1185e6@redhat.com>,
point (4), and now I thought I should search for
EdkiiIoMmuOperationBusMasterCommonBuffer too, not just
VirtioOperationBusMasterCommonBu
VirtioScsiDxe driver has been updated to use IOMMU-like member functions
from VIRTIO_DEVICE_PROTOCOL to translate the system physical address to
device address. We do not need to do anything special when
VIRTIO_F_IOMMU_PLATFORM bit is present hence treat it in parallel with
VIRTIO_F_VERSION_1.
Cc:
When device is behind the IOMMU then driver need to pass the device
address when programing the bus master. The patch uses VirtioRingMap() to
map the VRING system physical address to device address.
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Tom Lendacky
Cc: Laszlo Ersek
Contributed-under: Tiano
The patch updates VirtioScsiDxe to use IOMMU-like member functions to map
the system physical address to device address for buffers (including vring,
device specific request and response pointed by vring descriptor, and any
furter memory reference by those request and response).
Cc: Ard Biesheuvel
When device is behind the IOMMU, driver is require to pass the device
address of virtio request, response and any memory referenced by those
request/response to the bus master.
The patch uses IOMMU-like member functions from VIRTIO_DEVICE_PROTOCOL to
map request and response buffers system physica
On 08/28/17 02:34, Brijesh Singh wrote:
> The patch updates the VirtioBlkDxe to use IOMMU-like member functions to map
> the system physical address to device address for buffers (including vring,
> device specific request and response pointed by vring descriptor, and any
> furter memory reference
Hi,
I've been curious about it for a long time, so I guess I might as well
ask the question:
Even if OVMF's DXE phase is built for X64, and even if I give the VM
memory above 4GB -- confirmed by the MEMMAP command in the UEFI shell
--, in the OVMF log I see practically all allocations coming from
Hi,
Is the lower case letters allowed in the string definition ?
STRING_TOKEN (STR_DATA_BITS)
Example if we define like below we are getting build error. Is it expected one ?
STRING_TOKEN (STR_DATA_xBITS)
Thanks,
Ramesh
___
edk2-devel mail
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Zeng, Star
> Sent: Monday, August 28, 2017 9:54 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen ;
> Laszlo Ersek ; Dong, Eric
> Subject: [PATCH] UefiCpuPkg/PiSmmCpuDxeSmm: Centralize
> mPhysicalAddressBits defi
On 08/28/17 02:34, Brijesh Singh wrote:
> When device is behind the IOMMU, driver is require to pass the device
> address of virtio request, response and any memory referenced by those
> request/response to the bus master.
>
> The patch uses IOMMU-like member functions from VIRTIO_DEVICE_PROTOCOL
Reviewed-by: Liming Gao
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Eric
>Dong
>Sent: Monday, August 28, 2017 2:41 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [Patch v2 0/2] Add Management Mode infrastructure support.
>
>In PI spec 1.5,
Reviewed-by: Liming Gao
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Ruiyu Ni
>Sent: Friday, August 25, 2017 4:57 PM
>To: edk2-devel@lists.01.org
>Subject: [edk2] [PATCH v2 0/5] Add multiple PCI segments configuration
>access support
>
>v2:
Reviewed-by: Ruiyu Ni
Thanks/Ray
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Eric Dong
> Sent: Thursday, August 17, 2017 11:44 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 0/2] Add CPUID MCA supports check
>
> This patch s
Reviewed-by: Liming Gao
>-Original Message-
>From: Shi, Steven
>Sent: Wednesday, August 23, 2017 3:01 PM
>To: edk2-devel@lists.01.org; Gao, Liming
>Cc: Zhu, Yonghong ; Shi, Steven
>
>Subject: [PATCH] BaseTools/Conf: Support LLVM39 and LLVM40 in CLANG38
>toolchain
>
>From: "Shi, Steven"
On 08/28/17 03:54, Star Zeng wrote:
> Originally (before 714c2603018a99a514c42c2b511c821f30ba9cdf),
> mPhysicalAddressBits was only defined in X64 PageTbl.c, after
> 714c2603018a99a514c42c2b511c821f30ba9cdf, mPhysicalAddressBits is
> also defined in Ia32 PageTbl.c, then mPhysicalAddressBits is used
36 matches
Mail list logo
