Re: [Xen-devel] [RFC] Overriding MSR values via xl.cfg

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.09.14 at 19:37, <eshelton@xxxxxxxxx> wrote:
> Sometimes, it is helpful to persuade a guest OS that it is running on
> a particular CPU model, or that a CPU has (or does not have)
> particular features.  For example, this may ease migrating guests
> across a heterogeneous pool of systems.  Currently, via an xl.cfg file
> you can specify specific masks or values to be returned for the CPUID
> instruction.  This is an example of the syntax being used:
> 
> cpuid = [ '0:eax=0x3,ebx=0x0,ecx=0x0,edx=0x0',
>            '1:eax=0x06b1,
>               ecx=xxxxxxxxxx0000xx00xxx0000000xx0,
>               edx=xx00000xxxxxxx0xxxxxxxxx0xxxxxx',
>            '4:eax=0x3,ebx=0x0,ecx=0x0,edx=0x0',
>   '0x80000000:eax=0x3,ebx=0x0,ecx=0x0,edx=0x0']
> 
> MSRs provide another mechanism for a guest to collect information
> about the system on which it is running.  For much the same reasons it
> can be useful to change CPUID values returned to a guest, it could
> also be useful to be able to override and specify particular MSR
> values to be returned to a guest, and for this to be done via an
> xl.cfg.  This would only affect RDMSR return values, and would not
> affect WRMSR behavior.  The syntax in xl.cfg could be simlar to what
> is used for CPUID.
> 
> Additionally, it seems like this capability would be useful for debug,
> development, and testing of guest operating systems, or the Xen
> hypervisor itself.
> 
> I think the current implementation for the CPUID instruction, both in
> the hypervisor and toolchain, provides a reasonable prototype for
> implementing the above functionality.  However, before I pursue this,
> I wanted to gauge the acceptability of and interest in adding this
> capability to Xen.

While from an abstract perspective this would seem a feature that
could indeed be useful here, I think the resemblance with CPUID
handling is less than what you describe: The value calculation done
in the tool stack, the physical value to merge with (in case of a
partial bit-wise override) is ambiguous: The tool stack (running in
Dom0) can only see whatever it gets to see, which (a) may be
different between PV and PVH Dom0, (b) would likely differ from
what the guest would get to see in the absence of an override,
and (c) might be more heavily dependent on the pCPU it's being
determined on.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel