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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
