> >
> > Move inside irq_lock protection.
> >
> > >
> > > void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
> > > @@ -270,6 +291,7 @@ void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
> > > hlist_del_init_rcu(&kian->link);
> > > mutex_unlock(&kvm->irq_lock);
> > > synchronize_rcu(
On Thu, Jan 10, 2013 at 07:36:28PM -0200, Marcelo Tosatti wrote:
> Hi,
>
> Getting into good shape.
>
> On Thu, Jan 10, 2013 at 03:26:08PM +0800, Yang Zhang wrote:
> > From: Yang Zhang
> >
> > Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
> > manually, which is fully taken ca
Hi,
Getting into good shape.
On Thu, Jan 10, 2013 at 03:26:08PM +0800, Yang Zhang wrote:
> From: Yang Zhang
>
> Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
> manually, which is fully taken care of by the hardware. This needs
> some special awareness into existing interrupr
Gleb Natapov wrote on 2013-01-10:
> On Thu, Jan 10, 2013 at 03:26:08PM +0800, Yang Zhang wrote:
>> From: Yang Zhang
>>
>> Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
>> manually, which is fully taken care of by the hardware. This needs
>> some special awareness into existing
On Thu, Jan 10, 2013 at 03:26:08PM +0800, Yang Zhang wrote:
> From: Yang Zhang
>
> Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
> manually, which is fully taken care of by the hardware. This needs
> some special awareness into existing interrupr injection path:
>
> - for pend
From: Yang Zhang
Virtual interrupt delivery avoids KVM to inject vAPIC interrupts
manually, which is fully taken care of by the hardware. This needs
some special awareness into existing interrupr injection path:
- for pending interrupt, instead of direct injection, we may need
update architect
