From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: A couple of HVMlite loose ends Date: Wed, 13 Jan 2016 16:56:01 +0100 Message-ID: <56967391.1080300@suse.com> References: <569671EC.7010101@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aJNmM-0004aV-Ip for xen-devel@lists.xenproject.org; Wed, 13 Jan 2016 15:56:10 +0000 In-Reply-To: <569671EC.7010101@citrix.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: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , xen-devel Cc: Andrew Cooper , Boris Ostrovsky , David Vrabel , Jan Beulich List-Id: xen-devel@lists.xenproject.org On 13/01/16 16:49, Roger Pau Monn=E9 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 is a problem for a HVMlite Dom0, since the code that populates this > array resides in libxc, and when creating a HVMlite Dom0 from Xen itself > (using a properly arranged Dom0 builder) this array doesn't get > populated at all, leading to wrong CPUID information being returned to > the guest. I can see two solutions to this problem: > = > a) Switch CPUID handling for HVMlite Dom0 to the PV one, like it's done > for PVH Dom0. > = > b) Duplicate the code in libxc into the Xen HVMlite Dom0 builder and > populate d->arch.cpuids. Make this "move the code from libxc into xen/common/lib and use the code from libxc and the hypervisor". > I'm leaning towards option "b)", because I would like HVMlite to behave > as a HVM guest as much as possible, but I would like to hear opinions > from others before taking either route. I'd prefer the modified b) version, too. > 2. HVM MTRR and Dom0. > = > MTRR ranges are initialised from hvmloader, which means that although we > expose the MTRR functionality to HVMlite guests (and AFAICT the > functionality is fully complete/usable), the initial state in which a > guest finds the MTRR ranges is not expected, leading to errors. Again, I > see three ways to solve this: > = > a) Mask the MTRR functionality from CPUID for HVMlite guests. This > requires adding a XEN_X86_EMU_MTRR flag to the bitmap introduced in arch > domain. > = > b) Setting up the initial MTRR state from libxl/libxc for HVMlite DomU > and from the Xen domain builder for HVMlite Dom0. This again implies > some functional duplication of MTRR related code, since now we would > have 3 different places where MTRR is setup. One inside hvmloader for > classic HVM guests, another one inside of libxl/libxc for HVMlite DomU > and yet another one in the Dom0 building for HVMlite Dom0. Same as above. > = > c) Be aware of this fact and change the OS code so that it will setup > the initial MTRR ranges correctly. > = > Again, I'm leaning towards "b)", because that's the one that's closest > to native and what we do for classic HVM guests, but would like to hear > opinions. And again as above. :-) Juergen