From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andres Lagar-Cavilla" Subject: Re: [PATCH 2 of 3] Clip mfn to allowable width when building a PTE Date: Tue, 27 Mar 2012 08:21:24 -0700 Message-ID: References: <4F6AFC6B020000780007A1CF@nat28.tlf.novell.com> <20120322105011.GD37468@ocelot.phlegethon.org> <4F6B14D5020000780007A323@nat28.tlf.novell.com> <281f5f4c518c5e21f19814c03a8845e2.squirrel@webmail.lagarcavilla.org> <4F6B53DA020000780007A4C6@nat28.tlf.novell.com> Reply-To: andres@lagarcavilla.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F6B53DA020000780007A4C6@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: olaf@aepfle.de, keir@xen.org, andres@gridcentric.ca, Tim Deegan , xen-devel@lists.xen.org, wei.wang2@amd.com, hongkaixing@huawei.com, adin@gridcentric.ca List-Id: xen-devel@lists.xenproject.org >>>> On 22.03.12 at 15:54, "Andres Lagar-Cavilla" >>>> wrote: >>>>>> On 22.03.12 at 11:50, Tim Deegan wrote: >>>> At 09:18 +0000 on 22 Mar (1332407899), Jan Beulich wrote: >>>>> >>> On 21.03.12 at 20:22, Andres Lagar-Cavilla >>>>> 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 > >