Re: [Qemu-devel] [PATCH] vhost-user spec: Clarify policy on setting log_base

[Michael S. Tsirkin]

On Tue, Nov 28, 2017 at 12:29:04PM -0500, Victor Kaplansky wrote:
> > From: "Michael S. Tsirkin" <address@hidden>
> > To: "Victor Kaplansky" <address@hidden>
> > Cc: address@hidden, "Maxime Coquelin" <address@hidden>
> > Sent: Tuesday, November 28, 2017 6:16:32 PM
> > Subject: Re: [PATCH] vhost-user spec: Clarify policy on setting log_base
> > 
> > On Tue, Nov 28, 2017 at 03:46:44PM +0200, Victor Kaplansky wrote:
> > > From: Victor Kaplansky <address@hidden>
> > > 
> > > 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.
> 
> > 
> > Do we actually issue VHOST_USER_SET_LOG_BASE when ring is started?
> > 
> > Can we put it simpler:
> > 
> >     master must not send VHOST_USER_SET_LOG_BASE when ring
> >     is started and logging of used ring writes is started.
> > 
> > ?
> 
> I'm OK with this phrasing from DPDK point of view, the problem is
> that right now qemu issues VHOST_USER_SET_LOG_BASE for each queue
> pair, which causes backend to remap logging area, which is very
> prone to race conditions without full fledged lock on log_base variable.
> 
> The several set_log_base requests by qemu are to the same logging area
> with the same size, but a backend cannot know this, since the information is
> passed by fd (file descriptor).
> 
> So, if we use the word *must* it will *require* a change in QEMU, to
> issue single set_log_base for all queue pairs, and not once per queue
> pair, as it is done now.

Oh I was confusing VHOST_USER_SET_LOG_BASE with VHOST_SET_LOG_BASE.

Sorry, pls disregard.




> > 
> > >  Note that when logging modifications to the used ring (when
> > >  VHOST_VRING_F_LOG
> > >  is set for this ring), log_guest_addr should be used to calculate the log
> > >  offset: the write to first byte of the used ring is logged at this offset
> > >  from
> > > --
> > > 2.14.2
> >