Re: svn commit: r310177 - in head/sys: amd64/conf i386/conf

2016-12-22 Thread Roger Pau Monné
On Thu, Dec 22, 2016 at 10:13:44AM +, Roger Pau Monné wrote:
> On Wed, Dec 21, 2016 at 11:30:36PM +, Colin Percival wrote:
> > This commit breaks the Xen boot:
> > > panic: NULL pcpu device_t
> > 
> > > cpuid = 0
> > 
> > > KDB: stack backtrace:
> > 
> > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> > > 0x82233a20
> > 
> > > vpanic() at vpanic+0x186/frame 0x82233aa0
> > 
> > > kassert_panic() at kassert_panic+0x126/frame 0x82233b10
> > 
> > > xen_setup_cpus() at xen_setup_cpus+0x5b/frame 0x82233b50
> > 
> > > mi_startup() at mi_startup+0x118/frame 0x82233b70
> > 
> > > btext() at btext+0x2c
> > 
> > 
> > I'm assuming this means xenpvcpu_attach isn't running early enough; does
> > anyone have time to track this down and fix it?
> 
> xen_intr_alloc_and_bind_ipi requires a non-NULL device_t, and with the changes
> to the AP startup code now xen_cpu_ipi_init gets called before the dummy pcpu
> devices are attached. I will try to find some time this afternoon/tomorrow in
> order to rework the ipi bind function so that it no longer requires a device_t
> (it seems kind of pointless anyway, since IPIs by definition always belong to
> the CPU package).

I've been able to successfully boot FreeBSD in Dom0 mode using the following
patch, I think it should also work for a PVH/HVM DomU, could someone please
give it a spin?

Thanks.

---8<---
diff --git a/sys/dev/xen/evtchn/evtchn_dev.c b/sys/dev/xen/evtchn/evtchn_dev.c
index 5d54d6d..df81251 100644
--- a/sys/dev/xen/evtchn/evtchn_dev.c
+++ b/sys/dev/xen/evtchn/evtchn_dev.c
@@ -373,9 +373,9 @@ evtchn_bind_user_port(struct per_user_data *u, struct 
user_evtchn *evtchn)
mtx_lock(&u->bind_mutex);
RB_INSERT(evtchn_tree, &u->evtchns, evtchn);
mtx_unlock(&u->bind_mutex);
-   error = xen_intr_add_handler(evtchn_dev, evtchn_filter,
-   evtchn_interrupt, evtchn, INTR_TYPE_MISC | INTR_MPSAFE,
-   evtchn->handle);
+   error = xen_intr_add_handler(device_get_nameunit(evtchn_dev),
+   evtchn_filter, evtchn_interrupt, evtchn,
+   INTR_TYPE_MISC | INTR_MPSAFE, evtchn->handle);
if (error != 0) {
xen_intr_unbind(&evtchn->handle);
mtx_lock(&u->bind_mutex);
diff --git a/sys/x86/xen/xen_apic.c b/sys/x86/xen/xen_apic.c
index 45c3c18..a7fa255 100644
--- a/sys/x86/xen/xen_apic.c
+++ b/sys/x86/xen/xen_apic.c
@@ -500,12 +500,9 @@ xen_cpu_ipi_init(int cpu)
 {
xen_intr_handle_t *ipi_handle;
const struct xen_ipi_handler *ipi;
-   device_t dev;
int idx, rc;
 
ipi_handle = DPCPU_ID_GET(cpu, ipi_handle);
-   dev = pcpu_find(cpu)->pc_device;
-   KASSERT((dev != NULL), ("NULL pcpu device_t"));
 
for (ipi = xen_ipis, idx = 0; idx < nitems(xen_ipis); ipi++, idx++) {
 
@@ -514,7 +511,7 @@ xen_cpu_ipi_init(int cpu)
continue;
}
 
-   rc = xen_intr_alloc_and_bind_ipi(dev, cpu, ipi->filter,
+   rc = xen_intr_alloc_and_bind_ipi(cpu, ipi->filter,
INTR_TYPE_TTY, &ipi_handle[idx]);
if (rc != 0)
panic("Unable to allocate a XEN IPI port");
diff --git a/sys/x86/xen/xen_intr.c b/sys/x86/xen/xen_intr.c
index 9c78306..3f6d190 100644
--- a/sys/x86/xen/xen_intr.c
+++ b/sys/x86/xen/xen_intr.c
@@ -392,7 +392,7 @@ xen_intr_release_isrc(struct xenisrc *isrc)
  */
 static int
 xen_intr_bind_isrc(struct xenisrc **isrcp, evtchn_port_t local_port,
-enum evtchn_type type, device_t intr_owner, driver_filter_t filter,
+enum evtchn_type type, const char *intr_owner, driver_filter_t filter,
 driver_intr_t handler, void *arg, enum intr_type flags,
 xen_intr_handle_t *port_handlep)
 {
@@ -401,8 +401,8 @@ xen_intr_bind_isrc(struct xenisrc **isrcp, evtchn_port_t 
local_port,
 
*isrcp = NULL;
if (port_handlep == NULL) {
-   device_printf(intr_owner,
- "xen_intr_bind_isrc: Bad event handle\n");
+   printf("%s: xen_intr_bind_isrc: Bad event handle\n",
+   intr_owner);
return (EINVAL);
}
 
@@ -1175,8 +1175,9 @@ xen_intr_bind_local_port(device_t dev, evtchn_port_t 
local_port,
struct xenisrc *isrc;
int error;
 
-   error = xen_intr_bind_isrc(&isrc, local_port, EVTCHN_TYPE_PORT, dev,
-   filter, handler, arg, flags, port_handlep);
+   error = xen_intr_bind_isrc(&isrc, local_port, EVTCHN_TYPE_PORT,
+   device_get_nameunit(dev), filter, handler, arg, flags,
+   port_handlep);
if (error != 0)
return (error);
 
@@ -1210,8 +1211,8 @@ xen_intr_alloc_and_bind_local_port(device_t dev, u_int 
remote_domain,
}
 
error = xen_intr_bind_isrc(&isrc, alloc_unbound.port, EVTCHN_TYPE_PORT,
-dev, filter, handler, arg, flags,
-port_handlep);
+

Re: svn commit: r310177 - in head/sys: amd64/conf i386/conf

2016-12-22 Thread Roger Pau Monné
On Wed, Dec 21, 2016 at 11:30:36PM +, Colin Percival wrote:
> This commit breaks the Xen boot:
> > panic: NULL pcpu device_t
> 
> > cpuid = 0
> 
> > KDB: stack backtrace:
> 
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> > 0x82233a20
> 
> > vpanic() at vpanic+0x186/frame 0x82233aa0
> 
> > kassert_panic() at kassert_panic+0x126/frame 0x82233b10
> 
> > xen_setup_cpus() at xen_setup_cpus+0x5b/frame 0x82233b50
> 
> > mi_startup() at mi_startup+0x118/frame 0x82233b70
> 
> > btext() at btext+0x2c
> 
> 
> I'm assuming this means xenpvcpu_attach isn't running early enough; does
> anyone have time to track this down and fix it?

xen_intr_alloc_and_bind_ipi requires a non-NULL device_t, and with the changes
to the AP startup code now xen_cpu_ipi_init gets called before the dummy pcpu
devices are attached. I will try to find some time this afternoon/tomorrow in
order to rework the ipi bind function so that it no longer requires a device_t
(it seems kind of pointless anyway, since IPIs by definition always belong to
the CPU package).

Roger.
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"


Re: svn commit: r310177 - in head/sys: amd64/conf i386/conf

2016-12-21 Thread Colin Percival
This commit breaks the Xen boot:
> panic: NULL pcpu device_t

> cpuid = 0

> KDB: stack backtrace:

> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x82233a20

> vpanic() at vpanic+0x186/frame 0x82233aa0

> kassert_panic() at kassert_panic+0x126/frame 0x82233b10

> xen_setup_cpus() at xen_setup_cpus+0x5b/frame 0x82233b50

> mi_startup() at mi_startup+0x118/frame 0x82233b70

> btext() at btext+0x2c


I'm assuming this means xenpvcpu_attach isn't running early enough; does
anyone have time to track this down and fix it?

On 12/16/16 13:10, John Baldwin wrote:
> Author: jhb
> Date: Fri Dec 16 21:10:37 2016
> New Revision: 310177
> URL: https://svnweb.freebsd.org/changeset/base/310177
> 
> Log:
>   Enable EARLY_AP_STARTUP on amd64 and i386 kernels by default.
>   
>   PR: 199321, 203682
>   MFC after:  2 months
>   Sponsored by:   Netflix
> 
> Modified:
>   head/sys/amd64/conf/GENERIC
>   head/sys/amd64/conf/MINIMAL
>   head/sys/i386/conf/GENERIC
> 
> Modified: head/sys/amd64/conf/GENERIC
> ==
> --- head/sys/amd64/conf/GENERIC   Fri Dec 16 20:49:50 2016
> (r310176)
> +++ head/sys/amd64/conf/GENERIC   Fri Dec 16 21:10:37 2016
> (r310177)
> @@ -98,6 +98,7 @@ options MALLOC_DEBUG_MAXZONES=8 # Separ
>  # Make an SMP-capable kernel by default
>  options  SMP # Symmetric MultiProcessor Kernel
>  options  DEVICE_NUMA # I/O Device Affinity
> +options  EARLY_AP_STARTUP
>  
>  # CPU frequency control
>  device   cpufreq
> 
> Modified: head/sys/amd64/conf/MINIMAL
> ==
> --- head/sys/amd64/conf/MINIMAL   Fri Dec 16 20:49:50 2016
> (r310176)
> +++ head/sys/amd64/conf/MINIMAL   Fri Dec 16 21:10:37 2016
> (r310177)
> @@ -94,6 +94,7 @@ options MALLOC_DEBUG_MAXZONES=8 # Separ
>  # Make an SMP-capable kernel by default
>  options  SMP # Symmetric MultiProcessor Kernel
>  options  DEVICE_NUMA # I/O Device Affinity
> +options  EARLY_AP_STARTUP
>  
>  # CPU frequency control
>  device   cpufreq
> 
> Modified: head/sys/i386/conf/GENERIC
> ==
> --- head/sys/i386/conf/GENERICFri Dec 16 20:49:50 2016
> (r310176)
> +++ head/sys/i386/conf/GENERICFri Dec 16 21:10:37 2016
> (r310177)
> @@ -96,6 +96,7 @@ options MALLOC_DEBUG_MAXZONES=8 # Separ
>  # To make an SMP kernel, the next two lines are needed
>  options  SMP # Symmetric MultiProcessor Kernel
>  device   apic# I/O APIC
> +options  EARLY_AP_STARTUP
>  
>  # CPU frequency control
>  device   cpufreq
> 
> 
> 

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
___
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"