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:46, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----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.

The only downside is that this will need require peeking at
current->arch.hvm_vcpu.hvm_io.io_req.state, which would
(even if the source file is the same) be a mild layering violation.

>> But then again a MOVS has two memory operands ...
>> 
> 
> True... more of an argument for having two latched addresses though, right?

Yes, albeit two then isn't enough either if we want to fully address
the basic issue here: We'd have to latch as many translations as
there are possibly pages involved in the execution of a single
instruction.

Jan


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