Messages in this thread | | | Subject | Re: [PATCH v3 12/21] KVM: X86: Implement ring-based dirty memory tracking | From | Paolo Bonzini <> | Date | Tue, 21 Jan 2020 11:24:56 +0100 |
| |
On 20/01/20 08:29, Peter Xu wrote: >>> >>> 00b (invalid GFN) -> >>> 01b (valid gfn published by kernel, which is dirty) -> >>> 1*b (gfn dirty page collected by userspace) -> >>> 00b (gfn reset by kernel, so goes back to invalid gfn) >>> That is 10b and 11b are equivalent. The kernel doesn't read that bit if >>> userspace has collected the page. > Yes "1*b" is good too (IMHO as long as we can define three states for > an entry). However do you want me to change to that? Note that I > still think we need to read the rest of the field (in this case, > "slot" and "gfn") besides the two bits to do re-protect. Should we > trust that unconditionally if writable?
I think that userspace would only hurt itself if they do so. As long as the kernel has a trusted copy of the indices, it's okay.
We have plenty of bits--x86 limits GFNs to 40 bits (52 bits maximum physical address). However, even on other architectures GFNs are limited to address space size - page shift (64-12).
Paolo
| |