From: Laszlo Ersek <lersek@redhat.com>
To: Brijesh Singh <brijesh.singh@amd.com>, edk2-devel@lists.01.org
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
Jordan Justen <jordan.l.justen@intel.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v1 2/4] OvmfPkg: IommuDxe: Provide support for mapping BusMasterCommonBuffer operation
Date: Wed, 2 Aug 2017 10:41:35 +0200 [thread overview]
Message-ID: <b508dcc9-409b-4630-8ba8-cf25cd423279@redhat.com> (raw)
In-Reply-To: <c148fc3a-b4eb-61a8-b926-3fe69b44793d@amd.com>
On 08/02/17 01:51, Brijesh Singh wrote:
> On 8/1/17 4:59 PM, Laszlo Ersek wrote:
>> Please implement the free-list idea that I outlined earlier. Unmap()
>> must not call FreePool() on the MAP_INFO structures.
>
> Sorry it was my bad. I missed implementing that feedback. I will fix it
> in next rev. As you have outlined in previous feedback that Unmap() can
> be called from ExitBootService() hence i will refrain from using
> FreePool() or MemEncryptSev*() functions in this sequence (except when
> freeing the actual bounce buffer).
No, you have to distinguish the C-bit's management and memory releasing.
Unmap must restore the C bit on the bounce buffer, for all of
BusMasterRead, BusMasterWrite, and BusMasterCommonBuffer. This is
required regardless of whether the bounce buffer was allocated
implicitly (for BusMasterRead and BusMasterWrite) or explicitly (for
BusMasterCommonBuffer, in AllocateBuffer()).
Unmap must zero and release the implicitly allocated bounce buffer for
BusMasterRead, BusMasterWrite.
Unmap must neither zero nor release the explicitly allocated buffer for
BusMasterCommonBuffer. For that operation, FreeBuffer() must do both steps.
Unmap must put MAP_INFO back on the internal free list for
BusMasterCommonBuffer. For BusMasterRead and BusMasterWrite, Unmap can
release MAP_INFO with FreePool().
Thanks
Laszlo
next prev parent reply other threads:[~2017-08-02 8:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-31 19:31 [PATCH v1 0/4] OvmfPkg : IoMmuDxe: BusMasterCommonBuffer support when SEV is active Brijesh Singh
2017-07-31 19:31 ` [PATCH v1 1/4] OvmfPkg: IommuDxe: Do not clear C-bit in Allocate() and Free() Brijesh Singh
2017-08-01 20:42 ` Laszlo Ersek
2017-07-31 19:31 ` [PATCH v1 2/4] OvmfPkg: IommuDxe: Provide support for mapping BusMasterCommonBuffer operation Brijesh Singh
2017-07-31 19:49 ` Ard Biesheuvel
2017-07-31 20:27 ` Brijesh Singh
2017-08-01 20:52 ` Laszlo Ersek
2017-08-01 21:59 ` Laszlo Ersek
2017-08-01 23:51 ` Brijesh Singh
2017-08-02 8:41 ` Laszlo Ersek [this message]
2017-07-31 19:31 ` [PATCH v1 3/4] OvmfPkg: IommuDxe: Zero the shared page(s) on Unmap() Brijesh Singh
2017-07-31 19:38 ` Brijesh Singh
2017-08-02 7:37 ` Laszlo Ersek
2017-08-02 11:22 ` Brijesh Singh
2017-08-02 12:52 ` Laszlo Ersek
2017-07-31 19:31 ` [PATCH v1 4/4] OvmfPkg : QemuFwCfgLib: Map DMA buffer with CommonBuffer when SEV is enable Brijesh Singh
2017-08-02 8:09 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b508dcc9-409b-4630-8ba8-cf25cd423279@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox