Re: [PATCH v2] x86/HVM: correct hvmemul_map_linear_addr() for multi-page case

["Jan Beulich" <JBeulich@suse.com>]

>>> On 20.09.18 at 14:41, <andrew.cooper3@citrix.com> wrote:
> On 13/09/18 11:12, Jan Beulich wrote:
>> The function does two translations in one go for a single guest access.
>> Any failure of the first translation step (guest linear -> guest
>> physical), resulting in #PF, ought to take precedence over any failure
>> of the second step (guest physical -> host physical).
> 
> Why?  What is the basis of this presumption?
> 
> As far as what real hardware does...
> 
> This test sets up a ballooned page and a read-only page.  I.e. a second
> stage fault on the first part of a misaligned access, and a first stage
> fault on the second part of the access.
> 
> (d1) --- Xen Test Framework ---
> (d1) Environment: HVM 64bit (Long mode 4 levels)
> (d1) Test splitfault
> (d1) About to read
> (XEN) *** EPT qual 0000000000000181, gpa 000000000011cffc
> (d1) Reading PTR: got 00000000ffffffff
> (d1) About to write
> (XEN) *** EPT qual 0000000000000182, gpa 000000000011cffc
> (d1) ******************************
> (d1) PANIC: Unhandled exception at 0008:00000000001047e0
> (d1) Vec 14 #PF[-d-sWP] %cr2 000000000011d000
> (d1) ******************************
> 
> The second stage fault is recognised first, which is contrary to your
> presumption, i.e. the code in its current form appears to be correct.

Coming back to this example of yours: As a first step, are we in
agreement that with the exception of very complex instructions
(FSAVE, FXSAVE, XSAVE etc) instructions are supposed to work in an
all-or-nothing manner when it comes to updating of architectural
state (be it registers or memory)? If you agree, then I cannot see
how avoiding to raise #PF on the second half of a split access can be
correct in your opinion, irrespective of the first vs second level
translation ordering for the two parts. In fact I think there are further
cases where we would need to change code for this to be guaranteed,
but hvmemul_map_linear_addr() can be quite helpful here (once
patched as suggested).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel