On 04/18/2018 11:53 AM, Jan Beulich wrote: >>>> On 18.04.18 at 12:23, <george.dun...@citrix.com> wrote: >> That is, sensible input looks like: >> * start < end >> * For hostp2ms: >> - start <= max_mapped_pfn >> - either end <= max_mapped_pfn, or end == ~0UL >> (But for altp2ms, start or end > max_mapped_pfn is fine.) > > So I guess that's part of the difficulty I'm having with the original > suggestion: > Why would such input be okay for alternative p2m-s?
Because altp2ms use max_mapped_pfn to limit what gets propagated to individual altp2m views when the host p2m is updated. See p2m.c:p2m_altp2m_propagate_change(). The motivation for this patch can be found in marc.info/?i=<8fb5e427-a0e6-79bd-3bae-5fcb6aba4...@bitdefender.com> . In summary: - Razvan had started keeping more altp2m stuff 'in sync' with the hostp2m, including max_mapped_pfn - I suggested that was unnecessary, and would reverse the 'filtering' effect that had obviously been put there intentionally - Razvan posted the above stack trace in which not setting max_mapped_pfn triggered an ASSERT - I suggested "fixing" p2m_change_type_range() to handle start > max_mapped_pfn instead You could argue that this 'filtering' is unnecessary, but at the moment that's the way things work; whether it should be changed is a different discussion. You could also argue that we should be doing the filtering before calling p2m_change_type_range(), but it seems to me that this is the right level to do the filtering. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
