RE: [PATCH] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

2016-05-02 Thread Tian, Kevin
> From: Yongji Xie [mailto:xyj...@linux.vnet.ibm.com] > Sent: Tuesday, May 03, 2016 1:52 PM > > >> + > >> + if (!(res->start & ~PAGE_MASK)) { > >> + /* > >> + * Add shadow resource for sub-page bar whose mmio > >> + * page is exclusive

Re: [PATCH] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

2016-05-02 Thread Yongji Xie
On 2016/5/3 10:59, Tian, Kevin wrote: From: Yongji Xie Sent: Wednesday, April 27, 2016 8:22 PM Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio page may be shared with other BARs. This will cause some performance issues when we pass

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

2016-05-02 Thread Pratyush Anand
Hi Baoquan, On 03/05/2016:12:24:41 PM, Baoquan He wrote: > Hi Pratyush, > > Could you please help tell why arm PAE kernel can be put above 4G? PAE system can have physical addresses above 4G. So, if a CPU is supporting the LPAE page table format then we should be able to access physical addresse

Re: [PATCH 10/12] kexec: arrange for paddr_vmcoreinfo_note() to return phys_addr_t

2016-05-02 Thread Baoquan He
This patch is clearly related to kdump. The prefix of subject should be changed to kdump. Kexec doesn't need to handle vmcore things. And patches realted to kexec/kdump should be CCed to Andrew, he usually picks up and add them into akpm tree. Hi Pratyush, Could you please help tell why arm PAE

[PATCH 0/2] Add binding rule *any* support for USB Gadget Configfs

2016-05-02 Thread changbin . du
From: "Du, Changbin" When I am configuring Gadget Configfs, I need found a exactly UDC name before I can start my gadget. But, really I doesn't care about which UDC name is used, because I have only controller. "any" is a good option. Du, Changbin (2): usb: configfs: allow UDC binding rule con

[PATCH 2/2] Documentation: gadget_configfs: update UDC binding

2016-05-02 Thread changbin . du
From: "Du, Changbin" Add the usage of new binding mode 'any'. $ echo any > UDC Signed-off-by: Du, Changbin Signed-off-by: Du, Changbin --- Documentation/usb/gadget_configfs.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/usb/gadget_configfs.txt b/D

[PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC

2016-05-02 Thread changbin . du
From: "Du, Changbin" On most platforms, there is only one device controller available. In this case, we desn't care the UDC's name. So let's ignore the name by setting 'UDC' to 'any'. And also we can change UDC name at any time if it is not binded (no need set to "" first). Signed-off-by: Du, Ch

RE: [PATCH] vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive

2016-05-02 Thread Tian, Kevin
> From: Yongji Xie > Sent: Wednesday, April 27, 2016 8:22 PM > > Current vfio-pci implementation disallows to mmap > sub-page(size < PAGE_SIZE) MMIO BARs because these BARs' mmio > page may be shared with other BARs. This will cause some > performance issues when we passthrough a PCI device with >

Re: [PATCH v2 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

2016-05-02 Thread Dave Hansen
On 05/02/2016 02:41 PM, Thomas Garnier wrote: > -#define __PAGE_OFFSET _AC(0x8800, UL) > +#define __PAGE_OFFSET_BASE _AC(0x8800, UL) > +#ifdef CONFIG_RANDOMIZE_MEMORY > +#define __PAGE_OFFSET page_offset_base > +#else > +#define __PAGE_OFFSET

Re: [PATCH v2 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

2016-05-02 Thread Dave Hansen
On 05/02/2016 02:41 PM, Thomas Garnier wrote: > Minor change that allows early boot physical mapping of PUD level virtual > addresses. This change prepares usage of different virtual addresses for > KASLR memory randomization. It has no impact on default usage. ... > diff --git a/arch/x86/mm/init_6

Re: [PATCH v2] drm/docs: Move "scaling mode" property.

2016-05-02 Thread Daniel Vetter
On Mon, May 02, 2016 at 03:13:01PM -0400, robert.f...@collabora.com wrote: > From: Robert Foss > > The "scaling mode" property has been moved to the DRM->Generic. > It has also had a list of supported drivers added to it. > > Reviewed-by: Alex Deucher > Signed-off-by: Robert Foss Applied to d

[PATCH v2 1/4] x86, boot: Refactor KASLR entropy functions

2016-05-02 Thread Thomas Garnier
Move the KASLR entropy functions in x86/libray to be used in early kernel boot for KASLR memory randomization. Signed-off-by: Thomas Garnier --- Based on next-20160502 --- arch/x86/boot/compressed/kaslr.c | 76 +++--- arch/x86/include/asm/kaslr.h | 6

[PATCH v2 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

2016-05-02 Thread Thomas Garnier
CONFIG_MEMORY_HOTPLUG is not used, no space is reserved increasing the entropy available. Signed-off-by: Thomas Garnier --- Based on next-20160502 --- arch/x86/Kconfig| 15 +++ arch/x86/mm/kaslr.c | 14 -- 2 files changed, 27 insertions(+), 2 deletions(-) diff --git a/arch/x86/Kconfig

[PATCH v2 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

2016-05-02 Thread Thomas Garnier
splay each section. Updated documentation on x86_64 memory layout accordingly. Signed-off-by: Thomas Garnier --- Based on next-20160502 --- Documentation/x86/x86_64/mm.txt | 4 + arch/x86/Kconfig| 15 arch/x86/include/asm/kaslr.h| 12 +++ ar

[PATCH v2 2/4] x86, boot: PUD VA support for physical mapping (x86_64)

2016-05-02 Thread Thomas Garnier
Minor change that allows early boot physical mapping of PUD level virtual addresses. This change prepares usage of different virtual addresses for KASLR memory randomization. It has no impact on default usage. Signed-off-by: Thomas Garnier --- Based on next-20160502 --- arch/x86/mm/init_64.c

[PATCH v2 0/4] x86, boot: KASLR memory implementation

2016-05-02 Thread Thomas Garnier
This is PATCH v2 for KASLR memory implementation for x86_64. Edit commit based on recents testing against the KASLR bypass exploits & rebase on next-20160502. ***Background: The current implementation of KASLR randomizes only the base address of the kernel and its modules. Research was publi

Re: [PATCH v5 0/1] ARM64: ACPI: Update documentation for latest specification version

2016-05-02 Thread Al Stone
On 04/25/2016 03:21 PM, Al Stone wrote: > The ACPI 6.1 specification was recently released at the end of January > 2016, but the arm64 kernel documentation for the use of ACPI was written > for the 5.1 version of the spec. There were significant additions to the > spec that had not yet been mentio

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

2016-05-02 Thread Antti Palosaari
On 04/29/2016 12:16 PM, Peter Rosin wrote: On 2016-04-29 09:16, Wolfram Sang wrote: Yes, obviously... I'll make that change locally and wait for the rest. Another nit: You could use '--strict' with checkpatch and see if you want to fix the issues reported. I am not keen on those (except for 'sp

[PATCH v2] drm/docs: Move "scaling mode" property.

2016-05-02 Thread robert . foss
From: Robert Foss The "scaling mode" property has been moved to the DRM->Generic. It has also had a list of supported drivers added to it. Reviewed-by: Alex Deucher Signed-off-by: Robert Foss --- Changes since v1: - Added Reviewed-by: Alex Deucher Documentation/DocBook/gpu.tmpl | 22

Re: [RFC PATCH v1 00/18] x86: Secure Memory Encryption (AMD)

2016-05-02 Thread Andy Lutomirski
On Wed, Apr 27, 2016 at 1:10 PM, Tom Lendacky wrote: > On 04/27/2016 09:39 AM, Andy Lutomirski wrote: >> On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky >> wrote: >>> This RFC patch series provides support for AMD's new Secure Memory >>> Encryption (SME) feature. >>> >>> SME can be used to mark in

[PATCH] drm/docs: Move "scaling mode" property.

2016-05-02 Thread robert . foss
From: Robert Foss The "scaling mode" property has been moved to the DRM->Generic. It has also had a list of supported drivers added to it. Signed-off-by: Robert Foss --- Documentation/DocBook/gpu.tmpl | 22 ++ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/

RE: [PATCH] drm/docs: Move "scaling mode" property.

2016-05-02 Thread Deucher, Alexander
> -Original Message- > From: robert.f...@collabora.com [mailto:robert.f...@collabora.com] > Sent: Monday, May 02, 2016 11:41 AM > To: daniel.vet...@ffwll.ch; cor...@lwn.net; lu...@wunner.de; > tred...@nvidia.com; Deucher, Alexander; dh.herrm...@gmail.com; > graham.wha...@linux.intel.com; ja

Re: [PATCH 0/6] Intel Secure Guard Extensions

2016-05-02 Thread Austin S. Hemmelgarn
On 2016-04-29 16:17, Jarkko Sakkinen wrote: On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote: On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: Intel(R) SGX is a set of CPU instructions that can be used by applications to set aside private regions of code and data. The code outsid

[RESEND PATCH 2/3] rfkill: Userspace control for airplane mode

2016-05-02 Thread João Paulo Rechi Vita
From: João Paulo Rechi Vita Provide an interface for the airplane-mode indicator be controlled from userspace. User has to first acquire the control through RFKILL_OP_AIRPLANE_MODE_INDICATOR_ACQUIRE and keep the fd open for the whole time it wants to be in control of the indicator. Closing the fd

[RESEND PATCH 3/3] rfkill: Notify userspace of airplane-mode state changes

2016-05-02 Thread João Paulo Rechi Vita
From: João Paulo Rechi Vita Signed-off-by: João Paulo Rechi Vita --- Documentation/rfkill.txt| 3 +++ include/uapi/linux/rfkill.h | 4 ++-- net/rfkill/core.c | 13 + 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/Documentation/rfkill.txt b/Documentat

[RESEND PATCH 1/3] rfkill: Create "rfkill-airplane-mode" LED trigger

2016-05-02 Thread João Paulo Rechi Vita
From: João Paulo Rechi Vita This creates a new LED trigger to be used by platform drivers as a default trigger for airplane-mode indicator LEDs. By default this trigger will fire when RFKILL_OP_CHANGE_ALL is called for all types (RFKILL_TYPE_ALL), setting the LED brightness to LED_FULL when the

[RESEND PATCH 0/3] RFKill airplane-mode indicator

2016-05-02 Thread João Paulo Rechi Vita
This series implements an airplane-mode indicator LED trigger, which can be used by platform drivers. By default the trigger fires on RFKILL_OP_CHANGE_ALL, but this policy can be overwritten by userspace using the new operations _AIRPLANE_MODE_INDICATOR_ACQUIRE and _AIRPLANE_MODE_INDICATOR_CHANGE.

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

2016-05-02 Thread Pratyush Anand
On Mon, May 2, 2016 at 3:40 PM, Russell King - ARM Linux wrote: > On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote: >> On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux >> wrote: >> > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote: >> >> On Fri, Apr 29, 2016

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

2016-05-02 Thread Russell King - ARM Linux
On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote: > On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux > wrote: > > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote: > >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux > >> wrote: > >> > On Fri, Apr 2

Re: [PATCH 06/12] ARM: kexec: advertise location of bootable RAM

2016-05-02 Thread Pratyush Anand
On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux wrote: > On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote: >> On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux >> wrote: >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote: >> >> Hi Russell, >> >> >