From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: A couple of HVMlite loose ends Date: Wed, 13 Jan 2016 16:17:33 +0000 Message-ID: <5696789D.3020702@citrix.com> References: <569671EC.7010101@citrix.com> <569685BA02000078000C6655@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aJO79-0006YK-Ej for xen-devel@lists.xenproject.org; Wed, 13 Jan 2016 16:17:39 +0000 In-Reply-To: <569685BA02000078000C6655@prv-mh.provo.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 , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Cc: xen-devel , Boris Ostrovsky , David Vrabel List-Id: xen-devel@lists.xenproject.org On 13/01/16 16:13, Jan Beulich wrote: >>>> On 13.01.16 at 16:49, wrote: >> Hello, >> >> While working on a HVMlite Dom0 implementation I've found a couple of >> loose ends with the design that I would like to comment because it's not >> clear to me what's the best direction to take. >> >> 1. HVM CPUID and Dom0. >> >> Sadly the way CPUID is handled inside of Xen varies between PV and HVM. >> On PV guests AFAICT we mostly do black-listing (I think this is the >> right term), which means we pick the native CPUID result and then >> perform a series of filter operations in order to remove features which >> should not be exposed to a PV guest. On the other hand, for HVM guests >> we pre-populate an array (d->arch.cpuids) during domain build time, and >> the contents of that array is what is returned to the guest when a CPUID >> instruction is executed. > This d->arch.cpuids[] mechanism is common to HVM and PV; the > exception really is Dom0. Dom0 is not special when it comes to cpuid, and shouldn't be treated as such. My longter term CPUID plans will be fixing this. ~Andrew