From: Paolo Bonzini <pbonzini@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v2 4/5] KVM: add KVM_USER_EXIT vcpu ioctl for userspace exit
Date: Thu, 6 Aug 2015 15:52:03 +0200 [thread overview]
Message-ID: <55C36683.9050703@redhat.com> (raw)
In-Reply-To: <20150806134415.GB31952@potion.brq.redhat.com>
On 06/08/2015 15:44, Radim Krčmář wrote:
>> > Can we just return EINVAL if the parameter is not NULL?
> It complicates handling if we extend the ioctl, but removes the useless
> clearing/copying/checking now ...
Yes.
> The two obvious extensions are flags to skip kvm_make_request() or
> kvm_vcpu_kick(), both of dubious use.
Skipping kvm_make_request() would make some sense if you can set
vcpu->run->request_interrupt_window asynchronously. So you could do
vcpu->run->request_interrupt_window = 1;
ioctl(vcpu_fd, KVM_USER_EXIT, KVM_USER_EXIT_LAZY);
and only cause a lightweight vmexit if the interrupt window is currently
closed. I haven't thought of any races that could happen, but it looks
like it could work.
Skipping kvm_vcpu_kick() makes much less sense.
> Another possibility is setting up
> conditional exits, but that would be better as a separate control, like
> most other sophisticated extensions.
>
> I think that u32 flags would be sufficient -- is casting the 'unsigned
> long arg' (data pointer) to a value still an accepted solution?
Yeah, that would work for me as well. Also because, for now, you'd
return EINVAL if the unsigned long is not zero, which boils down to
"return EINVAL if the parameter is not NULL". :)
Paolo
next prev parent reply other threads:[~2015-08-06 14:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-05 16:32 [PATCH v2 0/5] KVM: optimize userspace exits with a new ioctl Radim Krčmář
2015-08-05 16:32 ` [PATCH v2 1/5] KVM: add kvm_has_request wrapper Radim Krčmář
2015-08-12 19:57 ` Christian Borntraeger
2015-08-13 9:11 ` Radim Krčmář
2015-08-13 9:29 ` Paolo Bonzini
2015-08-13 10:03 ` Christian Borntraeger
2015-08-14 8:42 ` Radim Krčmář
2015-08-05 16:32 ` [PATCH v2 2/5] KVM: add KVM_REQ_EXIT request for userspace exit Radim Krčmář
2015-08-05 16:32 ` [PATCH v2 3/5] KVM: x86: add request_exits debug counter Radim Krčmář
2015-08-05 16:33 ` [PATCH v2 4/5] KVM: add KVM_USER_EXIT vcpu ioctl for userspace exit Radim Krčmář
2015-08-05 16:36 ` Paolo Bonzini
2015-08-06 13:44 ` Radim Krčmář
2015-08-06 13:52 ` Paolo Bonzini [this message]
2015-08-06 17:21 ` Radim Krčmář
2015-08-16 20:27 ` Avi Kivity
2015-08-17 13:15 ` Paolo Bonzini
2015-08-18 18:30 ` Avi Kivity
2015-08-18 19:57 ` Paolo Bonzini
2015-08-19 6:43 ` Avi Kivity
2015-08-05 16:33 ` [PATCH v2 5/5] KVM: refactor asynchronous vcpu ioctl dispatch Radim Krčmář
2015-08-12 20:03 ` Christian Borntraeger
2015-08-13 8:53 ` Radim Krčmář
2015-08-13 9:29 ` Paolo Bonzini
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=55C36683.9050703@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rkrcmar@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).