On Wed, May 15, 2024 at 11:47:02AM +0100, Suzuki K Poulose wrote: > On 14/05/2024 19:00, Catalin Marinas wrote: > > On Fri, Apr 12, 2024 at 09:42:08AM +0100, Steven Price wrote: > > Can someone summarise what the point of this protection bit is? The IPA > > memory is marked as protected/unprotected already via the RSI call and > > presumably the RMM disables/permits sharing with a non-secure hypervisor > > accordingly irrespective of which alias the realm guest has the linear > > mapping mapped to. What does it do with the top bit of the IPA? Is it > > that the RMM will prevent (via Stage 2) access if the IPA does not match > > the requested protection? IOW, it unmaps one or the other at Stage 2? > > The Realm's IPA space is split in half. The lower half is "protected" > and all pages backing the "protected" IPA is in the Realm world and > thus cannot be shared with the hypervisor. The upper half IPA is > "unprotected" (backed by Non-secure PAS pages) and can be accessed > by the Host/hyp. What about emulated device I/O where there's no backing RAM at an IPA. Does it need to have the top bit set? > The RSI call (RSI_IPA_STATE_SET) doesn't make an IPA unprotected. It > simply "invalidates" a (protected) IPA to "EMPTY" implying the Realm doesn't > intend to use the "ipa" as RAM anymore and any access to it from > the Realm would trigger an SEA into the Realm. The RSI call triggers an exit > to the host with the information and is a hint to the hypervisor to reclaim > the page backing the IPA. > > Now, given we need dynamic "sharing" of pages (instead of a dedicated > set of shared pages), "aliasing" of an IPA gives us shared pages. > i.e., If OS wants to share a page "x" (protected IPA) with the host, > we mark that as EMPTY via RSI call and then access the "x" with top-bit > set (aliasing the IPA x). This fault allows the hyp to map the page backing > IPA "x" as "unprotected" at ALIAS(x) address. Does the RMM sanity-checks that the NS hyp mappings are protected or unprotected depending on the IPA range? I assume that's also the case if the NS hyp is the first one to access a page before the realm (e.g. inbound virtio transfer; no page allocated yet because of a realm access). -- Catalin
