|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] odd gfn number checking in p2m.c
I think the 0x55555 checks are a bit of a hack. It just happens to be the
value we initialise the m2p table to at boot time. Afaik we don't initialise
free mfns back to 0x555...55 in the m2p, so over time that value will become
less frequent in the m2p.
-- Keir
On 19/09/2010 16:49, "Olaf Hering" <olaf@xxxxxxxxx> wrote:
>
> Hello,
>
> how can a gfn become 0x555555 as checked in
> p2m.c:guest_physmap_add_entry() and p2m_alloc_table()?
> Looking further in p2m.c, audit_p2m() checks only for a 32bit value.
>
> So where is that magic number set, and why is it not a define to
> simplify grepping for users of that value?
>
> Olaf
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Previous by Date: |
[Xen-devel] odd gfn number checking in p2m.c, Olaf Hering |
Next by Date: |
[Xen-devel] Xen 4.0.1, tap vs tap2, blktap2 documentation, and gentoo-xen-kernel problem, Fajar A. Nugraha |
Previous by Thread: |
[Xen-devel] odd gfn number checking in p2m.c, Olaf Hering |
Next by Thread: |
[Xen-devel] Xen 4.0.1, tap vs tap2, blktap2 documentation, and gentoo-xen-kernel problem, Fajar A. Nugraha |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|
|
|