Content-Type: multipart/mixed; boundary="===============3176616092876891833==" MIME-Version: 1.0 From: Michael S. Tsirkin To: kbuild-all@lists.01.org Subject: Re: [PATCH v5 05/14] KVM: X86: Implement ring-based dirty memory tracking Date: Tue, 10 Mar 2020 10:11:30 -0400 Message-ID: <20200310101039-mutt-send-email-mst@kernel.org> In-Reply-To: <20200310140921.GD326977@xz-x1> List-Id: --===============3176616092876891833== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Mar 10, 2020 at 10:09:21AM -0400, Peter Xu wrote: > On Tue, Mar 10, 2020 at 02:31:55AM -0400, Michael S. Tsirkin wrote: > > On Mon, Mar 09, 2020 at 05:35:54PM -0400, Peter Xu wrote: > > > I'll probably also > > > move KVM_DIRTY_LOG_PAGE_OFFSET=3D=3D0 definition to uapi/linux/kvm.h. > > = > > = > > IMHO KVM_DIRTY_LOG_PAGE_OFFSET is kind of pointless anyway - = > > we won't be able to move data around just by changing the > > uapi value since userspace isn't > > recompiled when kernel changes ... > = > Yes I think we can even drop this KVM_DIRTY_LOG_PAGE_OFFSET=3D=3D0 > definition. IMHO it's only a matter of whether we would like to > directly reference this value in the common code (e.g., for kernel > virt/kvm_main.c) or we want quite a few of this instead: > = > #ifdef KVM_DIRTY_LOG_PAGE_OFFSET > .. > #endif Hmm do other arches define it to a different value? Maybe I'm confused. If they do then it makes sense. > I slightly prefer to not use lots of "#ifdef"s so I chose to make sure > it's defined. However I've no strong opinion on this either. So I'm > open to change that if anyone insists with some reasons. > = > Thanks, > = > -- = > Peter Xu --===============3176616092876891833==--