linux-kernel - Re: [PATCH 2/3] kvm: x86: do not use KVM_REQ

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 28 Sep 2016 16:08:02 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        yang.zhang.wz@...il.com, feng.wu@...el.com, rkrcmar@...hat.com
Subject: Re: [PATCH 2/3] kvm: x86: do not use KVM_REQ_EVENT for APICv
 interrupt injection



On 28/09/2016 15:46, Michael S. Tsirkin wrote:
> On Wed, Sep 28, 2016 at 10:21:41AM +0200, Paolo Bonzini wrote:
>> Basically the order for interrupt injection is:
>>
>> (1)	set PIR
>> 	smp_wmb()
> 
> Empty on x86 btw but good for reasoning about barrier
> pairing. So - where's the paired smp_rmb? See below.
> 
>> (2)	set ON
>> 	smp_mb()
> 
> This one can be combined to smp_store_mb to save
> a couple of cycles.

Yeah, this was very much a pseudo-code view.  In reality it's a
test_and_set_bit().  If ON=1 already there's no need to go on with 3/4.

>> (3)	read vcpu->mode
>> 	if IN_GUEST_MODE
>> (4a)		send posted interrupt IPI
>> 	else
>> (4b)		kick (i.e. cmpxchg vcpu->mode from IN_GUEST_MODE to
>> 		      EXITING_GUEST_MODE and send reschedule IPI)
>>
>> while the order for entering the guest must be the opposite.  The
>> numbers on the left identify the pairing between interrupt injection and
>> vcpu_entr_guest
>>
>> (4a)	enable posted interrupt processing (i.e. disable interrupts!)
>> (3)	set vcpu->mode to IN_GUEST_MODE
>> 	smp_mb()
> 
> This one can be combined to smp_store_mb to save
> a couple of cycles.

Here the actual code has smp_mb__after_srcu_unlock.

>> (2)	read ON
>> 	if ON then
> 
> do we need smp_rmb here?

Yes, we have test_and_clear here which has an implicit barrier.

Paolo

> 
>> (1)		read PIR
>> 		sync PIR to IRR
>> (4b)	read vcpu->mode
>> 	if vcpu->mode == EXITING_GUEST_MODE then
>> 		cancel vmentry
>> (3/2/1)		# posted interrupts are processed on the next vmentry
>>
>> Paolo