On Tue, Jan 4, 2022 at 10:58 AM Jan Beulich <jbeul...@suse.com> wrote:
> When not holding the PoD lock across the entire region covering P2M > update and stats update, the entry count should indicate too large a > value in preference to a too small one, to avoid functions bailing early > when they find the count is zero. Hence increments should happen ahead > of P2M updates, while decrements should happen only after. Deal with the > one place where this hasn't been the case yet. > > Signed-off-by: Jan Beulich <jbeul...@suse.com> > --- > v2: Add comments. > --- > While it might be possible to hold the PoD lock over the entire > operation, I didn't want to chance introducing a lock order violation on > a perhaps rarely taken code path. > [No idea how I missed this 2 years ago, sorry for the delay] Actually I think just holding the lock is probably the right thing to do. We already grab gfn_lock() over the entire operation, and p2m_set_entry() ASSERTs gfn_locked_by_me(); and all we have to do to trigger the check is boot any guest in PoD mode at all; surely we have osstest tests for that? -George
