Re: [PATCH 3/6] KVM: Dirty memory tracking for performant checkpointing and improved live migration

["Radim Krčmář" <rkrcmar@redhat.com>]

2016-05-02 15:24+0000, Cao, Lei:
> On 4/29/2016 2:19 PM, Radim Krčmář wrote:
> > 2016-04-28 19:58+0000, Cao, Lei:
>>> It should be noted that what is saved on the dirty list is 
>>> (mem slot id|offset), not gfn.
>> 
>> Current compaction causes a problem.  Slot id is u32, but gnflist stores
>> only bottom 16 bits while upper 16 contain important address space.
>> And 48 bit offset isn't enough for GPA sizes above 60 bits.
>> 
>> 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.)
>> 
> 
> memory slot id is currently defined as short. If I understand correctly,
> you are saying that it'll become u32 when per-vcpu address space arrives,
> 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 to
store the address space, but you are interested in a userspace
interface, which uses u32 slot_id to identify a slot.