On Sat, Dec 14, 2019 at 08:57:26AM +0100, Paolo Bonzini wrote: > On 13/12/19 21:23, Peter Xu wrote: > >> What is the benefit of using u16 for that? That means with 4K pages, you > >> can share at most 256M of dirty memory each time? That seems low to me, > >> especially since it's sufficient to touch one byte in a page to dirty it. > >> > >> Actually, this is not consistent with the definition in the code ;-) > >> So I'll assume it's actually u32. > > Yes it's u32 now. Actually I believe at least Paolo would prefer u16 > > more. :) > > It has to be u16, because it overlaps the padding of the first entry. Hmm, could you explain? Note that here what Christophe commented is on dirty_index, reset_index of "struct kvm_dirty_ring", so imho it could really be anything we want as long as it can store a u32 (which is the size of the elements in kvm_dirty_ring_indexes). If you were instead talking about the previous union definition of "struct kvm_dirty_gfns" rather than "struct kvm_dirty_ring", iiuc I've moved those indices out of it and defined kvm_dirty_ring_indexes which we expose via kvm_run, so we don't have that limitation as well any more? -- Peter Xu
