On 14.02.2018 16:15, David Hildenbrand wrote: >>> So what can happen is (please correct me if I'm wrong) >>> >>> a) PMD is split. SSKE writes storage key with _PAGE_CHANGED, ends up in >>> PGSTE. The real storage key doesn't match the requested storage key. >>> b) Split PMD is replaced, triggers a removal of the split PMD -> >>> gmap_pmd_split_free(pmdp). The requested storage key is partially lost >>> (pgste removed). >>> c) PMD is mapped in again. If the guest reads the storage key now, the >>> value is wrong. >> >> Yes, we loose GR and GC. >> Is there a case when the VM is running, where this would happen? > > It should already happen when migrating storage keys. The fake PGSTE are > not considered in get_guest_storage_key(). Yes, that should break it reliably :) > > For the other parts, the original user space PMD would have to be > changed. A simply mprotect() should achieve that. Or dirty tracking. But > not sure how that applies to huge pages at all. I've only seen that 'till now when the VM is already dead and the kernel cleans up. Anyhow, you already proposed a solution, so there's no sense in defending against corner cases.
Attachment:
signature.asc
Description: OpenPGP digital signature
