From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] xen: provide pse36 cpuid bit Date: Thu, 27 Oct 2011 15:59:45 +0100 Message-ID: References: <4EA96B0F.4070607@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4EA96B0F.4070607@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christoph Egger , Tim Deegan Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 27/10/2011 15:30, "Christoph Egger" wrote: > On 10/27/11 16:06, Tim Deegan wrote: >> At 14:10 +0200 on 27 Oct (1319724631), Christoph Egger wrote: >>> >>> Provide pse36 cpuid bit if guest runs in 32bit PAE >>> or in long mode. Hyper-V refuses to start as >>> the "cpu does not provide required hw features" >>> if it does not find the pse36 cpuid bits. >>> >>> Signed-off-by: Christoph Egger >> >> This patch appears to advertise PSE36 support to guests without actually >> supporting PSE36. Or am I missing something? > > That's right. The paging format differs only in 32bit legacy mode. > Since Hyper-V is not running in 32bit legacy mode but insists on having > these cpuid bits present it is sufficient to just populate them to the > guest when guest paging mode != 32bit legacy mode. It would be nice if we didn't have to toggle CPUID.PSE36 based on current guest mode. How hard would it be to pull out bits 35..32 of a physical address from bits 16..13 of a legacy 32-bit PDE whose PS flag = 1? I'm actually surprised we don't do it already, it's so trivial! The code explicitly says we don't though, and for a reason that makes no sense to me... -- Keir > Christoph >