linux-kernel - RE: [PATCH 05/13] KVM: Update IRTE according to guest interrupt configuration changes

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: <E959C4978C3B6342920538CF579893F00227680F@SHSMSX104.ccr.corp.intel.com>
Date:	Wed, 12 Nov 2014 09:19:55 +0000
From:	"Wu, Feng" <feng.wu@...el.com>
To:	Paolo Bonzini <pbonzini@...hat.com>,
	"Zhang, Yang Z" <yang.z.zhang@...el.com>,
	Alex Williamson <alex.williamson@...hat.com>
CC:	"gleb@...nel.org" <gleb@...nel.org>,
	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"joro@...tes.org" <joro@...tes.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 05/13] KVM: Update IRTE according to guest interrupt
 configuration changes



> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@...hat.com]
> Sent: Wednesday, November 12, 2014 5:14 PM
> To: Zhang, Yang Z; Wu, Feng; Alex Williamson
> Cc: gleb@...nel.org; dwmw2@...radead.org; joro@...tes.org;
> tglx@...utronix.de; mingo@...hat.com; hpa@...or.com; x86@...nel.org;
> kvm@...r.kernel.org; iommu@...ts.linux-foundation.org;
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 05/13] KVM: Update IRTE according to guest interrupt
> configuration changes
> 
> 
> 
> On 12/11/2014 04:42, Zhang, Yang Z wrote:
> > Personally, I think this feature will be helpful to the legacy device
> > assignment. Agree, vfio is the right solution for future feature
> > enabling. But the old kvm without the good vfio supporting is still
> > used largely today. The user really looking for this feature but they
> > will not upgrade their kernel. It's easy for us to backport this
> > feature to old kvm with the legacy device assignment, but it is
> > impossible to backport the whole vfio.
> 
> You can certainly backport these patches to distros that do not have
> VFIO.  But upstream we should work on VFIO first.  VFIO has feature
> parity with legacy device assignment, and adding a new feature that is
> not in VFIO would be a bad idea.
> 
> By the way, do you have benchmark results for it?  We have not been able
> to see any performance improvement for APICv on e.g. netperf.

Do you mean benchmark results for APICv itself or VT-d Posted-Interrtups?

Thanks,
Feng

> 
> Paolo