All of lore.kernel.org
 help / color / mirror / Atom feed
From: joserz@linux.vnet.ibm.com
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	qemu-devel@nongnu.org, aik@ozlabs.ru, mdroth@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH 0/2] VFIO: Make 8-byte accesses atomic
Date: Tue, 2 May 2017 23:41:01 -0300	[thread overview]
Message-ID: <20170503024101.GA31494@pacoca> (raw)
In-Reply-To: <07d71898-c392-c14a-9901-87ad4287bd5d@redhat.com>

On Fri, Apr 21, 2017 at 12:06:15PM +0200, Paolo Bonzini wrote:
> 
> 
> On 20/04/2017 18:03, Alex Williamson wrote:
> > On Thu, 20 Apr 2017 00:19:23 -0700
> > Richard Henderson <rth@twiddle.net> wrote:
> > 
> >> On 04/19/2017 12:44 PM, Jose Ricardo Ziviani wrote:
> >>> This patchset has two patches:
> >>> [1] 8-byte writes to non-mapped MMIO are broken into pairs of 4-byte writes, this patch makes such pairs atomic.
> >>>
> >>> [2] Enable 8-byte accesses in vfio_region_write and vfio_region_read.
> >>>
> >>> Patches based on master.
> >>>
> >>> Jose Ricardo Ziviani (2):
> >>>   vfio: Set MemoryRegionOps:max_access_size and min_access_size
> >>>   vfio: enable 8-byte reads/writes to vfio
> >>>
> >>>  hw/vfio/common.c | 14 ++++++++++++++
> >>>  1 file changed, 14 insertions(+)
> >>>  
> >>
> >> I think these patches need to be squashed to be bisectable.
> > 
> > No, I think it's fine.  The point of patch 1/2 is to indicate that the
> > hardware supports 8-byte accesses, which will still be broken into 2
> > 4-byte accesses because we don't yet set the implemented width beyond
> > the default.  The important part is that the mutex will now group the 4
> > byte access pair together rather than letting them get re-ordered.
> > Patch 2/2 then implements native 8-byte access.  I appreciate them
> > being separate for this subtle nuance, but maybe I'm not seeing the
> > same issue as you.  Thanks,
> '
> I agree, the patches looks fine as is.
> 
> Paolo
> 

Hello!

Thank you all for your review but I have a quick question: is it ok for
merge? :)

Thanks

  parent reply	other threads:[~2017-05-03  2:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-19 19:44 [Qemu-devel] [PATCH 0/2] VFIO: Make 8-byte accesses atomic Jose Ricardo Ziviani
2017-04-19 19:44 ` [Qemu-devel] [PATCH 1/2] vfio: Set MemoryRegionOps:max_access_size and min_access_size Jose Ricardo Ziviani
2017-04-19 19:44 ` [Qemu-devel] [PATCH 2/2] vfio: enable 8-byte reads/writes to vfio Jose Ricardo Ziviani
2017-04-20  7:19 ` [Qemu-devel] [PATCH 0/2] VFIO: Make 8-byte accesses atomic Richard Henderson
2017-04-20 16:03   ` Alex Williamson
2017-04-21 10:06     ` Paolo Bonzini
2017-04-21 15:51       ` Richard Henderson
2017-05-03  2:41       ` joserz [this message]
2017-05-03  2:52         ` Alex Williamson

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=20170503024101.GA31494@pacoca \
    --to=joserz@linux.vnet.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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.