From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Moraga Subject: Re: crash on boot with 4.6.1 on fedora 24 Date: Tue, 17 May 2016 14:58:15 -0600 Message-ID: <573B85E7.4080906@riseup.net> References: <572FC2F9.3060200@riseup.net> <57307DD402000078000E9622@prv-mh.provo.novell.com> <5730A447.3010505@riseup.net> <5730CE7E02000078000E9A8A@prv-mh.provo.novell.com> <5730BD86.6080407@riseup.net> <5730C5A4.9040008@oracle.com> <5730C73E.8030007@riseup.net> <5730D994.6050100@oracle.com> <5731A87502000078000E9D8C@prv-mh.provo.novell.com> <5731E4A5.30906@oracle.com> <5732050602000078000EA230@prv-mh.provo.novell.com> <5731FBEA.4010202@suse.com> <57321BFA02000078000EA3C2@suse.com> <573201AE.1010306@suse.com> <57320DD3.3030805@oracle.com> <5732C7D0.4050907@suse.com> <5732EEBF02000078000EA613@suse.com> <5732D893.7000503@suse.com> <5733068D.5050604@citrix.com> <573B3484.1080603@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4685852588526778875==" Return-path: In-Reply-To: <573B3484.1080603@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: David Vrabel , Juergen Gross , Jan Beulich Cc: Boris Ostrovsky , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============4685852588526778875== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oITw5xtMXlcPfvqvU11r8OgJ7PnAI30Ls" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oITw5xtMXlcPfvqvU11r8OgJ7PnAI30Ls Content-Type: multipart/mixed; boundary="Ext3l0SlM5hJHKOmve7wOBOaw9VkTb7XJ" From: Kevin Moraga To: David Vrabel , Juergen Gross , Jan Beulich Cc: Boris Ostrovsky , xen-devel@lists.xen.org Message-ID: <573B85E7.4080906@riseup.net> Subject: Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24 References: <572FC2F9.3060200@riseup.net> <57307DD402000078000E9622@prv-mh.provo.novell.com> <5730A447.3010505@riseup.net> <5730CE7E02000078000E9A8A@prv-mh.provo.novell.com> <5730BD86.6080407@riseup.net> <5730C5A4.9040008@oracle.com> <5730C73E.8030007@riseup.net> <5730D994.6050100@oracle.com> <5731A87502000078000E9D8C@prv-mh.provo.novell.com> <5731E4A5.30906@oracle.com> <5732050602000078000EA230@prv-mh.provo.novell.com> <5731FBEA.4010202@suse.com> <57321BFA02000078000EA3C2@suse.com> <573201AE.1010306@suse.com> <57320DD3.3030805@oracle.com> <5732C7D0.4050907@suse.com> <5732EEBF02000078000EA613@suse.com> <5732D893.7000503@suse.com> <5733068D.5050604@citrix.com> <573B3484.1080603@citrix.com> In-Reply-To: <573B3484.1080603@citrix.com> --Ext3l0SlM5hJHKOmve7wOBOaw9VkTb7XJ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/17/2016 09:11 AM, David Vrabel wrote: > On 11/05/16 11:16, David Vrabel wrote: >> Why don't we get the RW bits correct when making the pteval when we >> already have the pfn, instead trying to fix it up afterwards. > Kevin, can you try this patch. Yes :D. The patch is working fine. I only got this warning while compiling: WARNING: arch/x86/xen/built-in.o(.text+0x257d): Section mismatch in reference from the variable __raw_callee_save_xen_make_pte_init to the function .init.text:xen_make_pte_init() The function __raw_callee_save_xen_make_pte_init() references the function __init xen_make_pte_init(). This is often because __raw_callee_save_xen_make_pte_init lacks a __init annotation or the annotation of xen_make_pte_init is wrong. > > David > > 8<----------------- > x86/xen: avoid m2p lookup when setting early page table entries > > When page tables entries are set using xen_set_pte_init() during early > boot there is no page fault handler that could handle a fault when > performing an M2P lookup. > > In 64 guest (usually dom0) early_ioremap() would fault in > xen_set_pte_init() because an M2P lookup faults because the MFN is in > MMIO space and not mapped in the M2P. This lookup is done to see if > the PFN in in the range used for the initial page table pages, so that > the PTE may be set as read-only. > > The M2P lookup can be avoided by moving the check (and clear of RW) > earlier when the PFN is still available. > > [ Not entirely happy with this as the 32/64 bit paths diverge even > more. Is there some way to unify them instead? ] > > Signed-off-by: David Vrabel > --- > arch/x86/xen/mmu.c | 28 +++++++++++++++++++++------- > 1 file changed, 21 insertions(+), 7 deletions(-) > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index 478a2de..897fad4 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -1562,7 +1562,7 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_= t > pte) > return pte; > } > #else /* CONFIG_X86_64 */ > -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte) > +static pteval_t __init mask_rw_pte(pteval_t pte) > { > unsigned long pfn; > > @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep, > pte_t pte) > * page tables for mapping the p2m list, too, and page tables MUST be= > * mapped read-only. > */ > - pfn =3D pte_pfn(pte); > + pfn =3D (pte & PTE_PFN_MASK) >> PAGE_SHIFT; > if (pfn >=3D xen_start_info->first_p2m_pfn && > pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_fram= es) > - pte =3D __pte_ma(pte_val_ma(pte) & ~_PAGE_RW); > + pte &=3D ~_PAGE_RW; > > return pte; > } > @@ -1600,13 +1600,26 @@ static pte_t __init mask_rw_pte(pte_t *ptep, > pte_t pte) > * so always write the PTE directly and rely on Xen trapping and > * emulating any updates as necessary. > */ > +__visible __init pte_t xen_make_pte_init(pteval_t pte) > +{ > +#ifdef CONFIG_X86_64 > + pte =3D mask_rw_pte(pte); > +#endif > + pte =3D pte_pfn_to_mfn(pte); > + > + if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT =3D=3D INVALID_P2M_ENTRY) > + pte =3D 0; > + > + return native_make_pte(pte); > +} > +PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init); > + > static void __init xen_set_pte_init(pte_t *ptep, pte_t pte) > { > +#ifdef CONFIG_X86_32 > if (pte_mfn(pte) !=3D INVALID_P2M_ENTRY) > pte =3D mask_rw_pte(ptep, pte); > - else > - pte =3D __pte_ma(0); > - > +#endif > native_set_pte(ptep, pte); > } > > @@ -2407,6 +2420,7 @@ static void __init xen_post_allocator_init(void) > pv_mmu_ops.alloc_pud =3D xen_alloc_pud; > pv_mmu_ops.release_pud =3D xen_release_pud; > #endif > + pv_mmu_ops.make_pte =3D PV_CALLEE_SAVE(xen_make_pte); > > #ifdef CONFIG_X86_64 > pv_mmu_ops.write_cr3 =3D &xen_write_cr3; > @@ -2455,7 +2469,7 @@ static const struct pv_mmu_ops xen_mmu_ops > __initconst =3D { > .pte_val =3D PV_CALLEE_SAVE(xen_pte_val), > .pgd_val =3D PV_CALLEE_SAVE(xen_pgd_val), > > - .make_pte =3D PV_CALLEE_SAVE(xen_make_pte), > + .make_pte =3D PV_CALLEE_SAVE(xen_make_pte_init), > .make_pgd =3D PV_CALLEE_SAVE(xen_make_pgd), > > #ifdef CONFIG_X86_PAE --=20 Sincerely, Kevin Moraga PGP: F258EDCB Fingerprint: 3915 A5A9 959C D18F 0A89 B47E FB4B 55F5 F258 EDCB --Ext3l0SlM5hJHKOmve7wOBOaw9VkTb7XJ-- --oITw5xtMXlcPfvqvU11r8OgJ7PnAI30Ls Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXO4XoAAoJEIr57EYHp2ROXlQP/2/Iw0z5yl8kfm0AsG39O8iU 6Ae53h6CXnL8Ad3llgVM+Z+yMpkrESrNaULyQDrudHm35l0c4GVccco5DkS3PT6E A8+86HIXT+/5j/YogGobTK4dvxgl3DNxzi8fcf7+mww0wphpST7uXyVMu63AdkKT 8qasJWm/bNn5Z0j0HNAsEIbmdt+yhiYZjBTQy95C/RKbYgT7doyXZuQe4Ptjw+5o 85zkL1LKwM0DEavAS0SojlzgtZ6LzPIYlVe2qTeRZFMarUyTCOrzsWaGbqyht5/3 YCyY88HKTdvoMji/NkGWpX4fdzDyQ9q4OmJfXn5nSCoBL4EMSYryyU7jboUmS7wC G2NwHuBNGTJKUfIZflhtk84j2EEo5JpQ7m3YAM2ySZDuE7wO/+7DH0rzYxgEx0al PyBK/LBa7IMtMC4UHdLXPQgyRbu8SV2yr+fUOEVLWy4RRFfdlJpENF9X8vKLPkVM +EZm1QVIqz946UE+jVM6TVh1yeqQrXh/QOn13tPal0rJhloAqb3hTFXahL7d3ZOy GK284MFxAm7xW3Veoh8ymk/KQinMHeN8nkfoc39wSEl6bP2jRcVd4Rv/ra0Toptg tsx1I/X2h9zTw5S2SiY8ukCrAX9shOwxwvKF6rsol8hIIUl7keuq9A1DER5S36P9 b7rXw3P7lb2fmSGfHY/z =qdGg -----END PGP SIGNATURE----- --oITw5xtMXlcPfvqvU11r8OgJ7PnAI30Ls-- --===============4685852588526778875== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============4685852588526778875==--