On Wed, Oct 13, 2021, Sean Christopherson wrote: > On Fri, Aug 20, 2021, Brijesh Singh wrote: > > When SEV-SNP is enabled in the guest VM, the guest memory pages can > > either be a private or shared. A write from the hypervisor goes through > > the RMP checks. If hardware sees that hypervisor is attempting to write > > to a guest private page, then it triggers an RMP violation #PF. > > > > To avoid the RMP violation, add post_{map,unmap}_gfn() ops that can be > > used to verify that its safe to map a given guest page. Use the SRCU to > > protect against the page state change for existing mapped pages. > > SRCU isn't protecting anything. The synchronize_srcu_expedited() in the PSC code > forces it to wait for existing maps to go away, but it doesn't prevent new maps > from being created while the actual RMP updates are in-flight. Most telling is > that the RMP updates happen _after_ the synchronize_srcu_expedited() call. Argh, another goof on my part. Rereading prior feedback, I see that I loosely suggested SRCU as a possible solution. That was a bad, bad suggestion. I think (hope) I made it offhand without really thinking it through. SRCU can't work in this case, because the whole premise of Read-Copy-Update is that there can be multiple copies of the data. That simply can't be true for the RMP as hardware operates on a single table. In the future, please don't hesitate to push back on and/or question suggestions, especially those that are made without concrete examples, i.e. are likely off the cuff. My goal isn't to set you up for failure :-/