Re: xen, x86 intr code rototil alert.

[Taylor R Campbell]

> Date: Fri, 10 Nov 2017 19:38:59 +
> From: Taylor R Campbell 
> 
> > Date: Fri, 10 Nov 2017 18:47:21 +
> > From: "Cherry G. Mathew" 
> > 
> > On 6 November 2017 9:31:13 PM MYT, Manuel Bouyer  
> > wrote:
> > >note that there are automatic domU tests here:
> > >http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/
> > >
> > >Seems to be broken since the 2017-10-28 08:50 UTC run,
> > >maybe related to the exec changes. It may already be fixed.
> > 
> > There seems to be an IPL related regression that looks suspicious in
> > the post 4th Nov tests. Will investigate.
> 
> Can you try the attached patch?  It might help isolate the problem.

I didn't even forget to attach the file this time!  But it helps to
run cvs diff with the right ssh key loaded so I actually get a diff.
Index: sys/arch/xen/xen/evtchn.c
===
RCS file: /cvsroot/src/sys/arch/xen/xen/evtchn.c,v
retrieving revision 1.75
diff -p -u -r1.75 evtchn.c
--- sys/arch/xen/xen/evtchn.c   10 Nov 2017 19:24:17 -  1.75
+++ sys/arch/xen/xen/evtchn.c   10 Nov 2017 19:39:28 -
@@ -393,6 +393,11 @@ evtchn_do_event(int evtch, struct intrfr
ci->ci_ilevel = ih->ih_level;
ih_fun = (void *)ih->ih_fun;
ih_fun(ih->ih_arg, regs);
+   KASSERTMSG(ci->ci_ilevel == ih->ih_level,
+   "event handler %p for evtsource[%d] (%s) changed ipl:"
+   " %d != %d",
+   ih->ih_realfun, evtch, evtsource[evtch]->ev_evname,
+   ci->ci_ilevel, ih->ih_level);
ih = ih->ih_evt_next;
}
mutex_spin_exit([evtch]);
@@ -418,6 +423,13 @@ splx:
ih_fun = (void *)ih->ih_fun;
ih_fun(ih->ih_arg, regs);
cli();
+   KASSERTMSG(ci->ci_ilevel == i,
+   "interrupt handler %p"
+   " for interrupt source %s"
+   " changed ipl: %d != %d",
+   ih->ih_realfun,
+   ci->ci_isources[i]->is_xname,
+   ci->ci_ilevel, i);
}
hypervisor_enable_ipl(i);
/* more pending IPLs may have been registered */

Re: xen, x86 intr code rototil alert.

[Taylor R Campbell]

> Date: Fri, 10 Nov 2017 18:47:21 +
> From: "Cherry G. Mathew" 
> 
> On 6 November 2017 9:31:13 PM MYT, Manuel Bouyer  
> wrote:
> >note that there are automatic domU tests here:
> >http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/
> >
> >Seems to be broken since the 2017-10-28 08:50 UTC run,
> >maybe related to the exec changes. It may already be fixed.
> 
> There seems to be an IPL related regression that looks suspicious in
> the post 4th Nov tests. Will investigate.

Can you try the attached patch?  It might help isolate the problem.

Re: xen, x86 intr code rototil alert.

[Cherry G. Mathew]

On 6 November 2017 9:31:13 PM MYT, Manuel Bouyer  wrote:
>On Mon, Nov 06, 2017 at 12:59:45AM +0530, Cherry G. Mathew wrote:
>> Hello,
>> 
>> As threatened earlier [1], I checked in a bunch of preparatory
>commits
>> for the big one - to overhaul our PV interrupt codepath and to unify
>it
>> with the x86/intr.c paths.
>> 
>> This would help abstract out several things, as well as make it much
>> easier for PVHVM to happen sanely.
>> 
>> I really would appreciate it if people would test Xen  -current on
>> amd64/i386 - dom0/domU and shout if anything is broken that wasn't
>> before these changes.
>
>note that there are automatic domU tests here:
>http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/
>
>Seems to be broken since the 2017-10-28 08:50 UTC run,
>maybe related to the exec changes. It may already be fixed.

There seems to be an IPL related regression that looks suspicious in the post 
4th Nov tests. Will investigate. 
-- 
~cherry

If it's short it's because this email was tapped on a touchscreen keyboard.

Re: xen, x86 intr code rototil alert.

[Cherry G . Mathew]

Manuel Bouyer  writes:

> On Mon, Nov 06, 2017 at 12:59:45AM +0530, Cherry G. Mathew wrote:
>> Hello,
>> 
>> As threatened earlier [1], I checked in a bunch of preparatory commits
>> for the big one - to overhaul our PV interrupt codepath and to unify it
>> with the x86/intr.c paths.
>> 
>> This would help abstract out several things, as well as make it much
>> easier for PVHVM to happen sanely.
>> 
>> I really would appreciate it if people would test Xen  -current on
>> amd64/i386 - dom0/domU and shout if anything is broken that wasn't
>> before these changes.
>
> note that there are automatic domU tests here:
> http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/
>

Very nice - bookmarked, thanks!

> Seems to be broken since the 2017-10-28 08:50 UTC run,
> maybe related to the exec changes. It may already be fixed.

Yeah - 2 Nov - I'll keep an eye on there for post 4th/5th Nov.

-- 
~cherry

Re: xen, x86 intr code rototil alert.

[Manuel Bouyer]

On Mon, Nov 06, 2017 at 12:59:45AM +0530, Cherry G. Mathew wrote:
> Hello,
> 
> As threatened earlier [1], I checked in a bunch of preparatory commits
> for the big one - to overhaul our PV interrupt codepath and to unify it
> with the x86/intr.c paths.
> 
> This would help abstract out several things, as well as make it much
> easier for PVHVM to happen sanely.
> 
> I really would appreciate it if people would test Xen  -current on
> amd64/i386 - dom0/domU and shout if anything is broken that wasn't
> before these changes.

note that there are automatic domU tests here:
http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/

Seems to be broken since the 2017-10-28 08:50 UTC run,
maybe related to the exec changes. It may already be fixed.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

xen, x86 intr code rototil alert.

[Cherry G . Mathew]

Hello,

As threatened earlier [1], I checked in a bunch of preparatory commits
for the big one - to overhaul our PV interrupt codepath and to unify it
with the x86/intr.c paths.

This would help abstract out several things, as well as make it much
easier for PVHVM to happen sanely.

I really would appreciate it if people would test Xen  -current on
amd64/i386 - dom0/domU and shout if anything is broken that wasn't
before these changes.

The last of them were made on 4th November.

The next change I make will really rock the boat hard, so I want to make
sure that people who are using / testing -current have had a chance to
test things out, before I commit to that change. All the previous
changes are revertable in the reverse order they were committed - they
are more-or-less self contained - I took pains to make sure this was the
case. 

Many Thanks,

[1] http://mail-index.netbsd.org/port-xen/2017/10/23/msg009096.html
-- 
~cherry