linux-kernel - RE: [PATCH v4 1/2] KVM: VMX: Cleanup VMX basic information defines and usages

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: <SA1PR11MB6734D202AAD1F99628466A45A8712@SA1PR11MB6734.namprd11.prod.outlook.com>
Date: Thu, 18 Jan 2024 05:15:11 +0000
From: "Li, Xin3" <xin3.li@...el.com>
To: "Huang, Kai" <kai.huang@...el.com>, "Gao, Chao" <chao.gao@...el.com>
CC: "Yang, Weijiang" <weijiang.yang@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "bp@...en8.de" <bp@...en8.de>,
	"x86@...nel.org" <x86@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "hpa@...or.com" <hpa@...or.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 1/2] KVM: VMX: Cleanup VMX basic information defines
 and usages

> > > > 	 * KVM does not emulate a version of VMX that constrains physical
> > > > 	 * addresses of VMX structures (e.g. VMCS) to 32-bits.
> > > > 	 */
> > > > -	if (data & BIT_ULL(48))
> > > > +	if (data & VMX_BASIC_32BIT_PHYS_ADDR_ONLY)
> > > > 		return -EINVAL;
> > >
> > > Side topic:
> > >
> > > Actually, there is no need to handle bit 48 as a special case. If we
> > > add bit 48 to VMX_BASIC_FEATURES_MASK, the bitwise check will fail if bit 48
> of @data is 1.
> >
> > Good point!  This is also what you suggested above.
> >
> 
> Please try to avoid mixing things together in one patch.  If you want to do above,
> could you please do it in a separate patch so that can be reviewed separately?
> 
> E.g., people who have reviewed or acked this patch may not be interested in the
> new (logically separate) things.

I got to echo what Chao has suggested.

Yeah, if we are going to make this change in this patch set, it has to
be a new patch.  It can also be a separate patch.