[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86emul: handle address wrapping for VMASKMOVP{S, D}
On 10/10/17 11:43, Jan Beulich wrote: > I failed to recognize the need to mirror the changes done by 7869e2bafe > ("x86emul/fuzz: add rudimentary limit checking") into the earlier > written but later committed 2fe43d333f ("x86emul: support remaining AVX > insns"): Behavior here is the same as for multi-part reads or writes. > > Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > --- > There's another issue here, but I'll first have to think about possible > (preferably non-intrusive) solutions: An access crossing a page > boundary and having > - a set mask bit corresponding to an element fully living in the first > page, > - one or more clear mask bits corresponding to the initial elements on > the second page, > - another higher mask bit being set > would result in a wrong CR2 value to be reported in case the access to > the second page would cause a fault (it would point to the start of the > page instead of the element being accessed). Neither splitting the > access here into multiple ones nor uniformly passing a byte or word > enable mask into ->write() seem very desirable. Is this just supposition, or have you confirmed what really happens on hardware? I expect that the mask operations turn into multi-part operations, which means their behaviour on a straddled fault is implementation defined (and behaves differently between Atoms and Xeons). One option we could do is to have a variation of the "Implement hvmemul_write() using real mappings" logic where we pull mappings into the vmap individually, but that would require some part of the code to convert ea + mask => linear address of each unit, so the eventual mapping can be constructed piece-wise. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |