Re: [PATCH 0/6] cpuidle : per cpu latencies
On 09/08/2012 12:17 AM, Rafael J. Wysocki wrote:
> On Friday, September 07, 2012, Daniel Lezcano wrote:
>> Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab,
>> cpuidle: Single/Global registration of idle states
>>
>> we have a single registration for the cpuidle states which makes
>> sense. But now two new architectures are coming: tegra3 and big.LITTLE.
>>
>> These architectures have different cpus with different caracteristics
>> for power saving. High load => powerfull processors, idle => small
>> processors.
>>
>> That implies different cpu latencies.
>>
>> This patchset keeps the current behavior as introduced by Deepthi without
>> breaking the drivers and add the possibility to specify a per cpu states.
>>
>> * Tested on intel core 2 duo T9500
>> * Tested on vexpress by Lorenzo Pieralsi
>> * Tested on tegra3 by Peter De Schrijver
>>
>> Daniel Lezcano (6):
>> acpi : move the acpi_idle_driver variable declaration
>> acpi : move cpuidle_device field out of the acpi_processor_power
>> structure
>> acpi : remove pointless cpuidle device state_count init
>
> I've posted comments about patches [1-3/6] already. In short, I don't like
> [1/6], [2/6] would require some more work IMO and I'm not sure about the
> validity of the observation that [3/6] is based on.
>
> Yes, I agree that the ACPI processor driver as a whole might be cleaner
> and it probably would be good to spend some time on cleaning it up, but
> not necessarily in a hurry.
>
> Unfortunately, I also don't agree with the approach used by the remaining
> patches, which is to try to use a separate array of states for each
> individual CPU core. This way we end up with quite some duplicated data
> if the CPU cores in question actually happen to be identical.
Actually, there is a single array of states which is defined with the
cpuidle_driver. A pointer to this array from the cpuidle_device
structure is added and used from the cpuidle core.
If the cpu cores are identical, this pointer will refer to the same array.
Maybe I misunderstood you remark but there is no data duplication, that
was the purpose of this approach to just add a pointer to point to a
single array when the core are identical and to a different array when
the cores are different (set by the driver). Furthermore, this patch
allows to support multiple cpu latencies without impacting the existing
drivers.
> What about using a separate cpuidle driver for every kind of different CPUs in
> the system (e.g. one driver for "big" CPUs and the other for "little" ones)?
>
> Have you considered this approach already?
No, what would be the benefit of this approach ? We will need to switch
the driver each time we switch the cluster (assuming all it is the bL
switcher in place and not the scheduler). IMHO, that could be suboptimal
because we will have to (un)register the driver, register the devices,
pull all the sysfs and notifications mechanisms. The cpuidle core is not
designed for that.
eg.
int cpuidle_register_driver(struct cpuidle_driver *drv)
{
if (!drv || !drv->state_count)
return -EINVAL;
if (cpuidle_disabled())
return -ENODEV;
spin_lock(&cpuidle_driver_lock);
if (cpuidle_curr_driver) {
spin_unlock(&cpuidle_driver_lock);
return -EBUSY;
}
__cpuidle_register_driver(drv);
cpuidle_curr_driver = drv;
spin_unlock(&cpuidle_driver_lock);
return 0;
}
>> cpuidle : add a pointer for cpuidle_state in the cpuidle_device
>> cpuidle : use per cpuidle device cpu states
>> cpuidle : add cpuidle_register_states function
>>
>> drivers/acpi/processor_driver.c|2 +-
>> drivers/acpi/processor_idle.c | 27 +++---
>> drivers/cpuidle/cpuidle.c | 42
>> ---
>> drivers/cpuidle/governors/ladder.c | 22 +-
>> drivers/cpuidle/governors/menu.c |8 +++---
>> drivers/cpuidle/sysfs.c|3 +-
>> include/acpi/processor.h |3 --
>> include/linux/cpuidle.h| 11 ++--
>> 8 files changed, 76 insertions(+), 42 deletions(-)
>
> Thanks,
> Rafael
--
Facebook |
Twitter |
Re: fastmodel run over ubuntu 64bit machine
Hi Lei, I'm copying Andy Doan directly on this, since he's had more experience of getting FM working in LAVA and can probably point you in the right direction. Thanks Dave On 14 Sep 2012, at 14:35, Lei Wen wrote: > Hi Dave, > > On Fri, Sep 14, 2012 at 3:58 PM, Dave Pigott wrote: > Hi Lei, > > We run Fast Models on 64 bit all the time. How are you creating the model, > and how are you trying to launch it? > > I launch the fast model by below command: > model_shell cadi_system_Linux64-Release-GCC-4.4.so > boot-wrapper/linux-system-semi.axf -f params > > And it is interested that while I just run the "./isim_system", there is no > such error report out. > But I don't know to use isim_system to launch this simulation... > > > Dave > > On 14 Sep 2012, at 08:40, Lei Wen wrote: > > > Hi, > > > > Does anyone try to run the fastmodel over ubuntu 64bit machine? > > I try to run the simulation over Cortex-A15 model, but get below error > > message when start: > > "Fatal Error: No CreateCADIBroker entry point found. Not a CADI 2.0 model ?" > > > > Anyone knows what this message means? Do I need any additional > > configuration to bring up > > the fastmodel over 64bit ubuntu? > > > > Thanks, > > Lei > > ___ > > linaro-dev mailing list > > linaro-dev@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > Thanks, > Lei ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM
Hello. On 09/14/2012 03:13 PM, Stefano Stabellini wrote: > Changes in v2: > - mark Xen guest support on ARM as EXPERIMENTAL. > Signed-off-by: Stefano Stabellini > Acked-by: Konrad Rzeszutek Wilk > --- > arch/arm/Kconfig | 10 ++ > 1 files changed, 10 insertions(+), 0 deletions(-) > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 2f88d8d..e92518d 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT > This was deprecated in 2001 and announced to live on for 5 years. > Some old boot loaders still use this way. > > +config XEN_DOM0 > + def_bool y > + > +config XEN > + bool "Xen guest support on ARM (EXPERIMENTAL)" > + depends on EXPERIMENTAL && ARM && OF > + select XEN_DOM0 What's the point of selecting it if it's always "y"? WBR, Sergei ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[GIT PULL]: big LITTLE MP v8
Hi Andrey, This is PULL request for big LITTLE MP v8 branch: Major updates are: - Based on v3.6-rc5 - new branch from Paulm: rcu-hotplug-v1, vincent: scheduler-misc-v1 and sudeepk arm-multi_pmu_v1 - new version of patches from Morten: task-placement-v2 - config fragment updated for fast & slow cpu Compile tested only. -x-x--- The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217: Linux 3.6-rc5 (2012-09-08 16:43:45 -0700) are available in the git repository at: git://git.linaro.org/arm/big.LITTLE/mp.git big-LITTLE-MP-v8 for you to fetch changes up to eb07c27e2987ab3c16cedee1367694988efe3ff4: Merge branches 'per-cpu-thread-hotplug-v3-fixed', 'task-placement-v2', 'cpu-hotplug-get_online_cpus-v1', 'arm-asymmetric-support-v3-v3.6-rc1', 'rcu-hotplug-v1', 'arm-multi_pmu_v1', 'scheduler-misc-v1' and 'config-fragments' into big-LITTLE-MP-v8 (2012-09-17 09:26:07 +0530) Axel Lin (1): ARM: ux500: Fix build error due to missing include of asm/pmu.h in cpu-db8500.c Ben Segall (1): sched: maintain per-rq runnable averages Jon Hunter (1): ARM: PMU: Add runtime PM Support Jon Medhurst (6): configs: Initial core configs configs: Make CONFIG_MODULES part of linaro-base Merge branch 'config-core-3.4' into config-core-tracking configs: Replace CONFIG_PERF_COUNTERS with CONFIG_PERF_EVENTS configs: android: Enable FB_EARLYSUSPEND configs: android: Enable CONFIG_INPUT_UINPUT to get aidb working Lorenzo Pieralisi (1): ARM: kernel: provide cluster to logical cpu mask mapping API Morten Rasmussen (10): sched: entity load-tracking load_avg_ratio sched: Task placement for heterogeneous systems based on task load-tracking sched: Forced task migration on heterogeneous systems sched: Introduce priority-based task migration filter ARM: Add HMP scheduling support for ARM architecture ARM: sched: Use device-tree to provide fast/slow CPU list for HMP ARM: sched: Setup SCHED_HMP domains sched: Add ftrace events for entity load-tracking sched: Add HMP task migration ftrace event sched: SCHED_HMP multi-domain task migration control Paul E. McKenney (4): rcu: Use smp_hotplug_thread facility for RCUs per-CPU kthread hotplug: Fix UP bug in smpboot hotplug code rcu: Remove _rcu_barrier() dependency on __stop_machine() rcu: Disallow callback registry on offline CPUs Paul Turner (15): sched: track the runnable average on a per-task entitiy basis sched: aggregate load contributed by task entities on parenting cfs_rq sched: maintain the load contribution of blocked entities sched: add an rq migration call-back to sched_class sched: account for blocked load waking back up sched: aggregate total task_group load sched: compute load contribution by a group entity sched: normalize tg load contributions against runnable time sched: maintain runnable averages across throttled periods sched: replace update_shares weight distribution with per-entity computation sched: refactor update_shares_cpu() -> update_blocked_avgs() sched: update_cfs_shares at period edge sched: make __update_entity_runnable_avg() fast sched: implement usage tracking sched: introduce temporary FAIR_GROUP_SCHED dependency for load-tracking Peter Zijlstra (1): sched: Fix load avg vs cpu-hotplug Ricardo Salveti de Araujo (8): configs: moving previous ubuntu.conf as ubuntu-minimal and creating a full ubuntu one configs: ubuntu: be compatible with the enforce script configs: ubuntu: disabling CODA_FS, seems to be broken atm configs: ubuntu: disabling CGROUPS as default Merge branch 'config-core-3.4' into config-core-tracking configs: ubuntu: updating configs for 3.5 configs: ubuntu: disabling CONFIG_MTD_NAND_NANDSIM=m, breaking build config: ubuntu: ATH6KL should be platform dependent Silas Boyd-Wickizer (6): Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Sudeep KarkadaNagesha (9): ARM: pmu: remove arm_pmu_type enumeration ARM: perf: move irq registration into pmu implementation ARM: perf: allocation of cpu_pmu at init time ARM: perf: change multiple arm_pmu function parameters to struct perf_event ARM: perf: rework on armv7_pmnc_counter_valid ARM: perf: define per-cpu arm_pmu instead of a single global pointer ARM: perf: regi
Re: [PATCH v2 3/3] devfreq: Add current freq callback in device profile
> From: Rajagopal Venkat
>
> Devfreq returns governor predicted frequency as current frequency
> via sysfs interface. But device may not support all frequencies
> that governor predicts. So add a callback in device profile to get
> current freq from driver. Also add a new sysfs node to expose
> governor predicted next target frequency.
>
> Signed-off-by: Rajagopal Venkat
Signed-off-by: MyungJoo Ham
> ---
> Documentation/ABI/testing/sysfs-class-devfreq | 11 ++-
> drivers/devfreq/devfreq.c | 14 ++
> include/linux/devfreq.h | 3 +++
> 3 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-devfreq
> b/Documentation/ABI/testing/sysfs-class-devfreq
> index 89283b1..e6cf08e 100644
> --- a/Documentation/ABI/testing/sysfs-class-devfreq
> +++ b/Documentation/ABI/testing/sysfs-class-devfreq
> @@ -19,7 +19,16 @@ Date: September 2011
> Contact: MyungJoo Ham
> Description:
> The /sys/class/devfreq/.../cur_freq shows the current
> - frequency of the corresponding devfreq object.
> + frequency of the corresponding devfreq object. Same as
> + target_freq when get_cur_freq() is not implemented by
> + devfreq driver.
> +
> +What:/sys/class/devfreq/.../target_freq
> +Date:September 2012
> +Contact: Rajagopal Venkat
> +Description:
> + The /sys/class/devfreq/.../target_freq shows the next governor
> + predicted target frequency of the corresponding devfreq object.
>
> What:/sys/class/devfreq/.../polling_interval
> Date:September 2011
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 309c46e..049e273 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -401,6 +401,19 @@ static ssize_t show_governor(struct device *dev,
> static ssize_t show_freq(struct device *dev,
>struct device_attribute *attr, char *buf)
> {
> + unsigned long freq;
> + struct devfreq *devfreq = to_devfreq(dev);
> +
> + if (devfreq->profile->get_cur_freq &&
> + !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
> + return sprintf(buf, "%lu\n", freq);
> +
> + return sprintf(buf, "%lu\n", devfreq->previous_freq);
> +}
> +
> +static ssize_t show_target_freq(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> return sprintf(buf, "%lu\n", to_devfreq(dev)->previous_freq);
> }
>
> @@ -504,6 +517,7 @@ static ssize_t show_max_freq(struct device *dev, struct
> device_attribute *attr,
> static struct device_attribute devfreq_attrs[] = {
> __ATTR(governor, S_IRUGO, show_governor, NULL),
> __ATTR(cur_freq, S_IRUGO, show_freq, NULL),
> + __ATTR(target_freq, S_IRUGO, show_target_freq, NULL),
> __ATTR(polling_interval, S_IRUGO | S_IWUSR, show_polling_interval,
> store_polling_interval),
> __ATTR(min_freq, S_IRUGO | S_IWUSR, show_min_freq, store_min_freq),
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 7c7e179..d12ed41 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -66,6 +66,8 @@ struct devfreq_dev_status {
> * explained above with "DEVFREQ_FLAG_*" macros.
> * @get_dev_status The device should provide the current performance
> * status to devfreq, which is used by governors.
> + * @get_cur_freq The device should provide the current frequency
> + * at which it is operating.
> * @exit An optional callback that is called when devfreq
> * is removing the devfreq object due to error or
> * from devfreq_remove_device() call. If the user
> @@ -79,6 +81,7 @@ struct devfreq_dev_profile {
> int (*target)(struct device *dev, unsigned long *freq, u32 flags);
> int (*get_dev_status)(struct device *dev,
> struct devfreq_dev_status *stat);
> + int (*get_cur_freq)(struct device *dev, unsigned long *freq);
> void (*exit)(struct device *dev);
> };
>
> --
> 1.7.11.3
>
>
>
>
>
>
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM
On Fri, 14 Sep 2012, Sergei Shtylyov wrote: > Hello. > > On 09/14/2012 03:13 PM, Stefano Stabellini wrote: > > > Changes in v2: > > > - mark Xen guest support on ARM as EXPERIMENTAL. > > > Signed-off-by: Stefano Stabellini > > Acked-by: Konrad Rzeszutek Wilk > > --- > > arch/arm/Kconfig | 10 ++ > > 1 files changed, 10 insertions(+), 0 deletions(-) > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 2f88d8d..e92518d 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT > > This was deprecated in 2001 and announced to live on for 5 years. > > Some old boot loaders still use this way. > > > > +config XEN_DOM0 > > + def_bool y > > + > > +config XEN > > + bool "Xen guest support on ARM (EXPERIMENTAL)" > > + depends on EXPERIMENTAL && ARM && OF > > + select XEN_DOM0 > >What's the point of selecting it if it's always "y"? That's because on X86 is not always "y": there are things under drivers/xen that compile on both platforms and depend on XEN_DOM0. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 10/24] xen/arm: compile and run xenbus
On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote: > On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote: > > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not > > an error. > > > > If Linux is running as an HVM domain and is running as Dom0, use > > xenstored_local_init to initialize the xenstore page and event channel. > > Let me stick it in my tree and see how it works overnight with HVM and PV > guests. Did it work? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Re: [PATCH 1/3] devfreq: core updates to support devices which can idle
> On 10 September 2012 14:43, 함명주 wrote: > >> Prepare devfreq core framework to support devices which > >> can idle. When device idleness is detected perhaps through > >> runtime-pm, need some mechanism to suspend devfreq load > >> monitoring and resume back when device is online. Present > >> code continues monitoring unless device is removed from > >> devfreq core. > >> > >> This patch introduces following design changes, > >> > >> - use per device work instead of global work to monitor device > >> load. This enables suspend/resume of device devfreq and > >> reduces monitoring code complexity. > >> - decouple delayed work based load monitoring logic from core > >> by introducing helpers functions to be used by governors. This > >> provides flexibility for governors either to use delayed work > >> based monitoring functions or to implement their own mechanism. > >> - devfreq core interacts with governors via events to perform > >> specific actions. These events include start/stop devfreq. > >> This sets ground for adding suspend/resume events. > >> > >> The devfreq apis are not modified and are kept intact. > > > > Hello, > > > > Please revise locking mechanism along with event handler. > > > > It appears that we need to do mutex_lock(&devfreq->lock) before calling > > devfreq->governor->event_handler(); > > I don't think is the case. The governor can make use of devfreq->lock if > needed. > Anyways, I have revised locking mechanism in v2 set. > > > Or at least, userspace_init and userspace_exit functions require mutex_lock. > > The userspace_init function is executed only when device is added to devfreq > framework. This function itself is creating sysfs attributes. So this should > not > be a concern for us. > > The userspace_exit is executed when device is removed from devfreq > framework. sysfs_remove_group() should take care of serving any pending > reference to sysfs attributes before removing them. No concern here as well. > Am I missing something which demand locking for these functions? > > > Event_handler callback won't want the properties in devfreq to be changed > > externally during its execution. > > Agree. If so, the GOV_INTERVAL handler of ondemand requires mutex_lock. (and probably, nested mutex lock for monitor_resume) It determins next action based on the value protected by the devfreq lock. It won't crash the kernel and it won't happen often. However, it may behave incorrectly. Why don't we simply let the all the struct devfreq protected when the external code (governors) is probably reading/writing the protected values? This also guarantees that the event handler gets the exact status modified by the event caller. Otherwise, the event handler may get status different from the event caller's intention. Cheers! MyungJoo > > > > > Plus, please edit Documentation/ABI entry (central_polling is being removed) > Done. > > > > Other than that, it looks fine. > > > > Cheers! > > MyungJoo > > > >> > >> Signed-off-by: Rajagopal Venkat > >> --- > >> drivers/devfreq/devfreq.c | 376 > >> ++ > >> drivers/devfreq/governor.h| 9 + > >> drivers/devfreq/governor_performance.c| 16 +- > >> drivers/devfreq/governor_powersave.c | 16 +- > >> drivers/devfreq/governor_simpleondemand.c | 33 +++ > >> drivers/devfreq/governor_userspace.c | 23 +- > >> include/linux/devfreq.h | 31 +-- > >> 7 files changed, 220 insertions(+), 284 deletions(-) > >> > >> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c > >> index b146d76..be524c7 100644 > >> --- a/drivers/devfreq/devfreq.c > >> +++ b/drivers/devfreq/devfreq.c > >> @@ -30,17 +30,11 @@ > >> struct class *devfreq_class; > >> > >> /* > >> - * devfreq_work periodically monitors every registered device. > >> - * The minimum polling interval is one jiffy. The polling interval is > >> - * determined by the minimum polling period among all polling devfreq > >> - * devices. The resolution of polling interval is one jiffy. > >> + * devfreq core provides delayed work based load monitoring helper > >> + * functions. Governors can use these or can implement their own > >> + * monitoring mechanism. > >> */ > >> -static bool polling; > >> static struct workqueue_struct *devfreq_wq; > >> -static struct delayed_work devfreq_work; > >> - > >> -/* wait removing if this is to be removed */ > >> -static struct devfreq *wait_remove_device; > >> > >> /* The list of all device-devfreq */ > >> static LIST_HEAD(devfreq_list); > >> @@ -72,6 +66,8 @@ static struct devfreq *find_device_devfreq(struct device > >> *dev) > >> return ERR_PTR(-ENODEV); > >> } > >> > >> +/* Load monitoring helper functions for governors use */ > >> + > >> /** > >> * update_devfreq() - Reevaluate the device and configure frequency. > >> * @devfreq: the devfreq instance. > >> @@ -121,6 +117,90 @@ int update_devfreq(struct devfreq *devfreq) > >> } > >>
Re: [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM
Hello. On 17-09-2012 14:57, Stefano Stabellini wrote: Changes in v2: - mark Xen guest support on ARM as EXPERIMENTAL. Signed-off-by: Stefano Stabellini Acked-by: Konrad Rzeszutek Wilk --- arch/arm/Kconfig | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 2f88d8d..e92518d 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT This was deprecated in 2001 and announced to live on for 5 years. Some old boot loaders still use this way. +config XEN_DOM0 + def_bool y + +config XEN + bool "Xen guest support on ARM (EXPERIMENTAL)" + depends on EXPERIMENTAL && ARM && OF + select XEN_DOM0 What's the point of selecting it if it's always "y"? That's because on X86 is not always "y": there are things under drivers/xen that compile on both platforms and depend on XEN_DOM0. But we're not on x86. On ARM this select is pointless. WBR, Sergei ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 06/24] docs: Xen ARM DT bindings
On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
>> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
>>> Add a doc to describe the Xen ARM device tree bindings
>>>
>>>
>>> Changes in v4:
>>>
>>> - "xen,xen" should be last as it is less specific;
>>> - update reg property using 2 address-cells and 2 size-cells.
>>>
>>>
>>> Signed-off-by: Stefano Stabellini
>>> CC: devicetree-disc...@lists.ozlabs.org
>>> CC: David Vrabel
>>> CC: Rob Herring
>>> CC: Dave Martin
>>> ---
>>> Documentation/devicetree/bindings/arm/xen.txt | 22 ++
>>> 1 files changed, 22 insertions(+), 0 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt
>>> b/Documentation/devicetree/bindings/arm/xen.txt
>>> new file mode 100644
>>> index 000..1f8f7d4
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
>>> @@ -0,0 +1,22 @@
>>> +* Xen hypervisor device tree bindings
>>> +
>>> +Xen ARM virtual platforms shall have the following properties:
>>> +
State that they are part of top-level "hypervisor" node.
>>> +- compatible:
>>> + compatible = "xen,xen-", "xen,xen";
>>> + where is the version of the Xen ABI of the platform.
>>> +
>>> +- reg: specifies the base physical address and size of a region in
>>> + memory where the grant table should be mapped to, using an
>>> + HYPERVISOR_memory_op hypercall.
>>> +
>>> +- interrupts: the interrupt used by Xen to inject event notifications.
>>
>> Its singular here.. but in the example its plurar. What if you use
>> multiple of the same number ("16 0xf")?
>
> The "interrupts" property in the example below is a standard property to
> describe interrupts. We just happen to declare only one interrupt.
>
> From the device tree point of view it would be possible to declare more
> than one interrupt here, but Xen only supports one really.
>
> Regarding the three cells used in the example (<1 15 0xf08>), they have
> a specific meaning in the GIC context:
>
> """
> The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> interrupts.
>
> The 2nd cell contains the interrupt number for the interrupt type.
> SPI interrupts are in the range [0-987]. PPI interrupts are in the
> range [0-15].
>
> The 3rd cell is the flags, encoded as follows:
> bits[3:0] trigger type and level flags.
> 1 = low-to-high edge triggered
> 2 = high-to-low edge triggered
> 4 = active high level-sensitive
> 8 = active low level-sensitive
> bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
> the 8 possible cpus attached to the GIC. A bit set to '1' indicated
> the interrupt is wired to that CPU. Only valid for PPI interrupts.
> """
>
> So <1 15 0xf08> means the last PPI.
Since it is a PPI, it is handled differently than a normal interrupt.
That is fine, but you should somehow state that a GIC node is also required.
>
>>> +
>>> +
>>> +Example:
>>> +
>>> +hypervisor {
>>> + compatible = "xen,xen-4.3", "xen,xen";
>>> + reg = <0 0xb000 0 0x2>;
>>
>> So two grant tables?
>>
>> Hm, physical address is zero, and the size is 0xbignumber?
>> Or is the '0' denotating a seperator of arguments, so it is
>> 0xb000.. for physical address and 0x2 for size?
>
> from http://devicetree.org/Device_Tree_Usage:
>
> "Each addressable device gets a reg which is a list of tuples in the
> form reg = Each tuple represents an address range used by the device. Each address
> value is a list of one or more 32 bit integers called cells. Similarly,
> the length value can either be a list of cells, or empty."
>
> In this case the address is: [0 0xb000], that means
> 0xb000, and the length is [0 0x2], that means
> 0x0002.
But the size depends on #size-cells and #address-cells. I would expect
those to be 1 for a 32-bit guest.
Rob
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 10/24] xen/arm: compile and run xenbus
On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> an error.
>
> If Linux is running as an HVM domain and is running as Dom0, use
> xenstored_local_init to initialize the xenstore page and event channel.
>
>
> Changes in v4:
>
> - do not xs_reset_watches on dom0.
>
>
> Changes in v2:
>
> - refactor xenbus_init.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Konrad Rzeszutek Wilk
If you would like I can also carry this in my tree.
> ---
> drivers/xen/xenbus/xenbus_comms.c |2 +-
> drivers/xen/xenbus/xenbus_probe.c | 62 +---
> drivers/xen/xenbus/xenbus_xs.c|3 +-
> 3 files changed, 46 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/xen/xenbus/xenbus_comms.c
> b/drivers/xen/xenbus/xenbus_comms.c
> index 52fe7ad..c5aa55c 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -224,7 +224,7 @@ int xb_init_comms(void)
> int err;
> err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
> 0, "xenbus", &xb_waitq);
> - if (err <= 0) {
> + if (err < 0) {
> printk(KERN_ERR "XENBUS request irq failed %i\n", err);
> return err;
> }
> diff --git a/drivers/xen/xenbus/xenbus_probe.c
> b/drivers/xen/xenbus/xenbus_probe.c
> index b793723..a67ccc0 100644
> --- a/drivers/xen/xenbus/xenbus_probe.c
> +++ b/drivers/xen/xenbus/xenbus_probe.c
> @@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
> return err;
> }
>
> +enum xenstore_init {
> + UNKNOWN,
> + PV,
> + HVM,
> + LOCAL,
> +};
> static int __init xenbus_init(void)
> {
> int err = 0;
> + enum xenstore_init usage = UNKNOWN;
> + uint64_t v = 0;
>
> if (!xen_domain())
> return -ENODEV;
>
> xenbus_ring_ops_init();
>
> - if (xen_hvm_domain()) {
> - uint64_t v = 0;
> - err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> - if (err)
> - goto out_error;
> - xen_store_evtchn = (int)v;
> - err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> - if (err)
> - goto out_error;
> - xen_store_mfn = (unsigned long)v;
> - xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT,
> PAGE_SIZE);
> - } else {
> - xen_store_evtchn = xen_start_info->store_evtchn;
> - xen_store_mfn = xen_start_info->store_mfn;
> - if (xen_store_evtchn)
> - xenstored_ready = 1;
> - else {
> + if (xen_pv_domain())
> + usage = PV;
> + if (xen_hvm_domain())
> + usage = HVM;
> + if (xen_hvm_domain() && xen_initial_domain())
> + usage = LOCAL;
> + if (xen_pv_domain() && !xen_start_info->store_evtchn)
> + usage = LOCAL;
> + if (xen_pv_domain() && xen_start_info->store_evtchn)
> + xenstored_ready = 1;
> +
> + switch (usage) {
> + case LOCAL:
> err = xenstored_local_init();
> if (err)
> goto out_error;
> - }
> - xen_store_interface = mfn_to_virt(xen_store_mfn);
> + xen_store_interface = mfn_to_virt(xen_store_mfn);
> + break;
> + case PV:
> + xen_store_evtchn = xen_start_info->store_evtchn;
> + xen_store_mfn = xen_start_info->store_mfn;
> + xen_store_interface = mfn_to_virt(xen_store_mfn);
> + break;
> + case HVM:
> + err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> + if (err)
> + goto out_error;
> + xen_store_evtchn = (int)v;
> + err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> + if (err)
> + goto out_error;
> + xen_store_mfn = (unsigned long)v;
> + xen_store_interface =
> + ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> + break;
> + default:
> + pr_warn("Xenstore state unknown\n");
> + break;
> }
>
> /* Initialize the interface to xenstore. */
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index bce15cf..131dec0 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -44,6 +44,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include "xenbus_comms.h"
> @@ -622,7 +623,7 @@ static void xs_reset_watches(void)
> {
>
Re: [PATCH v4 10/24] xen/arm: compile and run xenbus
On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote:
> > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not
> > an error.
> >
> > If Linux is running as an HVM domain and is running as Dom0, use
> > xenstored_local_init to initialize the xenstore page and event channel.
> >
> >
> > Changes in v4:
> >
> > - do not xs_reset_watches on dom0.
> >
> >
> > Changes in v2:
> >
> > - refactor xenbus_init.
> >
> > Signed-off-by: Stefano Stabellini
>
> Acked-by: Konrad Rzeszutek Wilk
>
>
> If you would like I can also carry this in my tree.
OK, let's do that. I'll rebase again on your tree with this patch.
> > drivers/xen/xenbus/xenbus_comms.c |2 +-
> > drivers/xen/xenbus/xenbus_probe.c | 62
> > +---
> > drivers/xen/xenbus/xenbus_xs.c|3 +-
> > 3 files changed, 46 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/xen/xenbus/xenbus_comms.c
> > b/drivers/xen/xenbus/xenbus_comms.c
> > index 52fe7ad..c5aa55c 100644
> > --- a/drivers/xen/xenbus/xenbus_comms.c
> > +++ b/drivers/xen/xenbus/xenbus_comms.c
> > @@ -224,7 +224,7 @@ int xb_init_comms(void)
> > int err;
> > err = bind_evtchn_to_irqhandler(xen_store_evtchn, wake_waiting,
> > 0, "xenbus", &xb_waitq);
> > - if (err <= 0) {
> > + if (err < 0) {
> > printk(KERN_ERR "XENBUS request irq failed %i\n", err);
> > return err;
> > }
> > diff --git a/drivers/xen/xenbus/xenbus_probe.c
> > b/drivers/xen/xenbus/xenbus_probe.c
> > index b793723..a67ccc0 100644
> > --- a/drivers/xen/xenbus/xenbus_probe.c
> > +++ b/drivers/xen/xenbus/xenbus_probe.c
> > @@ -719,37 +719,61 @@ static int __init xenstored_local_init(void)
> > return err;
> > }
> >
> > +enum xenstore_init {
> > + UNKNOWN,
> > + PV,
> > + HVM,
> > + LOCAL,
> > +};
> > static int __init xenbus_init(void)
> > {
> > int err = 0;
> > + enum xenstore_init usage = UNKNOWN;
> > + uint64_t v = 0;
> >
> > if (!xen_domain())
> > return -ENODEV;
> >
> > xenbus_ring_ops_init();
> >
> > - if (xen_hvm_domain()) {
> > - uint64_t v = 0;
> > - err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> > - if (err)
> > - goto out_error;
> > - xen_store_evtchn = (int)v;
> > - err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> > - if (err)
> > - goto out_error;
> > - xen_store_mfn = (unsigned long)v;
> > - xen_store_interface = ioremap(xen_store_mfn << PAGE_SHIFT,
> > PAGE_SIZE);
> > - } else {
> > - xen_store_evtchn = xen_start_info->store_evtchn;
> > - xen_store_mfn = xen_start_info->store_mfn;
> > - if (xen_store_evtchn)
> > - xenstored_ready = 1;
> > - else {
> > + if (xen_pv_domain())
> > + usage = PV;
> > + if (xen_hvm_domain())
> > + usage = HVM;
> > + if (xen_hvm_domain() && xen_initial_domain())
> > + usage = LOCAL;
> > + if (xen_pv_domain() && !xen_start_info->store_evtchn)
> > + usage = LOCAL;
> > + if (xen_pv_domain() && xen_start_info->store_evtchn)
> > + xenstored_ready = 1;
> > +
> > + switch (usage) {
> > + case LOCAL:
> > err = xenstored_local_init();
> > if (err)
> > goto out_error;
> > - }
> > - xen_store_interface = mfn_to_virt(xen_store_mfn);
> > + xen_store_interface = mfn_to_virt(xen_store_mfn);
> > + break;
> > + case PV:
> > + xen_store_evtchn = xen_start_info->store_evtchn;
> > + xen_store_mfn = xen_start_info->store_mfn;
> > + xen_store_interface = mfn_to_virt(xen_store_mfn);
> > + break;
> > + case HVM:
> > + err = hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, &v);
> > + if (err)
> > + goto out_error;
> > + xen_store_evtchn = (int)v;
> > + err = hvm_get_parameter(HVM_PARAM_STORE_PFN, &v);
> > + if (err)
> > + goto out_error;
> > + xen_store_mfn = (unsigned long)v;
> > + xen_store_interface =
> > + ioremap(xen_store_mfn << PAGE_SHIFT, PAGE_SIZE);
> > + break;
> > + default:
> > + pr_warn("Xenstore state unknown\n");
> > + break;
> > }
> >
> > /* Initialize the interface to xenstore. */
> > diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> > index bce15cf..131dec0 100644
> > --- a/drivers/xen/xenbus/xenbus_xs.c
>
Re: [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM
On Mon, 17 Sep 2012, Sergei Shtylyov wrote: > Hello. > > On 17-09-2012 14:57, Stefano Stabellini wrote: > > >>> Changes in v2: > > >>> - mark Xen guest support on ARM as EXPERIMENTAL. > > >>> Signed-off-by: Stefano Stabellini > >>> Acked-by: Konrad Rzeszutek Wilk > >>> --- > >>> arch/arm/Kconfig | 10 ++ > >>> 1 files changed, 10 insertions(+), 0 deletions(-) > > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >>> index 2f88d8d..e92518d 100644 > >>> --- a/arch/arm/Kconfig > >>> +++ b/arch/arm/Kconfig > >>> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT > >>> This was deprecated in 2001 and announced to live on for 5 > >>> years. > >>> Some old boot loaders still use this way. > >>> > >>> +config XEN_DOM0 > >>> + def_bool y > >>> + > >>> +config XEN > >>> + bool "Xen guest support on ARM (EXPERIMENTAL)" > >>> + depends on EXPERIMENTAL && ARM && OF > >>> + select XEN_DOM0 > > >> What's the point of selecting it if it's always "y"? > > > That's because on X86 is not always "y": there are things under > > drivers/xen that compile on both platforms and depend on XEN_DOM0. > > But we're not on x86. On ARM this select is pointless. We need some common code (under drivers/xen) that compiles only if XEN_DOM0 is selected, so it is not pointless after all. XEN_DOM0 is not the only symbol that is conditionally compiled on one architectuire and always "y" on another... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 10/24] xen/arm: compile and run xenbus
On Mon, Sep 17, 2012 at 12:05:59PM +0100, Stefano Stabellini wrote: > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote: > > On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote: > > > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not > > > an error. > > > > > > If Linux is running as an HVM domain and is running as Dom0, use > > > xenstored_local_init to initialize the xenstore page and event channel. > > > > Let me stick it in my tree and see how it works overnight with HVM and PV > > guests. > > Did it work? Yes! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 06/24] docs: Xen ARM DT bindings
On Mon, 17 Sep 2012, Rob Herring wrote:
> On 09/14/2012 09:26 AM, Stefano Stabellini wrote:
> > On Fri, 14 Sep 2012, Konrad Rzeszutek Wilk wrote:
> >> On Fri, Sep 14, 2012 at 12:13:08PM +0100, Stefano Stabellini wrote:
> >>> Add a doc to describe the Xen ARM device tree bindings
> >>>
> >>>
> >>> Changes in v4:
> >>>
> >>> - "xen,xen" should be last as it is less specific;
> >>> - update reg property using 2 address-cells and 2 size-cells.
> >>>
> >>>
> >>> Signed-off-by: Stefano Stabellini
> >>> CC: devicetree-disc...@lists.ozlabs.org
> >>> CC: David Vrabel
> >>> CC: Rob Herring
> >>> CC: Dave Martin
> >>> ---
> >>> Documentation/devicetree/bindings/arm/xen.txt | 22
> >>> ++
> >>> 1 files changed, 22 insertions(+), 0 deletions(-)
> >>> create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt
> >>> b/Documentation/devicetree/bindings/arm/xen.txt
> >>> new file mode 100644
> >>> index 000..1f8f7d4
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> >>> @@ -0,0 +1,22 @@
> >>> +* Xen hypervisor device tree bindings
> >>> +
> >>> +Xen ARM virtual platforms shall have the following properties:
> >>> +
>
> State that they are part of top-level "hypervisor" node.
OK
> >>> +- compatible:
> >>> + compatible = "xen,xen-", "xen,xen";
> >>> + where is the version of the Xen ABI of the platform.
> >>> +
> >>> +- reg: specifies the base physical address and size of a region in
> >>> + memory where the grant table should be mapped to, using an
> >>> + HYPERVISOR_memory_op hypercall.
> >>> +
> >>> +- interrupts: the interrupt used by Xen to inject event notifications.
> >>
> >> Its singular here.. but in the example its plurar. What if you use
> >> multiple of the same number ("16 0xf")?
> >
> > The "interrupts" property in the example below is a standard property to
> > describe interrupts. We just happen to declare only one interrupt.
> >
> > From the device tree point of view it would be possible to declare more
> > than one interrupt here, but Xen only supports one really.
> >
> > Regarding the three cells used in the example (<1 15 0xf08>), they have
> > a specific meaning in the GIC context:
> >
> > """
> > The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> > interrupts.
> >
> > The 2nd cell contains the interrupt number for the interrupt type.
> > SPI interrupts are in the range [0-987]. PPI interrupts are in the
> > range [0-15].
> >
> > The 3rd cell is the flags, encoded as follows:
> > bits[3:0] trigger type and level flags.
> > 1 = low-to-high edge triggered
> > 2 = high-to-low edge triggered
> > 4 = active high level-sensitive
> > 8 = active low level-sensitive
> > bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of
> > the 8 possible cpus attached to the GIC. A bit set to '1' indicated
> > the interrupt is wired to that CPU. Only valid for PPI interrupts.
> > """
> >
> > So <1 15 0xf08> means the last PPI.
>
> Since it is a PPI, it is handled differently than a normal interrupt.
> That is fine, but you should somehow state that a GIC node is also required.
Yes, good idea
> >>> +
> >>> +
> >>> +Example:
> >>> +
> >>> +hypervisor {
> >>> + compatible = "xen,xen-4.3", "xen,xen";
> >>> + reg = <0 0xb000 0 0x2>;
> >>
> >> So two grant tables?
> >>
> >> Hm, physical address is zero, and the size is 0xbignumber?
> >> Or is the '0' denotating a seperator of arguments, so it is
> >> 0xb000.. for physical address and 0x2 for size?
> >
> > from http://devicetree.org/Device_Tree_Usage:
> >
> > "Each addressable device gets a reg which is a list of tuples in the
> > form reg = > Each tuple represents an address range used by the device. Each address
> > value is a list of one or more 32 bit integers called cells. Similarly,
> > the length value can either be a list of cells, or empty."
> >
> > In this case the address is: [0 0xb000], that means
> > 0xb000, and the length is [0 0x2], that means
> > 0x0002.
>
> But the size depends on #size-cells and #address-cells. I would expect
> those to be 1 for a 32-bit guest.
I was looking at the Versatile Express DTS (vexpress-v2p-ca15-tc1.dts)
that on Linux v3.6-rc5 has:
#address-cells = <2>;
#size-cells = <2>;
What should I use for the example in this doc?
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM
On Mon, Sep 17, 2012 at 04:07:37PM +0400, Sergei Shtylyov wrote: > Hello. > > On 17-09-2012 14:57, Stefano Stabellini wrote: > > >>>Changes in v2: > > >>>- mark Xen guest support on ARM as EXPERIMENTAL. > > >>>Signed-off-by: Stefano Stabellini > >>>Acked-by: Konrad Rzeszutek Wilk > >>>--- > >>> arch/arm/Kconfig | 10 ++ > >>> 1 files changed, 10 insertions(+), 0 deletions(-) > > >>>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >>>index 2f88d8d..e92518d 100644 > >>>--- a/arch/arm/Kconfig > >>>+++ b/arch/arm/Kconfig > >>>@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT > >>> This was deprecated in 2001 and announced to live on for 5 years. > >>> Some old boot loaders still use this way. > >>> > >>>+config XEN_DOM0 > >>>+ def_bool y > >>>+ > >>>+config XEN > >>>+ bool "Xen guest support on ARM (EXPERIMENTAL)" > >>>+ depends on EXPERIMENTAL && ARM && OF I think the CONFIG_EXPERIMENTAL is going away. Or it has already gone away? > >>>+ select XEN_DOM0 > > >>What's the point of selecting it if it's always "y"? > > >That's because on X86 is not always "y": there are things under > >drivers/xen that compile on both platforms and depend on XEN_DOM0. > >But we're not on x86. On ARM this select is pointless. Sure, but parts of the generic Xen (drivers/xen) code functionality has checks for that (CONFIG_DOM0) to use some functionality that is not neccessarily considered "dom0" specific for ARM. The right way is to seperate those to be more of a 'backend' config and 'frontend' config. But those CONFIG options are a maze and I figured I will fix this Gordon knot once this is all accepted/compiled/works, and then slowly untangle the CONFIG-mess. > > WBR, Sergei ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM
On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote: > On Mon, Sep 17, 2012 at 04:07:37PM +0400, Sergei Shtylyov wrote: > > Hello. > > > > On 17-09-2012 14:57, Stefano Stabellini wrote: > > > > >>>Changes in v2: > > > > >>>- mark Xen guest support on ARM as EXPERIMENTAL. > > > > >>>Signed-off-by: Stefano Stabellini > > >>>Acked-by: Konrad Rzeszutek Wilk > > >>>--- > > >>> arch/arm/Kconfig | 10 ++ > > >>> 1 files changed, 10 insertions(+), 0 deletions(-) > > > > >>>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > >>>index 2f88d8d..e92518d 100644 > > >>>--- a/arch/arm/Kconfig > > >>>+++ b/arch/arm/Kconfig > > >>>@@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT > > >>> This was deprecated in 2001 and announced to live on for 5 > > >>> years. > > >>> Some old boot loaders still use this way. > > >>> > > >>>+config XEN_DOM0 > > >>>+def_bool y > > >>>+ > > >>>+config XEN > > >>>+bool "Xen guest support on ARM (EXPERIMENTAL)" > > >>>+depends on EXPERIMENTAL && ARM && OF > > I think the CONFIG_EXPERIMENTAL is going away. Or it has already > gone away? I would like to keep it for Linux v3.6, because the Xen ABI offered by Xen 4.2 hasn't been declared stable yet. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 10/24] xen/arm: compile and run xenbus
On Mon, Sep 17, 2012 at 02:45:00PM +0100, Stefano Stabellini wrote: > On Mon, 17 Sep 2012, Konrad Rzeszutek Wilk wrote: > > On Fri, Sep 14, 2012 at 12:13:12PM +0100, Stefano Stabellini wrote: > > > bind_evtchn_to_irqhandler can legitimately return 0 (irq 0): it is not > > > an error. > > > > > > If Linux is running as an HVM domain and is running as Dom0, use > > > xenstored_local_init to initialize the xenstore page and event channel. > > > > > > > > > Changes in v4: > > > > > > - do not xs_reset_watches on dom0. > > > > > > > > > Changes in v2: > > > > > > - refactor xenbus_init. > > > > > > Signed-off-by: Stefano Stabellini > > > > Acked-by: Konrad Rzeszutek Wilk > > > > > > If you would like I can also carry this in my tree. > > OK, let's do that. I'll rebase again on your tree with this patch. Done. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 12/24] xen/arm: introduce CONFIG_XEN on ARM
On Mon, 17 Sep 2012, Stefano Stabellini wrote: > On Mon, 17 Sep 2012, Sergei Shtylyov wrote: > > Hello. > > > > On 17-09-2012 14:57, Stefano Stabellini wrote: > > > > >>> Changes in v2: > > > > >>> - mark Xen guest support on ARM as EXPERIMENTAL. > > > > >>> Signed-off-by: Stefano Stabellini > > >>> Acked-by: Konrad Rzeszutek Wilk > > >>> --- > > >>> arch/arm/Kconfig | 10 ++ > > >>> 1 files changed, 10 insertions(+), 0 deletions(-) > > > > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > >>> index 2f88d8d..e92518d 100644 > > >>> --- a/arch/arm/Kconfig > > >>> +++ b/arch/arm/Kconfig > > >>> @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT > > >>> This was deprecated in 2001 and announced to live on for 5 > > >>> years. > > >>> Some old boot loaders still use this way. > > >>> > > >>> +config XEN_DOM0 > > >>> + def_bool y > > >>> + > > >>> +config XEN > > >>> + bool "Xen guest support on ARM (EXPERIMENTAL)" > > >>> + depends on EXPERIMENTAL && ARM && OF > > >>> + select XEN_DOM0 > > > > >> What's the point of selecting it if it's always "y"? > > > > > That's because on X86 is not always "y": there are things under > > > drivers/xen that compile on both platforms and depend on XEN_DOM0. > > > > But we're not on x86. On ARM this select is pointless. > > We need some common code (under drivers/xen) that compiles only if > XEN_DOM0 is selected, so it is not pointless after all. > > XEN_DOM0 is not the only symbol that is conditionally compiled on one > architectuire and always "y" on another... > Wait a sec, I have just realized that written this way XEN_DOM0 is always "y", even if XEN is not! The right way of doing this is: config XEN_DOM0 def_bool y depends on XEN config XEN bool "Xen guest support on ARM (EXPERIMENTAL)" depends on EXPERIMENTAL && ARM && OF help Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. I am not sure if this is what you meant, but thanks for making me realize this mistake anyway! :) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[Powertop][PATCH 2/2] Add stubs to support Android platform
This patch adds stubs for features that are not supported
by Andriod. An header file which defines all stubs is
included only for Android builds.
Signed-off-by: Rajagopal Venkat
---
Android.mk | 33 +++--
src/android_stubs.h | 47 +++
src/lib.h |4
3 files changed, 78 insertions(+), 6 deletions(-)
create mode 100644 src/android_stubs.h
diff --git a/Android.mk b/Android.mk
index a52ecfd..081f470 100644
--- a/Android.mk
+++ b/Android.mk
@@ -1,17 +1,36 @@
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
+LOCAL_MODULE := powertop
+
LOCAL_MODULE_TAGS := debug
LOCAL_SHARED_LIBRARIES := libstlport \
libnl \
libpci \
- libtraceevnet \
-LOCAL_MODULE := powertop
+
+LOCAL_STATIC_LIBRARIES := libncurses
+
+CSSTOH_SOURCE := $(LOCAL_PATH)/src/csstoh.c
+POWERTOP_CSS_SOURCE := $(LOCAL_PATH)/src/powertop.css
+GEN_CSSTOH := $(LOCAL_PATH)/src/csstoh
+GEN_CSS_H := $(LOCAL_PATH)/src/css.h
+$(GEN_CSS_H):
+ $(CC) -o $(GEN_CSSTOH) $(CSSTOH_SOURCE)
+ ./$(GEN_CSSTOH) $(POWERTOP_CSS_SOURCE) $@
+
+LOCAL_GENERATED_SOURCES += $(GEN_CSS_H)
#LOCAL_CFLAGS += -Wall -O2 -g -fno-omit-frame-pointer -fstack-protector
-Wshadow -Wformat -D_FORTIFY_SOURCE=2
#LOCAL_CPPFLAGS += -Wall -O2 -g -fno-omit-frame-pointer
-LOCAL_C_INCLUDES += external/stlport/stlport/ external/stlport/stlport/stl
external/stlport/stlport/using/h/ bionic external/libnl/include/
+LOCAL_C_INCLUDES += external/stlport/stlport/ \
+ external/stlport/stlport/stl \
+ external/stlport/stlport/using/h/ \
+ bionic \
+ external/libnl/include/ \
+ external/ncurses/include \
+ external/elfutils/bionic-fixup \
+ $(LOCAL_PATH)/src
LOCAL_SRC_FILES += \
src/parameters/parameters.cpp \
@@ -21,10 +40,11 @@ LOCAL_SRC_FILES += \
src/process/work.cpp \
src/process/process.cpp \
src/process/timer.cpp \
- src/process/device.cpp \
+ src/process/processdevice.cpp \
src/process/interrupt.cpp \
src/process/do_process.cpp \
src/cpu/intel_cpus.cpp \
+ src/cpu/intel_gpu.cpp \
src/cpu/cpu.cpp \
src/cpu/cpu_linux.cpp \
src/cpu/cpudevice.cpp \
@@ -33,20 +53,21 @@ LOCAL_SRC_FILES += \
src/cpu/abstract_cpu.cpp \
src/measurement/measurement.cpp \
src/measurement/acpi.cpp \
+ src/measurement/sysfs.cpp \
src/measurement/extech.cpp \
src/measurement/power_supply.cpp \
src/display.cpp \
src/report.cpp \
src/main.cpp \
src/tuning/tuning.cpp \
- src/tuning/usb.cpp \
+ src/tuning/tuningusb.cpp \
src/tuning/bluetooth.cpp \
src/tuning/ethernet.cpp \
src/tuning/runtime.cpp \
src/tuning/iw.c \
src/tuning/iw.h \
src/tuning/tunable.cpp \
- src/tuning/sysfs.cpp \
+ src/tuning/tuningsysfs.cpp \
src/tuning/cpufreq.cpp \
src/tuning/wifi.cpp \
src/perf/perf_bundle.cpp \
diff --git a/src/android_stubs.h b/src/android_stubs.h
new file mode 100644
index 000..60b1e29
--- /dev/null
+++ b/src/android_stubs.h
@@ -0,0 +1,47 @@
+#include
+#include
+
+/* Android doesn't provide locale support int its C and C++
+ * runtime. Handled at higher level in application stack.
+ * So define stubs for gettext funtions used.
+ */
+#define PACKAGE0
+#define LOCALEDIR 0
+#define bindtextdomain(x, y)
+#define textdomain(x)
+#define gettext(x) (x)
+
+/* Android C++ new operator does not throw exception on failure */
+#define set_new_handler(x)
+
+/* define stubs for C++ exception handling */
+#define tryif (true)
+#define catch(x) if (false)
+
+/* Define __NR_perf_event_open if not already defined */
+#if __arm__
+#ifndef __NR_perf_event_open
+#define __NR_perf_event_open364
+#endif
+#endif
+
+/* Implement missing functions */
+static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
+ __u32 speed)
+{
+
+ ep->speed = (__u16)speed;
+ ep->speed_hi = (__u16)(speed >> 16);
+}
+
+static inline __u32 ethtool_cmd_speed(struct ethtool_cmd *ep)
+{
+ return (ep->speed_hi << 16) | ep->speed;
+}
+
+static inline char *strchrnul(const char *s, int c)
+{
+ while (*s && (*s != c))
+ s++;
+ return (char *)s;
+}
diff --git a/src/lib.h b/src/lib.h
index 8cf4632..6772904 100644
--- a/src/lib.h
+++ b/src/lib.h
@@ -33,6 +33,10 @@
#include "config.h"
#endif
+#ifdef __ANDROID__
+#include "android_stubs.h"
+#endif
+
#define _(STRING)gettext(STRING)
#define POWERTOP_VERSION "v2.1"
--
1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[Powertop][PATCH 1/2] Updates to support Android platform
This patch adds following minor changes to prepare powertop
to support Android platform.
- add missing HAVE_CONFIG_H conditional check.
- remove un-used ethtool_cmd_speed_set and ethtool_cmd_speed
functions.
- minimize dependency on exception handling in catch blocks.
These changes will not affect powertop functionality.
Signed-off-by: Rajagopal Venkat
---
src/devices/ahci.cpp |4 ++--
src/devices/alsa.cpp |4 ++--
src/devices/network.cpp| 16
src/lib.cpp|2 +-
src/main.cpp |2 ++
src/process/do_process.cpp |4 ++--
6 files changed, 9 insertions(+), 23 deletions(-)
diff --git a/src/devices/ahci.cpp b/src/devices/ahci.cpp
index 1fe39c7..67ce06e 100644
--- a/src/devices/ahci.cpp
+++ b/src/devices/ahci.cpp
@@ -170,7 +170,7 @@ void ahci::start_measurement(void)
file.close();
}
catch (std::ios_base::failure &c) {
- fprintf(stderr, "%s\n", c.what());
+ fprintf(stderr, "Failed to start measurement for ahci
device\n");
}
}
@@ -203,7 +203,7 @@ void ahci::end_measurement(void)
file.close();
}
catch (std::ios_base::failure &c) {
- fprintf(stderr, "%s\n", c.what());
+ fprintf(stderr, "Failed to end measurement for ahci device\n");
}
if (end_active < start_active)
end_active = start_active;
diff --git a/src/devices/alsa.cpp b/src/devices/alsa.cpp
index 4f5d3f9..a67780c 100644
--- a/src/devices/alsa.cpp
+++ b/src/devices/alsa.cpp
@@ -104,7 +104,7 @@ void alsa::start_measurement(void)
file.close();
}
catch (std::ios_base::failure &c) {
- fprintf(stderr, "%s\n", c.what());
+ fprintf(stderr, "Failed to start measurement for alsa
device\n");
}
}
@@ -130,7 +130,7 @@ void alsa::end_measurement(void)
file.close();
}
catch (std::ios_base::failure &c) {
- fprintf(stderr, "%s\n", c.what());
+ fprintf(stderr, "Failed to end measurement for alsa device\n");
}
p = (end_active - start_active) / (0.001 + end_active + end_inactive -
start_active - start_inactive) * 100.0;
diff --git a/src/devices/network.cpp b/src/devices/network.cpp
index b8a5c9c..ed9d7aa 100644
--- a/src/devices/network.cpp
+++ b/src/devices/network.cpp
@@ -55,22 +55,6 @@ extern "C" {
static map nics;
-#ifdef DISABLE_TRYCATCH
-
-static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
- __u32 speed)
-{
-
- ep->speed = (__u16)speed;
- ep->speed_hi = (__u16)(speed >> 16);
-}
-
-static inline __u32 ethtool_cmd_speed(struct ethtool_cmd *ep)
-{
- return (ep->speed_hi << 16) | ep->speed;
-}
-
-#endif
static void do_proc_net_dev(void)
{
diff --git a/src/lib.cpp b/src/lib.cpp
index 9838c0b..776a67b 100644
--- a/src/lib.cpp
+++ b/src/lib.cpp
@@ -259,7 +259,7 @@ void format_watts(double W, char *buffer, unsigned int len)
if (W < 0.0001)
sprintf(buffer, _("0 mW"));
- while (mbstowcs(NULL,buffer,0) < len)
+ while (mbstowcs(NULL,buffer,len) < len)
strcat(buffer, " ");
}
diff --git a/src/main.cpp b/src/main.cpp
index 1815075..dc49dba 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -42,7 +42,9 @@
#include "perf/perf.h"
#include "perf/perf_bundle.h"
#include "lib.h"
+#ifdef HAVE_CONFIG_H
#include "../config.h"
+#endif
#include "devices/device.h"
diff --git a/src/process/do_process.cpp b/src/process/do_process.cpp
index eaef7f1..c9d6b0b 100644
--- a/src/process/do_process.cpp
+++ b/src/process/do_process.cpp
@@ -869,7 +869,7 @@ void process_update_display(void)
if (!show_power)
strcpy(power, " ");
sprintf(name, "%s", all_power[i]->type());
- while (mbstowcs(NULL,name,0) < 14) strcat(name, " ");
+ while (mbstowcs(NULL,name,20) < 14) strcat(name, " ");
if (all_power[i]->events() == 0 && all_power[i]->usage() == 0
&& all_power[i]->Witts() == 0)
@@ -882,7 +882,7 @@ void process_update_display(void)
else
sprintf(usage, "%5i%s",
(int)all_power[i]->usage(), all_power[i]->usage_units());
}
- while (mbstowcs(NULL,usage,0) < 14) strcat(usage, " ");
+ while (mbstowcs(NULL,usage,20) < 14) strcat(usage, " ");
sprintf(events, "%5.1f", all_power[i]->events());
if (!all_power[i]->show_events())
events[0] = 0;
--
1.7.9.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL]: big LITTLE MP v8
On Mon, 2012-09-17 at 15:19 +0530, Viresh Kumar wrote: > Hi Andrey, > > This is PULL request for big LITTLE MP v8 branch: > Major updates are: > - Based on v3.6-rc5 > - new branch from Paulm: rcu-hotplug-v1, vincent: > scheduler-misc-v1 and sudeepk arm-multi_pmu_v1 > - new version of patches from Morten: task-placement-v2 > - config fragment updated for fast & slow cpu > > Compile tested only. I've done a quick test of this v8 branch and Android builds and boots on TC2 (and A9). When using Streamline to view the CPU usage running 0xbench's 3D benchmarks, things looked a bit different from before (surfaceflinger occasionally running on a little core) but I couldn't see anything which was obviously wrong. As a sanity check I used some printfs to verify that the HMP migration code was being executed and that the big and little cores were correctly identified. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
General Invite Letter for Connect
Hey everyone, I'm sending out general invites based on this for anyone who's looking for something to use or modify: Howdy y’all! This is Zach on the Linaro Android team with an invitation to our upcoming Linaro Connect event. Tired of carrying changes around on your internal trees? Looking to get some possibly disruptive changes changes into the Linux kernel, GCC or another upstream? Just want to chat and plan for the future of ARM open-source with developers who are passionate about the SoCs that run Android and other Linux based distributions? If you answered yes to any of these questions please join us for Linaro Connect in Copenhagen Oct 29th to Nov 2nd at the Bella Center. Feel free to email me at zach.pfef...@linaro.org or G+ me for more information or to participate. Connect: http://connect.linaro.org/events/event/lce12-copenhagen/ Register at: http://connect.linaro.org/register-connect/ Be great to see you there! -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 00/17] Introduce Xen support on ARM (based on 3.6-rc5)
Hi all, this patch series implements Xen support for ARMv7 with virtualization extensions. It allows a Linux guest to boot as dom0 and as domU on Xen on ARM. PV console, disk and network frontends and backends are all working correctly. It has been tested on a Versatile Express Cortex A15 emulator, using the latest Xen ARM developement branch (git://xenbits.xen.org/people/ianc/xen-unstable.git arm-for-4.3) plus the "ARM hypercall ABI: 64 bit ready" patch series (http://marc.info/?l=xen-devel&m=134426267205408), and a simple ad-hoc tool to build guest domains (marc.info/?l=xen-devel&m=134089788016546). The patch marked with [HACK] has been dropped from this series, however you can find it here: http://marc.info/?l=linux-kernel&m=134513277823527&w=2. I am also attaching to this email the dts'es that I am currently using for dom0 and domU: vexpress-v2p-ca15-tc1.dts (that includes vexpress-v2m-rs1-rtsm.dtsi) is the dts used for dom0 and it is passed to Linux by Xen, while vexpress-virt.dts is the dts used for other domUs and it is appended in binary form to the guest kernel image. I am not sure where they are supposed to live yet, so I am just attaching them here so that people can actually try out this series if they want to. Comments are very welcome! The patch series has been rebased on Konrad's stable/for-linus-3.7 branch. Arnd, Russell, what do you think about this series? If you are OK with it, to whom should I submit it? Changes in v5: - rebase on Konrad's stable/for-linus-3.7; - add a comment about the size of the grant table memory region in the device tree documentation; - add a comment about the required presence of a GIC node in the device tree documentation; - specify that the described properties are part of a top-level "hypervisor" node in the device tree documentation; - specify #address-cells and #size-cells for the device tree example; - make XEN_DOM0 depend on XEN; - avoid "select XEN_DOM0" in XEN. Changes in v4: - rebase on 3.6-rc5; - devicetree: "xen,xen" should be last as it is less specific; - devicetree: use 2 address-cells and 2 size-cells in the reg property; - do not xs_reset_watches on dom0; - compile drivers/xen/pcpu.c only on x86; - use "+=" instead of ":=" for dom0- targets; - add a patch to update the MAINTAINERS file. Changes in v3: - move patches that have been picked up by Konrad at the end of the series; - improve comments; - add a doc to describe the Xen Device Tree format; - do not use xen_ulong_t for multicalls and apic_physbase; - add a patch at the end of the series to use the new __HVC macro; - add missing pvclock-abi.h include to ia64 header files; - do not use an anonymous union in struct xen_add_to_physmap. Changes in v2: - fix up many comments and commit messages; - remove the early_printk patches: rely on the emulated serial for now; - remove the xen_guest_init patch: without any PV early_printk, we don't need any early call to xen_guest_init, we can rely on core_initcall alone; - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if at the moment is unused; - use ldm instead of pop in the hypercall wrappers; - return -ENOSYS rather than -1 from the unimplemented grant_table functions; - remove the pvclock ifdef in the Xen headers; - remove include linux/types.h from xen/interface/xen.h; - replace pr_info with pr_debug in xen_guest_init; - add a new patch to introduce xen_ulong_t and use it top replace all the occurences of unsigned long in the public Xen interface; - explicitely size all the pointers to 64 bit on ARM, so that the hypercall ABI is "64 bit ready"; - clean up xenbus_init; - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI; - mark Xen guest support on ARM as EXPERIMENTAL; - introduce GRANT_TABLE_PHYSADDR; - remove unneeded initialization of boot_max_nr_grant_frames; - add a new patch to clear IRQ_NOAUTOEN and IRQ_NOREQUEST in events.c; - return -EINVAL from xen_remap_domain_mfn_range if auto_translated_physmap; - retain binary compatibility in xen_add_to_physmap: use a union to introduce foreign_domid. Shortlog and diffstat: Stefano Stabellini (17): arm: initial Xen support xen/arm: hypercalls xen/arm: page.h definitions xen/arm: sync_bitops xen/arm: empty implementation of grant_table arch specific functions docs: Xen ARM DT bindings xen/arm: Xen detection and shared_info page mapping xen/arm: Introduce xen_ulong_t for unsigned long xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM xen/arm: introduce CONFIG_XEN on ARM xen/arm: get privilege status xen/arm: initialize grant_table on ARM xen/arm: receive Xen events on ARM xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree xen/arm: compile blkfront and blkback xen/arm: compile netback MAINTAINERS: add myself as Xen ARM maintainer Documentation/devicetree/bindings/arm/xen.txt |
[PATCH v5 06/17] docs: Xen ARM DT bindings
Add a doc to describe the Xen ARM device tree bindings
Changes in v5:
- add a comment about the size of the grant table memory region;
- add a comment about the required presence of a GIC node;
- specify that the described properties are part of a top-level
"hypervisor" node;
- specify #address-cells and #size-cells for the example.
Changes in v4:
- "xen,xen" should be last as it is less specific;
- update reg property using 2 address-cells and 2 size-cells.
Signed-off-by: Stefano Stabellini
CC: devicetree-disc...@lists.ozlabs.org
CC: David Vrabel
CC: Rob Herring
CC: Dave Martin
---
Documentation/devicetree/bindings/arm/xen.txt | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
diff --git a/Documentation/devicetree/bindings/arm/xen.txt
b/Documentation/devicetree/bindings/arm/xen.txt
new file mode 100644
index 000..0f7b9c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.txt
@@ -0,0 +1,25 @@
+* Xen hypervisor device tree bindings
+
+Xen ARM virtual platforms shall have a top-level "hypervisor" node with
+the following properties:
+
+- compatible:
+ compatible = "xen,xen-", "xen,xen";
+ where is the version of the Xen ABI of the platform.
+
+- reg: specifies the base physical address and size of a region in
+ memory where the grant table should be mapped to, using an
+ HYPERVISOR_memory_op hypercall. The memory region is large enough to map
+ the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
+
+- interrupts: the interrupt used by Xen to inject event notifications.
+ A GIC node is also required.
+
+
+Example (assuming #address-cells = <2> and #size-cells = <2>):
+
+hypervisor {
+ compatible = "xen,xen-4.3", "xen,xen";
+ reg = <0 0xb000 0 0x2>;
+ interrupts = <1 15 0xf08>;
+};
--
1.7.2.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 05/17] xen/arm: empty implementation of grant_table arch specific functions
Changes in v2:
- return -ENOSYS rather than -1.
Signed-off-by: Stefano Stabellini
Acked-by: Konrad Rzeszutek Wilk
---
arch/arm/xen/Makefile |2 +-
arch/arm/xen/grant-table.c | 53
2 files changed, 54 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/xen/grant-table.c
diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile
index b9d6acc..4384103 100644
--- a/arch/arm/xen/Makefile
+++ b/arch/arm/xen/Makefile
@@ -1 +1 @@
-obj-y := enlighten.o hypercall.o
+obj-y := enlighten.o hypercall.o grant-table.o
diff --git a/arch/arm/xen/grant-table.c b/arch/arm/xen/grant-table.c
new file mode 100644
index 000..dbd1330
--- /dev/null
+++ b/arch/arm/xen/grant-table.c
@@ -0,0 +1,53 @@
+/**
+ * grant_table.c
+ * ARM specific part
+ *
+ * Granting foreign access to our memory reservation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (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.
+ */
+
+#include
+#include
+#include
+
+int arch_gnttab_map_shared(unsigned long *frames, unsigned long nr_gframes,
+ unsigned long max_nr_gframes,
+ void **__shared)
+{
+ return -ENOSYS;
+}
+
+void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
+{
+ return;
+}
+
+int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
+ unsigned long max_nr_gframes,
+ grant_status_t **__shared)
+{
+ return -ENOSYS;
+}
--
1.7.2.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 07/17] xen/arm: Xen detection and shared_info page mapping
Check for a node in the device tree compatible with "xen,xen", if it is
present set xen_domain_type to XEN_HVM_DOMAIN and continue
initialization.
Map the real shared info page using XENMEM_add_to_physmap with
XENMAPSPACE_shared_info.
Changes in v4:
- simpler parsing of Xen version in the compatible DT node.
Changes in v3:
- use the "xen,xen" notation rather than "arm,xen";
- add an additional check on the presence of the Xen version.
Changes in v2:
- replace pr_info with pr_debug.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/enlighten.c | 61 ++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c535540..6a0217d 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -5,6 +5,9 @@
#include
#include
#include
+#include
+#include
+#include
struct start_info _xen_start_info;
struct start_info *xen_start_info = &_xen_start_info;
@@ -33,3 +36,61 @@ int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
return -ENOSYS;
}
EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
+
+/*
+ * see Documentation/devicetree/bindings/arm/xen.txt for the
+ * documentation of the Xen Device Tree format.
+ */
+static int __init xen_guest_init(void)
+{
+ struct xen_add_to_physmap xatp;
+ static struct shared_info *shared_info_page = 0;
+ struct device_node *node;
+ int len;
+ const char *s = NULL;
+ const char *version = NULL;
+ const char *xen_prefix = "xen,xen-";
+
+ node = of_find_compatible_node(NULL, NULL, "xen,xen");
+ if (!node) {
+ pr_debug("No Xen support\n");
+ return 0;
+ }
+ s = of_get_property(node, "compatible", &len);
+ if (strlen(xen_prefix) + 3 < len &&
+ !strncmp(xen_prefix, s, strlen(xen_prefix)))
+ version = s + strlen(xen_prefix);
+ if (version == NULL) {
+ pr_debug("Xen version not found\n");
+ return 0;
+ }
+ xen_domain_type = XEN_HVM_DOMAIN;
+
+ if (!shared_info_page)
+ shared_info_page = (struct shared_info *)
+ get_zeroed_page(GFP_KERNEL);
+ if (!shared_info_page) {
+ pr_err("not enough memory\n");
+ return -ENOMEM;
+ }
+ xatp.domid = DOMID_SELF;
+ xatp.idx = 0;
+ xatp.space = XENMAPSPACE_shared_info;
+ xatp.gpfn = __pa(shared_info_page) >> PAGE_SHIFT;
+ if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, &xatp))
+ BUG();
+
+ HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+
+ /* xen_vcpu is a pointer to the vcpu_info struct in the shared_info
+* page, we use it in the event channel upcall and in some pvclock
+* related functions. We don't need the vcpu_info placement
+* optimizations because we don't use any pv_mmu or pv_irq op on
+* HVM.
+* The shared info contains exactly 1 CPU (the boot CPU). The guest
+* is required to use VCPUOP_register_vcpu_info to place vcpu info
+* for secondary CPUs as they are brought up. */
+ per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+ return 0;
+}
+core_initcall(xen_guest_init);
--
1.7.2.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 04/17] xen/arm: sync_bitops
sync_bitops functions are equivalent to the SMP implementation of the original functions, independently from CONFIG_SMP being defined. We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But under Xen you might be communicating with a completely external entity who might be on another CPU (e.g. two uniprocessor guests communicating via event channels and grant tables). So we need a variant of the bit ops which are SMP safe even on a UP kernel. Signed-off-by: Stefano Stabellini Acked-by: Konrad Rzeszutek Wilk --- arch/arm/include/asm/sync_bitops.h | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/asm/sync_bitops.h diff --git a/arch/arm/include/asm/sync_bitops.h b/arch/arm/include/asm/sync_bitops.h new file mode 100644 index 000..63479ee --- /dev/null +++ b/arch/arm/include/asm/sync_bitops.h @@ -0,0 +1,27 @@ +#ifndef __ASM_SYNC_BITOPS_H__ +#define __ASM_SYNC_BITOPS_H__ + +#include +#include + +/* sync_bitops functions are equivalent to the SMP implementation of the + * original functions, independently from CONFIG_SMP being defined. + * + * We need them because _set_bit etc are not SMP safe if !CONFIG_SMP. But + * under Xen you might be communicating with a completely external entity + * who might be on another CPU (e.g. two uniprocessor guests communicating + * via event channels and grant tables). So we need a variant of the bit + * ops which are SMP safe even on a UP kernel. + */ + +#define sync_set_bit(nr, p)_set_bit(nr, p) +#define sync_clear_bit(nr, p) _clear_bit(nr, p) +#define sync_change_bit(nr, p) _change_bit(nr, p) +#define sync_test_and_set_bit(nr, p) _test_and_set_bit(nr, p) +#define sync_test_and_clear_bit(nr, p) _test_and_clear_bit(nr, p) +#define sync_test_and_change_bit(nr, p)_test_and_change_bit(nr, p) +#define sync_test_bit(nr, addr)test_bit(nr, addr) +#define sync_cmpxchg cmpxchg + + +#endif -- 1.7.2.5 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 02/17] xen/arm: hypercalls
Use r12 to pass the hypercall number to the hypervisor. We need a register to pass the hypercall number because we might not know it at compile time and HVC only takes an immediate argument. Among the available registers r12 seems to be the best choice because it is defined as "intra-procedure call scratch register". Use the ISS to pass an hypervisor specific tag. Changes in v2: - define an HYPERCALL macro for 5 arguments hypercall wrappers, even if at the moment is unused; - use ldm instead of pop; - fix up comments. Signed-off-by: Stefano Stabellini Reviewed-by: Konrad Rzeszutek Wilk --- arch/arm/include/asm/xen/hypercall.h | 50 arch/arm/xen/Makefile|2 +- arch/arm/xen/hypercall.S | 106 ++ 3 files changed, 157 insertions(+), 1 deletions(-) create mode 100644 arch/arm/include/asm/xen/hypercall.h create mode 100644 arch/arm/xen/hypercall.S diff --git a/arch/arm/include/asm/xen/hypercall.h b/arch/arm/include/asm/xen/hypercall.h new file mode 100644 index 000..4ac0624 --- /dev/null +++ b/arch/arm/include/asm/xen/hypercall.h @@ -0,0 +1,50 @@ +/** + * hypercall.h + * + * Linux-specific hypervisor handling. + * + * Stefano Stabellini , Citrix, 2012 + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (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. + */ + +#ifndef _ASM_ARM_XEN_HYPERCALL_H +#define _ASM_ARM_XEN_HYPERCALL_H + +#include + +long privcmd_call(unsigned call, unsigned long a1, + unsigned long a2, unsigned long a3, + unsigned long a4, unsigned long a5); +int HYPERVISOR_xen_version(int cmd, void *arg); +int HYPERVISOR_console_io(int cmd, int count, char *str); +int HYPERVISOR_grant_table_op(unsigned int cmd, void *uop, unsigned int count); +int HYPERVISOR_sched_op(int cmd, void *arg); +int HYPERVISOR_event_channel_op(int cmd, void *arg); +unsigned long HYPERVISOR_hvm_op(int op, void *arg); +int HYPERVISOR_memory_op(unsigned int cmd, void *arg); +int HYPERVISOR_physdev_op(int cmd, void *arg); + +#endif /* _ASM_ARM_XEN_HYPERCALL_H */ diff --git a/arch/arm/xen/Makefile b/arch/arm/xen/Makefile index 0bad594..b9d6acc 100644 --- a/arch/arm/xen/Makefile +++ b/arch/arm/xen/Makefile @@ -1 +1 @@ -obj-y := enlighten.o +obj-y := enlighten.o hypercall.o diff --git a/arch/arm/xen/hypercall.S b/arch/arm/xen/hypercall.S new file mode 100644 index 000..074f5ed --- /dev/null +++ b/arch/arm/xen/hypercall.S @@ -0,0 +1,106 @@ +/** + * hypercall.S + * + * Xen hypercall wrappers + * + * Stefano Stabellini , Citrix, 2012 + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (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
[PATCH v5 03/17] xen/arm: page.h definitions
ARM Xen guests always use paging in hardware, like PV on HVM guests in
the X86 world.
Changes in v3:
- improve comments.
Signed-off-by: Stefano Stabellini
Acked-by: Konrad Rzeszutek Wilk
---
arch/arm/include/asm/xen/page.h | 82 +++
1 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/xen/page.h
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
new file mode 100644
index 000..1742023
--- /dev/null
+++ b/arch/arm/include/asm/xen/page.h
@@ -0,0 +1,82 @@
+#ifndef _ASM_ARM_XEN_PAGE_H
+#define _ASM_ARM_XEN_PAGE_H
+
+#include
+#include
+
+#include
+#include
+
+#include
+
+#define pfn_to_mfn(pfn)(pfn)
+#define phys_to_machine_mapping_valid (1)
+#define mfn_to_pfn(mfn)(mfn)
+#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+#define pte_mfnpte_pfn
+#define mfn_ptepfn_pte
+
+/* Xen machine address */
+typedef struct xmaddr {
+ phys_addr_t maddr;
+} xmaddr_t;
+
+/* Xen pseudo-physical address */
+typedef struct xpaddr {
+ phys_addr_t paddr;
+} xpaddr_t;
+
+#define XMADDR(x) ((xmaddr_t) { .maddr = (x) })
+#define XPADDR(x) ((xpaddr_t) { .paddr = (x) })
+
+static inline xmaddr_t phys_to_machine(xpaddr_t phys)
+{
+ unsigned offset = phys.paddr & ~PAGE_MASK;
+ return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+}
+
+static inline xpaddr_t machine_to_phys(xmaddr_t machine)
+{
+ unsigned offset = machine.maddr & ~PAGE_MASK;
+ return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+}
+/* VIRT <-> MACHINE conversion */
+#define virt_to_machine(v) (phys_to_machine(XPADDR(__pa(v
+#define virt_to_pfn(v) (PFN_DOWN(__pa(v)))
+#define virt_to_mfn(v) (pfn_to_mfn(virt_to_pfn(v)))
+#define mfn_to_virt(m) (__va(mfn_to_pfn(m) << PAGE_SHIFT))
+
+static inline xmaddr_t arbitrary_virt_to_machine(void *vaddr)
+{
+ /* TODO: assuming it is mapped in the kernel 1:1 */
+ return virt_to_machine(vaddr);
+}
+
+/* TODO: this shouldn't be here but it is because the frontend drivers
+ * are using it (its rolled in headers) even though we won't hit the code path.
+ * So for right now just punt with this.
+ */
+static inline pte_t *lookup_address(unsigned long address, unsigned int *level)
+{
+ BUG();
+ return NULL;
+}
+
+static inline int m2p_add_override(unsigned long mfn, struct page *page,
+ struct gnttab_map_grant_ref *kmap_op)
+{
+ return 0;
+}
+
+static inline int m2p_remove_override(struct page *page, bool clear_pte)
+{
+ return 0;
+}
+
+static inline bool set_phys_to_machine(unsigned long pfn, unsigned long mfn)
+{
+ BUG();
+ return false;
+}
+#endif /* _ASM_ARM_XEN_PAGE_H */
--
1.7.2.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 01/17] arm: initial Xen support
- Basic hypervisor.h and interface.h definitions.
- Skeleton enlighten.c, set xen_start_info to an empty struct.
- Make xen_initial_domain dependent on the SIF_PRIVILIGED_BIT.
The new code only compiles when CONFIG_XEN is set, that is going to be
added to arch/arm/Kconfig in patch #11 "xen/arm: introduce CONFIG_XEN on
ARM".
Changes in v3:
- improve comments.
Signed-off-by: Stefano Stabellini
Acked-by: Konrad Rzeszutek Wilk
---
arch/arm/Makefile |1 +
arch/arm/include/asm/hypervisor.h |6 +++
arch/arm/include/asm/xen/hypervisor.h | 19 +
arch/arm/include/asm/xen/interface.h | 69 +
arch/arm/xen/Makefile |1 +
arch/arm/xen/enlighten.c | 35 +
include/xen/xen.h |2 +-
7 files changed, 132 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/include/asm/hypervisor.h
create mode 100644 arch/arm/include/asm/xen/hypervisor.h
create mode 100644 arch/arm/include/asm/xen/interface.h
create mode 100644 arch/arm/xen/Makefile
create mode 100644 arch/arm/xen/enlighten.c
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 30eae87..f42968a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -251,6 +251,7 @@ endif
core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/
core-$(CONFIG_FPE_FASTFPE) += $(FASTFPE_OBJ)
core-$(CONFIG_VFP) += arch/arm/vfp/
+core-$(CONFIG_XEN) += arch/arm/xen/
# If we have a machine-specific directory, then include it in the build.
core-y += arch/arm/kernel/ arch/arm/mm/
arch/arm/common/
diff --git a/arch/arm/include/asm/hypervisor.h
b/arch/arm/include/asm/hypervisor.h
new file mode 100644
index 000..b90d9e5
--- /dev/null
+++ b/arch/arm/include/asm/hypervisor.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_ARM_HYPERVISOR_H
+#define _ASM_ARM_HYPERVISOR_H
+
+#include
+
+#endif
diff --git a/arch/arm/include/asm/xen/hypervisor.h
b/arch/arm/include/asm/xen/hypervisor.h
new file mode 100644
index 000..d7ab99a
--- /dev/null
+++ b/arch/arm/include/asm/xen/hypervisor.h
@@ -0,0 +1,19 @@
+#ifndef _ASM_ARM_XEN_HYPERVISOR_H
+#define _ASM_ARM_XEN_HYPERVISOR_H
+
+extern struct shared_info *HYPERVISOR_shared_info;
+extern struct start_info *xen_start_info;
+
+/* Lazy mode for batching updates / context switch */
+enum paravirt_lazy_mode {
+ PARAVIRT_LAZY_NONE,
+ PARAVIRT_LAZY_MMU,
+ PARAVIRT_LAZY_CPU,
+};
+
+static inline enum paravirt_lazy_mode paravirt_get_lazy_mode(void)
+{
+ return PARAVIRT_LAZY_NONE;
+}
+
+#endif /* _ASM_ARM_XEN_HYPERVISOR_H */
diff --git a/arch/arm/include/asm/xen/interface.h
b/arch/arm/include/asm/xen/interface.h
new file mode 100644
index 000..74c72b5
--- /dev/null
+++ b/arch/arm/include/asm/xen/interface.h
@@ -0,0 +1,69 @@
+/**
+ * Guest OS interface to ARM Xen.
+ *
+ * Stefano Stabellini , Citrix, 2012
+ */
+
+#ifndef _ASM_ARM_XEN_INTERFACE_H
+#define _ASM_ARM_XEN_INTERFACE_H
+
+#include
+
+#define __DEFINE_GUEST_HANDLE(name, type) \
+ typedef type * __guest_handle_ ## name
+
+#define DEFINE_GUEST_HANDLE_STRUCT(name) \
+ __DEFINE_GUEST_HANDLE(name, struct name)
+#define DEFINE_GUEST_HANDLE(name) __DEFINE_GUEST_HANDLE(name, name)
+#define GUEST_HANDLE(name)__guest_handle_ ## name
+
+#define set_xen_guest_handle(hnd, val) \
+ do {\
+ if (sizeof(hnd) == 8) \
+ *(uint64_t *)&(hnd) = 0;\
+ (hnd) = val;\
+ } while (0)
+
+#ifndef __ASSEMBLY__
+/* Explicitly size integers that represent pfns in the interface with
+ * Xen so that we can have one ABI that works for 32 and 64 bit guests. */
+typedef uint64_t xen_pfn_t;
+/* Guest handles for primitive C types. */
+__DEFINE_GUEST_HANDLE(uchar, unsigned char);
+__DEFINE_GUEST_HANDLE(uint, unsigned int);
+__DEFINE_GUEST_HANDLE(ulong, unsigned long);
+DEFINE_GUEST_HANDLE(char);
+DEFINE_GUEST_HANDLE(int);
+DEFINE_GUEST_HANDLE(long);
+DEFINE_GUEST_HANDLE(void);
+DEFINE_GUEST_HANDLE(uint64_t);
+DEFINE_GUEST_HANDLE(uint32_t);
+DEFINE_GUEST_HANDLE(xen_pfn_t);
+
+/* Maximum number of virtual CPUs in multi-processor guests. */
+#define MAX_VIRT_CPUS 1
+
+struct arch_vcpu_info { };
+struct arch_shared_info { };
+
+/* TODO: Move pvclock definitions some place arch independent */
+struct pvclock_vcpu_time_info {
+ u32 version;
+ u32 pad0;
+ u64 tsc_timestamp;
+ u64 system_time;
+ u32 tsc_to_system_mul;
+ s8tsc_shift;
+ u8flags;
+ u8pad[2];
+} __attribute__((__packed__)); /* 32 bytes */
+
+/* It is OK to have a 12 bytes struct with no padding because it is packed */
+struct pvclock_wall_clock {
+ u32 version;
+ u32 sec;
+ u32 nsec;
+} __attribute__(
[PATCH v5 09/17] xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on ARM
Changes in v4: - compile pcpu only on x86; - use "+=" instead of ":=" for dom0- targets. Changes in v2: - make pci.o depend on CONFIG_PCI and acpi.o depend on CONFIG_ACPI. Signed-off-by: Stefano Stabellini Acked-by: Konrad Rzeszutek Wilk --- drivers/xen/Makefile | 13 + 1 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile index d80bea5..cd28aae 100644 --- a/drivers/xen/Makefile +++ b/drivers/xen/Makefile @@ -1,11 +1,18 @@ -obj-y += grant-table.o features.o events.o manage.o balloon.o +ifneq ($(CONFIG_ARM),y) +obj-y += manage.o balloon.o +obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o +endif +obj-y += grant-table.o features.o events.o obj-y += xenbus/ nostackp := $(call cc-option, -fno-stack-protector) CFLAGS_features.o := $(nostackp) +obj-$(CONFIG_XEN_DOM0) += $(dom0-y) +dom0-$(CONFIG_PCI) += pci.o +dom0-$(CONFIG_ACPI) += acpi.o +dom0-$(CONFIG_X86) += pcpu.o obj-$(CONFIG_BLOCK)+= biomerge.o -obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o obj-$(CONFIG_XEN_XENCOMM) += xencomm.o obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o obj-$(CONFIG_XEN_SELFBALLOONING) += xen-selfballoon.o @@ -17,8 +24,6 @@ obj-$(CONFIG_XEN_SYS_HYPERVISOR) += sys-hypervisor.o obj-$(CONFIG_XEN_PVHVM)+= platform-pci.o obj-$(CONFIG_XEN_TMEM) += tmem.o obj-$(CONFIG_SWIOTLB_XEN) += swiotlb-xen.o -obj-$(CONFIG_XEN_DOM0) += pcpu.o -obj-$(CONFIG_XEN_DOM0) += pci.o acpi.o obj-$(CONFIG_XEN_MCE_LOG) += mcelog.o obj-$(CONFIG_XEN_PCIDEV_BACKEND) += xen-pciback/ obj-$(CONFIG_XEN_PRIVCMD) += xen-privcmd.o -- 1.7.2.5 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 10/17] xen/arm: introduce CONFIG_XEN on ARM
Changes in v5: - make XEN_DOM0 depend on XEN; - avoid "select XEN_DOM0" in XEN. Changes in v2: - mark Xen guest support on ARM as EXPERIMENTAL. Signed-off-by: Stefano Stabellini CC: Sergei Shtylyov --- arch/arm/Kconfig | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 2f88d8d..3361466 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1897,6 +1897,16 @@ config DEPRECATED_PARAM_STRUCT This was deprecated in 2001 and announced to live on for 5 years. Some old boot loaders still use this way. +config XEN_DOM0 + def_bool y + depends on XEN + +config XEN + bool "Xen guest support on ARM (EXPERIMENTAL)" + depends on EXPERIMENTAL && ARM && OF + help + Say Y if you want to run Linux in a Virtual Machine on Xen on ARM. + endmenu menu "Boot options" -- 1.7.2.5 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 08/17] xen/arm: Introduce xen_ulong_t for unsigned long
All the original Xen headers have xen_ulong_t as unsigned long type, however
when they have been imported in Linux, xen_ulong_t has been replaced with
unsigned long. That might work for x86 and ia64 but it does not for arm.
Bring back xen_ulong_t and let each architecture define xen_ulong_t as they
see fit.
Also explicitly size pointers (__DEFINE_GUEST_HANDLE) to 64 bit.
Changes in v3:
- remove the incorrect changes to multicall_entry;
- remove the change to apic_physbase.
Signed-off-by: Stefano Stabellini
Acked-by: Konrad Rzeszutek Wilk
---
arch/arm/include/asm/xen/interface.h |8 ++--
arch/ia64/include/asm/xen/interface.h |1 +
arch/x86/include/asm/xen/interface.h |1 +
include/xen/interface/memory.h| 12 ++--
include/xen/interface/physdev.h |2 +-
include/xen/interface/version.h |2 +-
6 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/xen/interface.h
b/arch/arm/include/asm/xen/interface.h
index 74c72b5..ae05e56 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -9,8 +9,11 @@
#include
+#define uint64_aligned_t uint64_t __attribute__((aligned(8)))
+
#define __DEFINE_GUEST_HANDLE(name, type) \
- typedef type * __guest_handle_ ## name
+ typedef struct { union { type *p; uint64_aligned_t q; }; } \
+__guest_handle_ ## name
#define DEFINE_GUEST_HANDLE_STRUCT(name) \
__DEFINE_GUEST_HANDLE(name, struct name)
@@ -21,13 +24,14 @@
do {\
if (sizeof(hnd) == 8) \
*(uint64_t *)&(hnd) = 0;\
- (hnd) = val;\
+ (hnd).p = val; \
} while (0)
#ifndef __ASSEMBLY__
/* Explicitly size integers that represent pfns in the interface with
* Xen so that we can have one ABI that works for 32 and 64 bit guests. */
typedef uint64_t xen_pfn_t;
+typedef uint64_t xen_ulong_t;
/* Guest handles for primitive C types. */
__DEFINE_GUEST_HANDLE(uchar, unsigned char);
__DEFINE_GUEST_HANDLE(uint, unsigned int);
diff --git a/arch/ia64/include/asm/xen/interface.h
b/arch/ia64/include/asm/xen/interface.h
index 3d52a5b..e88c5de 100644
--- a/arch/ia64/include/asm/xen/interface.h
+++ b/arch/ia64/include/asm/xen/interface.h
@@ -71,6 +71,7 @@
* with Xen so that we could have one ABI that works for 32 and 64 bit
* guests. */
typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
/* Guest handles for primitive C types. */
__DEFINE_GUEST_HANDLE(uchar, unsigned char);
__DEFINE_GUEST_HANDLE(uint, unsigned int);
diff --git a/arch/x86/include/asm/xen/interface.h
b/arch/x86/include/asm/xen/interface.h
index 555f94d..28fc621 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -51,6 +51,7 @@
* with Xen so that on ARM we can have one ABI that works for 32 and 64
* bit guests. */
typedef unsigned long xen_pfn_t;
+typedef unsigned long xen_ulong_t;
/* Guest handles for primitive C types. */
__DEFINE_GUEST_HANDLE(uchar, unsigned char);
__DEFINE_GUEST_HANDLE(uint, unsigned int);
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index d8e33a9..b66d04c 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -34,7 +34,7 @@ struct xen_memory_reservation {
GUEST_HANDLE(xen_pfn_t) extent_start;
/* Number of extents, and size/alignment of each (2^extent_order pages). */
-unsigned long nr_extents;
+xen_ulong_t nr_extents;
unsigned int extent_order;
/*
@@ -92,7 +92,7 @@ struct xen_memory_exchange {
* command will be non-zero.
* 5. THIS FIELD MUST BE INITIALISED TO ZERO BY THE CALLER!
*/
-unsigned long nr_exchanged;
+xen_ulong_t nr_exchanged;
};
DEFINE_GUEST_HANDLE_STRUCT(xen_memory_exchange);
@@ -148,8 +148,8 @@ DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mfn_list);
*/
#define XENMEM_machphys_mapping 12
struct xen_machphys_mapping {
-unsigned long v_start, v_end; /* Start and end virtual addresses. */
-unsigned long max_mfn;/* Maximum MFN that can be looked up. */
+xen_ulong_t v_start, v_end; /* Start and end virtual addresses. */
+xen_ulong_t max_mfn;/* Maximum MFN that can be looked up. */
};
DEFINE_GUEST_HANDLE_STRUCT(xen_machphys_mapping_t);
@@ -172,7 +172,7 @@ struct xen_add_to_physmap {
unsigned int space;
/* Index into source mapping space. */
-unsigned long idx;
+xen_ulong_t idx;
/* GPFN where the source mapping page should appear. */
xen_pfn_t gpfn;
@@ -189,7 +189,7 @@ struct xen_translate_gpfn_list {
domid_t domid;
/* Length of list. */
-unsigned long nr_gpfns;
+xen_ulong_t nr_gpfns;
/* List of GPFNs to translate. */
GUEST_HANDLE(ulong) gpfn_list;
diff --git a/include
[PATCH v5 16/17] xen/arm: compile netback
Signed-off-by: Stefano Stabellini
Acked-by: Konrad Rzeszutek Wilk
---
arch/arm/include/asm/xen/hypercall.h | 19 +++
drivers/net/xen-netback/netback.c|1 +
drivers/net/xen-netfront.c |1 +
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/xen/hypercall.h
b/arch/arm/include/asm/xen/hypercall.h
index 4ac0624..8a82325 100644
--- a/arch/arm/include/asm/xen/hypercall.h
+++ b/arch/arm/include/asm/xen/hypercall.h
@@ -47,4 +47,23 @@ unsigned long HYPERVISOR_hvm_op(int op, void *arg);
int HYPERVISOR_memory_op(unsigned int cmd, void *arg);
int HYPERVISOR_physdev_op(int cmd, void *arg);
+static inline void
+MULTI_update_va_mapping(struct multicall_entry *mcl, unsigned long va,
+ unsigned int new_val, unsigned long flags)
+{
+ BUG();
+}
+
+static inline void
+MULTI_mmu_update(struct multicall_entry *mcl, struct mmu_update *req,
+int count, int *success_count, domid_t domid)
+{
+ BUG();
+}
+
+static inline int
+HYPERVISOR_multicall(void *call_list, int nr_calls)
+{
+ BUG();
+}
#endif /* _ASM_ARM_XEN_HYPERCALL_H */
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 682633b..1c0a302 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -40,6 +40,7 @@
#include
+#include
#include
#include
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 650f79a..24d968d 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -43,6 +43,7 @@
#include
#include
+#include
#include
#include
#include
--
1.7.2.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 12/17] xen/arm: initialize grant_table on ARM
Initialize the grant table mapping at the address specified at index 0
in the DT under the /xen node.
After the grant table is initialized, call xenbus_probe (if not dom0).
Changes in v2:
- introduce GRANT_TABLE_PHYSADDR;
- remove unneeded initialization of boot_max_nr_grant_frames.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/enlighten.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index c2a47a7..036a4d8 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,8 +1,12 @@
#include
+#include
+#include
#include
#include
+#include
#include
#include
+#include
#include
#include
#include
@@ -42,6 +46,7 @@ EXPORT_SYMBOL_GPL(xen_remap_domain_mfn_range);
* see Documentation/devicetree/bindings/arm/xen.txt for the
* documentation of the Xen Device Tree format.
*/
+#define GRANT_TABLE_PHYSADDR 0
static int __init xen_guest_init(void)
{
struct xen_add_to_physmap xatp;
@@ -51,6 +56,7 @@ static int __init xen_guest_init(void)
const char *s = NULL;
const char *version = NULL;
const char *xen_prefix = "xen,xen-";
+ struct resource res;
node = of_find_compatible_node(NULL, NULL, "xen,xen");
if (!node) {
@@ -65,6 +71,9 @@ static int __init xen_guest_init(void)
pr_debug("Xen version not found\n");
return 0;
}
+ if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
+ return 0;
+ xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
xen_domain_type = XEN_HVM_DOMAIN;
xen_setup_features();
@@ -98,6 +107,11 @@ static int __init xen_guest_init(void)
* is required to use VCPUOP_register_vcpu_info to place vcpu info
* for secondary CPUs as they are brought up. */
per_cpu(xen_vcpu, 0) = &HYPERVISOR_shared_info->vcpu_info[0];
+
+ gnttab_init();
+ if (!xen_initial_domain())
+ xenbus_probe(NULL);
+
return 0;
}
core_initcall(xen_guest_init);
--
1.7.2.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 14/17] xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
Only until we get the balloon driver to work.
Signed-off-by: Stefano Stabellini
Acked-by: Konrad Rzeszutek Wilk
---
arch/arm/xen/enlighten.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index bad67ad..59bcb96 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -148,3 +148,21 @@ static int __init xen_init_events(void)
return 0;
}
postcore_initcall(xen_init_events);
+
+/* XXX: only until balloon is properly working */
+int alloc_xenballooned_pages(int nr_pages, struct page **pages, bool highmem)
+{
+ *pages = alloc_pages(highmem ? GFP_HIGHUSER : GFP_KERNEL,
+ get_order(nr_pages));
+ if (*pages == NULL)
+ return -ENOMEM;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(alloc_xenballooned_pages);
+
+void free_xenballooned_pages(int nr_pages, struct page **pages)
+{
+ kfree(*pages);
+ *pages = NULL;
+}
+EXPORT_SYMBOL_GPL(free_xenballooned_pages);
--
1.7.2.5
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 11/17] xen/arm: get privilege status
Use Xen features to figure out if we are privileged. XENFEAT_dom0 was introduced by 23735 in xen-unstable.hg. Signed-off-by: Stefano Stabellini Acked-by: Konrad Rzeszutek Wilk --- arch/arm/xen/enlighten.c |7 +++ include/xen/interface/features.h |3 +++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index 6a0217d..c2a47a7 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -1,6 +1,7 @@ #include #include #include +#include #include #include #include @@ -66,6 +67,12 @@ static int __init xen_guest_init(void) } xen_domain_type = XEN_HVM_DOMAIN; + xen_setup_features(); + if (xen_feature(XENFEAT_dom0)) + xen_start_info->flags |= SIF_INITDOMAIN|SIF_PRIVILEGED; + else + xen_start_info->flags &= ~(SIF_INITDOMAIN|SIF_PRIVILEGED); + if (!shared_info_page) shared_info_page = (struct shared_info *) get_zeroed_page(GFP_KERNEL); diff --git a/include/xen/interface/features.h b/include/xen/interface/features.h index b6ca39a..131a6cc 100644 --- a/include/xen/interface/features.h +++ b/include/xen/interface/features.h @@ -50,6 +50,9 @@ /* x86: pirq can be used by HVM guests */ #define XENFEAT_hvm_pirqs 10 +/* operation as Dom0 is supported */ +#define XENFEAT_dom0 11 + #define XENFEAT_NR_SUBMAPS 1 #endif /* __XEN_PUBLIC_FEATURES_H__ */ -- 1.7.2.5 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 15/17] xen/arm: compile blkfront and blkback
Signed-off-by: Stefano Stabellini Acked-by: Konrad Rzeszutek Wilk --- drivers/block/xen-blkback/blkback.c |1 + include/xen/interface/io/protocols.h |3 +++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-blkback/blkback.c index 73f196c..63dd5b9 100644 --- a/drivers/block/xen-blkback/blkback.c +++ b/drivers/block/xen-blkback/blkback.c @@ -42,6 +42,7 @@ #include #include +#include #include #include #include "common.h" diff --git a/include/xen/interface/io/protocols.h b/include/xen/interface/io/protocols.h index 01fc8ae..0eafaf2 100644 --- a/include/xen/interface/io/protocols.h +++ b/include/xen/interface/io/protocols.h @@ -5,6 +5,7 @@ #define XEN_IO_PROTO_ABI_X86_64 "x86_64-abi" #define XEN_IO_PROTO_ABI_IA64 "ia64-abi" #define XEN_IO_PROTO_ABI_POWERPC64 "powerpc64-abi" +#define XEN_IO_PROTO_ABI_ARM"arm-abi" #if defined(__i386__) # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_X86_32 @@ -14,6 +15,8 @@ # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_IA64 #elif defined(__powerpc64__) # define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_POWERPC64 +#elif defined(__arm__) +# define XEN_IO_PROTO_ABI_NATIVE XEN_IO_PROTO_ABI_ARM #else # error arch fixup needed here #endif -- 1.7.2.5 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 17/17] MAINTAINERS: add myself as Xen ARM maintainer
Signed-off-by: Stefano Stabellini Acked-by: Konrad Rzeszutek Wilk CC: Arnd Bergmann --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fdc0119..3d38291 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7752,6 +7752,13 @@ F: drivers/xen/ F: arch/x86/include/asm/xen/ F: include/xen/ +XEN HYPERVISOR ARM +M: Stefano Stabellini +L: xen-de...@lists.xensource.com (moderated for non-subscribers) +S: Supported +F: arch/arm/xen/ +F: arch/arm/include/asm/xen/ + XEN NETWORK BACKEND DRIVER M: Ian Campbell L: xen-de...@lists.xensource.com (moderated for non-subscribers) -- 1.7.2.5 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH v5 13/17] xen/arm: receive Xen events on ARM
Compile events.c on ARM.
Parse, map and enable the IRQ to get event notifications from the device
tree (node "/xen").
Signed-off-by: Stefano Stabellini
Acked-by: Konrad Rzeszutek Wilk
---
arch/arm/include/asm/xen/events.h | 18 ++
arch/arm/xen/enlighten.c | 33 +
arch/x86/xen/enlighten.c |1 +
arch/x86/xen/irq.c|1 +
arch/x86/xen/xen-ops.h|1 -
drivers/xen/events.c | 17 ++---
include/xen/events.h |2 ++
7 files changed, 69 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/include/asm/xen/events.h
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
new file mode 100644
index 000..94b4e90
--- /dev/null
+++ b/arch/arm/include/asm/xen/events.h
@@ -0,0 +1,18 @@
+#ifndef _ASM_ARM_XEN_EVENTS_H
+#define _ASM_ARM_XEN_EVENTS_H
+
+#include
+
+enum ipi_vector {
+ XEN_PLACEHOLDER_VECTOR,
+
+ /* Xen IPIs go here */
+ XEN_NR_IPIS,
+};
+
+static inline int xen_irqs_disabled(struct pt_regs *regs)
+{
+ return raw_irqs_disabled_flags(regs->ARM_cpsr);
+}
+
+#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 036a4d8..bad67ad 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -1,4 +1,5 @@
#include
+#include
#include
#include
#include
@@ -9,6 +10,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -33,6 +36,8 @@ EXPORT_SYMBOL_GPL(xen_have_vector_callback);
int xen_platform_pci_unplug = XEN_UNPLUG_ALL;
EXPORT_SYMBOL_GPL(xen_platform_pci_unplug);
+static __read_mostly int xen_events_irq = -1;
+
int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
unsigned long addr,
unsigned long mfn, int nr,
@@ -74,6 +79,9 @@ static int __init xen_guest_init(void)
if (of_address_to_resource(node, GRANT_TABLE_PHYSADDR, &res))
return 0;
xen_hvm_resume_frames = res.start >> PAGE_SHIFT;
+ xen_events_irq = irq_of_parse_and_map(node, 0);
+ pr_info("Xen %s support found, events_irq=%d gnttab_frame_pfn=%lx\n",
+ version, xen_events_irq, xen_hvm_resume_frames);
xen_domain_type = XEN_HVM_DOMAIN;
xen_setup_features();
@@ -115,3 +123,28 @@ static int __init xen_guest_init(void)
return 0;
}
core_initcall(xen_guest_init);
+
+static irqreturn_t xen_arm_callback(int irq, void *arg)
+{
+ xen_hvm_evtchn_do_upcall();
+ return IRQ_HANDLED;
+}
+
+static int __init xen_init_events(void)
+{
+ if (!xen_domain() || xen_events_irq < 0)
+ return -ENODEV;
+
+ xen_init_IRQ();
+
+ if (request_percpu_irq(xen_events_irq, xen_arm_callback,
+ "events", xen_vcpu)) {
+ pr_err("Error requesting IRQ %d\n", xen_events_irq);
+ return -EINVAL;
+ }
+
+ enable_percpu_irq(xen_events_irq, 0);
+
+ return 0;
+}
+postcore_initcall(xen_init_events);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 47b3acd..689a4c9 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,6 +33,7 @@
#include
#include
+#include
#include
#include
#include
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 1573376..01a4dc0 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index bb5a810..a95b417 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -35,7 +35,6 @@ void xen_set_pat(u64);
char * __init xen_memory_setup(void);
void __init xen_arch_setup(void);
-void __init xen_init_IRQ(void);
void xen_enable_sysenter(void);
void xen_enable_syscall(void);
void xen_vcpu_restore(void);
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index c60d162..8672211 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -31,14 +31,16 @@
#include
#include
+#ifdef CONFIG_X86
#include
#include
#include
#include
#include
-#include
#include
#include
+#endif
+#include
#include
#include
@@ -50,6 +52,9 @@
#include
#include
#include
+#include
+#include
+#include
/*
* This lock protects updates to the following mapping and reference-count
@@ -1386,7 +1391,9 @@ void xen_evtchn_do_upcall(struct pt_regs *regs)
{
struct pt_regs *old_regs = set_irq_regs(regs);
+#ifdef CONFIG_X86
exit_idle();
+#endif
irq_enter();
__xen_evtchn_do_upcall();
@@ -1795,9 +1802,9 @@ void xen_callback_vector(void)
void xen_callback_vector(void) {}
#endif
-void __init xen_init_IRQ(void)
+void xen_init_IRQ(void)
{
- int i, rc;
+ int i;
evtchn_to_irq = kcalloc(NR_EVENT_CHANNELS, sizeof(*evtchn_to_ir
Re: [GIT PULL]: big LITTLE MP v8
Hi Viresh, On 09/17/2012 01:49 PM, Viresh Kumar wrote: Hi Andrey, This is PULL request for big LITTLE MP v8 branch: Merged into linux-linaro-core-tracking, the tag is llct-20120917.0. Thanks, Andrey Major updates are: - Based on v3.6-rc5 - new branch from Paulm: rcu-hotplug-v1, vincent: scheduler-misc-v1 and sudeepk arm-multi_pmu_v1 - new version of patches from Morten: task-placement-v2 - config fragment updated for fast & slow cpu Compile tested only. -x-x--- The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217: Linux 3.6-rc5 (2012-09-08 16:43:45 -0700) are available in the git repository at: git://git.linaro.org/arm/big.LITTLE/mp.git big-LITTLE-MP-v8 for you to fetch changes up to eb07c27e2987ab3c16cedee1367694988efe3ff4: Merge branches 'per-cpu-thread-hotplug-v3-fixed', 'task-placement-v2', 'cpu-hotplug-get_online_cpus-v1', 'arm-asymmetric-support-v3-v3.6-rc1', 'rcu-hotplug-v1', 'arm-multi_pmu_v1', 'scheduler-misc-v1' and 'config-fragments' into big-LITTLE-MP-v8 (2012-09-17 09:26:07 +0530) Axel Lin (1): ARM: ux500: Fix build error due to missing include of asm/pmu.h in cpu-db8500.c Ben Segall (1): sched: maintain per-rq runnable averages Jon Hunter (1): ARM: PMU: Add runtime PM Support Jon Medhurst (6): configs: Initial core configs configs: Make CONFIG_MODULES part of linaro-base Merge branch 'config-core-3.4' into config-core-tracking configs: Replace CONFIG_PERF_COUNTERS with CONFIG_PERF_EVENTS configs: android: Enable FB_EARLYSUSPEND configs: android: Enable CONFIG_INPUT_UINPUT to get aidb working Lorenzo Pieralisi (1): ARM: kernel: provide cluster to logical cpu mask mapping API Morten Rasmussen (10): sched: entity load-tracking load_avg_ratio sched: Task placement for heterogeneous systems based on task load-tracking sched: Forced task migration on heterogeneous systems sched: Introduce priority-based task migration filter ARM: Add HMP scheduling support for ARM architecture ARM: sched: Use device-tree to provide fast/slow CPU list for HMP ARM: sched: Setup SCHED_HMP domains sched: Add ftrace events for entity load-tracking sched: Add HMP task migration ftrace event sched: SCHED_HMP multi-domain task migration control Paul E. McKenney (4): rcu: Use smp_hotplug_thread facility for RCUs per-CPU kthread hotplug: Fix UP bug in smpboot hotplug code rcu: Remove _rcu_barrier() dependency on __stop_machine() rcu: Disallow callback registry on offline CPUs Paul Turner (15): sched: track the runnable average on a per-task entitiy basis sched: aggregate load contributed by task entities on parenting cfs_rq sched: maintain the load contribution of blocked entities sched: add an rq migration call-back to sched_class sched: account for blocked load waking back up sched: aggregate total task_group load sched: compute load contribution by a group entity sched: normalize tg load contributions against runnable time sched: maintain runnable averages across throttled periods sched: replace update_shares weight distribution with per-entity computation sched: refactor update_shares_cpu() -> update_blocked_avgs() sched: update_cfs_shares at period edge sched: make __update_entity_runnable_avg() fast sched: implement usage tracking sched: introduce temporary FAIR_GROUP_SCHED dependency for load-tracking Peter Zijlstra (1): sched: Fix load avg vs cpu-hotplug Ricardo Salveti de Araujo (8): configs: moving previous ubuntu.conf as ubuntu-minimal and creating a full ubuntu one configs: ubuntu: be compatible with the enforce script configs: ubuntu: disabling CODA_FS, seems to be broken atm configs: ubuntu: disabling CGROUPS as default Merge branch 'config-core-3.4' into config-core-tracking configs: ubuntu: updating configs for 3.5 configs: ubuntu: disabling CONFIG_MTD_NAND_NANDSIM=m, breaking build config: ubuntu: ATH6KL should be platform dependent Silas Boyd-Wickizer (6): Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Use get_online_cpus to avoid races involving CPU hotplug Sudeep KarkadaNagesha (9): ARM: pmu: remove arm_pmu_type enumeration ARM: perf: move irq registration into pmu implementation ARM: perf: allocation of cpu_pmu at init time ARM: perf: ch
Re: [PATCH v2 3/3] devfreq: Add current freq callback in device profile
On Monday, September 17, 2012, MyungJoo Ham wrote:
> > From: Rajagopal Venkat
> >
> > Devfreq returns governor predicted frequency as current frequency
> > via sysfs interface. But device may not support all frequencies
> > that governor predicts. So add a callback in device profile to get
> > current freq from driver. Also add a new sysfs node to expose
> > governor predicted next target frequency.
> >
> > Signed-off-by: Rajagopal Venkat
>
> Signed-off-by: MyungJoo Ham
OK, I'm taking this as an acked-by (signed-off-by would be appropriate if
the patch went through your hands).
Does it apply to [3/3] only or to all of the patches in the series?
Rafael
> > ---
> > Documentation/ABI/testing/sysfs-class-devfreq | 11 ++-
> > drivers/devfreq/devfreq.c | 14 ++
> > include/linux/devfreq.h | 3 +++
> > 3 files changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-class-devfreq
> > b/Documentation/ABI/testing/sysfs-class-devfreq
> > index 89283b1..e6cf08e 100644
> > --- a/Documentation/ABI/testing/sysfs-class-devfreq
> > +++ b/Documentation/ABI/testing/sysfs-class-devfreq
> > @@ -19,7 +19,16 @@ Date:September 2011
> > Contact: MyungJoo Ham
> > Description:
> > The /sys/class/devfreq/.../cur_freq shows the current
> > - frequency of the corresponding devfreq object.
> > + frequency of the corresponding devfreq object. Same as
> > + target_freq when get_cur_freq() is not implemented by
> > + devfreq driver.
> > +
> > +What: /sys/class/devfreq/.../target_freq
> > +Date: September 2012
> > +Contact: Rajagopal Venkat
> > +Description:
> > + The /sys/class/devfreq/.../target_freq shows the next governor
> > + predicted target frequency of the corresponding devfreq object.
> >
> > What: /sys/class/devfreq/.../polling_interval
> > Date: September 2011
> > diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> > index 309c46e..049e273 100644
> > --- a/drivers/devfreq/devfreq.c
> > +++ b/drivers/devfreq/devfreq.c
> > @@ -401,6 +401,19 @@ static ssize_t show_governor(struct device *dev,
> > static ssize_t show_freq(struct device *dev,
> > struct device_attribute *attr, char *buf)
> > {
> > + unsigned long freq;
> > + struct devfreq *devfreq = to_devfreq(dev);
> > +
> > + if (devfreq->profile->get_cur_freq &&
> > + !devfreq->profile->get_cur_freq(devfreq->dev.parent, &freq))
> > + return sprintf(buf, "%lu\n", freq);
> > +
> > + return sprintf(buf, "%lu\n", devfreq->previous_freq);
> > +}
> > +
> > +static ssize_t show_target_freq(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > return sprintf(buf, "%lu\n", to_devfreq(dev)->previous_freq);
> > }
> >
> > @@ -504,6 +517,7 @@ static ssize_t show_max_freq(struct device *dev, struct
> > device_attribute *attr,
> > static struct device_attribute devfreq_attrs[] = {
> > __ATTR(governor, S_IRUGO, show_governor, NULL),
> > __ATTR(cur_freq, S_IRUGO, show_freq, NULL),
> > + __ATTR(target_freq, S_IRUGO, show_target_freq, NULL),
> > __ATTR(polling_interval, S_IRUGO | S_IWUSR, show_polling_interval,
> >store_polling_interval),
> > __ATTR(min_freq, S_IRUGO | S_IWUSR, show_min_freq, store_min_freq),
> > diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> > index 7c7e179..d12ed41 100644
> > --- a/include/linux/devfreq.h
> > +++ b/include/linux/devfreq.h
> > @@ -66,6 +66,8 @@ struct devfreq_dev_status {
> > * explained above with "DEVFREQ_FLAG_*" macros.
> > * @get_dev_status The device should provide the current performance
> > * status to devfreq, which is used by governors.
> > + * @get_cur_freq The device should provide the current frequency
> > + * at which it is operating.
> > * @exit An optional callback that is called when devfreq
> > * is removing the devfreq object due to error or
> > * from devfreq_remove_device() call. If the user
> > @@ -79,6 +81,7 @@ struct devfreq_dev_profile {
> > int (*target)(struct device *dev, unsigned long *freq, u32 flags);
> > int (*get_dev_status)(struct device *dev,
> > struct devfreq_dev_status *stat);
> > + int (*get_cur_freq)(struct device *dev, unsigned long *freq);
> > void (*exit)(struct device *dev);
> > };
> >
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/6] cpuidle : per cpu latencies
On Monday, September 17, 2012, Daniel Lezcano wrote: > On 09/08/2012 12:17 AM, Rafael J. Wysocki wrote: > > On Friday, September 07, 2012, Daniel Lezcano wrote: > >> Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab, > >> cpuidle: Single/Global registration of idle states > >> > >> we have a single registration for the cpuidle states which makes > >> sense. But now two new architectures are coming: tegra3 and big.LITTLE. > >> > >> These architectures have different cpus with different caracteristics > >> for power saving. High load => powerfull processors, idle => small > >> processors. > >> > >> That implies different cpu latencies. > >> > >> This patchset keeps the current behavior as introduced by Deepthi without > >> breaking the drivers and add the possibility to specify a per cpu states. > >> > >> * Tested on intel core 2 duo T9500 > >> * Tested on vexpress by Lorenzo Pieralsi > >> * Tested on tegra3 by Peter De Schrijver > >> > >> Daniel Lezcano (6): > >> acpi : move the acpi_idle_driver variable declaration > >> acpi : move cpuidle_device field out of the acpi_processor_power > >> structure > >> acpi : remove pointless cpuidle device state_count init > > > > I've posted comments about patches [1-3/6] already. In short, I don't like > > [1/6], [2/6] would require some more work IMO and I'm not sure about the > > validity of the observation that [3/6] is based on. > > > > Yes, I agree that the ACPI processor driver as a whole might be cleaner > > and it probably would be good to spend some time on cleaning it up, but > > not necessarily in a hurry. > > > > Unfortunately, I also don't agree with the approach used by the remaining > > patches, which is to try to use a separate array of states for each > > individual CPU core. This way we end up with quite some duplicated data > > if the CPU cores in question actually happen to be identical. > > Actually, there is a single array of states which is defined with the > cpuidle_driver. A pointer to this array from the cpuidle_device > structure is added and used from the cpuidle core. > > If the cpu cores are identical, this pointer will refer to the same array. OK, but what if there are two (or more) sets of cores, where all cores in one set are identical, but two cores from different sets differ? In that case it would be good to have one array of states per set, but the patch doesn't seem to do that, does it? > Maybe I misunderstood you remark but there is no data duplication, that > was the purpose of this approach to just add a pointer to point to a > single array when the core are identical and to a different array when > the cores are different (set by the driver). Furthermore, this patch > allows to support multiple cpu latencies without impacting the existing > drivers. Well that's required. :-) > > What about using a separate cpuidle driver for every kind of different CPUs > > in > > the system (e.g. one driver for "big" CPUs and the other for "little" ones)? > > > > Have you considered this approach already? > > No, what would be the benefit of this approach ? Uniform handling of all the CPUs of the same kind without data duplication and less code complexity, I think. > We will need to switch > the driver each time we switch the cluster (assuming all it is the bL > switcher in place and not the scheduler). IMHO, that could be suboptimal > because we will have to (un)register the driver, register the devices, > pull all the sysfs and notifications mechanisms. The cpuidle core is not > designed for that. I don't seem to understand how things are supposed to work, then. What _exactly_ do you mean by "the bL switcher", for instance? Rafael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/6] cpuidle : per cpu latencies
On 09/17/2012 10:50 PM, Rafael J. Wysocki wrote: > On Monday, September 17, 2012, Daniel Lezcano wrote: >> On 09/08/2012 12:17 AM, Rafael J. Wysocki wrote: >>> On Friday, September 07, 2012, Daniel Lezcano wrote: Since commit 46bcfad7a819bd17ac4e831b04405152d59784ab, cpuidle: Single/Global registration of idle states we have a single registration for the cpuidle states which makes sense. But now two new architectures are coming: tegra3 and big.LITTLE. These architectures have different cpus with different caracteristics for power saving. High load => powerfull processors, idle => small processors. That implies different cpu latencies. This patchset keeps the current behavior as introduced by Deepthi without breaking the drivers and add the possibility to specify a per cpu states. * Tested on intel core 2 duo T9500 * Tested on vexpress by Lorenzo Pieralsi * Tested on tegra3 by Peter De Schrijver Daniel Lezcano (6): acpi : move the acpi_idle_driver variable declaration acpi : move cpuidle_device field out of the acpi_processor_power structure acpi : remove pointless cpuidle device state_count init >>> >>> I've posted comments about patches [1-3/6] already. In short, I don't like >>> [1/6], [2/6] would require some more work IMO and I'm not sure about the >>> validity of the observation that [3/6] is based on. >>> >>> Yes, I agree that the ACPI processor driver as a whole might be cleaner >>> and it probably would be good to spend some time on cleaning it up, but >>> not necessarily in a hurry. >>> >>> Unfortunately, I also don't agree with the approach used by the remaining >>> patches, which is to try to use a separate array of states for each >>> individual CPU core. This way we end up with quite some duplicated data >>> if the CPU cores in question actually happen to be identical. >> >> Actually, there is a single array of states which is defined with the >> cpuidle_driver. A pointer to this array from the cpuidle_device >> structure is added and used from the cpuidle core. >> >> If the cpu cores are identical, this pointer will refer to the same array. > > OK, but what if there are two (or more) sets of cores, where all cores in one > set are identical, but two cores from different sets differ? A second array is defined and registered for these cores with the cpuidle_register_states function. Let's pick an example with the big.LITTLE architecture. There are two A7 and two A15, resulting in the code on 4 cpuidle_device structure (eg. dev_A7_1, dev_A7_2, dev_A15_1, dev_A15_2). Then the driver registers a different cpu states array for the A7s and the A15s At the end, dev_A7_1->states points to the array states 1 dev_A7_2->states points to the array states 1 dev_A15_1->states points to the array states 2 dev_A15_2->states points to the array states 2 It is similar with Tegra3. I think Peter and Lorenzo already wrote a driver based on this approach. Peter, Lorenzo any comments ? The single registration mechanism introduced by Deepthi is kept and we have a way to specify different idle states for different cpus. > In that case it would be good to have one array of states per set, but the > patch doesn't seem to do that, does it? Yes, this is what does the patch. >> Maybe I misunderstood you remark but there is no data duplication, that >> was the purpose of this approach to just add a pointer to point to a >> single array when the core are identical and to a different array when >> the cores are different (set by the driver). Furthermore, this patch >> allows to support multiple cpu latencies without impacting the existing >> drivers. > > Well that's required. :-) Yes :) >>> What about using a separate cpuidle driver for every kind of different CPUs >>> in >>> the system (e.g. one driver for "big" CPUs and the other for "little" ones)? >>> >>> Have you considered this approach already? >> >> No, what would be the benefit of this approach ? > > Uniform handling of all the CPUs of the same kind without data duplication > and less code complexity, I think. > >> We will need to switch >> the driver each time we switch the cluster (assuming all it is the bL >> switcher in place and not the scheduler). IMHO, that could be suboptimal >> because we will have to (un)register the driver, register the devices, >> pull all the sysfs and notifications mechanisms. The cpuidle core is not >> designed for that. > > I don't seem to understand how things are supposed to work, then. Sorry, I did not suggest that. I am wondering how several cpuidle drivers can co-exist together in the state of the code. Maybe I misunderstood your idea. The patchset I sent is pretty simple and do not duplicate the array states. That would be nice if Len could react to this patchset (4/6,5/6, and 6/6). Cc'ing him to its intel address. > What _exactly_ do you mean by "the bL switcher
Re: [PATCH v5 06/17] docs: Xen ARM DT bindings
On 09/17/2012 12:38 PM, Stefano Stabellini wrote:
> Add a doc to describe the Xen ARM device tree bindings
>
>
> Changes in v5:
>
> - add a comment about the size of the grant table memory region;
> - add a comment about the required presence of a GIC node;
> - specify that the described properties are part of a top-level
> "hypervisor" node;
> - specify #address-cells and #size-cells for the example.
>
>
> Changes in v4:
>
> - "xen,xen" should be last as it is less specific;
> - update reg property using 2 address-cells and 2 size-cells.
>
>
> Signed-off-by: Stefano Stabellini
> CC: devicetree-disc...@lists.ozlabs.org
> CC: David Vrabel
> CC: Rob Herring
> CC: Dave Martin
This is so minimal now and it doesn't seem to have any overlap with kvm, so:
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/arm/xen.txt | 25
> +
> 1 files changed, 25 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt
> b/Documentation/devicetree/bindings/arm/xen.txt
> new file mode 100644
> index 000..0f7b9c2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -0,0 +1,25 @@
> +* Xen hypervisor device tree bindings
> +
> +Xen ARM virtual platforms shall have a top-level "hypervisor" node with
> +the following properties:
> +
> +- compatible:
> + compatible = "xen,xen-", "xen,xen";
> + where is the version of the Xen ABI of the platform.
> +
> +- reg: specifies the base physical address and size of a region in
> + memory where the grant table should be mapped to, using an
> + HYPERVISOR_memory_op hypercall. The memory region is large enough to map
> + the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
> +
> +- interrupts: the interrupt used by Xen to inject event notifications.
> + A GIC node is also required.
> +
> +
> +Example (assuming #address-cells = <2> and #size-cells = <2>):
> +
> +hypervisor {
> + compatible = "xen,xen-4.3", "xen,xen";
> + reg = <0 0xb000 0 0x2>;
> + interrupts = <1 15 0xf08>;
> +};
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Re: [PATCH 1/3] devfreq: core updates to support devices which can idle
On 17 September 2012 17:46, MyungJoo Ham wrote: >> On 10 September 2012 14:43, 함명주 wrote: >> >> Prepare devfreq core framework to support devices which >> >> can idle. When device idleness is detected perhaps through >> >> runtime-pm, need some mechanism to suspend devfreq load >> >> monitoring and resume back when device is online. Present >> >> code continues monitoring unless device is removed from >> >> devfreq core. >> >> >> >> This patch introduces following design changes, >> >> >> >> - use per device work instead of global work to monitor device >> >> load. This enables suspend/resume of device devfreq and >> >> reduces monitoring code complexity. >> >> - decouple delayed work based load monitoring logic from core >> >> by introducing helpers functions to be used by governors. This >> >> provides flexibility for governors either to use delayed work >> >> based monitoring functions or to implement their own mechanism. >> >> - devfreq core interacts with governors via events to perform >> >> specific actions. These events include start/stop devfreq. >> >> This sets ground for adding suspend/resume events. >> >> >> >> The devfreq apis are not modified and are kept intact. >> > >> > Hello, >> > >> > Please revise locking mechanism along with event handler. >> > >> > It appears that we need to do mutex_lock(&devfreq->lock) before calling >> > devfreq->governor->event_handler(); >> >> I don't think is the case. The governor can make use of devfreq->lock if >> needed. >> Anyways, I have revised locking mechanism in v2 set. >> >> > Or at least, userspace_init and userspace_exit functions require >> > mutex_lock. >> >> The userspace_init function is executed only when device is added to devfreq >> framework. This function itself is creating sysfs attributes. So this should >> not >> be a concern for us. >> >> The userspace_exit is executed when device is removed from devfreq >> framework. sysfs_remove_group() should take care of serving any pending >> reference to sysfs attributes before removing them. No concern here as well. >> Am I missing something which demand locking for these functions? >> >> > Event_handler callback won't want the properties in devfreq to be changed >> > externally during its execution. >> >> Agree. > > If so, the GOV_INTERVAL handler of ondemand requires mutex_lock. > (and probably, nested mutex lock for monitor_resume) > I don't think so. The polling_ms value update and the GOV_INTERVAL event are handled in store_polling_interval() i.e same caller's context. So no reason for concern here. Also polling_ms value update and queuing the work(using polling_ms) are synchronized. > It determins next action based on the value protected by the > devfreq lock. It won't crash the kernel and it won't happen > often. However, it may behave incorrectly. > > Why don't we simply let the all the struct devfreq protected > when the external code (governors) is probably reading/writing the > protected values? > > This also guarantees that the event handler gets the exact status > modified by the event caller. Otherwise, the event handler may > get status different from the event caller's intention. > > > Cheers! > MyungJoo > > >> >> > >> > Plus, please edit Documentation/ABI entry (central_polling is being >> > removed) >> Done. >> > >> > Other than that, it looks fine. >> > >> > Cheers! >> > MyungJoo >> > >> >> >> >> Signed-off-by: Rajagopal Venkat >> >> --- >> >> drivers/devfreq/devfreq.c | 376 >> >> ++ >> >> drivers/devfreq/governor.h| 9 + >> >> drivers/devfreq/governor_performance.c| 16 +- >> >> drivers/devfreq/governor_powersave.c | 16 +- >> >> drivers/devfreq/governor_simpleondemand.c | 33 +++ >> >> drivers/devfreq/governor_userspace.c | 23 +- >> >> include/linux/devfreq.h | 31 +-- >> >> 7 files changed, 220 insertions(+), 284 deletions(-) >> >> >> >> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c >> >> index b146d76..be524c7 100644 >> >> --- a/drivers/devfreq/devfreq.c >> >> +++ b/drivers/devfreq/devfreq.c >> >> @@ -30,17 +30,11 @@ >> >> struct class *devfreq_class; >> >> >> >> /* >> >> - * devfreq_work periodically monitors every registered device. >> >> - * The minimum polling interval is one jiffy. The polling interval is >> >> - * determined by the minimum polling period among all polling devfreq >> >> - * devices. The resolution of polling interval is one jiffy. >> >> + * devfreq core provides delayed work based load monitoring helper >> >> + * functions. Governors can use these or can implement their own >> >> + * monitoring mechanism. >> >> */ >> >> -static bool polling; >> >> static struct workqueue_struct *devfreq_wq; >> >> -static struct delayed_work devfreq_work; >> >> - >> >> -/* wait removing if this is to be removed */ >> >> -static struct devfreq *wait_remove_device; >> >> >> >> /* The list of all device-devfreq */ >> >>
Re: Re: Re: [PATCH 1/3] devfreq: core updates to support devices which can idle
> Sender : Rajagopal Venkat > Date : 2012-09-18 14:20 (GMT+09:00) > Title : Re: Re: [PATCH 1/3] devfreq: core updates to support devices which > can idle > On 17 September 2012 17:46, MyungJoo Ham wrote: > >> On 10 September 2012 14:43, 함명주 wrote: > >> >> Prepare devfreq core framework to support devices which > >> >> can idle. When device idleness is detected perhaps through > >> >> runtime-pm, need some mechanism to suspend devfreq load > >> >> monitoring and resume back when device is online. Present > >> >> code continues monitoring unless device is removed from > >> >> devfreq core. > >> >> > >> >> This patch introduces following design changes, > >> >> > >> >> - use per device work instead of global work to monitor device > >> >> load. This enables suspend/resume of device devfreq and > >> >> reduces monitoring code complexity. > >> >> - decouple delayed work based load monitoring logic from core > >> >> by introducing helpers functions to be used by governors. This > >> >> provides flexibility for governors either to use delayed work > >> >> based monitoring functions or to implement their own mechanism. > >> >> - devfreq core interacts with governors via events to perform > >> >> specific actions. These events include start/stop devfreq. > >> >> This sets ground for adding suspend/resume events. > >> >> > >> >> The devfreq apis are not modified and are kept intact. > >> > > >> > Hello, > >> > > >> > Please revise locking mechanism along with event handler. > >> > > >> > It appears that we need to do mutex_lock(&devfreq->lock) before calling > >> > devfreq->governor->event_handler(); > >> > >> I don't think is the case. The governor can make use of devfreq->lock if > >> needed. > >> Anyways, I have revised locking mechanism in v2 set. > >> > >> > Or at least, userspace_init and userspace_exit functions require > >> > mutex_lock. > >> > >> The userspace_init function is executed only when device is added to > >> devfreq > >> framework. This function itself is creating sysfs attributes. So this > >> should not > >> be a concern for us. > >> > >> The userspace_exit is executed when device is removed from devfreq > >> framework. sysfs_remove_group() should take care of serving any pending > >> reference to sysfs attributes before removing them. No concern here as > >> well. > >> Am I missing something which demand locking for these functions? > >> > >> > Event_handler callback won't want the properties in devfreq to be > >> > changed externally during its execution. > >> > >> Agree. > > > > If so, the GOV_INTERVAL handler of ondemand requires mutex_lock. > > (and probably, nested mutex lock for monitor_resume) > > > I don't think so. The polling_ms value update and the GOV_INTERVAL > event are handled in store_polling_interval() i.e same caller's context. So > no reason for concern here. Also polling_ms value update and queuing > the work(using polling_ms) are synchronized. The proposed structure in this patch is: [mutex_lock] update value [mutex_unlock] ... [mutex_lock] use the updated value (including queueing the work) [mutex_unlock] It is not synchronized. If it is to be synchronized, the mutex should be kept locked. Besides, as mentioned below, in order to guarantee that the modified values related with an event trigger are kept intact for the event handlers, you need to keep the mutex locked. It may be a neglectible issue if we only consider polling_ms; however, we should never assume so because we can have custom governors and drivers. (or even more events are to be defined later) Please note that even if every devfreq driver implement mutex-lock/unlock appropriately, the consistency is not guaranteed as there is unlocked period between "update" and "read". Assuming that we are to support run-time governor changes and additional events later as discussed before, we'd better prepare this beforehand. > > > It determins next action based on the value protected by the > > devfreq lock. It won't crash the kernel and it won't happen > > often. However, it may behave incorrectly. > > > > Why don't we simply let the all the struct devfreq protected > > when the external code (governors) is probably reading/writing the > > protected values? > > > > This also guarantees that the event handler gets the exact status > > modified by the event caller. Otherwise, the event handler may > > get status different from the event caller's intention. > > > > > > Cheers! > > MyungJoo > > > > > >> > >> > > >> > Plus, please edit Documentation/ABI entry (central_polling is being > >> > removed) > >> Done. > >> > > >> > Other than that, it looks fine. > >> > > >> > Cheers! > >> > MyungJoo > >> > > >> >> > >> >> Signed-off-by: Rajagopal Venkat > >> >> --- > >> >> drivers/devfreq/devfreq.c | 376 > >> >> ++ > >> >> drivers/devfreq/governor.h| 9 + > >> >> drivers/devfreq/governor_performance.c| 16 +- > >> >> drivers/devfr
