> From: Jan Beulich <jbeul...@suse.com> > Sent: Monday, March 14, 2022 3:33 PM > > On 14.03.2022 05:01, Tian, Kevin wrote: > >> From: Jan Beulich <jbeul...@suse.com> > >> Sent: Friday, February 18, 2022 4:31 PM > >> > >> On 18.02.2022 06:20, Tian, Kevin wrote: > >>>> 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? > >> > >> Not sure what you mean here. I don't think I can trigger any I/O at this > >> point in time, and hence I also couldn't try to trigger a fault. But if > >> the question is whether fault reporting at this time actually works, > >> then yes, I think so: This is during Dom0 construction, i.e. late enough > >> for fault reporting to be fully set up and enabled. > >> > > > > My point was that with your guess that the ignored bits are not > > ignored some VT-d faults should be triggered. If the reason why > > you cannot observe such faults is because they happened too > > early so no much can be shown on the screen then trying to > > setting those bits at much later point might get more shown to > > verify your guess. > > Pretty clearly there aren't any faults. And in fact my suspicion is > that the bits are used for addressing memory, and then the memory > access hangs (doesn't complete). > > > btw any progress since last post? How urgent do you want this > > feature in (compared to the issue that it may paper over)? > > Well, one way or another the issue needs to be dealt with for this > series to eventually go in. To be honest I hadn't expected that it > would still be pending ... >
Sorry I didn't get your meaning. Do you mean that you didn't expect that I haven't given r-b or that you haven't found time to root-cause this issue? Thanks Kevin
