All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>,
	qemu-devel@nongnu.org, cohuck@redhat.com, f4bug@amsat.org,
	yuval.shaia@oracle.com, borntraeger@de.ibm.com,
	pbonzini@redhat.com, imammedo@redhat.com
Subject: Re: [Qemu-devel] [PATCH V8 1/4] mem: add share parameter to memory-backend-ram
Date: Thu, 1 Feb 2018 15:36:55 -0200	[thread overview]
Message-ID: <20180201173655.GC26425@localhost.localdomain> (raw)
In-Reply-To: <20180201190902-mutt-send-email-mst@kernel.org>

On Thu, Feb 01, 2018 at 07:12:45PM +0200, Michael S. Tsirkin wrote:
> On Thu, Feb 01, 2018 at 03:01:36PM -0200, Eduardo Habkost wrote:
> > On Thu, Feb 01, 2018 at 06:59:07PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Feb 01, 2018 at 02:57:39PM -0200, Eduardo Habkost wrote:
> > > > On Thu, Feb 01, 2018 at 06:48:54PM +0200, Michael S. Tsirkin wrote:
> > > > > On Thu, Feb 01, 2018 at 02:31:32PM -0200, Eduardo Habkost wrote:
> > > > > > On Thu, Feb 01, 2018 at 04:24:30PM +0200, Michael S. Tsirkin wrote:
> > > > > > [...]
> > > > > > > The full fix would be to allow QEMU to map a list of
> > > > > > > pages to a guest supplied IOVA.
> > > > > > 
> > > > > > Thanks, that's what I expected.
> > > > > > 
> > > > > > While this is not possible, the only requests I have for this
> > > > > > patch is that we clearly document:
> > > > > > * What's the only purpose of share=on on a host-memory-backend
> > > > > >   object (due to pvrdma limitations).
> > > > > > * The potential undesirable side-effects of setting share=on.
> > > > > > * On the commit message and other comments, clearly distinguish
> > > > > >   HVAs in the QEMU address-space from IOVAs, to avoid confusion.
> > > > > 
> > > > > Looking forward, when we do support it, how will management find out
> > > > > it no longer needs to pass the share parameter?
> > > > > 
> > > > > Further, if the side effects of the share parameter go away,
> > > > > how will it know these no longer hold?
> > > > 
> > > > A query-host-capabilities or similar QMP command seems necessary
> > > > for that.
> > > 
> > > Is anyone working on that?
> > 
> > Not yet.
> > 
> > -- 
> > Eduardo
> 
> Do these patches need to wait until we do have that command?

I don't think so.  The command will be needed only when
support for pvrdma without share=on gets implemented.

Right now, all we need is clear documentation.

> 
> I'm thinking it's better to have "share=on required with rdma"
> and "hugetlbfs not supported with rdma"
> than the reverse, this way new hosts do not need to carry
> thus stuff around forever.

What do you mean by "the reverse"?

IIUC, the requirements/limitations are:

* share=on required for pvrdma.  Already documented and enforced
  by pvrdma code in this series.
* hugetlbfs not supported with rdma. Is this detected/reported by
  QEMU?  Is it documented?
* side-effects of share=on.  This is not detected nor documented,
  and probably already applies to other memory backends.
  * Nice to have: document when share=on is useful (answer:
    because of pvrdma), when adding share=on support to
    host-memory-backend.

> 
> Also, how does management know which devices are affected?

Right now?  By reading documentation.

-- 
Eduardo

  reply	other threads:[~2018-02-01 17:37 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17  9:54 [Qemu-devel] [PATCH V8 0/4] hw/pvrdma: PVRDMA device implementation Marcel Apfelbaum
2018-01-17  9:54 ` [Qemu-devel] [PATCH V8 1/4] mem: add share parameter to memory-backend-ram Marcel Apfelbaum
2018-01-31 20:40   ` Eduardo Habkost
2018-01-31 21:10     ` Michael S. Tsirkin
2018-01-31 23:34       ` Eduardo Habkost
2018-02-01  2:22         ` Michael S. Tsirkin
2018-02-01  5:36           ` Marcel Apfelbaum
2018-02-01 12:10             ` Eduardo Habkost
2018-02-01 12:29               ` Marcel Apfelbaum
2018-02-01 13:53                 ` Eduardo Habkost
2018-02-01 18:03                   ` Marcel Apfelbaum
2018-02-01 18:21                     ` Eduardo Habkost
2018-02-01 18:31                       ` Marcel Apfelbaum
2018-02-01 18:51                         ` Eduardo Habkost
2018-02-01 18:58                           ` Marcel Apfelbaum
2018-02-01 19:21                             ` Eduardo Habkost
2018-02-01 19:28                               ` Marcel Apfelbaum
2018-02-01 19:35                               ` Paolo Bonzini
2018-02-01 18:52                         ` Michael S. Tsirkin
2018-02-01 14:24                 ` Michael S. Tsirkin
2018-02-01 16:31                   ` Eduardo Habkost
2018-02-01 16:48                     ` Michael S. Tsirkin
2018-02-01 16:57                       ` Eduardo Habkost
2018-02-01 16:59                         ` Michael S. Tsirkin
2018-02-01 17:01                           ` Eduardo Habkost
2018-02-01 17:12                             ` Michael S. Tsirkin
2018-02-01 17:36                               ` Eduardo Habkost [this message]
2018-02-01 17:58                                 ` Marcel Apfelbaum
2018-02-01 18:18                                   ` Eduardo Habkost
2018-02-01 18:34                                     ` Marcel Apfelbaum
2018-02-01 18:01                                 ` Michael S. Tsirkin
2018-02-01 18:07                   ` Marcel Apfelbaum
2018-02-01 12:57             ` Michael S. Tsirkin
2018-02-01 18:11               ` Marcel Apfelbaum
2018-01-17  9:54 ` [Qemu-devel] [PATCH V8 2/4] docs: add pvrdma device documentation Marcel Apfelbaum
2018-01-17  9:54 ` [Qemu-devel] [PATCH V8 3/4] pvrdma: initial implementation Marcel Apfelbaum
2018-02-01 19:10   ` Michael S. Tsirkin
2018-02-01 19:46     ` Marcel Apfelbaum
2018-01-17  9:54 ` [Qemu-devel] [PATCH V8 4/4] MAINTAINERS: add entry for hw/rdma Marcel Apfelbaum
2018-01-17 10:50 ` [Qemu-devel] [PATCH V8 0/4] hw/pvrdma: PVRDMA device implementation no-reply
2018-01-17 11:22   ` Yuval Shaia

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=20180201173655.GC26425@localhost.localdomain \
    --to=ehabkost@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=f4bug@amsat.org \
    --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.