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
next prev parent 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: linkBe 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.