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 in case that hot-add device's
> >> +   * bar is assigned into the mem hole.
> >> +   */
> >> +  shadow_res = kzalloc(sizeof(*shadow_res), GFP_KERNEL);
> >> +  shadow_res->resource.start = res->end + 1;
> >> +  shadow_res->resource.end = res->start + PAGE_SIZE - 1;
> > What about res->start not page aligned so you end up still having
> > a portion before res->start not exclusively reserved?
> 
> Do you mean add a 'dummy' resource to reserve the portion
> before res->start if res->start not page aligned?
> 
> But would it happen that there is a mem hole in the portion
> before res->start? The resource should have been assigned
> into the hole at the beginning.
> 

Just a quick thought. Another device might occupy that range 
before initializing this device, and then 'another device' is hot
removed later... 

Thanks
Kevin

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 passthrough a PCI device with
this kind of BARs. Guest will be not able to handle the mmio
accesses to the BARs which leads to mmio emulations in host.

However, not all sub-page BARs will share page with other BARs.
We should allow to mmap those sub-page MMIO BARs which we can
make sure will not share page with other BARs.

This patch adds support for this case. And we also try to use
shadow resource to reserve the remaind of the page which hot-add
device's BAR might be assigned into.

'shadow' usually means you have a corresponding part being
shadowed, while here looks you mostly want some 'dummy'
resource for reservation purpose?


Yes., 'dummy' may be better here. And I would also replace
shadow_res/shadow_resources_list with reserved_res/reserved_resources_list.


+
+   if (!(res->start & ~PAGE_MASK)) {
+   /*
+* Add shadow resource for sub-page bar whose mmio
+* page is exclusive in case that hot-add device's
+* bar is assigned into the mem hole.
+*/
+   shadow_res = kzalloc(sizeof(*shadow_res), GFP_KERNEL);
+   shadow_res->resource.start = res->end + 1;
+   shadow_res->resource.end = res->start + PAGE_SIZE - 1;

What about res->start not page aligned so you end up still having
a portion before res->start not exclusively reserved?


Do you mean add a 'dummy' resource to reserve the portion
before res->start if res->start not page aligned?

But would it happen that there is a mem hole in the portion
before res->start? The resource should have been assigned
into the hole at the beginning.

Thanks,
Yongji


+   shadow_res->resource.flags = res->flags;
+   if (request_resource(res->parent,
+   &shadow_res->resource)) {
+   kfree(shadow_res);
+   return false;
+   }
+   shadow_res->index = index;
+   list_add(&shadow_res->res_next,
+   &vdev->shadow_resources_list);
+   return true;

Thanks
Kevin
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
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 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 addresses
beyond 4G.

> Since the change is related to common code, I am curious about how
> it's so different with other ARCHs.

paddr_vmcoreinfo_note() returns a physical address, so returning phys_addr_t
seems most appropriate. So, kernel variable may land into above 4G locations,
even with the platform in other architecture (with PAE support), if start of RAM
is located very high,

So, in my opinion it would be safer to have these changes for other ARCHs as
well.

~Pratyush
--
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 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 kernel can be put above 4G?
Since the change is related to common code, I am curious about how
it's so different with other ARCHs.

Thanks
Baoquan


On 04/29/16 at 09:17pm, Pratyush Anand wrote:
> On Fri, Apr 29, 2016 at 8:46 PM, Mark Rutland  wrote:
> > On Fri, Apr 29, 2016 at 08:36:43PM +0530, Pratyush Anand wrote:
> >> > +   phys_addr_t vmcore_base = paddr_vmcoreinfo_note();
> >> > +   return sprintf(buf, "%pa %x\n", &vmcore_base,
> >>
> >> Why do we pass &vmcore_base? Shouldn't it be vmcore_base?
> >
> > The %pa* printk format specifiers take the value by reference (as
> > phys_addr_t and friends are not necessarily the same width as a
> > pointer). Per Documentation/printk-formats.txt:
> >
> > Physical addresses types phys_addr_t:
> >
> > %pa[p]  0x01234567 or 0x0123456789abcdef
> >
> > For printing a phys_addr_t type (and its derivatives, such as
> > resource_size_t) which can vary based on build options, regardless 
> > of
> > the width of the CPU data path. Passed by reference.
> >
> > So the above prints the value of vmcore_base as expected.
> 
> Thanks a lot Mark for explaining :-)
> 
> Reviewed-by: Pratyush Anand 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
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 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 configured as binding to *any*
UDC
  Documentation: gadget_configfs: update UDC binding

 Documentation/usb/gadget_configfs.txt |  6 --
 drivers/usb/gadget/configfs.c | 22 ++
 2 files changed, 18 insertions(+), 10 deletions(-)

-- 
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

[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/Documentation/usb/gadget_configfs.txt
index 635e574..1edeb4f 100644
--- a/Documentation/usb/gadget_configfs.txt
+++ b/Documentation/usb/gadget_configfs.txt
@@ -205,11 +205,13 @@ In order to enable the gadget it must be bound to a UDC 
(USB Device Controller).
 
 $ echo  > UDC
 
-where  is one of those found in /sys/class/udc/*
+where  is one of those found in /sys/class/udc/* or "any" if you
+doesn't care about which controller to bind.
 e.g.:
 
 $ echo s3c-hsotg > UDC
-
+or
+$ echo any > UDC
 
 6. Disabling the gadget
 ---
-- 
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

[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, Changbin 
Signed-off-by: Du, Changbin 
---
 drivers/usb/gadget/configfs.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index b6f60ca..5da2991 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -230,16 +230,18 @@ static ssize_t gadget_dev_desc_bcdUSB_store(struct 
config_item *item,
 
 static ssize_t gadget_dev_desc_UDC_show(struct config_item *item, char *page)
 {
-   char *udc_name = to_gadget_info(item)->composite.gadget_driver.udc_name;
+   struct gadget_info *gi = to_gadget_info(item);
+   char *udc_name = gi->composite.gadget_driver.udc_name;
 
-   return sprintf(page, "%s\n", udc_name ?: "");
+   return sprintf(page, "%s\n", udc_name ?:
+   (gi->cdev.gadget ? "any" : ""));
 }
 
 static int unregister_gadget(struct gadget_info *gi)
 {
int ret;
 
-   if (!gi->composite.gadget_driver.udc_name)
+   if (!gi->cdev.gadget)
return -ENODEV;
 
ret = usb_gadget_unregister_driver(&gi->composite.gadget_driver);
@@ -270,10 +272,14 @@ static ssize_t gadget_dev_desc_UDC_store(struct 
config_item *item,
if (ret)
goto err;
} else {
-   if (gi->composite.gadget_driver.udc_name) {
+   if (gi->cdev.gadget) {
ret = -EBUSY;
goto err;
}
+   if (!strcmp(name, "any")) {
+   kfree(name);
+   name = NULL;
+   }
gi->composite.gadget_driver.udc_name = name;
ret = usb_gadget_probe_driver(&gi->composite.gadget_driver);
if (ret) {
@@ -428,9 +434,9 @@ static int config_usb_cfg_unlink(
 * remove the function.
 */
mutex_lock(&gi->lock);
-   if (gi->composite.gadget_driver.udc_name)
+   if (gi->cdev.gadget)
unregister_gadget(gi);
-   WARN_ON(gi->composite.gadget_driver.udc_name);
+   WARN_ON(gi->cdev.gadget);
 
list_for_each_entry(f, &cfg->func_list, list) {
if (f->fi == fi) {
@@ -873,10 +879,10 @@ static int os_desc_unlink(struct config_item *os_desc_ci,
struct usb_composite_dev *cdev = &gi->cdev;
 
mutex_lock(&gi->lock);
-   if (gi->composite.gadget_driver.udc_name)
+   if (gi->cdev.gadget)
unregister_gadget(gi);
cdev->os_desc_config = NULL;
-   WARN_ON(gi->composite.gadget_driver.udc_name);
+   WARN_ON(gi->cdev.gadget);
mutex_unlock(&gi->lock);
return 0;
 }
-- 
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] 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
> this kind of BARs. Guest will be not able to handle the mmio
> accesses to the BARs which leads to mmio emulations in host.
> 
> However, not all sub-page BARs will share page with other BARs.
> We should allow to mmap those sub-page MMIO BARs which we can
> make sure will not share page with other BARs.
> 
> This patch adds support for this case. And we also try to use
> shadow resource to reserve the remaind of the page which hot-add
> device's BAR might be assigned into.

'shadow' usually means you have a corresponding part being
shadowed, while here looks you mostly want some 'dummy'
resource for reservation purpose?

> +
> + if (!(res->start & ~PAGE_MASK)) {
> + /*
> +  * Add shadow resource for sub-page bar whose mmio
> +  * page is exclusive in case that hot-add device's
> +  * bar is assigned into the mem hole.
> +  */
> + shadow_res = kzalloc(sizeof(*shadow_res), GFP_KERNEL);
> + shadow_res->resource.start = res->end + 1;
> + shadow_res->resource.end = res->start + PAGE_SIZE - 1;

What about res->start not page aligned so you end up still having 
a portion before res->start not exclusively reserved?

> + shadow_res->resource.flags = res->flags;
> + if (request_resource(res->parent,
> + &shadow_res->resource)) {
> + kfree(shadow_res);
> + return false;
> + }
> + shadow_res->index = index;
> + list_add(&shadow_res->res_next,
> + &vdev->shadow_resources_list);
> + return true;

Thanks
Kevin
--
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 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   __PAGE_OFFSET_BASE
> +#endif /* CONFIG_RANDOMIZE_MEMORY */

Do you have any data about the performance impact of this change?  It's
not necessary to have it to merge something like this, I'm just curious
how bad it is.
--
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 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_64.c b/arch/x86/mm/init_64.c
> index 89d9747..6adfbce 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -526,10 +526,10 @@ phys_pud_init(pud_t *pud_page, unsigned long addr, 
> unsigned long end,
>  {
>   unsigned long pages = 0, next;
>   unsigned long last_map_addr = end;
> - int i = pud_index(addr);
> + int i = pud_index((unsigned long)__va(addr));
>  
>   for (; i < PTRS_PER_PUD; i++, addr = next) {
> - pud_t *pud = pud_page + pud_index(addr);
> + pud_t *pud = pud_page + pud_index((unsigned long)__va(addr));
>   pmd_t *pmd;
>   pgprot_t prot = PAGE_KERNEL;

pud_index() is supposed to take a virtual address.  We were passing a
physical address in here, and it all just worked because PAGE_OFFSET is
PUD-aligned.  Now that you are moving PAGE_OFFSET around a bit and not
PUD-aligning it, this breaks.  Right?

Could you spell this out a bit more the changelog?
--
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] 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 drm-misc, thanks.
-Daniel

> ---
> Changes since v1:
> - Added Reviewed-by: Alex Deucher 
> 
> Documentation/DocBook/gpu.tmpl | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 1692c4d..da58702 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1817,7 +1817,7 @@ void intel_crt_init(struct drm_device *dev)
>   
>   
>   DRM
> - Generic
> + Generic
>   “rotation”
>   BITMASK
>   { 0, "rotate-0" },
> @@ -1832,6 +1832,13 @@ void intel_crt_init(struct drm_device *dev)
>   image along the specified axis prior to rotation
>   
>   
> + “scaling mode”
> + ENUM
> + { "None", "Full", "Center", "Full aspect" }
> + Connector
> + Supported by: amdgpu, gma500, i915, nouveau and 
> radeon.
> + 
> + 
>   Connector
>   “EDID”
>   BLOB | IMMUTABLE
> @@ -2068,21 +2075,12 @@ void intel_crt_init(struct drm_device *dev)
>   property to suggest an Y offset for a connector
>   
>   
> - Optional
> - “scaling mode”
> - ENUM
> - { "None", "Full", "Center", "Full aspect" }
> - Connector
> - TBD
> - 
> - 
> + Optional
>   "aspect ratio"
>   ENUM
>   { "None", "4:3", "16:9" }
>   Connector
> - DRM property to set aspect ratio from user space app.
> - This enum is made generic to allow addition of custom aspect
> - ratios.
> + TDB
>   
>   
>   “dirty”
> -- 
> 2.5.0
> 

-- 
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

[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 +++
 arch/x86/lib/Makefile|  1 +
 arch/x86/lib/kaslr.c | 79 
 4 files changed, 91 insertions(+), 71 deletions(-)
 create mode 100644 arch/x86/include/asm/kaslr.h
 create mode 100644 arch/x86/lib/kaslr.c

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 8741a6d..0bdee23 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -11,10 +11,6 @@
  */
 #include "misc.h"
 
-#include 
-#include 
-#include 
-
 #include 
 #include 
 #include 
@@ -25,26 +21,6 @@
 static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
 
-#define I8254_PORT_CONTROL 0x43
-#define I8254_PORT_COUNTER00x40
-#define I8254_CMD_READBACK 0xC0
-#define I8254_SELECT_COUNTER0  0x02
-#define I8254_STATUS_NOTREADY  0x40
-static inline u16 i8254(void)
-{
-   u16 status, timer;
-
-   do {
-   outb(I8254_PORT_CONTROL,
-I8254_CMD_READBACK | I8254_SELECT_COUNTER0);
-   status = inb(I8254_PORT_COUNTER0);
-   timer  = inb(I8254_PORT_COUNTER0);
-   timer |= inb(I8254_PORT_COUNTER0) << 8;
-   } while (status & I8254_STATUS_NOTREADY);
-
-   return timer;
-}
-
 static unsigned long rotate_xor(unsigned long hash, const void *area,
size_t size)
 {
@@ -61,7 +37,7 @@ static unsigned long rotate_xor(unsigned long hash, const 
void *area,
 }
 
 /* Attempt to create a simple but unpredictable starting entropy. */
-static unsigned long get_random_boot(void)
+static unsigned long get_boot_seed(void)
 {
unsigned long hash = 0;
 
@@ -71,50 +47,6 @@ static unsigned long get_random_boot(void)
return hash;
 }
 
-static unsigned long get_random_long(void)
-{
-#ifdef CONFIG_X86_64
-   const unsigned long mix_const = 0x5d6008cbf3848dd3UL;
-#else
-   const unsigned long mix_const = 0x3f39e593UL;
-#endif
-   unsigned long raw, random = get_random_boot();
-   bool use_i8254 = true;
-
-   debug_putstr("KASLR using");
-
-   if (has_cpuflag(X86_FEATURE_RDRAND)) {
-   debug_putstr(" RDRAND");
-   if (rdrand_long(&raw)) {
-   random ^= raw;
-   use_i8254 = false;
-   }
-   }
-
-   if (has_cpuflag(X86_FEATURE_TSC)) {
-   debug_putstr(" RDTSC");
-   raw = rdtsc();
-
-   random ^= raw;
-   use_i8254 = false;
-   }
-
-   if (use_i8254) {
-   debug_putstr(" i8254");
-   random ^= i8254();
-   }
-
-   /* Circular multiply for better bit diffusion */
-   asm("mul %3"
-   : "=a" (random), "=d" (raw)
-   : "a" (random), "rm" (mix_const));
-   random += raw;
-
-   debug_putstr("...\n");
-
-   return random;
-}
-
 struct mem_vector {
unsigned long start;
unsigned long size;
@@ -122,7 +54,6 @@ struct mem_vector {
 
 #define MEM_AVOID_MAX 5
 static struct mem_vector mem_avoid[MEM_AVOID_MAX];
-
 static bool mem_contains(struct mem_vector *region, struct mem_vector *item)
 {
/* Item at least partially before region. */
@@ -229,13 +160,16 @@ static void slots_append(unsigned long addr)
slots[slot_max++] = addr;
 }
 
+#define KASLR_COMPRESSED_BOOT
+#include "../../lib/kaslr.c"
+
 static unsigned long slots_fetch_random(void)
 {
/* Handle case of no slots stored. */
if (slot_max == 0)
return 0;
 
-   return slots[get_random_long() % slot_max];
+   return slots[kaslr_get_random_boot_long() % slot_max];
 }
 
 static void process_e820_entry(struct e820entry *entry,
diff --git a/arch/x86/include/asm/kaslr.h b/arch/x86/include/asm/kaslr.h
new file mode 100644
index 000..2ae1429
--- /dev/null
+++ b/arch/x86/include/asm/kaslr.h
@@ -0,0 +1,6 @@
+#ifndef _ASM_KASLR_H_
+#define _ASM_KASLR_H_
+
+unsigned long kaslr_get_random_boot_long(void);
+
+#endif
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 72a5767..cfa6d07 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -24,6 +24,7 @@ lib-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o
 lib-y += memcpy_$(BITS).o
 lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
 lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o
+lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
 
 obj-y += msr.o msr-reg.o msr-reg-export.o
 
diff

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

2016-05-02 Thread Thomas Garnier 
Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define
the padding used for the physical memory mapping section when KASLR
memory is enabled. It ensures there is enough virtual address space when
CONFIG_MEMORY_HOTPLUG is used. The default value is 10 terabytes. If
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 b/arch/x86/Kconfig
index 60f33c7..5124d9c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2003,6 +2003,21 @@ config RANDOMIZE_MEMORY
 
   If unsure, say N.
 
+config RANDOMIZE_MEMORY_PHYSICAL_PADDING
+   hex "Physical memory mapping padding" if EXPERT
+   depends on RANDOMIZE_MEMORY
+   default "0xa" if MEMORY_HOTPLUG
+   default "0x0"
+   range 0x1 0x40 if MEMORY_HOTPLUG
+   range 0x0 0x40
+   ---help---
+  Define the padding in terabyte added to the existing physical memory
+  size during kernel memory randomization. It is useful for memory
+  hotplug support but reduces the entropy available for address
+  randomization.
+
+  If unsure, leave at the default value.
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 3b330a9..ef3dc19 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -68,15 +68,25 @@ void __init kernel_randomize_memory(void)
 {
size_t i;
unsigned long addr = memory_rand_start;
-   unsigned long padding, rand, mem_tb;
+   unsigned long padding, rand, mem_tb, page_offset_padding;
struct rnd_state rnd_st;
unsigned long remain_padding = memory_rand_end - memory_rand_start;
 
if (!kaslr_enabled())
return;
 
+   /*
+* Update Physical memory mapping to available and
+* add padding if needed (especially for memory hotplug support).
+*/
+   page_offset_padding = CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
+
+#ifdef CONFIG_MEMORY_HOTPLUG
+   page_offset_padding = max(1UL, page_offset_padding);
+#endif
+
BUG_ON(kaslr_regions[0].base != &page_offset_base);
-   mem_tb = ((max_pfn << PAGE_SHIFT) >> TB_SHIFT);
+   mem_tb = ((max_pfn << PAGE_SHIFT) >> TB_SHIFT) + page_offset_padding;
 
if (mem_tb < kaslr_regions[0].size_tb)
kaslr_regions[0].size_tb = mem_tb;
-- 
2.8.0.rc3.226.g39d4020

--
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 v2 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

2016-05-02 Thread Thomas Garnier 
Randomizes the virtual address space of kernel memory sections (physical
memory mapping, vmalloc & vmemmap) for x86_64. This security feature
mitigates exploits relying on predictable kernel addresses. These
addresses can be used to disclose the kernel modules base addresses or
corrupt specific structures to elevate privileges bypassing the current
implementation of KASLR. This feature can be enabled with the
CONFIG_RANDOMIZE_MEMORY option.

The physical memory mapping holds most allocations from boot and heap
allocators. Knowning the base address and physical memory size, an
attacker can deduce the PDE virtual address for the vDSO memory page.
This attack was demonstrated at CanSecWest 2016, in the "Getting
Physical Extreme Abuse of Intel Based Paged Systems"
https://goo.gl/ANpWdV (see second part of the presentation). The
exploits used against Linux worked successfuly against 4.6+ but fail
with KASLR memory enabled (https://goo.gl/iTtXMJ). Similar research
was done at Google leading to this patch proposal. Variants exists to
overwrite /proc or /sys objects ACLs leading to elevation of privileges.
These variants were testeda against 4.6+.

The vmalloc memory section contains the allocation made through the
vmalloc api. The allocations are done sequentially to prevent
fragmentation and each allocation address can easily be deduced
especially from boot.

The vmemmap section holds a representation of the physical
memory (through a struct page array). An attacker could use this section
to disclose the kernel memory layout (walking the page linked list).

The order of each memory section is not changed. The feature looks at
the available space for the sections based on different configuration
options and randomizes the base and space between each. The size of the
physical memory mapping is the available physical memory. No performance
impact was detected while testing the feature.

Entropy is generated using the KASLR early boot functions now shared in
the lib directory (originally written by Kees Cook). Randomization is
done on PGD & PUD page table levels to increase possible addresses. The
physical memory mapping code was adapted to support PUD level virtual
addresses. An additional low memory page is used to ensure each CPU can
start with a PGD aligned virtual address (for realmode).

x86/dump_pagetable was updated to correctly display 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 +++
 arch/x86/include/asm/page_64_types.h|  11 ++-
 arch/x86/include/asm/pgtable_64.h   |   1 +
 arch/x86/include/asm/pgtable_64_types.h |  15 +++-
 arch/x86/kernel/head_64.S   |   2 +-
 arch/x86/kernel/setup.c |   3 +
 arch/x86/mm/Makefile|   1 +
 arch/x86/mm/dump_pagetables.c   |  11 ++-
 arch/x86/mm/init.c  |   4 +
 arch/x86/mm/kaslr.c | 136 
 arch/x86/realmode/init.c|   4 +
 13 files changed, 211 insertions(+), 8 deletions(-)
 create mode 100644 arch/x86/mm/kaslr.c

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 5aa7383..602a52d 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -39,4 +39,8 @@ memory window (this size is arbitrary, it can be raised later 
if needed).
 The mappings are not part of any other kernel PGD and are only available
 during EFI runtime calls.
 
+Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
+physical memory, vmalloc/ioremap space and virtual memory map are randomized.
+Their order is preserved but their base will be changed early at boot time.
+
 -Andi Kleen, Jul 2004
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0b128b4..60f33c7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1988,6 +1988,21 @@ config PHYSICAL_ALIGN
 
  Don't change this unless you know what you are doing.
 
+config RANDOMIZE_MEMORY
+   bool "Randomize the kernel memory sections"
+   depends on X86_64
+   depends on RANDOMIZE_BASE
+   default n
+   ---help---
+  Randomizes the virtual address of memory sections (physical memory
+  mapping, vmalloc & vmemmap). This security feature mitigates exploits
+  relying on predictable memory locations.
+
+  Base and padding between memory section is randomized. Their order is
+  not. Entropy is generated in the same way as RANDOMIZE_BASE.
+
+  If unsure, say N.
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
depends on SMP
diff --git a/arch/x86/include/asm/kaslr.h b/arch/x86/include/asm/kaslr.h
index 2ae1429..12c7742 100644
--- a/arch/x86

[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 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 89d9747..6adfbce 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -526,10 +526,10 @@ phys_pud_init(pud_t *pud_page, unsigned long addr, 
unsigned long end,
 {
unsigned long pages = 0, next;
unsigned long last_map_addr = end;
-   int i = pud_index(addr);
+   int i = pud_index((unsigned long)__va(addr));
 
for (; i < PTRS_PER_PUD; i++, addr = next) {
-   pud_t *pud = pud_page + pud_index(addr);
+   pud_t *pud = pud_page + pud_index((unsigned long)__va(addr));
pmd_t *pmd;
pgprot_t prot = PAGE_KERNEL;
 
-- 
2.8.0.rc3.226.g39d4020

--
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 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 published showing that static
memory can be overwitten to elevate privileges bypassing KASLR.

In more details:

The physical memory mapping holds most allocations from boot and heap
allocators. Knowning the base address and physical memory size, an
attacker can deduce the PDE virtual address for the vDSO memory page.
This attack was demonstrated at CanSecWest 2016, in the "Getting
Physical Extreme Abuse of Intel Based Paged Systems"
https://goo.gl/ANpWdV (see second part of the presentation). Similar
research was done at Google leading to this patch proposal. Variants
exists to overwrite /proc or /sys objects ACLs leading to elevation of
privileges. These variants were tested against 4.6+.

This set of patches randomizes base address and padding of three
major memory sections (physical memory mapping, vmalloc & vmemmap).
It mitigates exploits relying on predictable kernel addresses. This
feature can be enabled with the CONFIG_RANDOMIZE_MEMORY option.

Padding for the memory hotplug support is managed by
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. The default value is 10
terabytes.

The patches were tested on qemu & physical machines. Xen compatibility was
also verified. Multiple reboots were used to verify entropy for each
memory section.

***Problems that needed solving:
 - The three target memory sections are never at the same place between
   boots.
 - The physical memory mapping can use a virtual address not aligned on
   the PGD page table.
 - Have good entropy early at boot before get_random_bytes is available.
 - Add optional padding for memory hotplug compatibility.

***Parts:
 - The first part prepares for the KASLR memory randomization by
   refactoring entropy functions used by the current implementation and
   support PUD level virtual addresses for physical mapping.
   (Patches 01-02)
 - The second part implements the KASLR memory randomization for all
   sections mentioned.
   (Patch 03)
 - The third part adds support for memory hotplug by adding an option to
   define the padding used between the physical memory mapping section
   and the others.
   (Patch 04)

Thanks!

--
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 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 mentioned -- for example, the 6.0 mechanisms
> added to make it easier to define processors and low power idle states,
> as well as the 6.1 addition allowing regular interrupts (not just from
> GPIO) be used to signal ACPI general purpose events.
> 
> This patch reflects going back through and examining the specs in detail
> and updating content appropriately.  Whilst there, a few odds and ends of
> typos were caught as well.  This brings the documentation up to date with
> ACPI 6.1 for arm64.
> 
> Changes for v5:
>-- Miscellaneous typos and corrections (Lorenzo Pieralisi)
>-- Add linux-acpi@ ML to the distribution list (Alexey Klimov)
>-- Corrections to CPPC information (Alexey Klimov)
>-- ACK from Lorenzo Pieralisi
>-- Updated bibliographic info (Al Stone)
> 
> Changes for v4:
>-- Clarify that IORT can sometimes be optional (Jon Masters).
>-- Remove "Use as needed" descriptions of ACPI objects; they provide
>   no substantive information and doing so simplifies maintenance of
>   this document over time.  These have been replaced with a simpler
>   notice that states that unless otherwise noted, do what the ACPI
>   specification says is needed.
>-- Corrected the _OSI object usage recommendation; it described kernel
>   behavior that does not exist (Al Stone).
> 
> Changes for v3:
>-- Clarify use of _LPI/_RDI (Vikas Sajjan)
>-- Whitespace cleanup as pointed out by checkpatch
> 
> Changes for v2:
>-- Clean up white space (Harb Abdulhahmid)
>-- Clarification on _CCA usage (Harb Abdulhamid)
>-- IORT moved to required from recommended (Hanjun Guo)
>-- Clarify IORT description (Hanjun Guo)
> 
> 
> Al Stone (1):
>   ARM64: ACPI: Update documentation for latest specification version
> 
>  Documentation/arm64/acpi_object_usage.txt | 343 
> --
>  Documentation/arm64/arm-acpi.txt  |  40 ++--
>  2 files changed, 213 insertions(+), 170 deletions(-)
> 

Ping?  If there are no further comments, can this be pulled in through
either the documentation or arm64 tree?

Thanks.

-- 
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
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 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
'space around operators'), it's a matter of taste I guess, but maybe you
like some of the suggestions.


Yes, they look like reasonable complaints.

So, I fixed all of them locally except the complaint about lack of comment
on the new struct mutex member in struct si2168_dev (patch 21/24),
because that patch is Anttis and he's the maintainer of that driver...

Antti, if you want that fixed as part of this series, send a suitable comment
for the mutex this way and I'll incorporate it.


Ah, I never ran checkpatch with --strict option...

CHECK: struct mutex definition without comment
#202: FILE: drivers/media/dvb-frontends/si2168_priv.h:32:
+   struct mutex i2c_mutex;

If you wish you could add some comment for it, but for me it is still 
pretty much self explaining. It is lock to protect firmware command 
execution. Command is executed always with I2C write and then poll reply 
using I2C read until it timeouts or answers with "ready" status.


regards
Antti

--
http://palosaari.fi/
--
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 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 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 1692c4d..da58702 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1817,7 +1817,7 @@ void intel_crt_init(struct drm_device *dev)


DRM
-   Generic
+   Generic
“rotation”
BITMASK
{ 0, "rotate-0" },
@@ -1832,6 +1832,13 @@ void intel_crt_init(struct drm_device *dev)
image along the specified axis prior to rotation


+   “scaling mode”
+   ENUM
+   { "None", "Full", "Center", "Full aspect" }
+   Connector
+   Supported by: amdgpu, gma500, i915, nouveau and 
radeon.
+   
+   
Connector
“EDID”
BLOB | IMMUTABLE
@@ -2068,21 +2075,12 @@ void intel_crt_init(struct drm_device *dev)
property to suggest an Y offset for a connector


-   Optional
-   “scaling mode”
-   ENUM
-   { "None", "Full", "Center", "Full aspect" }
-   Connector
-   TBD
-   
-   
+   Optional
"aspect ratio"
ENUM
{ "None", "4:3", "16:9" }
Connector
-   DRM property to set aspect ratio from user space app.
-   This enum is made generic to allow addition of custom aspect
-   ratios.
+   TDB


“dirty”
-- 
2.5.0

--
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: [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 individual pages of memory as encrypted through the
>>> page tables. A page of memory that is marked encrypted will be automatically
>>> decrypted when read from DRAM and will be automatically encrypted when
>>> written to DRAM. Details on SME can found in the links below.
>>
>> Having read through the docs briefly, some questions:
>>
>> 1. How does the crypto work?  Is it straight AES-ECB?  Is it a
>> tweakable mode?  If so, what does into the tweak?  For example, if I
>> swap the ciphertext of two pages, does the plaintext of the pages get
>> swapped?  If not, why not?
>
> The AES crypto uses a tweak such that two identical plaintexts at
> different locations will have different ciphertext. So swapping the
> ciphertext of two pages will not result in the plaintext being swapped.

OK, makes sense.

>
>>
>> 2. In SEV mode, how does the hypervisor relocate a physical backing
>> page?  Does it simple move it and update the 2nd-level page tables?
>> If so, is the result of decryption guaranteed to be garbage if it
>> relocates a page and re-inserts it at the wrong guest physical
>> address?
>
> For SEV mode, relocating a physical backing page takes extra steps.
> There are APIs that are used to have the AMD Secure Processor create a
> transportable encrypted page that can then be moved to a new location
> in memory. After moving it to the new location the APIs are used to
> haves the AMD Secure Processor re-encrypt the page for use with the
> guests SEV key. Based on #1 above, just moving a page without invoking
> the necessary APIs will result in the decryption returning garbage.
>
>>
>> 3. In SEV mode, does anything prevent the hypervisor from resuming a
>> guest with the wrong ASID, or is this all relying on the resulting
>> corruption of the guest code and data to cause a crash?
>
> There is nothing that prevents resuming a guest with the wrong ASID.
> This relies on the resulting corruption of the guest code/data to
> cause a crash.

This all seems somewhat useful, but I almost guarantee that if there
is ever anything economically important (or important for national
security reasons, or simply something that sounds fun for an
enterprising kid to break) that it *will* be broken in many creative
ways.

Someone will break it by replaying old data through the VM, either to
confuse control flow or to use some part of the VM code as an oracle
with which to attack another part.

Someone else will break it by installing a #UD / #PF handler and using
the resulting exceptions as an oracle.

A third clever person will break it by carefully constructing a
scenario in which randomizing 16 bytes of data has a high probability
of letting then pwn your system.  (For example, what if the secured VM
creates an RSA key and you can carefully interrupt it right after
generating p and q.  Replace 16 bytes from the middle of both p and q
(32 bytes total) with random garbage.  With reasonably high
probability, the resulting p and q will no longer be prime.)

Depending on how strong your ASID protection is, a fourth clever
person will break it by replacing a bunch of the VM out from under the
target while leaving the sensitive data in place and then will use
some existing exploit or design issue to gain code execution in the
modified VM.

Also, I really hope that your tweakable cipher mode is at least CCA2
secure, because attackers can absolutely hit it with adaptive chosen
ciphertext attacks.  (Actually, attackers can alternate between
adaptive chosen ciphertext and adaptive chosen plaintext.)

And did the SEV implementation remember to encrypt the guest register
state?  Because, if not, everything of importance will leak out
through the VMCB and/or GPRs.

But I guess it's better than nothing.

--Andy
--
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] 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/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 1692c4d..da58702 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1817,7 +1817,7 @@ void intel_crt_init(struct drm_device *dev)


DRM
-   Generic
+   Generic
“rotation”
BITMASK
{ 0, "rotate-0" },
@@ -1832,6 +1832,13 @@ void intel_crt_init(struct drm_device *dev)
image along the specified axis prior to rotation


+   “scaling mode”
+   ENUM
+   { "None", "Full", "Center", "Full aspect" }
+   Connector
+   Supported by: amdgpu, gma500, i915, nouveau and 
radeon.
+   
+   
Connector
“EDID”
BLOB | IMMUTABLE
@@ -2068,21 +2075,12 @@ void intel_crt_init(struct drm_device *dev)
property to suggest an Y offset for a connector


-   Optional
-   “scaling mode”
-   ENUM
-   { "None", "Full", "Center", "Full aspect" }
-   Connector
-   TBD
-   
-   
+   Optional
"aspect ratio"
ENUM
{ "None", "4:3", "16:9" }
Connector
-   DRM property to set aspect ratio from user space app.
-   This enum is made generic to allow addition of custom aspect
-   ratios.
+   TDB


“dirty”
-- 
2.5.0

--
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] 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; jani.nik...@intel.com
> Cc: linux-doc@vger.kernel.org; linux-ker...@vger.kernel.org; Robert Foss
> Subject: [PATCH] drm/docs: Move "scaling mode" property.
> 
> 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 

Reviewed-by: Alex Deucher 

> ---
>  Documentation/DocBook/gpu.tmpl | 22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/DocBook/gpu.tmpl
> b/Documentation/DocBook/gpu.tmpl
> index 1692c4d..da58702 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1817,7 +1817,7 @@ void intel_crt_init(struct drm_device *dev)
>   
>   
>   DRM
> - Generic
> + Generic
>   “rotation”
>   BITMASK
>   { 0, "rotate-0" },
> @@ -1832,6 +1832,13 @@ void intel_crt_init(struct drm_device *dev)
>   image along the specified axis prior to rotation
>   
>   
> + “scaling mode”
> + ENUM
> + { "None", "Full", "Center", "Full aspect" }
> + Connector
> + Supported by: amdgpu, gma500, i915, nouveau
> and radeon.
> + 
> + 
>   Connector
>   “EDID”
>   BLOB | IMMUTABLE
> @@ -2068,21 +2075,12 @@ void intel_crt_init(struct drm_device *dev)
>   property to suggest an Y offset for a
> connector
>   
>   
> - Optional
> - “scaling mode”
> - ENUM
> - { "None", "Full", "Center", "Full aspect" }
> - Connector
> - TBD
> - 
> - 
> + Optional
>   "aspect ratio"
>   ENUM
>   { "None", "4:3", "16:9" }
>   Connector
> - DRM property to set aspect ratio from user space
> app.
> - This enum is made generic to allow addition of custom aspect
> - ratios.
> + TDB
>   
>   
>   “dirty”
> --
> 2.5.0

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
outside the enclave is disallowed to access the memory inside the
enclave by the CPU access control.

The firmware uses PRMRR registers to reserve an area of physical memory
called Enclave Page Cache (EPC). There is a hardware unit in the
processor called Memory Encryption Engine. The MEE encrypts and decrypts
the EPC pages as they enter and leave the processor package.


What are non-evil use cases for this?


I'm not sure what you mean by non-evil.

I would think that this should be pretty straightforward.  Pretty much 
every security technology integrated in every computer in existence has 
the potential to be used by malware for various purposes.  Based on a 
cursory look at SGX, it is pretty easy to figure out how to use this to 
hide arbitrary code from virus scanners and the OS itself unless you 
have some way to force everything to be a debug enclave, which entirely 
defeats the stated purpose of the extensions.  I can see this being 
useful for tight embedded systems.  On a desktop which I have full 
control of physical access to though, it's something I'd immediately 
turn off, because the risk of misuse is so significant (I've done so on 
my new Thinkpad L560 too, although that's mostly because Linux doesn't 
support it yet).

--
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

[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
restores the default policy.

To change state of the indicator, the
RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE operation is used, passing the
value on "struct rfkill_event.soft". If the caller has not acquired the
airplane-mode control beforehand, the operation fails.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt| 10 ++
 include/uapi/linux/rfkill.h |  6 ++
 net/rfkill/core.c   | 40 ++--
 3 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index b13025a..9dbe3fc 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -87,6 +87,7 @@ RFKill provides per-switch LED triggers, which can be used to 
drive LEDs
 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
 An airplane-mode indicator LED trigger is also available, which triggers
 LED_FULL when all radios known by RFKill are blocked, and LED_OFF otherwise.
+The airplane-mode indicator LED trigger policy can be overridden by userspace.
 
 
 5. Userspace support
@@ -123,5 +124,14 @@ RFKILL_TYPE
 The contents of these variables corresponds to the "name", "state" and
 "type" sysfs files explained above.
 
+Userspace can also override the default airplane-mode indicator policy through
+/dev/rfkill. Control of the airplane mode indicator has to be acquired first,
+using RFKILL_OP_AIRPLANE_MODE_INDICATOR_ACQUIRE, and is only available for one
+userspace application at a time. Closing the fd reverts the airplane-mode
+indicator back to the default kernel policy and makes it available for other
+applications to take control. Changes to the airplane-mode indicator state can
+be made using RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE, passing the new value
+in the 'soft' field of 'struct rfkill_event'.
+
 
 For further details consult Documentation/ABI/stable/sysfs-class-rfkill.
diff --git a/include/uapi/linux/rfkill.h b/include/uapi/linux/rfkill.h
index 2e00dce..36e0770 100644
--- a/include/uapi/linux/rfkill.h
+++ b/include/uapi/linux/rfkill.h
@@ -61,12 +61,18 @@ enum rfkill_type {
  * @RFKILL_OP_CHANGE_ALL: userspace changes all devices (of a type, or all)
  * into a state, also updating the default state used for devices that
  * are hot-plugged later.
+ * @RFKILL_OP_AIRPLANE_MODE_INDICATOR_ACQUIRE: userspace acquires control of
+ * the airplane-mode indicator.
+ * @RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE: userspace changes the
+ * airplane-mode indicator state.
  */
 enum rfkill_operation {
RFKILL_OP_ADD = 0,
RFKILL_OP_DEL,
RFKILL_OP_CHANGE,
RFKILL_OP_CHANGE_ALL,
+   RFKILL_OP_AIRPLANE_MODE_INDICATOR_ACQUIRE,
+   RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE,
 };
 
 /**
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 9adf95e..95824b3 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -89,6 +89,7 @@ struct rfkill_data {
struct mutexmtx;
wait_queue_head_t   read_wait;
boolinput_handler;
+   boolis_apm_owner;
 };
 
 
@@ -123,7 +124,7 @@ static struct {
 } rfkill_global_states[NUM_RFKILL_TYPES];
 
 static bool rfkill_epo_lock_active;
-
+static bool rfkill_apm_owned;
 
 #ifdef CONFIG_RFKILL_LEDS
 static struct led_trigger rfkill_apm_led_trigger;
@@ -350,7 +351,8 @@ static void rfkill_update_global_state(enum rfkill_type 
type, bool blocked)
 
for (i = 0; i < NUM_RFKILL_TYPES; i++)
rfkill_global_states[i].cur = blocked;
-   rfkill_apm_led_trigger_event(blocked);
+   if (!rfkill_apm_owned)
+   rfkill_apm_led_trigger_event(blocked);
 }
 
 #ifdef CONFIG_RFKILL_INPUT
@@ -1174,9 +1176,23 @@ static ssize_t rfkill_fop_read(struct file *file, char 
__user *buf,
return ret;
 }
 
+static int rfkill_airplane_mode_release(struct rfkill_data *data)
+{
+   bool state = rfkill_global_states[RFKILL_TYPE_ALL].cur;
+
+   if (rfkill_apm_owned && data->is_apm_owner) {
+   rfkill_apm_owned = false;
+   data->is_apm_owner = false;
+   rfkill_apm_led_trigger_event(state);
+   return 0;
+   }
+   return -EACCES;
+}
+
 static ssize_t rfkill_fop_write(struct file *file, const char __user *buf,
size_t count, loff_t *pos)
 {
+   struct rfkill_data *data = file->private_data;
struct rfkill *rfkill;
struct rfkill_event ev;
int ret;
@@ -1216,6 +1232,25 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
rfkill_set_block(rfkill, ev.soft);

[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/Documentation/rfkill.txt
index 9dbe3fc..588b4bf 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -133,5 +133,8 @@ applications to take control. Changes to the airplane-mode 
indicator state can
 be made using RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE, passing the new value
 in the 'soft' field of 'struct rfkill_event'.
 
+This same API is also used to provide userspace with notifications of changes
+to airplane-mode indicator state.
+
 
 For further details consult Documentation/ABI/stable/sysfs-class-rfkill.
diff --git a/include/uapi/linux/rfkill.h b/include/uapi/linux/rfkill.h
index 36e0770..2ccb02f 100644
--- a/include/uapi/linux/rfkill.h
+++ b/include/uapi/linux/rfkill.h
@@ -63,8 +63,8 @@ enum rfkill_type {
  * are hot-plugged later.
  * @RFKILL_OP_AIRPLANE_MODE_INDICATOR_ACQUIRE: userspace acquires control of
  * the airplane-mode indicator.
- * @RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE: userspace changes the
- * airplane-mode indicator state.
+ * @RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE: the airplane-mode indicator state
+ * changed -- userspace changes the airplane-mode indicator state.
  */
 enum rfkill_operation {
RFKILL_OP_ADD = 0,
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 95824b3..c4bbd19 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -131,7 +131,20 @@ static struct led_trigger rfkill_apm_led_trigger;
 
 static void rfkill_apm_led_trigger_event(bool state)
 {
+   struct rfkill_data *data;
+   struct rfkill_int_event *ev;
+
led_trigger_event(&rfkill_apm_led_trigger, state ? LED_FULL : LED_OFF);
+
+   list_for_each_entry(data, &rfkill_fds, list) {
+   ev = kzalloc(sizeof(*ev), GFP_KERNEL);
+   if (!ev)
+   continue;
+   ev->ev.op = RFKILL_OP_AIRPLANE_MODE_INDICATOR_CHANGE;
+   ev->ev.soft = state;
+   list_add_tail(&ev->list, &data->events);
+   wake_up_interruptible(&data->read_wait);
+   }
 }
 
 static void rfkill_apm_led_trigger_activate(struct led_classdev *led)
-- 
2.5.0

--
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

[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 changing the state to blocked, and to LED_OFF when the changing
the state to unblocked. In the future there will be a mechanism for
userspace to override the default policy, so it can implement its own.

This trigger will be used by the asus-wireless x86 platform driver.

Signed-off-by: João Paulo Rechi Vita 
---
 Documentation/rfkill.txt |  2 ++
 net/rfkill/core.c| 49 +++-
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 1f0c270..b13025a 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -85,6 +85,8 @@ device). Don't do this unless you cannot get the event in any 
other way.
 
 RFKill provides per-switch LED triggers, which can be used to drive LEDs
 according to the switch state (LED_FULL when blocked, LED_OFF otherwise).
+An airplane-mode indicator LED trigger is also available, which triggers
+LED_FULL when all radios known by RFKill are blocked, and LED_OFF otherwise.
 
 
 5. Userspace support
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 884027f..9adf95e 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -126,6 +126,30 @@ static bool rfkill_epo_lock_active;
 
 
 #ifdef CONFIG_RFKILL_LEDS
+static struct led_trigger rfkill_apm_led_trigger;
+
+static void rfkill_apm_led_trigger_event(bool state)
+{
+   led_trigger_event(&rfkill_apm_led_trigger, state ? LED_FULL : LED_OFF);
+}
+
+static void rfkill_apm_led_trigger_activate(struct led_classdev *led)
+{
+   rfkill_apm_led_trigger_event(!rfkill_default_state);
+}
+
+static int rfkill_apm_led_trigger_register(void)
+{
+   rfkill_apm_led_trigger.name = "rfkill-airplane-mode";
+   rfkill_apm_led_trigger.activate = rfkill_apm_led_trigger_activate;
+   return led_trigger_register(&rfkill_apm_led_trigger);
+}
+
+static void rfkill_apm_led_trigger_unregister(void)
+{
+   led_trigger_unregister(&rfkill_apm_led_trigger);
+}
+
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
struct led_trigger *trigger;
@@ -177,6 +201,19 @@ static void rfkill_led_trigger_unregister(struct rfkill 
*rfkill)
led_trigger_unregister(&rfkill->led_trigger);
 }
 #else
+static void rfkill_apm_led_trigger_event(bool state)
+{
+}
+
+static int rfkill_apm_led_trigger_register(void)
+{
+   return 0;
+}
+
+static void rfkill_apm_led_trigger_unregister(void)
+{
+}
+
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
 }
@@ -313,6 +350,7 @@ static void rfkill_update_global_state(enum rfkill_type 
type, bool blocked)
 
for (i = 0; i < NUM_RFKILL_TYPES; i++)
rfkill_global_states[i].cur = blocked;
+   rfkill_apm_led_trigger_event(blocked);
 }
 
 #ifdef CONFIG_RFKILL_INPUT
@@ -1262,15 +1300,22 @@ static int __init rfkill_init(void)
 {
int error;
 
+   error = rfkill_apm_led_trigger_register();
+   if (error)
+   goto out;
+
rfkill_update_global_state(RFKILL_TYPE_ALL, !rfkill_default_state);
 
error = class_register(&rfkill_class);
-   if (error)
+   if (error) {
+   rfkill_apm_led_trigger_unregister();
goto out;
+   }
 
error = misc_register(&rfkill_miscdev);
if (error) {
class_unregister(&rfkill_class);
+   rfkill_apm_led_trigger_unregister();
goto out;
}
 
@@ -1279,6 +1324,7 @@ static int __init rfkill_init(void)
if (error) {
misc_deregister(&rfkill_miscdev);
class_unregister(&rfkill_class);
+   rfkill_apm_led_trigger_unregister();
goto out;
}
 #endif
@@ -1295,5 +1341,6 @@ static void __exit rfkill_exit(void)
 #endif
misc_deregister(&rfkill_miscdev);
class_unregister(&rfkill_class);
+   rfkill_apm_led_trigger_unregister();
 }
 module_exit(rfkill_exit);
-- 
2.5.0

--
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

[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. When the
airplane-mode indicator state changes, userspace gets notifications through the
RFKill control misc device (/dev/rfkill). I also have patches to the rfkill
userspace tool that makes use of this interface, so it can serve as API usage
example and to do quick checks on a running system, which I'll send in a
separate series.

After some hiatus I found the time to get back to this, and this time I've used
Jouni's hwsim suite to test the patches on top of mac80211-next/master. Lines
containing rfkill are pasted bellow:

START wext_rfkill 14/1880
PASS wext_rfkill 4.12 2016-04-29 12:30:23.792682
START rfkill_wpas 571/1880
PASS rfkill_wpas 1.245307 2016-04-29 12:48:51.804344
START rfkill_autogo 572/1880
PASS rfkill_autogo 1.154174 2016-04-29 12:48:52.959605
START rfkill_p2p_discovery 573/1880
PASS rfkill_p2p_discovery 0.534903 2016-04-29 12:48:53.495547
START rfkill_open 574/1880
PASS rfkill_open 0.34073 2016-04-29 12:48:53.836963
START rfkill_p2p_discovery_p2p_dev 575/1880
PASS rfkill_p2p_discovery_p2p_dev 1.159446 2016-04-29 12:48:54.997555
START rfkill_hostapd 576/1880
PASS rfkill_hostapd 3.686868 2016-04-29 12:48:58.685162
START rfkill_wpa2_psk 577/1880
PASS rfkill_wpa2_psk 0.330014 2016-04-29 12:48:59.016711

João Paulo Rechi Vita (3):
  rfkill: Create "rfkill-airplane-mode" LED trigger
  rfkill: Userspace control for airplane mode
  rfkill: Notify userspace of airplane-mode state changes

 Documentation/rfkill.txt|  15 +++
 include/uapi/linux/rfkill.h |   6 +++
 net/rfkill/core.c   | 100 +++-
 3 files changed, 119 insertions(+), 2 deletions(-)

-- 
2.5.0

--
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 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 at 11:30 PM, Russell King - ARM Linux
>> >>  wrote:
>> >> > On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
>> >> >> Hi Russell,
>> >> >>
>> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >> >>  wrote:
>> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs 
>> >> >> > to
>> >> >> > know where it can place the kernel in RAM, and so be executable when
>> >> >> > the system needs to jump into it.
>> >> >> >
>> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> >> > tag.
>> >> >> >
>> >> >> > Signed-off-by: Russell King 
>> >> >>
>> >> >> Can you please also share git tree path of corresponding kexec-tools 
>> >> >> changes?
>> >> >>
>> >> >> Could it be a better idea (if things in user space become simpler)
>> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> >> user space, and then user space manipulates existing "Crash kernel"
>> >> >> and "System RAM" resources.
>> >> >
>> >> > Given that it's only _one_ platform right now, I don't think that
>> >> > additional complexity is worth it.  It means that we have to invent
>> >>
>> >> Probably, I could not communicate it well.  I was not trying  to have
>> >> *additional* complexity. Wanted to see if things could be simpler
>> >> rather. So this is what my understanding was:
>> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> >> (say in /sys/kernel/bootmem_idmap_offset)
>> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> >> content of the series will go away.
>> >
>> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
>> > 11 and 12 are necessary to allow the boot-view addresses to be passed
>> > into the kernel through kexec, and to allow kexec to find appropriate
>> > memory resources.
>>
>> But once we would have manipulated "start" and "end" of "Crash Kernel"
>> and "System RAM" resources in user space using
>> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
>> call would have already receive boot-view addresses, no?
>
> Correct, but that's still a problem for all the reasons I gave in the
> email to which you replied to.
>
> I'm not sure where the misunderstanding is.

No, no..there is no misunderstanding. I agreed to your implementation
because that will work for generic cases and for me complete series is
OK.

I just wanted to clarify my understanding, and so was the last argument.

>
> Let me repeat: even if we do what you're suggesting, patches 11 and 12
> do *not* go away.  I've explained in detail why each of the changes are
> necessary (which you have cut from your reply.)
>

Again, it is just for clarifying myself.
I cut the reply because I understood that in patch 11 and 12, you
convert addresses passed by kexec tools from run time view to boot
view using different helpers like phys_to_boot_phys(). So, had kexec
system call passed boot view addresses, we would have not needed 11
and 12. This is what I wanted to clarify.

> In other words: exporting this offset via
> /sys/kernel/bootmem_idmap_offset is technically inferior to the solution
> I have come up with here, and it saves very little complexity and code.

I still have opinion that code will probably be more simple and reduce
significantly, however solution will siege to work the moment
idmap_offset is not a simple additive value.

Therefore, I am OK with your implementation.

~Pratyush
--
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 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 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:
> >> >> Hi Russell,
> >> >>
> >> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
> >> >>  wrote:
> >> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
> >> >> > know where it can place the kernel in RAM, and so be executable when
> >> >> > the system needs to jump into it.
> >> >> >
> >> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
> >> >> > tag.
> >> >> >
> >> >> > Signed-off-by: Russell King 
> >> >>
> >> >> Can you please also share git tree path of corresponding kexec-tools 
> >> >> changes?
> >> >>
> >> >> Could it be a better idea (if things in user space become simpler)
> >> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
> >> >> user space, and then user space manipulates existing "Crash kernel"
> >> >> and "System RAM" resources.
> >> >
> >> > Given that it's only _one_ platform right now, I don't think that
> >> > additional complexity is worth it.  It means that we have to invent
> >>
> >> Probably, I could not communicate it well.  I was not trying  to have
> >> *additional* complexity. Wanted to see if things could be simpler
> >> rather. So this is what my understanding was:
> >> -- We create one patch to pass arch_phys_to_idmap_offset to user space
> >> (say in /sys/kernel/bootmem_idmap_offset)
> >> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
> >> content of the series will go away.
> >
> > Patches 11 and 12 don't go away with what you're suggesting.  Patches
> > 11 and 12 are necessary to allow the boot-view addresses to be passed
> > into the kernel through kexec, and to allow kexec to find appropriate
> > memory resources.
> 
> But once we would have manipulated "start" and "end" of "Crash Kernel"
> and "System RAM" resources in user space using
> /sys/kernel/bootmem_idmap_offset , then kernel through kexec system
> call would have already receive boot-view addresses, no?

Correct, but that's still a problem for all the reasons I gave in the
email to which you replied to.

I'm not sure where the misunderstanding is.

Let me repeat: even if we do what you're suggesting, patches 11 and 12
do *not* go away.  I've explained in detail why each of the changes are
necessary (which you have cut from your reply.)

In other words: exporting this offset via
/sys/kernel/bootmem_idmap_offset is technically inferior to the solution
I have come up with here, and it saves very little complexity and code.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 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,
>> >>
>> >> On Thu, Apr 28, 2016 at 2:58 PM, Russell King
>> >>  wrote:
>> >> > Advertise the location of bootable RAM to kexec-tools.  kexec needs to
>> >> > know where it can place the kernel in RAM, and so be executable when
>> >> > the system needs to jump into it.
>> >> >
>> >> > Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
>> >> > tag.
>> >> >
>> >> > Signed-off-by: Russell King 
>> >>
>> >> Can you please also share git tree path of corresponding kexec-tools 
>> >> changes?
>> >>
>> >> Could it be a better idea (if things in user space become simpler)
>> >> that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
>> >> user space, and then user space manipulates existing "Crash kernel"
>> >> and "System RAM" resources.
>> >
>> > Given that it's only _one_ platform right now, I don't think that
>> > additional complexity is worth it.  It means that we have to invent
>>
>> Probably, I could not communicate it well.  I was not trying  to have
>> *additional* complexity. Wanted to see if things could be simpler
>> rather. So this is what my understanding was:
>> -- We create one patch to pass arch_phys_to_idmap_offset to user space
>> (say in /sys/kernel/bootmem_idmap_offset)
>> -- We do not use patch 5,6,11 and 12 of this series. Probably few more
>> content of the series will go away.
>
> Patches 11 and 12 don't go away with what you're suggesting.  Patches
> 11 and 12 are necessary to allow the boot-view addresses to be passed
> into the kernel through kexec, and to allow kexec to find appropriate
> memory resources.

But once we would have manipulated "start" and "end" of "Crash Kernel"
and "System RAM" resources in user space using
/sys/kernel/bootmem_idmap_offset , then kernel through kexec system
call would have already receive boot-view addresses, no?

~Pratyush
--
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