linux-kernel - RE: [v3 23/26] KVM: Update Posted-Interrupts Descriptor when vCPU is preempted

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <E959C4978C3B6342920538CF579893F002307C66@SHSMSX104.ccr.corp.intel.com>
Date:	Thu, 18 Dec 2014 03:15:37 +0000
From:	"Wu, Feng" <feng.wu@...el.com>
To:	Paolo Bonzini <pbonzini@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>, Gleb Natapov <gleb@...nel.org>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"joro@...tes.org" <joro@...tes.org>,
	Alex Williamson <alex.williamson@...hat.com>,
	"jiang.liu-VuQAYsv1563Yd54FQh9/CA@...lic.gmane.org" 
	<jiang.liu-VuQAYsv1563Yd54FQh9/CA@...lic.gmane.org>
CC:	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	KVM list <kvm@...r.kernel.org>,
	Eric Auger <eric.auger@...aro.org>,
	"Wu, Feng" <feng.wu@...el.com>
Subject: RE: [v3 23/26] KVM: Update Posted-Interrupts Descriptor when vCPU
 is preempted



> -----Original Message-----
> From: Paolo Bonzini [mailto:paolo.bonzini@...il.com] On Behalf Of Paolo
> Bonzini
> Sent: Thursday, December 18, 2014 1:11 AM
> To: Wu, Feng; Thomas Gleixner; Ingo Molnar; H. Peter Anvin; x86@...nel.org;
> Gleb Natapov; Paolo Bonzini; dwmw2@...radead.org; joro@...tes.org; Alex
> Williamson; jiang.liu-VuQAYsv1563Yd54FQh9/CA@...lic.gmane.org
> Cc: iommu@...ts.linux-foundation.org; linux-kernel@...r.kernel.org; KVM list;
> Eric Auger
> Subject: Re: [v3 23/26] KVM: Update Posted-Interrupts Descriptor when vCPU
> is preempted
> 
> 
> 
> On 12/12/2014 16:14, Feng Wu wrote:
> > +	if (irq_remapping_cap(IRQ_POSTING_CAP)) {
> > +		struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> > +		struct pi_desc old, new;
> > +		unsigned int dest;
> > +
> > +		memset(&old, 0, sizeof(old));
> > +		memset(&new, 0, sizeof(new));
> 
> This is quite expensive.  Just use an u64 for old_control and
> new_control, instead of a full struct.
> 
> >
> > +			pi_clear_sn(&new);
> 
> This can be simply new.sn = 0.  It does not need atomic operations.

Thanks for your comments, Paolo!

If we use u64 new_control, we cannot use new.sn any more.
Maybe we can change the struct pi_desc {} like this:

typedef struct pid_control{
        u64     on      : 1,
        sn      : 1,
        rsvd_1  : 13,
        ndm     : 1,
        nv      : 8,
        rsvd_2  : 8,
        ndst    : 32;
}pid_control_t;

struct pi_desc {
        u32 pir[8];     /* Posted interrupt requested */
		pid_control_t control;
        u32 rsvd[6];
} __aligned(64);


Then we can define pid_control_t new_control, old_control. And use new_control.sn = 0.

What is your opinon?

Thanks,
Feng

> 
> Same in patch 24 (if needed at all there---see the reply there).
> 
> >
> > +	if (irq_remapping_cap(IRQ_POSTING_CAP)) {
> > +		struct pi_desc *pi_desc = vcpu_to_pi_desc(vcpu);
> > +		struct pi_desc old, new;
> > +
> > +		memset(&old, 0, sizeof(old));
> > +		memset(&new, 0, sizeof(new));
> > +
> 
> Here you do not need old/new at all because...
> 
> > +		if (vcpu->preempted) {
> > +			do {
> > +				old.control = new.control = pi_desc->control;
> > +				pi_set_sn(&new);
> > +			} while (cmpxchg(&pi_desc->control, old.control,
> > +					new.control) != old.control);
> 
> this can do pi_set_sn directly on pi_desc, without the cmpxchg.
> 
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/