[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.