Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 15 June 2016 16:22
> To: Paul Durrant; Boris Ostrovsky
> Cc: Sander Eikelenboom; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from
> emulate.c:144 RIP: c000:[<000000000000336a>]
> 
> >>> On 15.06.16 at 16:56, <boris.ostrovsky@xxxxxxxxxx> wrote:
> > On 06/15/2016 10:39 AM, Jan Beulich wrote:
> >>>>> On 15.06.16 at 16:32, <boris.ostrovsky@xxxxxxxxxx> wrote:
> >>> So perhaps we shouldn't latch data for anything over page size.
> >> But why? What we latch is the start of the accessed range, so
> >> the repeat count shouldn't matter?
> >
> > Because otherwise we won't emulate full stos (or movs) --- we truncate
> > *reps to fit into a page, don't we?
> 
> That merely causes the instruction to get restarted (with a smaller
> rCX).
> 
> > And then we fail the completion check.
> >
> > And we should latch only when we don't cross page boundary, not just
> > when we are under 4K. Or maybe it's not that we don't latch it. It's
> > that we don't use latched data if page boundary is being crossed.
> 
> Ah, I think that's it: When we hand a batch to qemu which crosses
> a page boundary and latch the start address translation, upon
> retry (after qemu did its job) we'd wrongly reduce the repeat count
> because of finding the start address in the cache. So indeed I think
> it should be the latter: Not using an available translation is likely
> better than breaking up a large batch we hand to qemu. Paul, what
> do you think?

Presumably we can tell the difference because we have the vio ioreq state, 
which should tell us that we're waiting for I/O completion and so, in this 
case, you can avoid reducing the repeat count when retrying. You should still 
be able to use the latched translation though, shouldn't you?

  Paul 

> 
> In any event I'll revert the patch from staging, until I can provide
> a fixed one.
> 
> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel