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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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).
But then again a MOVS has two memory operands ...

Jan


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