[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] A couple of HVMlite loose ends



>>> On 13.01.16 at 16:54, <david.vrabel@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.