Well, on amd64 and arm64 we have multiple pmap types in order to support vmm, which generally involves 2 stages of translation: first from guest VA to guest PA, then guest PA to host PA. The mappings used by each stage are maintained in a pmap, but the pmap layer needs to be aware of which stage of the translation it's handling. On amd64, this is reflected in pm_type; on arm64 this is pm_stage. In general, the encoding of a PTE might depend on the type of the pmap, see pmap_valid_bit() on amd64 for example.

While there's currently no difference between pmap types in the handling of memattrs, it's not obvious to me that that'll always be true. In other words, I don't really agree with the premise of the patch. Maybe I'm missing some reason that my concern is invalid.

In D45321#1034161, @markj wrote:

Logically, it doesn't make sense that this result would differ per-pmap.

...

While there's currently no difference between pmap types in the handling of memattrs, it's not obvious to me that that'll always be true. In other words, I don't really agree with the premise of the patch. Maybe I'm missing some reason that my concern is invalid.

There is already a PAT mode (UC-) which cannot be represented in EPT. Although the mode is a hack to fix broken sofware (I believe), it is still a demonstration of the issue.

In D45321#1034234, @kib wrote:

In D45321#1034161, @markj wrote:

Logically, it doesn't make sense that this result would differ per-pmap.

...

While there's currently no difference between pmap types in the handling of memattrs, it's not obvious to me that that'll always be true. In other words, I don't really agree with the premise of the patch. Maybe I'm missing some reason that my concern is invalid.

There is already a PAT mode (UC-) which cannot be represented in EPT. Although the mode is a hack to fix broken sofware (I believe), it is still a demonstration of the issue.