[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86emul: de-duplicate scatters to the same linear address

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 <jbeulich@xxxxxxxx>
>> ---
>> 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."


"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).




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.