Page MenuHomeFreeBSD

pmap_is_valid_memattr: drop unused 'pmap' argument
AbandonedPublic

Authored by mhorne on May 23 2024, 7:16 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Jul 19, 1:08 PM
Unknown Object (File)
Sat, Jul 13, 7:44 AM
Unknown Object (File)
Sun, Jul 7, 12:48 PM
Unknown Object (File)
Wed, Jul 3, 10:36 PM
Unknown Object (File)
Sun, Jun 30, 11:58 PM
Unknown Object (File)
Wed, Jun 26, 1:27 AM
Unknown Object (File)
May 25 2024, 10:07 PM
Unknown Object (File)
May 25 2024, 6:09 PM

Details

Summary

Logically, it doesn't make sense that this result would differ per-pmap.
In practice, no implementation uses the argument, so remove it.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 57874
Build 54762: arc lint + arc unit

Event Timeline

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

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.

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:

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.

ACK, thanks both. I am glad to drop it.