Re: [Xen-devel] [PATCH 2 of 3] Clip mfn to allowable width when building a PTE

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.03.12 at 15:54, "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx> 
>>> wrote:
>>>>> On 22.03.12 at 11:50, Tim Deegan <tim@xxxxxxx> wrote:
>>> At 09:18 +0000 on 22 Mar (1332407899), Jan Beulich wrote:
>>>>  >>> On 21.03.12 at 20:22, Andres Lagar-Cavilla
>>>> <andres@xxxxxxxxxxxxxxxx> wrote:
>>>> > xen/include/asm-x86/page.h |  12 ++++++++----
>>>> >  1 files changed, 8 insertions(+), 4 deletions(-)
>>>> >
>>>> >
>>>> > Otherwise, INVALID_MFN tramples over high order bits used for
>>>> additional
>>>> > flags.
>>>>
>>>> But is passing INVALID_PFN into these macros valid/sensible in the
>>>> first
>>>> place?
>>>
>>> The p2m code uses pte layout even for entries that don't have the
>>> _PAGE_PRESENT bit set.  We can:
>>>  - mask out in these macros, making everything safe;
>>>  - make new macros just for p2m code;
>>>  - rewrite p2m callers not to use INVALID_MFN; or
>>>  - have the p2m code explicitly replace INVALID_MFN with some other
>>>    value when callers specify it.
>>
>> As the transformation backwards doesn't yield INVALID_MFN anyway,
>> I'd prefer one of those options.
> 
> The whole issue originates in p2m-pt, which uses l1e_from_pfn with
> INVALID_PFN -- sometimes. My favourite option would be to replace that
> with p2m_l1e_from_pfn, which does the masking of the pfn and then calls
> l1e_from_pfn.
> 
> Limits the masking to the only places where it is relevant. If that's ok
> with you I'll prepare and resend.

Yes, that sounds good to me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel