> From: "Michael S. Tsirkin" <m...@redhat.com> > To: "Victor Kaplansky" <vkapl...@redhat.com> > Cc: qemu-devel@nongnu.org, "Maxime Coquelin" <maxime.coque...@redhat.com> > 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 <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.
> > 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 >
