From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: One question on xen_cpuid in pv guest Date: Thu, 30 Jul 2009 10:06:36 -0700 Message-ID: <4A71D31C.7020307@goop.org> References: <4A707EDF.1030104@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Jiang, Yunhong" Cc: "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 07/29/09 22:44, Jiang, Yunhong wrote: > Jeremy, thanks for clarification, but I still not sure about following code in pv_ops dom0. Since the Local APIC is owned by Xen totally, why is it not "outright forbidden for the guest"? > > > if (!xen_initial_domain()) > cpuid_leaf1_edx_mask &= > ~((1 << X86_FEATURE_APIC) | /* disable local APIC */ > (1 << X86_FEATURE_ACPI)); /* disable ACPI */ > Some of the approaches to implementing dom0 pretend the local APIC exists in order to fool various code-paths into doing the right thing (for example, getting the kernel to parse all the MADT tables, which it won't do if there's no local APIC). Historically I think the policy has been for Xen to explicitly blacklist features which turn out to be problematic when they become problematic, rather than whitelist features known to be safe. J