WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH] xen/x86: replace order-based range checking of M

To: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] xen/x86: replace order-based range checking of M2P table by linear one
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 17 Aug 2011 07:58:10 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 16 Aug 2011 23:58:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E4AACD6.8000108@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4E4A95CD0200007800051824@xxxxxxxxxxxxxxxxxxxx> <4E4AACD6.8000108@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 16.08.11 at 19:45, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> On 08/16/2011 07:07 AM, Jan Beulich wrote:
>> +#ifdef CONFIG_X86_32
>> +    if (machine_to_phys_mapping + machine_to_phys_nr
>> +        < machine_to_phys_mapping)
> 
> I'd prefer extra parens around the + just to make it very clear.  Is
> this kind of overflow check fully defined, or could the compiler find
> some way of screwing it up?

This check is fully defined afaik, ...

>> +            machine_to_phys_nr = (unsigned long *)NULL
>> +                                 - machine_to_phys_mapping;
> 
> Is the machine_to_phys_mapping array guaranteed to end at the end of the
> address space?  And I think a literal '0' there would make it a bit
> clearer what's going on, rather than invoking all the stuff that NULL
> implies.

... and this operation is as long as machine_to_phys_mapping is
aligned to a long boundary (which we know it is).

machine_to_phys_mapping not necessarily ends at the end of address
space (it never will on a 32-bit hypervisor, and the 64-bit one puts a
2Mb guard page at the end), but the purpose here is not to determine
a precise machine_to_phys_nr, but just to avoid overflow, since the
number reported by the hypervisor isn't necessarily precise.

But wait, only on x86-64 it's possibly much larger than the actual
number of entries, while what a 32-bit kernel gets to see (no matter
whether running on a 32- or 64-bit hypervisor) should really never
itself result in an overflow (only the previous order-based calculation
could), so it should even be okay to make this a BUG_ON(). I may
give this a try, and come up with an incremental patch (but I don't
see a pressing need to re-spin this one).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>