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:43
> To: Paul Durrant
> Cc: Sander Eikelenboom; xen-devel@xxxxxxxxxxxxx; Boris Ostrovsky
> Subject: RE: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from
> emulate.c:144 RIP: c000:[<000000000000336a>]
> 
> >>> On 15.06.16 at 17:29, <Paul.Durrant@xxxxxxxxxx> wrote:
> >>  -----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?
> 
> Would we want to rely on it despite crossing a page boundary?
> Of course what was determined to be contiguous should
> continue to be, so one might even say using the latched
> translation in that case would provide more consistent results
> (as we'd become independent of a guest page table change).

Yes, exactly.

> But then again a MOVS has two memory operands ...
> 

True... more of an argument for having two latched addresses though, right?

  Paul

> Jan


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