From: Auger Eric <eric.auger@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [RFC PATCH 2/5] vfio/quirks: Add generic support for ioveventfds
Date: Thu, 8 Feb 2018 21:37:15 +0100 [thread overview]
Message-ID: <346aa0ba-2e2c-f348-82c1-470cc3870ccd@redhat.com> (raw)
In-Reply-To: <20180208113311.337aebc1@w520.home>
Hi Alex,
On 08/02/18 19:33, Alex Williamson wrote:
> On Thu, 8 Feb 2018 12:11:57 +0100
> Auger Eric <eric.auger@redhat.com> wrote:
>
>> Hi Alex,
>>
>> On 07/02/18 01:26, Alex Williamson wrote:
>>> We might wish to handle some quirks via ioeventfds, add a list of
>>> ioeventfds to the quirk.
>> The commit title is a bit misleading as we only add the data type and
>> deletion function.
>
> Unfortunately that's as much as I can add here or else QEMU will fail
> to build because of unused functions :-\ So I pulled as much
> infrastructure as I could here but had to leave some meat for when it
> gets called. Suggestions welcome for title/commit updates.
Understood. Something like "vfio/quirks: Add a VFIOIOEventFD list in
quirks"?
>
>>>
>>> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
>>> ---
>>> hw/vfio/pci-quirks.c | 17 +++++++++++++++++
>>> hw/vfio/pci.h | 11 +++++++++++
>>> 2 files changed, 28 insertions(+)
>>>
>>> diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
>>> index 10af23217292..e4cf4ea2dd9c 100644
>>> --- a/hw/vfio/pci-quirks.c
>>> +++ b/hw/vfio/pci-quirks.c
>>> @@ -12,6 +12,7 @@
>>>
>>> #include "qemu/osdep.h"
>>> #include "qemu/error-report.h"
>>> +#include "qemu/main-loop.h"
>>> #include "qemu/range.h"
>>> #include "qapi/error.h"
>>> #include "qapi/visitor.h"
>>> @@ -278,12 +279,24 @@ static const MemoryRegionOps vfio_ati_3c3_quirk = {
>>> static VFIOQuirk *vfio_quirk_alloc(int nr_mem)
>>> {
>>> VFIOQuirk *quirk = g_malloc0(sizeof(*quirk));
>>> + QLIST_INIT(&quirk->ioeventfds);
>>> quirk->mem = g_new0(MemoryRegion, nr_mem);
>>> quirk->nr_mem = nr_mem;
>>>
>>> return quirk;
>>> }
>>>
>>> +static void vfio_ioeventfd_exit(VFIOIOEventFD *ioeventfd)
>>> +{
>>> + QLIST_REMOVE(ioeventfd, next);
>>> + memory_region_del_eventfd(ioeventfd->mr, ioeventfd->addr, ioeventfd->size,
>>> + ioeventfd->match_data, ioeventfd->data,
>>> + &ioeventfd->e);
>>> + qemu_set_fd_handler(event_notifier_get_fd(&ioeventfd->e), NULL, NULL, NULL);
>>> + event_notifier_cleanup(&ioeventfd->e);
>>> + g_free(ioeventfd);
>>> +}
>>> +
>>> static void vfio_vga_probe_ati_3c3_quirk(VFIOPCIDevice *vdev)
>>> {
>>> VFIOQuirk *quirk;
>>> @@ -1668,6 +1681,10 @@ void vfio_bar_quirk_exit(VFIOPCIDevice *vdev, int nr)
>>> int i;
>>>
>>> QLIST_FOREACH(quirk, &bar->quirks, next) {
>>> + while (!QLIST_EMPTY(&quirk->ioeventfds)) {
>>> + vfio_ioeventfd_exit(QLIST_FIRST(&quirk->ioeventfds));
>>> + }
>>> +
>>> for (i = 0; i < quirk->nr_mem; i++) {
>>> memory_region_del_subregion(bar->region.mem, &quirk->mem[i]);
>>> }
>>> diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
>>> index f4aa13e021fa..146065c2f715 100644
>>> --- a/hw/vfio/pci.h
>>> +++ b/hw/vfio/pci.h
>>> @@ -24,9 +24,20 @@
>>>
>>> struct VFIOPCIDevice;
>>>
>>> +typedef struct VFIOIOEventFD {
>>> + QLIST_ENTRY(VFIOIOEventFD) next;
>>> + MemoryRegion *mr;
>>> + hwaddr addr;
>>> + unsigned size;
>>> + bool match_data;
>> Shouldn't you add the match_data field also in the kernel uapi?
>
> In the vfio uapi? vfio isn't matching anything and has no ability to
> match anything, it's just triggering a pre-programmed write via
> eventfd. Maybe I'm not understanding the comment. Thanks,
Yes that not sensible. We have a KVM ioeventfd that triggers an fd only
if the address/data matches and this VFIO "ioeventfd" listens to this fd
and writes the fixed address/data. At the beginning I was thinking about
having the VFIO handler taking in charge any value written at this
address but there is no way to retrieve the value besides doing a fixed
assignment from userspace. Sorry for the noise.
Thanks
Eric
>
> Alex
>
next prev parent reply other threads:[~2018-02-08 20:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 0:26 [Qemu-devel] [RFC PATCH 0/5] vfio: ioeventfd support Alex Williamson
2018-02-07 0:26 ` [Qemu-devel] [RFC PATCH 1/5] vfio/quirks: Add common quirk alloc helper Alex Williamson
2018-02-08 11:10 ` Auger Eric
2018-02-08 18:28 ` Alex Williamson
2018-02-07 0:26 ` [Qemu-devel] [RFC PATCH 2/5] vfio/quirks: Add generic support for ioveventfds Alex Williamson
2018-02-08 11:11 ` Auger Eric
2018-02-08 18:33 ` Alex Williamson
2018-02-08 20:37 ` Auger Eric [this message]
2018-02-07 0:26 ` [Qemu-devel] [RFC PATCH 3/5] vfio/quirks: Automatic ioeventfd enabling for NVIDIA BAR0 quirks Alex Williamson
2018-02-08 11:10 ` Auger Eric
2018-02-08 11:33 ` Auger Eric
2018-02-08 18:24 ` Alex Williamson
2018-02-08 20:52 ` Auger Eric
2018-02-07 0:26 ` [Qemu-devel] [RFC PATCH 4/5] vfio: Update linux header Alex Williamson
2018-02-07 0:26 ` [Qemu-devel] [RFC PATCH 5/5] vfio/quirks: Enable ioeventfd quirks to be handled by vfio directly Alex Williamson
2018-02-08 11:42 ` Auger Eric
2018-02-08 18:41 ` Alex Williamson
2018-02-09 7:11 ` Peter Xu
2018-02-09 22:09 ` Alex Williamson
2018-02-11 2:38 ` Peter Xu
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=346aa0ba-2e2c-f348-82c1-470cc3870ccd@redhat.com \
--to=eric.auger@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=kvm@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).