On Wed, Sep 14, 2016 at 12:28 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote: > On 14/09/2016 20:23, Boris Ostrovsky wrote: >> On 09/14/2016 02:52 PM, Andy Lutomirski wrote: >>> On Tue, Sep 13, 2016 at 11:13 PM, Kyle Huey <me@xxxxxxxxxxxx> wrote: >>>> On Mon, Sep 12, 2016 at 9:56 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>>>> You should explicitly check that, if the >>>>> feature is set under Xen PV, then the MSR actually works as >>>>> advertised. This may require talking to the Xen folks to make sure >>>>> you're testing the right configuration. >>>> This is interesting. When running under Xen PV the kernel is allowed >>>> to read the real value of MSR_PLATFORM_INFO and see that CPUID >>>> faulting is supported. But as you suggested, writing to >>>> MSR_MISC_FEATURES_ENABLES doesn't actually enable CPUID faulting, at >>>> least not in any way that works. >>>> >>>> It's not obvious to me how to test this, because when this feature >>>> works, CPUID only faults in userspace, not in the kernel. Is there >>>> existing code somewhere that runs tests like this in userspace? >>>> >>> Andrew, Boris: should we expect Xen PV to do anything sensible when we >>> write to MSR_PLATFORM_INFO to turn on CPUID faulting? Should the Xen >>> PV rdmsr hooks or perhaps the hypervisor mask out the feature if it >>> isn't going to be supported? >> The hypervisor uses CPUID faulting so we shouldn't advertise this >> feature to guests. > > In the case that the hardware has faulting, or for any HVM guest, the > extra cost to making the feature available to the guest is a single > conditional test in the cpuid path. This is about as close to zero as a > feature gets. We really should be offering the feature to guests, and > have it actually working. The issue here is that it is leaking when we > weren't intending to offer it. As long as Xen can fix this one way or the other in reasonably short order, I think I'm okay with having Linux incorrectly think it works on old Xen hypervisors. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
