On 5/2/2016 11:46 AM, Radim Krčmář wrote: > 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. > Got it. Thanks! -- 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
