Re: [PATCH v7 04/19] amd64: introduce hook for custom preload metadata parsers
On Tuesday, December 24, 2013 11:47:53 am Roger Pau Monné wrote: > On 24/12/13 16:47, John Baldwin wrote: > > On Thursday, December 19, 2013 1:54:41 pm Roger Pau Monne wrote: > >> --- /dev/null > >> +++ b/sys/xen/pv.h > >> @@ -0,0 +1,28 @@ > >> +/* > >> + * Permission is hereby granted, free of charge, to any person obtaining > >> a copy > >> + * of this software and associated documentation files (the "Software"), > >> to > >> + * deal in the Software without restriction, including without limitation > >> the > >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, > >> and/or > >> + * sell copies of the Software, and to permit persons to whom the > >> Software is > >> + * furnished to do so, subject to the following conditions: > >> + * > >> + * The above copyright notice and this permission notice shall be > >> included in > >> + * all copies or substantial portions of the Software. > >> + * > >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > >> EXPRESS OR > >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > >> MERCHANTABILITY, > >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > >> SHALL THE > >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > >> + * DEALINGS IN THE SOFTWARE. > > > > One non-technical question. This license statement doesn't actually say > > who the > > copyright belongs to which seems problematic. Would it be possible to use > > FreeBSD's > > preferred 2-clause BSD license on this file? > > I copied the license from sys/xen/hvm.h without realizing it was not the > standard 2-clause BSD one, but I don't have any problem changing it > (maybe we should also change hvm.h?) to match the license in pv.c. The license in pv.c is perfect. For hvm.h, if that could be changed to the 2-clause BSD license, that would also be great. I'll leave that up you to and Justin to determine if that change is ok to make. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 04/19] amd64: introduce hook for custom preload metadata parsers
On 24/12/13 16:47, John Baldwin wrote: > On Thursday, December 19, 2013 1:54:41 pm Roger Pau Monne wrote: >> --- /dev/null >> +++ b/sys/xen/pv.h >> @@ -0,0 +1,28 @@ >> +/* >> + * Permission is hereby granted, free of charge, to any person obtaining a >> copy >> + * of this software and associated documentation files (the "Software"), to >> + * deal in the Software without restriction, including without limitation >> the >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, >> and/or >> + * sell copies of the Software, and to permit persons to whom the Software >> is >> + * furnished to do so, subject to the following conditions: >> + * >> + * The above copyright notice and this permission notice shall be included >> in >> + * all copies or substantial portions of the Software. >> + * >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS >> OR >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL >> THE >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER >> + * DEALINGS IN THE SOFTWARE. > > One non-technical question. This license statement doesn't actually say who > the > copyright belongs to which seems problematic. Would it be possible to use > FreeBSD's > preferred 2-clause BSD license on this file? I copied the license from sys/xen/hvm.h without realizing it was not the standard 2-clause BSD one, but I don't have any problem changing it (maybe we should also change hvm.h?) to match the license in pv.c. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 16/19] xen: add shutdown hook for PVH
On Thursday, December 19, 2013 1:54:53 pm Roger Pau Monne wrote: > Add the PV shutdown hook to PVH. > --- > sys/dev/xen/control/control.c | 37 ++--- > 1 files changed, 18 insertions(+), 19 deletions(-) This looks fine to me. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 12/19] xen: add a hook to perform AP startup
On Thursday, December 19, 2013 1:54:49 pm Roger Pau Monne wrote: > AP startup on PVH follows the PV method, so we need to add a hook in > order to diverge from bare metal. > --- > > +int native_start_all_aps(void); > + Please put this in a header instead of using an extern in the Xen PV code. is probably the best header to use. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 19/19] isa: allow ISA bus to attach to the nexus
On Thursday, December 19, 2013 1:54:56 pm Roger Pau Monne wrote: > --- > sys/x86/isa/isa.c |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) If you go the xenpv route, you would replace 'nexus' with 'xenpv' here. > diff --git a/sys/x86/isa/isa.c b/sys/x86/isa/isa.c > index 1a57137..09d1ab7 100644 > --- a/sys/x86/isa/isa.c > +++ b/sys/x86/isa/isa.c > @@ -241,3 +241,6 @@ isa_release_resource(device_t bus, device_t child, int type, int rid, > * On this platform, isa can also attach to the legacy bus. > */ > DRIVER_MODULE(isa, legacy, isa_driver, isa_devclass, 0, 0); > +#ifdef XENHVM > +DRIVER_MODULE(isa, nexus, isa_driver, isa_devclass, 0, 0); > +#endif > -- > 1.7.7.5 (Apple Git-26) > > -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 08/19] xen: use the same hypercall mechanism for XEN and XENHVM
On Thursday, December 19, 2013 1:54:45 pm Roger Pau Monne wrote: > --- > sys/amd64/include/xen/hypercall.h |7 --- > sys/i386/i386/locore.s|9 + > sys/i386/include/xen/hypercall.h |8 > sys/x86/xen/hvm.c | 24 ++-- > 4 files changed, 19 insertions(+), 29 deletions(-) Looks good to me. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 14/19] xen: introduce a dummy pvcpu device
On Thursday, December 19, 2013 1:54:51 pm Roger Pau Monne wrote: > Since Xen PVH guests doesn't have ACPI, we need to create a dummy > pvcpu device that will be used to fill the pcpu->pc_device field. Rather than have this hang directly off of nexus0, it might be better to create some sort of 'xenov0' device that takes the place of acpi0 and have the CPUs hang off of that. This is how the non-ACPI case works in the native case where the default nexus creates a 'legacy0' device that sits at the same spot in the device tree as acpi0. In sys/x86/legacy.c we create CPU devices that are a child of legacy0. In general the way the native code handes ACPI vs non-ACPI is to have a different nexus (as you've adopted) create a specific child bus (acpi0 vs legacy0). Drivers that want to only attach in one of the cases at the top- level then attach as children of those rather than children of 'nexus0'. This just adds an extra layer of protection to avoid the possibility of a top-level driver that is ACPI or non-ACPI specific being probed in the "wrong" case. Right now, all drivers that attach to 'nexus' aside from the top-level busses (acpi0 vs legacy0) are intended to work on any machine. I think the CPU driver itself looks fine, I would just encourage you to consider a xenpv0 device and to move anything PV specific to hang off of that rather than directly attaching to nexus0. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 04/19] amd64: introduce hook for custom preload metadata parsers
On Thursday, December 19, 2013 1:54:41 pm Roger Pau Monne wrote: > --- /dev/null > +++ b/sys/xen/pv.h > @@ -0,0 +1,28 @@ > +/* > + * Permission is hereby granted, free of charge, to any person obtaining a > copy > + * of this software and associated documentation files (the "Software"), to > + * deal in the Software without restriction, including without limitation the > + * rights to use, copy, modify, merge, publish, distribute, sublicense, > and/or > + * sell copies of the Software, and to permit persons to whom the Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > THE > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > + * DEALINGS IN THE SOFTWARE. One non-technical question. This license statement doesn't actually say who the copyright belongs to which seems problematic. Would it be possible to use FreeBSD's preferred 2-clause BSD license on this file? -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 17/19] xen: xenstore changes to support PVH
On Thursday, December 19, 2013 1:54:54 pm Roger Pau Monne wrote: > --- > sys/xen/xenstore/xenstore.c | 21 ++--- > 1 files changed, 10 insertions(+), 11 deletions(-) This looks fine modulo possibly making it a xenpv child instead of a nexus child. Note that even in the old XEN code in FreeBSD I would argue that attaching directly to nexus is wrong and that even the old XEN code should create some sort of top-level device below nexus0 that is XEN-specific for XEN- specific drivers to attach to. I've no idea what shape the old XEN-specific code is in or if it can be tested, but I'd really like PVH to do the right thing if at all possible. > diff --git a/sys/xen/xenstore/xenstore.c b/sys/xen/xenstore/xenstore.c > index bcf6357..2893c84 100644 > --- a/sys/xen/xenstore/xenstore.c > +++ b/sys/xen/xenstore/xenstore.c > @@ -229,13 +229,11 @@ struct xs_softc { >*/ > struct sx xenwatch_mutex; > > -#ifdef XENHVM > /** >* The HVM guest pseudo-physical frame number. This is Xen's mapping >* of the true machine frame number into our "physical address space". >*/ > unsigned long gpfn; > -#endif > > /** >* The event channel for communicating with the > @@ -1141,13 +1139,15 @@ xs_attach(device_t dev) > /* Initialize the interface to xenstore. */ > struct proc *p; > > -#ifdef XENHVM > - xs.evtchn = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN); > - xs.gpfn = hvm_get_parameter(HVM_PARAM_STORE_PFN); > - xen_store = pmap_mapdev(xs.gpfn * PAGE_SIZE, PAGE_SIZE); > -#else > - xs.evtchn = xen_start_info->store_evtchn; > -#endif > + if (xen_hvm_domain()) { > + xs.evtchn = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN); > + xs.gpfn = hvm_get_parameter(HVM_PARAM_STORE_PFN); > + xen_store = pmap_mapdev(xs.gpfn * PAGE_SIZE, PAGE_SIZE); > + } else if (xen_pv_domain()) { > + xs.evtchn = HYPERVISOR_start_info->store_evtchn; > + } else { > + panic("Unknown domain type, cannot initialize xenstore\n"); > + } > > TAILQ_INIT(&xs.reply_list); > TAILQ_INIT(&xs.watch_events); > @@ -1256,9 +1256,8 @@ static devclass_t xenstore_devclass; > > #ifdef XENHVM > DRIVER_MODULE(xenstore, xenpci, xenstore_driver, xenstore_devclass, 0, 0); > -#else > -DRIVER_MODULE(xenstore, nexus, xenstore_driver, xenstore_devclass, 0, 0); > #endif > +DRIVER_MODULE(xenstore, nexus, xenstore_driver, xenstore_devclass, 0, 0); > > /*--- Sysctl Data */ > /* XXX Shouldn't the node be somewhere else? */ > -- > 1.7.7.5 (Apple Git-26) > > -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 15/19] xen: create a Xen nexus to use in PV/PVH
On Thursday, December 19, 2013 1:54:52 pm Roger Pau Monne wrote: > Introduce a Xen specific nexus that is going to be in charge for > attaching Xen specific devices. Remove the identify routine from Xen > devices and instead attach them from the nexus (PV/PVH) or xenpci > (HVM). As with my previous mail, I would encourage you to create a xenpv0 device and have the xen nexus be very minimal. This would let you leave the existing identify routines in place (which is cleaner / more extensible than a static table of devices that you explicitly add), but by having the PV-specific drivers attach as children of xenpv0, their identify routines would only be invoked when xenpv0 attached. You can even use an identify routine for CPUs (see cpu_identify in sys/x86/x86/legacy.c). -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 06/19] xen: implement an early timer for Xen PVH
On Thursday, December 19, 2013 1:54:43 pm Roger Pau Monne wrote: > When running as a PVH guest, there's no emulated i8254, so we need to > use the Xen PV timer as the early source for DELAY. This change allows > for different implementations of the early DELAY function and > implements a Xen variant for it. This mostly looks good to me. I would perhaps move DELAY() itself into delay.c if it isn't too ugly to do so. I guess it would look something like: #if !(defined(__i386__) && defined(XEN)) void DELAY(int n) { if (delay_tc(n)) return; #ifdef __amd64__ init_ops.early_delay(n); #else i8254_delay(n); } #endif This would let you leave delay_tc() private to delay.c. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 11/19] xen: changes to hvm code in order to support PVH guests
On Thursday, December 19, 2013 1:54:48 pm Roger Pau Monne wrote: > On PVH we don't need to init the shared info page, or disable emulated > devices. Also, make sure PV IPIs are set before starting the APs. Looks ok to me. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 18/19] xen: changes to gnttab for PVH
On Thursday, December 19, 2013 1:54:55 pm Roger Pau Monne wrote: > --- > sys/xen/gnttab.c | 26 +- > 1 files changed, 21 insertions(+), 5 deletions(-) I can't really speak to the correctness of this as I don't know the Xen internals well enough, but I don't see anything that looks wrong. :) -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 13/19] xen: introduce flag to disable the local apic
On Thursday, December 19, 2013 1:54:50 pm Roger Pau Monne wrote: > PVH guests don't have an emulated lapic. Since the tests all use '!lapic_disabled' I think I would prefer to flip the name to 'lapic_valid' and have it default to true. It would just be a cosmetic change to the current patch, but I think it is more readable long- term. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 09/19] xen: add a apic_enumerator for PVH
On Thursday, December 19, 2013 1:54:46 pm Roger Pau Monne wrote: > --- > sys/conf/files.amd64 |1 + > sys/x86/xen/mptable.c | 136 My only request would be to not call this 'mptable.c' as it has nothing to do with the MP Table spec. (I realize the older Xen code made this error previously.) You could maybe call it sys/x86/xen/pv_vcpu.c or some such. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 03/19] xen: add and enable Xen console for PVH guests
On Thursday, December 19, 2013 1:54:40 pm Roger Pau Monne wrote: > diff --git a/sys/dev/xen/console/console.c b/sys/dev/xen/console/console.c > index 23eaee2..e8079da 100644 > --- a/sys/dev/xen/console/console.c > +++ b/sys/dev/xen/console/console.c > @@ -69,11 +69,14 @@ struct mtx cn_mtx; > static char wbuf[WBUF_SIZE]; > static char rbuf[RBUF_SIZE]; > static int rc, rp; > -static unsigned int cnsl_evt_reg; > +unsigned int cnsl_evt_reg; > static unsigned int wc, wp; /* write_cons, write_prod */ > xen_intr_handle_t xen_intr_handle; > device_t xencons_dev; > > +/* Virt address of the shared console page */ Tiny nit: I would expand "Virt" to "Virtual" > +char *console_page; > + > #ifdef KDB > static int xc_altbrk; > #endif > @@ -110,9 +113,28 @@ static struct ttydevsw xc_ttydevsw = { > .tsw_outwakeup = xcoutwakeup, > }; > > +/*- Debug function > ---*/ > +#define XC_PRINTF_BUFSIZE 1024 > +void > +xc_printf(const char *fmt, ...) > +{ > +__va_list ap; > +int retval; > +static char buf[XC_PRINTF_BUFSIZE]; > + > +va_start(ap, fmt); > +retval = vsnprintf(buf, XC_PRINTF_BUFSIZE - 1, fmt, ap); > +va_end(ap); > +buf[retval] = 0; > +HYPERVISOR_console_write(buf, retval); > +} > + vsnprintf() always nul-terminates, so you can simplify this slightly to: retval = vsnprintf(buf, sizeof(buf), fmt, ap); OTOH, you can't actually use 'retval' from vsnprintf as it returns the number of characters that would have been output if the buffer were infinitely long, not the number of characters output into the string. >From printf(3): These functions return the number of characters printed (not including the trailing `\0' used to end output to strings) or a negative value if an output error occurs, except for snprintf() and vsnprintf(), which return the number of characters that would have been printed if the size were unlimited (again, not including the final `\0'). So I think what you actually want is this: void xc_printf(const char *fmt, ...) { static char buf[XC_PRINTF_BUFSIZE]; __va_list ap; va_start(ap, fmt); vsnprintf(buf, sizeof(buf), fmt, ap); va_end(ap); HYPERVISOR_console_write(buf, strlen(buf)); } (And I realize this is an old bug, you were just moving an existing function) > > -static void > -xc_identify(driver_t *driver, device_t parent) > -{ > - device_t child; > - child = BUS_ADD_CHILD(parent, 0, driver_name, 0); > - device_set_driver(child, driver); > - device_set_desc(child, "Xen Console"); > -} > - Hmm, how does the device get created without an identify routine? -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 05/19] xen: rework xen timer so it can be used early in boot process
On Thursday, December 19, 2013 1:54:42 pm Roger Pau Monne wrote: > This should not introduce any functional change, and makes the > functions suitable to be called before we have actually mapped the > vcpu_info struct on a per-cpu basis. Looks fine to me. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 02/19] xen: add macro to detect if running as Dom0
On Thursday, December 19, 2013 1:54:39 pm Roger Pau Monne wrote: > --- > sys/xen/xen-os.h |7 +++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/sys/xen/xen-os.h b/sys/xen/xen-os.h > index c7474d8..e8a5a99 100644 > --- a/sys/xen/xen-os.h > +++ b/sys/xen/xen-os.h > @@ -82,6 +82,13 @@ xen_hvm_domain(void) > return (xen_domain_type == XEN_HVM_DOMAIN); > } > > +static inline int > +xen_initial_domain(void) > +{ > + return (xen_domain() && HYPERVISOR_start_info && > + HYPERVISOR_start_info->flags & SIF_INITDOMAIN); > +} > + > #ifndef xen_mb > #define xen_mb() mb() > #endif This looks fine to me. -- John Baldwin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 10/13] xen: add ACPI bus to xen_nexus when running as Dom0
Also disable a couple of ACPI devices that are not usable under Dom0. --- sys/x86/xen/xen_nexus.c | 24 +--- 1 files changed, 21 insertions(+), 3 deletions(-) diff --git a/sys/x86/xen/xen_nexus.c b/sys/x86/xen/xen_nexus.c index 288e6b6..823b3bc 100644 --- a/sys/x86/xen/xen_nexus.c +++ b/sys/x86/xen/xen_nexus.c @@ -35,6 +35,10 @@ __FBSDID("$FreeBSD$"); #include #include +#include + +#include + #include #include @@ -44,7 +48,6 @@ static const char *xen_devices[] = "xenstore", /* XenStore bus */ "xen_et", /* Xen PV timer (provides: tc, et, clk) */ "xc", /* Xen PV console */ - "isa", /* Dummy ISA bus for sc to attach */ }; /* @@ -56,13 +59,14 @@ nexus_xen_probe(device_t dev) if (!xen_pv_domain()) return (ENXIO); - return (BUS_PROBE_DEFAULT); + return (BUS_PROBE_SPECIFIC); } static int nexus_xen_attach(device_t dev) { int i, error = 0; + device_t acpi_dev; nexus_init_resources(); bus_generic_probe(dev); @@ -79,8 +83,22 @@ nexus_xen_attach(device_t dev) if (BUS_ADD_CHILD(dev, 0, xen_devices[i], 0) == NULL) panic("%s: could not add", xen_devices[i]); } + if (xen_initial_domain()) { + /* Disable some ACPI devices that are not usable by Dom0 */ + setenv("debug.acpi.disabled", "cpu hpet timer"); + + acpi_dev = BUS_ADD_CHILD(dev, 10, "acpi", 0); + if (acpi_dev == NULL) + panic("Unable to add ACPI bus to Xen Dom0"); + } else { + /* Dummy ISA bus for sc to attach */ + if (BUS_ADD_CHILD(dev, 0, "isa", 0) == NULL) + panic("isa: could not add"); + } - bus_generic_attach(dev); + error = bus_generic_attach(dev); + if (xen_initial_domain() && (error == 0)) + acpi_install_wakeup_handler(device_get_softc(acpi_dev)); return (error); } -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 12/13] mca: disable cmc enable on Xen PV
Xen PV guests doesn't have a lapic, so disable the lapic call in mca initialization. --- sys/x86/x86/mca.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sys/x86/x86/mca.c b/sys/x86/x86/mca.c index f1369cd..e9d2c1d 100644 --- a/sys/x86/x86/mca.c +++ b/sys/x86/x86/mca.c @@ -897,7 +897,7 @@ _mca_init(int boot) } #ifdef DEV_APIC - if (PCPU_GET(cmci_mask) != 0 && boot) + if (PCPU_GET(cmci_mask) != 0 && boot && !lapic_disabled) lapic_enable_cmc(); #endif } -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 13/13] xenstore: changes needed to boot in Dom0 mode
This patch includes changes to xenstore in order to boot as Dom0. This is different from booting as a guest, since when booted as Dom0 xenstore is not available. This patch sets up a memory page, an event channel for xenstore and disables xenbus device probing at boot. It contains a workaround for xs_watch, that should be fixed when we are able to start xenstored from Dom0. --- sys/xen/xenbus/xenbusb.c|6 -- sys/xen/xenstore/xenstore.c | 22 ++ 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/sys/xen/xenbus/xenbusb.c b/sys/xen/xenbus/xenbusb.c index 1f84795..11be0f5 100644 --- a/sys/xen/xenbus/xenbusb.c +++ b/sys/xen/xenbus/xenbusb.c @@ -760,8 +760,10 @@ xenbusb_attach(device_t dev, char *bus_node, u_int id_components) * bus when they are dynamically attached to us * by a Xen management action. */ - (void)xenbusb_enumerate_bus(xbs); - xenbusb_probe_children(dev); + if (!xen_initial_domain()) { + (void)xenbusb_enumerate_bus(xbs); + xenbusb_probe_children(dev); + } xbs->xbs_device_watch.node = bus_node; xbs->xbs_device_watch.callback = xenbusb_devices_changed; diff --git a/sys/xen/xenstore/xenstore.c b/sys/xen/xenstore/xenstore.c index 2893c84..bde3f5d 100644 --- a/sys/xen/xenstore/xenstore.c +++ b/sys/xen/xenstore/xenstore.c @@ -1144,6 +1144,24 @@ xs_attach(device_t dev) xs.gpfn = hvm_get_parameter(HVM_PARAM_STORE_PFN); xen_store = pmap_mapdev(xs.gpfn * PAGE_SIZE, PAGE_SIZE); } else if (xen_pv_domain()) { + if (!HYPERVISOR_start_info->store_evtchn) { + struct evtchn_alloc_unbound alloc_unbound; + + /* Allocate a local event channel for xenstore */ + alloc_unbound.dom= DOMID_SELF; + alloc_unbound.remote_dom = DOMID_SELF; + error = HYPERVISOR_event_channel_op(EVTCHNOP_alloc_unbound, + &alloc_unbound); + if (error) + panic("unable to alloc event channel for Dom0: %d", + error); + + HYPERVISOR_start_info->store_evtchn = alloc_unbound.port; + + /* Allocate memory for the xs shared ring */ + xen_store = malloc(PAGE_SIZE, M_XENSTORE, + M_WAITOK | M_ZERO); + } xs.evtchn = HYPERVISOR_start_info->store_evtchn; } else { panic("Unknown domain type, cannot initialize xenstore\n"); @@ -1579,6 +1597,10 @@ xs_register_watch(struct xs_watch *watch) char token[sizeof(watch) * 2 + 1]; int error; + /* XXX: this is a hack until we get xenstored working */ + if (xen_initial_domain()) + return (0); + sprintf(token, "%lX", (long)watch); sx_slock(&xs.suspend_mutex); -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 11/13] pci: introduce a new event on PCI device detection
Add a new event that will fire each time a PCI device is added to the system, and allows us to register the device with Xen. --- sys/dev/pci/pci.c |1 + sys/sys/eventhandler.h |5 + sys/x86/xen/pv.c| 21 + sys/x86/xen/xen_nexus.c |6 ++ sys/xen/pv.h|1 + 5 files changed, 34 insertions(+), 0 deletions(-) diff --git a/sys/dev/pci/pci.c b/sys/dev/pci/pci.c index 4d8837f..2ee5093 100644 --- a/sys/dev/pci/pci.c +++ b/sys/dev/pci/pci.c @@ -3293,6 +3293,7 @@ pci_add_child(device_t bus, struct pci_devinfo *dinfo) resource_list_init(&dinfo->resources); pci_cfg_save(dinfo->cfg.dev, dinfo, 0); pci_cfg_restore(dinfo->cfg.dev, dinfo); + EVENTHANDLER_INVOKE(pci_add, dinfo); pci_print_verbose(dinfo); pci_add_resources(bus, dinfo->cfg.dev, 0, 0); } diff --git a/sys/sys/eventhandler.h b/sys/sys/eventhandler.h index 111c21b..3201848 100644 --- a/sys/sys/eventhandler.h +++ b/sys/sys/eventhandler.h @@ -269,5 +269,10 @@ typedef void (*unregister_framebuffer_fn)(void *, struct fb_info *); EVENTHANDLER_DECLARE(register_framebuffer, register_framebuffer_fn); EVENTHANDLER_DECLARE(unregister_framebuffer, unregister_framebuffer_fn); +/* PCI events */ +struct pci_devinfo; +typedef void (*pci_add_fn)(void *, struct pci_devinfo *); +EVENTHANDLER_DECLARE(pci_add, pci_add_fn); + #endif /* _SYS_EVENTHANDLER_H_ */ diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c index e5ad200..a44f8ca 100644 --- a/sys/x86/xen/pv.c +++ b/sys/x86/xen/pv.c @@ -39,6 +39,9 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include +#include +#include #include #include @@ -63,6 +66,8 @@ __FBSDID("$FreeBSD$"); #include +#include + /* Native initial function */ extern u_int64_t hammer_time(u_int64_t, u_int64_t); /* Xen initial function */ @@ -384,6 +389,22 @@ xen_pv_ioapic_register_intr(struct ioapic_intsrc *pin) xen_register_pirq(pin->io_irq, pin->io_activehi, pin->io_edgetrigger); } +void +xen_pv_pci_device_add(void *arg, struct pci_devinfo *dinfo) +{ + struct physdev_pci_device_add add_pci; + int error; + + bzero(&add_pci, sizeof(add_pci)); + add_pci.seg = dinfo->cfg.domain; + add_pci.bus = dinfo->cfg.bus; + add_pci.devfn = (dinfo->cfg.slot << 3) | dinfo->cfg.func; + error = HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_add, &add_pci); + if (error) + printf("unable to add device bus %u devfn %u error: %d\n", + add_pci.bus, add_pci.devfn, error); +} + static void xen_pv_set_init_ops(void) { diff --git a/sys/x86/xen/xen_nexus.c b/sys/x86/xen/xen_nexus.c index 823b3bc..60c6c5d 100644 --- a/sys/x86/xen/xen_nexus.c +++ b/sys/x86/xen/xen_nexus.c @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include @@ -42,6 +43,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include static const char *xen_devices[] = { @@ -87,6 +89,10 @@ nexus_xen_attach(device_t dev) /* Disable some ACPI devices that are not usable by Dom0 */ setenv("debug.acpi.disabled", "cpu hpet timer"); + /* Register PCI add hook */ + EVENTHANDLER_REGISTER(pci_add, xen_pv_pci_device_add, NULL, + EVENTHANDLER_PRI_FIRST); + acpi_dev = BUS_ADD_CHILD(dev, 10, "acpi", 0); if (acpi_dev == NULL) panic("Unable to add ACPI bus to Xen Dom0"); diff --git a/sys/xen/pv.h b/sys/xen/pv.h index a9d6eb0..ac737a7 100644 --- a/sys/xen/pv.h +++ b/sys/xen/pv.h @@ -24,5 +24,6 @@ #define__XEN_PV_H__ intxen_pv_start_all_aps(void); +void xen_pv_pci_device_add(void *, struct pci_devinfo *); #endif /* __XEN_PV_H__ */ -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 04/13] xen: implement basic PIRQ support for Dom0
This allows Dom0 to manage physical hardware, redirecting the physical interrupts to event channels. --- sys/x86/xen/xen_intr.c | 190 +-- sys/xen/xen_intr.h | 11 +++ 2 files changed, 192 insertions(+), 9 deletions(-) diff --git a/sys/x86/xen/xen_intr.c b/sys/x86/xen/xen_intr.c index bc0781e..340e5ed 100644 --- a/sys/x86/xen/xen_intr.c +++ b/sys/x86/xen/xen_intr.c @@ -104,6 +104,8 @@ DPCPU_DECLARE(struct vcpu_info *, vcpu_info); #define is_valid_evtchn(x) ((x) != 0) +#defineEEXIST 17 /* Xen "already exists" error */ + struct xenisrc { struct intsrc xi_intsrc; enum evtchn_type xi_type; @@ -111,6 +113,9 @@ struct xenisrc { int xi_vector; /* Global isrc vector number. */ evtchn_port_t xi_port; int xi_pirq; + int xi_activehi:1; + int xi_edgetrigger:1; + int xi_configured:1; int xi_virq; u_int xi_close:1; /* close on unbind? */ u_int xi_needs_eoi:1; @@ -136,6 +141,9 @@ static void xen_intr_pirq_enable_source(struct intsrc *isrc); static voidxen_intr_pirq_disable_source(struct intsrc *isrc, int eoi); static voidxen_intr_pirq_eoi_source(struct intsrc *isrc); static voidxen_intr_pirq_enable_intr(struct intsrc *isrc); +static voidxen_intr_pirq_disable_intr(struct intsrc *isrc); +static int xen_intr_pirq_config_intr(struct intsrc *isrc, +enum intr_trigger trig, enum intr_polarity pol); /** * PIC interface for all event channel port types except physical IRQs. @@ -163,12 +171,12 @@ struct pic xen_intr_pirq_pic = { .pic_disable_source = xen_intr_pirq_disable_source, .pic_eoi_source = xen_intr_pirq_eoi_source, .pic_enable_intr= xen_intr_pirq_enable_intr, - .pic_disable_intr = xen_intr_disable_intr, + .pic_disable_intr = xen_intr_pirq_disable_intr, .pic_vector = xen_intr_vector, .pic_source_pending = xen_intr_source_pending, .pic_suspend= xen_intr_suspend, .pic_resume = xen_intr_resume, - .pic_config_intr= xen_intr_config_intr, + .pic_config_intr= xen_intr_pirq_config_intr, .pic_assign_cpu = xen_intr_assign_cpu }; @@ -282,11 +290,10 @@ xen_intr_find_unused_isrc(enum evtchn_type type) * object or NULL. */ static struct xenisrc * -xen_intr_alloc_isrc(enum evtchn_type type) +xen_intr_alloc_isrc(enum evtchn_type type, int vector) { static int warned; struct xenisrc *isrc; - int vector; KASSERT(mtx_owned(&xen_intr_isrc_lock), ("Evtchn alloc lock not held")); @@ -297,12 +304,19 @@ xen_intr_alloc_isrc(enum evtchn_type type) } return (NULL); } - vector = FIRST_EVTCHN_INT + xen_intr_isrc_count; - xen_intr_isrc_count++; + + if (type != EVTCHN_TYPE_PIRQ) { + vector = FIRST_EVTCHN_INT + xen_intr_isrc_count; + xen_intr_isrc_count++; + } + + KASSERT((intr_lookup_source(vector) == NULL), + ("Trying to use an already allocated vector")); mtx_unlock(&xen_intr_isrc_lock); isrc = malloc(sizeof(*isrc), M_XENINTR, M_WAITOK | M_ZERO); - isrc->xi_intsrc.is_pic = &xen_intr_pic; + isrc->xi_intsrc.is_pic = (type == EVTCHN_TYPE_PIRQ) ? + &xen_intr_pirq_pic : &xen_intr_pic; isrc->xi_vector = vector; isrc->xi_type = type; intr_register_source(&isrc->xi_intsrc); @@ -388,7 +402,7 @@ xen_intr_bind_isrc(struct xenisrc **isrcp, evtchn_port_t local_port, mtx_lock(&xen_intr_isrc_lock); isrc = xen_intr_find_unused_isrc(type); if (isrc == NULL) { - isrc = xen_intr_alloc_isrc(type); + isrc = xen_intr_alloc_isrc(type, 0); if (isrc == NULL) { mtx_unlock(&xen_intr_isrc_lock); return (ENOSPC); @@ -592,6 +606,10 @@ xen_intr_init(void *dummy __unused) } intr_register_pic(&xen_intr_pic); + intr_register_pic(&xen_intr_pirq_pic); + + if (bootverbose) + printf("Xen interrupt system initialized\n"); return (0); } @@ -925,6 +943,9 @@ xen_intr_pirq_disable_source(struct intsrc *base_isrc, int eoi) isrc = (struct xenisrc *)base_isrc; evtchn_mask_port(isrc->xi_port); + + if (eoi == PIC_EOI) + xen_intr_pirq_eoi_source(base_isrc); } /* @@ -966,8 +987,115 @@ xen_intr_pirq_eoi_source(struct intsrc *base_isrc) * \param isrc The interrupt source to enable. */ static void -xen_intr_pirq_enable_intr(struct intsrc *isrc) +xen_intr_pirq_enable_intr(struct intsrc *base_isrc) +{ + struct xenisrc *isrc; + struct evtchn_bind_pirq bind_pirq; + struct physdev_irq_stat
[PATCH RFC 02/13] ioapic: introduce hooks for some ioapic ops
Create some hooks for IO APIC operations that will diverge from bare metal when implemented for Xen Dom0. This patch should not introduce any changes in functionality, it's a preparatory patch for the implementation of the Xen IO APIC hooks. --- sys/amd64/include/apicvar.h | 13 sys/i386/include/apicvar.h | 13 sys/x86/include/apicreg.h | 12 sys/x86/x86/io_apic.c | 65 ++- 4 files changed, 71 insertions(+), 32 deletions(-) diff --git a/sys/amd64/include/apicvar.h b/sys/amd64/include/apicvar.h index 84e01d4..a48a76b 100644 --- a/sys/amd64/include/apicvar.h +++ b/sys/amd64/include/apicvar.h @@ -161,6 +161,19 @@ struct apic_enumerator { SLIST_ENTRY(apic_enumerator) apic_next; }; +struct ioapic_intsrc { + struct intsrc io_intsrc; + u_int io_irq; + u_int io_intpin:8; + u_int io_vector:8; + u_int io_cpu:8; + u_int io_activehi:1; + u_int io_edgetrigger:1; + u_int io_masked:1; + int io_bus:4; + uint32_t io_lowreg; +}; + inthand_t IDTVEC(apic_isr1), IDTVEC(apic_isr2), IDTVEC(apic_isr3), IDTVEC(apic_isr4), IDTVEC(apic_isr5), IDTVEC(apic_isr6), diff --git a/sys/i386/include/apicvar.h b/sys/i386/include/apicvar.h index 24c99f0..c8ee9bc 100644 --- a/sys/i386/include/apicvar.h +++ b/sys/i386/include/apicvar.h @@ -160,6 +160,19 @@ struct apic_enumerator { SLIST_ENTRY(apic_enumerator) apic_next; }; +struct ioapic_intsrc { + struct intsrc io_intsrc; + u_int io_irq; + u_int io_intpin:8; + u_int io_vector:8; + u_int io_cpu:8; + u_int io_activehi:1; + u_int io_edgetrigger:1; + u_int io_masked:1; + int io_bus:4; + uint32_t io_lowreg; +}; + inthand_t IDTVEC(apic_isr1), IDTVEC(apic_isr2), IDTVEC(apic_isr3), IDTVEC(apic_isr4), IDTVEC(apic_isr5), IDTVEC(apic_isr6), diff --git a/sys/x86/include/apicreg.h b/sys/x86/include/apicreg.h index 283d50e..4629470 100644 --- a/sys/x86/include/apicreg.h +++ b/sys/x86/include/apicreg.h @@ -204,6 +204,18 @@ struct IOAPIC { typedef struct IOAPIC ioapic_t; +struct ioapic_intsrc; +/* + * Struct containing pointers to IO APIC management functions whose + * implementation is run time selectable. + */ +struct ioapic_ops { + u_int(*read)(volatile ioapic_t *, int); + void (*write)(volatile ioapic_t *, int, u_int); + void (*register_intr)(struct ioapic_intsrc *); +}; +extern struct ioapic_ops ioapic_ops; + #undef PAD4 #undef PAD3 diff --git a/sys/x86/x86/io_apic.c b/sys/x86/x86/io_apic.c index 6d62b1e..125d06a 100644 --- a/sys/x86/x86/io_apic.c +++ b/sys/x86/x86/io_apic.c @@ -81,19 +81,6 @@ static MALLOC_DEFINE(M_IOAPIC, "io_apic", "I/O APIC structures"); * ftp://download.intel.com/design/chipsets/datashts/29056601.pdf */ -struct ioapic_intsrc { - struct intsrc io_intsrc; - u_int io_irq; - u_int io_intpin:8; - u_int io_vector:8; - u_int io_cpu:8; - u_int io_activehi:1; - u_int io_edgetrigger:1; - u_int io_masked:1; - int io_bus:4; - uint32_t io_lowreg; -}; - struct ioapic { struct pic io_pic; u_int io_id:8; /* logical ID */ @@ -106,8 +93,9 @@ struct ioapic { struct ioapic_intsrc io_pins[0]; }; -static u_int ioapic_read(volatile ioapic_t *apic, int reg); -static voidioapic_write(volatile ioapic_t *apic, int reg, u_int val); +static u_int native_ioapic_read(volatile ioapic_t *apic, int reg); +static voidnative_ioapic_write(volatile ioapic_t *apic, int reg, u_int val); +static voidnative_ioapic_register_intr(struct ioapic_intsrc *pin); static const char *ioapic_bus_string(int bus_type); static voidioapic_print_irq(struct ioapic_intsrc *intpin); static voidioapic_enable_source(struct intsrc *isrc); @@ -139,6 +127,13 @@ SYSCTL_INT(_hw_apic, OID_AUTO, enable_extint, CTLFLAG_RDTUN, &enable_extint, 0, "Enable the ExtINT pin in the first I/O APIC"); TUNABLE_INT("hw.apic.enable_extint", &enable_extint); +/* Default ioapic_ops implementation. */ +struct ioapic_ops ioapic_ops = { + .read = native_ioapic_read, + .write =native_ioapic_write, + .register_intr =native_ioapic_register_intr, +}; + static __inline void _ioapic_eoi_source(struct intsrc *isrc) { @@ -146,7 +141,7 @@ _ioapic_eoi_source(struct intsrc *isrc) } static u_int -ioapic_read(volatile ioapic_t *apic, int reg) +native_ioapic_read(volatile ioapic_t *apic, int reg) { mtx_assert(&icu_lock, MA_OWNED); @@ -155,7 +150,7 @@ ioapic_read(volatile ioapic_t *apic, int reg) } static void -ioapic_write(volatile ioapic_t *apic, int reg, u_int val) +native_ioapic_write(volatile ioapic_t *apic, int reg, u_int val) { mtx_assert(&icu_lock, MA_OWNED); @@ -163,6 +158,12 @@ ioapic_write(volatile ioapic_t *apic, int reg, u_int val) a
[PATCH RFC 05/13] xen: implement Xen IO APIC ops
Implement a different set of hooks for IO APIC to use when running under Xen Dom0. --- sys/x86/xen/pv.c | 44 1 files changed, 44 insertions(+), 0 deletions(-) diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c index ab4afba..e5ad200 100644 --- a/sys/x86/xen/pv.c +++ b/sys/x86/xen/pv.c @@ -49,6 +49,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include #include @@ -58,6 +59,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include @@ -73,6 +75,11 @@ static caddr_t xen_pv_parse_preload_data(u_int64_t); static void xen_pv_parse_memmap(caddr_t, vm_paddr_t *, int *); static void xen_pv_set_init_ops(void); + +static u_int xen_pv_ioapic_read(volatile ioapic_t *, int); +static void xen_pv_ioapic_write(volatile ioapic_t *, int, u_int); +static void xen_pv_ioapic_register_intr(struct ioapic_intsrc *); + /* Extern Declarations ---*/ /* Variables used by amd64 mp_machdep to start APs */ extern struct mtx ap_boot_mtx; @@ -92,6 +99,13 @@ struct init_ops xen_init_ops = { .parse_memmap = xen_pv_parse_memmap, }; +/* Xen ioapic_ops implementation */ +struct ioapic_ops xen_ioapic_ops = { + .read = xen_pv_ioapic_read, + .write =xen_pv_ioapic_write, + .register_intr =xen_pv_ioapic_register_intr, +}; + static struct { const char *ev; @@ -342,6 +356,34 @@ xen_pv_parse_memmap(caddr_t kmdp, vm_paddr_t *physmap, int *physmap_idx) bios_add_smap_entries(xen_smap, size, physmap, physmap_idx); } +static u_int +xen_pv_ioapic_read(volatile ioapic_t *apic, int reg) +{ + struct physdev_apic apic_op; + int rc; + + mtx_assert(&icu_lock, MA_OWNED); + + apic_op.apic_physbase = pmap_kextract((vm_offset_t) apic); + apic_op.reg = reg; + rc = HYPERVISOR_physdev_op(PHYSDEVOP_apic_read, &apic_op); + if (rc) + panic("apic_read operation failed"); + + return (apic_op.value); +} + +static void +xen_pv_ioapic_write(volatile ioapic_t *apic, int reg, u_int val) +{ +} + +static void +xen_pv_ioapic_register_intr(struct ioapic_intsrc *pin) +{ + xen_register_pirq(pin->io_irq, pin->io_activehi, pin->io_edgetrigger); +} + static void xen_pv_set_init_ops(void) { @@ -349,4 +391,6 @@ xen_pv_set_init_ops(void) init_ops = xen_init_ops; /* Disable lapic */ lapic_disabled = true; + /* IOAPIC ops for Xen PV */ + ioapic_ops = xen_ioapic_ops; } -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 06/13] xen: Dom0 console fixes
Minor fixes and workarounds to make the Xen Dom0 console work. --- sys/dev/xen/console/xencons_ring.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/sys/dev/xen/console/xencons_ring.c b/sys/dev/xen/console/xencons_ring.c index d826363..ea97f7b 100644 --- a/sys/dev/xen/console/xencons_ring.c +++ b/sys/dev/xen/console/xencons_ring.c @@ -48,6 +48,9 @@ xencons_has_input(void) { struct xencons_interface *intf; + if (xen_initial_domain()) + return 1; + intf = xencons_interface(); return (intf->in_cons != intf->in_prod); @@ -97,6 +100,19 @@ xencons_handle_input(void *unused) XENCONS_RING_IDX cons, prod; CN_LOCK(cn_mtx); + + if (xen_initial_domain()) { + /* XXX: read from console */ + static char rbuf[16]; + int l; + + while ((l = HYPERVISOR_console_io(CONSOLEIO_read, 16, rbuf)) > 0) + xencons_rx(rbuf, l); + + CN_UNLOCK(cn_mtx); + return; + } + intf = xencons_interface(); cons = intf->in_cons; -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 03/13] xen: mask event channels while changing affinity
Event channels should be masked while chaning affinity, or else we might get spurious/lost interrupts. --- sys/x86/xen/xen_intr.c | 15 --- 1 files changed, 12 insertions(+), 3 deletions(-) diff --git a/sys/x86/xen/xen_intr.c b/sys/x86/xen/xen_intr.c index fd36e68..bc0781e 100644 --- a/sys/x86/xen/xen_intr.c +++ b/sys/x86/xen/xen_intr.c @@ -797,7 +797,7 @@ xen_intr_assign_cpu(struct intsrc *base_isrc, u_int apic_id) struct evtchn_bind_vcpu bind_vcpu; struct xenisrc *isrc; u_int to_cpu, vcpu_id; - int error; + int error, masked; #ifdef XENHVM if (xen_vector_callback_enabled == 0) @@ -815,6 +815,12 @@ xen_intr_assign_cpu(struct intsrc *base_isrc, u_int apic_id) return (EINVAL); } + /* +* Mask the event channel port so we don't receive spurious events +* while changing affinity. +*/ + masked = evtchn_test_and_set_mask(isrc->xi_port); + if ((isrc->xi_type == EVTCHN_TYPE_VIRQ) || (isrc->xi_type == EVTCHN_TYPE_IPI)) { /* @@ -825,8 +831,7 @@ xen_intr_assign_cpu(struct intsrc *base_isrc, u_int apic_id) evtchn_cpu_mask_port(isrc->xi_cpu, isrc->xi_port); isrc->xi_cpu = to_cpu; evtchn_cpu_unmask_port(isrc->xi_cpu, isrc->xi_port); - mtx_unlock(&xen_intr_isrc_lock); - return (0); + goto out; } bind_vcpu.port = isrc->xi_port; @@ -848,6 +853,10 @@ xen_intr_assign_cpu(struct intsrc *base_isrc, u_int apic_id) evtchn_cpu_mask_port(to_cpu, isrc->xi_port); } } + +out: + if (!masked) + evtchn_unmask_port(isrc->xi_port); mtx_unlock(&xen_intr_isrc_lock); return (0); #else -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 08/13] xen: change order of Xen intr init and IO APIC registration
Change order of some of the services in the SI_SUB_INTR stage, so that it follows the order: - System intr initialization - Xen intr initalization - IO APIC source registration --- sys/x86/x86/local_apic.c |2 +- sys/x86/xen/xen_intr.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sys/x86/x86/local_apic.c b/sys/x86/x86/local_apic.c index 85736c8..c206281 100644 --- a/sys/x86/x86/local_apic.c +++ b/sys/x86/x86/local_apic.c @@ -1383,7 +1383,7 @@ apic_setup_io(void *dummy __unused) /* Enable the MSI "pic". */ msi_init(); } -SYSINIT(apic_setup_io, SI_SUB_INTR, SI_ORDER_SECOND, apic_setup_io, NULL); +SYSINIT(apic_setup_io, SI_SUB_INTR, SI_ORDER_THIRD, apic_setup_io, NULL); #ifdef SMP /* diff --git a/sys/x86/xen/xen_intr.c b/sys/x86/xen/xen_intr.c index 340e5ed..700fd22 100644 --- a/sys/x86/xen/xen_intr.c +++ b/sys/x86/xen/xen_intr.c @@ -613,7 +613,7 @@ xen_intr_init(void *dummy __unused) return (0); } -SYSINIT(xen_intr_init, SI_SUB_INTR, SI_ORDER_MIDDLE, xen_intr_init, NULL); +SYSINIT(xen_intr_init, SI_SUB_INTR, SI_ORDER_SECOND, xen_intr_init, NULL); /*--- Common PIC Functions ---*/ /** -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 01/13] xen: use the hardware e820 map on Dom0
We need to do some tweaking of the hardware e820 map, since the memory layout provided by Xen and the e820 map doesn't match. This consists in clamping the e820 map so that regions above max_pfn are marked as unusuable. --- sys/x86/xen/pv.c | 35 +-- 1 files changed, 33 insertions(+), 2 deletions(-) diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c index 4f7415e..ab4afba 100644 --- a/sys/x86/xen/pv.c +++ b/sys/x86/xen/pv.c @@ -297,17 +297,48 @@ static void xen_pv_parse_memmap(caddr_t kmdp, vm_paddr_t *physmap, int *physmap_idx) { struct xen_memory_map memmap; + unsigned long max_pfn = HYPERVISOR_start_info->nr_pages; + u_int64_t mem_end = ptoa(max_pfn); u_int32_t size; - int rc; + int rc, mem_op, i; /* Fetch the E820 map from Xen */ memmap.nr_entries = MAX_E820_ENTRIES; set_xen_guest_handle(memmap.buffer, xen_smap); - rc = HYPERVISOR_memory_op(XENMEM_memory_map, &memmap); + mem_op = xen_initial_domain() ? + XENMEM_machine_memory_map : + XENMEM_memory_map; + rc = HYPERVISOR_memory_op(mem_op, &memmap); if (rc) panic("unable to fetch Xen E820 memory map"); size = memmap.nr_entries * sizeof(xen_smap[0]); + /* +* This should be improved, Xen provides us with a single +* chunk of physical memory that goes from 0 to max_pfn, +* and what we do here is clamp the HW memory map to make +* sure regions above max_pfn are marked as reserved. +* +* TRTTD would be to move the memory not used because of +* the holes in the HW memory map to the now clamped regions +* using XENMEM_{decrease/increase}_reservation. +*/ + for (i = 0; i < memmap.nr_entries; i++) { + u_int64_t end = xen_smap[i].base + xen_smap[i].length; + if (xen_smap[i].type == SMAP_TYPE_MEMORY) { + if (xen_smap[i].base > mem_end) { + /* Mark as reserved */ + xen_smap[i].type = SMAP_TYPE_RESERVED; + continue; + } + if (end > mem_end) { + /* Truncate region */ + xen_smap[i].length -= end - mem_end; + } + } + } + + bios_add_smap_entries(xen_smap, size, physmap, physmap_idx); } -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[PATCH RFC 07/13] xen: implement IO APIC support in Xen mptable parser
Use madt_setup_io (from madt.c) on Xen apic_enumerator, in order to parse the interrupt sources from the IO APIC. I would like to get opinions, but I think we should rename and move madt_setup_io to io_apic.c. --- sys/amd64/include/apicvar.h |1 + sys/i386/include/apicvar.h |1 + sys/x86/acpica/madt.c |5 ++--- sys/x86/xen/mptable.c | 24 +++- 4 files changed, 27 insertions(+), 4 deletions(-) diff --git a/sys/amd64/include/apicvar.h b/sys/amd64/include/apicvar.h index a48a76b..3974067 100644 --- a/sys/amd64/include/apicvar.h +++ b/sys/amd64/include/apicvar.h @@ -233,6 +233,7 @@ int lapic_set_lvt_triggermode(u_int apic_id, u_int lvt, void lapic_set_tpr(u_int vector); void lapic_setup(int boot); void xen_intr_handle_upcall(struct trapframe *frame); +intmadt_setup_io(void); #endif /* !LOCORE */ #endif /* _MACHINE_APICVAR_H_ */ diff --git a/sys/i386/include/apicvar.h b/sys/i386/include/apicvar.h index c8ee9bc..05ec013 100644 --- a/sys/i386/include/apicvar.h +++ b/sys/i386/include/apicvar.h @@ -232,6 +232,7 @@ int lapic_set_lvt_triggermode(u_int apic_id, u_int lvt, void lapic_set_tpr(u_int vector); void lapic_setup(int boot); void xen_intr_handle_upcall(struct trapframe *frame); +intmadt_setup_io(void); #endif /* !LOCORE */ #endif /* _MACHINE_APICVAR_H_ */ diff --git a/sys/x86/acpica/madt.c b/sys/x86/acpica/madt.c index 5929fde..6f3b591 100644 --- a/sys/x86/acpica/madt.c +++ b/sys/x86/acpica/madt.c @@ -61,7 +61,7 @@ static struct lapic_info { } lapics[MAX_APIC_ID + 1]; static int madt_found_sci_override; -static ACPI_TABLE_MADT *madt; +ACPI_TABLE_MADT *madt; static vm_paddr_t madt_physaddr; static vm_offset_t madt_length; @@ -84,7 +84,6 @@ static void madt_probe_cpus_handler(ACPI_SUBTABLE_HEADER *entry, void *arg __unused); static voidmadt_register(void *dummy); static int madt_setup_local(void); -static int madt_setup_io(void); static voidmadt_walk_table(acpi_subtable_handler *handler, void *arg); static struct apic_enumerator madt_enumerator = { @@ -147,7 +146,7 @@ madt_setup_local(void) /* * Enumerate I/O APICs and setup interrupt sources. */ -static int +int madt_setup_io(void) { void *ioapic; diff --git a/sys/x86/xen/mptable.c b/sys/x86/xen/mptable.c index 0384886..46b03f3 100644 --- a/sys/x86/xen/mptable.c +++ b/sys/x86/xen/mptable.c @@ -43,6 +43,9 @@ __FBSDID("$FreeBSD$"); #include #include +#include +#include + #include #include @@ -51,6 +54,9 @@ __FBSDID("$FreeBSD$"); #include +/* From madt.c */ +extern ACPI_TABLE_MADT *madt; + static int xenpv_probe(void); static int xenpv_probe_cpus(void); static int xenpv_setup_local(void); @@ -107,7 +113,23 @@ xenpv_setup_local(void) static int xenpv_setup_io(void) { - return (0); + vm_paddr_t madt_physaddr; + vm_offset_t madt_length; + + if (!xen_initial_domain()) + return (0); + + madt_physaddr = acpi_find_table(ACPI_SIG_MADT); + if (madt_physaddr == 0) + panic("could not find MADT table"); + madt = acpi_map_table(madt_physaddr, ACPI_SIG_MADT); + if (madt == NULL) + panic("unable to map MADT"); + madt_length = madt->Header.Length; + acpi_unmap_table(madt); + madt = pmap_mapbios(madt_physaddr, madt_length); + + return (madt_setup_io()); } static void -- 1.7.7.5 (Apple Git-26) ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"