From: "Michael S. Tsirkin" <mst@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,
borntraeger@de.ibm.com, cohuck@redhat.com, f4bug@amsat.org
Subject: Re: [Qemu-devel] [PATCH V7 3/5] docs: add pvrdma device documentation.
Date: Tue, 16 Jan 2018 04:06:12 +0200 [thread overview]
Message-ID: <20180116040030-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180114090147.39255-4-marcel@redhat.com>
On Sun, Jan 14, 2018 at 11:01:45AM +0200, Marcel Apfelbaum wrote:
> +5. Limitations
> +==============
Limitations are fine but need to cause init failures since users
don't poke in the internal documentation.
> +- 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.
Depends on the size of the region I guess. Did you try this with several
gigabytes of memory? If we are talking seconds of downtime,
it's worth documenting so people aren't surprised.
Alternatively, limit the max size of MR?
> +- The device requires target page size to be the same as the host page size.
Pls add code to fail init when this is not the case.
> +- 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 Guest RAM with MADV_HUGEPAGE so if there are enough huge
> + pages available, QEMU will use them.
Same here.
> +- As previously stated, migration is not supported yet, however with some hardware
> + support can be done.
I don't see a migration blocker.
--
MST
next prev parent reply other threads:[~2018-01-16 2:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-14 9:01 [Qemu-devel] [PATCH V7 0/5] hw/pvrdma: PVRDMA device implementation Marcel Apfelbaum
2018-01-14 9:01 ` [Qemu-devel] [PATCH V7 1/5] pci/shpc: Move function to generic header file Marcel Apfelbaum
2018-01-14 9:01 ` [Qemu-devel] [PATCH V7 2/5] mem: add share parameter to memory-backend-ram Marcel Apfelbaum
2018-01-14 9:01 ` [Qemu-devel] [PATCH V7 3/5] docs: add pvrdma device documentation Marcel Apfelbaum
2018-01-16 2:06 ` Michael S. Tsirkin [this message]
2018-01-17 9:29 ` Marcel Apfelbaum
2018-01-14 9:01 ` [Qemu-devel] [PATCH V7 4/5] pvrdma: initial implementation Marcel Apfelbaum
2018-01-14 9:01 ` [Qemu-devel] [PATCH V7 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=20180116040030-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=ehabkost@redhat.com \
--cc=f4bug@amsat.org \
--cc=imammedo@redhat.com \
--cc=marcel@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.