[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." 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |