[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160122134911.GC14104@potion.brq.redhat.com>
Date: Fri, 22 Jan 2016 14:49:12 +0100
From: "rkrcmar@...hat.com" <rkrcmar@...hat.com>
To: Yang Zhang <yang.zhang.wz@...il.com>
Cc: "Wu, Feng" <feng.wu@...el.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH v3 2/4] KVM: x86: Use vector-hashing to deliver
lowest-priority interrupts
2016-01-22 12:00+0800, Yang Zhang:
> On 2016/1/22 1:21, rkrcmar@...hat.com wrote:
>>(I think there isn't a practical difference between *r=-1 and *r=0.)
>
> Currently, if *r == -1, the remote_irr may get set. But it seems wrong. I
Yeah ...
> need to have a double check to see whether it is a bug in current code.
Looking forward to the patch!
Thanks.
>>'ret = true' is the better one. We know that the interrupt is not
>>deliverable [1], so there's no point in trying to deliver with the slow
>>path. We behave similarly when the interrupt targets a single disabled
>>APIC.
>>
>>---
>>1: Well ... it's possible that slowpath would deliver it thanks to
>> different handling of disabled APICs, but it's undefined behavior,
>
> why it is undefined behavior? Besides, why we will keep two different
> handling logic for the fast path and slow path? It looks weird.
It does look very weird ... the slow path would require refactoring,
though, so we save effort without a considerable drawback.
(I would love if it behaved identically, but I don't want to force it on
someone and likely won't do it myself ...)
I consider it undefined because SMD says that an OS musn't configure
this behavior and doesn't say what should happen if the OS does => we
could do anything. (Killing the guest would be great for debugging OS
issues, but ours behavior is fairly conservative.)
Powered by blists - more mailing lists