From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7VFK-00084w-B5 for qemu-devel@nongnu.org; Thu, 17 Nov 2016 17:33:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7VFH-0004Ta-8X for qemu-devel@nongnu.org; Thu, 17 Nov 2016 17:33:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60758) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c7VFH-0004T2-2n for qemu-devel@nongnu.org; Thu, 17 Nov 2016 17:33:27 -0500 Date: Fri, 18 Nov 2016 00:33:24 +0200 From: "Michael S. Tsirkin" Message-ID: <20161118002751-mutt-send-email-mst@kernel.org> References: <20161116180551.9611-1-pbonzini@redhat.com> <20161116180551.9611-3-pbonzini@redhat.com> <20161117195511-mutt-send-email-mst@kernel.org> <28571590.170644.1479412198176.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28571590.170644.1479412198176.JavaMail.zimbra@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/3] virtio: access ISR atomically List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, alex williamson , borntraeger@de.ibm.com, felipe@nutanix.com On Thu, Nov 17, 2016 at 02:49:58PM -0500, Paolo Bonzini wrote: > > > ----- Original Message ----- > > From: "Michael S. Tsirkin" > > To: "Paolo Bonzini" > > Cc: qemu-devel@nongnu.org, "alex williamson" , borntraeger@de.ibm.com, felipe@nutanix.com > > Sent: Thursday, November 17, 2016 6:55:50 PM > > Subject: Re: [PATCH 2/3] virtio: access ISR atomically > > > > On Wed, Nov 16, 2016 at 07:05:50PM +0100, Paolo Bonzini wrote: > > > @@ -1318,10 +1318,18 @@ void virtio_del_queue(VirtIODevice *vdev, int n) > > > vdev->vq[n].vring.num_default = 0; > > > } > > > > > > +static void virtio_set_isr(VirtIODevice *vdev, int value) > > > +{ > > > + uint8_t old = atomic_read(&vdev->isr); > > > + if ((old & value) != value) { > > > + atomic_or(&vdev->isr, value); > > > + } > > > +} > > > + > > > > Paolo, can you pls comment on why is it done like this, > > as opposed to a single atomic_or? > > To avoid cacheline bouncing in the common case where MSI is active > but the host doesn't read ISR. > > Paolo You mean the guest does not read ISR? And so this helps keep the field read-mostly for all CPUs, sharing the cache line. OK but this is worth documenting. -- MST