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:40:54 +0200 [thread overview]
Message-ID: <520C9416.8080404@web.de> (raw)
In-Reply-To: <CABpY8MLk6=pOsBwVds6NNmw8TtgBngZB6K8MV6w=qKa-BTuusA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 8879 bytes --]
On 2013-08-15 10:35, Arthur Chunqi Li wrote:
> On Thu, Aug 15, 2013 at 4:20 PM, Jan Kiszka <jan.kiszka@web.de> wrote:
>> 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?
> OK. It's better to rename it to "ctrl_field" and define some macros
> such as CTRL_CPU0, CTRL_CPU1, CTRL_NONE to make it more readable.
>>
>>>>
>>>>> + 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.
> Only test the used field will make it more complex because we need to
> define which field is used in insn_table. Besides, if any of these
> three fields is unused, it will be set to 0;
Please point me to the paragraph in the SDM where this is stated.
> and I think writing like
> this is OK since we just write a test case.
>
> Arthur
>>
>>>>
>>>>> +};
>>>>> +
>>>>> +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?
> No, thus maybe we need to rename it to "instruction test" :)
This is an instruction intercept control test.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2013-08-15 8:40 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
2013-08-15 8:35 ` Arthur Chunqi Li
2013-08-15 8:40 ` Jan Kiszka [this message]
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=520C9416.8080404@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