>>> On 04.02.16 at 19:36, <konrad.w...@oracle.com> wrote: > (XEN) nvmx_handle_vmwrite 1: IO_BITMAP_A(2000)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 0: IO_BITMAP_A(2000)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 1: IO_BITMAP_B(2002)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 2: IO_BITMAP_A(2000)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 1: VIRTUAL_APIC_PAGE_ADDR(2012)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 2: IO_BITMAP_B(2002)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 1: (2006)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 2: VIRTUAL_APIC_PAGE_ADDR(2012)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 1: VM_EXIT_MSR_LOAD_ADDR(2008)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 3: IO_BITMAP_A(2000)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 3: IO_BITMAP_B(2002)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 2: MSR_BITMAP(2004)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 1: MSR_BITMAP(2004)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 0: MSR_BITMAP(2004)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 3: (2006)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 3: VM_EXIT_MSR_LOAD_ADDR(2008)[0=ffffffffffffffff] > (XEN) nvmx_handle_vmwrite 3: MSR_BITMAP(2004)[0=ffffffffffffffff]
So there's a whole lot of "interesting" writes of all ones, and indeed VIRTUAL_APIC_PAGE_ADDR is among them, and the code doesn't handle that case (nor the equivalent for APIC_ACCESS_ADDR). What's odd though is that the writes are for vCPU 1 and 2, while the crash is on vCPU 3 (it would of course help if the guest had as few vCPU-s as possible without making the issue disappear). While you have circumvented the ASSERT() you've originally hit, the log messages you've added there don't appear anywhere, which is clearly confusing, so I wonder what other unintended effects your debugging code has (there's clearly an uninitialized variable issue in your additions to vmx_vmexit_handler(), but that shouldn't matter here, albeit it should have cause build failure, making me suspect the patch to be stale). Oddly enough the various bitmap field VMWRITEs above should all fail, yet the guest appears to recover from (ignore?) these failures. (From all I can tell we're prone to NULL dereferences due to that at least in _shadow_io_bitmap().) > (XEN) Failed vm entry (exit reason 0x80000021) caused by invalid guest state > (4). 4 means invalid VMCS link pointer - interesting. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel