Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 7 Jul 2020 16:38:23 -0400
From:   Peter Xu <peterx@redhat.com>
To:     Sean Christopherson <sean.j.christopherson@intel.com>
Cc:     kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        "Dr . David Alan Gilbert" <dgilbert@redhat.com>,
        Andrew Jones <drjones@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        "Michael S . Tsirkin" <mst@redhat.com>,
        Jason Wang <jasowang@redhat.com>,
        Kevin Tian <kevin.tian@intel.com>
Subject: Re: [PATCH v10 02/14] KVM: Cache as_id in kvm_memory_slot
Message-ID: <20200707203823.GI88106@xz-x1>
References: <20200601115957.1581250-1-peterx@redhat.com>
 <20200601115957.1581250-3-peterx@redhat.com>
 <20200702230849.GL3575@linux.intel.com>
 <20200703184122.GF6677@xz-x1>
 <20200707061732.GI5208@linux.intel.com>
 <20200707195009.GE88106@xz-x1>
 <20200707195658.GK20096@linux.intel.com>
 <20200707201508.GH88106@xz-x1>
 <20200707202623.GM20096@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200707202623.GM20096@linux.intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jul 07, 2020 at 01:26:23PM -0700, Sean Christopherson wrote:
> On Tue, Jul 07, 2020 at 04:15:08PM -0400, Peter Xu wrote:
> > On Tue, Jul 07, 2020 at 12:56:58PM -0700, Sean Christopherson wrote:
> > > > > It's a single line of code, and there's more than one
> > > > > "shouldn't" in the above.
> > > > 
> > > > If you want, I can both set it and add the comment.  Thanks,
> > > 
> > > Why bother with the comment?  It'd be wrong in the sense that the as_id is
> > > always valid/accurate, even if npages == 0.
> > 
> > Sorry I'm confused.. when npages==0, why as_id field is meaningful?  Even if
> > the id field is meaningless after the slot is successfully removed, or am I
> > wrong?
> > 
> > My understanding is that after your dynamic slot work, we'll only have at most
> > one extra memslot that was just removed, and that slot should be meaningless as
> > a whole.  Feel free to correct me.
> 
> Your understanding is correct.  What I'm saying is that if something goes
> awry and the memslots need to be debugged, having accurate info for that one
> defunct memslot could be helpful, if only to not confuse a future debugger
> that doesn't fully understand memslots or address spaces.  Sure, it could be
> manually added back in for debug, but it's literally a single line of code
> to carry and it avoids the need for a special comment.

Sure, will do.  But again, I hope you allow me to add at least some comment.
To me, it's still weird to set these in a destroying memslot...

-- 
Peter Xu