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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 30/08/2023 3:30 pm, Roger Pau Monné wrote:
> On Wed, Sep 12, 2018 at 03:09:35AM -0600, 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).

Erm... No?

There are up to 25 translations steps, assuming a memory operand
contained entirely within a cache-line.

They intermix between gla->gpa and gpa->spa in a strict order.

There not a point where the error is ambiguous, nor is there ever a
point where a pagewalk continues beyond a faulting condition.

Hardware certainly isn't wasting transistors to hold state just to see
could try to progress further in order to hand back a different error...


When the pipeline needs to split an access, it has to generate multiple
adjacent memory accesses, because the unit of memory access is a cache line.

There is a total order of accesses in the memory queue, so any faults
from first byte of the access will be delivered before any fault from
the first byte to move into the next cache line.


I'm not necessarily saying that Xen's behaviour in
hvmemul_map_linear_addr() is correct in all cases, but it looks a hell
of a lot more correct in it's current form than what this patch presents.

Or do you have a concrete example where you think
hvmemul_map_linear_addr() behaves incorrectly?

~Andrew