[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [RFC 09/16] xen/arm: p2m: Introduce a function to resolve translation fault
Hi Stefano,
On 05/11/2018 17:56, Stefano Stabellini wrote:
On Mon, 5 Nov 2018, Julien Grall wrote:
On 02/11/2018 23:27, Stefano Stabellini wrote:
On Mon, 8 Oct 2018, Julien Grall wrote:
Currently a Stage-2 translation fault could happen:
1) MMIO emulation
2) When the page-tables is been updated using Break-Before-Make
^ have
3) Page not mapped
A follow-up patch will re-purpose the valid bit in an entry to generate
translation fault. This would be used to do an action on each entries to
^entry
track page used for a given period.
^pages
A new function is introduced to try to resolve a translation fault. This
will include 2) and the new way to generate fault explained above.
I can see the code does what you describe, but I don't understand why we
are doing this. What is missing in the commit message is the explanation
of the relationship between the future goal of repurposing the valid bit
and the introduction of a function to handle Break-Before-Make stage2
faults. Does it fix an issue with Break-Before-Make that we currently
have? Or it becomes needed due to the repurposing of valid? If so, why?
This does not fix any issue with BBM. The valid bit adds a 4th reasons for
translation fault. Both BBM and the valid bit will require to walk the
page-tables.
For the valid bit, we will need to walk the page-table in order to fixup the
entry (i.e set valid bit). We also can't use p2m_lookup(...) has it only tell
you the mapping exists, the valid bit may still not be set.
So we need to provide a new helper to walk the page-table and fixup an entry.
OK. Please expand a bit the commit message.
Sure.
+ break;
+ }
+
+ /*
+ * If the valid bit of the entry is set, it means someone was playing
with
+ * the Stage-2 page table. Nothing to do and mark the fault as
resolved.
+ */
+ if ( lpae_is_valid(entry) )
+ {
+ resolved = true;
+ goto out_unmap;
+ }
+
+ /*
+ * The valid bit is unset. If the entry is still not valid then the
fault
+ * cannot be resolved, exit and report it.
+ */
+ if ( !p2m_is_valid(entry) )
+ goto out_unmap;
+
+ /*
+ * Now we have an entry with valid bit unset, but still valid from
+ * the P2M point of view.
+ *
+ * For entry pointing to a table, the table will be invalidated.
^ entries
+ * For entry pointing to a block/page, no work to do for now.
^ entries
I am not entirely sure why it should be plural here. We are dealing with only
one entry it.
I was trying to make the grammar work as a generic sentence. To make it
singular we would have to remove "For":
If an entry is pointing to a table, the table will be invalidated.
If an entry is pointing to a block/page, no work to do for now.
I will use the singular version.
+ */
+ if ( lpae_is_table(entry, level) )
+ p2m_invalidate_table(p2m, lpae_get_mfn(entry));
Maybe because I haven't read the rest of the patches, it is not clear to
me why in the case of an entry pointing to a table we need to invalidate
it, and otherwise set valid to 1.
This was written in the commit message:
"To avoid invalidating all the page-tables entries in one go. It is
possible to invalidate the top-level table and then on trap invalidate
the table one-level down. This will be repeated until a block/page entry
has been reached."
It is mostly to spread the cost of invalidating the page-tables. With this
solution, you only need to clear the valid bit of the top-level entries to
invalidate the full P2M.
On the first access, you will trap, set the entry of the first "invalid
entry", and invalidate the next level if necessary.
The access will then be retried. If trapped, the process is repeated until all
the entries are valid.
It is possible to optimize it, avoiding intermediate trap when necessary. But
I would not bother looking at that for now. Indeed, this will be used for
lowering down the cost of set/way cache maintenance emulation. Any guest using
that already knows that a big cost will incur.
So instead of walking the page table in Xen, finding all the leaf
(level==3) entries that we need to set !valid, we just set !valid one of
the higher levels entries. On access, we'll trap in Xen, then set the
higher level entry back to valid but the direct children to !valid. And
we'll cycle again through this until the table entries are valid and the
leaf entry is the only invalid one: at that point we'll only set it to
valid and the whole translation for that address is valid again.
That's correct.
Very inefficient, but very simple to implement in Xen. A good way to > penalize
guests that are using instructions they should not be using :-)
I am not convinced you will see a major slowdown. As you will quickly go through
all the level, ending to only trap once after a bit. So the impact is mostly boot.
All right, please expand on the explanation in the commit message. It is
also worthy of a in-code comment on top of
p2m_resolve_translation_fault.
I will expand it.
One more comment below.
+ /*
+ * Now that the work on the entry is done, set the valid bit to
prevent
+ * another fault on that entry.
+ */
+ resolved = true;
+ entry.p2m.valid = 1;
+
+ p2m_write_pte(table + offsets[level], entry, p2m->clean_pte);
+
+ /*
+ * No need to flush the TLBs as the modified entry had the valid bit
+ * unset.
+ */
+
+out_unmap:
+ unmap_domain_page(table);
+
+out:
+ p2m_write_unlock(p2m);
+
+ return resolved;
+}
+
static inline int p2m_insert_mapping(struct domain *d,
gfn_t start_gfn,
unsigned long nr,
We probably want to update the comment on top of the call to
p2m_resolve_translation_fault:
Whoops. I will fix it.
@@ -1977,8 +1978,8 @@ static void do_trap_stage2_abort_guest(struct
cpu_user_regs *regs,
* with the Stage-2 page table. Walk the Stage-2 PT to check
* if the entry exists. If it's the case, return to the guest
*/
- mfn = gfn_to_mfn(current->domain, gaddr_to_gfn(gpa));
- if ( !mfn_eq(mfn, INVALID_MFN) )
+ if ( p2m_resolve_translation_fault(current->domain,
+ gaddr_to_gfn(gpa)) )
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
