Re: [Xen-devel] [PATCH] x86/p2m: fixed p2m_change_type_range() start / end check

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 04/18/2018 11:53 AM, Jan Beulich wrote:
>>>> On 18.04.18 at 12:23, <george.dunlap@xxxxxxxxxx> 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-5fcb6aba4613@xxxxxxxxxxxxxxx> .
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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel