On 05.02.2021 11:41, Andrew Cooper wrote:
> On 10/11/2020 13:26, Jan Beulich wrote:
>> The SDM specifically allows for earlier writes to fully overlapping
>> ranges to be dropped. If a guest did so, hvmemul_phys_mmio_access()
>> would crash it if varying data was written to the same address. Detect
>> overlaps early, as doing so in hvmemul_{linear,phys}_mmio_access() would
>> be quite a bit more difficult.
>
> Are you saying that there is currently a bug if a guest does encode such
> an instruction, and we emulate it?
That is my take on it, yes.
>> Note that due to cache slot use being linear address based, there's no
>> similar issue with multiple writes to the same physical address (mapped
>> through different linear addresses).
>>
>> Since this requires an adjustment to the EVEX Disp8 scaling test,
>> correct a comment there at the same time.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> TBD: The SDM isn't entirely unambiguous about the faulting behavior in
>> this case: If a fault would need delivering on the earlier slot
>> despite the write getting squashed, we'd have to call ops->write()
>> with size set to zero for the earlier write(s). However,
>> hvm/emulate.c's handling of zero-byte accesses extends only to the
>> virtual-to-linear address conversions (and raising of involved
>> faults), so in order to also observe #PF changes to that logic
>> would then also be needed. Can we live with a possible misbehavior
>> here?
>
> Do you have a chapter/section reference?
The instruction pages. They say in particular
"If two or more destination indices completely overlap, the “earlier”
write(s) may be skipped."
and
"Faults are delivered in a right-to-left manner. That is, if a fault
is triggered by an element and delivered ..."
To me this may or may not mean the skipping of indices includes the
skipping of faults (which a later element then would raise anyway).
Jan