From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 8/9] xen/arch/x86: use is_hardware_domain instead of domid == 0 Date: Fri, 12 Apr 2013 16:41:06 +0100 Message-ID: References: <51683B1902000078000CCD0D@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51683B1902000078000CCD0D@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Daniel De Graaf Cc: Ian.Campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 12/04/2013 15:49, "Jan Beulich" wrote: >> My impression was that this would be the hardware domain since it is >> the one that would be parsing ACPI tables and similar things that need >> CPUID to work. The control domain would just be involved in creating >> and managing domains, which doesn't need anything out of CPUID that a >> normal PV domain would need. > > Parsing ACPI tables is unrelated to CPUID, as is most other > hardware management. The only reason I could see to override > this would be to have some domains know the true capabilities of > the processor. And that would be the control domain(s), in order > to be able to sensibly set up CPUID emulation for the guests. Yes, it's subtle but this would break tools/libxc/xc_cpuid_x86.c which expects to see the real CPUID, not the virtualised one. For example, it will look for host 64-bit capabilities this way, which would be hidden in the virtualised CPUID space if the control domain is 32-bit. We could get rid of this not-always-faulting-cpuid hack in the hypervisor altogether, if we could provide a paravirtualised interface that guarantees access to the real CPUID space, for the toolstack to use. But anyhow, the hack is for the toolstack only, and hence is for control_domain only. -- Keir