On 27/11/2025 1:39 pm, Teddy Astie wrote: > First patch removes a shadow mode check in a function that can't be > called with shadow mode (only called with EPT hence HAP). > > 3 other patches drops guest_tlb_flush_mask by removing all its users : > in the shadow paging case by migrating it a shadow variant of it and > in the hap case by moving it to p2m->flush_tlb logic. > > One of the goal is to prepare adding HAP-specific optimizations to TLB > flushing code without risking regressions in the shadow paging code.
You need a clearer background to try and explain the changes. I've discussed some of it with you, but it needs describing here for everyone else. >From memory, encrypted AMD VMs cannot use "asid++" to flush TLBs, and must used VMCB->tlb_ctrl instead. On top of that, Xen does not have a correct abstraction for "flush guest VA space" vs "flush guest PA space" vs "flush Xen's mappings of guest VA space". This comes about because of the shadow code originally had all 3 things together, and HAP didn't clean this up when the need first arose. This causes over-flushing (Tamas found and reported this on Intel), and FLUSH_HVM_ASID_CORE isn't an adequate abstraction either. All of that said, it would help to have a sketch of what you want the logic to look like in the end. "flush guest VA space" and "flush guest PA space" originate from different actions. VA flushes always from emulation of a guest action, whereas PA flushes originate from modifications to the P2M. When shadow is in use, both of these escalate into a full local flush because of Xen's use of shadow linear mappings, but this escalation should be inside the shadow code, not the top level primitive. Have I missed anything else? ~Andrew
