On 05/16/2010 04:00 AM, Alexander Graf wrote:
On 15.05.2010, at 19:30, Avi Kivity wrote:
On 05/15/2010 11:26 AM, Alexander Graf wrote:
That means you never inject an interrupt from the iothread (or from a different
vcpu thread)?
If that's the case we might make it part of t
On 16.05.2010, at 10:23, Avi Kivity wrote:
> On 05/16/2010 04:00 AM, Alexander Graf wrote:
>> On 15.05.2010, at 19:30, Avi Kivity wrote:
>>
>>
>>> On 05/15/2010 11:26 AM, Alexander Graf wrote:
>>>
> That means you never inject an interrupt from the iothread (or from a
>>
On 05/16/2010 12:01 PM, Alexander Graf wrote:
That's what the world looked like in 2006.
We could change it, but there's not much point, since having the local apic in
the kernel is pretty much a requirement for reasonable performance.
Well, I'm not convinced yet that's the case for PP
On 16.05.2010, at 11:09, Avi Kivity wrote:
> On 05/16/2010 12:01 PM, Alexander Graf wrote:
>>
>>> That's what the world looked like in 2006.
>>>
>>> We could change it, but there's not much point, since having the local apic
>>> in the kernel is pretty much a requirement for reasonable perform
On 05/16/2010 12:35 PM, Alexander Graf wrote:
So let me think this through. With remote interrupt injection we have.
* thread 1 does vcpu_run
* thread 2 triggers KVM_INTERRUPT on fd
* thread 2 signals thread 1 so we're sure the interrupt gets injected
* thread 1 exits into qemu
Thi
On 16.05.2010, at 11:47, Avi Kivity wrote:
> 1: vcpu_run
> 2: KVM_INTERRUPT
> 2k: sets flag, if msr.ee IPIs 1 or wakes up 1 if halted
Doesn't that break when we have a while(1) loop in the guest with msr.ee=0
while no timer is scheduled on the host? But then again with msr.ee=0 we don't
get in
On 05/15/2010 03:03 AM, Marcelo Tosatti wrote:
On Thu, May 13, 2010 at 02:17:35PM +0300, Avi Kivity wrote:
All vcpu ioctls need to be locked, so instead of locking each one specifically
we lock at the generic dispatcher.
This patch only updates generic ioctls and leaves arch specific ioctls
