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

Andres

>
>> I'm happy to do it this way but I guess maybe it slows down paths that
>> don't need the mask.
>
> Yes, that was one of the concerns - less because of the slowdown,
> but more because the generated code then becomes even worse to
> look at (which at least I happen to be required to do now and then,
> albeit admittedly less frequently over time, i.e. as the general code
> quality improves).
>
> Jan
>
>



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