All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: eric.auger@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2 3/4] vfio/quirks: ioeventfd quirk acceleration
Date: Wed, 2 May 2018 22:20:00 -0600	[thread overview]
Message-ID: <20180502222000.611ddfe4@w520.home> (raw)
In-Reply-To: <20180503033635.GF8239@xz-mi>

On Thu, 3 May 2018 11:36:35 +0800
Peter Xu <peterx@redhat.com> wrote:

> On Tue, May 01, 2018 at 10:43:32AM -0600, Alex Williamson wrote:
> 
> [...]
> 
> > @@ -743,6 +843,60 @@ static void vfio_nvidia_quirk_mirror_write(void *opaque, hwaddr addr,
> >                            addr + mirror->offset, data, size);
> >          trace_vfio_quirk_nvidia_bar0_msi_ack(vdev->vbasedev.name);
> >      }
> > +
> > +    /*
> > +     * Automatically add an ioeventfd to handle any repeated write with the
> > +     * same data and size above the standard PCI config space header.  This is
> > +     * primarily expected to accelerate the MSI-ACK behavior, such as noted
> > +     * above.  Current hardware/drivers should trigger an ioeventfd at config
> > +     * offset 0x704 (region offset 0x88704), with data 0x0, size 4.
> > +     *
> > +     * The criteria of 10 successive hits is arbitrary but reliably adds the
> > +     * MSI-ACK region.  Note that as some writes are bypassed via the ioeventfd,
> > +     * the remaining ones have a greater chance of being seen successively.
> > +     * To avoid the pathological case of burning up all of QEMU's open file
> > +     * handles, arbitrarily limit this algorithm from adding no more than 10
> > +     * ioeventfds, print an error if we would have added an 11th, and then
> > +     * stop counting.
> > +     */
> > +    if (!vdev->no_kvm_ioeventfd &&
> > +        addr > PCI_STD_HEADER_SIZEOF && last->added < MAX_DYN_IOEVENTFD + 1) {
> > +        if (addr != last->addr || data != last->data || size != last->size) {
> > +            last->addr = addr;
> > +            last->data = data;
> > +            last->size = size;
> > +            last->hits = 1;
> > +        } else if (++last->hits >= HITS_FOR_IOEVENTFD) {
> > +            if (last->added < MAX_DYN_IOEVENTFD) {
> > +                VFIOIOEventFD *ioeventfd;
> > +                ioeventfd = vfio_ioeventfd_init(vdev, mirror->mem, addr, size,
> > +                                        data, &vdev->bars[mirror->bar].region,
> > +                                        mirror->offset + addr, true);
> > +                if (ioeventfd) {
> > +                    VFIOQuirk *quirk;
> > +
> > +                    QLIST_FOREACH(quirk,
> > +                                  &vdev->bars[mirror->bar].quirks, next) {  
> 
> I'm not sure whether the quirks list can be a long one, otherwise not
> sure whether we can just cache the quirk pointer inside the mirror to
> avoid the loop.

The list here only has two entries, but it does seem simple enough to
add a VFIOQuirk* to LastData which we set when it's allocated to avoid
this loop.  I'll test and post and update tomorrow.
 
> > +                        if (quirk->data == mirror) {
> > +                            QLIST_INSERT_HEAD(&quirk->ioeventfds,
> > +                                              ioeventfd, next);
> > +                            break;
> > +                        }
> > +                    }  
> 
> [...]
> 
> > +typedef struct VFIOIOEventFD {
> > +    QLIST_ENTRY(VFIOIOEventFD) next;
> > +    MemoryRegion *mr;
> > +    hwaddr addr;
> > +    unsigned size;
> > +    uint64_t data;
> > +    EventNotifier e;
> > +    VFIORegion *region;
> > +    hwaddr region_addr;
> > +    bool match_data;  
> 
> Would it possible in the future that match_data will be false?
> Otherwise I'm not sure whether we can even omit this field.

I don't see how we could, and you're right, it's pretty useless.  I'll
drop it in the next version.  Thanks!

Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, eric.auger@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 3/4] vfio/quirks: ioeventfd quirk acceleration
Date: Wed, 2 May 2018 22:20:00 -0600	[thread overview]
Message-ID: <20180502222000.611ddfe4@w520.home> (raw)
In-Reply-To: <20180503033635.GF8239@xz-mi>

On Thu, 3 May 2018 11:36:35 +0800
Peter Xu <peterx@redhat.com> wrote:

> On Tue, May 01, 2018 at 10:43:32AM -0600, Alex Williamson wrote:
> 
> [...]
> 
> > @@ -743,6 +843,60 @@ static void vfio_nvidia_quirk_mirror_write(void *opaque, hwaddr addr,
> >                            addr + mirror->offset, data, size);
> >          trace_vfio_quirk_nvidia_bar0_msi_ack(vdev->vbasedev.name);
> >      }
> > +
> > +    /*
> > +     * Automatically add an ioeventfd to handle any repeated write with the
> > +     * same data and size above the standard PCI config space header.  This is
> > +     * primarily expected to accelerate the MSI-ACK behavior, such as noted
> > +     * above.  Current hardware/drivers should trigger an ioeventfd at config
> > +     * offset 0x704 (region offset 0x88704), with data 0x0, size 4.
> > +     *
> > +     * The criteria of 10 successive hits is arbitrary but reliably adds the
> > +     * MSI-ACK region.  Note that as some writes are bypassed via the ioeventfd,
> > +     * the remaining ones have a greater chance of being seen successively.
> > +     * To avoid the pathological case of burning up all of QEMU's open file
> > +     * handles, arbitrarily limit this algorithm from adding no more than 10
> > +     * ioeventfds, print an error if we would have added an 11th, and then
> > +     * stop counting.
> > +     */
> > +    if (!vdev->no_kvm_ioeventfd &&
> > +        addr > PCI_STD_HEADER_SIZEOF && last->added < MAX_DYN_IOEVENTFD + 1) {
> > +        if (addr != last->addr || data != last->data || size != last->size) {
> > +            last->addr = addr;
> > +            last->data = data;
> > +            last->size = size;
> > +            last->hits = 1;
> > +        } else if (++last->hits >= HITS_FOR_IOEVENTFD) {
> > +            if (last->added < MAX_DYN_IOEVENTFD) {
> > +                VFIOIOEventFD *ioeventfd;
> > +                ioeventfd = vfio_ioeventfd_init(vdev, mirror->mem, addr, size,
> > +                                        data, &vdev->bars[mirror->bar].region,
> > +                                        mirror->offset + addr, true);
> > +                if (ioeventfd) {
> > +                    VFIOQuirk *quirk;
> > +
> > +                    QLIST_FOREACH(quirk,
> > +                                  &vdev->bars[mirror->bar].quirks, next) {  
> 
> I'm not sure whether the quirks list can be a long one, otherwise not
> sure whether we can just cache the quirk pointer inside the mirror to
> avoid the loop.

The list here only has two entries, but it does seem simple enough to
add a VFIOQuirk* to LastData which we set when it's allocated to avoid
this loop.  I'll test and post and update tomorrow.
 
> > +                        if (quirk->data == mirror) {
> > +                            QLIST_INSERT_HEAD(&quirk->ioeventfds,
> > +                                              ioeventfd, next);
> > +                            break;
> > +                        }
> > +                    }  
> 
> [...]
> 
> > +typedef struct VFIOIOEventFD {
> > +    QLIST_ENTRY(VFIOIOEventFD) next;
> > +    MemoryRegion *mr;
> > +    hwaddr addr;
> > +    unsigned size;
> > +    uint64_t data;
> > +    EventNotifier e;
> > +    VFIORegion *region;
> > +    hwaddr region_addr;
> > +    bool match_data;  
> 
> Would it possible in the future that match_data will be false?
> Otherwise I'm not sure whether we can even omit this field.

I don't see how we could, and you're right, it's pretty useless.  I'll
drop it in the next version.  Thanks!

Alex

  reply	other threads:[~2018-05-03  4:20 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-01 16:42 [PATCH v2 0/4] vfio/quirks: ioeventfd support Alex Williamson
2018-05-01 16:42 ` [Qemu-devel] " Alex Williamson
2018-05-01 16:43 ` [PATCH v2 1/4] vfio/quirks: Add common quirk alloc helper Alex Williamson
2018-05-01 16:43   ` [Qemu-devel] " Alex Williamson
2018-05-01 16:43 ` [PATCH v2 2/4] vfio/quirks: Add quirk reset callback Alex Williamson
2018-05-01 16:43   ` [Qemu-devel] " Alex Williamson
2018-05-01 16:43 ` [PATCH v2 3/4] vfio/quirks: ioeventfd quirk acceleration Alex Williamson
2018-05-01 16:43   ` [Qemu-devel] " Alex Williamson
2018-05-03  3:36   ` Peter Xu
2018-05-03  3:36     ` [Qemu-devel] " Peter Xu
2018-05-03  4:20     ` Alex Williamson [this message]
2018-05-03  4:20       ` Alex Williamson
2018-05-03 14:33   ` Auger Eric
2018-05-03 14:33     ` [Qemu-devel] " Auger Eric
2018-05-03 14:48     ` Alex Williamson
2018-05-03 14:48       ` [Qemu-devel] " Alex Williamson
2018-05-01 16:43 ` [PATCH v2 4/4] vfio/quirks: Enable ioeventfd quirks to be handled by vfio directly Alex Williamson
2018-05-01 16:43   ` [Qemu-devel] " Alex Williamson
2018-05-03  4:56   ` Peter Xu
2018-05-03  4:56     ` [Qemu-devel] " Peter Xu
2018-05-03 16:29     ` Alex Williamson
2018-05-03 16:29       ` [Qemu-devel] " Alex Williamson
2018-05-04  2:16       ` Peter Xu
2018-05-04  2:16         ` [Qemu-devel] " Peter Xu
2018-05-04  7:38       ` Auger Eric
2018-05-04  7:38         ` [Qemu-devel] " Auger Eric
2018-05-03 15:20   ` Auger Eric
2018-05-03 15:20     ` [Qemu-devel] " Auger Eric
2018-05-03 16:30     ` Alex Williamson
2018-05-03 16:30       ` [Qemu-devel] " Alex Williamson
2018-05-01 16:56 ` [PATCH v2 0/4] vfio/quirks: ioeventfd support no-reply
2018-05-01 16:56   ` [Qemu-devel] " no-reply
2018-05-01 17:05   ` Alex Williamson
2018-05-01 17:05     ` [Qemu-devel] " Alex Williamson
2018-05-01 16:56 ` no-reply
2018-05-01 16:56   ` [Qemu-devel] " no-reply

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=20180502222000.611ddfe4@w520.home \
    --to=alex.williamson@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.