On 22.01.2018 12:46, David Hildenbrand wrote: > On 13.12.2017 13:53, Janosch Frank wrote: >> For later migration of huge pages we want to write-protect guest >> PMDs. While doing this, we have to make absolutely sure, that the >> guest's lowcore is always accessible when the VCPU is running. With >> PTEs, this is solved by marking the PGSTEs of the lowcore pages with >> the invalidation notification bit and kicking the guest out of the SIE >> via a notifier function if we need to invalidate such a page. >> >> With PMDs we do not have PGSTEs or some other bits we could use in the >> host PMD. Instead we pick one of the free bits in the gmap PMD. Every >> time a host pmd will be invalidated, we will check if the respective >> gmap PMD has the bit set and in that case fire up the notifier. >> >> In the first step we only support setting the invalidation bit, but we >> do not support restricting access of guest pmds. It will follow >> shortly. > > I am wondering if we could avoid having invalidation bits on PMDs > completely by always splitting up a PMD huge page into PTEs. > > I assume this would make the code easier - as we need split up of PMDs > either way when protecting for the shadow gmap. > > This would imply that also our notification handler only has to be > called for 4k pages, which also makes that part easier. Except for 1MB shadowed segments which still need an invalidation handler. > > This would mean, that the 1MB segments where the prefixes live would > always be split into 4k pages - but do we care? Hmm, I currently don't see a medium to huge benefit from it. > > I somehow dislike that somebody registers a notifier for some subregion > (e.g. 8k) but gets notified about a huge page (1mb). > > Opinions? Well, if you start bending reality to your will, things get messy. Having two tables with different depths is a risk, as I can't be sure if at some point a common code function will touch a split pte and set a problematic value. But then again, we already do that anyhow. As I'd need to rearrange patches again, I'd either do that after this series or leave it be.
Attachment:
signature.asc
Description: OpenPGP digital signature
