Re: [PATCH V2] pv-grub: Fix for incorrect dom->p2m_host[] list initialization

From: Samuel Thibault
Date: Tue Apr 26 2011 - 16:58:19 EST


Daniel Kiper, le Tue 26 Apr 2011 20:56:49 +0200, a écrit :
> New time optimized version.
>
> After a lot of debugging and long reading of Linux Kernel and Xen code
> finally I killed deeply hidden bug in pv-grub. Details below.
> Additionally, I am CC'ing this e-mail to LKML because this issue
> looks like Linux Kernel problem, however, it is not.
>
> This patch applies to Xen Ver. 4.0, Xen Ver. 4.1 and Xen unstable tree.
>
> # HG changeset patch
> # User dkiper@xxxxxxxxxxxx
> # Date 1303843062 -7200
> # Node ID c4c2919afe9727e107ad3b862619b40d4731d3e4
> # Parent dbf2ddf652dc3dd927447e79ef4bc586de55d708
> Introduction of Linux Kernel git commit ceefccc93932b920a8ec6f35f596db05202a12fe
> (x86: default CONFIG_PHYSICAL_START and CONFIG_PHYSICAL_ALIGN to 16 MB) revealed
> deeply hidden bug in pv-grub. During kernel load stage dom->p2m_host[] list has
> been incorrectly initialized.
>
> At the beginning of kernel load stage dom->p2m_host[] list is populated with
> current PFN->MFN layout. Later during memory allocation (memory is allocated
> page by page in kexec_allocate()) page order is changed to establish linear
> layout in new domain. It is done by exchanging subsequent MFNs with newly
> allocated MFNs. dom->p2m_host[] list is indexed by currently requested PFN
> (it is incremented from 0) and PFN of newly allocated paged. If PFN of newly
> allocated page is less than currently requested PFN then earlier allocated
> MFN is overwritten which leads to domain crash later. This patch corrects
> that issue. If PFN of newly allocated page is less then currently requested
> PFN then relevant PFN/MFN pair is properly calculated and usual exchange
> occurs later.
>
> Signed-off-by: Daniel Kiper <dkiper@xxxxxxxxxxxx>

Reviewed-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/