On Wed, Aug 29, Olaf Hering wrote: > On Mon, Aug 13, Jan Beulich wrote: > > > And hence the consideration of mapping in an all zeros page > > instead. This is because of the way __hvmemul_read() / > > __hvm_copy() work: The latter doesn't tell its caller how many > > bytes it was able to read, and hence the former considers the > > entire range MMIO (and forwards the request for emulation). > > Of course all of this is an issue only because > > hvmemul_virtual_to_linear() sees no need to split the request > > at the page boundary, due to the balloon driver having left in > > place the mapping of the ballooned out page.
So how is this bug supposed to be fixed? What I see in my tracing is that __hvmemul_read gets called with gla==ffff880223bffff9/bytes==8. Then hvm_copy_from_guest_linear fills the buffer from gpa 223bffff9 with data, but finally it returns HVMTRANS_bad_gfn_to_mfn, which it got from a failed get_page_from_gfn for the second page. Now things go downhill. hvmemul_linear_mmio_read is called, which calls hvmemul_do_io/hvm_io_intercept. That returns X86EMUL_UNHANDLEABLE. As a result hvm_process_io_intercept(null_handler) is called, which overwrites the return buffer with 0xff. Olaf
signature.asc
Description: PGP signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel