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

Re: [Xen-devel] How to get a few MSR values from userspace?



On 21/12/12 14:08, Razvan Cojocaru wrote:
I need access to some MSR values that are not currently being saved in
struct hvm_hw_cpu. Among them are MSR_IA32_MC0_CTL, MSR_IA32_MISC_ENABLE
and MSR_IA32_ENERGY_PERF_BIAS.
I can't see why, and this is quite likely related to the reason for
them not being accessible in the first place.
Because they offer heuristic information about the type of OS running in
the domU domain, and there are classes of applications interested in that.
The handling of MC0_CTL for guest is this:
/xen/arch/x86/cpu/mcheck/vmce.c: line 14:
    case MSR_IA32_MC0_CTL:
        /*
         * if guest crazy clear any bit of MCi_CTL,
         * treat it as not implement and ignore write change it.
         */
        break;
That is, whatever the guest writes to MC0 is completely ignored.

So, if you're trying to figure out what guest is running by looking at MC0_CTL, then I guess tough - Xen doesn't store that at all.

Like I said before, MC Interrupt is handled in Xen, and then forwarded to the guest as an IRQ. (Obviously, MCE is generally fatal to the system, so guest isn't at all involved in those).

If you are to save some more Machine Check related information, it probably should go into:
static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
in the same vmce.c file as above (although I'm not 100% sure this is part of "partial" saves).
Currently, this saves MCI_CTL2 register values only.
Not to me, no. These records are use for save/restore/migrate,
and so far there hasn't been a need to include here the MSRs you
mention.
Interesting. I've assumed that those would be saved (and perhaps ignored
on restore if they became irrelevant) in a migration scenario.
I presume guests would just be happy with the defaults Xen provides. Otherwise, we'd have bug reports...

--
Mats
For MSR_IA32_MC0_CTL, why not? These should be fine for
anything that is architectural to x86.

The other two MSRs are Intel specific iirc, and hence wouldn't
be validly dealt with in vendor independent code.
I agree, however, as I've said before, _some_ applications _are_
interested in vendor-specific information for heuristic purposes.

Whether this would make a interesting patch for Xen or not, I would
appreciate any advice on how best to implement said functionality (if
only for MSR_IA32_MC0_CTL).

Thanks,
Razvan Cojocaru

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




_______________________________________________
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®.