search for: xen_arch_setup

...mory? > + return 0; > +} > + > +static int xen_idle_init(void) > +{ > + int retval, i; > + retval = cpuidle_register_driver(&xen_idle_driver); > + > + for_each_online_cpu(i) { > + setup_cpuidle(i); > + } > + > + return 0; > +} > + > void __init xen_arch_setup(void) > { > xen_panic_handler_init(); > @@ -354,7 +394,7 @@ void __init xen_arch_setup(void) > #ifdef CONFIG_X86_32 > boot_cpu_data.hlt_works_ok = 1; > #endif > - pm_idle = default_idle; > + xen_idle_init(); > boot_option_idle_override = IDLE_HALT; > >...

...a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -20,6 +20,7 @@ #include <asm/numa.h> #include <asm/xen/hypervisor.h> #include <asm/xen/hypercall.h> +#include <asm/xen/vnuma.h> #include <xen/xen.h> #include <xen/page.h> @@ -598,6 +599,9 @@ void __init xen_arch_setup(void) WARN_ON(xen_set_default_idle()); fiddle_vdso(); #ifdef CONFIG_NUMA - numa_off = 1; + if (!xen_initial_domain() && xen_vnuma_supported()) + numa_off = 0; + else + numa_off = 1; #endif } -- 1.7.10.4

...* fmt, ...){ ... atomic_notifier_call_chain(&panic_notifier_list, 0, buf); } When xen aware this, it will call xen_reboot(SHUTDOWN_crash) to send out an event with reason code - SHUTDOWN_crash. xen_panic_handler_init() is defined to register on panic_notifier_list but we only call it in xen_arch_setup which only be called by pvm, this patch is necessary for pvhvm. Signed-off-by: Vaughan Cao <vaughan.cao at oracle.com> --- arch/x86/xen/enlighten.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 4aec5ed..53e5726 100644 --- a/...

...* fmt, ...){ ... atomic_notifier_call_chain(&panic_notifier_list, 0, buf); } When xen aware this, it will call xen_reboot(SHUTDOWN_crash) to send out an event with reason code - SHUTDOWN_crash. xen_panic_handler_init() is defined to register on panic_notifier_list but we only call it in xen_arch_setup which only be called by pvm, this patch is necessary for pvhvm. Signed-off-by: Vaughan Cao <vaughan.cao at oracle.com> --- arch/x86/xen/enlighten.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 4aec5ed..53e5726 100644 --- a/...

...* fmt, ...){ ... atomic_notifier_call_chain(&panic_notifier_list, 0, buf); } When xen aware this, it will call xen_reboot(SHUTDOWN_crash) to send out an event with reason code - SHUTDOWN_crash. xen_panic_handler_init() is defined to register on panic_notifier_list but we only call it in xen_arch_setup which only be called by pvm, this patch is necessary for pvhvm. Signed-off-by: Vaughan Cao <vaughan.cao at oracle.com> --- arch/x86/xen/enlighten.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 4aec5ed..53e5726 100644 --- a/...

...xen/setup.c | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 0982233..66bb6f5 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -625,3 +625,22 @@ void __init xen_arch_setup(void) > numa_off = 1; > #endif > } > + > +#ifdef CONFIG_PARAVIRT_UNFAIR_LOCKS > +/* > + * Enable unfair lock if running in a Xen guest > + */ > +static __init int xen_unfair_locks_init_jump(void) > +{ > + /* > + * Disable unfair lock if not running in a PV d...

...xen/setup.c | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > index 0982233..66bb6f5 100644 > --- a/arch/x86/xen/setup.c > +++ b/arch/x86/xen/setup.c > @@ -625,3 +625,22 @@ void __init xen_arch_setup(void) > numa_off = 1; > #endif > } > + > +#ifdef CONFIG_PARAVIRT_UNFAIR_LOCKS > +/* > + * Enable unfair lock if running in a Xen guest > + */ > +static __init int xen_unfair_locks_init_jump(void) > +{ > + /* > + * Disable unfair lock if not running in a PV d...

...th rings in memory? > Being broken on PPC is really > the least of their problems. > > So, what do we do? It'd be nice if Linux virtio Just Worked under Xen, > though Xen's IOMMU is outside the virtio spec. Since virtio_pci can be > a module, obvious hacks like having xen_arch_setup initialize a dma_ops pointer > exposed by virtio_pci.c is out. Well virtio could probe for xen, it's not a lot of code. > I think the best approach is to have a new feature bit (25 is free), > VIRTIO_F_USE_BUS_MAPPING which indicates that a device really wants to > use the mapping...

...th rings in memory? > Being broken on PPC is really > the least of their problems. > > So, what do we do? It'd be nice if Linux virtio Just Worked under Xen, > though Xen's IOMMU is outside the virtio spec. Since virtio_pci can be > a module, obvious hacks like having xen_arch_setup initialize a dma_ops pointer > exposed by virtio_pci.c is out. Well virtio could probe for xen, it's not a lot of code. > I think the best approach is to have a new feature bit (25 is free), > VIRTIO_F_USE_BUS_MAPPING which indicates that a device really wants to > use the mapping...

...t allocated by the driver. Being broken on PPC is really > the least of their problems. > > So, what do we do? It'd be nice if Linux virtio Just Worked under Xen, > though Xen's IOMMU is outside the virtio spec. Since virtio_pci can be > a module, obvious hacks like having xen_arch_setup initialize a dma_ops pointer > exposed by virtio_pci.c is out. Xen does expose dma_ops. The trick is knowing when to use it. > > I think the best approach is to have a new feature bit (25 is free), > VIRTIO_F_USE_BUS_MAPPING which indicates that a device really wants to > use the...

...t allocated by the driver. Being broken on PPC is really > the least of their problems. > > So, what do we do? It'd be nice if Linux virtio Just Worked under Xen, > though Xen's IOMMU is outside the virtio spec. Since virtio_pci can be > a module, obvious hacks like having xen_arch_setup initialize a dma_ops pointer > exposed by virtio_pci.c is out. Xen does expose dma_ops. The trick is knowing when to use it. > > I think the best approach is to have a new feature bit (25 is free), > VIRTIO_F_USE_BUS_MAPPING which indicates that a device really wants to > use the...

When booting 2.6.37 (from kernel.org) under Xen 4.1, there are apparently issues with timer interrupts being delivered to the dom0. Repeatedly causing an interrupt (for example, the ACPI power button) will allow the system to boot, as does adding "clocksource=jiffies" to the kernel command line. This is only present under Xen, not when booting the same kernel on real hardware. When boot

On Tue, Sep 2, 2014 at 1:53 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote: >> >> On x86, at least, I doubt that we'll ever see a physically addressed >> PCI virtio device for which ACPI advertises an IOMMU, since any sane >> hypervisor will just not advertise an IOMMU for the virtio

On Tue, Sep 2, 2014 at 1:53 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > On Mon, 2014-09-01 at 22:55 -0700, Andy Lutomirski wrote: >> >> On x86, at least, I doubt that we'll ever see a physically addressed >> PCI virtio device for which ACPI advertises an IOMMU, since any sane >> hypervisor will just not advertise an IOMMU for the virtio

...ed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Rusty Russell <rusty@rustcorp.com.au> diff -r c79da0042c7d arch/i386/xen/setup.c --- a/arch/i386/xen/setup.c Tue Jun 05 18:17:30 2007 -0700 +++ b/arch/i386/xen/setup.c Tue Jun 05 18:17:59 2007 -0700 @@ -93,4 +93,6 @@ void __init xen_arch_setup(void) /* fill cpus_possible with all available cpus */ xen_fill_possible_map(); #endif + + paravirt_disable_iospace(); }

...ed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com> Cc: Rusty Russell <rusty@rustcorp.com.au> diff -r c79da0042c7d arch/i386/xen/setup.c --- a/arch/i386/xen/setup.c Tue Jun 05 18:17:30 2007 -0700 +++ b/arch/i386/xen/setup.c Tue Jun 05 18:17:59 2007 -0700 @@ -93,4 +93,6 @@ void __init xen_arch_setup(void) /* fill cpus_possible with all available cpus */ xen_fill_possible_map(); #endif + + paravirt_disable_iospace(); }

...9,7 @@ bool set_pm_idle_to_default(void) return ret; } +#endif void stop_this_cpu(void *dummy) { local_irq_disable(); diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 8971a26..2b73b5c 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -561,7 +561,7 @@ void __init xen_arch_setup(void) #endif disable_cpuidle(); disable_cpufreq(); - WARN_ON(set_pm_idle_to_default()); + WARN_ON(xen_set_default_idle()); fiddle_vdso(); #ifdef CONFIG_NUMA numa_off = 1; -- 1.8.1.3.535.ga923c31

...n.Long at hp.com> --- arch/x86/xen/setup.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c index 0982233..66bb6f5 100644 --- a/arch/x86/xen/setup.c +++ b/arch/x86/xen/setup.c @@ -625,3 +625,22 @@ void __init xen_arch_setup(void) numa_off = 1; #endif } + +#ifdef CONFIG_PARAVIRT_UNFAIR_LOCKS +/* + * Enable unfair lock if running in a Xen guest + */ +static __init int xen_unfair_locks_init_jump(void) +{ + /* + * Disable unfair lock if not running in a PV domain + */ + if (!xen_pv_domain()) + return 0; + + static_...

...d, 19 insertions(+), 0 deletions(-) > >> > >> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c > >> index 0982233..66bb6f5 100644 > >> --- a/arch/x86/xen/setup.c > >> +++ b/arch/x86/xen/setup.c > >> @@ -625,3 +625,22 @@ void __init xen_arch_setup(void) > >>?? numa_off = 1; > >>?? #endif > >>?? } > >> + > >> +#ifdef CONFIG_PARAVIRT_UNFAIR_LOCKS > >> +/* > >> + * Enable unfair lock if running in a Xen guest > >> + */ > >> +static __init int xen_unfair_lo...

...rd's MMIO region, not allocated by the driver. Being broken on PPC is really the least of their problems. So, what do we do? It'd be nice if Linux virtio Just Worked under Xen, though Xen's IOMMU is outside the virtio spec. Since virtio_pci can be a module, obvious hacks like having xen_arch_setup initialize a dma_ops pointer exposed by virtio_pci.c is out. I think the best approach is to have a new feature bit (25 is free), VIRTIO_F_USE_BUS_MAPPING which indicates that a device really wants to use the mapping for the bus it is on. A real device would set this, or it won't work behind...