Christian Bornträger wrote:
Am Dienstag 26 Mai 2009 09:57:58 schrieb Avi Kivity:
I could add that behaviour, but that could make our normal interrupt
handling much slower. Therefore I don't want to call that function,
but on the other hand I like the "skip if the request is already set"
functionality and think about adding that in my loop.
I don't understand why it would affect your interrupt handling. We need
As far as I understand x86, every host interrupt causes a guest exit.
Yes.
On s390 the SIE instruction is interruptible. On a host interrupt (like an
IPI) the host interrupt handler runs and finally jumps back into the SIE
instruction. The hardware will continue with guest execution. This has the
advantage, that we dont have to load/save guest and host registers on host
interrupts. (the low level interrupt handler saves the registers of the
interrupted context)
Neat stuff. Wish I had something like that.
In our low-level interrupt handler we do check for signal_pending,
machine_check_pending and need_resched to leave the sie instruction. For
anything else a the host sees a cpu bound guest always in the SIE instruction.
Okay, now I understand (and agree with) you multi-level kick thing.
Maybe we could do it like so:
Interrupt handler (on s390 only) checks vcpu->requests, handles the ones
it cans. If bits are still set, it exits to arch loop, which handles
the bits it cans. If bits are still set, it exits to the generic code
loop, which can finally exit to userspace.
Does this fit with s390 hardware?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
