[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

 


Rackspace

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