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 17:14:51 +0000 Message-ID: <5696860B.7060800@citrix.com> References: <569671EC.7010101@citrix.com> <569685BA02000078000C6655@prv-mh.provo.novell.com> <5696789D.3020702@citrix.com> <569688BF02000078000C668B@prv-mh.provo.novell.com> <56967BBF.5000004@citrix.com> <56968366.8020106@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aJP0l-0001Xd-Dy for xen-devel@lists.xenproject.org; Wed, 13 Jan 2016 17:15:07 +0000 In-Reply-To: <56968366.8020106@oracle.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: Boris Ostrovsky , Jan Beulich Cc: xen-devel , David Vrabel , roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On 13/01/16 17:03, Boris Ostrovsky wrote: > On 01/13/2016 11:30 AM, Andrew Cooper wrote: >> On 13/01/16 16:26, Jan Beulich wrote: >>>>>> On 13.01.16 at 17:17, wrote: >>>> 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. >>> In some way it is - there's no need for hiding features from it, since >>> it can't be migrated. >> Thats perfectly fine and normal. The same applies to all other domains >> which wont migrate, or will only migrate to identical hardware. > > We don't use CPUID to only turn on and off features. It also, for > example, describes topology -- something that we may use one day > (possibly for dom0 too). It still doesn't make dom0 special compared to other guests. All guests (should) have accurate topology information represented in cpuid (I will also be fixing this). ~Andrew