On 06.11.2017 23:29, Janosch Frank wrote: > A guest can put DAT tables for a lower level guest in the same huge > segment as one of its prefixes. This would make it necessary for the > segment to be unprotected (because of the prefix) and protected > (because of the shadowing) at the same time. This is not possible in > this universe. > > Hence we split the affected huge segment, so we can protect on a > per-page basis. Such gmap segments are special and get a new software > bit, that helps us handling this edge case. I am thinking about another condition and am not sure yet if it is really a problem and already handled by this patch (if so, feel free to add it to the description :) ): G2 -> G3 page table and a contained G2 -> G3 page lying on same G1 huge page G1 runs G2 with huge pages. G2 runs G3 without huge pages, G1 creates shadow page tables for G3. G2 has no idea of huge pages, so it could happen that a page table from G2 -> G3 falls into the same G1 huge page as a G2->G3 backing page. Now, if we're unlucky, it can happen that this page table references that G3 page, lying on the same G1 huge page. G1 will create a shadow page table, protecting access to this huge page (do maintain the shadow properly). What will happen when G3 tries to write to this page: 1. Shadow page table in G1 is built, huge page is protected in g2 gmap. 2. Part of that huge page is to be used in the shadow page table with write access. This huge page is protected but we need write access, we need to fixup. 3. Fixing up will invalidate the shadow page table. IOW, G3 will never make progress. -- Thanks, David / dhildenb -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
