From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Haigh Subject: Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0 Date: Thu, 23 Oct 2014 02:23:16 +1100 Message-ID: <5447CBE4.6090104@crc.id.au> References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au> <1413968436.20604.53.camel@citrix.com> <20141022095906.GG3659@type.bordeaux.inria.fr> <1413974439.18118.1.camel@citrix.com> <1413979542.19198.14.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1555143581092402970==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini , Ian Campbell Cc: Anthony Perard , Samuel Thibault , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============1555143581092402970== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h0xq4VBbx1AGNSHSXUOt2UaWOdsBMrjWl" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h0xq4VBbx1AGNSHSXUOt2UaWOdsBMrjWl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 22/10/2014 11:13 PM, Stefano Stabellini wrote: > On Wed, 22 Oct 2014, Ian Campbell wrote: >> On Wed, 2014-10-22 at 12:57 +0100, Stefano Stabellini wrote: >>> On Wed, 22 Oct 2014, Ian Campbell wrote: >>>> On Wed, 2014-10-22 at 11:59 +0200, Samuel Thibault wrote: >>>>> Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a =C3=A9crit : >>>>>> On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote: >>>>>>> As a side note to this - if I use pygrub as a bootloader vs using= >>>>>>> pvgrub, then VNC works perfectly. >>>>>>> >>>>>>> So, what options exist to make pvgrub behave properly for booting= with >>>>>>> VNC enabled? >>>>>> >>>>>> ISTR (vaguely) that way back when the backends needed to be modifi= ed to >>>>>> cope with kexec (which is effectively what pvgrub does) by not exi= ting >>>>>> when the frontend disconnects, instead sticking around waiting for= a new >>>>>> frontend, this relates somehow to the "online" key in xenstore. >>>>>> >>>>>> Perhaps the pvfb backend never got that treatment, which would exp= lain >>>>>> #2?=20 >>>>> >>>>> Probably, yes. >>>> >>>> Adding Stefano and Anthony, since the backend in this case is in qem= u. >>>> >>>> When the frontend disconnects and the online node =3D=3D 1 then the = backend >>>> is supposed to go from Closed back to InitWait and wait for a new >>>> connection, as opposed to shutting down. This is needed for kexec (w= hich >>>> pvgrub uses). >>>> >>>> I can see some handling of the online node in hw/xen/xen_backend.c b= ut >>>> it doesn't look like it would do what is needed here. I also don't s= ee >>>> any handling in either hw/block/xen_disk.c or hw/display/xenfb.c. Wh= ich >>>> makes me suspect that as well as pvfb not working with kexec/pvgrub >>>> neither does the qdisk backend, which would be unfortunate. >>> >>> Looking at the code in xen_backend.c, it seems that on XenbusStateClo= sed >>> xen_backend is going to try to reset to XenbusStateInitialising, unle= ss >>> the frontend state is XenbusStateInitialising (no idea why). See: >>> xen_be_try_reset and xen_be_check_state. >>> >>> Maybe it should go to XenbusStateInitWait instead? >> >> Possibly? >> >> Doesn't xen_be_check_state do that though, i.e. once you hit >> XenbusStateInitialising you have: >> case XenbusStateInitialising: >> rc =3D xen_be_try_init(xendev); >> which will push on to XenbusStateInitWait? >> >> There's quite a few xen_be_printf surrounding these state transitions,= >> which ought to be printed at level >=3D 2. How can Steven control the >> loglevel and where would they go (/var/log/xen/qemu-dm-$domname.log?) >=20 >=20 > I think that this should do: >=20 >=20 > diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c > index b2cb22b..d1d5d8e 100644 > --- a/hw/xen/xen_backend.c > +++ b/hw/xen/xen_backend.c > @@ -50,7 +50,7 @@ const char *xen_protocol; > =20 > /* private */ > static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs =3D QTAILQ_HEAD_I= NITIALIZER(xendevs); > -static int debug =3D 0; > +static int debug =3D 9; > =20 > /* ------------------------------------------------------------- */ > =20 >=20 I applied this patch and posted testing packages.... For completeness, this is the DomU config: ---------- DomU Config ----------- name =3D "dev.vm" memory =3D 8192 vcpus =3D 6 cpus =3D "1-7" disk =3D [ 'phy:/dev/vg_hosting/dev.vm,xvda,w', 'file:/root/SL-65-x86_64-2013-12-05-boot.iso,xvdd:cdrom,r' ] vif =3D [ 'mac=3D20:34:01:36:00:42, vifname=3Dvif.dev, bridge= =3Dbr0' ] kernel =3D "/usr/lib/xen/boot/pv-grub-x86_64.gz" extra =3D "(hd0)/boot/grub/grub.conf" #bootloader =3D "pygrub" vfb =3D [ 'type=3Dvnc, vnclisten=3D203.4.136.1, vncdisplay=3D= 2' ] on_poweroff =3D 'destroy' on_reboot =3D 'restart' on_crash =3D 'restart' ---------------------------------- Output using pv-grub: Xen Minimal OS! start_info: 0x19ac000(VA) nr_pages: 0x200000 shared_inf: 0xa5d0a000(MA) pt_base: 0x19af000(VA) nr_pt_frames: 0x11 mfn_list: 0x9ac000(VA) mod_start: 0x0(VA) mod_len: 0 flags: 0x0 cmd_line: (hd0)/boot/grub/grub.conf stack: 0x96b100-0x98b100 MM: Init _text: 0x0(VA) _etext: 0x7c814(VA) _erodata: 0x98000(VA) _edata: 0x9dd00(VA) stack start: 0x96b100(VA) _end: 0x9ab700(VA) start_pfn: 19c3 max_pfn: 200000 Mapping memory range 0x1c00000 - 0x200000000 setting 0x0-0x98000 readonly skipped 0x1000 MM: Initialise page allocator for 29bc000(29bc000)-200000000(200000000) MM: done Demand map pfns at 200001000-2200001000. Heap resides at 2200002000-4200002000. Initialising timer interface Initialising console ... done. gnttab_table mapped at 0x200001000. Initialising scheduler Thread "Idle": pointer: 0x2200002050, stack: 0x3a10000 Thread "xenstore": pointer: 0x2200002800, stack: 0x3a20000 xenbus initialised on irq 1 mfn 0x3f46d1 Thread "shutdown": pointer: 0x2200002fb0, stack: 0x3a30000 Dummy main: start_info=3D0x98b200 Thread "main": pointer: 0x2200003760, stack: 0x3a40000 "main" "(hd0)/boot/grub/grub.conf" vbd 51712 is hd0 ******************* BLKFRONT for device/vbd/51712 ********** Shutting down () Shutdown requested: 3 Thread "shutdown" exited. backend at /local/domain/0/backend/vbd/20/51712 125829120 sectors of 512 bytes ************************** vbd 51760 is hd1 ******************* BLKFRONT for device/vbd/51760 ********** backend at /local/domain/0/backend/qdisk/20/51760 Failed to read /local/domain/0/backend/qdisk/20/51760/feature-barrier. 436224 sectors of 512 bytes ************************** Thread "kbdfront": pointer: 0x2200004580, stack: 0x3a30000 ******************* FBFRONT for device/vfb/0 ********** ******************* KBDFRONT for device/vkbd/0 ********** backend at /local/domain/0/backend/vkbd/20/0 backend at /local/domain/0/backend/vfb/20/0 /local/domain/0/backend/vkbd/20/0 connected ************************** KBDFRONT Thread "kbdfront" exited. /local/domain/0/backend/vfb/20/0 connected ************************** FBFRONT ((( Hit enter to boot a grub entry ))) Thread "kbdfront close": pointer: 0x2200004580, stack: 0x3a30000 close fb: backend at /local/domain/0/backend/vfb/21/0 close kbd: backend at /local/domain/0/backend/vkbd/21/0 Booting 'Scientific Linux (3.14.21-1.el6xen.x86_64)' root (hd0) Filesystem type is ext2fs, using whole disk kernel /boot/vmlinuz-3.14.21-1.el6xen.x86_64 ro root=3D/dev/xvda rd_NO_LUKS rd_NO _DM LANG=3Den_US.UTF-8 SYSFONT=3Dlatarcyrheb-sun16 KEYBOARDTYPE=3Dpc KEYTABLE=3Dus cras hkernel=3Dauto console=3Dhvc0 Thread "kbdfront close" exited. initrd /boot/initramfs-3.14.21-1.el6xen.x86_64.img =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Init TPM Front =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tpmfront:Error Unable to read device/vtpm/0/backend-id during tpmfront initialization! error =3D ENOENT Tpmfront:Info Shutting down tpmfront close blk: backend=3D/local/domain/0/backend/vbd/21/51712 node=3Ddevice/vbd/51712 close blk: backend=3D/local/domain/0/backend/qdisk/21/51760 node=3Ddevice/vbd/51760 ---------------------------------- This gives a VNC display on port 5092 - and the system waits at the grub prompt (ie the timeout is never reached). I don't get a console from this point on in either VNC or via 'xl console dev.vm' On another note, I noticed this within the Dom0 kernel dmesg: device vif.dev entered promiscuous mode IPv6: ADDRCONF(NETDEV_UP): vif.dev: link is not ready xen-blkback:ring-ref 2047, event-channel 4, protocol 1 (x86_64-abi) qemu-system-i38[3956]: segfault at 0 ip (null) sp 00007fffb4573638 error 4 xen-blkback:backend/vbd/21/51712: prepare for reconnect br0: port 8(vif.dev) entered disabled state I also noticed that if I pass console=3Dtty0 on the grub command line in "(hd0)/boot/grub/grub.conf" - then I get the expected console - however the grub menu timeout still fails - almost as if a keypress has been registered and cancelled the timeout... For example, a 'sort of' working grub.conf for the DomU that hangs at grub, but when manually selected, works as expected: default=3D0 timeout=3D1 splashimage=3D(hd0)/boot/grub/splash.xpm.gz title Scientific Linux (3.14.21-1.el6xen.x86_64) root (hd0) kernel /boot/vmlinuz-3.14.21-1.el6xen.x86_64 ro root=3D/dev/xvda rd_NO_LUKS rd_NO_DM LANG=3Den_US.UTF-8 SYSFONT=3Dlatarcyrheb-sun16 KEYBOARDTYPE=3Dpc KEYTABLE=3Dus crashkernel=3Dauto console=3Dtty0 initrd /boot/initramfs-3.14.21-1.el6xen.x86_64.img --=20 Steven Haigh Email: netwiz@crc.id.au Web: http://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 --h0xq4VBbx1AGNSHSXUOt2UaWOdsBMrjWl 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.0.22 (MingW32) iQIcBAEBAgAGBQJUR8vvAAoJEEGvNdV6fTHcic8P/0Nz5Egdf8rsxztnJ5coD6ew 0ZRljWPg27OBlzT2M6Gu780fPeKH/fj5E9FeHQINxsYUJY+uEkn1bk709gP6+NdU 9ljKlSWATEMH/Yvx7+uLgCaHY+T2lkMYIftzcinDm2RMLVpk2N6NkdbHhZqFbnFi t1gb8dIjVnw8KH+PMhdh+tExTE0q9B7d4eKxJAo+Pap6MQXiUMAAEmIqaht2SgLw aJ8HY9H7+JRCYE9Crc3cNvEAKwEHpnXxfDe9pApt1RBfx+V6LOubMVe2DnNwszGB ypa3CugT+E5XCu2UmLjxDOYmiQ2jxdIi5e9n7OtEaOzw4+tHhzKuv+3mME5KtfhV zkW8gjLYh1ClUH+CoBojWGBq4KHxlwlIpDsBEuRkxdKiI7n+VwVKybPbUP2cmx/q 2YjKzUa4+95fWa+oUTP60HcizrHfMGdIGtQkuAmPl6JSWmBpYG5iMLD5dmZTYaL5 vgPGghH/MVFpLyhp0UPckoUGm9kZt4K9C5p26MSyv2TzvQ0PxQ2pArbuply0He+O 0EDVWEpk8H8ETtDzFfozvv6SmDxrL2/Fn/CuuKSKjT+jFyU/E2iRUNVAJ9W3eixc Qwrbk0MJi7mgPU8pcHC1Ya9/A3AOJ7e3iTnWav4TOnVdLI6X5lS+fgiH+4MrAdqb T6Dao55pW4dp9+L5gXVU =qvzE -----END PGP SIGNATURE----- --h0xq4VBbx1AGNSHSXUOt2UaWOdsBMrjWl-- --===============1555143581092402970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1555143581092402970==--