From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH 3/6] KVM: Dirty memory tracking for performant checkpointing and improved live migration Date: Mon, 2 May 2016 17:46:08 +0200 Message-ID: <20160502154608.GB24741@potion> References: <201604261855.u3QItn85024244@dev1.sn.stratus.com> <33d8668e-2bba-af91-069e-6452609a6ff0@linux.intel.com> <20160429181911.GA2687@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "Huang, Kai" , Paolo Bonzini , "kvm@vger.kernel.org" To: "Cao, Lei" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56640 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753941AbcEBPqM (ORCPT ); Mon, 2 May 2016 11:46:12 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 2016-05-02 15:24+0000, Cao, Lei: > On 4/29/2016 2:19 PM, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: > > 2016-04-28 19:58+0000, Cao, Lei: >>> It should be noted that what is saved on the dirty list is=20 >>> (mem slot id|offset), not gfn. >>=20 >> Current compaction causes a problem. Slot id is u32, but gnflist st= ores >> only bottom 16 bits while upper 16 contain important address space. >> And 48 bit offset isn't enough for GPA sizes above 60 bits. >>=20 >> Compaction can reserve up to PAGE_SHIFT bits. KVM must BUILD_BUG_ON= () >> if KVM_ADDRESS_SPACE_NUM and KVM_MEM_SLOTS_NUM don't fit. (We'll be >> this reworking compaction as soon as per-vcpu address spaces arrive, >> because KVM_MEM_SLOTS_NUM already takes 9 bits.) >>=20 >=20 > memory slot id is currently defined as short. If I understand correct= ly, > you are saying that it'll become u32 when per-vcpu address space arri= ves, > right? It's certainly an issue for the current compaction. I'll need = to > rework it. slot_id was always u32. Before address spaces, it had interval [0, KVM_MEM_SLOTS_NUM), so u16 was enough. After address spaces, slot_id has two components as_id: [0, KVM_ADDRESS_SPACE_NUM) as_slot_id: [0, KVM_MEM_SLOTS_NUM) and slot_id is as_id << 16 | as_slot_id This means you shouldn't look only at bottom 16 bits of slot_id. 'id' in struct kvm_memory_slot is only short, because it doesn't need t= o store the address space, but you are interested in a userspace interface, which uses u32 slot_id to identify a slot.