From: Avi Kivity <avi@qumranet.com> To: Arjan van de Ven <arjan@infradead.org> Cc: Dor Laor <dor.laor@qumranet.com>, Pavel Machek <pavel@ucw.cz>, kvm-devel@lists.sourceforge.net, akpm@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [kvm-devel] [PATCH 10/13] KVM: Wire up hypercall handlers to a central arch-independent location Date: Thu, 22 Feb 2007 15:04:19 +0200 [thread overview] Message-ID: <45DD94D3.4030102@qumranet.com> (raw) In-Reply-To: <1172142081.3531.243.camel@laptopd505.fenrus.org> Arjan van de Ven wrote: > - execution of hypercall handlers outside vcpu_load() (so they are > > preemptible and sleepable) > > > I don't need this; most of my hypercalls are non-blocking. The ones that > are can already undo the load themselves, no big deal. > I don't really like exposing the vcpu_load()/vcpu_put() interfaces. On the other hand, sleeping in a hypercall means the guest vcpu is not doing any processing. Maybe we should declare hypercall handlers atomic and let them use a workqueue if they can't be atomic. On the third hand, sleeping in a hypercall should be a rare event, so forcing hypercall handlers to handle the sleeping case introduces a lot of complexity for marginal gain. >> - passing unhandled hypercalls to userspace for qemu-based devices >> > > hm could do I suppose > One user would be the opengl guest to host tunneling driver/device that's being developed for qemu. > One thing I'd like to see is some way to do batched hypercalls. I don't > quite know how this will work in general, but let me explain the > scenario: > The guest submits a bunch of disk IO requests into a submit queue. > The host gets a hypercall and goes to process the submit queue > While this is processing, the guest submits more IO > The guest would here do another hypercall.. > > .. but what could be done is have the host poll at the end of it's scan > of the queue if there's more, and while the host is scanning, just > disable the hypercall the guest would make. So that if there is a > "submit while scanning/processing" going on, no need for more > hypercalls. > Xen does exactly that. It's actually outside the scope of hypercalls, and more related to the protocol between guest and host. Not that it can't be made generic (and the Xen rings are). Maybe we should just copy the code. > (Otoh... the current situation isn't all that bad, there's one hypercall > for an entire batch of IO's, and the blocklayer isn't all that bad at > giving us nice large batches) > True. I expect it's more necessary with networking. Somthing else that came up in a conversation with Dor: the need for a clean way to raise a guest interrupt. The guest may be sleeping in userspace, scheduled out, or running on another cpu (and requiring an ipi to get it out of guest mode). Right now I'm thinking about using the signal machinery since it appears to do exactly the right thing. -- error compiling committee.c: too many arguments to function
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> To: Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, akpm-3NddpPZAyC0@public.gmane.org, Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH 10/13] KVM: Wire up hypercall handlers to a central arch-independent location Date: Thu, 22 Feb 2007 15:04:19 +0200 [thread overview] Message-ID: <45DD94D3.4030102@qumranet.com> (raw) In-Reply-To: <1172142081.3531.243.camel-NIQFrBLA1CpScpXdPBN83iCwEArCW2h5@public.gmane.org> Arjan van de Ven wrote: > - execution of hypercall handlers outside vcpu_load() (so they are > > preemptible and sleepable) > > > I don't need this; most of my hypercalls are non-blocking. The ones that > are can already undo the load themselves, no big deal. > I don't really like exposing the vcpu_load()/vcpu_put() interfaces. On the other hand, sleeping in a hypercall means the guest vcpu is not doing any processing. Maybe we should declare hypercall handlers atomic and let them use a workqueue if they can't be atomic. On the third hand, sleeping in a hypercall should be a rare event, so forcing hypercall handlers to handle the sleeping case introduces a lot of complexity for marginal gain. >> - passing unhandled hypercalls to userspace for qemu-based devices >> > > hm could do I suppose > One user would be the opengl guest to host tunneling driver/device that's being developed for qemu. > One thing I'd like to see is some way to do batched hypercalls. I don't > quite know how this will work in general, but let me explain the > scenario: > The guest submits a bunch of disk IO requests into a submit queue. > The host gets a hypercall and goes to process the submit queue > While this is processing, the guest submits more IO > The guest would here do another hypercall.. > > .. but what could be done is have the host poll at the end of it's scan > of the queue if there's more, and while the host is scanning, just > disable the hypercall the guest would make. So that if there is a > "submit while scanning/processing" going on, no need for more > hypercalls. > Xen does exactly that. It's actually outside the scope of hypercalls, and more related to the protocol between guest and host. Not that it can't be made generic (and the Xen rings are). Maybe we should just copy the code. > (Otoh... the current situation isn't all that bad, there's one hypercall > for an entire batch of IO's, and the blocklayer isn't all that bad at > giving us nice large batches) > True. I expect it's more necessary with networking. Somthing else that came up in a conversation with Dor: the need for a clean way to raise a guest interrupt. The guest may be sleeping in userspace, scheduled out, or running on another cpu (and requiring an ipi to get it out of guest mode). Right now I'm thinking about using the signal machinery since it appears to do exactly the right thing. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
next prev parent reply other threads:[~2007-02-22 13:05 UTC|newest] Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-19 10:20 [PATCH 0/13] kvm updates for 2.6.21 Avi Kivity 2007-02-19 10:20 ` Avi Kivity 2007-02-19 10:21 ` [PATCH 1/13] KVM: mmu: add missing dirty page tracking cases Avi Kivity 2007-02-19 10:21 ` Avi Kivity 2007-02-19 10:22 ` [PATCH 2/13] KVM: Move virtualization deactivation from CPU_DEAD state to CPU_DOWN_PREPARE Avi Kivity 2007-02-19 10:22 ` Avi Kivity 2007-02-19 10:23 ` [PATCH 3/13] KVM: Cosmetics Avi Kivity 2007-02-19 10:23 ` Avi Kivity 2007-02-19 10:24 ` [PATCH 4/13] KVM: vmx: hack set_cr0_no_modeswitch() to actually do modeswitch Avi Kivity 2007-02-19 10:24 ` Avi Kivity 2007-02-19 10:25 ` [PATCH 5/13] KVM: Use ARRAY_SIZE macro instead of manual calculation Avi Kivity 2007-02-19 10:25 ` Avi Kivity 2007-02-19 10:26 ` [PATCH 6/13] KVM: Use page_private()/set_page_private() apis Avi Kivity 2007-02-19 10:26 ` Avi Kivity 2007-02-19 10:27 ` [PATCH 7/13] KVM: add MSR based hypercall API Avi Kivity 2007-02-19 10:27 ` Avi Kivity 2007-02-19 10:28 ` [PATCH 8/13] KVM: Add host hypercall support for vmx Avi Kivity 2007-02-19 10:28 ` Avi Kivity 2007-02-19 10:29 ` [PATCH 9/13] KVM: Add hypercall host support for svm Avi Kivity 2007-02-19 10:29 ` Avi Kivity 2007-02-19 10:30 ` [PATCH 10/13] KVM: Wire up hypercall handlers to a central arch-independent location Avi Kivity 2007-02-19 10:30 ` Avi Kivity 2007-02-21 10:37 ` Pavel Machek 2007-02-21 10:37 ` Pavel Machek 2007-02-22 10:14 ` Avi Kivity 2007-02-22 10:14 ` Avi Kivity 2007-02-22 10:17 ` [kvm-devel] " Dor Laor 2007-02-22 10:17 ` Dor Laor 2007-02-22 10:22 ` [kvm-devel] " Joerg Roedel 2007-02-22 10:22 ` Joerg Roedel 2007-02-22 10:37 ` [kvm-devel] " Avi Kivity 2007-02-22 10:37 ` Avi Kivity 2007-02-22 10:34 ` [kvm-devel] " Arjan van de Ven 2007-02-22 10:34 ` Arjan van de Ven 2007-02-22 10:40 ` [kvm-devel] " Avi Kivity 2007-02-22 10:40 ` Avi Kivity 2007-02-22 11:01 ` [kvm-devel] " Arjan van de Ven 2007-02-22 11:01 ` Arjan van de Ven 2007-02-22 13:04 ` Avi Kivity [this message] 2007-02-22 13:04 ` Avi Kivity 2007-02-22 13:12 ` [kvm-devel] " Arjan van de Ven 2007-02-22 13:29 ` Avi Kivity 2007-02-22 13:29 ` Avi Kivity 2007-02-22 14:09 ` [kvm-devel] " Arjan van de Ven 2007-02-22 14:09 ` Arjan van de Ven 2007-02-22 14:20 ` [kvm-devel] " Avi Kivity 2007-02-22 14:20 ` Avi Kivity 2007-02-23 14:55 ` [kvm-devel] " Anthony Liguori 2007-02-23 14:55 ` Anthony Liguori 2007-02-22 13:31 ` [kvm-devel] [PATCH 10/13] KVM: Wire up hypercall handlers toa " Dor Laor 2007-02-22 13:31 ` Dor Laor [not found] ` <1172142081.3531.243.camel-NIQFrBLA1CpScpXdPBN83iCwEArCW2h5@public.gmane.org> 2007-02-23 21:14 ` Booting from PV disk driver (Was: Re: [PATCH 10/13] KVM: Wire up hypercall handler ..) Anthony Liguori [not found] ` <45DF5943.3090304-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> 2007-02-23 22:33 ` Arjan van de Ven [not found] ` <1172269981.3241.57.camel-NIQFrBLA1CpScpXdPBN83iCwEArCW2h5@public.gmane.org> 2007-02-24 22:35 ` Booting from PV disk driver (Was: Re: [PATCH 10/13]KVM: " Dor Laor [not found] ` <64F9B87B6B770947A9F8391472E032160A91C385-yEcIvxbTEBqsx+V+t5oei8rau4O3wl8o3fe8/T/H7NteoWH0uzbU5w@public.gmane.org> 2007-02-25 5:20 ` Avi Kivity [not found] ` <45E11C8A.9070006-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 2007-02-25 5:48 ` Avi Kivity 2007-02-25 5:17 ` Booting from PV disk driver (Was: Re: [PATCH 10/13] KVM: " Avi Kivity [not found] ` <45E11C00.2000602-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 2007-02-25 6:31 ` Arjan van de Ven [not found] ` <1172385067.3265.1.camel-NIQFrBLA1CpScpXdPBN83iCwEArCW2h5@public.gmane.org> 2007-02-25 6:34 ` Avi Kivity [not found] ` <45E12E08.8040402-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 2007-02-25 6:42 ` Arjan van de Ven [not found] ` <1172385720.3265.12.camel-NIQFrBLA1CpScpXdPBN83iCwEArCW2h5@public.gmane.org> 2007-02-25 6:52 ` Avi Kivity [not found] ` <45E13213.5070502-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 2007-02-25 6:56 ` Arjan van de Ven 2007-02-19 10:31 ` [PATCH 11/13] KVM: svm: init cr0 with the wp bit set Avi Kivity 2007-02-19 10:31 ` Avi Kivity 2007-02-19 10:32 ` [PATCH 12/13] KVM: SVM: intercept SMI to handle it at host level Avi Kivity 2007-02-19 10:33 ` [PATCH 13/13] KVM: More 0 -> NULL conversions Avi Kivity 2007-02-19 10:33 ` Avi Kivity
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=45DD94D3.4030102@qumranet.com \ --to=avi@qumranet.com \ --cc=akpm@osdl.org \ --cc=arjan@infradead.org \ --cc=dor.laor@qumranet.com \ --cc=kvm-devel@lists.sourceforge.net \ --cc=linux-kernel@vger.kernel.org \ --cc=pavel@ucw.cz \ /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.