RE: [PATCH v3 20/23] VT-d: free all-empty page tables

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Monday, March 14, 2022 3:33 PM
> 
> On 14.03.2022 05:01, Tian, Kevin wrote:
> >> From: Jan Beulich <jbeulich@xxxxxxxx>
> >> Sent: Friday, February 18, 2022 4:31 PM
> >>
> >> On 18.02.2022 06:20, Tian, Kevin wrote:
> >>>> From: Jan Beulich <jbeulich@xxxxxxxx>
> >>>> 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 <jbeulich@xxxxxxxx>
> >>>> ---
> >>>> 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