[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Jun 2020 20:18:39 -0700
From: Nadav Amit <nadav.amit@...il.com>
To: John Andersen <john.s.andersen@...el.com>
Cc: corbet@....net,
Paolo Bonzini <pbonzini@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
mingo <mingo@...hat.com>,
bp <bp@...en8.de>,
hpa@...or.com,
shuah@...nel.org,
sean.j.christopherson@...el.com,
rick.p.edgecombe@...el.com,
kvm@...r.kernel.org,
kernel-hardening@...ts.openwall.com
Subject: Re: [kvm-unit-tests PATCH] x86: Add control register pinning tests
> On Jun 17, 2020, at 3:52 PM, Nadav Amit <nadav.amit@...il.com> wrote:
>
>> On Jun 17, 2020, at 3:46 PM, John Andersen <john.s.andersen@...el.com> wrote:
>>
>> Paravirutalized control register pinning adds MSRs guests can use to
>> discover which bits in CR0/4 they may pin, and MSRs for activating
>> pinning for any of those bits.
>
> [ sni[
>
>> +static void vmx_cr_pin_test_guest(void)
>> +{
>> + unsigned long i, cr0, cr4;
>> +
>> + /* Step 1. Skip feature detection to skip handling VMX_CPUID */
>> + /* nop */
>
> I do not quite get this comment. Why do you skip checking whether the
> feature is enabled? What happens if KVM/bare-metal/other-hypervisor that
> runs this test does not support this feature?
My bad, I was confused between the nested checks and the non-nested ones.
Nevertheless, can we avoid situations in which
rdmsr(MSR_KVM_CR0_PIN_ALLOWED) causes #GP when the feature is not
implemented? Is there some protocol for detection that this feature is
supported by the hypervisor, or do we need something like rdmsr_safe()?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
