Clarification for patch 7
Hi Christoffer, Marc -
in stage2_dissolve_pmd() CONFIG_SMP is
unnecessary. At the time huge page is write protected, until it faults and is cleared any page in the range may be dirty not just the gpa access that caused the fault.
The comment on another CPU is wrong, I
confused myself while testing it should not be possible for another CPU to write to same PMD range while another is handling its PMD fault. I ran a test with only initrd which exposed an issue using my
test scenario, QEMU appears fine.
It also depends on user space if you first turn on logging, do pre-copy then marking just the page is enough. It's hard to interpret the API in this case. It just says dirty pages since the last call.
That patch could be resent without upsetting the rest.
- Mario
Quoted 14 lines · Mario Smarduch
Hi Christoffer, Marc -
instage2_dissolve_pmd()CONFIG_SMPis
unnecessary. At the time huge page is write protected, until it faults and is cleared any page in the range may be dirty not just the gpa access that caused the fault.The comment on another CPU is wrong, I
confused myself while testing it should not be possible for another CPU to write to same PMD range while another is handling its PMD fault. I ran a test with only initrd which exposed an issue using my
test scenario, QEMU appears fine.
Quoted 9 lines
It also depends on user space if you first turn on logging, do pre-copy then marking just the page is enough. It's hard to interpret the API in this case. It just says dirty pages since the last call.
That patch could be resent without upsetting the rest.
I think I raised all these issues on your patch, let's discuss it there.
-Christoffer