test

struct kvm_memory_slot {
 gfn_t base_gfn;
 unsigned long npages;
 unsigned long *dirty_bitmap;
 struct kvm_arch_memory_slot arch;
 unsigned long userspace_addr;
 u32 flags;
 short id;
};

Some tricks of GIT

Add local branch to remote: git push -u origin new_branch
Delete remote branch: git push -u origin :del_branch

Feedback after weekly sync

There are some feedback from Jan after sync of this weekend.

1. Preemption timer: Currently "save preemption timer value on exit" is not supported, so preempt exit from L2->L0 cannot trace its preemption timer value and preemption timer value is reset when L0->L2. But L2->L0->L1 is not one case of L2->L1 exit, so preemption timer value should be kept.
1. Write test case for this bug.
2. Write "save preemption timer value on exit" support for KVM and nested KVM.
2. Instruction interception: Refine the codes using table-driven structure.
3. CR0/4 shadowing has some big problems
1. Some of flags are "owned" by L1 and some are shadowed. Check owned flags with vcpu->arch.cr0_guest_owned_bits and vcpu->arch.cr4_guest_owned_bits.
2. Write a test where in once case L1 shadows the bit and in the other it leave it to L2.
3. For CR0, we can test TS (owned by L1) and MP (shadow); for CR4, we can test DE (owned by L1) and TSD (shadow).
4. PAT and EFER looks good
5. For I/O bitmap: Needs to change the test cases totally.
1. Test low parts and high parts
2. Test in and out
3. Test access width
4. Test pass and trap, and "partial" pass or trap
5. Test corner cases: 0x0, 0x7FFF, 0x8000, 0xFFFF, overruns (4-bytes on address 0x7FFF, and 0xFFFF)

Plan for next milestone

So after the final (I hope it is the final one) version of VMX hypervisor patch is commited, we need another plan for the next milestone. The next one is about test cases for control bits in VM-Execution Control Fields and VM-Exit/VM-Entry Control Fields.

1. Save and restore IA32_PAT and IA32_EFER in VM-Exit and VM-Entry. These two bits are defined in Intel SDM, bit 18-21 in Table 24-10 and bit 14-15 in Table 24-12. IA32_EFER should be tested separately in and out of IA32e mode.
2. Test for VMX preemption timer. See details in Intel SDM "25.5.1 VMX-Preemption Timer", and bit 6 of Table 24-5.
3. I/O bitmaps and exception bitmaps. Test if they act right.
4. CR0/4 shadowing. See details in Intel SDM "24.6.6 Guest/Host Masks and Read Shadows for CR0 and CR4". CRx shadowing needs Haswell host, so as APICv and posted interrupts. Some related VMCS field is "CR0 guest/host mask", "CR4 guest/host mask", "CR0 read shadow" and "CR4 read shadow".
5. Instruction intercepts. Test instruction intercepts of VMX ans their exit codes and information. See Table 24-6 and 24-7, as well as chapter Chapter 27.2 which describes the information when VM exit. Some instructions maybe host capabilities.

The test cases cited above needs to be put in some separate files, all basic tests are so simple that they can live in the same file, maybe in instruction_intercepts.c, entry-exit-control.c. I'd prefer to put them all in a sub-directory named nvmx.

All the relevant patches should be committed after the framework patch is in, but I will keep developing in my tree.

Finally finished the first vmx hypervisor

I finally finished my first vmx hypervisor!

Mini-Hypervisor Milestone 2013/07/13

The job is too trivial to debug!!!

Now the VM can run and the VMCALL can call to vmx_entry and get the right VMEXIT reason. But calling to printf in VM fails and the VM blocks in someplace I don't know.

Well, goto sleep first :)

Checking and Loading Guest State When VMLAUNCH/VMRESUME

If all checks on the VMX controls and the host-state area pass, the following checks will take place in any order. Because VMX is entering Guest now, it will cause VMEXIT by loading host state fields in VMCS. So some exit reasons can be retrieved from VMCS exit reason.

I. Checks on Guest State Area

1. Checks on Guest Control Registers, Debug Registers and MSRs

• CR0 should be set correctly except:
• CR0.PE (bit 0) and CR0.PG (bit 31) are not checked if "unrestricted guest" VM-execution control is 1 (Bit 7 of Secondary Processor-Based VM-Execution Controls)
• CR0.NW (bit 29) and CR0.CD (bit 30) are never checked.
• If bit 31 in the CR0 field (corresponding to PG) is 1, bit 0 in that field (PE) must also be 1.
• The CR4 field must not set any bit to a value not supported in VMX operation
• If the “load debug controls” (Bit 2 of VM-Entry Controls) VM-entry control is 1, bits reserved in the IA32_DEBUGCTL MSR must be 0 in the field for that register.
• The following checks are performed on processors that support Intel 64 architecture:
• If the “IA-32e mode guest” (Bit 9 of VM-Entry Controls) VM-entry control is 1, bit 31 in the CR0 field (corresponding to CR0.PG) and bit 5 in the CR4 field (corresponding to CR4.PAE) must each be 1.
• If the “IA-32e mode guest” (Bit 9 of VM-Entry Controls) VM-entry control is 0, bit 17 in the CR4 field (corresponding to CR4.PCIDE) must each be 0.
• The CR3 field must be such that bits 63:52 and bits in the range 51:32 beyond the processor’s physicaladdress width are 0.
• If the “load debug controls” (Bit 2 of VM-Entry Controls) VM-entry control is 1, bits 63:32 in the DR7 field must be 0.
• The IA32_SYSENTER_ESP field and the IA32_SYSENTER_EIP field must each contain a canonical address.
• If the “load IA32_PERF_GLOBAL_CTRL” (Bit 13 of VM-Entry Controls) VM-entry control is 1, bits reserved in the IA32_PERF_GLOBAL_CTRL MSR must be 0 in the field for that register. (See Intel SDM Volumn 3B, Figure 18-3)
• If the “load IA32_PAT” (Bit 14 of VM-Entry Controls) VM-entry control is 1, the value of the field for the IA32_PAT MSR must be one that could be written by WRMSR without fault at CPL 0. Specifically, each of the 8 bytes in the field must have one of the values 0 (UC), 1 (WC), 4 (WT), 5 (WP), 6 (WB), or 7 (UC-).
• If the “load IA32_EFER” (Bit 15 of VM-Entry Controls) VM-entry control is 1, the following checks are performed on the field for the IA32_EFER MSR :
• Bits reserved in the IA32_EFER MSR must be 0.(See Intel SDM Volumn 3A, 2.2.1, Figure 2-4, Table 2-1)
• Bit 10 (corresponding to IA32_EFER.LMA) must equal the value of the “IA-32e mode guest” (bit 9 of VM-Entry Controls) VM-exit control. It must also be identical to bit 8 (LME) if bit 31 in the CR0 field (corresponding to CR0.PG) is 1.

2. Checks on Guest Segment Registers

This section specific the checks on the fields for CS, SS, DS, ES, FS, GS, TR, and LDTR.

The following terms will be checked first:

• The guest will be virtual-8086 if the VM flag (bit 17) is 1 in the RFLAGS field in the guest-state area.
• The guest will be IA-32e mode if the “IA-32e mode guest” VM-entry control (Bit 9 of VM-Entry Controls) is 1. (This is possible only on processors that support Intel 64 architecture.)
• Any one of these registers is said to be usable if the unusable bit (bit 16) is 0 in the access-rights field for that register.

Then the following checks on segment registers:

• Selector fields
• TR. The TI flag (bit 2) must be 0.
• LDTR. If LDTR is usable, the TI flag (bit 2) must be 0.
• SS. If the guest will not be virtual-8086 and the “unrestricted guest” VM-execution control is 0, the RPL (bits 1:0) must equal the RPL of the selector field for CS.
• Base-address fields.
• CS, SS, DS, ES, FS, GS. If the guest will be virtual-8086, the address must be the selector field shifted left 4 bits (multiplied by 16).
• The following checks are performed on processors that support Intel 64 architecture:
• TR, FS, GS. The address must be canonical
• LDTR. If LDTR is usable, the address must be canonical
• CS. Bits 63:32 of the address must be zero
• SS, DS, ES. If the register is usable, bits 63:32 of the address must be zero.
• Limit fields for CS, SS, DS, ES, FS, GS. If the guest will be virtual-8086, the field must be 0000FFFFH.
• Access-rights fields.
• CS, SS, DS, ES, FS, GS.
• If the guest will be virtual-8086, the field must be 000000F3H. This implies the following:
• Bits 3:0 (Type) must be 3, indicating an expand-up read/write accessed data segment.
• Bit 4 (S) must be 1.
• Bits 6:5 (DPL) must be 3.
• Bit 7 (P) must be 1.
• Bits 11:8 (reserved), bit 12 (software available), bit 13 (reserved/L), bit 14 (D/B), bit 15 (G), bit 16 (unusable), and bits 31:17 (reserved) must all be 0.
• If the guest will not be virtual-8086, the different sub-fields are considered separately:
• Bits 3:0 (Type).
• CS. The values allowed depend on the setting of the “unrestricted guest” VM-execution control (Bit 7 of Secondary Processor-Based VM-Execution Controls):
• If the control is 0, the Type must be 9, 11, 13, or 15 (accessed code segment).
• If the control is 1, the Type must be either 3 (read/write accessed expand-up data segment) or one of 9, 11, 13, and 15 (accessed code segment).
• SS. If SS is usable, the Type must be 3 or 7 (read/write, accessed data segment).
• DS, ES, FS, GS. The following checks apply if the register is usable:
• Bit 0 of the Type must be 1 (accessed).
• If bit 3 of the Type is 1 (code segment), then bit 1 of the Type must be 1 (readable).
• Bit 4 (S). If the register is CS or if the register is usable, S must be 1.
• Bits 6:5 (DPL).
• CS.
• If the Type is 3 (read/write accessed expand-up data segment), the DPL must be 0. The Type can be 3 only if the “unrestricted guest” VM-execution control is 1.
• If the Type is 9 or 11 (non-conforming code segment), the DPL must equal the DPL in the access-rights field for SS.
• If the Type is 13 or 15 (conforming code segment), the DPL cannot be greater than the DPL in the access-rights field for SS.
• SS.
• If the “unrestricted guest” VM-execution control is 0, the DPL must equal the RPL from the selector field.
• The DPL must be 0 either if the Type in the access-rights field for CS is 3 (read/write accessed expand-up data segment) or if bit 0 in the CR0 field (corresponding to CR0.PE) is 0.
• DS, ES, FS, GS. The DPL cannot be less than the RPL in the selector field if (1) the “unrestricted guest” VM-execution control is 0; (2) the register is usable; and (3) the Type in the access-rights field is in the range 0 – 11 (data segment or non-conforming code segment).
• Bit 7 (P). If the register is CS or if the register is usable, P must be 1.
• Bits 11:8 (reserved). If the register is CS or if the register is usable, these bits must all be 0.
• Bit 14 (D/B). For CS, D/B must be 0 if the guest will be IA-32e mode and the L bit (bit 13) in the access-rights field is 1.
• Bit 15 (G). The following checks apply if the register is CS or if the register is usable:
• If any bit in the limit field in the range 11:0 is 0, G must be 0.
• If any bit in the limit field in the range 31:20 is 1, G must be 1.
• Bits 31:17 (reserved). If the register is CS or if the register is usable, these bits must all be 0.
• TR. The different sub-fields are considered separately:
• Bits 3:0 (Type).
• If the guest will not be IA-32e mode, the Type must be 3 (16-bit busy TSS) or 11 (32-bit busy TSS).
• If the guest will be IA-32e mode, the Type must be 11 (64-bit busy TSS).
• Bit 4 (S). S must be 0.
• Bit 7 (P). P must be 1.
• Bits 11:8 (reserved). These bits must all be 0.
• Bit 15 (G).
• If any bit in the limit field in the range 11:0 is 0, G must be 0.
• If any bit in the limit field in the range 31:20 is 1, G must be 1.
• Bit 16 (Unusable). The unusable bit must be 0.
• Bits 31:17 (reserved). These bits must all be 0.
• LDTR. The following checks on the different sub-fields apply only if LDTR is usable:
• Bits 3:0 (Type). The Type must be 2 (LDT).
• Bit 4 (S). S must be 0.
• Bit 7 (P). P must be 1.
• Bits 11:8 (reserved). These bits must all be 0.
• Bit 15 (G).
• If any bit in the limit field in the range 11:0 is 0, G must be 0.
• If any bit in the limit field in the range 31:20 is 1, G must be 1.
• Bits 31:17 (reserved). These bits must all be 0.

3. Checks on Guest Descriptor-Table Registers

The following checks are performed on the fields for GDTR and IDTR:

• On processors that support Intel 64 architecture, the base-address fields must contain canonical addresses.
• Bits 31:16 of each limit field must be 0.

4. Checks on Guest RIP and RFLAGS

• RIP. The following checks are performed on processors that support Intel 64 architecture:
• Bits 63:32 must be 0 if the “IA-32e mode guest” (Bit 9 of VM-Entry Controls) VM-entry control is 0 or if the L bit (bit 13) in the access rights field for CS is 0.
• If the processor supports N < 64 linear-address bits, bits 63:N must be identical if the “IA-32e mode guest” VM-entry control is 1 and the L bit in the access-rights field for CS is 1.
• RFLAGS.
• Reserved bits 63:22 (bits 31:22 on processors that do not support Intel 64 architecture), bit 15, bit 5 and bit 3 must be 0 in the field, and reserved bit 1 must be 1.
• The VM flag (bit 17) must be 0 either if the “IA-32e mode guest” VM-entry control is 1 or if bit 0 in the CR0 field (corresponding to CR0.PE) is 0.
• The IF flag (RFLAGS[bit 9]) must be 1 if the valid bit (bit 31) in the VM-entry interruption-information field is 1 and the interruption type (bits 10:8) is external interrupt. (See Intel SDM, Volumn 3C, 24.8.3 VM-Entry Controls for Event Injection)

CPU state transfer in QEMU live migration

The CPU migration state in QEMU is in target-i386/machine.c. This file defines all the CPU states needed to transfer to the target VM in struct const VMStateDescription vmstate_x86_cpu. This struct consists of many version control messages. Messages can be set in VMStateSubsection to ignore version problems.

Read the relevant codes for more details.

Format of GDT entry

The Global Descriptor Table (GDT) usually used to hold segment informations. But GDT can hold things other than segment descriptors, every 8-byte entry in GDT is a descriptor, which can be TSS descriptor, LDT descriptor, Call Gate descriptor. I will introduce segment descriptors in this blog, because the last three descriptors are rarely used in most operating systems. Linux uses a shared TSS and LDT descriptor for every task and imply its own call gates mechanism.

Firstly, GDT can be accessed by a GDT descriptor. This descriptor is not the same as descriptors cited before, it is an assembly structure with a 2-byte size and a 4-byte offset. 2-byte size saves total entries in GDT and 4-byte offset refers to the first entry of GDT. So this means GDT entry can only be set on the first 4G memory.

Each entry of segment descriptor in GDT has a complex structure:

Here are three Base fields refers to the base address of a segment. What "Limit 0:15" means is that the field contains bits 0-15 of the limit value. The base is a 32 bit value containing the linear address where the segment begins. The limit, a 20 bit value, tells the maximum addressable unit (either in 1 byte units, or in pages). Hence, if you choose page granularity (4 KiB) and set the limit value to 0xFFFFF the segment will span the full 4 GiB address space. Here is the structure of the access byte and flags:

The bit fields are:

• Pr: Present bit. This must be 1 for all valid selectors.
• Privl: Privilege, 2 bits. Contains the ring level, 0 = highest (kernel), 3 = lowest (user applications).
• Ex: Executable bit. If 1 code in this segment can be executed, ie. a code selector. If 0 it is a data selector.
• DC: Direction bit/Conforming bit.
  • Direction bit for data selectors: Tells the direction. 0 the segment grows up. 1 the segment grows down, ie. the offset has to be greater than the base.
  • Conforming bit for code selectors:
    • If 1 code in this segment can be executed from an equal or lower privilege level. For example, code in ring 3 can far-jump to conforming code in a ring 2 segment. Theprivl-bits represent the highest privilege level that is allowed to execute the segment. For example, code in ring 0 cannot far-jump to a conforming code segment withprivl==0x2, while code in ring 2 and 3 can. Note that the privilege level remains the same, ie. a far-jump form ring 3 to a privl==2-segment remains in ring 3 after the jump.
    • If 0 code in this segment can only be executed from the ring set in privl.
• RW: Readable bit/Writable bit.
  • Readable bit for code selectors: Whether read access for this segment is allowed. Write access is never allowed for code segments.
  • Writable bit for data selectors: Whether write access for this segment is allowed. Read access is always allowed for data segments.
• Ac: Accessed bit. Just set to 0. The CPU sets this to 1 when the segment is accessed.
• Gr: Granularity bit. If 0 the limit is in 1 B blocks (byte granularity), if 1 the limit is in 4 KiB blocks (page granularity).
• Sz: Size bit. If 0 the selector defines 16 bit protected mode. If 1 it defines 32 bit protected mode. You can have both 16 bit and 32 bit selectors at once.

Not shown in the picture is the 'L' bit (bit 21, next to 'Sz') which is used for x86-64 mode. See table 3-1 of the Intel Architecture manual.

Refer to Intel Manual 3.4.5 for more details.

Some materials are cited from http://wiki.osdev.org/Global_Descriptor_Table

Intel Control Registers

Control registers of Intel CPU, including CR0/CR1/CR2/CR3/CR4/CR8, determine operating mode of the processor and the characteristics of the currently executing task. Most of the contents of this blog is cited from Intel manual Volume 3C.

All the CRx registers can be written by MOV, but only support moving from general registers to CRx, any move from memory may cause error when assembling. In 64-bit mode, control registers are expanded to 64 bits width. But the upper bits are always not used and set zero.

• CR0 - Contains system control flags that control operating mode and states of the processor.
• CR1 - Reserved.
• CR2 - Contains the page-fault linear address (the linear address that caused a page fault).
• CR3 - Contains the physical address of the base of the paging-structure hierarchy and two flags (PCD and PWT). The lower 12 bits of address are supposed to be 0 because they are for page offset while CR3 contains page directory. Then these bits store flags of page table.
• CR4 - Contains a group of flags that enable several architectural extensions, and indicate operating system or executive support for specific processor capabilities.
• CR8 - This register is available only in 64-bit mode. Provides read and write access to the Task Priority Register (TPR). It specifies the priority threshold value that operating systems use to control the priority class of external interrupts allowed to interrupt the processor.

One of the most import bit(s) in CR0 is PG and PE bit. PE(Protection Enable) bit is the bit 0 of CR0, which enables protected mode when set. It enables segment-level protection. PG(Paging) bit is the bit 31 of CR0, which enables paging when set. PG bit can be set only when PE is set. Set to these two bits means entering protected mode.

For more information about bits in control registers, you can refer to Intel Manual Volume 3C, chapter 2 System Architecture Overview.

What is GDT/LDT/IDT/TSS

GDT, LDT, IDT and TSS are all data structures specified by Intel x86 architecture in memory management module.

GDT, Global Descriptor Table, is used to define the characteristics of the various memory areas used during program execution, including the base address, the size and access privileges like executability and writability. These memory areas are called segments in Intel terminology. (From Wikipedia) Segment is a term for memory management in Intel x86 architecture, which is also used collaboratively with paging mechanism.

LDT, Local Descriptor Table, acts similar to GDT, which also saves segments descriptor. The main differences between GDT and LDT is: 1) GDT have only one copy in system while LDT can have many, 2) GDT may not changed during execution which LDT often changes when task switches, 3) entry of LDT is save in GDT. Entries in GDT and LDT have the same structure.

IDT, Interrupt Descriptor Table, is a data structure used by the x86 architecture to implement an interrupt vector table. The IDT is used by the processor to determine the correct response to interrupts and exceptions. Use of the IDT is triggered by three types of events: hardware interrupts, software interrupts, and processor exceptions, which together are referred to as "interrupts". The IDT consists of 256 interrupt vectors–the first 32 (0-31 or 00-1F) of which are reserved for processor exceptions. (From Wikipedia)

TSS, Task State Segment, is a special structure on x86-based computers which holds information about a task. It is used by the operating system kernel for task management. The TSS may reside anywhere in memory. A special segment register called the task register (TR) holds a segment selector that points to a valid TSS segment descriptor which resides in the GDT (a TSS descriptor may not reside in the LDT). The TSS may contain saved values of all the x86 registers. This is used for task switching. The operating system may load the TSS with the values of the registers that the new task needs and after executing a hardware task switch (such as with an IRET instruction) the x86 CPU will load the saved values from the TSS into the appropriate registers.

Note that only IDT is necessary for a CPU running normally. But actually, GDT is also used to store globally shared memory message. LDT is actually not used in Linux (every task used a shared default LDT). TSS is also used the same as LDT -- all tasks use a shared TSS. Before Linux 2.4, TSS is used for task switching. But every entry of TSS and LDT should be saved in GDT, which limits the total task numbers in the system. Linux uses software mechanism to manage task switching.

How to build a micro hypervisor

I'm trying to find out how to build a micro hypervisor these days. As to what I know, building a micro hypervisor needs at least 5 parts as follows:

1. CPU management. This part consists physical CPU (pCPU) management and virtual CPU (vCPU) management. Every pCPU should be initialed first and each CPU of VM needs a structure to management its flags, registers and states.
2. Memory management. Memory management and isolation protection is another key feature of hypervisor. Hypervisor needs to know which part of physical memory is allocated to separated VM. Some advanced feature such as buddy system and memory ballooning may also be applied in hypervisor. 
3. Interrupt control and exception handling. This part controls interrupts and exceptions caused in VM. This part mainly handles VMEXIT and inserts interrupts when VMENTER.
4. Scheduling. This is a feature to support scheduling vCPUs on pCPUs.
5. Communication. Communication between hypervisor and VM, as well as between VMs, is also another feature supported by hypervisor. Messages transferred between different domains should be handled by each sides. A message queue is used in Xen to support asynchronous communication.

In our test cases, we just need a much more simple hypervisor. We just need CPU management, memory management and interrupt control at first. Switching between different VMs can be supported in later version.

Footprint - June 25th

Actually, after all the final exams it is the first day for me to coding today. As what I have discussed with Jan last week, it seems to be a hard startup for our project.

First, I need to build up a tiny hypervisor which can support simple functions for nested virtualization test cases. Here is a simple tiny hypervisor named NOVA (https://github.com/IntelLabs/NOVA). I'm now reading through all NOVA's code. But unfortunately NOVA is written in C++! I have almost forget how to write inheritance! So I need "C++ Primer" by hand when reading codes ;(. I planned to thoroughly understand NOVA's code and write an abstract of implementing tiny hypervisor before IRC meet of this weekend.

It is sad that I have not received my welcome package! Some of my friends received request of custom declaration but I haven't got any message or phone call. I will ask Carol for my trace number of FedEx and then call FedEx for details of my package.

I'm itch for new lens, Sigma 10-20mm/F4~5.6, using on my D7000. I'm now staggering, maybe because the payment of GSoC has not come to hand.^_^

Configuring git send-email to use Gmail SMTP

Firstly, apt-get install git-email.

Then, add the correct configuration variables with the following:

$ git config --global sendemail.smtpserver smtp.gmail.com

$ git config --global sendemail.smtpserverport 587

$ git config --global sendemail.smtpencryption tls

$ git config --global sendemail.smtpuser your_email@gmail.com

Now it’s ready to use git send-email. Password is needed each time you send email.

P.S. Before using git send-email, you should use git format-patch first.

git format-patch -M origin/master
git send-email --to xxx@xxx.com --cc xxx@xxx.com 0001-xxx.patch

git config --global user.email "yzt356@gmail.com"
git config --global user.name "Arthur Chunqi Li"

Apply for GSoC’13 - Nested Virtualization Project

Email: yzt356 at gmail dot com

Short description: I’m a student of Peking University, China, and now seeking for a master degree. My research area is distributed system and virtualization. I have focused on opensource community (especially Xen & kVM) for some time an I’d like to do something for opensource.

Additional info: http://www.linkedin.com/profile/view?id=203536720

Please contact the mentor before applying so we can arrange for an IRC interview and get to know each other. Students who do not contact the mentor cannot be accepted.

Name: Arthur Chunqi Li

IRC nick: #xelatex

Phone number: +861861225XXXX (Please contact me via email)

Programming languages (fluent): C, python, assembly x86

Version control systems: Git SVN

Past open source contributions: Focus on Xen & KVM, report some bugs

Other relevant experience: I have done intern jobs in EMC and Intel about side-channel attack on virtualization and lightweight virtualization.

Why are you applying to QEMU.org?

My research area is virtualization and I have focused on Xen & KVM for some time. Some of my research work are now under KVM so I’m familiar with Qemu and KVM.

Why did you chose this project idea?

Mostly because I have great interest in it, and I think I can handle such a project.

Summary of your understanding of the project idea:

The project I apply for is “Improve nested virtualization support for x86”. which is mostly a testing work. Nested virtualization is a mechanism to run hypervisor in a virtualized environment. Nested virtualization is good for debugging hypervisor, migrating hypervisor and offering fine granularity virtualization. For KVM, nested virtualization is implemented but have a lot of bugs and unrealized features to run a nested environment. This project is to find bugs in nested environment with kvm-units-test and some other well-defined test cases. Some easy bug fixed codes should be patched for this project. The greatest challenge for this project is undetermined final goal because you don’t know what the bugs are until you find it, which is different from some programming projects. Besides testing project needs very good and detailed knowledge on the whole virtualization system as well as some hardware knowledge. Now I’m reading the manual of Intel & AMD CPU and try to get to know the vmx & svm well.

Outline of how you will tackle the project:

I will tackle the project in different steps:

1. Build up a nested virtualization environment and run some basic test cases of kvm-units-test. (Done, besides there is a bug just when I start running nested virt, I have found the reason and reported to the maillist.)

2. Reading manual and related materials related to nested virtualization.(Almost done)

3. Reading codes of kvm-units-test and try to understand the testing manners of test cases. (Doing)

4. Starting test with the current KVM codes and test cases, reporting and try to fix bugs.

5. Write special test cases (if any) for nested virtualization environment.

6. Some other works such as implementing new features (need to discussed with mentor).

How will you do the testing and the schedule.

• May 28th ~ Jun 16th. Read through the materials including Intel Manual 3C and other docs related. 
• Jun 17th ~ Jul 6th (3 weeks). VMX instructions check. This part consists of most VMX instructions (VMPTRLD, VMPTRST, VMXON, VMXOFF and so on), which is the basic of Intel VT. 
• Jul 6th ~ Jul 29th (3 weeks). MSR checks and memory checks. In this part RDMSR and WRMSR of Intel VT related MSRs will be checked. MSR is CPU vendor diversified and I will only focused on some special vendor. Memory check has been implemented in kvm-test-units and I just need to refined it. 
• Jul 30th ~ Aug 2nd (1 week). Prepare for mid-term evaluation. 
• Aug 3rd ~ Sept 7th (5 weeks).  VM-enter & VM-exit checks, memory check. VM-enter and VM-exit is the key part of Intel VT and kvm-test-units lacks of these tests. APIC checks, including I/O APIC. In the period some other undetermined tests will carry on. And I may have a trip for about a week in this period. 
• Sept 8th ~ Sept 14th (1 week). Handling some other affairs and reserve some flexible time for emergency. 
• Sept 15th ~ Sept 23th (1 week). Prepare for final evaluation.

• I’m open for any suggestions to this project, please contact me via Gmail at any time.