From: Gregory Haskins <ghaskins@novell.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
avi@redhat.com, davidel@xmailserver.org,
paulmck@linux.vnet.ibm.com, markmc@redhat.com,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [KVM PATCH v6 2/2] KVM: add iosignalfd support
Date: Mon, 15 Jun 2009 00:25:37 -0400 [thread overview]
Message-ID: <4A35CD41.20206@novell.com> (raw)
In-Reply-To: <20090613043951.GA3083@amt.cnet>
[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]
Hi Marcelo,
Marcelo Tosatti wrote:
> On Fri, Jun 05, 2009 at 12:02:02PM -0400, Gregory Haskins wrote:
>
>> Hi Marcelo!
>>
>> Comments about the shutdown path ambiguity are in-line
>>
>> Gregory Haskins wrote:
>>
>>> iosignalfd is a mechanism to register PIO/MMIO regions to trigger an eventfd
>>> signal when written to by a guest. Host userspace can register any arbitrary
>>> IO address with a corresponding eventfd and then pass the eventfd to a
>>> + list_del(&item->list);
>>> + iosignalfd_item_free(item);
>>> + }
>>> +
>>> + list_del(&group->list);
>>> + kfree(group);
>>> +}
>>>
>>>
>> So this function is called by the path that executes as we do the last
>> kvm_put_kvm(). I do not do any careful RCU wrangling here because I
>> assume that there cannot possibly be any active MMIO/PIO operations at
>> this time, or the reference would never have dropped. Let me know if
>> anyone sees any holes in that.
>>
>> An alternative approach is to do this similar to how irqfd_release()
>> works. That is: invoke it from the vmfd release() path instead of the
>> the kvm object destructor. I currently do not think this is necessary,
>> but I will throw that out there in case someone likes it better.
>>
>
> Gregory,
>
> Can't see any problems with it.
Thanks for the review!
> You might want an upper limit
> in the number of items per group.
>
Yeah, I agree that is a good idea. Will fix in v7.
BTW: Did your series get merged while I was away?
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]
prev parent reply other threads:[~2009-06-15 4:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 15:54 [KVM PATCH v6 0/2] iosignalfd Gregory Haskins
2009-06-05 15:55 ` [KVM PATCH v6 1/2] KVM: make io_bus interface more robust Gregory Haskins
2009-06-05 15:55 ` [KVM PATCH v6 2/2] KVM: add iosignalfd support Gregory Haskins
2009-06-05 16:02 ` Gregory Haskins
2009-06-13 4:39 ` Marcelo Tosatti
2009-06-15 4:25 ` Gregory Haskins [this message]
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=4A35CD41.20206@novell.com \
--to=ghaskins@novell.com \
--cc=avi@redhat.com \
--cc=davidel@xmailserver.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markmc@redhat.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=paulmck@linux.vnet.ibm.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 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.