[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] x86/HVM: correct hvmemul_map_linear_addr() for multi-page case
>>> On 20.09.18 at 14:41, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |