All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Victor Kaplansky <vkaplans@redhat.com>,
	qemu-devel@nongnu.org,
	Maxime Coquelin <maxime.coquelin@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] vhost-user spec: Clarify policy on setting log_base
Date: Tue, 28 Nov 2017 20:17:03 +0200	[thread overview]
Message-ID: <20171128201642-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20171128174316.GB3256@work-vm>

On Tue, Nov 28, 2017 at 05:43:16PM +0000, Dr. David Alan Gilbert wrote:
> * Victor Kaplansky (vkaplans@redhat.com) wrote:
> > > From: "Michael S. Tsirkin" <mst@redhat.com>
> > > To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > > Cc: "Victor Kaplansky" <vkaplans@redhat.com>, qemu-devel@nongnu.org, "Maxime Coquelin" <maxime.coquelin@redhat.com>
> > > Sent: Tuesday, November 28, 2017 6:12:44 PM
> > > Subject: Re: [Qemu-devel] [PATCH] vhost-user spec: Clarify policy on setting log_base
> > > 
> > > On Tue, Nov 28, 2017 at 04:04:21PM +0000, Dr. David Alan Gilbert wrote:
> > > > * Victor Kaplansky (vkaplans@redhat.com) wrote:
> > > > > From: Victor Kaplansky <vkaplans@dell9020.localdomain>
> > > > > 
> > > > > If we allow qemu to change logging area after it was already established,
> > > > > it may require from the backend to acquire a lock on each access to
> > > > > the log_base, which has a potential quite a big performance hit.
> > > > > 
> > > > > Thus we would like to clarify in the spec, that qemu is not expected
> > > > > to resize or remap the logging area, and backend implementations
> > > > > can safely ignore subsequent requests to log_base modifications.
> > > > 
> > > > There's quite a bit of code in vhost to cope with changes in mappings
> > > > of regions; and there's already code in there to handle log size
> > > > changes:
> > > > 
> > > > static inline void vhost_dev_log_resize(struct vhost_dev *dev, uint64_t
> > > > size)
> > > > {
> > > >     struct vhost_log *log = vhost_log_get(size,
> > > >     vhost_dev_log_is_shared(dev));
> > > >     uint64_t log_base = (uintptr_t)log->log;
> > > >     int r;
> > > > 
> > > >     /* inform backend of log switching, this must be done before
> > > >        releasing the current log, to ensure no logging is lost */
> > > >     r = dev->vhost_ops->vhost_set_log_base(dev, log_base, log);
> > > > 
> > > > so when is a log resize legal?
> > > > 
> > > > Dave
> > > 
> > > Log base has nothing to do with log resize.
> > > 
> > > It supplies the physical address of the ring
> > > for dirty logging purposes.
> > > 
> > 
> > Right. Just for complete picture, it also supplies the address for
> > dirty logging of where descriptors can point, in other words for logging
> > whole guest's physical memory. It is why a single log_base is enough for
> > whole device, and there is no need to specify it for every ring separately.
> > 
> > Having said that, there is an obscure possibility to place the ring in
> > a memory different from guest's physical memory, but as far as I know there
> > is no backend that supports this now.
> > 
> > The introduction of this clarification to the vhost-user spec, either with
> > *must* or without it, will enable us to fix in DPDK several BZs open for qemu
> > and related to migration failure of MQ vhost-user.
> 
> OK thanks for the clarification Michael, Victor!
> 
> Dave

Sorry, what I said was completely wrong. Was mixing up vhost and
vhost-user.

> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2017-11-28 18:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-28 13:46 [Qemu-devel] [PATCH] vhost-user spec: Clarify policy on setting log_base Victor Kaplansky
2017-11-28 16:04 ` Dr. David Alan Gilbert
2017-11-28 16:12   ` Michael S. Tsirkin
2017-11-28 17:38     ` Victor Kaplansky
2017-11-28 17:43       ` Dr. David Alan Gilbert
2017-11-28 18:17         ` Michael S. Tsirkin [this message]
2017-11-28 16:16 ` Michael S. Tsirkin
2017-11-28 17:29   ` Victor Kaplansky
2017-11-28 17:57     ` Michael S. Tsirkin
2017-11-28 17:43   ` Victor Kaplansky
2017-11-28 18:06 ` Michael S. Tsirkin
2017-11-28 18:34   ` Victor Kaplansky
2017-11-28 18:45     ` Michael S. Tsirkin
2017-11-28 20:55       ` Victor Kaplansky
2017-11-29  2:08   ` Jason Wang

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=20171128201642-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vkaplans@redhat.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.