From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fanny Dwargee Subject: Re: Stub domain crash on Xen v4.6.1 Date: Tue, 12 Apr 2016 10:27:55 +0200 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0591307023549267394==" Return-path: Received: from mail6.bemta6.messagelabs.com ([85.158.143.247]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aptfy-0002TI-9x for xen-devel@lists.xenproject.org; Tue, 12 Apr 2016 08:27:58 +0000 Received: by mail-lf0-f65.google.com with SMTP id p81so1435291lfb.3 for ; Tue, 12 Apr 2016 01:27:55 -0700 (PDT) List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Wei Liu , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org --===============0591307023549267394== Content-Type: multipart/alternative; boundary=001a11401ab219b1040530457001 --001a11401ab219b1040530457001 Content-Type: text/plain; charset=UTF-8 Wei, thanks for your help. After following your advice I added to the DomU config the 'device_model_version = "qemu-xen-traditional"' (and removing 'device_model_stubdomain_override'), the DomU started successfully as without stub domain: (d18) Press F12 for boot menu. (d18) (d18) Booting from Hard Disk... (XEN) irq.c:275: Dom18 PCI link 0 changed 5 -> 0 (XEN) irq.c:275: Dom18 PCI link 1 changed 10 -> 0 (XEN) irq.c:275: Dom18 PCI link 2 changed 11 -> 0 (XEN) irq.c:275: Dom18 PCI link 3 changed 5 -> 0 Just for the sake of remember this is the log of the DomU with the initial configuration (no 'device_model_version' and no 'device_model_stubdomain_override'): (d19) Press F12 for boot menu. (d19) (d19) Searching bootorder for: HALT (d19) drive 0x000f64f0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=20971520 (d19) Space available for UMB: ca800-ef000, f5f10-f64f0 (d19) Returned 258048 bytes of ZoneHigh (d19) e820 map has 6 items: (d19) 0: 0000000000000000 - 000000000009fc00 = 1 RAM (d19) 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED (d19) 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED (d19) 3: 0000000000100000 - 000000007efff000 = 1 RAM (d19) 4: 000000007efff000 - 000000007f000000 = 2 RESERVED (d19) 5: 00000000fc000000 - 0000000100000000 = 2 RESERVED (d19) enter handle_19: (d19) NULL (d19) Booting from Hard Disk... (d19) Booting from 0000:7c00 (XEN) irq.c:275: Dom19 PCI link 0 changed 5 -> 0 (XEN) irq.c:275: Dom19 PCI link 1 changed 10 -> 0 (XEN) irq.c:275: Dom19 PCI link 2 changed 11 -> 0 (XEN) irq.c:275: Dom19 PCI link 3 changed 5 -> 0 ...and this is the log with 'device_model_stubdomain_override = 1' (the DomU hangs starting Windows7): (d20) Press F12 for boot menu. (d20) (d20) Booting from Hard Disk... (XEN) irq.c:275: Dom20 PCI link 0 changed 5 -> 0 (XEN) irq.c:275: Dom20 PCI link 1 changed 10 -> 0 (XEN) irq.c:275: Dom20 PCI link 2 changed 11 -> 0 (XEN) irq.c:275: Dom20 PCI link 3 changed 5 -> 0 (XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0) (d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num bytes 512 [...] [several logs with the same 2 previous lines, snipped for brevity] [...] (XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0) (d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num bytes 512 (d21) close(11) As you can see the error message appears only with the stub domain config. Regards, Fanny On Mon, 11 Apr 2016 at 12:06:38 +0100, Wei Liu wrote: > > Sorry for the late reply. > > In the case successfully booting DomU, do you see similar error like > this in xl dmesg? > > (d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num bytes > 512 > (XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0) > (d21) read error -1 on /local/domain/21/device/vbd/768 at offset 0, num bytes > 512 > (XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0) > > Another thing to try is to add to your config without > device_model_override=xxx, > > device_model_version="qemu-xen-traditional" > > and see if it still works. > > Here is why: the default device model is upstream qemu, but when you > need to use stubdom, the device model is another version of qemu > (qemu-trad). The newly added config option forces Xen to use the same > qemu that would be used when stubdom is in use. It's useful to figure > out if qemu-trad is not functioning. > > > > Wei. --001a11401ab219b1040530457001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wei, thanks for your help.

A= fter following your advice I added to the DomU config the 'device_model= _version =3D "qemu-xen-traditional"' (and removing 'devic= e_model_stubdomain_override'), the DomU started successfully as without= stub domain:

(d18) Press F12 for boot menu.
(d18)
(d18) Booting from Hard Disk...
(XEN) irq.c:275: Dom18 PCI l= ink 0 changed 5 -> 0
(XEN) irq.c:275: Dom18 PCI link 1 changed 10 -> 0
(XEN) irq.c:275: Dom= 18 PCI link 2 changed 11 -> 0
(XEN) irq.c:275: Dom18 PCI link 3 changed 5 -> 0


Just for t= he sake of remember this is the log of the DomU with the initial configurat= ion (no 'device_model_version' and no 'device_model_stubdomain_= override'):

(d19)
(d19) Searching bootorder for: HALT
(d19) drive 0x000f64f0: PCHS=3D16= 383/16/63 translation=3Dlba LCHS=3D1024/255/63 s=3D20971520
(d19) Space available for = UMB: ca800-ef000, f5f10-f64f0
(d19) Returned 258048 bytes of ZoneHigh
(d19) e820 map has 6 items:=
(d19) =C2= =A0 0: 0000000000000000 - 000000000009fc00 =3D 1 RAM
(d19) =C2=A0 1: 000000000009fc00 = - 00000000000a0000 =3D 2 RESERVED
(d19) =C2=A0 2: 00000000000f0000 - 0000000000100000 = =3D 2 RESERVED
(d19) =C2=A0 3: 0000000000100000 - 000000007efff000 =3D 1 RAM
(d19) =C2=A0 4: 0000= 00007efff000 - 000000007f000000 =3D 2 RESERVED
= (d19) =C2=A0 5: 00000000fc000000 - 0000= 000100000000 =3D 2 RESERVED
(d19) enter handle_19:
(d19) =C2=A0 NULL
= (d19) Booting from Hard Disk...<= /div>
(d19) Booting from= 0000:7c00
= (XEN) irq.c:275: Dom19 PCI link 0 changed 5 -> 0
=
(XEN) irq.c:275: Dom19 PCI link 1 = changed 10 -> 0
(XEN) irq.c:275: Dom19 PCI link 2 changed 11 -> 0
(XEN) irq.c:275: Dom19 PC= I link 3 changed 5 -> 0


...and this is the log with 'device_model_stubdomain_= override =3D 1' (the DomU hangs starting Windows7):

(d20) Press F12 for b= oot menu.
(d20)
(d= 20) Booting from Hard Disk...
(XEN) irq.c:275: Dom20 PCI link 0 changed 5 -> 0
(XEN) irq.c:275= : Dom20 PCI link 1 changed 10 -> 0
(XEN) irq.c:275: Dom20 PCI link 2 changed 11 -&g= t; 0
(XEN) = irq.c:275: Dom20 PCI link 3 changed 5 -> 0
<= font face=3D"monospace, monospace">(XEN) grant_table.c:525:d0v0 Bad flags (= 0) or dom (0). (expected dom 0)
(d21) read error -1 on /local/domain/21/device/vbd/768= at offset 0, num bytes 512
[...]
=C2=A0 =C2=A0 =C2=A0[several logs with the same 2 previous lines, s= nipped for brevity]
[...]
(XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (expected dom 0)<= /font>
(d21) read = error -1 on /local/domain/21/device/vbd/768 at offset 0, num bytes 512
(d21) close(11)=


As you c= an see the error message appears only with the stub domain config.

Regards,

Fanny

On Mon, 11 Apr 2016 at 12:06:38 +0100, Wei Liu wrote:
>
<= div>
> Sorry for the late reply.
>=C2=A0
> In the case successfully booting DomU, do you see similar error like<= /div>
> this in xl dmesg?
>=C2=A0
> (d21) = read error -1 on /local/domain/21/device/vbd/768 at offset 0, num bytes=C2= =A0
> 512
> (XEN) grant_table.c:525:d0v0 Bad flag= s (0) or dom (0). (expected dom 0)
> (d21) read error -1 on /l= ocal/domain/21/device/vbd/768 at offset 0, num bytes=C2=A0
> 5= 12
> (XEN) grant_table.c:525:d0v0 Bad flags (0) or dom (0). (e= xpected dom 0)
>=C2=A0
> Another thing to try is = to add to your config without
> device_model_override=3Dxxx,
>=C2=A0
> =C2=A0 device_model_version=3D"qemu= -xen-traditional"
>=C2=A0
> and see if it st= ill works.
>=C2=A0
> Here is why: the default dev= ice model is upstream qemu, but when you
> need to use stubdom= , the device model is another version of qemu
> (qemu-trad). T= he newly added config option forces Xen to use the same
> qemu= that would be used when stubdom is in use. It's useful to figure
=
> out if qemu-trad is not functioning.
>
>
>
> Wei.

--001a11401ab219b1040530457001-- --===============0591307023549267394== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============0591307023549267394==--