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

[Victor Kaplansky]

> 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.

> 
> >  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
>