Carsten Otte wrote:
> Avi Kivity wrote:
>> kvm doesn't do this directly.  A hlt instruction (which is is used on 
>> x86 to signal an idle cpu) is trapped and echoed to userspace, which 
>> then sleeps using select(2).
> I've read that part. I still don't like this approach, it just does'nt 
> fit our signal processor instruction without interresting race 
> conditions.

x86 and s390 don't have to be the same when hardware differences 
warrant.  But see below.

> Our SIGP instruction does provide a condition code on the source cpu 
> which indicates if the interprocessor signal was accepted by the 
> target cpu.
> - When the target CPU is going idle, but has not yet called signal(), 
> how can we figure from kernel space if it has masked this interrupt? 
> We would want to figure that quick to be able to reenter VM context on 
> the initiating CPU asap.

I don't understand the context here.  Why would the target cpu call 
signal()?

> - Also this requires synchronization, our arch requires there may be 
> just one external interrupt pending per target CPU at a given time. 
> How do we synchronize if both user and kernel can inject interrupts?

With the code that's going into kvm now, userspace posts the interrupt 
to the kernel, and the kernel injects it.  So the kernel is the 
synchronization point (x86 has the same constraint).

>
>> We thought of having hlt sleep in the kernel, but that meant that we 
>> would need to specify the exit conditions from sleep (signals, fd 
>> readiness, aio readiness).
> Yes, that is required indeed. I think pending signals should make the
> syscall exit. AIO translates to SIGIO, and file descriptors should be 
> checked by another pthread via poll.
>

Currently qemu multiplexes fd readiness and vcpu execution on the same 
(and only) thread, but it may make sense to have completions reaped by 
an I/O thread, which then dispatches interrupts to the appropriate vcpu, 
if necessary.  That avoids unnecessary exits, especially if we have 
interrupt mitigation and guest smp.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to