From: Steven Sistare <steven.sistare@oracle.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Jason Zeng" <jason.zeng@linux.intel.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Juan Quintela" <quintela@redhat.com>,
qemu-devel@nongnu.org,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [PATCH V3 11/22] vfio-pci: refactor for cpr
Date: Fri, 21 May 2021 17:18:08 -0400 [thread overview]
Message-ID: <aeb26a90-78eb-3f28-c639-d1cc7edd3974@oracle.com> (raw)
In-Reply-To: <20210521150729.0bb54382.alex.williamson@redhat.com>
On 5/21/2021 5:07 PM, Alex Williamson wrote:
> On Fri, 21 May 2021 09:33:13 -0400
> Steven Sistare <steven.sistare@oracle.com> wrote:
>
>> On 5/19/2021 6:38 PM, Alex Williamson wrote:
>>> On Fri, 7 May 2021 05:25:09 -0700
>>> Steve Sistare <steven.sistare@oracle.com> wrote:
>>>
>>>> Export vfio_address_spaces and vfio_listener_skipped_section.
>>>> Add optional eventfd arg to vfio_add_kvm_msi_virq.
>>>> Refactor vector use into a helper vfio_vector_init.
>>>> All for use by cpr in a subsequent patch. No functional change.
>>>>
>>>> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
>>>> ---
>>>> hw/vfio/common.c | 4 ++--
>>>> hw/vfio/pci.c | 36 +++++++++++++++++++++++++-----------
>>>> include/hw/vfio/vfio-common.h | 3 +++
>>>> 3 files changed, 30 insertions(+), 13 deletions(-)
>>>>
>>>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>>>> index ae5654f..9220e64 100644
>>>> --- a/hw/vfio/common.c
>>>> +++ b/hw/vfio/common.c
>>>> @@ -42,7 +42,7 @@
>>>>
>>>> VFIOGroupList vfio_group_list =
>>>> QLIST_HEAD_INITIALIZER(vfio_group_list);
>>>> -static QLIST_HEAD(, VFIOAddressSpace) vfio_address_spaces =
>>>> +VFIOAddressSpaceList vfio_address_spaces =
>>>> QLIST_HEAD_INITIALIZER(vfio_address_spaces);
>>>>
>>>> #ifdef CONFIG_KVM
>>>> @@ -534,7 +534,7 @@ static int vfio_host_win_del(VFIOContainer *container, hwaddr min_iova,
>>>> return -1;
>>>> }
>>>>
>>>> -static bool vfio_listener_skipped_section(MemoryRegionSection *section)
>>>> +bool vfio_listener_skipped_section(MemoryRegionSection *section)
>>>> {
>>>> return (!memory_region_is_ram(section->mr) &&
>>>> !memory_region_is_iommu(section->mr)) ||
>>>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>>>> index 5c65aa0..7a4fb6c 100644
>>>> --- a/hw/vfio/pci.c
>>>> +++ b/hw/vfio/pci.c
>>>> @@ -411,7 +411,7 @@ static int vfio_enable_vectors(VFIOPCIDevice *vdev, bool msix)
>>>> }
>>>>
>>>> static void vfio_add_kvm_msi_virq(VFIOPCIDevice *vdev, VFIOMSIVector *vector,
>>>> - int vector_n, bool msix)
>>>> + int vector_n, bool msix, int eventfd)
>>>> {
>>>> int virq;
>>>>
>>>> @@ -419,7 +419,9 @@ static void vfio_add_kvm_msi_virq(VFIOPCIDevice *vdev, VFIOMSIVector *vector,
>>>> return;
>>>> }
>>>>
>>>> - if (event_notifier_init(&vector->kvm_interrupt, 0)) {
>>>> + if (eventfd >= 0) {
>>>> + event_notifier_init_fd(&vector->kvm_interrupt, eventfd);
>>>> + } else if (event_notifier_init(&vector->kvm_interrupt, 0)) {
>>>> return;
>>>> }
>>>
>>> This seems very obfuscated. The "active" arg of event_notifier_init()
>>> just seems to preload the eventfd with a signal. What does that have
>>> to do with an eventfd arg to this function? What if the first branch
>>> returns failure?
>>
>> Perhaps you mis-read the code? The function called in the first branch is different than
>> the function called in the second branch. And event_notifier_init_fd is void and never fails.
>>
>> Eschew obfuscation.
>>
>> Gesundheit.
>
> D'oh! I looked at that so many times trying to figure out what I was
> missing and still didn't spot the "_fd" on the first function. The
> fact that @active is an int used as a bool in the non-fd version didn't
> help. Maybe we need our own wrapper just to spread the code out a
> bit...
>
> /* Create new or reuse existing eventfd */
> static int vfio_event_notifier_init(EventNotifier *e, int fd)
> {
> if (fd < 0) {
> return event_notifier_init(e, 0);
> }
>
> event_notifier_init_fd(e, fd);
> return 0;
> }
Will do, for both here and below - Steve
> Or I should just user bigger fonts, but that's somehow more apparent to
> me and can be reused below.
>
>>>> @@ -455,6 +457,22 @@ static void vfio_update_kvm_msi_virq(VFIOMSIVector *vector, MSIMessage msg,
>>>> kvm_irqchip_commit_routes(kvm_state);
>>>> }
>>>>
>>>> +static void vfio_vector_init(VFIOPCIDevice *vdev, int nr, int eventfd)
>>>> +{
>>>> + VFIOMSIVector *vector = &vdev->msi_vectors[nr];
>>>> + PCIDevice *pdev = &vdev->pdev;
>>>> +
>>>> + vector->vdev = vdev;
>>>> + vector->virq = -1;
>>>> + if (eventfd >= 0) {
>>>> + event_notifier_init_fd(&vector->interrupt, eventfd);
>>>> + } else if (event_notifier_init(&vector->interrupt, 0)) {
>>>> + error_report("vfio: Error: event_notifier_init failed");
>>>> + }
>>>
>>> Gak, here's that same pattern.
>>>
>>>> + vector->use = true;
>>>> + msix_vector_use(pdev, nr);
>>>> +}
>>>> +
>>>> static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
>>>> MSIMessage *msg, IOHandler *handler)
>>>> {
>>>> @@ -466,14 +484,10 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
>>>>
>>>> vector = &vdev->msi_vectors[nr];
>>>>
>>>> + vfio_vector_init(vdev, nr, -1);
>>>> +
>>>> if (!vector->use) {
>>>> - vector->vdev = vdev;
>>>> - vector->virq = -1;
>>>> - if (event_notifier_init(&vector->interrupt, 0)) {
>>>> - error_report("vfio: Error: event_notifier_init failed");
>>>> - }
>>>> - vector->use = true;
>>>> - msix_vector_use(pdev, nr);
>>>> + vfio_vector_init(vdev, nr, -1);
>>>> }
>>>
>>> Huh? That's not at all "no functional change". Also the branch is
>>> entirely dead code now.
>>
>> Good catch, thank you. This is a rebase error. The unconditional call to vfio_vector_init
>> should not be there. With that fix, we have:
>>
>> if (!vector->use) {
>> vfio_vector_init(vdev, nr, -1);
>> }
>>
>> and there is no functional change; the actions performed in vfio_vector_init are identical to
>> those deleted here.
>
> Yup.
>
>>>> qemu_set_fd_handler(event_notifier_get_fd(&vector->interrupt),
>>>> @@ -491,7 +505,7 @@ static int vfio_msix_vector_do_use(PCIDevice *pdev, unsigned int nr,
>>>> }
>>>> } else {
>>>> if (msg) {
>>>> - vfio_add_kvm_msi_virq(vdev, vector, nr, true);
>>>> + vfio_add_kvm_msi_virq(vdev, vector, nr, true, -1);
>>>> }
>>>> }
>>>>
>>>> @@ -641,7 +655,7 @@ retry:
>>>> * Attempt to enable route through KVM irqchip,
>>>> * default to userspace handling if unavailable.
>>>> */
>>>> - vfio_add_kvm_msi_virq(vdev, vector, i, false);
>>>> + vfio_add_kvm_msi_virq(vdev, vector, i, false, -1);
>>>> }
>>>
>>> And then we're not really passing an eventfd anyway :-\ I'm so
>>> confused...
>>
>> This patch just adds the eventfd arg. The next few patches pass valid eventfd's from the
>> cpr code paths.
>
> Yeah, I couldn't put the pieces together though after repeatedly
> misreading eventfd being used as a bool in event_notifier_init(), even
> though -1 here should have clued me in too. Thanks,
>
> Alex
>
next prev parent reply other threads:[~2021-05-21 21:19 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 12:24 [PATCH V3 00/22] Live Update Steve Sistare
2021-05-07 12:24 ` [PATCH V3 01/22] as_flat_walk Steve Sistare
2021-05-07 12:25 ` [PATCH V3 02/22] qemu_ram_volatile Steve Sistare
2021-05-07 12:25 ` [PATCH V3 03/22] oslib: qemu_clr_cloexec Steve Sistare
2021-05-07 12:25 ` [PATCH V3 04/22] util: env var helpers Steve Sistare
2021-05-07 12:25 ` [PATCH V3 05/22] machine: memfd-alloc option Steve Sistare
2021-05-07 12:25 ` [PATCH V3 06/22] vl: add helper to request re-exec Steve Sistare
2021-05-07 14:31 ` Eric Blake
2021-05-13 20:19 ` Steven Sistare
2021-05-14 8:18 ` Daniel P. Berrangé
2021-05-12 16:27 ` Stefan Hajnoczi
2021-05-13 20:20 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 07/22] cpr Steve Sistare
2021-05-12 16:19 ` Stefan Hajnoczi
2021-05-13 20:21 ` Steven Sistare
2021-05-14 11:28 ` Stefan Hajnoczi
2021-05-14 15:14 ` Steven Sistare
2021-05-18 13:42 ` Stefan Hajnoczi
2021-05-07 12:25 ` [PATCH V3 08/22] cpr: QMP interfaces Steve Sistare
2021-06-04 13:59 ` Eric Blake
2021-06-07 17:19 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 09/22] cpr: HMP interfaces Steve Sistare
2021-05-07 12:25 ` [PATCH V3 10/22] pci: export functions for cpr Steve Sistare
2021-05-07 12:25 ` [PATCH V3 11/22] vfio-pci: refactor " Steve Sistare
2021-05-19 22:38 ` Alex Williamson
2021-05-21 13:33 ` Steven Sistare
2021-05-21 21:07 ` Alex Williamson
2021-05-21 21:18 ` Steven Sistare [this message]
2021-05-07 12:25 ` [PATCH V3 12/22] vfio-pci: cpr part 1 Steve Sistare
2021-05-21 22:24 ` Alex Williamson
2021-05-24 18:29 ` Steven Sistare
2021-06-11 18:15 ` Steven Sistare
2021-06-11 19:43 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 13/22] vfio-pci: cpr part 2 Steve Sistare
2021-05-21 22:24 ` Alex Williamson
2021-05-24 18:31 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 14/22] vhost: reset vhost devices upon cprsave Steve Sistare
2021-05-07 12:25 ` [PATCH V3 15/22] hostmem-memfd: cpr support Steve Sistare
2021-05-07 12:25 ` [PATCH V3 16/22] chardev: cpr framework Steve Sistare
2021-05-07 14:33 ` Eric Blake
2021-05-13 20:19 ` Steven Sistare
2021-05-07 12:25 ` [PATCH V3 17/22] chardev: cpr for simple devices Steve Sistare
2021-05-07 12:25 ` [PATCH V3 18/22] chardev: cpr for pty Steve Sistare
2021-05-07 12:25 ` [PATCH V3 19/22] chardev: cpr for sockets Steve Sistare
2021-05-07 12:25 ` [PATCH V3 20/22] cpr: only-cpr-capable option Steve Sistare
2021-05-07 12:25 ` [PATCH V3 21/22] cpr: maintainers Steve Sistare
2021-05-07 12:25 ` [PATCH V3 22/22] simplify savevm Steve Sistare
2021-05-07 13:00 ` [PATCH V3 00/22] Live Update no-reply
2021-05-13 20:42 ` Steven Sistare
2021-05-12 16:42 ` Stefan Hajnoczi
2021-05-13 20:21 ` Steven Sistare
2021-05-14 11:53 ` Stefan Hajnoczi
2021-05-14 15:15 ` Steven Sistare
2021-05-17 11:40 ` Stefan Hajnoczi
2021-05-17 19:10 ` Alex Williamson
2021-05-18 13:39 ` Stefan Hajnoczi
2021-05-18 15:48 ` Steven Sistare
2021-05-18 9:57 ` Dr. David Alan Gilbert
2021-05-18 16:00 ` Steven Sistare
2021-05-18 19:23 ` Dr. David Alan Gilbert
2021-05-18 20:01 ` Alex Williamson
2021-05-18 20:14 ` Steven Sistare
2021-05-20 13:00 ` [PATCH V3 00/22] Live Update [reboot] Dr. David Alan Gilbert
2021-05-21 14:55 ` Steven Sistare
2021-06-15 19:14 ` Dr. David Alan Gilbert
2021-06-24 15:05 ` Steven Sistare
2021-07-06 17:31 ` Steven Sistare
2021-05-20 13:13 ` [PATCH V3 00/22] Live Update [restart] Dr. David Alan Gilbert
2021-05-21 14:56 ` Steven Sistare
2021-05-24 10:39 ` Dr. David Alan Gilbert
2021-06-02 13:51 ` Steven Sistare
2021-06-03 19:36 ` Dr. David Alan Gilbert
2021-06-03 20:44 ` Daniel P. Berrangé
2021-06-07 16:40 ` [PATCH V3 00/22] Live Update [restart] : exec Steven Sistare
2021-06-14 14:31 ` Steven Sistare
2021-06-14 14:36 ` Daniel P. Berrangé
2021-06-15 19:05 ` Dr. David Alan Gilbert
2021-06-07 18:08 ` [PATCH V3 00/22] Live Update [restart] : code replication Steven Sistare
2021-06-14 14:33 ` Steven Sistare
2021-05-19 16:43 ` [PATCH V3 00/22] Live Update Steven Sistare
2021-06-02 15:19 ` Steven Sistare
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=aeb26a90-78eb-3f28-c639-d1cc7edd3974@oracle.com \
--to=steven.sistare@oracle.com \
--cc=alex.bennee@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jason.zeng@linux.intel.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.com \
/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).