Re: [PATCH] x86/ept: limit calls to memory_type_changed()

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.09.2022 17:58, Roger Pau Monné wrote:
> On Mon, Sep 26, 2022 at 05:36:41PM +0200, Jan Beulich wrote:
>> On 26.09.2022 17:25, Roger Pau Monné wrote:
>>> Correction: the Arm memory_type_changed() needs to stay, as
>>> iomem_{permit,deny}_access() is common code.
>>
>> Right, or we'd need some other arch abstraction. (I wonder whether
>> long term Arm can actually get away without this. Even on the AMD side
>> of x86 I don't think it's quite right that adding/removing of MMIO
>> ranges has no effect on the memory type of accesses.)
> 
> IIRC there's no way for the hypervisor to infer cache attributes on
> AMD SVM for NPT entries, but maybe I'm missing something.  Guest MTRRs
> settings are completely ignored for AMD guests.

Right, as documented: "Note that there is no hardware support for guest
MTRRs; the VMM can simulate their effect by altering the memory types
in the nested page tables." That's something we imo should do, but which
I don't think we actually do (see p2m_type_to_flags()). We respect the
PAT bit when splitting large pages, but I don't think we ever set the
bit when making new / updated entries.

>  I'm not able ATM
> however to find in the AMD PM how effective cache attributes are
> calculated when using NPT however.  I would guess host MTRR + guest
> PAT?

First guest and host PAT are combined, then the result is combined with
(host) MTRR. See the tables in the "Nested Paging" sub-section "Combining
Memory Types, MTRRs". Of course things are quite a bit more limited (but
also simpler) in shadow mode.

Jan