>>> On 13.01.16 at 16:54, <david.vra...@citrix.com> wrote: > On 13/01/16 15:49, Roger Pau Monné wrote: >> 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. > > I think Andy's pending cpu feature series will address this.
The blacklisting vs whitelisting part yes, but the pre-population of d->arch.cpuids[] is independent afaict. >> 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. > > I'd favour this approach I think, depending on if any changes were > needed in guests to support this (I assume not?). > > Guests should use PAT instead. +1 Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
