Re: [edk2] [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

On 7/28/17 7:52 PM, Brijesh Singh wrote: [snip] > AMD APM document a procedure which must be used to perform in-place > encryption/decryption. We must follow those steps to ensure that data is > flush into memory using the correct C-bit. Not doing so may result in > unpredictable results. > >

Re: [edk2] [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

On 7/28/17 2:59 PM, Laszlo Ersek wrote: > On 07/28/17 18:00, Brijesh Singh wrote: >> On 07/28/2017 08:38 AM, Laszlo Ersek wrote: > snip > >>> (b) Plus, approaching the question from the Map() direction, we need >>> to consider two scenarios: >>> >>> - Client code calls AllocateBuffer(), then

Re: [edk2] [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

On 07/28/17 18:00, Brijesh Singh wrote: > > > On 07/28/2017 08:38 AM, Laszlo Ersek wrote: >> On 07/27/17 21:00, Brijesh Singh wrote: >>> Actually one of main reason why we cleared and restored the memory >>> encryption mask during allocate/free is because we also consume the >>> IOMMU protocol in

Re: [edk2] [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

On 07/28/17 18:00, Brijesh Singh wrote: > > > On 07/28/2017 08:38 AM, Laszlo Ersek wrote: >> On 07/27/17 21:00, Brijesh Singh wrote: >>> I agree with you, there is a bug in AmdSevIoMmu.c. I will fix it. And >>> introduce list to track if the buffer was allocated by us. If buffer >>> was

Re: [edk2] [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

On 07/28/2017 08:38 AM, Laszlo Ersek wrote: On 07/27/17 21:00, Brijesh Singh wrote: On 07/27/2017 12:56 PM, Ard Biesheuvel wrote: On 27 July 2017 at 18:16, Laszlo Ersek wrote: Normally, Map allocates the bounce buffer internally, and Unmap releases the bounce buffer

Re: [edk2] bus number padding [was: MdeModulePkg/PciBus: Avoid hang when BUS pad resource is not in top]

On 07/28/17 12:19, Ni, Ruiyu wrote: > Laszlo, > Thanks for raising this questions. > Please see my embedded reply in below > > Thanks/Ray > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Laszlo Ersek >> Sent: Thursday, July 27, 2017

Re: [edk2] [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

On 07/28/17 10:39, Ard Biesheuvel wrote: > On 27 July 2017 at 23:10, Brijesh Singh wrote: >> >> >> On 07/27/2017 04:31 PM, Ard Biesheuvel wrote: >>> >>> On 27 Jul 2017, at 21:55, Brijesh Singh wrote: On 07/27/2017 02:00 PM,

Re: [edk2] [PATCH v3 1/2] EmbeddedPkg/AndroidBoot: boot android kernel from storage

On Fri, Jul 28, 2017 at 10:18:49PM +0800, Jun Nie wrote: > On 2017年07月28日 21:06, Leif Lindholm wrote: > >On Fri, Jul 28, 2017 at 05:47:46PM +0800, Jun Nie wrote: > >>On 2017年07月27日 22:09, Leif Lindholm wrote: > >>>On Thu, Jul 27, 2017 at 06:07:19PM +0800, Jun Nie wrote: > Add an android kernel

Re: [edk2] [PATCH v3 1/2] EmbeddedPkg/AndroidBoot: boot android kernel from storage

On 2017年07月28日 21:06, Leif Lindholm wrote: On Fri, Jul 28, 2017 at 05:47:46PM +0800, Jun Nie wrote: On 2017年07月27日 22:09, Leif Lindholm wrote: On Thu, Jul 27, 2017 at 06:07:19PM +0800, Jun Nie wrote: Add an android kernel loader that could load kernel from storage device. This patch is from

Re: [edk2] [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

On 07/27/17 21:00, Brijesh Singh wrote: > On 07/27/2017 12:56 PM, Ard Biesheuvel wrote: >> On 27 July 2017 at 18:16, Laszlo Ersek wrote: >>> Normally, Map allocates the bounce buffer internally, and Unmap >>> releases the bounce buffer internally (for BusMasterRead and >>>

Re: [edk2] [PATCH v3 1/2] EmbeddedPkg/AndroidBoot: boot android kernel from storage

On Fri, Jul 28, 2017 at 05:47:46PM +0800, Jun Nie wrote: > On 2017年07月27日 22:09, Leif Lindholm wrote: > >On Thu, Jul 27, 2017 at 06:07:19PM +0800, Jun Nie wrote: > >>Add an android kernel loader that could load kernel from storage > >>device. This patch is from Haojian's code as below link. The

Re: [edk2] bus number padding [was: MdeModulePkg/PciBus: Avoid hang when BUS pad resource is not in top]

Laszlo, Thanks for raising this questions. Please see my embedded reply in below Thanks/Ray > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Laszlo Ersek > Sent: Thursday, July 27, 2017 7:23 PM > To: Ni, Ruiyu ;

Re: [edk2] [PATCH v3 1/2] EmbeddedPkg/AndroidBoot: boot android kernel from storage

On 2017年07月27日 22:09, Leif Lindholm wrote: On Thu, Jul 27, 2017 at 06:07:19PM +0800, Jun Nie wrote: Add an android kernel loader that could load kernel from storage device. This patch is from Haojian's code as below link. The minor change is that alternative dtb is searched in second loader

[edk2] [PATCH 2/2] MdeModulePkg PeiCore: Handle notification PPI from SEC

InstallPpi() will be used for normal PPI in PPI list from SEC, and NotifyPpi() will be used for notification PPI in PPI list from SEC. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng ---

[edk2] [PATCH 0/2] Handle notification PPI from SEC

This patch series is to follow latest (>= 1.5) PI spec to handle notification PPI from SEC. Star Zeng (2): MdePkg PiPeiCis.h: Add description for notification PPI from SEC MdeModulePkg PeiCore: Handle notification PPI from SEC MdeModulePkg/Core/Pei/PeiMain.h | 14

Re: [edk2] [PATCH] ShellPkg: Avoid buffer out-of-bound access

Reviewed-by: Steven Shi Thanks Steven Shi > -Original Message- > From: Ni, Ruiyu > Sent: Wednesday, July 26, 2017 4:22 PM > To: edk2-devel@lists.01.org > Cc: Shi, Steven > Subject: [PATCH] ShellPkg: Avoid buffer out-of-bound access > >

[edk2] [PATCH 1/2] MdePkg PiPeiCis.h: Add description for notification PPI from SEC

This patch is to follow latest (>= 1.5) PI spec to add description for notification PPI from SEC Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng --- MdePkg/Include/Pi/PiPeiCis.h | 17 + 1

Re: [edk2] [RFC v1 0/3] Add VIRTIO_F_IOMMU_PLATFORM support

On 27 July 2017 at 23:10, Brijesh Singh wrote: > > > On 07/27/2017 04:31 PM, Ard Biesheuvel wrote: >> >> >>> On 27 Jul 2017, at 21:55, Brijesh Singh wrote: >>> >>> >>> >>> On 07/27/2017 02:00 PM, Brijesh Singh wrote: >>> >> This distribution of