From: Jan Kiszka <jan.kiszka@web.de>
To: Arthur Chunqi Li <yzt356@gmail.com>
Cc: kvm <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 4/4] kvm-unit-tests: VMX: Add test cases for instruction interception
Date: Thu, 15 Aug 2013 10:20:18 +0200 [thread overview]
Message-ID: <520C8F42.2010101@web.de> (raw)
In-Reply-To: <CABpY8MKw_aRpvvLH3C_MaGXbb52qpgiFjp3hg0dsXJzBd0n+QQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7750 bytes --]
On 2013-08-15 10:16, Arthur Chunqi Li wrote:
> On Thu, Aug 15, 2013 at 4:06 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2013-08-13 17:56, Arthur Chunqi Li wrote:
>>> Add test cases for instruction interception, including three types:
>>> 1. Primary Processor-Based VM-Execution Controls (HLT/INVLPG/MWAIT/
>>> RDPMC/RDTSC/MONITOR/PAUSE)
>>> 2. Secondary Processor-Based VM-Execution Controls (WBINVD)
>>> 3. No control flag (CPUID/INVD)
>>>
>>> Signed-off-by: Arthur Chunqi Li <yzt356@gmail.com>
>>> ---
>>> x86/vmx.c | 3 +-
>>> x86/vmx.h | 7 ++++
>>> x86/vmx_tests.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 125 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/x86/vmx.c b/x86/vmx.c
>>> index ca36d35..c346070 100644
>>> --- a/x86/vmx.c
>>> +++ b/x86/vmx.c
>>> @@ -336,8 +336,7 @@ static void init_vmx(void)
>>> : MSR_IA32_VMX_ENTRY_CTLS);
>>> ctrl_cpu_rev[0].val = rdmsr(basic.ctrl ? MSR_IA32_VMX_TRUE_PROC
>>> : MSR_IA32_VMX_PROCBASED_CTLS);
>>> - if (ctrl_cpu_rev[0].set & CPU_SECONDARY)
>>> - ctrl_cpu_rev[1].val = rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2);
>>> + ctrl_cpu_rev[1].val = rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2);
>>> if (ctrl_cpu_rev[1].set & CPU_EPT || ctrl_cpu_rev[1].set & CPU_VPID)
>>> ept_vpid.val = rdmsr(MSR_IA32_VMX_EPT_VPID_CAP);
>>>
>>> diff --git a/x86/vmx.h b/x86/vmx.h
>>> index dba8b20..d81d25d 100644
>>> --- a/x86/vmx.h
>>> +++ b/x86/vmx.h
>>> @@ -354,6 +354,9 @@ enum Ctrl0 {
>>> CPU_INTR_WINDOW = 1ul << 2,
>>> CPU_HLT = 1ul << 7,
>>> CPU_INVLPG = 1ul << 9,
>>> + CPU_MWAIT = 1ul << 10,
>>> + CPU_RDPMC = 1ul << 11,
>>> + CPU_RDTSC = 1ul << 12,
>>> CPU_CR3_LOAD = 1ul << 15,
>>> CPU_CR3_STORE = 1ul << 16,
>>> CPU_TPR_SHADOW = 1ul << 21,
>>> @@ -361,6 +364,8 @@ enum Ctrl0 {
>>> CPU_IO = 1ul << 24,
>>> CPU_IO_BITMAP = 1ul << 25,
>>> CPU_MSR_BITMAP = 1ul << 28,
>>> + CPU_MONITOR = 1ul << 29,
>>> + CPU_PAUSE = 1ul << 30,
>>> CPU_SECONDARY = 1ul << 31,
>>> };
>>>
>>> @@ -368,6 +373,8 @@ enum Ctrl1 {
>>> CPU_EPT = 1ul << 1,
>>> CPU_VPID = 1ul << 5,
>>> CPU_URG = 1ul << 7,
>>> + CPU_WBINVD = 1ul << 6,
>>> + CPU_RDRAND = 1ul << 11,
>>> };
>>>
>>> #define SAVE_GPR \
>>> diff --git a/x86/vmx_tests.c b/x86/vmx_tests.c
>>> index ad28c4c..66187f4 100644
>>> --- a/x86/vmx_tests.c
>>> +++ b/x86/vmx_tests.c
>>> @@ -20,6 +20,13 @@ static inline void set_stage(u32 s)
>>> asm volatile("mov %0, stage\n\t"::"r"(s):"memory", "cc");
>>> }
>>>
>>> +static inline u32 get_stage()
>>> +{
>>> + u32 s;
>>> + asm volatile("mov stage, %0\n\t":"=r"(s)::"memory", "cc");
>>> + return s;
>>> +}
>>
>> Tagging "stage" volatile will obsolete this special assembly.
>>
>>> +
>>> void basic_init()
>>> {
>>> }
>>> @@ -638,6 +645,114 @@ static int iobmp_exit_handler()
>>> return VMX_TEST_VMEXIT;
>>> }
>>>
>>> +asm(
>>> + "insn_hlt: hlt;ret\n\t"
>>> + "insn_invlpg: invlpg 0x12345678;ret\n\t"
>>> + "insn_mwait: mwait;ret\n\t"
>>> + "insn_rdpmc: rdpmc;ret\n\t"
>>> + "insn_rdtsc: rdtsc;ret\n\t"
>>> + "insn_monitor: monitor;ret\n\t"
>>> + "insn_pause: pause;ret\n\t"
>>> + "insn_wbinvd: wbinvd;ret\n\t"
>>> + "insn_cpuid: cpuid;ret\n\t"
>>> + "insn_invd: invd;ret\n\t"
>>> +);
>>> +extern void insn_hlt();
>>> +extern void insn_invlpg();
>>> +extern void insn_mwait();
>>> +extern void insn_rdpmc();
>>> +extern void insn_rdtsc();
>>> +extern void insn_monitor();
>>> +extern void insn_pause();
>>> +extern void insn_wbinvd();
>>> +extern void insn_cpuid();
>>> +extern void insn_invd();
>>> +
>>> +u32 cur_insn;
>>> +
>>> +struct insn_table {
>>> + const char *name;
>>> + u32 flag;
>>> + void (*insn_func)();
>>> + u32 type;
>>
>> What do the "type" values mean?
> For intercepted instructions we have three type: controlled by Primary
> Processor-Based VM-Execution Controls, controlled by Secondary
> Controls and always intercepted. The testing process is different for
> different types.
This was a rhetorical questions. ;) Could you make the values symbolic?
>>
>>> + u32 reason;
>>> + ulong exit_qual;
>>> + u32 insn_info;
>>
>> For none of the instructions you test, EXI_INST_INFO will have valid
>> content on exit. So you must not check it anyway.
> Actually , "RDRAND" uses EXI_INST_INFO though it is not supported now.
> Since for all intercepts these three vmcs fields are enough to
> determine everything, I put it here for future use.
OK, but don't test its value when it's undefined - like in all cases
implemented here.
>>
>>> +};
>>> +
>>> +static struct insn_table insn_table[] = {
>>> + // Flags for Primary Processor-Based VM-Execution Controls
>>> + {"HLT", CPU_HLT, insn_hlt, 0, 12, 0, 0},
>>> + {"INVLPG", CPU_INVLPG, insn_invlpg, 0, 14, 0x12345678, 0},
>>> + {"MWAIT", CPU_MWAIT, insn_mwait, 0, 36, 0, 0},
>>> + {"RDPMC", CPU_RDPMC, insn_rdpmc, 0, 15, 0, 0},
>>> + {"RDTSC", CPU_RDTSC, insn_rdtsc, 0, 16, 0, 0},
>>> + {"MONITOR", CPU_MONITOR, insn_monitor, 0, 39, 0, 0},
>>> + {"PAUSE", CPU_PAUSE, insn_pause, 0, 40, 0, 0},
>>> + // Flags for Secondary Processor-Based VM-Execution Controls
>>> + {"WBINVD", CPU_WBINVD, insn_wbinvd, 1, 54, 0, 0},
>>> + // Flags for Non-Processor-Based
>>> + {"CPUID", 0, insn_cpuid, 2, 10, 0, 0},
>>> + {"INVD", 0, insn_invd, 2, 13, 0, 0},
>>> + {NULL},
>>> +};
>>> +
>>> +static void insn_intercept_init()
>>> +{
>>> + u32 ctrl_cpu[2];
>>> +
>>> + ctrl_cpu[0] = vmcs_read(CPU_EXEC_CTRL0);
>>> + ctrl_cpu[0] |= CPU_HLT | CPU_INVLPG | CPU_MWAIT | CPU_RDPMC | CPU_RDTSC |
>>> + CPU_MONITOR | CPU_PAUSE | CPU_SECONDARY;
>>> + ctrl_cpu[0] &= ctrl_cpu_rev[0].clr;
>>> + vmcs_write(CPU_EXEC_CTRL0, ctrl_cpu[0]);
>>> + ctrl_cpu[1] = vmcs_read(CPU_EXEC_CTRL1);
>>> + ctrl_cpu[1] |= CPU_WBINVD | CPU_RDRAND;
>>> + ctrl_cpu[1] &= ctrl_cpu_rev[1].clr;
>>> + vmcs_write(CPU_EXEC_CTRL1, ctrl_cpu[1]);
>>> +}
>>> +
>>> +static void insn_intercept_main()
>>> +{
>>> + cur_insn = 0;
>>> + while(insn_table[cur_insn].name != NULL) {
>>> + set_stage(cur_insn);
>>> + if ((insn_table[cur_insn].type == 0 && !(ctrl_cpu_rev[0].clr & insn_table[cur_insn].flag)) ||
>>> + (insn_table[cur_insn].type == 1 && !(ctrl_cpu_rev[1].clr & insn_table[cur_insn].flag))) {
>>> + printf("\tCPU_CTRL.CPU_%s is not supported.\n", insn_table[cur_insn].name);
>>
>>
>> Coding style, specifically overlong lines.
>>
>>> + } else {
>>> + insn_table[cur_insn].insn_func();
>>> + if (stage != cur_insn + 1)
>>> + report(insn_table[cur_insn].name, 0);
>>
>> Would be good to test the inverse as well, i.e. the intercept-free
>> execution.
> Since this is called "insn_intercept", I think we'd better test
> intercept-free execution insns in a separate test suite.
You have all the infrastructure here now. Isn't it trivial to check
weather stage makes no progress when the intercept bit is cleared instead?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2013-08-15 8:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-13 15:56 [PATCH 0/4] kvm-unit-tests: Add a series of test cases Arthur Chunqi Li
2013-08-13 15:56 ` [PATCH 1/4] kvm-unit-tests: VMX: Add test cases for PAT and EFER Arthur Chunqi Li
2013-08-15 7:17 ` Jan Kiszka
2013-08-15 7:41 ` Arthur Chunqi Li
2013-08-15 7:48 ` Jan Kiszka
2013-08-15 8:05 ` Arthur Chunqi Li
2013-08-15 8:09 ` Jan Kiszka
2013-08-13 15:56 ` [PATCH 2/4] kvm-unit-tests: VMX: Add test cases for CR0/4 shadowing Arthur Chunqi Li
2013-08-15 7:30 ` Jan Kiszka
2013-08-15 7:40 ` Arthur Chunqi Li
2013-08-15 7:47 ` Jan Kiszka
2013-08-15 7:59 ` Arthur Chunqi Li
2013-08-15 8:07 ` Jan Kiszka
2013-08-18 14:07 ` Paolo Bonzini
2013-08-18 14:32 ` Gmail
2013-08-13 15:56 ` [PATCH 3/4] kvm-unit-tests: VMX: Add test cases for I/O bitmaps Arthur Chunqi Li
2013-08-15 7:40 ` Jan Kiszka
2013-08-15 7:51 ` Arthur Chunqi Li
2013-08-15 7:58 ` Jan Kiszka
2013-08-15 8:09 ` Arthur Chunqi Li
2013-08-15 8:13 ` Jan Kiszka
2013-08-15 8:20 ` Arthur Chunqi Li
2013-08-15 8:23 ` Jan Kiszka
2013-08-15 10:43 ` Arthur Chunqi Li
2013-08-13 15:56 ` [PATCH 4/4] kvm-unit-tests: VMX: Add test cases for instruction interception Arthur Chunqi Li
2013-08-15 8:06 ` Jan Kiszka
2013-08-15 8:16 ` Arthur Chunqi Li
2013-08-15 8:20 ` Jan Kiszka [this message]
2013-08-15 8:35 ` Arthur Chunqi Li
2013-08-15 8:40 ` Jan Kiszka
2013-08-15 8:48 ` Arthur Chunqi Li
2013-08-15 9:15 ` Jan Kiszka
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=520C8F42.2010101@web.de \
--to=jan.kiszka@web.de \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yzt356@gmail.com \
/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