From: Eric Shelton <eshelton@pobox.com>
To: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Jun Nakajima <jun.nakajima@intel.com>,
Eddie Dong <eddie.dong@intel.com>,
Kevin Tian <kevin.tian@intel.com>,
Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>,
Ian Campbell <Ian.Campbell@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: [RFC] Overriding MSR values via xl.cfg
Date: Wed, 17 Sep 2014 13:37:50 -0400 [thread overview]
Message-ID: <CAPQw5rk_u9n3FBrvCtZpETHFr8hSDuwunsMqpAX76oh3KQ3H2w@mail.gmail.com> (raw)
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.
Thanks,
Eric
next reply other threads:[~2014-09-17 17:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-17 17:37 Eric Shelton [this message]
2014-09-18 7:48 ` [RFC] Overriding MSR values via xl.cfg Jan Beulich
2014-09-20 20:39 ` Konrad Rzeszutek Wilk
2014-09-22 9:55 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPQw5rk_u9n3FBrvCtZpETHFr8hSDuwunsMqpAX76oh3KQ3H2w@mail.gmail.com \
--to=eshelton@pobox.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=eddie.dong@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir@xen.org \
--cc=kevin.tian@intel.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).