On 12/12/2012 07:36 AM, Marcelo Tosatti wrote: > On Mon, Dec 10, 2012 at 05:11:35PM +0800, Xiao Guangrong wrote: >> Changelog: >> There are some changes from Marcelo and Gleb's review, thank you all! >> - access indirect_shadow_pages in the protection of mmu-lock >> - fix the issue when unhandleable instruction access on large page >> - add a new test case for large page >> >> The current reexecute_instruction can not well detect the failed instruction >> emulation. It allows guest to retry all the instructions except it accesses >> on error pfn. >> >> For example, these cases can not be detected: >> - for tdp used >> currently, it refused to retry all instructions. If nested npt is used, the >> emulation may be caused by shadow page, it can be fixed by unshadow the >> shadow page. >> >> - for shadow mmu >> some cases are nested-write-protect, for example, if the page we want to >> write is used as PDE but it chains to itself. Under this case, we should >> stop the emulation and report the case to userspace. >> >> There are two test cases based on kvm-unit-test can trigger a infinite loop on >> current code (ept = 0), after this patchset, it can report the error to Qemu. >> >> Subject: [PATCH] access test: test unhandleable instruction >> >> Test the instruction which can not be handled by kvm >> >> Signed-off-by: Xiao Guangrong <xiaoguangrong@xxxxxxxxxxxxxxxxxx> > > Please submit the test for inclusion. There should be some way to make > it fail.. Yes. But it is not easy. If the test cases run normally, kvm will report a error to Qemu then Qemu will exit the vcpu thread after dumping the vcpu state. We need to do something to let guest can be aware that the error report is triggered. I guess we can add a option in Qemu, say '-notify-guest' and allow Qemu to inject #GP to guest with a special ERROR_CODE if error is reported. > program a timer interrupt and #GP? Could you please explain the detail? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
