Re: [PATCH 0/2] MMIO emulation fixes

[Olaf Hering <olaf@aepfle.de>]

[-- Attachment #1.1: Type: text/plain, Size: 1244 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel