Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

["Hu, Robert" <robert.hu@xxxxxxxxx>]

> -----Original Message-----
> From: Hu, Robert
> Sent: Monday, October 26, 2015 3:05 PM
> To: 'Ian Campbell' <ian.campbell@xxxxxxxxxx>; 'Ian Jackson'
> <ian.jackson@xxxxxxxxxxxxx>; 'xen-devel@xxxxxxxxxxxxxxxxxxxx'
> <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> > -----Original Message-----
> > From: Hu, Robert
> > Sent: Sunday, October 25, 2015 10:46 AM
> > To: Ian Campbell <ian.campbell@xxxxxxxxxx>; 'Ian Jackson'
> > <ian.jackson@xxxxxxxxxxxxx>; 'xen-devel@xxxxxxxxxxxxxxxxxxxx'
> > <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> > Subject: RE: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> >
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> > > Sent: Friday, October 23, 2015 9:38 PM
> > > To: Hu, Robert <robert.hu@xxxxxxxxx>; 'Ian Jackson'
> > > <ian.jackson@xxxxxxxxxxxxx>; 'xen-devel@xxxxxxxxxxxxxxxxxxxx'
> > > <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > > `nodhcp' to `ensurebridge'
> > >
> > > On Fri, 2015-10-23 at 13:25 +0000, Hu, Robert wrote:
> > > > > -----Original Message-----
> > > > > From: Ian Campbell [mailto:ian.campbell@xxxxxxxxxx]
> > > > > Sent: Friday, October 23, 2015 4:15 PM
> > > > > To: Hu, Robert <robert.hu@xxxxxxxxx>; 'Ian Jackson'
> > > > > <ian.jackson@xxxxxxxxxxxxx>; 'xen-devel@xxxxxxxxxxxxxxxxxxxx'
> > > > > <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> > > > > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking:
> Rename
> > > > > `nodhcp' to `ensurebridge'
> > > > >
> > > > > On Fri, 2015-10-23 at 06:16 +0000, Hu, Robert wrote:
> > > > >
> > > > > > [Hu, Robert]
> > > > > > Seems the failure log shall be this, any idea? I've spent days on
> > > > > > debugging this:(
> > > > > > (XEN) traps.c:3290: GPF (0000): ffff82d080195082 ->
> > ffff82d080243d9d
> > > > > > (XEN) PCI add device 0000:00:00.0
> > > > > > (XEN) PCI add device 0000:00:01.0
> > > > > > (XEN) PCI add device 0000:00:01.1
> > > > > > (XEN) PCI add device 0000:00:01.2
> > > > > > (XEN) PCI add device 0000:00:01.3
> > > > > > (XEN) PCI add device 0000:00:02.0
> > > > > > (XEN) PCI add device 0000:00:03.0
> > > > > > (XEN) d0: Forcing read-only access to MFN fed00
> > > > > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > > > > > Issued domain 3 reboot
> > > > > > qemu: terminating on signal 1 from pid 4322
> > > > >
> > > > > Please can you report this as a regular bug in a fresh thread, that 
> > > > > way
> > > > > the relevant Xen maintainers are likely to see and react to it, rather
> > > > > than just us osstest folks.
> > > > [Hu, Robert]
> > > >
> > > > It shall be in that way after I confirm it is a bug.
> > > > Currently I'm just still not certain it is a nested bug or because of 
> > > > the
> > > > latest
> > > > osstest code change.
> > > > I was just asking for if you can recall some hint on what changes (of
> > > > osstest)
> > > > might causing this.
> > > > I'm to restore to my v12 code, with current Xen and qemu selection to
> try
> > > > again. I think by this way, I can confirm it is an actual nested bug or
> > > > not.
> > > > Then I would report this in a fresh thread.
> > >
> > [Hu, Robert]
> >
> > With v12 code, on same L1 Dom0 kernel, L1 Xen and Qemu selection,
> nested
> > test
> > passes.
> > I've saved l1 guest configuration, l1 network configuration, and l1 Dom0
> > kernel
> > config for further comparison. Anything else possibly related you can think
> > of?
> >
> > > A dom0 crash of this sort is pretty certainly a bug somewhere in Xen,
> > > whether it is exposed by a new osstest case or not. The people who are
> > best
> > > placed to figure out where the bug is are certainly not reading this
> > > osstest thread.
> > >
> > > So please just report it as a bug as it stands, with the relevant
> > > information.
> > [Hu, Robert]
> >
> > Nested Xen is in tech preview phase, not that production level matured.
> > It is so nit-picking that any configuration change not meeting its appetite
> will
> > induce its naughtiness, i.e. crash, I think. :)
> [Hu, Robert]
> 
> Root cause found: Dom0 kernel boot cmd line: console=xvc0 matters, shall
> be
> hvc0 in nested environment.
[Hu, Robert] 

A patch for this: in ts-xen-install, after exact kernel and xen, check if 
'kernkind'
for this host exist, if not, set it with existing runvar.
The hvc0 --> xvc0 happens in debian_boot_setup() --> target_kernkind_check().
If 'kernkind' runvar for host is missing, the existing code will set it to xvc0.
For our pvops kernel, it shall be hvc0.

diff --git a/ts-xen-install b/ts-xen-install
index 3d0f394..eb40c1e 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -79,6 +79,15 @@ sub extract () {
                $r{"$ho->{Ident}_${part}buildjob"} // $r{"${part}buildjob"},
                \%distpath);
     }
+    
+    if (!target_var($ho, 'kernkind'))
+    {
+       my $pfx=target_var_prefix($ho);
+
+       store_runvar($pfx."kernkind", $r{'kernkind'});
+    }
+    
+
     if (target_file_exists($ho, "/usr/lib64/efi/xen.efi")) {
        target_cmd_root($ho,<<END);
            mkdir -p /boot/efi/EFI/osstest


How would you like it? it is just my proposal fix. (Tested)
> 
> > >
> > > Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel