Marcelo Tosatti wrote:
True. Anything other potential problem you could think of?
No, so applied the patch. Thanks.
--
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 [EMAIL PROTECTE
27;s a
> different question. isr_ack is not guest visible, so nothing is lost
> from clearing it, but we can fail if we don't clear it.
True. Anything other potential problem you could think of?
KVM: PIC: enhance IPI avoidance
The PIC code makes little effort to avoid kvm_vcpu
Marcelo Tosatti wrote:
and by register load from userspace, no?
Isnt that responsability of the guest?
I'm talking about a restore to previous state scenario. In this case we
want to disable any IPI avoidance in case it avoids a needed IPI.
Unacked IOAPIC interrupts are not
clea
On Wed, Sep 24, 2008 at 03:19:47PM +0300, Avi Kivity wrote:
>> Index: kvm/arch/x86/kvm/irq.h
>> ===
>> --- kvm.orig/arch/x86/kvm/irq.h
>> +++ kvm/arch/x86/kvm/irq.h
>> @@ -42,6 +42,7 @@ struct kvm_kpic_state {
>> u8 irr; /
Marcelo Tosatti wrote:
KVM: PIC: enhance IPI avoidance
The PIC code makes little effort to avoid kvm_vcpu_kick(), resulting in
unnecessary guest exits in some conditions.
For example, if the timer interrupt is routed through the IOAPIC, IRR
for IRQ 0 will get set but not cleared, since the
This patched worked very nicely for me -- about an 8% performance
improvement for my workload.
david
Marcelo Tosatti wrote:
> KVM: PIC: enhance IPI avoidance
>
> The PIC code makes little effort to avoid kvm_vcpu_kick(), resulting in
> unnecessary guest exits in some conditio
KVM: PIC: enhance IPI avoidance
The PIC code makes little effort to avoid kvm_vcpu_kick(), resulting in
unnecessary guest exits in some conditions.
For example, if the timer interrupt is routed through the IOAPIC, IRR
for IRQ 0 will get set but not cleared, since the APIC is handling the
acks
