From: Cornelia Huck <cohuck@redhat.com>
To: Marcel Apfelbaum <marcel@redhat.com>
Cc: qemu-devel@nongnu.org, ehabkost@redhat.com, imammedo@redhat.com,
yuval.shaia@oracle.com, pbonzini@redhat.com, mst@redhat.com,
borntraeger@de.ibm.com
Subject: Re: [Qemu-devel] [PATCH V6 3/5] docs: add pvrdma device documentation.
Date: Tue, 9 Jan 2018 10:17:48 +0100 [thread overview]
Message-ID: <20180109101748.4cfeda03.cohuck@redhat.com> (raw)
In-Reply-To: <20180107123224.100877-4-marcel@redhat.com>
On Sun, 7 Jan 2018 14:32:22 +0200
Marcel Apfelbaum <marcel@redhat.com> wrote:
> Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
> Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com>
> Reviewed-by: Shamir Rabinovitch <shamir.rabinovitch@oracle.com>
> ---
> docs/pvrdma.txt | 254 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 254 insertions(+)
> create mode 100644 docs/pvrdma.txt
> +5. Limitations
> +==============
> +- The device obviously is limited by the Guest Linux Driver features implementation
> + of the VMware device API.
> +- Memory registration mechanism requires mremap for every page in the buffer in order
> + to map it to a contiguous virtual address range. Since this is not the data path
> + it should not matter much.
> +- The device requires target page size to be the same as the host page size.
> +- QEMU cannot map guest RAM from a file descriptor if a pvrdma device is attached,
> + so it can't work with huge pages. The limitation will be addressed in the future,
> + however QEMU allocates Gust RAM with MADV_HUGEPAGE so if there are enough huge
s/Gust/Guest/
> + pages available, QEMU will use them.
> +- As previously stated, migration is not supported yet, however with some hardware
> + support can be done.
next prev parent reply other threads:[~2018-01-09 9:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-07 12:32 [Qemu-devel] [PATCH V6 0/5] hw/pvrdma: PVRDMA device implementation Marcel Apfelbaum
2018-01-07 12:32 ` [Qemu-devel] [PATCH V6 1/5] pci/shpc: Move function to generic header file Marcel Apfelbaum
2018-01-07 13:47 ` Philippe Mathieu-Daudé
2018-01-07 14:35 ` Marcel Apfelbaum
2018-01-07 12:32 ` [Qemu-devel] [PATCH V6 2/5] mem: add share parameter to memory-backend-ram Marcel Apfelbaum
2018-01-08 16:05 ` [Qemu-devel] Getting rid of phys_mem_set_alloc (was: Re: [PATCH V6 2/5] mem: add share parameter to memory-backend-ram) Cornelia Huck
2018-01-08 18:53 ` [Qemu-devel] Getting rid of phys_mem_set_alloc Marcel Apfelbaum
2018-01-07 12:32 ` [Qemu-devel] [PATCH V6 3/5] docs: add pvrdma device documentation Marcel Apfelbaum
2018-01-09 9:17 ` Cornelia Huck [this message]
2018-01-09 10:09 ` Marcel Apfelbaum
2018-01-07 12:32 ` [Qemu-devel] [PATCH V6 4/5] pvrdma: initial implementation Marcel Apfelbaum
2018-01-09 10:39 ` Cornelia Huck
2018-01-09 11:08 ` Yuval Shaia
2018-01-09 12:51 ` Cornelia Huck
2018-01-10 9:28 ` Marcel Apfelbaum
2018-01-10 9:37 ` Cornelia Huck
2018-01-10 9:06 ` Marcel Apfelbaum
2018-01-07 12:32 ` [Qemu-devel] [PATCH V6 5/5] MAINTAINERS: add entry for hw/rdma Marcel Apfelbaum
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-all 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=20180109101748.4cfeda03.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yuval.shaia@oracle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.