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

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

>>>> 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.

Posted here
http://lists.xen.org/archives/html/xen-devel/2012-03/msg01982.html

(just making sure it doesn't slip through the cracks)
Andres

>
> Jan
>
>



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