[PATCH 3/4] cpu_cooling: Keep only one of_cpufreq*cooling_register() helper
of_cpufreq_cooling_register() isn't used by anyone and so can be
removed, but then we would be left with two routines:
cpufreq_cooling_register() and of_cpufreq_power_cooling_register() that
would look odd because of strange names.
Remove current implementation of of_cpufreq_cooling_register() and
rename of_cpufreq_power_cooling_register() as
of_cpufreq_cooling_register(). This simplifies lots of stuff.
Signed-off-by: Viresh Kumar
---
Documentation/thermal/cpu-cooling-api.txt | 14 ++--
drivers/cpufreq/arm_big_little.c | 2 +-
drivers/cpufreq/cpufreq-dt.c | 2 +-
drivers/cpufreq/mediatek-cpufreq.c| 2 +-
drivers/cpufreq/qoriq-cpufreq.c | 2 +-
drivers/thermal/cpu_cooling.c | 28 ++--
include/linux/cpu_cooling.h | 53 ---
7 files changed, 23 insertions(+), 80 deletions(-)
diff --git a/Documentation/thermal/cpu-cooling-api.txt
b/Documentation/thermal/cpu-cooling-api.txt
index ea61e8bf7e2b..7a1c89db0419 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -26,24 +26,16 @@ the user. The registration APIs returns the cooling device
pointer.
clip_cpus: cpumask of cpus where the frequency constraints will happen.
1.1.2 struct thermal_cooling_device *of_cpufreq_cooling_register(
- struct device_node *np, const struct cpumask *clip_cpus)
+ struct cpufreq_policy *policy)
This interface function registers the cpufreq cooling device with
the name "thermal-cpufreq-%x" linking it with a device tree node, in
order to bind it via the thermal DT code. This api can support multiple
instances of cpufreq cooling devices.
-np: pointer to the cooling device device tree node
-clip_cpus: cpumask of cpus where the frequency constraints will happen.
-
-1.1.3 struct thermal_cooling_device *of_cpufreq_power_cooling_register(
- struct cpufreq_policy *policy)
-
-Similar to cpufreq_cooling_register, this function register a
-cpufreq cooling device with power extensions using the device tree
-information supplied by the np parameter.
+policy: CPUFreq policy.
-1.1.4 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+1.1.3 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
This interface function unregisters the "thermal-cpufreq-%x" cooling
device.
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 3d5ed4ef3927..c56b57dcfda5 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -532,7 +532,7 @@ static void bL_cpufreq_ready(struct cpufreq_policy *policy)
if (cur_cluster >= MAX_CLUSTERS)
return;
- cdev[cur_cluster] = of_cpufreq_power_cooling_register(policy);
+ cdev[cur_cluster] = of_cpufreq_cooling_register(policy);
}
static struct cpufreq_driver bL_cpufreq_driver = {
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 1e7bec7694ab..de3d104c25d7 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -320,7 +320,7 @@ static void cpufreq_ready(struct cpufreq_policy *policy)
{
struct private_data *priv = policy->driver_data;
- priv->cdev = of_cpufreq_power_cooling_register(policy);
+ priv->cdev = of_cpufreq_cooling_register(policy);
}
static struct cpufreq_driver dt_cpufreq_driver = {
diff --git a/drivers/cpufreq/mediatek-cpufreq.c
b/drivers/cpufreq/mediatek-cpufreq.c
index dd0bc783cb8b..1aa79486a033 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -311,7 +311,7 @@ static void mtk_cpufreq_ready(struct cpufreq_policy *policy)
{
struct mtk_cpu_dvfs_info *info = policy->driver_data;
- info->cdev = of_cpufreq_power_cooling_register(policy);
+ info->cdev = of_cpufreq_cooling_register(policy);
}
static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 3a665c18e14e..0562761a3dec 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -276,7 +276,7 @@ static void qoriq_cpufreq_ready(struct cpufreq_policy
*policy)
{
struct cpu_data *cpud = policy->driver_data;
- cpud->cdev = of_cpufreq_power_cooling_register(policy);
+ cpud->cdev = of_cpufreq_cooling_register(policy);
}
static struct cpufreq_driver qoriq_cpufreq_driver = {
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 94ffb4463e22..55d6b9fb909d 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -819,7 +819,6 @@ EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
/**
* of_cpufreq_cooling_register - function to create cpufreq cooling device.
- * @np: a valid struct device_node to the c
[PATCH 2/4] cpu_cooling: Remove unused cpufreq_power_cooling_register()
It isn't used by anyone, drop it.
Signed-off-by: Viresh Kumar
---
Documentation/thermal/cpu-cooling-api.txt | 24 +++-
drivers/thermal/cpu_cooling.c | 30 --
include/linux/cpu_cooling.h | 10 --
3 files changed, 3 insertions(+), 61 deletions(-)
diff --git a/Documentation/thermal/cpu-cooling-api.txt
b/Documentation/thermal/cpu-cooling-api.txt
index 4f6f5e9bb4d6..ea61e8bf7e2b 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -36,28 +36,14 @@ the user. The registration APIs returns the cooling device
pointer.
np: pointer to the cooling device device tree node
clip_cpus: cpumask of cpus where the frequency constraints will happen.
-1.1.3 struct thermal_cooling_device *cpufreq_power_cooling_register(
-const struct cpumask *clip_cpus, u32 capacitance,
-get_static_t plat_static_func)
-
-Similar to cpufreq_cooling_register, this function registers a cpufreq
-cooling device. Using this function, the cooling device will
-implement the power extensions by using a simple cpu power model. The
-cpus must have registered their OPPs using the OPP library.
-
-The additional parameters are needed for the power model (See 2. Power
-models). "capacitance" is the dynamic power coefficient (See 2.1
-Dynamic power). "plat_static_func" is a function to calculate the
-static power consumed by these cpus (See 2.2 Static power).
-
-1.1.4 struct thermal_cooling_device *of_cpufreq_power_cooling_register(
+1.1.3 struct thermal_cooling_device *of_cpufreq_power_cooling_register(
struct cpufreq_policy *policy)
-Similar to cpufreq_power_cooling_register, this function register a
+Similar to cpufreq_cooling_register, this function register a
cpufreq cooling device with power extensions using the device tree
information supplied by the np parameter.
-1.1.5 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
+1.1.4 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
This interface function unregisters the "thermal-cpufreq-%x" cooling
device.
@@ -74,10 +60,6 @@ cpu. If you are using CONFIG_CPUFREQ_DT then the
`cpufreq_frequency_table` should already be assigned to the cpu
device.
-The `plat_static_func` parameter of `cpufreq_power_cooling_register()`
-is optional. If you don't provide it, only dynamic power will be
-considered.
-
2.1 Dynamic power
The dynamic power consumption of a processor depends on many factors.
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 5740b49fee68..94ffb4463e22 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -841,36 +841,6 @@ of_cpufreq_cooling_register(struct device_node *np,
}
EXPORT_SYMBOL_GPL(of_cpufreq_cooling_register);
-/**
- * cpufreq_power_cooling_register() - create cpufreq cooling device with power
extensions
- * @policy:cpufreq policy
- * @capacitance: dynamic power coefficient for these cpus
- * @plat_static_func: function to calculate the static power consumed by these
- * cpus (optional)
- *
- * This interface function registers the cpufreq cooling device with
- * the name "thermal-cpufreq-%x". This api can support multiple
- * instances of cpufreq cooling devices. Using this function, the
- * cooling device will implement the power extensions by using a
- * simple cpu power model. The cpus must have registered their OPPs
- * using the OPP library.
- *
- * An optional @plat_static_func may be provided to calculate the
- * static power consumed by these cpus. If the platform's static
- * power consumption is unknown or negligible, make it NULL.
- *
- * Return: a valid struct thermal_cooling_device pointer on success,
- * on failure, it returns a corresponding ERR_PTR().
- */
-struct thermal_cooling_device *
-cpufreq_power_cooling_register(struct cpufreq_policy *policy, u32 capacitance,
- get_static_t plat_static_func)
-{
- return __cpufreq_cooling_register(NULL, policy, capacitance,
- plat_static_func);
-}
-EXPORT_SYMBOL(cpufreq_power_cooling_register);
-
/**
* of_cpufreq_power_cooling_register() - create cpufreq cooling device with
power extensions
* @policy: CPUFreq policy.
diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
index f09d4feb34f4..c35778960a9c 100644
--- a/include/linux/cpu_cooling.h
+++ b/include/linux/cpu_cooling.h
@@ -41,10 +41,6 @@ typedef int (*get_static_t)(cpumask_t *cpumask, int interval,
struct thermal_cooling_device *
cpufreq_cooling_register(struct cpufreq_policy *policy);
-struct thermal_cooling_device *
-cpufreq_power_cooling_register(struct cpufreq_policy *policy,
- u32 capacitance, get_static_t plat_static_func);
-
/**
* of_cpufreq_cooling_register - create cpufreq coolin
[PATCH 1/4] cpu_cooling: Make of_cpufreq_power_cooling_register() parse DT
All the callers of of_cpufreq_power_cooling_register() have almost
identical code and it makes more sense to move that code into the helper
as its all about reading DT properties.
This got rid of lot of redundant code.
Signed-off-by: Viresh Kumar
---
Documentation/thermal/cpu-cooling-api.txt | 7 ++---
drivers/cpufreq/arm_big_little.c | 23 +--
drivers/cpufreq/cpufreq-dt.c | 27 +
drivers/cpufreq/mediatek-cpufreq.c| 22 +-
drivers/cpufreq/qoriq-cpufreq.c | 14 +
drivers/thermal/cpu_cooling.c | 49 +++
include/linux/cpu_cooling.h | 15 ++
7 files changed, 41 insertions(+), 116 deletions(-)
diff --git a/Documentation/thermal/cpu-cooling-api.txt
b/Documentation/thermal/cpu-cooling-api.txt
index 71653584cd03..4f6f5e9bb4d6 100644
--- a/Documentation/thermal/cpu-cooling-api.txt
+++ b/Documentation/thermal/cpu-cooling-api.txt
@@ -51,8 +51,7 @@ Dynamic power). "plat_static_func" is a function to
calculate the
static power consumed by these cpus (See 2.2 Static power).
1.1.4 struct thermal_cooling_device *of_cpufreq_power_cooling_register(
-struct device_node *np, const struct cpumask *clip_cpus, u32 capacitance,
-get_static_t plat_static_func)
+ struct cpufreq_policy *policy)
Similar to cpufreq_power_cooling_register, this function register a
cpufreq cooling device with power extensions using the device tree
@@ -76,8 +75,8 @@ cpu. If you are using CONFIG_CPUFREQ_DT then the
device.
The `plat_static_func` parameter of `cpufreq_power_cooling_register()`
-and `of_cpufreq_power_cooling_register()` is optional. If you don't
-provide it, only dynamic power will be considered.
+is optional. If you don't provide it, only dynamic power will be
+considered.
2.1 Dynamic power
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index 65ec5f01aa8d..3d5ed4ef3927 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -526,34 +526,13 @@ static int bL_cpufreq_exit(struct cpufreq_policy *policy)
static void bL_cpufreq_ready(struct cpufreq_policy *policy)
{
- struct device *cpu_dev = get_cpu_device(policy->cpu);
int cur_cluster = cpu_to_cluster(policy->cpu);
- struct device_node *np;
/* Do not register a cpu_cooling device if we are in IKS mode */
if (cur_cluster >= MAX_CLUSTERS)
return;
- np = of_node_get(cpu_dev->of_node);
- if (WARN_ON(!np))
- return;
-
- if (of_find_property(np, "#cooling-cells", NULL)) {
- u32 power_coefficient = 0;
-
- of_property_read_u32(np, "dynamic-power-coefficient",
-&power_coefficient);
-
- cdev[cur_cluster] = of_cpufreq_power_cooling_register(np,
- policy, power_coefficient, NULL);
- if (IS_ERR(cdev[cur_cluster])) {
- dev_err(cpu_dev,
- "running cpufreq without cooling device: %ld\n",
- PTR_ERR(cdev[cur_cluster]));
- cdev[cur_cluster] = NULL;
- }
- }
- of_node_put(np);
+ cdev[cur_cluster] = of_cpufreq_power_cooling_register(policy);
}
static struct cpufreq_driver bL_cpufreq_driver = {
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 545946ad0752..1e7bec7694ab 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -319,33 +319,8 @@ static int cpufreq_exit(struct cpufreq_policy *policy)
static void cpufreq_ready(struct cpufreq_policy *policy)
{
struct private_data *priv = policy->driver_data;
- struct device_node *np = of_node_get(priv->cpu_dev->of_node);
- if (WARN_ON(!np))
- return;
-
- /*
-* For now, just loading the cooling device;
-* thermal DT code takes care of matching them.
-*/
- if (of_find_property(np, "#cooling-cells", NULL)) {
- u32 power_coefficient = 0;
-
- of_property_read_u32(np, "dynamic-power-coefficient",
-&power_coefficient);
-
- priv->cdev = of_cpufreq_power_cooling_register(np,
- policy, power_coefficient, NULL);
- if (IS_ERR(priv->cdev)) {
- dev_err(priv->cpu_dev,
- "running cpufreq without cooling device: %ld\n",
- PTR_ERR(priv->cdev));
-
- priv->cdev = NULL;
- }
- }
-
- of_node_put(np);
+ priv->cdev = of_cpufreq_power_cooling_register(policy);
}
static struct cpufreq_driver dt_cpufreq_driver = {
diff --git a/drivers/cpufreq/mediatek-cpufreq.c
b/drivers/cpufreq/media
Re: [PATCH v2] sched/deadline: fix runtime accounting in documentation
On Tue, Nov 14, 2017 at 12:19:26PM +0100, Claudio Scordino wrote:
> Signed-off-by: Claudio Scordino
> Signed-off-by: Luca Abeni
> Acked-by: Daniel Bristot de Oliveira
> CC: Jonathan Corbet
> CC: "Peter Zijlstra (Intel)"
> CC: Ingo Molnar
> CC: linux-doc@vger.kernel.org
> Cc: Tommaso Cucinotta
> Cc: Mathieu Poirier
ACK, Ingo can you route this?
> ---
> Documentation/scheduler/sched-deadline.txt | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/scheduler/sched-deadline.txt
> b/Documentation/scheduler/sched-deadline.txt
> index e89e36e..8ce78f8 100644
> --- a/Documentation/scheduler/sched-deadline.txt
> +++ b/Documentation/scheduler/sched-deadline.txt
> @@ -204,10 +204,17 @@ CONTENTS
> It does so by decrementing the runtime of the executing task Ti at a pace
> equal
> to
>
> - dq = -max{ Ui, (1 - Uinact) } dt
> + dq = -max{ Ui / Umax, (1 - Uinact - Uextra) } dt
>
> - where Uinact is the inactive utilization, computed as (this_bq -
> running_bw),
> - and Ui is the bandwidth of task Ti.
> + where:
> +
> + - Ui is the bandwidth of task Ti;
> + - Umax is the maximum reclaimable utilization (subjected to RT throttling
> +limits);
> + - Uinact is the (per runqueue) inactive utilization, computed as
> +(this_bq - running_bw);
> + - Uextra is the (per runqueue) extra reclaimable utilization
> +(subjected to RT throttling limits).
>
>
> Let's now see a trivial example of two deadline tasks with runtime equal
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull
Linus Torvalds writes: > On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding wrote: >> >> Linus do you care what protocol? I'm patching Documentation and since >> the point is creating pull requests for you 'some people' don't matter. > > I actually tend to prefer the regular git:// protocol and signed tags. > > It's true that https should have the proper certificate and perhaps > help with DNS spoofing, but I'm not convinced that git won't just > accept self-signed random certs, and I basically don't think we should > trust that. git does not accept self-signed certs by default, at least in recent versions. Though you can do a trust-on-first-use type thing, by downloading the cert and telling git where to find it. So https does provide additional security vs git:// IMHO. There is some verification of the server and your data is encrypted on the wire. It's not like it would be trivial to MITM a git fetch to insert a malicious Makefile change, but it's also not *hard*. > In contrast, using ssh I would actually trust, but it's not convenient > and involves people sending things that aren't necessarily publicly > available. > > So instead, I prefer just using git:// and not trying to fool people > into thinking the protocol is secure - the security should come from > the signed tag. That's true, but only when you're pulling a signed tag, which for most people is not the common case. ... > That said, I actually would prefer even kernel.org repositories to > just send pull requests with signed tags, despite the protocol itself > being secure for that (and only that). Which you mention here. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/7] Support RAS virtualization in KVM
Hi James,
Thank you very much for your comments and review.
On 2017/11/15 0:00, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 10/11/17 19:54, Dongjiu Geng wrote:
>> This series patches mainly do below things:
>>
>> 1. Trap RAS ERR* registers Accesses to EL2 from Non-secure EL1,
>>KVM will will do a minimum simulation, there registers are simulated
>>to RAZ/WI in KVM.
>> 2. Route synchronous External Abort exceptions from Non-secure EL0
>>and EL1 to EL2. When exception EL3 routing is enabled by firmware,
>>system will trap to EL3 firmware instead of EL2 KVM, then firmware
>>judges whether El2 routing is enabled, if enabled, jump to EL2 KVM,
>>otherwise jump to EL1 host kernel.
>> 3. Enable APEI ARv8 SEI notification to parse the CPER records for SError
>>in the ACPI GHES driver, KVM will call handle_guest_sei() to let ACPI
>>driver to parse the CPER record for SError which happened in the guest
>> 4. Although we can use APEI driver to handle the guest SError, but not all
>>system support SEI notification, such as kernel-first. So here KVM will
>>also classify the Error through Exception Syndrome Register and do
>> different
>>approaches according to Asynchronous Error Type
>
>> 5. If the guest SError error is not propagated and not consumed, then KVM
>> return
>>recoverable error status to user-space, user-space will specify the guest
>> ESR
>
> I thought we'd gone over this. There should be no RAS errors/notifications in
> user space. Only the symptoms should be sent, using the SIGBUS_MCEERR_A{O,R}
> if
> the kernel has handled as much as it can. This hides the actual mechanisms the
> kernel and firmware used.
Yes, I understand it.
For guest SError, if it is not propagated and not consumed by PE, and the
error address recorded by firmware is not accurate,
what is your suggestion about this scenario ?
I check again the comments in [0](as shown below), you ever suggest system
panic.
-
"I think in this scenario your firmware should describe a memory-error with an
unknown address. (i.e. don't set the 'physical address valid' bit in CPER's
'Table 275 Memory Error Record'). When Linux gets one of these, it should
panic(): We know some memory is corrupt, we don't know where it is"
but I think it is not better, you ever have below concern in [0]
"The fault may be in the page tables belonging to the guest kernel,
even worse they may belong to they hypervisor's stage2 page tables"
If it is in the page tables, killing the APP, the memory will be free. if there
is another application
will use this error address again, trigger another SError?
you know the error still not consumed by PE , so we can isolated it by killing
it.
lets discuses the host EL0, if host El0 APP happen SError and error not
consumed by the PE.
do you mean we also panic host OS?
>
> User-space should not have to know how to handle RAS errors directly. This is
> a
> service the operating system provides for it. This abstraction means the smae
> user-space code is portable between x86, arm64, powerpc etc.
>
> What if the firmware uses another notification method? User space should
> expect
> the kernel to hide things like this from it.
>
> If the kernel has no information to interpret a notification, how is user
> space
> supposed to know?
>
> I understand you are trying to work around your 'memory corruption at an
> unknown
> address'[0] problem, but if the kernel can't know where this corrupt memory is
> it should really reboot. What stops this corrupt data being swapped to disk?
>
> Killing 'the thing' that was running at the time is not sufficient because we
> don't know that this 'got' all the users of the corrupt memory. KSM can merge
I think if we better using the ESB to isolate the error between EL0 and EL1,
isolate the error between different guest.
then the error will be isolate to El0 application if it happen in El0. When KSM
running, the ESB can synchronize
the error out instead of spread the error to other guests.
> pages between guests. This is the difference between the error persisting
> forever killing off all the VMs one by one, and the corrupt page being
> silently
> re-read from disk clearing the error.
>
>
>>and inject a virtual SError. For other Asynchronous Error Type, KVM
>> directly
>>injects virtual SError with IMPLEMENTATION DEFINED ESR or KVM is panic if
>> the
>>error is fatal. In the RAS extension, guest virtual ESR must be set,
>> because
>>all-zero means 'RAS error: Uncategorized' instead of 'no valid ISS', so
>> set
>>this ESR to IMPLEMENTATION DEFINED by default if user space does not
>> specify it.
>
>
> Thanks,
>
> James
>
>
> [0] https://www.spinics.net/lists/arm-kernel/msg605345.html
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" i
Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
Hi James,
Thanks a lot for the review.
On 2017/11/15 0:00, James Morse wrote:
> Hi Dongjiu Geng,
>
> On 10/11/17 19:54, Dongjiu Geng wrote:
>> If it is not RAS SError, directly inject virtual SError,
>> which will keep the old way. If it is RAS SError, firstly
>> let host ACPI module to handle it.
>
>> For the ACPI handling,
>> if the error address is invalid, APEI driver will not
>> identify the address to hwpoison memory and can not notify
>> guest to do the recovery.
>
> The guest can't do any recover either. There is no recovery you can do without
> some information about what the error is.
>
> This is your memory corruption at an unknown address? We should reboot.
>
> (I agree memory_failure.c's::me_kernel() is ignoring kernel errors, we should
> try and fix this. It makes some sense for polled or irq notifications, but not
> SEA/SEI).
>
>
>> In order to safe, KVM continues
>> categorizing errors and handle it separately.
>
>> If the RAS error is not propagated, let host user space to
>> handle it.
>
> No. Host user space should not know anything about the kernel or platform RAS
> support. Doing so creates an ABI link between EL3 firmware and Qemu. This is
> totally unmaintainable.
Here I have two question:
(1) If the AET(Asynchronous Error Type) is Recoverable error (UER), do you mean
we also reboot or panic?
(2) what is the chance to set guest ESR for Qemu? here I return a error code
to Qemu. when Qemu get this error return,
it will specify guest ESR and inject the abort. here if KVM does not return
error to Qemu, Qemu will do
not know when to set the guest ESR value and inject abort.
>
> This thing needs to be portable. The kernel should handle the error, and
> report
> any symptoms to user-space. e.g. 'this memory is gone'.
>
> We shouldn't special case KVM.
>
>
>> The reason is that sometimes we can only kill the
>> guest effected application instead of panic whose guest OS.
>> Host user space specifies a valid ESR and inject virtual
>> SError, guest can just kill the current application if the
>> non-consumed error coming from guest application.
>>
>> Signed-off-by: Dongjiu Geng
>> Signed-off-by: Quanming Wu
>
> The last Signed-off-by should match the person posting the patch. It's a chain
> of custody for GPL-signoff purposes, not a 'partially-written-by'. If you want
> to credit Quanming Wu you can add CC and they can Ack/Review your patch.
Ok, got it. thanks a lot for your suggestion.
>
>
>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
>> index 7debb74..1afdc87 100644
>> --- a/arch/arm64/kvm/handle_exit.c
>> +++ b/arch/arm64/kvm/handle_exit.c
>> @@ -178,6 +179,66 @@ static exit_handle_fn kvm_get_exit_handler(struct
>> kvm_vcpu *vcpu)
>> return arm_exit_handlers[hsr_ec];
>> }
>>
>> +/**
>> + * kvm_handle_guest_sei - handles SError interrupt or asynchronous aborts
>> + * @vcpu: the VCPU pointer
>> + *
>> + * For RAS SError interrupt, firstly let host kernel handle it.
>> + * If the AET is [ESR_ELx_AET_UER], then let user space handle it,
>> + */
>> +static int kvm_handle_guest_sei(struct kvm_vcpu *vcpu, struct kvm_run *run)
>> +{
>> +unsigned int esr = kvm_vcpu_get_hsr(vcpu);
>> +bool impdef_syndrome = esr & ESR_ELx_ISV; /* aka IDS */
>> +unsigned int aet = esr & ESR_ELx_AET;
>> +
>> +/*
>> + * This is not RAS SError
>> + */
>> +if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) {
>> +kvm_inject_vabt(vcpu);
>> +return 1;
>> +}
>
>> +/* The host kernel may handle this abort. */
>> +handle_guest_sei();
>
> This has to claim the SError as a notification. If APEI claims the error, KVM
> doesn't need to do anything more. You ignore its return code.
Thanks for the pointing out.
I will check the return code, if it return success, KVM doesn't need to do
anything more,
otherwise, continue run.
>
>
>> +
>> +/*
>> + * In below two conditions, it will directly inject the
>> + * virtual SError:
>> + * 1. The Syndrome is IMPLEMENTATION DEFINED
>> + * 2. It is Uncategorized SEI
>> + */
>> +if (impdef_syndrome ||
>> +((esr & ESR_ELx_FSC) != ESR_ELx_FSC_SERROR)) {
>> +kvm_inject_vabt(vcpu);
>> +return 1;
>> +}
>> +
>> +switch (aet) {
>> +case ESR_ELx_AET_CE:/* corrected error */
>> +case ESR_ELx_AET_UEO: /* restartable error, not yet consumed */
>> +return 1; /* continue processing the guest exit */
>
>> +case ESR_ELx_AET_UER: /* The error has not been propagated */
>> +/*
>> + * Userspace only handle the guest SError Interrupt(SEI) if the
>> + * error has not been propagated
>> + */
>> +run->exit_reason = KVM_EXIT_EXCEPTION;
>> +run->ex.exception = ESR_ELx_EC_SERROR;
>> +run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>> +return 0;
>
> We should not pass RA
Hello Dear...
Hello Dear... I know that this message will come to you as a surprise. I hoped that you will not expose or betray this trust and confident that I am about to repose on you, my name is M, Shakour Rosarita. I am 19 years old Girl, female, from Tartu Syria, (never married) 61 kg, white in complexion, and I am currently living in the refugee camp here in Abidjan Ivory Coast, My late beloved father M,Shakour Hassin was a renowned businessman and owner of Natour Petrol Station in Syria, he was killed in a stampede riot in Tartu, Syria. When I got the news about my parents. I fled to a nearby country Jordan before I joined a ferry to Africa and came to Abidjan capital city Ivory Coast West Africa find safety here. I came in 2015 to Abidjan and I now live in refugee camps here as refugees are allowed freely to enter here without, My late father deposited (US$6.200.000.00m) My late father kept the money at the bank of Africa, I want you to help me transfer the money to your hand so that you will help me bring me into your country for my continue education. I sent my pictures here for you to see. Who I am seriously looking for a good-person in my life, so I want to hear from you soon and learn more about you. I am an open-minded and friendly girl to share a good time with you and have fun and enjoy on the go, bird watching, the rest of our lives. My Hobbies, tourism books, dance, music, soccer, tennis, swimming and cinema. I would just think about you, including your dose and doesn’t .I believe we will do well together, and live like one family. Thank you and God bless you, for you in your promise to help me here, looking forward to your reply by the grace of God and have a good day. I hope you send me your photos as well? I await your next reply in faith please reply through my private email at (mshakourrosarit...@gmail.com): Thanks. Ms Rosarita -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote: > From: Yang Zhang > > Implement a generic idle poll which resembles the functionality > found in arch/. Provide weak arch_cpu_idle_poll function which > can be overridden by the architecture code if needed. No, we want less of those magic hooks, not more. > Interrupts arrive which may not cause a reschedule in idle loops. > In KVM guest, this costs several VM-exit/VM-entry cycles, VM-entry > for interrupts and VM-exit immediately. Also this becomes more > expensive than bare metal. Add a generic idle poll before enter > real idle path. When a reschedule event is pending, we can bypass > the real idle path. Why not do a HV specific idle driver? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 0/6] x86/idle: add halt poll support
On Mon, Nov 13, 2017 at 07:01:40PM +0800, Quan Xu wrote: > Documentation/sysctl/kernel.txt | 35 > arch/x86/include/asm/paravirt.h |5 ++ > arch/x86/include/asm/paravirt_types.h |6 +++ > arch/x86/kernel/kvm.c | 73 > + > arch/x86/kernel/paravirt.c| 10 + > arch/x86/kernel/process.c |7 +++ > include/linux/kernel.h|6 +++ > include/linux/tick.h |2 + > kernel/sched/idle.c |2 + > kernel/sysctl.c | 34 +++ > kernel/time/tick-sched.c | 11 + > kernel/time/tick-sched.h |3 + > 12 files changed, 194 insertions(+), 0 deletions(-) You seem to have forgotten to CC me on the actual patches, but no. Not going to happen. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: add submitting-pull-requests.rst
On Wed, 15 Nov 2017, "Tobin C. Harding" wrote: > On Tue, Nov 14, 2017 at 04:48:16PM -0700, Jonathan Corbet wrote: > > Awesome comments Jon, I knew there would be more to writing docs than > first met the eye. > >> On Wed, 15 Nov 2017 09:54:21 +1100 >> "Tobin C. Harding" wrote: >> >> > There is currently no documentation on how to create a pull request for >> > Linus. >> > >> > Anyway, this actually came up at the kernel summit / maintainer >> > meeting a few weeks ago, in that "how do I make a good pull request >> > to Linus" is something we need to document. >> > >> > Here's what I do, and it seems to work well, so maybe we should turn >> > it into the start of the documentation for how to do it. >> > >> > Create document from email thread on LKML (referenced in document). >> > >> > Signed-off-by: Tobin C. Harding >> > --- >> > >> > Is it rude to send this during the merge window? Can resend after it >> > closes if >> > it makes life easier. >> >> I can handle patches during the merge window. That said, while I welcome >> this effort and think it's a good start, there's a few things I'll >> quibble about: >> >> - Much of this was actually written by Greg, I believe, and some by Linus. >>That deserves credit in the changelog, if nowhere else. > > Yeah, I struggled for ages with the tense, Greg's stuff is obviously > written as him. But I didn't want to paraphrase and present it as if I'd > written it. After your comments I'm still unsure of the _best_ way to > present this material with a good flow but still giving credit where > credit is due? I didn't seem right to add their names to the document > (thereby presenting myself as them). I did not think of the changelog - > I'll go that path for v2. > >> - Putting it in Documentation/process as RST is good. But it should be >>added to index.rst and made part of the docs build. I suspect you >>haven't run it through sphinx at all yet, right? Some things are >>unlikely to format the way you think they might. > > My bad, I knew I would botch some of the RST stuff, didn't think to run > it through sphinx (I tend to view kernel docs as the raw files ;) > >> Finally, I see this as being the first installment in what, I hope, will >> someday be a nice "how to be a kernel maintainer" manual. I wouldn't >> insist on it before taking a patch like this, but if you could see >> through to organizing it as a chapter in a bigger sub-book, that would be >> great. > > Happy to do so. I'm no way qualified to produce much of the text but > perhaps can assist in getting things moving. > >> Finally finally... Dan Williams [CC'd] has plans for doing some >> maintainer-level documentation. He may have thoughts on how this fits >> into what he's scheming, and I'd suggest copying him on the next >> iteration. > > Let's liaise on this Dan (if you want to). > >> Finally finally finally...some specific comments on the text. Some of >> them might be read to suggest a major expansion of the work you've done; >> please see that as me saying "that would be nice". Doing all of this is >> not a precondition to getting this document added! > > There is no rush to get merged, let's get it into shape first :) > >> > +Submitting Pull Requests to Linus: a guide for maintainers >> > +== >> > + >> > +This document is aimed at kernel maintainers. It describes a method for >> > creating >> > +a pull request to be sent to Linus. >> >> Limiting text widths to, say, 75 columns when possible is preferable. Word >> has it some maintainers are still reading the docs on their adm3a >> terminals. > > Got it. (idea for next doc 'column widths howto' - your canonical guide > to column widths (includes git brief, commit log, email, source code, > and docs). > > I'm kidding. 75 it is. > >> Most maintainers push directly to Linus, so that's an obvious best focus, >> but pull requests happen at other levels too. One would hope that this >> information would be applicable at all levels, so it might be nice to >> describe it as such. > > Oh, Greg had this, I stripped it out. Back in on next spin. > >> > +Configure Git >> > +- >> >> "Configure Git to use your private key" >> >> We are, of course, missing the whole discussion on why one would want a >> keypair, how to create it, how to get it into the web of trust, etc. All >> fodder for a separate chapter in our shiny new maintainer book :) But it >> is worth saying at least that this is about making Git use your key so you >> can sign tags for pull requests. > > Funny you should say that, I'm trying to get into the web of trust so > perhaps I can help with that document (as I work out how to do it). > >> > +Since you _usually_ would use the same key for the same project, just set >> > it >> > +once with >> >> If you end a line like that with "::", the following indented section will >> be formatted as code by sphinx. That's almo
Re: [PATCH v3 4/6] PM / core: Add helpers for subsystem callback selection
On Wed, Nov 15, 2017 at 8:43 AM, Ulf Hansson wrote: > On 12 November 2017 at 01:42, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> Add helper routines to find and return a suitable subsystem callback >> during the "noirq" phases of system suspend/resume (or analogous) >> transitions as well as during the "late" phase of system suspend and >> the "early" phase of system resume (or analogous) transitions. >> >> The helpers will be called from additional sites going forward. >> >> Signed-off-by: Rafael J. Wysocki > > With a minor nitpick, see below, feel free to add: > > Reviewed-by: Ulf Hansson > >> --- >> >> v2 -> v3: No changes. >> >> --- >> drivers/base/power/main.c | 196 >> +++--- >> 1 file changed, 136 insertions(+), 60 deletions(-) >> >> Index: linux-pm/drivers/base/power/main.c >> === >> --- linux-pm.orig/drivers/base/power/main.c >> +++ linux-pm/drivers/base/power/main.c >> @@ -525,6 +525,14 @@ static void dpm_watchdog_clear(struct dp >> #define dpm_watchdog_clear(x) >> #endif >> >> +static pm_callback_t dpm_subsys_suspend_noirq_cb(struct device *dev, >> +pm_message_t state, >> +const char **info_p); >> + >> +static pm_callback_t dpm_subsys_suspend_late_cb(struct device *dev, >> + pm_message_t state, >> + const char **info_p); >> + > > There is no need to declare these functions. > > Perhaps a following patch in the series need them, but then that > change should add these or even better (in my opinion) just move the > implementations and avoid the declarations all together. Well, all of the changes in this patch are for the benefit of the subsequent patches. :-) I just wanted to move additional code churn noise from those patches. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Xen-devel] [PATCH RFC v3 0/6] x86/idle: add halt poll support
On Mon, Nov 13, 2017 at 06:05:59PM +0800, Quan Xu wrote: > From: Yang Zhang > > Some latency-intensive workload have seen obviously performance > drop when running inside VM. The main reason is that the overhead > is amplified when running inside VM. The most cost I have seen is > inside idle path. Meaning an VMEXIT b/c it is an 'halt' operation ? And then going back in guest (VMRESUME) takes time. And hence your latency gets all whacked b/c of this? So if I understand - you want to use your _full_ timeslice (of the guest) without ever (or as much as possible) to go in the hypervisor? Which means in effect you don't care about power-saving or CPUfreq savings, you just want to eat the full CPU for snack? > > This patch introduces a new mechanism to poll for a while before > entering idle state. If schedule is needed during poll, then we > don't need to goes through the heavy overhead path. Schedule of what? The guest or the host? -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
On Wed, 15 Nov 2017, Peter Zijlstra wrote:
> On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote:
> > From: Yang Zhang
> >
> > Implement a generic idle poll which resembles the functionality
> > found in arch/. Provide weak arch_cpu_idle_poll function which
> > can be overridden by the architecture code if needed.
>
> No, we want less of those magic hooks, not more.
>
> > Interrupts arrive which may not cause a reschedule in idle loops.
> > In KVM guest, this costs several VM-exit/VM-entry cycles, VM-entry
> > for interrupts and VM-exit immediately. Also this becomes more
> > expensive than bare metal. Add a generic idle poll before enter
> > real idle path. When a reschedule event is pending, we can bypass
> > the real idle path.
>
> Why not do a HV specific idle driver?
If I understand the problem correctly then he wants to avoid the heavy
lifting in tick_nohz_idle_enter() in the first place, but there is already
an interesting quirk there which makes it exit early. See commit
3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this commit
looks similar. But lets not proliferate that. I'd rather see that go away.
But the irq_timings stuff is heading into the same direction, with a more
complex prediction logic which should tell you pretty good how long that
idle period is going to be and in case of an interrupt heavy workload this
would skip the extra work of stopping and restarting the tick and provide a
very good input into a polling decision.
This can be handled either in a HV specific idle driver or even in the
generic core code. If the interrupt does not arrive then you can assume
within the predicted time then you can assume that the flood stopped and
invoke halt or whatever.
That avoids all of that 'tunable and tweakable' x86 specific hackery and
utilizes common functionality which is mostly there already.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v10 00/10] Application Data Integrity feature introduced by SPARC M7
SPARC M7 processor adds additional metadata for memory address space that can be used to secure access to regions of memory. This additional metadata is implemented as a 4-bit tag attached to each cacheline size block of memory. A task can set a tag on any number of such blocks. Access to such block is granted only if the virtual address used to access that block of memory has the tag encoded in the uppermost 4 bits of VA. Since sparc processor does not implement all 64 bits of VA, top 4 bits are available for ADI tags. Any mismatch between tag encoded in VA and tag set on the memory block results in a trap. Tags are verified in the VA presented to the MMU and tags are associated with the physical page VA maps on to. If a memory page is swapped out and page frame gets reused for another task, the tags are lost and hence must be saved when swapping or migrating the page. A userspace task enables ADI through mprotect(). This patch series adds a page protection bit PROT_ADI and a corresponding VMA flag VM_SPARC_ADI. VM_SPARC_ADI is used to trigger setting TTE.mcd bit in the sparc pte that enables ADI checking on the corresponding page. MMU validates the tag embedded in VA for every page that has TTE.mcd bit set in its pte. After enabling ADI on a memory range, the userspace task can set ADI version tags using stxa instruction with ASI_MCD_PRIMARY or ASI_MCD_ST_BLKINIT_PRIMARY ASI. Once userspace task calls mprotect() with PROT_ADI, kernel takes following overall steps: 1. Find the VMAs covering the address range passed in to mprotect and set VM_SPARC_ADI flag. If address range covers a subset of a VMA, the VMA will be split. 2. When a page is allocated for a VA and the VMA covering this VA has VM_SPARC_ADI flag set, set the TTE.mcd bit so MMU will check the vwersion tag. 3. Userspace can now set version tags on the memory it has enabled ADI on. Userspace accesses ADI enabled memory using a virtual address that has the version tag embedded in the high bits. MMU validates this version tag against the actual tag set on the memory. If tag matches, MMU performs the VA->PA translation and access is granted. If there is a mismatch, hypervisor sends a data access exception or precise memory corruption detected exception depending upon whether precise exceptions are enabled or not (controlled by MCDPERR register). Kernel sends SIGSEGV to the task with appropriate si_code. 4. If a page is being swapped out or migrated, kernel must save any ADI tags set on the page. Kernel maintains a page worth of tag storage descriptors. Each descriptors pointsto a tag storage space and the address range it covers. If the page being swapped out or migrated has ADI enabled on it, kernel finds a tag storage descriptor that covers the address range for the page or allocates a new descriptor if none of the existing descriptors cover the address range. Kernel saves tags from the page into the tag storage space descriptor points to. 5. When the page is swapped back in or reinstantiated after migration, kernel restores the version tags on the new physical page by retrieving the original tag from tag storage pointed to by a tag storage descriptor for the virtual address range for new page. User task can disable ADI by calling mprotect() again on the memory range with PROT_ADI bit unset. Kernel clears the VM_SPARC_ADI flag in VMAs, merges adjacent VMAs if necessary, and clears TTE.mcd bit in the corresponding ptes. IOMMU does not support ADI checking. Any version tags embedded in the top bits of VA meant for IOMMU, are cleared and replaced with sign extension of the first non-version tag bit (bit 59 for SPARC M7) for IOMMU addresses. This patch series adds support for this feature in 10 patches: Patch 1/10 Tag mismatch on access by a task results in a trap from hypervisor as data access exception or a precide memory corruption detected exception. As part of handling these exceptions, kernel sends a SIGSEGV to user process with special si_code to indicate which fault occurred. This patch adds three new si_codes to differentiate between various mismatch errors. Patch 2/10 When a page is swapped or migrated, metadata associated with the page must be saved so it can be restored later. This patch adds a new function that saves/restores this metadata when updating pte upon a swap/migration. Patch 3/10 SPARC M7 processor adds new fields to control registers to support ADI feature. It also adds a new exception for precise traps on tag mismatch. This patch adds definitions for the new control register fields, new ASIs for ADI and an exception handler for the precise trap on tag mismatch. Patch 4/10 New hypervisor fault types were added by sparc M7 processor to support ADI feature. This patch adds code to handle these fault types for data access exception handler. Patch 5/10 When ADI is in use for a page and a tag mismatch occurs, processor raises "Memory corruption Detected" trap. This patch adds a
[PATCH v10 10/10] sparc64: Add support for ADI (Application Data Integrity)
ADI is a new feature supported on SPARC M7 and newer processors to allow hardware to catch rogue accesses to memory. ADI is supported for data fetches only and not instruction fetches. An app can enable ADI on its data pages, set version tags on them and use versioned addresses to access the data pages. Upper bits of the address contain the version tag. On M7 processors, upper four bits (bits 63-60) contain the version tag. If a rogue app attempts to access ADI enabled data pages, its access is blocked and processor generates an exception. Please see Documentation/sparc/adi.txt for further details. This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable MCD (Memory Corruption Detection) on selected memory ranges, enable TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI version tags on page swap out/in or migration. ADI is not enabled by default for any task. A task must explicitly enable ADI on a memory range and set version tag for ADI to be effective for the task. Signed-off-by: Khalid Aziz Cc: Khalid Aziz --- v10: - Added code to return from kernel path to set PSTATE.mcde if kernel continues execution in another thread (Suggested by Anthony Yznaga) v9: - Added code to migrate ADI tags to copy_highpage() to ensure tags get copied on page migration - Improved code to detect underflow and overflow when allocating tag storage v8: - Added note to doc about non-faulting loads not triggering ADI tag mismatch and more details on special tag values of 0x0 and 0xf, as suggested by Anthony Yznaga) - Added an IPI on mprotect(...PROT_ADI...) call to set TSTATE.MCDE on threads running on other processors and restore of TSTATE.MCDE on context switch (suggested by David Miller) - Removed restriction on enabling ADI on read-only memory (suggested by Anthony Yznaga) - Changed kzalloc() for tag storage to use GFP_NOWAIT - Added code to handle overflow and underflow when allocating tag storage, as suggested by Anthony Yznaga - Replaced sun_m7_patch_1insn_range() with sun4v_patch_1insn_range() which is functionally identical (suggested by Anthony Yznaga) - Added membar after restoring ADI tags in copy_user_highpage(), as suggested by David Miller v7: - Enhanced arch_validate_prot() to enable ADI only on writable addresses backed by physical RAM - Added support for saving/restoring ADI tags for each ADI block size address range on a page on swap in/out - Added code to copy ADI tags on COW - Updated values for auxiliary vectors to not conflict with values on other architectures to avoid conflict in glibc. glibc consolidates all auxiliary vectors into its headers and duplicate values in consolidated header are problematic - Disable same page merging on ADI enabled pages since ADI tags may not match on pages with identical data - Broke the patch up further into smaller patches v6: - Eliminated instructions to read and write PSTATE as well as MCDPER and PMCDPER on every access to userspace addresses by setting PSTATE and PMCDPER correctly upon entry into kernel. PSTATE.mcde and PMCDPER are set upon entry into kernel when running on an M7 processor. PSTATE.mcde being set only affects memory accesses that have TTE.mcd set. PMCDPER being set only affects writes to memory addresses that have TTE.mcd set. This ensures any faults caused by ADI tag mismatch on a write are exposed before kernel returns to userspace. v5: - Fixed indentation issues and instrcuctions in assembly code - Removed CONFIG_SPARC64 from mdesc.c - Changed to maintain state of MCDPER register in thread info flags as opposed to in mm context. MCDPER is a per-thread state and belongs in thread info flag as opposed to mm context which is shared across threads. Added comments to clarify this is a lazily maintained state and must be updated on context switch and copy_process() - Updated code to use the new arch_do_swap_page() and arch_unmap_one() functions v4: - Broke patch up into smaller patches v3: - Removed CONFIG_SPARC_ADI - Replaced prctl commands with mprotect - Added auxiliary vectors for ADI parameters - Enabled ADI for swappable pages v2: - Fixed a build error Documentation/sparc/adi.txt | 278 + arch/sparc/include/asm/mman.h | 84 - arch/sparc/include/asm/mmu_64.h | 17 ++ arch/sparc/include/asm/mmu_context_64.h | 50 ++ arch/sparc/include/asm/page_64.h| 6 + arch/sparc/include/asm
Re: [PATCH] docs: dev-tools: coccinelle: delete out of date wiki reference
2017-11-14 1:50 GMT+09:00 Julia Lawall : > The wiki is no longer available. > > Signed-off-by: Julia Lawall > > --- > > diff --git a/Documentation/dev-tools/coccinelle.rst > b/Documentation/dev-tools/coccinelle.rst > index 37e474f..94f41c2 100644 > --- a/Documentation/dev-tools/coccinelle.rst > +++ b/Documentation/dev-tools/coccinelle.rst > @@ -33,9 +33,6 @@ of many distributions, e.g. : > You can get the latest version released from the Coccinelle homepage at > http://coccinelle.lip6.fr/ > > -Information and tips about Coccinelle are also provided on the wiki > -pages at http://cocci.ekstranet.diku.dk/wiki/doku.php > - > Once you have it, run the following command:: > > ./configure Applied to linux-kbuild/misc. Thanks! -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Documentation: add UUID/GUID section to kernel-api
From: Randy Dunlap
Update kernel-doc notation in lib/uuid.c and then add UUID/GUID
function interfaces to kernel-api.
Signed-off-by: Randy Dunlap
---
Documentation/core-api/kernel-api.rst |6
lib/uuid.c| 34
2 files changed, 23 insertions(+), 17 deletions(-)
--- lnx-414.orig/lib/uuid.c
+++ lnx-414/lib/uuid.c
@@ -29,15 +29,14 @@ EXPORT_SYMBOL(uuid_null);
const u8 guid_index[16] = {3,2,1,0,5,4,7,6,8,9,10,11,12,13,14,15};
const u8 uuid_index[16] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
-/***
+/**
+ * generate_random_uuid - generate a random UUID
+ * @uuid: where to put the generated UUID
+ *
* Random UUID interface
*
- * Used here for a Boot ID, but can be useful for other kernel
- * drivers.
- ***/
-
-/*
- * Generate random UUID
+ * Used to create a Boot ID or a filesystem UUID/GUID, but can be
+ * useful for other kernel drivers.
*/
void generate_random_uuid(unsigned char uuid[16])
{
@@ -73,16 +72,17 @@ void uuid_gen(uuid_t *bu)
EXPORT_SYMBOL_GPL(uuid_gen);
/**
- * uuid_is_valid - checks if UUID string valid
- * @uuid: UUID string to check
- *
- * Description:
- * It checks if the UUID string is following the format:
- *----
- * where x is a hex digit.
- *
- * Return: true if input is valid UUID string.
- */
+ * uuid_is_valid - checks if UUID string valid
+ * @uuid: UUID string to check
+ *
+ * Description:
+ * It checks if the UUID string is following the format:
+ * ----
+ *
+ * where x is a hex digit.
+ *
+ * Return: true if input is valid UUID string.
+ */
bool uuid_is_valid(const char *uuid)
{
unsigned int i;
--- lnx-414.orig/Documentation/core-api/kernel-api.rst
+++ lnx-414/Documentation/core-api/kernel-api.rst
@@ -105,6 +105,12 @@ Sorting
.. kernel-doc:: lib/list_sort.c
:export:
+UUID/GUID
+-
+
+.. kernel-doc:: lib/uuid.c
+ :export:
+
Memory Management in Linux
==
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Documentation: add Sorting section to kernel-api
From: Randy Dunlap Add sort() and list_sort() to the kernel API documentation in a new "Sorting" section. Signed-off-by: Randy Dunlap --- Documentation/core-api/kernel-api.rst |9 + 1 file changed, 9 insertions(+) --- lnx-414.orig/Documentation/core-api/kernel-api.rst +++ lnx-414/Documentation/core-api/kernel-api.rst @@ -96,6 +96,15 @@ idr/ida Functions .. kernel-doc:: lib/idr.c :export: +Sorting +--- + +.. kernel-doc:: lib/sort.c + :export: + +.. kernel-doc:: lib/list_sort.c + :export: + Memory Management in Linux == -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set
Hey Radim,
On Thu, Nov 09, 2017 at 03:17:33PM +0100, Radim Krčmář wrote:
>
> This is what I'm doubting, because the patch is adding about two
> thousand cycles to every spinlock-taken path.
> Doesn't this patch yield better results?
>
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 3df743b60c80..d9225e48c11a 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -676,6 +676,12 @@ void __init kvm_spinlock_init(void)
> {
> if (!kvm_para_available())
> return;
> +
> + if (kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED)) {
> + static_branch_disable(&virt_spin_lock_key);
> + return;
> + }
> +
Yes, the above suggestion is a much better approach. The code has probably
changed from the time I wrote the first version. I will refresh with the above
suggestion.
> /* Does host kernel support KVM_FEATURE_PV_UNHALT? */
> if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT))
> return;
>
> > However, the
> > key aspect
> > here is this patch gives a way for the host to instruct the guest to use
> > qspinlock.
> > Even with Longman's patch which allows guest to select the spinlock
> > implementation,
> > there should still be the auto-select mode. In such mode, PV_DEDICATED
> > should
> > allow the host to get the guest to use qspinlock, without, the guest will
> > fallback
> > to tas when PV_UNHALT == 0.
>
> I agree that a flag can be useful for certains setups.
Cool!
>
--
All the best,
Eduardo Valentin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
