Re: [PATCH 3/3] kvm-s390: streamline memslot handling

[Avi Kivity <avi@redhat.com>]

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