> From: Jan Beulich <jbeul...@suse.com> > Sent: Tuesday, January 11, 2022 12:36 AM > > When a page table ends up with no present entries left, it can be > replaced by a non-present entry at the next higher level. The page table > itself can then be scheduled for freeing. > > Note that while its output isn't used there yet, > pt_update_contig_markers() right away needs to be called in all places > where entries get updated, not just the one where entries get cleared. > > Note further that while pt_update_contig_markers() updates perhaps > several PTEs within the table, since these are changes to "avail" bits > only I do not think that cache flushing would be needed afterwards. Such > cache flushing (of entire pages, unless adding yet more logic to me more > selective) would be quite noticable performance-wise (very prominent > during Dom0 boot). > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > v3: Properly bound loop. Re-base over changes earlier in the series. > v2: New. > --- > The hang during boot on my Latitude E6410 (see the respective code > comment) was pretty close after iommu_enable_translation(). No errors, > no watchdog would kick in, just sometimes the first few pixel lines of > the next log message's (XEN) prefix would have made it out to the screen > (and there's no serial there). It's been a lot of experimenting until I > figured the workaround (which I consider ugly, but halfway acceptable). > I've been trying hard to make sure the workaround wouldn't be masking a > real issue, yet I'm still wary of it possibly doing so ... My best guess > at this point is that on these old IOMMUs the ignored bits 52...61 > aren't really ignored for present entries, but also aren't "reserved" > enough to trigger faults. This guess is from having tried to set other
Is this machine able to capture any VT-d faults before? If yes maybe you will observe more information if trying to tweak those bits at a later time (instead of when iommu is enabled)? Thanks Kevin
