From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [Xen-devel] pvgrub2 is merged Date: Fri, 7 Nov 2014 15:20:53 +0000 Message-ID: References: <527EA084.6000706@gmail.com> <52987A43.9070806@m2r.biz> <52987D7F.3050006@gmail.com> <52988F86.6050008@m2r.biz> <529DB2F1.4080509@m2r.biz> <529DB363.7080003@gmail.com> <529DBED9.80105@m2r.biz> <529DC07E.8000201@gmail.com> <529DE3FD.90002@m2r.biz> <529DF9D5.2060301@gmail.com> <529E03FB.90603@m2r.biz> <52A1B0CB.3000705@m2r.biz> <52A1B5E8.5090709@gmail.com> <52A1E2CD.9030002@m2r.biz> <52A1E56E.3070105@gmail.com> <52A1EBAB.5090006@m2r.biz> <52A2F341.9010606@gmail.com> <52A5961A.2010608@m2r.biz> <52B02B13.1000103@m2r.biz> <52B02F84.6070403@gmail.com> <52B04D6E.3070700@m2r.biz> <52B0527C.40104@gmail.com> <52B057BD.8070701@m2r.biz> <52B05AF1.1040508@gmail.com> <52B05B5C.1080901@m2r.biz> <52B06131.8040809@m2r.biz> <52B1B82D.9050501@gmail.com> <52B20392.9090001@gmail.com> <52B434AC.7090905@gmail.com> Reply-To: The development of GNU GRUB Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1342847746-475817987-1415373653=:22875" Return-path: In-Reply-To: <52B434AC.7090905@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: grub-devel-bounces+gcbgd-grub-devel=m.gmane.org@gnu.org Sender: grub-devel-bounces+gcbgd-grub-devel=m.gmane.org@gnu.org To: =?UTF-8?Q?Vladimir_'=CF=86-coder=2Fphcoder'_Serbinenko?= Cc: The development of GRUB 2 , Fabio Fantoni , xen-devel , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org --1342847746-475817987-1415373653=:22875 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: QUOTED-PRINTABLE Hello Vladimir, sorry to resurrect an old thread and to top-post, but I noticed that in upstream grub the xenfb driver has been reverted. Is that because of this bug? If so, you should know that the bug has been fixed in QEMU. Thanks, Stefano On Fri, 20 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > On 19.12.2013 12:54, Stefano Stabellini wrote: > > On Wed, 18 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > >> On 18.12.2013 20:39, Stefano Stabellini wrote: > >>> On Wed, 18 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote= : > >>>> On 17.12.2013 15:35, Fabio Fantoni wrote: > >>>>> Il 17/12/2013 15:10, Fabio Fantoni ha scritto: > >>>>>> Il 17/12/2013 15:08, Vladimir '=CF=86-coder/phcoder' Serbinenko ha= scritto: > >>>>>>>> Thanks. > >>>>>>>> Now there is another error, probably introduced by xenfb support= : > >>>>>>>> > >>>>>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest? > >>>>>> > >>>>>> 64 bit > >>>>> > >>>>> I did "git reset --hard" to commit "Remove grub_bios_interrupt on > >>>>> coreboot." and then I applied only > >>>>> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation.= " > >>>>> commit. > >>>>> Now the Sid domU boot correctly, therefore the regression is caused= by > >>>>> "xenfb" or "xen grants to v1" commit, should I find the exact commi= t > >>>>> that causes that problem or these informations are enough for you? > >>>> > >>>> It's because of vfb. Apparently vfb framebuffer stays mapped as rw e= ven > >>>> after vfb shutdown > >>>> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls > >>>> /local/domain/54/device/vfb > >>>> 0 =3D "" > >>>> backend =3D "/local/domain/0/backend/vfb/54/0" > >>>> backend-id =3D "0" > >>>> state =3D "1" > >>>> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls > >>>> /local/domain/0/backend/vfb/54/0 > >>>> frontend =3D "/local/domain/54/device/vfb/0" > >>>> frontend-id =3D "54" > >>>> online =3D "1" > >>>> state =3D "2" > >>>> domain =3D "grub" > >>>> vnc =3D "1" > >>>> vnclisten =3D "127.0.0.1" > >>>> vncdisplay =3D "0" > >>>> vncunused =3D "1" > >>>> sdl =3D "0" > >>>> opengl =3D "0" > >>>> feature-resize =3D "1" > >>>> hotplug-status =3D "connected" > >>>> > >>>> When I do "dry vfb": do everything except writing vfb state problem > >>>> disappears. So my question would be: > >>>> - how can I inspect how backend maps framebuffer pages? > >>> > >>> There is only one xenfb backend: hw/display/xenfb.c in the QEMU sourc= e > >>> tree. > >>> > >>> > >>>> - Why does it map as rw and not ro? It doesn't need to write to fram= ebuffer? > >>> > >>> Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb > >>> > >> ./tools/qemu-xen-dir-remote/hw/xenfb.c: > >> xenfb->pixels =3D xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom= , > >> =09=09=09=09=09 PROT_READ | PROT_WRITE, fbmfns, xenfb->fbpages); > >=20 > > You are right, my bad. > > I did a quick test and it should be safe to modify it to PROT_READ only= =2E > >=20 > >=20 > >>>> - How do I force it to drop the mapping? > >>> > >>> Theoretically QEMU should drop the mapping at disconnect time: > >>> > >>> hw/display/xenfb.c:fb_disconnect > >>> > >>> /* > >>> * FIXME: qemu can't un-init gfx display (yet?). > >>> * Replacing the framebuffer with anonymous shared memory > >>> * instead. This releases the guest pages and keeps qemu happy= =2E > >>> */ > >>> fb->pixels =3D mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE, > >>> PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON, > >>> -1, 0); > >>> > >> Could this fail? > >=20 > > Yes and we don't check for the return value (-1 in case of error). Well= spotted! > > Do you want to submit a patch to fix both issues or should I do it? > >=20 > I'm fine with you doing it. >=20 >=20 --1342847746-475817987-1415373653=:22875 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel --1342847746-475817987-1415373653=:22875-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Xmlaw-0003d1-6B for mharc-grub-devel@gnu.org; Fri, 07 Nov 2014 10:37:02 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmlao-0003co-DL for grub-devel@gnu.org; Fri, 07 Nov 2014 10:37:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xmlai-0002JE-8f for grub-devel@gnu.org; Fri, 07 Nov 2014 10:36:54 -0500 Received: from smtp.citrix.com ([66.165.176.89]:31448) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmlai-0002IO-1h for grub-devel@gnu.org; Fri, 07 Nov 2014 10:36:48 -0500 X-IronPort-AV: E=Sophos;i="5.07,333,1413244800"; d="scan'208";a="189168691" Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.3.181.6; Fri, 7 Nov 2014 10:36:37 -0500 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1XmlLS-00063k-2g; Fri, 07 Nov 2014 15:21:02 +0000 Date: Fri, 7 Nov 2014 15:20:53 +0000 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: =?UTF-8?Q?Vladimir_'=CF=86-coder=2Fphcoder'_Serbinenko?= Subject: Re: [Xen-devel] pvgrub2 is merged In-Reply-To: <52B434AC.7090905@gmail.com> Message-ID: References: <527EA084.6000706@gmail.com> <52987A43.9070806@m2r.biz> <52987D7F.3050006@gmail.com> <52988F86.6050008@m2r.biz> <529DB2F1.4080509@m2r.biz> <529DB363.7080003@gmail.com> <529DBED9.80105@m2r.biz> <529DC07E.8000201@gmail.com> <529DE3FD.90002@m2r.biz> <529DF9D5.2060301@gmail.com> <529E03FB.90603@m2r.biz> <52A1B0CB.3000705@m2r.biz> <52A1B5E8.5090709@gmail.com> <52A1E2CD.9030002@m2r.biz> <52A1E56E.3070105@gmail.com> <52A1EBAB.5090006@m2r.biz> <52A2F341.9010606@gmail.com> <52A5961A.2010608@m2r.biz> <52B02B13.1000103@m2r.biz> <52B02F84.6070403@gmail.com> <52B04D6E.3070700@m2r.biz> <52B0527C.40104@gmail.com> <52B057BD.8070701@m2r.biz> <52B05AF1.1040508@gmail.com> <52B05B5C.1080901@m2r.biz> <52B06131.8040809@m2r.biz> <52B1B82D.9050501@gmail.com> <52B20392.9090001@gmail.com> <52B434AC.7090905@gmail.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1342847746-475817987-1415373653=:22875" X-DLP: MIA1 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.165.176.89 Cc: The development of GRUB 2 , Fabio Fantoni , xen-devel , Stefano Stabellini X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 15:37:00 -0000 --1342847746-475817987-1415373653=:22875 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: QUOTED-PRINTABLE Hello Vladimir, sorry to resurrect an old thread and to top-post, but I noticed that in upstream grub the xenfb driver has been reverted. Is that because of this bug? If so, you should know that the bug has been fixed in QEMU. Thanks, Stefano On Fri, 20 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > On 19.12.2013 12:54, Stefano Stabellini wrote: > > On Wed, 18 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > >> On 18.12.2013 20:39, Stefano Stabellini wrote: > >>> On Wed, 18 Dec 2013, Vladimir '=CF=86-coder/phcoder' Serbinenko wrote= : > >>>> On 17.12.2013 15:35, Fabio Fantoni wrote: > >>>>> Il 17/12/2013 15:10, Fabio Fantoni ha scritto: > >>>>>> Il 17/12/2013 15:08, Vladimir '=CF=86-coder/phcoder' Serbinenko ha= scritto: > >>>>>>>> Thanks. > >>>>>>>> Now there is another error, probably introduced by xenfb support= : > >>>>>>>> > >>>>>>> doesn't look like related to xenfb. Is it 64-bit or PAE guest? > >>>>>> > >>>>>> 64 bit > >>>>> > >>>>> I did "git reset --hard" to commit "Remove grub_bios_interrupt on > >>>>> coreboot." and then I applied only > >>>>> "grub-core/lib/x86_64/xen/relocator.S: Fix hypercall ABI violation.= " > >>>>> commit. > >>>>> Now the Sid domU boot correctly, therefore the regression is caused= by > >>>>> "xenfb" or "xen grants to v1" commit, should I find the exact commi= t > >>>>> that causes that problem or these informations are enough for you? > >>>> > >>>> It's because of vfb. Apparently vfb framebuffer stays mapped as rw e= ven > >>>> after vfb shutdown > >>>> phcoder@debian:15:52:40:~/grub2$ sudo xenstore-ls > >>>> /local/domain/54/device/vfb > >>>> 0 =3D "" > >>>> backend =3D "/local/domain/0/backend/vfb/54/0" > >>>> backend-id =3D "0" > >>>> state =3D "1" > >>>> phcoder@debian:15:52:51:~/grub2$ sudo xenstore-ls > >>>> /local/domain/0/backend/vfb/54/0 > >>>> frontend =3D "/local/domain/54/device/vfb/0" > >>>> frontend-id =3D "54" > >>>> online =3D "1" > >>>> state =3D "2" > >>>> domain =3D "grub" > >>>> vnc =3D "1" > >>>> vnclisten =3D "127.0.0.1" > >>>> vncdisplay =3D "0" > >>>> vncunused =3D "1" > >>>> sdl =3D "0" > >>>> opengl =3D "0" > >>>> feature-resize =3D "1" > >>>> hotplug-status =3D "connected" > >>>> > >>>> When I do "dry vfb": do everything except writing vfb state problem > >>>> disappears. So my question would be: > >>>> - how can I inspect how backend maps framebuffer pages? > >>> > >>> There is only one xenfb backend: hw/display/xenfb.c in the QEMU sourc= e > >>> tree. > >>> > >>> > >>>> - Why does it map as rw and not ro? It doesn't need to write to fram= ebuffer? > >>> > >>> Actually it is mapping it RO, see hw/display/xenfb.c:xenfb_map_fb > >>> > >> ./tools/qemu-xen-dir-remote/hw/xenfb.c: > >> xenfb->pixels =3D xc_map_foreign_pages(xen_xc, xenfb->c.xendev.dom= , > >> =09=09=09=09=09 PROT_READ | PROT_WRITE, fbmfns, xenfb->fbpages); > >=20 > > You are right, my bad. > > I did a quick test and it should be safe to modify it to PROT_READ only= =2E > >=20 > >=20 > >>>> - How do I force it to drop the mapping? > >>> > >>> Theoretically QEMU should drop the mapping at disconnect time: > >>> > >>> hw/display/xenfb.c:fb_disconnect > >>> > >>> /* > >>> * FIXME: qemu can't un-init gfx display (yet?). > >>> * Replacing the framebuffer with anonymous shared memory > >>> * instead. This releases the guest pages and keeps qemu happy= =2E > >>> */ > >>> fb->pixels =3D mmap(fb->pixels, fb->fbpages * XC_PAGE_SIZE, > >>> PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANON, > >>> -1, 0); > >>> > >> Could this fail? > >=20 > > Yes and we don't check for the return value (-1 in case of error). Well= spotted! > > Do you want to submit a patch to fix both issues or should I do it? > >=20 > I'm fine with you doing it. >=20 >=20 --1342847746-475817987-1415373653=:22875--