Le 27/11/2025 à 20:52, Andrew Cooper a écrit : > 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. >
Not only for encrypted VMs, but also for broadcast TLB invalidations (like AMD INVLPGB and Intel RAR) which also requires this. I'm also wondering if the current model works well when Xen is running as a nested guest (as the L0 may get confused about the ASID changing constantly). > 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. > I guess that also wants to have a way to optionally specify the address we want to flush (whether it is gva or gpa). So that it can lower to things like single-address invalidation (instead of flushing everything) if possible and meaningful. Having a clearer model would definetely help clarifying p2m_tlb_flush_sync vs paging_flush_tlb (which sounds like it does the same thing, but actually not really). > > All of that said, it would help to have a sketch of what you want the > logic to look like in the end. > Yes, that's something I planned to do. > "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? > Nested virtualization will also wants clearly defined p2m semantics to avoid falling into obscure corner cases. > ~Andrew > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
