Re: [PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

[gengdongjiu]

Hi Christoffer,
  thanks for the review.


On 2017/7/3 16:39, Christoffer Dall wrote:
> Hi Dongjiu,
> 
> On Mon, Jun 26, 2017 at 08:46:39PM +0800, Dongjiu Geng wrote:
>> when SError happen, kvm notifies user space to record the CPER,
>> user space specifies and passes the contents of ESR_EL1 on taking
>> a virtual SError interrupt to KVM, KVM enables virtual system
>> error or asynchronous abort with this specifies syndrome. This
>> patch modify the world-switch to restore VSESR_EL2, VSESR_EL2
>> saves the virtual SError syndrome, it becomes the ESR_EL1 value when
>> HCR_EL2.VSE injects an SError. This register is added by the
>> RAS Extensions.
> 
> This commit message is confusing and doesn't help me understand the
> patch.
(1) what is the rationale for the guest OS SError interrupt(SEI) handling in 
the RAS solution?
  you can refer to document: "RAS_Extension_PRD03-PRDC-010953-32-0, 6.5.3 
Example software sequences"
  a). In the firmware-first RAS solution, when guest OS happen a SError 
interrupt (SEI), it will firstly trap to EL3(SCR_EL3.EA = 1);
  b). The firmware logs, triages, and delegates the error exception to the 
hypervisor. As the error came from guest OS  EL1, firmware
  does by faking an SError interrupt exception entry to EL2.
  c). Control transfers to the hypervisor's delegated error recovery 
agent.Because HCR_EL2.AMO is set to 1, the hypervisor can use a
  Virtual SError interrupt to delegate an asynchronous abort to EL1, by 
setting HCR_EL2.VSE to 1 and using VESR_EL2 to pass syndrome.

(2) what is this patch mainly do?
  As mentioned above, the hypervisor needs to enable virtual SError and pass 
the virtual syndrome to the guest OS.

  a). when Control transfers to the hypervisor from firmware by faking an 
SError interrupt, the hypervisor delivered the syndrome_info(esr_el2) and
  host VA address( Qemu translate this VA address to the virtual machine 
physical address(IPA)) using below new added "serror_intr" struct.
/* KVM_EXIT_SERROR_INTR */
struct {
__u32 syndrome_info;
__u64 address;
} serror_intr;

  b). Qemu gets the address(host VA) delivered by KVM, translate this host VA 
address to virtual machine physical address(IPA), and runtime record this 
virtual
 machine physical address(IPA) to the guest OS's APEI table.

  c). Qemu gets the syndrome_info delivered by KVM, it refers to this syndrome 
value(but can be different from it) to specify the virtual SError interrupt's 
syndrome through setting VESR_EL2.

the vsesr_el2 is armv8.2 register, its explanation can be found in 
"RAS_Extension_PRD03-PRDC-010953-33-0, 5.6.18 VSESR_EL2, Virtual SError 
Exception Syndrome Register"

>>The VSESR_EL2 characteristics are:
>>Purpose:
>>Provides the syndrome value reported to software on taking a virtual 
SError interrupt exception:
>>  — If the virtual SError interrupt is taken to EL1 using AArch64 
then VSESR_EL2 provides the
>>syndrome value reported in ESR_EL1.
>>  — If the virtual SError interrupt is taken to EL1 using AArch32 
then VSESR_EL2 provides the
>>syndrome values reported in DFSR.{AET, ExT} and the remainder 
of the DFSR is set as
>>   defined by VMSAv8-32.

 so in the KVM, I added a new IOCTL(#define KVM_ARM_SEI  _IO(KVMIO,  0xb8)) 
to pass the virtual SError syndrome value specified by Qemu and enable a 
virtual System Error.


 d). when world switch to guest OS, guest OS will happen virtual SError(this 
virtual SError can not be route to EL3 firmware), guest OS uses the specified 
syndrome value to do the recovery and
 parses the guest OS CPER which is dynamically recorded by the Qemu in the 
APEI table .



> 
> I think this patch is trying to do too many things.  I suggest you split
> the patch into (at least) one patch that captures exception information
> from the world-switch path, one patch that deals with the new exit
> reason, and finally a patch with the new ioctl.  That way you can write
> a commit message for each patch describing first what the patch does,
> and then why this is a good idea.
  Ok, thanks for the good suggestion.

> 
> Neverthess, I added some random comments below.
> 
>>
>> Changes since v3:
>> (1) Move restore VSESR_EL2 value logic to a helper method
>> (2) In the world-switch, not save VSESR_EL2, because no one cares the
>> old VSESR_EL2 value
>> (3) Add a new KVM_ARM_SEI ioctl to set the VSESR_EL2 value and pend
>> a virtual system error
>>
>> Signed-off-by: Dongjiu Geng 
>> Signed-off-by: Quanming Wu 
>> ---
>>  Documentation/virtual/kvm/api.txt| 10 ++
>>  arch/arm/include/asm/kvm_host.h  |  1 +
>>  arch/arm/kvm/arm.c   |  7 +++
>>  arch/arm/kvm/guest.c |  5 +
>>  arch/arm64/include/asm/esr.h |  2 ++
>>  

Re: [PULL] Docs for 4.13

[Linus Torvalds]

On Mon, Jul 3, 2017 at 6:20 AM, Jonathan Corbet  wrote:
>You'll also encounter more than the usual number of conflicts, which
>is saying something.

Hmm. I fixed the ones that were actual data conflicts, but I think
there ends up being several things that are just stale or didn't get
updated by other pulls.

Eg things like

  Error: Cannot open file ./kernel/rcu/srcu.c
  Error: Cannot open file ./kernel/rcu/srcu.c

happen simply because that file no longer exists, and the docs never
got updated.

So my merge didn't even try to fix those kinds of things at all.  I
literally just looked at the conflicts and moved those over to the rst
files, and that was it. There's a lot of other changes that never
cause conflicts for the simple reason that those changes never caused
documentation changes to begin with.

Now, this is obviously not new, but it does strike me that if checking
for these kinds of things was easier and part of "make allmodconfig",
then we might have less of it happen.

At the same time, lots of people run a lot of builds, and while I'd
love to see warnings about docs failures, I am *not* willing to slow
down my usual build enormously. I run "male allmodconfig" builds
between every single pull during the merge window, and while it's
often parallel with me looking at the problems, I don't really want to
slow the build down too much. And the doc building is still *slow*.

Is there some fast "just basic sanity checks" that would be more reasonable?

Because one thing that the switch to sphinx has done is that the doc
build environment seems saner (tool-wise). So now that kind of thing
would at least be _possible_ to do in ways I don't think was
reasonable with docbook.

And now docbook is finally gone. But sphinx isn't exactly a speed demon either.

 Linus
--
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 2/2] x86/idle: use dynamic halt poll

[Yang Zhang]

On 2017/7/3 18:06, Thomas Gleixner wrote:

On Mon, 3 Jul 2017, Yang Zhang wrote:

The background is that we(Alibaba Cloud) do get more and more complaints from
our customers in both KVM and Xen compare to bare-mental.After investigations,
the root cause is known to us: big cost in message passing workload(David show
it in KVM forum 2015)

A typical message workload like below:
vcpu 0 vcpu 1
1. send ipi 2.  doing hlt
3. go into idle 4.  receive ipi and wake up from hlt
5. write APIC time twice6.  write APIC time twice to
   to stop sched timer  reprogram sched timer
7. doing hlt8.  handle task and send ipi to
vcpu 0
9. same to 4.   10. same to 3

One transaction will introduce about 12 vmexits(2 hlt and 10 msr write). The
cost of such vmexits will degrades performance severely. Linux kernel already
provide idle=poll to mitigate the trend. But it only eliminates the IPI and
hlt vmexit. It has nothing to do with start/stop sched timer. A compromise
would be to turn off NOHZ kernel, but it is not the default config for new
distributions.


You still can turn if off on the kernel command line via nohz=off


You are right. Senior users will turn off it manually. But it only solve 
the sched timer. They still have the IPI/hlt problem. Another point is 
we release the distribution image to customer without any extra 
configuration to avoid mismatch between VM and bare-metal. To change 
such configuration needs reboot, but some customer's business cannot be 
interrupted after they start the service(like online gaming). It would 
be better if we can provide the sysctl interface to allow run-time 
modification. By the way, idle=poll seems too heavy to use.






Thanks,

tglx




--
Yang
Alibaba Cloud Computing
--
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 v3 1/3] rtmutex: update rt-mutex-design

[Steven Rostedt]

On Thu, 25 May 2017 13:26:32 +0800
Alex Shi  wrote:

> The rt-mutex-design documents didn't gotten meaningful update from its
> first version. Even after owner's pending bit was removed in commit 
> 8161239a8bcc
> ("rtmutex: Simplify PI algorithm and make highest prio task get lock")
> and priority list 'plist' changed to rbtree. And Peter Zijlstra did some
> clean up and fix for deadline task changes on tip tree.
> 
> So update it to latest code and make it meaningful.
> 
> Signed-off-by: Alex Shi 
> Cc: Steven Rostedt 
> Cc: Sebastian Siewior 
> Cc: Mathieu Poirier 
> Cc: Juri Lelli 
> Cc: Thomas Gleixner 
> To: linux-doc@vger.kernel.org
> To: linux-ker...@vger.kernel.org
> To: Jonathan Corbet 
> To: Ingo Molnar 
> To: Peter Zijlstra 
> ---
>  Documentation/locking/rt-mutex-design.txt | 418 
> +++---
>  1 file changed, 97 insertions(+), 321 deletions(-)
> 
> diff --git a/Documentation/locking/rt-mutex-design.txt 
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..1a0da32 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
> of a blocked
> a process being blocked on the mutex, it is fine to allocate
> the waiter on the process's stack (local variable).  This
> structure holds a pointer to the task, as well as the mutex that
> -   the task is blocked on.  It also has the plist node structures to
> -   place the task in the waiter_list of a mutex as well as the
> -   pi_list of a mutex owner task (described below).


> +   the task is blocked on.  It also has a rbtree node structures to

 "has rbtree node structures"

> +   place the task in waiters rbtree of a mutex as well as the

 "place the task in the waiters"

> +   pi_waiters rbtree of a mutex owner task (described below).



>  
> waiter is sometimes used in reference to the task that is waiting
> on a mutex. This is the same as waiter->task.
> @@ -179,53 +179,35 @@ again.
>   |
> F->L5-+
>  
> -
> -Plist
> --
> -
> -Before I go further and talk about how the PI chain is stored through lists
> -on both mutexes and processes, I'll explain the plist.  This is similar to
> -the struct list_head functionality that is already in the kernel.
> -The implementation of plist is out of scope for this document, but it is
> -very important to understand what it does.
> -
> -There are a few differences between plist and list, the most important one
> -being that plist is a priority sorted linked list.  This means that the
> -priorities of the plist are sorted, such that it takes O(1) to retrieve the
> -highest priority item in the list.  Obviously this is useful to store 
> processes
> -based on their priorities.
> -
> -Another difference, which is important for implementation, is that, unlike
> -list, the head of the list is a different element than the nodes of a list.
> -So the head of the list is declared as struct plist_head and nodes that will
> -be added to the list are declared as struct plist_node.
> -
> +If process G has the highest priority in the chain, then all the tasks up
> +the chain (A and B in this example), must have their priorities increased
> +to that of G.
>  
>  Mutex Waiter List

 "Mutex Waiters Tree"

>  -
>  
>  Every mutex keeps track of all the waiters that are blocked on itself. The 
> mutex
> -has a plist to store these waiters by priority.  This list is protected by
> +has a rbtree to store these waiters by priority.  This tree is protected by
>  a spin lock that is located in the struct of the mutex. This lock is called
> -wait_lock.  Since the modification of the waiter list is never done in
> +wait_lock.  Since the modification of the waiter tree is never done in

   "waiters tree"

>  interrupt context, the wait_lock can be taken without disabling interrupts.


Note, we now always disable interrupts when taking the waiter_lock, so
that last sentence needs to go too.

>  
>  
> -Task PI List
> +Task PI Tree
>  
>  
> -To keep track of the PI chains, each process has its own PI list.  This is
> -a list of all top waiters of the mutexes that are owned by the process.
> -Note that this list only holds the top waiters and not all waiters that are
> +To keep track of the PI chains, each process has its own PI rbtree.  This is
> +a tree of all top waiters of the mutexes that are owned by the process.
> +Note that this tree only holds the top waiters and not all waiters that are
>  blocked on mutexes owned by the process.
>  
> -The top of the task's PI list is always the 

Re: [PATCH v4] arm64: kvm: inject SError with user space specified syndrome

[Christoffer Dall]

On Mon, Jul 3, 2017 at 4:09 PM, gengdongjiu  wrote:
> Hi Christoffer,
>   thank you very much for your review.
>
>
> 2017-07-03 15:50 GMT+08:00, Christoffer Dall :
>> Hi Dongjiu,
>>
>> It seems you sent this patch twice, once on its own and then part of a
>> series?
> Christoffer, yes, it is. once on its own and then part of a
> series
>

ok, please don't do that in the future. It confuses us on the other end.

>>
>> Also, please use a cover letter when sending patch series.
> Ok, got it, thank you a lot for your suggestion.
>

Thanks, I'll look more closely once you respin into a new series.

-Christoffer
--
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 v4] arm64: kvm: inject SError with user space specified syndrome

[gengdongjiu]

Hi Christoffer,
  thank you very much for your review.


2017-07-03 15:50 GMT+08:00, Christoffer Dall :
> Hi Dongjiu,
>
> It seems you sent this patch twice, once on its own and then part of a
> series?
Christoffer, yes, it is. once on its own and then part of a
series

>
> Also, please use a cover letter when sending patch series.
Ok, got it, thank you a lot for your suggestion.

>
> Thanks,
> -Christoffer
>
> On Mon, Jun 26, 2017 at 07:39:15PM +0800, Dongjiu Geng wrote:
>> when SError happen, kvm notifies user space to record the CPER,
>> user space specifies and passes the contents of ESR_EL1 on taking
>> a virtual SError interrupt to KVM, KVM enables virtual system
>> error or asynchronous abort with this specifies syndrome. This
>> patch modify the world-switch to restore VSESR_EL2, VSESR_EL2
>> saves the virtual SError syndrome, it becomes the ESR_EL1 value when
>> HCR_EL2.VSE injects an SError. This register is added by the
>> RAS Extensions.
>>
>> Changes since v3:
>> (1) Move restore VSESR_EL2 value logic to a helper method
>> (2) In the world-switch, not save VSESR_EL2, because no one cares the
>> old VSESR_EL2 value
>> (3) Add a new KVM_ARM_SEI ioctl to set the VSESR_EL2 value and pend
>> a virtual system error
>>
>> Signed-off-by: Dongjiu Geng 
>> Signed-off-by: Quanming Wu 
>> ---
>>  Documentation/virtual/kvm/api.txt| 10 ++
>>  arch/arm/include/asm/kvm_host.h  |  1 +
>>  arch/arm/kvm/arm.c   |  6 ++
>>  arch/arm/kvm/guest.c |  5 +
>>  arch/arm64/include/asm/esr.h |  2 ++
>>  arch/arm64/include/asm/kvm_emulate.h | 10 ++
>>  arch/arm64/include/asm/kvm_host.h|  2 ++
>>  arch/arm64/include/asm/sysreg.h  |  3 +++
>>  arch/arm64/kvm/guest.c   | 14 ++
>>  arch/arm64/kvm/handle_exit.c | 25 +++--
>>  arch/arm64/kvm/hyp/switch.c  | 14 ++
>>  include/uapi/linux/kvm.h |  8 
>>  12 files changed, 94 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/virtual/kvm/api.txt
>> b/Documentation/virtual/kvm/api.txt
>> index 3c248f7..852ac55 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -3377,6 +3377,16 @@ struct kvm_ppc_resize_hpt {
>>  __u32 pad;
>>  };
>>
>> +4.104 KVM_ARM_SEI
>> +
>> +Capability: KVM_EXIT_SERROR_INTR
>> +Architectures: arm/arm64
>> +Type: vcpu ioctl
>> +Parameters: u64 (syndrome)
>> +Returns: 0 in case of success
>> +
>> +Pend an virtual system error or asynchronous abort with user space
>> specified.
>> +
>>  5. The kvm_run structure
>>  
>>
>> diff --git a/arch/arm/include/asm/kvm_host.h
>> b/arch/arm/include/asm/kvm_host.h
>> index 31ee468..566292a 100644
>> --- a/arch/arm/include/asm/kvm_host.h
>> +++ b/arch/arm/include/asm/kvm_host.h
>> @@ -244,6 +244,7 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu,
>> const struct kvm_one_reg *);
>>
>>  int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>>  int exception_index);
>> +int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
>>
>>  static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
>> unsigned long hyp_stack_ptr,
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 96dba7c..2622501 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -987,6 +987,12 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>>  return -EFAULT;
>>  return kvm_arm_vcpu_has_attr(vcpu, );
>>  }
>> +case KVM_ARM_SEI: {
>> +u64 syndrome;
>> +if (copy_from_user(, argp, sizeof(syndrome)))
>> +return -EFAULT;
>> +return kvm_vcpu_ioctl_sei(vcpu, );
>> +}
>>  default:
>>  return -EINVAL;
>>  }
>> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
>> index fa6182a..a610f8f 100644
>> --- a/arch/arm/kvm/guest.c
>> +++ b/arch/arm/kvm/guest.c
>> @@ -248,6 +248,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu
>> *vcpu,
>>  return -EINVAL;
>>  }
>>
>> +int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
>> +{
>> +return 0;
>> +}
>> +
>>  int __attribute_const__ kvm_target_cpu(void)
>>  {
>>  switch (read_cpuid_part()) {
>> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
>> index 22f9c90..d009c99 100644
>> --- a/arch/arm64/include/asm/esr.h
>> +++ b/arch/arm64/include/asm/esr.h
>> @@ -127,6 +127,8 @@
>>  #define ESR_ELx_WFx_ISS_WFE (UL(1) << 0)
>>  #define ESR_ELx_xVC_IMM_MASK((1UL << 16) - 1)
>>
>> +#define VSESR_ELx_IDS_ISS_MASK((1UL << 25) - 1)
>> +
>>  /* ESR value templates for specific events */
>>
>>  /* BRK instruction trap from AArch64 state */
>> diff --git a/arch/arm64/include/asm/kvm_emulate.h
>> b/arch/arm64/include/asm/kvm_emulate.h
>> index 

Re: [PATCH v3 01/28] crypto: change backlog return code to -EIOCBQUEUED

[Gilad Ben-Yossef]

On Mon, Jul 3, 2017 at 3:35 PM, Herbert Xu  wrote:
> On Sun, Jul 02, 2017 at 05:41:43PM +0300, Gilad Ben-Yossef wrote:
>> The crypto API was using the -EBUSY return value to indicate
>> both a hard failure to submit a crypto operation into a
>> transformation provider when the latter was busy and the backlog
>> mechanism was not enabled as well as a notification that the operation
>> was queued into the backlog when the backlog mechanism was enabled.
>>
>> Having the same return code indicate two very different conditions
>> depending on a flag is both error prone and requires extra runtime
>> check like the following to discern between the cases:
>>
>>   if (err == -EINPROGRESS ||
>>   (err == -EBUSY && (ahash_request_flags(req) &
>>  CRYPTO_TFM_REQ_MAY_BACKLOG)))
>>
>> This patch changes the return code used to indicate a crypto op
>> was queued in the backlog to -EIOCBQUEUED, thus resolving both
>> issues.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>
> So you're changing the success case from EBUSY to EIOCBQUEUED.
> This results in a lot of churn as you have to change every single
> driver and caller.
>
> How about changing the error case to use something other than
> EBUSY instead?

That was indeed my first thought - I wanted to change EBUSY to EAGAIN.
It might even be a more descriptive error message since the failure is
transient.

What stopped me was that I saw the algif interface passes this EBUSY value
to user space. I don't know of any software that depends on this value but
I'm really averse to changing user space API.

Of course, we can just plant a (ret != AGAIN : ? EBUSY) in the algif interface
return to user space code path but that felt like a kludge to me.

And it doesn't really save any churn, I think - I'd still have to
visit all the places that
use the flags value to distinguish between the two EBUSY use cases and  I need
to visit most places that check for EBUSY as backlog indication because I'm
replacing the check with the generic replacement, so it doesn't look
like in the end
it will be a smaller change.

Having said that, if you prefer me to replace the error case I'd
happily do that.

Thanks,
Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru
--
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

[PULL] Docs for 4.13

[Jonathan Corbet]

The following changes since commit
2ea659a9ef488125eb46da6eb571de5eae5c43f6:

  Linux 4.12-rc1 (2017-05-13 13:19:49 -0700)

are available in the git repository at:

  git://git.lwn.net/linux.git tags/docs-4.13

for you to fetch changes up to 1cb566ba5634d7593b8b2a0a5c83f1c9e14b2e09:

  scripts/kernel-doc: handle DECLARE_HASHTABLE (2017-07-03 06:57:09 -0600)


There has been a fair amount of activity in the docs tree this time
around.  Highlights include:

 - Conversion of a bunch of security documentation into RST

 - The conversion of the remaining DocBook templates by The Amazing
   Mauro Machine.  We can now drop the entire DocBook build chain.

 - The usual collection of fixes and minor updates.

NOTES: this is a somewhat messy-looking pull, unfortunately, due to the
   nature of the changes.  Mauro's work, in particular, involved fixing
   lots of kerneldoc comments elsewhere in the tree; there are no code
   changes in the non-docs stuff.

   You'll also encounter more than the usual number of conflicts, which
   is saying something.  The tip tree tweaked kernel-hacking.tmpl,
   which got converted to RST; the change just needs to be carried
   over.  There is a similar situation with w1.tmpl being changed in
   the char-misc tree.  Kbuild wants to change the shebang line in the
   kernel-doc-xml-ref tool, but that tool is just not needed anymore.

   Hopefully, as the transition settles down we'll see less of this
   kind of stuff.  Meanwhile thanks to Stephen for flagging and
   managing all of these.


Ayan Shafqat (1):
  Doc: fix a markup error in coding-style.rst

Jakub Kicinski (1):
  scripts/kernel-doc: handle DECLARE_HASHTABLE

Jonathan Corbet (7):
  Merge tag 'v4.12-rc1' into docs-next
  docs: Fix some formatting issues in request-key.rst
  Merge remote-tracking branch 'mauro-exp/docbook3' into death-to-docbook
  Docs: Include the Latex "ifthen" package
  Docs: fix table problems in ras.rst
  Docs: Use kernel-figure in vidioc-g-selection.rst
  Docs: clean up some DocBook loose ends

Kees Cook (17):
  doc: ReSTify seccomp_filter.txt
  doc: ReSTify no_new_privs.txt
  doc: ReSTify IMA-templates.txt
  doc: ReSTify credentials.txt
  doc: ReSTify self-protection.txt
  doc: security: minor cleanups to build kernel-doc
  doc: ReSTify and split LSM.txt
  doc: ReSTify SELinux.txt
  doc: ReSTify apparmor.txt
  doc: ReSTify tomoyo.txt
  doc: ReSTify Yama.txt
  doc: ReSTify LoadPin.txt
  doc: ReSTify Smack.txt
  doc: ReSTify keys.txt
  doc: ReSTify keys-ecryptfs.txt
  doc: ReSTify keys-request-key.txt
  doc: ReSTify keys-trusted-encrypted.txt

Konstantin Ryabitsev (1):
  Make the main documentation title less Geocities

Markus Heiser (2):
  core-api: remove an unexpected unident
  doc-rst: fix inline emphasis in unshare.rst

Mauro Carvalho Chehab (54):
  docs-rst: convert kernel-hacking to ReST
  kernel-hacking: update document
  docs-rst: convert kernel-locking to ReST
  mutex, futex: adjust kernel-doc markups to generate ReST
  locking.rst: reformat locking table
  locking.rst: add captions to two tables
  locking.rst: Update some ReST markups
  docs-rst: convert kgdb DocBook to ReST
  kgdb.rst: Adjust ReST markups
  conf.py: define a color for important markup on PDF output
  docs-rst: conf.py: sort LaTeX documents in alphabetical order
  docs-rst: conf.py: remove kernel-documentation from LaTeX
  docs-rst: add crypto API book to pdf output
  docs-rst: add dev-tools book to pdf output
  docs-rst: add sound book to pdf output
  docs-rst: add userspace API book to pdf output
  docs-rst: convert filesystems book to ReST
  docs-rst: filesystems: use c domain references where needed
  fs: jbd2: make jbd2_journal_start() kernel-doc parseable
  docs-rst: don't ignore internal functions for jbd2 docs
  fs: add a blank lines on some kernel-doc comments
  fs: eventfd: fix identation on kernel-doc
  fs: jbd2: escape a string with special chars on a kernel-doc
  docs-rst: convert libata book to ReST
  libata.rst: add c function and struct cross-references
  libata: fix identation on a kernel-doc markup
  docs-rst: convert s390-drivers DocBook to ReST
  docs-rst: convert networking book to ReST
  net: skbuff.h: properly escape a macro name on kernel-doc
  net: fix some identation issues at kernel-doc markups
  docs-rst: convert z8530book DocBook to ReST
  docs-rst: convert scsi DocBook to ReST
  scsi: fix some kernel-doc markups
  docs-rst: convert w1 book to ReST
  docs-rst: convert rapidio book to ReST
  docs-rst: convert librs book to ReST
  docs-rst: convert mtdnand book to 

Re: [PATCH] scripts/kernel-doc: handle DECLARE_HASHTABLE

[Jonathan Corbet]

On Sat, 1 Jul 2017 12:11:03 -0700
Jakub Kicinski  wrote:

> > That was my question as well...as Andrew would ask: what are the
> > user-visible effects of this problem?  
> 
> The commit which made me write the patch is sitting in Dave Miller's
> net-next tree:
> 
> 43f84b72c50d ("nfp: add metadata to each flow offload")

Good enough, I've applied it, thanks.

jon
--
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 0/5] Make PDF builds work again

[Jonathan Corbet]

On Mon, 3 Jul 2017 10:25:38 +0200
Daniel Vetter  wrote:

> Only now stumbled over the full thread, but the drm patch is already
> queued up for at least 4.13 (Dave was out and all that). I guess we could
> try to cherry-pick through stable.

I kind of gave up on the 4.12 goal, at least for now.  The number of
complaints has not been huge - I suspect you're far from the only one who
is not too worried about building PDFs...:)

jon
--
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 v3 01/28] crypto: change backlog return code to -EIOCBQUEUED

[Herbert Xu]

On Sun, Jul 02, 2017 at 05:41:43PM +0300, Gilad Ben-Yossef wrote:
> The crypto API was using the -EBUSY return value to indicate
> both a hard failure to submit a crypto operation into a
> transformation provider when the latter was busy and the backlog
> mechanism was not enabled as well as a notification that the operation
> was queued into the backlog when the backlog mechanism was enabled.
> 
> Having the same return code indicate two very different conditions
> depending on a flag is both error prone and requires extra runtime
> check like the following to discern between the cases:
> 
>   if (err == -EINPROGRESS ||
>   (err == -EBUSY && (ahash_request_flags(req) &
>  CRYPTO_TFM_REQ_MAY_BACKLOG)))
> 
> This patch changes the return code used to indicate a crypto op
> was queued in the backlog to -EIOCBQUEUED, thus resolving both
> issues.
> 
> Signed-off-by: Gilad Ben-Yossef 

So you're changing the success case from EBUSY to EIOCBQUEUED.
This results in a lot of churn as you have to change every single
driver and caller.

How about changing the error case to use something other than
EBUSY instead?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 1/2] docs RDT theme: fix bottom margin of lists items

[Markus Heiser]

Hi Jon,

sorry for my noise .. did you received the two patches?

-- Markus --

> Am 17.06.2017 um 10:17 schrieb Markus Heiser :
> 
> List items with two ore more blocks are not well rendered. E.g. the gap
> between last block (l1-b2) of the first list item and the following list
> item (L2) is to small::
> 
>* L1 xx
>  x
> 
>  l1-b2 xxx
>  x
>* L2 xx
>  x
> 
> So that it can be read more liquidly, a distance was added to the last
> block (l1-b2)::
> 
>* L1 xx
>  x
> 
>  l1-b2 xxx
>  x
> 
>* L2 xx
>  x
> 
> Signed-off-by: Markus Heiser 
> ---
> Documentation/sphinx-static/theme_overrides.css | 6 ++
> 1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/sphinx-static/theme_overrides.css 
> b/Documentation/sphinx-static/theme_overrides.css
> index d5764a4..1c9a9ab 100644
> --- a/Documentation/sphinx-static/theme_overrides.css
> +++ b/Documentation/sphinx-static/theme_overrides.css
> @@ -56,6 +56,12 @@
>   font-family: "Courier New", Courier, monospace
> }
> 
> +/* fix bottom margin of lists items */
> +
> +.rst-content .section ul li:last-child, .rst-content .section ul li 
> p:last-child {
> +  margin-bottom: 12px;
> +}
> +
> /* inline literal: drop the borderbox, padding and red color */
> 
> code, .rst-content tt, .rst-content code {
> -- 
> 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: [PATCH 2/2] x86/idle: use dynamic halt poll

[Thomas Gleixner]

On Mon, 3 Jul 2017, Yang Zhang wrote:
> The background is that we(Alibaba Cloud) do get more and more complaints from
> our customers in both KVM and Xen compare to bare-mental.After investigations,
> the root cause is known to us: big cost in message passing workload(David show
> it in KVM forum 2015)
> 
> A typical message workload like below:
> vcpu 0 vcpu 1
> 1. send ipi 2.  doing hlt
> 3. go into idle 4.  receive ipi and wake up from hlt
> 5. write APIC time twice6.  write APIC time twice to
>to stop sched timer  reprogram sched timer
> 7. doing hlt8.  handle task and send ipi to
> vcpu 0
> 9. same to 4.   10. same to 3
> 
> One transaction will introduce about 12 vmexits(2 hlt and 10 msr write). The
> cost of such vmexits will degrades performance severely. Linux kernel already
> provide idle=poll to mitigate the trend. But it only eliminates the IPI and
> hlt vmexit. It has nothing to do with start/stop sched timer. A compromise
> would be to turn off NOHZ kernel, but it is not the default config for new
> distributions.

You still can turn if off on the kernel command line via nohz=off

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

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

[Yang Zhang]

On 2017/6/27 22:22, Radim Krčmář wrote:

2017-06-27 15:56+0200, Paolo Bonzini:

On 27/06/2017 15:40, Radim Krčmář wrote:

... which is not necessarily _wrong_.  It's just a different heuristic.

Right, it's just harder to use than host's single_task_running() -- the
VCPU calling vcpu_is_preempted() is never preempted, so we have to look
at other VCPUs that are not halted, but still preempted.

If we see some ratio of preempted VCPUs (> 0?), then we stop polling and
yield to the host.  Working under the assumption that there is work for
this PCPU if other VCPUs have stuff to do.  The downside is that it
misses information about host's topology, so it would be hard to make it
work well.


I would just use vcpu_is_preempted on the current CPU.  From guest POV
this option is really a "f*** everyone else" setting just like
idle=poll, only a little more polite.


vcpu_is_preempted() on current cpu cannot return true, AFAIK.


If we've been preempted and we were polling, there are two cases.  If an
interrupt was queued while the guest was preempted, the poll will be
treated as successful anyway.


I think the poll should be treated as invalid if the window has expired
while the VCPU was preempted -- the guest can't tell whether the
interrupt arrived still within the poll window (unless we added paravirt
for that), so it shouldn't be wasting time waiting for it.


   If it hasn't, let others run---but really
that's not because the guest wants to be polite, it's to avoid that the
scheduler penalizes it excessively.


This sounds like a VM entry just to do an immediate VM exit, so paravirt
seems better here as well ... (the guest telling the host about its
window -- which could also be used to rule it out as a target in the
pause loop random kick.)


So until it's preempted, I think it's okay if the guest doesn't care
about others.  You wouldn't use this option anyway in overcommitted
situations.

(I'm still not very convinced about the idea).


Me neither.  (The same mechanism is applicable to bare-metal, but was
never used there, so I would rather bring the guest behavior closer to
bare-metal.)



The background is that we(Alibaba Cloud) do get more and more complaints 
from our customers in both KVM and Xen compare to bare-mental.After 
investigations, the root cause is known to us: big cost in message 
passing workload(David show it in KVM forum 2015)


A typical message workload like below:
vcpu 0 vcpu 1
1. send ipi 2.  doing hlt
3. go into idle 4.  receive ipi and wake up from hlt
5. write APIC time twice6.  write APIC time twice to
   to stop sched timer  reprogram sched timer
7. doing hlt8.  handle task and send ipi to
vcpu 0
9. same to 4.   10. same to 3

One transaction will introduce about 12 vmexits(2 hlt and 10 msr write). 
The cost of such vmexits will degrades performance severely. Linux 
kernel already provide idle=poll to mitigate the trend. But it only 
eliminates the IPI and hlt vmexit. It has nothing to do with start/stop 
sched timer. A compromise would be to turn off NOHZ kernel, but it is 
not the default config for new distributions. Same for halt-poll in KVM, 
it only solve the cost from schedule in/out in host and can not help 
such workload much.


The purpose of this patch we want to improve current idle=poll mechanism 
to use dynamic polling and do poll before touch sched timer. It should 
not be a virtualization specific feature but seems bare mental have low 
cost to access the MSR. So i want to only enable it in VM. Though the 
idea below the patch may not so perfect to fit all conditions, it looks 
no worse than now.
How about we keep current implementation and i integrate the patch to 
para-virtualize part as Paolo suggested? We can continue discuss it and 
i will continue to refine it if anyone has better suggestions?



--
Yang
Alibaba Cloud Computing
--
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 v2] Documentation: fix wrong example command

[David Miller]

From: Matteo Croce 
Date: Fri, 30 Jun 2017 18:21:47 +0200

> In the IPVLAN documentation there is an example command line where the
> master and slave interface names are inverted.
> Fix the command line and also add the optional `name' keyword to better
> describe what the command is doing.
> 
> v2: added commit message
> 
> Signed-off-by: Matteo Croce 

Applied, thank you.
--
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 v4 3/3] arm64: kvm: inject SError with user space specified syndrome

[Christoffer Dall]

Hi Dongjiu,

On Mon, Jun 26, 2017 at 08:46:39PM +0800, Dongjiu Geng wrote:
> when SError happen, kvm notifies user space to record the CPER,
> user space specifies and passes the contents of ESR_EL1 on taking
> a virtual SError interrupt to KVM, KVM enables virtual system
> error or asynchronous abort with this specifies syndrome. This
> patch modify the world-switch to restore VSESR_EL2, VSESR_EL2
> saves the virtual SError syndrome, it becomes the ESR_EL1 value when
> HCR_EL2.VSE injects an SError. This register is added by the
> RAS Extensions.

This commit message is confusing and doesn't help me understand the
patch.

I think this patch is trying to do too many things.  I suggest you split
the patch into (at least) one patch that captures exception information
from the world-switch path, one patch that deals with the new exit
reason, and finally a patch with the new ioctl.  That way you can write
a commit message for each patch describing first what the patch does,
and then why this is a good idea.

Neverthess, I added some random comments below.

> 
> Changes since v3:
> (1) Move restore VSESR_EL2 value logic to a helper method
> (2) In the world-switch, not save VSESR_EL2, because no one cares the
> old VSESR_EL2 value
> (3) Add a new KVM_ARM_SEI ioctl to set the VSESR_EL2 value and pend
> a virtual system error
> 
> Signed-off-by: Dongjiu Geng 
> Signed-off-by: Quanming Wu 
> ---
>  Documentation/virtual/kvm/api.txt| 10 ++
>  arch/arm/include/asm/kvm_host.h  |  1 +
>  arch/arm/kvm/arm.c   |  7 +++
>  arch/arm/kvm/guest.c |  5 +
>  arch/arm64/include/asm/esr.h |  2 ++
>  arch/arm64/include/asm/kvm_emulate.h | 10 ++
>  arch/arm64/include/asm/kvm_host.h|  2 ++
>  arch/arm64/include/asm/sysreg.h  |  3 +++
>  arch/arm64/kvm/guest.c   | 14 ++
>  arch/arm64/kvm/handle_exit.c | 25 +++--
>  arch/arm64/kvm/hyp/switch.c  | 14 ++
>  include/uapi/linux/kvm.h |  8 
>  12 files changed, 95 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/virtual/kvm/api.txt 
> b/Documentation/virtual/kvm/api.txt
> index 3c248f7..852ac55 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -3377,6 +3377,16 @@ struct kvm_ppc_resize_hpt {
>   __u32 pad;
>  };
>  
> +4.104 KVM_ARM_SEI
> +
> +Capability: KVM_EXIT_SERROR_INTR
> +Architectures: arm/arm64
> +Type: vcpu ioctl
> +Parameters: u64 (syndrome)
> +Returns: 0 in case of success
> +
> +Pend an virtual system error or asynchronous abort with user space specified.
> +

I don't understand enough about what this ioctl does by just reading
this text.  Did you mean to say something like "Record that userspace
wishes to inject a pending virtual system error to the VCPU.  Next time
the VCPU is run, th

>  5. The kvm_run structure
>  
>  
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 31ee468..566292a 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -244,6 +244,7 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const 
> struct kvm_one_reg *);
>  
>  int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>   int exception_index);
> +int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
>  
>  static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
>  unsigned long hyp_stack_ptr,
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 96dba7c..583294f 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -987,6 +987,13 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>   return -EFAULT;
>   return kvm_arm_vcpu_has_attr(vcpu, );
>   }
> + case KVM_ARM_SEI: {
> + u64 syndrome;
> +
> + if (copy_from_user(, argp, sizeof(syndrome)))
> + return -EFAULT;
> + return kvm_vcpu_ioctl_sei(vcpu, );
> + }
>   default:
>   return -EINVAL;
>   }
> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
> index fa6182a..72505bf 100644
> --- a/arch/arm/kvm/guest.c
> +++ b/arch/arm/kvm/guest.c
> @@ -248,6 +248,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>   return -EINVAL;
>  }
>  
> +int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome)
> +{
> + return 0;
> +}
> +
>  int __attribute_const__ kvm_target_cpu(void)
>  {
>   switch (read_cpuid_part()) {
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index 22f9c90..d009c99 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -127,6 +127,8 @@
>  #define ESR_ELx_WFx_ISS_WFE  (UL(1) << 0)
>  #define ESR_ELx_xVC_IMM_MASK ((1UL << 16) - 1)
>  
> +#define VSESR_ELx_IDS_ISS_MASK  

Re: [PATCH 0/5] Make PDF builds work again

[Daniel Vetter]

On Sun, Jun 18, 2017 at 05:46:25PM -0600, Jonathan Corbet wrote:
> I've just spent rather more time than I would like figuring out why the PDF
> builds fail and what was needed to fix it.  The result is the following
> patch series.  It's a combination of little mistakes and fragility in the
> whole PDF build tool chain.
> 
> Mauro, Daniel: Do you want the last two?  Or otherwise give me acks?  I'd
> like to send the set Linusward forthwith so that 4.12 can come out with
> a working PDF build.

Only now stumbled over the full thread, but the drm patch is already
queued up for at least 4.13 (Dave was out and all that). I guess we could
try to cherry-pick through stable.

Personally I don't care at all for PDF builds, the only thing we do in our
autobuilder is html, same for me locally when building docs. That tends to
keep working :-)

Also, 0-day only tests the htmlbuild. Maybe you want to ping Fu and ask
him to add the pdfdocs to his build targets?
-Daniel

> 
> In general, I'm dismayed by the fragility of the whole thing.  I'm also a
> little concerned that nobody except Jim complained about the problem.
> Perhaps nobody really cares about PDF output anymore?  In the absence of a
> concerted effort on somebody's part, I predict that PDF building will be
> broken much of the time.  I have to wonder if it's worth it...
> 
> Jonathan Corbet (5):
>   Docs: Include the Latex "ifthen" package
>   Docs: Remove redundant geometry package inclusion
>   Docs: fix table problems in ras.rst
>   Docs: Use kernel-figure in vidioc-g-selection.rst
>   DRM: Fix an incorrectly formatted table
> 
>  Documentation/admin-guide/ras.rst  | 10 ++--
>  Documentation/conf.py  |  3 +-
>  .../media/uapi/v4l/vidioc-g-selection.rst  |  4 +-
>  include/drm/bridge/dw_hdmi.h   | 70 
> +++---
>  4 files changed, 43 insertions(+), 44 deletions(-)
> 
> -- 
> 2.13.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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 v4 2/3] arm64: kvm: route synchronous external abort exceptions to el2

[Christoffer Dall]

On Tue, Jun 27, 2017 at 08:15:49PM +0800, gengdongjiu wrote:
> correct the commit message:
> 
>  In the firmware-first RAS solution, OS receives an synchronous
>  external abort, then trapped to EL3 by SCR_EL3.EA. Firmware inspects
>  the HCR_EL2.TEA and chooses the target to send APEI's SEA notification.
>  If the SCR_EL3.EA is set, delegates the error exception to the hypervisor,
>  otherwise it delegates to the host OS kernel

This commit text has nothing (directly) to do with the content of the
patch.  Whether or not seting these bits are used by firmware to emulate
injecting an exception or by the CPU raising a an exception is not the
core of the issue.

Please describe your change, then provide rationale.

Thanks,
-Christoffer


> 
> 
> On 2017/6/26 20:45, Dongjiu Geng wrote:
> > In the firmware-first RAS solution, guest OS receives an synchronous
> > external abort, then trapped to EL3 by SCR_EL3.EA. Firmware inspects
> > the HCR_EL2.TEA and chooses the target to send APEI's SEA notification.
> > If the SCR_EL3.EA is set, delegates the error exception to the hypervisor,
> > otherwise it delegates to the guest OS kernel
> > 
> > Signed-off-by: Dongjiu Geng 
> > ---
> >  arch/arm64/include/asm/kvm_arm.h | 2 ++
> >  arch/arm64/include/asm/kvm_emulate.h | 7 +++
> >  2 files changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm64/include/asm/kvm_arm.h 
> > b/arch/arm64/include/asm/kvm_arm.h
> > index 61d694c..1188272 100644
> > --- a/arch/arm64/include/asm/kvm_arm.h
> > +++ b/arch/arm64/include/asm/kvm_arm.h
> > @@ -23,6 +23,8 @@
> >  #include 
> >  
> >  /* Hyp Configuration Register (HCR) bits */
> > +#define HCR_TEA(UL(1) << 37)
> > +#define HCR_TERR   (UL(1) << 36)
> >  #define HCR_E2H(UL(1) << 34)
> >  #define HCR_ID (UL(1) << 33)
> >  #define HCR_CD (UL(1) << 32)
> > diff --git a/arch/arm64/include/asm/kvm_emulate.h 
> > b/arch/arm64/include/asm/kvm_emulate.h
> > index f5ea0ba..5f64ab2 100644
> > --- a/arch/arm64/include/asm/kvm_emulate.h
> > +++ b/arch/arm64/include/asm/kvm_emulate.h
> > @@ -47,6 +47,13 @@ static inline void vcpu_reset_hcr(struct kvm_vcpu *vcpu)
> > vcpu->arch.hcr_el2 = HCR_GUEST_FLAGS;
> > if (is_kernel_in_hyp_mode())
> > vcpu->arch.hcr_el2 |= HCR_E2H;
> > +   if (cpus_have_const_cap(ARM64_HAS_RAS_EXTN)) {
> > +   /* route synchronous external abort exceptions to EL2 */
> > +   vcpu->arch.hcr_el2 |= HCR_TEA;
> > +   /* trap error record accesses */
> > +   vcpu->arch.hcr_el2 |= HCR_TERR;
> > +   }
> > +
> > if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features))
> > vcpu->arch.hcr_el2 &= ~HCR_RW;
> >  }
> > 
> 
--
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 v4 1/3] arm64: kvm: support user space to detect RAS extension feature

[Christoffer Dall]

On Mon, Jun 26, 2017 at 08:45:43PM +0800, Dongjiu Geng wrote:
> Handle userspace's detection for RAS extension, because sometimes
> the userspace needs to know the CPU's capacity

Why?  Can you please provide some more rationale.

> 
> Signed-off-by: Dongjiu Geng 
> ---
>  arch/arm64/kvm/reset.c   | 11 +++
>  include/uapi/linux/kvm.h |  1 +
>  2 files changed, 12 insertions(+)
> 
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index d9e9697..1004039 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -64,6 +64,14 @@ static bool cpu_has_32bit_el1(void)
>   return !!(pfr0 & 0x20);
>  }
>  
> +static bool kvm_arm_support_ras_extension(void)
> +{
> + u64 pfr0;
> +
> + pfr0 = read_system_reg(SYS_ID_AA64PFR0_EL1);
> + return !!(pfr0 & 0x1000);
> +}

Why is this specific to KVM?  This seems to reveal information about the
underlying physical CPU, not specific to KVM at all, surely if userspace
is really supposed to be able to figure this out, it should not be KVM
specific.

Thanks,
-Christoffer

> +
>  /**
>   * kvm_arch_dev_ioctl_check_extension
>   *
> @@ -87,6 +95,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, 
> long ext)
>   case KVM_CAP_ARM_PMU_V3:
>   r = kvm_arm_support_pmu_v3();
>   break;
> + case KVM_CAP_ARM_RAS_EXTENSION:
> + r = kvm_arm_support_ras_extension();
> + break;
>   case KVM_CAP_SET_GUEST_DEBUG:
>   case KVM_CAP_VCPU_ATTRIBUTES:
>   r = 1;
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index f51d508..27fe556 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -883,6 +883,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_PPC_MMU_RADIX 134
>  #define KVM_CAP_PPC_MMU_HASH_V3 135
>  #define KVM_CAP_IMMEDIATE_EXIT 136
> +#define KVM_CAP_ARM_RAS_EXTENSION 137
>  
>  #ifdef KVM_CAP_IRQ_ROUTING
>  
> -- 
> 2.10.1
> 
--
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] kernel-doc parser mishandles declarations split into lines

[Daniel Vetter]

On Fri, Jun 16, 2017 at 09:27:48PM +0200, Markus Heiser wrote:
> Reported by Johannes Berg [1].  Problem here: function
> process_proto_type() concatenates the striped lines of declaration
> without any whitespace. A one-liner of::
> 
>  struct something {
>struct foo
>bar;
>};
> 
> has to be::
> 
>  struct something {struct foo bar;};
> 
> Without the patching process_proto_type(), the result missed the space
> between 'foo' and 'bar'::
> 
>  struct something {struct foobar;};
> 
> Bugfix of process_proto_type() brings next error when blank lines
> between enum declaration::
> 
>  warning: Enum value ' ' not described in enum 'foo'
> 
> Problem here: dump_enum() does not strip leading whitespaces from
> the concatenated string (with the new additional space from
> process_proto_type).
> 
> [1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg12410.html
> 
> Signed-off-by: Markus Heiser 
> ---
>  scripts/kernel-doc | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index a26a5f2..fb67994 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -2223,6 +2223,7 @@ sub dump_enum($$) {
>  if ($x =~ /enum\s+(\w+)\s*{(.*)}/) {
>   $declaration_name = $1;
>   my $members = $2;
> + $members =~ s/\s+$//;
>  
>   foreach my $arg (split ',', $members) {
>   $arg =~ s/^\s*(\w+).*/$1/;
> @@ -2763,6 +2764,9 @@ sub process_proto_type($$) {
>  
>  while (1) {
>   if ( $x =~ /([^{};]*)([{};])(.*)/ ) {
> +if( length $prototype ) {
> +$prototype .= " "
> +}
>   $prototype .= $1 . $2;

Can't we avoid the issue in dump_enum if we're more careful with not
adding blanks here when not needed, i.e.

   if( length $prototype && length ($1 . $2)) {
$prototype .= " "
   }

Or do I miss something?
-Daniel

>   $prototype .= $1 . $2;
>   ($2 eq '{') && $brcount++;
>   ($2 eq '}') && $brcount--;
> -- 
> 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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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 v4] arm64: kvm: inject SError with user space specified syndrome

[Christoffer Dall]

Hi Dongjiu,

It seems you sent this patch twice, once on its own and then part of a
series?

Also, please use a cover letter when sending patch series.

Thanks,
-Christoffer

On Mon, Jun 26, 2017 at 07:39:15PM +0800, Dongjiu Geng wrote:
> when SError happen, kvm notifies user space to record the CPER,
> user space specifies and passes the contents of ESR_EL1 on taking
> a virtual SError interrupt to KVM, KVM enables virtual system
> error or asynchronous abort with this specifies syndrome. This
> patch modify the world-switch to restore VSESR_EL2, VSESR_EL2
> saves the virtual SError syndrome, it becomes the ESR_EL1 value when
> HCR_EL2.VSE injects an SError. This register is added by the
> RAS Extensions.
> 
> Changes since v3:
> (1) Move restore VSESR_EL2 value logic to a helper method
> (2) In the world-switch, not save VSESR_EL2, because no one cares the
> old VSESR_EL2 value
> (3) Add a new KVM_ARM_SEI ioctl to set the VSESR_EL2 value and pend
> a virtual system error
> 
> Signed-off-by: Dongjiu Geng 
> Signed-off-by: Quanming Wu 
> ---
>  Documentation/virtual/kvm/api.txt| 10 ++
>  arch/arm/include/asm/kvm_host.h  |  1 +
>  arch/arm/kvm/arm.c   |  6 ++
>  arch/arm/kvm/guest.c |  5 +
>  arch/arm64/include/asm/esr.h |  2 ++
>  arch/arm64/include/asm/kvm_emulate.h | 10 ++
>  arch/arm64/include/asm/kvm_host.h|  2 ++
>  arch/arm64/include/asm/sysreg.h  |  3 +++
>  arch/arm64/kvm/guest.c   | 14 ++
>  arch/arm64/kvm/handle_exit.c | 25 +++--
>  arch/arm64/kvm/hyp/switch.c  | 14 ++
>  include/uapi/linux/kvm.h |  8 
>  12 files changed, 94 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/virtual/kvm/api.txt 
> b/Documentation/virtual/kvm/api.txt
> index 3c248f7..852ac55 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -3377,6 +3377,16 @@ struct kvm_ppc_resize_hpt {
>   __u32 pad;
>  };
>  
> +4.104 KVM_ARM_SEI
> +
> +Capability: KVM_EXIT_SERROR_INTR
> +Architectures: arm/arm64
> +Type: vcpu ioctl
> +Parameters: u64 (syndrome)
> +Returns: 0 in case of success
> +
> +Pend an virtual system error or asynchronous abort with user space specified.
> +
>  5. The kvm_run structure
>  
>  
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 31ee468..566292a 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -244,6 +244,7 @@ int kvm_arm_coproc_set_reg(struct kvm_vcpu *vcpu, const 
> struct kvm_one_reg *);
>  
>  int handle_exit(struct kvm_vcpu *vcpu, struct kvm_run *run,
>   int exception_index);
> +int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
>  
>  static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
>  unsigned long hyp_stack_ptr,
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 96dba7c..2622501 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -987,6 +987,12 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
>   return -EFAULT;
>   return kvm_arm_vcpu_has_attr(vcpu, );
>   }
> + case KVM_ARM_SEI: {
> + u64 syndrome;
> + if (copy_from_user(, argp, sizeof(syndrome)))
> + return -EFAULT;
> + return kvm_vcpu_ioctl_sei(vcpu, );
> + }
>   default:
>   return -EINVAL;
>   }
> diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
> index fa6182a..a610f8f 100644
> --- a/arch/arm/kvm/guest.c
> +++ b/arch/arm/kvm/guest.c
> @@ -248,6 +248,11 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>   return -EINVAL;
>  }
>  
> +int kvm_vcpu_ioctl_sei(struct kvm_vcpu *vcpu, u64 *syndrome);
> +{
> + return 0;
> +}
> +
>  int __attribute_const__ kvm_target_cpu(void)
>  {
>   switch (read_cpuid_part()) {
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index 22f9c90..d009c99 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -127,6 +127,8 @@
>  #define ESR_ELx_WFx_ISS_WFE  (UL(1) << 0)
>  #define ESR_ELx_xVC_IMM_MASK ((1UL << 16) - 1)
>  
> +#define VSESR_ELx_IDS_ISS_MASK((1UL << 25) - 1)
> +
>  /* ESR value templates for specific events */
>  
>  /* BRK instruction trap from AArch64 state */
> diff --git a/arch/arm64/include/asm/kvm_emulate.h 
> b/arch/arm64/include/asm/kvm_emulate.h
> index f5ea0ba..a3259a9 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -148,6 +148,16 @@ static inline u32 kvm_vcpu_get_hsr(const struct kvm_vcpu 
> *vcpu)
>   return vcpu->arch.fault.esr_el2;
>  }
>  
> +static inline u32 kvm_vcpu_get_vsesr(const struct kvm_vcpu *vcpu)
> +{
> + return