Hi Catalin, I have some questions after deep reading your patch https://patchwork.kernel.org/patch/8824261/ which enables hardware updates of the Access Flag for Stage 2 page tables. I notice that at the bottom of commit message, you said the following words: "After some digging through the KVM code, I concluded that hardware DBM (dirty bit management) support is not feasible for Stage 2. A potential user would be dirty logging but this requires a different bitmap exposed to Qemu and, to avoid races, the stage 2 mappings need to be mapped read-only on clean, writable on fault. This assumption simplifies the hardware Stage 2 AF support." I have three questions here. 1. I do not understand the reason well about "not feasible". Does the main reason for this is the "races" you referred? 2. What does the "races" refer to? Do you mean the races between [hardware S2 DBM] and [dirty information collection that executed by KVM]? During VM live migration, Qemu will send dirty page iteratively and finally stop VM when dirty pages is not too much. We may miss dirty pages during each iteration before VM stop, but there are no races after VM stop, so we won't miss dirty pages finally. It seems that "races" is not a convinced reason for "not feasible". 3. You said that disable hardware S2 DBM support can simplify the hardware S2 AF support. Could you please explain the reason in detail? Expect your reply. Many Thanks! Thanks, Keqian. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
