Gregory Haskins wrote:
> Hi All,
> Attached are the first three patches in my queue. The first two you are
> likely familiar with at this point (though I have made some more of the
> requested changes to 02-irqdevice.patch). The last item
> (03-preemptible-cpu.patch) adds an implementation to the previously unused
> kvm_vcpu_intr() callback. This acts as a functional example of the INTR
> callback mechanism as Avi requested. Note that the work related to
> IF/NMI/TPR classification of interrupts happens later in my queue and is not
> mature enough to share yet, but hopefully soon.
>
>
> KVM: Preemptible VCPU
>
> From: <>
>
> This adds support for interrupting an executing CPU
>
> diff --git a/drivers/kvm/condvar.c b/drivers/kvm/condvar.c
> new file mode 100644
> index 0000000..87e464a
> --- /dev/null
> +++ b/drivers/kvm/condvar.c
> @@ -0,0 +1,109 @@
> +/*
> + * Condition Variable
> + *
> + * Copyright (C) 2007, Novell
> + *
> + * Authors:
> + * Gregory Haskins <[EMAIL PROTECTED]>
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2. See
> + * the COPYING file in the top-level directory.
> + *
> + */
>
If you want condition variables, activate your cryogenically-cooled suit
and post on it on lkml. This cannot be added to the kernel via kvm.
> +
> /*
> - * FIXME: Implement this or the CPU wont notice the interrupt until
> - * the next natural VMEXIT. Note that this is how the system
> - * has always worked, so nothing is broken here. This is a future
> - * enhancement
> + * HACK ALERT!
> + *
> + * We want to send a virtual interrupt signal to the task that owns
> + * the guest. However, the signal will only force a VMEXIT (via
> + * a reschedule IPI) if the task is currently in GUEST mode. There
> + * is a race condition between the time that we mark the vcpu as
> + * running and the time the system actually enter guest mode. Since
> + * there doesnt appear to be any way to help with this situation from
> + * the VT hardware, we are forced to wait to make sure the guest
>
We support AMD too.
> + * actually gets interrupted in a reasonable amount of time. If it
> + * does not, we assume that the IPI failed because it was too early
> + * and must try again until it does.
>
Waiting seems totally broken. I'm not even sure what we are waiting for
-- certainly you can't wait for re-entry into guest mode, since there's
not guarantee that's coming. Many times the guest will be sleeping on a
hlt instruction waiting for an interrupt.
If the guest is in guest mode, an IPI is right. If it is elsewhere, we
need to use one of the many (alas) standard wakeup mechanisms to wake up
userspace and let it know the vcpu needs service.
Qemu uses signals, but I think that making the vcpu fd writable is more
generic. For qemu, we can attach a signal to the fd (using fcntl(2));
that has the benefit of leaving the choice of which signal to use to
userspace.
> + *
> + * This condvar/spinlock/timeout/retry eliminate the race in a safe
> + * manner, at the expense of making the INTR delivery synchronous
> */
> + spin_lock(&vcpu->irq.lock);
> +
> + if (vcpu->irq.task) {
> + struct timespec tmo = {
> + .tv_sec = 0,
> + .tv_nsec = 100000 /* 100us */
> + };
> +
> + BUG_ON(vcpu->irq.task == current);
> +
> + while (vcpu->irq.task) {
> + send_sig(SIGSTOP, vcpu->irq.task, 0);
>
SIGSTOP?! I lost the plot here.
--
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
_______________________________________________
kvm-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
