> From: Jan Beulich > Sent: Wednesday, May 18, 2022 6:26 PM > > On 10.05.2022 16:30, Roger Pau Monné wrote: > > On Mon, Apr 25, 2022 at 10:42:50AM +0200, Jan Beulich wrote: > >> 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 <[email protected]> > >> --- > >> v4: Re-base over changes earlier in the series. > >> 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 > >> bits in this range (unconditionally, and with the workaround here in > >> place), which yielded the same behavior. > > > > Should we take Kevin's Reviewed-by as a heads up that bits 52..61 on > > some? IOMMUs are not usable? > > > > Would be good if we could get a more formal response I think. > > A more formal response would be nice, but given the age of the affected > hardware I don't expect anything more will be done there by Intel. >
I didn't hear response on this open internally.
