Re: [Xen-devel] MMIO emulation failure on REP OUTS (was: [PATCH] x86/HVM: fix hvmemul_rep_outs_set_context())

["Jan Beulich" <JBeulich@xxxxxxxx>]

(shrinking Cc list)

>>> On 23.11.17 at 19:37, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 23/11/17 15:09, Jan Beulich wrote:
>> There were two issues with this function: Its use of
>> hvmemul_do_pio_buffer() was wrong (the function deals only with
>> individual port accesses, not repeated ones, i.e. passing it
>> "*reps * bytes_per_rep" does not have the intended effect). And it
>> could have processed a larger set of operations in one go than was
>> probably intended (limited just by the size that xmalloc() can hand
>> back).
>>
>> By converting to proper use of hvmemul_do_pio_buffer(), no intermediate
>> buffer is needed at all. As a result a preemption check is being added.
>>
>> Also drop unused parameters from the function.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> While this does look like real bug, and bugfix, it isn't the issue I'm
> hitting.  I've distilled the repro scenario down to a tiny XTF test,
> which is just a `rep outsb` with a buffer which crosses a page boundary.
> 
> The results are reliably:
> 
> (d1) --- Xen Test Framework ---
> (d1) Environment: HVM 32bit (No paging)
> (d1) Test hvm-print
> (d1) String crossing a page boundary
> (XEN) MMIO emulation failed (1): d1v0 32bit @ 0010:001032b0 -> 5e c3 8d
> b4 26 00 00 00 00 8d bc 27 00 00 00 00
> (d1) Test result: SUCCESS
> 
> The Port IO hits a retry because of hitting the page boundary, and the
> retry logic successes, as evident by all data hitting hvm_print_line(). 
> Somewhere however, the PIO turns into MMIO, and a failure is reported
> after the PIO completed successfully.  %rip in the failure message
> points after the `rep outsb`, rather than at it.
> 
> If anyone has any ideas, I'm all ears.  If not, I will try to find some
> time to look deeper into the issue.

The failure being UNHANDLEABLE, I have another possibility in
mind: What if there's a bogus extra retry attempt after the REP
OUTS was already handled? The POP which is the next insn
would result in x86_insn_is_mem_access() returning false (its
memory access is an implicit stack one, which the function
intentionally produces false for). I'll see if I can find time later
today to debug this a little - thanks for shrinking it down to an
XTF test.

Jan


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