linux-kernel - Re: [PATCH v3 1/4] KVM: Recover IRTE to remapped mode if the interrupt is not single-destination

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160127150528.GI21252@potion.brq.redhat.com>
Date:	Wed, 27 Jan 2016 16:05:28 +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 1/4] KVM: Recover IRTE to remapped mode if the
 interrupt is not single-destination

2016-01-27 10:07+0800, Yang Zhang:
> On 2016/1/27 2:22, rkrcmar@...hat.com wrote:
>>2016-01-26 09:44+0800, Yang Zhang:
>>>On 2016/1/25 21:59, rkrcmar@...hat.com wrote:
>>>>>>   Also, if wakeup vector were used for wakeup and multicast, we'd be
>>>>>>   uselessly doing work, because we can't tell which reason triggered the
>>>>>>   interrupt before finishing one part -- using separate vectors for that
>>>>>>   would be a bit nicer.
>>>>
>>>>(imprecise -- we would always have to check for ON bit of all PIDs from
>>>>  blocked VCPUs, for the original meaning of wakeup vector, and always
>>>>  either read the PIRR or check for ON bit of all PIDs that encode
>>>>  multicast interrupts;  then we have to clear ON bits for multicasts.)
>>>
>>>Also, most part of work is covered by current logic except checking the
>>>multicast.
>>
>>We could reuse the setup that gets us to wakeup_handler, but there is
>>nothing to share in the handler itself.  Sharing a handler means that we
>>always have to execute both parts.
> 
> I don't quite understand it. There is nothing need to be modified for wakeup
> logic. The only thing we need to do is add the checking before the vcpu pick
> up the pending interrupt(This is happened in VCPU context, not in handler).

I see, there are few problems with that.

>>We must create new PID anyway and compared to the extra work needed for
>>multicast handling, a new vector + handler is a relatively small code
>>investment that adds clarity to the design (and performance).
> 
> No new PID is needed. If the target vcpu is running, no additional work is
> required in wakeup handler. If target vcpu is not running, the current logic
> will wake up the vcpu, then let vcpu itself to check whether pending
> interrupt is a multicast and handle it in vcpu's context.

We do need a new PID.  The existing VCPU PID switches between wakeup
vector and notification vector, so if the VCPU was running when the
device triggered an interrupt, we'd deliver the posted interrupt without
exiting, but we need to handle the interrupt in the host.

=> We need at least one PID that is never set to notification vector.

Reusing VCPU's PIRR is in new PID(s) is not doable.
Parsing PIRR would be our only option of recognizing multicast
interrupts and if the guest configured many sources to send the same
vector, we'd have to do unacceptable things to tell which one was
triggered.

=> We also need at least on one new PIRR.

Handling the interrupt in VCPU context doesn't pose any advantage and we
even want to do it outside, because all VCPUs can be running when the
interrupt arrives and can therefore be posted further.

I hope I covered other disadvantages of PIDs and PIRRs earlier.