Re: [kvm-devel] [PATCH 10/13] KVM: Wire up hypercall handlers to a central arch-independent location

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux