Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

[Ricardo Neri]

On Thu, 2016-11-10 at 11:52 +0300, Stas Sergeev wrote:
> Hi!
> 
> I don't know the context of that discussion, so I'll only
> comment on the dosemu part.

I'm sorry! I will cc you and the linux-msdos list in my v2.
> 
> 10.11.2016 09:46, Ricardo Neri пишет:
> > I took a closer look at the dosemu code. It appears that it does not
> > purposely utilize SGDT to obtain the descriptor table while in vm86. It
> > does use SGDT (in protected mode) to emulate certain functionality such
> > as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
> > However, this code seems to be disabled [1].
> Indeed.
> The code you've found, was copied from wine, because
> dosemu supports windows-3.1. But sgdt is in win32s part
> that is disabled in dosemu. It is however enabled in wine, or
> at least it was when I ported the VxD code from there. So you
> may want to ask wine devs if they still use sgdt and vm86.
> In dosemu, if we ever enable win32s support, we won't rely
> on sgdt. In fact, when some prot mode program under dosemu
> uses GDT selectors, in a fault handler we replace them with
> LDT selectors.

Actually, the SLDT instruction is also impacted by this feature. This
feature, will cause a GP fault if the instructions SGDT, SLDT, SIDT,
SMSW or STR are executed with CPL > 0. Would this be a problem for
dosemu? The proposal now is to trap this GPU fault and give fake value
for these tables.
> 
> >   dosemu includes an i386
> > emulator that in some cases uses the actual instructions of the host
> > system.
> In dosemu2 code, the places you've found, now contain this:
> error("SGDT not implemented\n");
> If we ever support SGDT, we'll use some emulation/fake values.
> 
> So overall, dosemu is not going to willingly use sgdt in any
> near future. But the programs running under vm86 or in prot mode
> may do so. This is very uncommon though, especially under dosemu,
> because it supports only a "polite" programs - those that work
> under win95's dos prompt. No one would get sufficiently hurt if
> sgdt under vm86 will somehow change from its current behaviour.

This is good news. This means that we could go ahead and give a fake
pointer to the GDT and the other impacted tables?
> 
> You can ask wine people for their sgdt use in win32s subsystem.

Will do.

Thanks and BR,
Ricardo

--
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/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Ricardo Neri]

On Thu, 2016-11-10 at 09:58 +0100, Borislav Petkov wrote:
> On Wed, Nov 09, 2016 at 07:24:43PM -0800, Ricardo Neri wrote:
> > I intended this feature to be configurable at build time in case someone
> > wants to build a kernel without it; similar to other features such as
> > SMAP. Is this not needed? Should Linux be built with this feature always
> > enabled?
> > 
> > This feature could always be disabled via a kernel parameter, though;
> > even if Linux is built with it.
> 
> It probably is a good idea to have it build-time configurable for the
> embedded folks. But you can do a before and after build and look at
> the vmlinux size and see how much it has grown. If it is only a couple
> of KBs I guess we can drop the config option even but I know there are
> people who still care about KBs too...

Thanks for the suggestions. Perhaps I can include these metrics in my
V2. On th other hand, Dave Hansen gave a good argument on potential
conflicts when, of instance running on an AMD CPU. UMIP is enabled by
setting a bit in CR4. If that bit is not supposed to be set, that could
cause a #GP fault.

Thanks and BR,
Ricardo
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 
> 21284 (AG Nürnberg)


--
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 v3 02/20] x86: Set the write-protect cache mode for full PAT support

[Kani, Toshimitsu]

On Thu, 2016-11-10 at 14:14 +0100, Borislav Petkov wrote:
> + Toshi.
> 
> On Wed, Nov 09, 2016 at 06:34:48PM -0600, Tom Lendacky wrote:
> > 
> > For processors that support PAT, set the write-protect cache mode
> > (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value
> > (x05).

Using slot 6 may be more cautious (for the same reason slot 7 was used
for WT), but I do not have a strong opinion for it.

set_page_memtype() cannot track the use of WP type since there is no
extra-bit available for WP, but WP is only supported by
early_memremap_xx() interfaces in this series.  So, I think we should
just document that WP is only intended for temporary mappings at boot-
time until this issue is resolved.  Also, we need to make sure that
this early_memremap for WP is only called after pat_init() is done.

A nit - please add WP to the function header comment below.
"This function initializes PAT MSR and PAT table with an OS-defined
value to enable additional cache attributes, WC and WT."

Thanks,
-Toshi

[PATCH] i2c: i2c-topology: fix minor whitespace nit

[Peter Rosin]

Signed-off-by: Peter Rosin 
---
 Documentation/i2c/i2c-topology | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/i2c/i2c-topology b/Documentation/i2c/i2c-topology
index e0aefeece551..1a014fede0b7 100644
--- a/Documentation/i2c/i2c-topology
+++ b/Documentation/i2c/i2c-topology
@@ -326,7 +326,7 @@ Two parent-locked sibling muxes
 
 This is a good topology.
 
-   ..
+..
.--.  .--| dev D1 |
|  parent- |--'  ''
 .--|  locked  | ..
@@ -350,7 +350,7 @@ Mux-locked and parent-locked sibling muxes
 
 This is a good topology.
 
-   ..
+..
.--.  .--| dev D1 |
|   mux-   |--'  ''
 .--|  locked  | ..
-- 
2.1.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] i2c: i2c-topology: fix minor whitespace nit

[Wolfram Sang]

On Thu, Nov 10, 2016 at 03:03:21PM +0100, Peter Rosin wrote:
> Signed-off-by: Peter Rosin 

Applied to for-current, thanks!



signature.asc
Description: PGP signature

Re: [RESEND PATCH v1 07/11] perf: hisi: Add support for Hisilicon SoC event counters

[Mark Rutland]

On Thu, Nov 03, 2016 at 01:42:03AM -0400, Anurup M wrote:
> + do {
> + /* Get count from individual L3C banks and sum them up */
> + for (i = 0; i < num_banks; i++) {
> + total_raw_count += hisi_read_l3c_counter(l3c_hwmod_data,
> + idx, i);
> + }
> + prev_raw_count = local64_read(>prev_count);
> +
> + /*
> +  * As prev_raw_count is updated with average value of
> +  * L3 cache banks, we multiply it by no of banks and
> +  * compute the delta
> +  */
> + delta = (total_raw_count - (prev_raw_count * num_banks)) &
> + HISI_MAX_PERIOD;
> +
> + local64_add(delta, >count);
> +
> + /*
> +  * Divide by num of banks to get average count and
> +  * update prev_count with this value
> +  */
> + avg_raw_count = total_raw_count / num_banks;
> + } while (local64_cmpxchg(
> +  >prev_count, prev_raw_count, avg_raw_count) !=
> +  prev_raw_count);

Please don't aggregate like this; expose separate PMUs instead.

This is racy, and by averaging and multiplying we're making up and/or
throwing away data.

[...]

> + event_value = (val -
> + HISI_HWEVENT_L3C_READ_ALLOCATE);
> +
> + /* Select the appropriate Event select register */
> + if (idx > 3)
> + reg_offset += 4;
> +
> + /* Value to write to event type register */
> + val = event_value << (8 * idx);
> +

Please add helpers for these, and explain *why* the transformations are
necessary.

> + /* Find the djtag Identifier of the Unit */
> + client = l3c_hwmod_data->client;
> +
> + /*
> +  * Set the event in L3C_EVENT_TYPEx Register
> +  * for all L3C banks
> +  */

As above, it seems like you should expose a separate PMU per bank
instead. That applies for all the other instances where you iterate over
banks.

[...]

> + for (i = 0; i < l3c_hwmod_data->l3c_hwcfg.num_banks; i++) {
> + module_id = l3c_hwmod_data->l3c_hwcfg.module_id[i];
> + cfg_en = l3c_hwmod_data->l3c_hwcfg.bank_cfgen[i];
> + ret = hisi_djtag_writereg(module_id,
> + cfg_en,
> + reg_offset,
> + value,
> + client);
> + if (!ret)
> + ret = value;
> + }

This is impossible to read. Please factor this into helpers such that
you don't need this amount of indentation.

Please do similarly elsewhere when you see this indentation pattern.

[...]

> +static int hisi_l3c_get_event_idx(struct hisi_pmu *pl3c_pmu)
> +{
> + struct hisi_l3c_data *l3c_hwmod_data = pl3c_pmu->hwmod_data;
> + int event_idx;
> +
> + event_idx =
> + find_first_zero_bit(
> + l3c_hwmod_data->hisi_l3c_event_used_mask,
> +  pl3c_pmu->num_counters);
> +
> + if (event_idx == HISI_MAX_CFG_L3C_CNTR)
> + return -EAGAIN;
> +
> + __set_bit(event_idx,
> + l3c_hwmod_data->hisi_l3c_event_used_mask);
> +
> + return event_idx;
> +}

Please get rid of the weird hungarian notation (i.e. don't use 'p' as a
prefix for pointers), and use temporary variables consistently, e.g.

static int hisi_l3c_get_event_idx(struct hisi_pmu *l3c_pmu)
{
struct hisi_l3c_data *l3c_hwmod_data = l3c_pmu->hwmod_data;
unsigned long *used_mask = l3c_hwmod_data->hisi_l3c_event_used_mask;
int num_counters = pl3c_pmu->num_counters
int idx;

idx = find_first_zero_bit(used_mask, num_counters);
if (idx == num_counters)
return -EAGAIN;

set_bit(idx, used_mask);

return idx;
}

[...]

> + if (of_property_read_u32(node, "counter-reg",
> +  _hwcfg->counter_reg0_off)) {
> + dev_err(dev, "DT:Couldnot read counter-reg!\n");
> + return -EINVAL;
> + }

Please use spaces in these messages.

Otherwise, my comments on the binding apply here.

[...]

> +static int init_hisi_l3c_data(struct device *dev,
> + struct hisi_pmu *pl3c_pmu,
> + struct hisi_djtag_client *client)
> +{
> + struct hisi_l3c_data *l3c_hwmod_data = NULL;
> + int ret;
> +
> + l3c_hwmod_data = kzalloc(sizeof(struct hisi_l3c_data),
> + GFP_KERNEL);

Use:

l3c_hwmod_data = kzalloc(sizeof(*l3c_hwmod_data, GFP_KERNEL):

[...]

> +static int hisi_pmu_l3c_dev_probe(struct hisi_djtag_client *client)
> +{
> + struct hisi_pmu *pl3c_pmu = NULL;
> +

Re: [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU

[Mark Rutland]

Hi,

On Thu, Nov 03, 2016 at 01:42:01AM -0400, Anurup M wrote:
>   1) Device tree bindings for Hisilicon SoC PMU.
>   2) Add example for Hisilicon L3 cache, MN and DDRC PMU.
> 
> Signed-off-by: Anurup M 
> Signed-off-by: Shaokun Zhang 
> ---
>  .../devicetree/bindings/arm/hisilicon/pmu.txt  | 127 
> +
>  1 file changed, 127 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> new file mode 100644
> index 000..e7b35e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> @@ -0,0 +1,127 @@
> +Hisilicon SoC hip05/06/07 ARMv8 PMU
> +===
> +
> +The Hisilicon SoC chips like hip05/06/07 etc. consist of varous independent
> +system device PMU's such as L3 cache (L3C), Miscellaneous Nodes(MN) and DDR

s/PMU's/PMUs/

> +comtroller. These PMU devices are independent and have hardware logic to

s/comtroller/controller/

> +gather statistics and performance information.
> +
> +HiSilicon SoC chip is encapsulated by multiple CPU and IO die's. The CPU die

s/die's/dies/

> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
> +is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
> +e.g. In the case of hip05/06/07, each SCCL has 1 L3 cache and 1 MN PMU 
> device.
> +
> +The Hisilicon SoC PMU DT node bindigs for uncore PMU devices are as below.

s/bindigs/bindings/

> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
> +the parent node will be the djtag node of the corresponding CPU die(SCCL).
> +
> +For uncore PMU devices there are some common required properties as detailed
> +below.
> +
> +Required properties:
> + - compatible : This field contain two values. The first value is
> + always "hisilicon" and second value is the Module type as shown
> + in below examples:

Just say:

 - Compatible: should contain one of:

> + (a) "hisilicon,hisi-pmu-l3c-v1" for Hisilicon SoC L3C PMU
> + device (Version 1)
> + (b) "hisilicon,hisi-pmu-mn-v1" for Hisilicon SoC MN PMU
> + device (Version 1)
> + (c) "hisilicon,hisi-pmu-ddrc-v1" for Hisilicon SoC DDRC PMU
> + device (Version 1)
> + The hip05/06/07 chips have v1 hardware for L3C, MN and DDRC.
> +
> + - scl-id : The Super Cluster ID. This can be the ID of the CPU die
> +or IO die in the chip.

What's this needed for?

> + - num-events : No of events supported by this PMU device.
> +
> + - num-counters : No of hardware counters available for counting.

This isn't probeable or well-known?

> +
> +L3 cache
> +
> +The L3 cache is dedicated for each SCCL and hence there are separate DT nodes
> +for L3 cache for each SCCL. For L3 cache PMU the additional required 
> properties
> +are
> + - counter-reg : Counter register offset.
> +
> + - evtype-reg : Event select register offset.
> +
> + - evctrl-reg : Event counting control(LAUCTRL) register offset.

Surely for a given revision of the chip these offsets are known? i.e.
surely the compatible string implies specific offsets?

> + - event-en : Event enable value.

Huh?

> + - module-id : Module ID to input for djtag. This property is an array of
> +   module_id for each L3 cache banks.
> +
> + - num-banks : Number of banks or instances of the device.

What's a bank? Surely they have separate instances of the PMU?

What order are these in?

> + - cfgen-map : Config enable array to select the bank.

Huh?

> +Miscellaneous Node
> +---
> +The MN is dedicated for each SCCL and hence there are separate DT nodes for 
> MN
> +for each SCCL. For MN PMU the additional required properties are
> + - counter-reg : Counter register offset.
> +
> + - evtype-reg : Event select register offset.
> +
> + - evctrl-reg : Event counting control register offset.

Likewise, surely this is well-known for a given revision of the chip?

> +
> + - module-id : Module ID to input for djtag. As MN doesnot have multiple 
> banks
> +   this property is a single value.
> +
> + - cfgen-map : Config enable to select the bank. For MN it is a single 
> value
> +
> + - event-en : Event enable value.

Same comments as for the L3 cache nodes


[...]

> +DDR controller
> +--
> +Each SCCL in Hip05/06/07 chips have 2 DDR channels and hence 2 DDR 
> controllers.
> +There are separate DT nodes for each DDR channel.
> +For DDRC PMU the additional required properties are
> +
> + - ch-id : DDRC Channel ID.

Why is this necessary?

Thanks,
Mark.

> + - reg : Register base address and range for the DDRC channel.
> +

Re: [RESEND PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver

[Mark Rutland]

On Thu, Nov 03, 2016 at 01:41:59AM -0400, Anurup M wrote:
> From: Tan Xiaojun 
> 
>   The Hisilicon Djtag is an independent component which connects
>   with some other components in the SoC by Debug Bus. This driver
>   can be configured to access the registers of connecting components
>   (like L3 cache) during real time debugging.
> 

Just to check, is this likely to be used in multi-socket hardware, and
if so, are instances always-on?

> Signed-off-by: Tan Xiaojun 
> Signed-off-by: John Garry 
> Signed-off-by: Anurup M 
> ---
>  drivers/soc/Kconfig |   1 +
>  drivers/soc/Makefile|   1 +
>  drivers/soc/hisilicon/Kconfig   |  12 +
>  drivers/soc/hisilicon/Makefile  |   1 +
>  drivers/soc/hisilicon/djtag.c   | 639 
> 
>  include/linux/soc/hisilicon/djtag.h |  38 +++
>  6 files changed, 692 insertions(+)
>  create mode 100644 drivers/soc/hisilicon/Kconfig
>  create mode 100644 drivers/soc/hisilicon/Makefile
>  create mode 100644 drivers/soc/hisilicon/djtag.c
>  create mode 100644 include/linux/soc/hisilicon/djtag.h

Other than the PMU driver(s), what is going to use this?

If you don't have something in particular, please also place this under
drivers/perf/hisilicon, along with the PMU driver(s).

We can always move it later if necessary.

[...]

> +#define SC_DJTAG_TIMEOUT 10  /* 100ms */

This would be better as:

#define SC_DJTAG_TIMEOUT_US (100 * USEC_PER_MSEC)

(you'll need to include )

[...]

> +static void djtag_read32_relaxed(void __iomem *regs_base, u32 off, u32 
> *value)
> +{
> + void __iomem *reg_addr = regs_base + off;
> +
> + *value = readl_relaxed(reg_addr);
> +}
> +
> +static void djtag_write32(void __iomem *regs_base, u32 off, u32 val)
> +{
> + void __iomem *reg_addr = regs_base + off;
> +
> + writel(val, reg_addr);
> +}

I think these make the driver harder to read, especially given the read
function is void and takes an output pointer.

In either case you can call readl/writel directly with base + off for
the __iomem ptr. Please do that.

> +
> +/*
> + * djtag_readwrite_v1/v2: djtag read/write interface
> + * @reg_base:djtag register base address
> + * @offset:  register's offset
> + * @mod_sel: module selection
> + * @mod_mask:mask to select specific modules for write
> + * @is_w:write -> true, read -> false
> + * @wval:value to register for write
> + * @chain_id:which sub module for read
> + * @rval:value in register for read
> + *
> + * Return non-zero if error, else return 0.
> + */
> +static int djtag_readwrite_v1(void __iomem *regs_base, u32 offset, u32 
> mod_sel,
> + u32 mod_mask, bool is_w, u32 wval, int chain_id, u32 *rval)
> +{
> + u32 rd;
> + int timeout = SC_DJTAG_TIMEOUT;
> +
> + if (!(mod_mask & CHAIN_UNIT_CFG_EN)) {
> + pr_warn("djtag: do nothing.\n");
> + return 0;
> + }
> +
> + /* djtag mster enable & accelerate R,W */
> + djtag_write32(regs_base, SC_DJTAG_MSTR_EN,
> + DJTAG_NOR_CFG | DJTAG_MSTR_EN);
> +
> + /* select module */
> + djtag_write32(regs_base, SC_DJTAG_DEBUG_MODULE_SEL, mod_sel);
> + djtag_write32(regs_base, SC_DJTAG_CHAIN_UNIT_CFG_EN,
> + mod_mask & CHAIN_UNIT_CFG_EN);
> +
> + if (is_w) {
> + djtag_write32(regs_base, SC_DJTAG_MSTR_WR, DJTAG_MSTR_W);
> + djtag_write32(regs_base, SC_DJTAG_MSTR_DATA, wval);
> + } else
> + djtag_write32(regs_base, SC_DJTAG_MSTR_WR, DJTAG_MSTR_R);
> +
> + /* address offset */
> + djtag_write32(regs_base, SC_DJTAG_MSTR_ADDR, offset);
> +
> + /* start to write to djtag register */
> + djtag_write32(regs_base, SC_DJTAG_MSTR_START_EN, DJTAG_MSTR_START_EN);
> +
> + /* ensure the djtag operation is done */
> + do {
> + djtag_read32_relaxed(regs_base, SC_DJTAG_MSTR_START_EN, );
> + if (!(rd & DJTAG_MSTR_EN))
> + break;
> +
> + udelay(1);
> + } while (timeout--);
> +
> + if (timeout < 0) {
> + pr_err("djtag: %s timeout!\n", is_w ? "write" : "read");
> + return -EBUSY;
> + }
> +
> + if (!is_w)
> + djtag_read32_relaxed(regs_base,
> + SC_DJTAG_RD_DATA_BASE + chain_id * 0x4, rval);
> +
> + return 0;
> +}

Please factor out the common bits into helpers and have separate
read/write functions. It's incredibly difficult to follow the code with
read/write hidden behind a boolean parameter.

> +static const struct of_device_id djtag_of_match[] = {
> + /* for hip05(D02) cpu die */
> + { .compatible = "hisilicon,hip05-cpu-djtag-v1",
> + .data = (void *)djtag_readwrite_v1 },
> + /* for hip05(D02) io die */
> + { .compatible = 

Re: [RESEND PATCH v1 02/11] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Sysctrl and Djtag dts bindings

[Mark Rutland]

Hi,

On Thu, Nov 03, 2016 at 01:41:58AM -0400, Anurup M wrote:
> From: Tan Xiaojun 
> 
>   1) Add Hisilicon HiP05/06/07 CPU and ALGSUB system controller dts
>  bindings.
>   2) Add Hisilicon Djtag dts binding.
> 
> Signed-off-by: Tan Xiaojun 
> Signed-off-by: Anurup M 
> ---
>  .../bindings/arm/hisilicon/hisilicon.txt   | 82 
> ++
>  1 file changed, 82 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> index 7df79a7..341cbb9 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
> @@ -270,3 +270,85 @@ Required Properties:
>[1]: bootwrapper size
>[2]: relocation physical address
>[3]: relocation size


> +---
> +The Hisilicon Djtag in CPU die is an independent component which connects 
> with
> +some other components in the SoC by Debug Bus. This driver can be configured
> +to access the registers of connecting components (like L3 cache, l3 cache PMU
> + etc.) during real time debugging by sysctrl. These components appear as 
> child
> +nodes of djtag.

Please put the djtag binding in a new file. 

It's clearly unrelated to many other things in this file, which should
also be split out.

> +The Hip05/06/07 CPU system controller(sysctrl) support to manage some 
> important
> +components (such as clock, reset, soft reset, secure debugger, etc.).
> +The CPU sysctrl registers in hip05/06/07 doesnot use syscon but will be 
> mapped
> +by djtag driver for use by connecting components.

The djtag driver is irrelvant here.

If there's a realtionship between the two, please define that in the
binding rather than implicitly assuming it in the driver.

> +
> +Required properties:
> +  - compatible : "hisilicon,hip05-cpu-djtag-v1"
> +  - reg : Register address and size
> +
> +Hisilicon HiP06 djtag for CPU sysctrl
> +Required properties:
> +- compatible : "hisilicon,hip06-sysctrl", "syscon", "simple-mfd";

This looks messy. Why is this syscon and a simple-mfd?

We should kill off / deprecate the syscon binding. It's completely
meaningless.

> +- reg : Register address and size
> +- djtag :
> +  - compatible : "hisilicon,hip06-cpu-djtag-v1"
> +  - reg : Register address and size
> +
> +Hisilicon HiP07 djtag for CPU sysctrl
> +Required properties:
> +  - compatible : "hisilicon,hip07-cpu-djtag-v2"
> +  - reg : Register address and size
> +
> +Example:
> + /* for Hisilicon HiP05 djtag for CPU sysctrl */
> + djtag0: djtag@8001 {
> + compatible = "hisilicon,hip05-cpu-djtag-v1";
> + reg = <0x0 0x8001 0x0 0x1>;
> +
> + /* For L3 cache PMU */
> + pmul3c0 {
> + compatible = "hisilicon,hisi-pmu-l3c-v1";
> + scl-id = <0x02>;
> + num-events = <0x16>;
> + num-counters = <0x08>;
> + module-id = <0x04>;
> + num-banks = <0x04>;
> + cfgen-map = <0x02 0x04 0x01 0x08>;
> + counter-reg = <0x170>;
> + evctrl-reg = <0x04>;
> + event-en = <0x100>;
> + evtype-reg = <0x140>;
> + };

This sub-node needs a binding document.

These properties are completely opaque

> + };
> +
> +---
> +The Hisilicon HiP05/06/07 ALGSUB system controller(sysctrl) is in IO die
> +of SoC. It has a similar function as the Hisilicon HiP05/06/07 CPU system
> +controller in CPU die and it manage different components, like RSA, etc.
> +The Hisilicon Djtag in IO die has a similar function as in CPU die and maps
> +the sysctrl registers for use by connecting components.
> +All connecting components shall appear as child nodes of djtag.

I don't follow the above. This describes an ALGSUB system controllerm
but the documentation below is all about djtag.

Thanks,
Mark.

> +Hisilicon HiP05 djtag for ALGSUB sysctrl
> +Required properties:
> +  - compatible : "hisilicon,hip05-io-djtag-v1"
> +  - reg : Register address and size
> +
> +Hisilicon HiP06 djtag for ALGSUB sysctrl
> +Required properties:
> +  - compatible : "hisilicon,hip06-io-djtag-v2"
> +  - reg : Register address and size
> +
> +Hisilicon HiP07 djtag for ALGSUB sysctrl
> +Required properties:
> +  - compatible : "hisilicon,hip07-io-djtag-v2"
> +  - reg : Register address and size
> +
> +Example:
> + /* for Hisilicon HiP05 djtag for alg sysctrl */
> + djtag0: djtag@d000 {
> +compatible = "hisilicon,hip05-io-djtag-v1";
> + reg = <0x0 0xd000 0x0 0x1>;
> + };
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send 

Re: [PATCH 1/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Dave Hansen]

On 11/09/2016 07:24 PM, Ricardo Neri wrote:
> On Wed, 2016-11-09 at 03:02 -0800, Andy Lutomirski wrote:
...
>> > What I mean is: why does this need a config option at all?
> I intended this feature to be configurable at build time in case someone
> wants to build a kernel without it; similar to other features such as
> SMAP. Is this not needed? Should Linux be built with this feature always
> enabled?

I think marking these features with their own CONFIG's is a really good
idea.  It helps the tinification effort.  It's also nice for folks that
might want to turn all the Intel features off because they're running on
AMD or something.

We don't necessarily need prompts for *everything*, but I can't imagine
just slapping the code in without #ifdefs of any kind.
--
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 v9 7/8] thunderbolt: Networking doc

[Jonathan Corbet]

On Wed, 9 Nov 2016 17:00:02 +0100
Greg KH  wrote:

> >  Documentation/00-INDEX   |   2 +
> >  Documentation/thunderbolt/networking.txt | 132 
> > +++  
> 
> Note, new files should be in .rst format, and live in the new
> subdirectory for them (somewhere in Documentation, don't know off the
> top of my head...)

This one's almost in RST already, happily.

We haven't really figured out a hierarchy for device-specific docs like
this yet; I should get on that, I guess.

I do believe that we should separate documents for end users from those
aimed at kernel developers; those are two very different audiences
looking for different kinds of information.

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: [RFC PATCH v3 02/20] x86: Set the write-protect cache mode for full PAT support

[Borislav Petkov]

+ Toshi.

On Wed, Nov 09, 2016 at 06:34:48PM -0600, Tom Lendacky wrote:
> For processors that support PAT, set the write-protect cache mode
> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
> 
> Acked-by: Borislav Petkov 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/mm/pat.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
> index 170cc4f..87e8952 100644
> --- a/arch/x86/mm/pat.c
> +++ b/arch/x86/mm/pat.c
> @@ -355,7 +355,7 @@ void pat_init(void)
>*  0102UC-: _PAGE_CACHE_MODE_UC_MINUS
>*  0113UC : _PAGE_CACHE_MODE_UC
>*  1004WB : Reserved
> -  *  1015WC : Reserved
> +  *  1015WP : _PAGE_CACHE_MODE_WP
>*  1106UC-: Reserved
>*  1117WT : _PAGE_CACHE_MODE_WT
>*
> @@ -363,7 +363,7 @@ void pat_init(void)
>* corresponding types in the presence of PAT errata.
>*/
>   pat = PAT(0, WB) | PAT(1, WC) | PAT(2, UC_MINUS) | PAT(3, UC) |
> -   PAT(4, WB) | PAT(5, WC) | PAT(6, UC_MINUS) | PAT(7, WT);
> +   PAT(4, WB) | PAT(5, WP) | PAT(6, UC_MINUS) | PAT(7, WT);
>   }
>  
>   if (!boot_cpu_done) {
> 
> 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
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 v9 7/8] thunderbolt: Networking doc

[Greg KH]

On Thu, Nov 10, 2016 at 11:47:57AM +, Levy, Amir (Jer) wrote:
> On Wed, Nov 9 2016, 06:00 PM, Greg KH wrote:
> > On Wed, Nov 09, 2016 at 04:20:07PM +0200, Amir Levy wrote:
> > > Adding Thunderbolt(TM) networking documentation.
> > >
> > > Signed-off-by: Amir Levy 
> > > ---
> > >  Documentation/00-INDEX   |   2 +
> > >  Documentation/thunderbolt/networking.txt | 132
> > > +++
> > 
> > Note, new files should be in .rst format, and live in the new subdirectory 
> > for
> > them (somewhere in Documentation, don't know off the top of my head...)
> > 
> > >  2 files changed, 134 insertions(+)
> > >  create mode 100644 Documentation/thunderbolt/networking.txt
> > >
> > > diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index
> > > 3acc4f1..0239e68 100644
> > > --- a/Documentation/00-INDEX
> > > +++ b/Documentation/00-INDEX
> > > @@ -440,6 +440,8 @@ this_cpu_ops.txt
> > >   - List rationale behind and the way to use this_cpu operations.
> > >  thermal/
> > >   - directory with information on managing thermal issues (CPU/temp)
> > > +thunderbolt/
> > > + - directory with info regarding Thunderbolt.
> > >  trace/
> > >   - directory with info on tracing technologies within linux
> > > unaligned-memory-access.txt
> > 
> > This change is probably not needed.
> > 
> > > diff --git a/Documentation/thunderbolt/networking.txt
> > > b/Documentation/thunderbolt/networking.txt
> > > new file mode 100644
> > > index 000..88d1c12
> > > --- /dev/null
> > > +++ b/Documentation/thunderbolt/networking.txt
> > > @@ -0,0 +1,132 @@
> > > +Intel Thunderbolt(TM) Networking driver
> > > +===
> > > +
> > > +Copyright(c) 2013 - 2016 Intel Corporation.
> > > +
> > > +Contact Information:
> > > +Intel Thunderbolt mailing list 
> > > +Edited by Amir Levy 
> > > +
> > > +Overview
> > > +
> > > +
> > > +* The Thunderbolt Networking driver enables peer to peer networking
> > > +on non-Apple
> > > +  platforms running Linux.
> > > +
> > > +* The driver creates a virtual Ethernet device that enables computer
> > > +to computer
> > > +  communication over the Thunderbolt cable.
> > > +
> > > +* Using Thunderbolt Networking you can perform high speed file
> > > +transfers between
> > > +  computers, perform PC migrations and/or set up small workgroups
> > > +with shared
> > > +  storage without compromising any other Thunderbolt functionality.
> > > +
> > > +* The driver is located in drivers/thunderbolt/icm.
> > > +
> > > +* This driver will function only on non-Apple platforms with firmware
> > > +based
> > > +  Thunderbolt controllers that support Thunderbolt Networking.
> > > +
> > > +  ++++
> > > +  |Host 1  ||Host 2  |
> > > +  ||||
> > > +  |   +---+||+---+   |
> > > +  |   |Network||||Network|   |
> > > +  |   |Stack  ||||Stack  |   |
> > > +  |   +---+||+---+   |
> > > +  |   ^||^   |
> > > +  |   ||||   |
> > > +  |   v||v   |
> > > +  | +---+  ||  +---+ |
> > > +  | |Thunderbolt|  ||  |Thunderbolt| |
> > > +  | |Networking |  ||  |Networking | |
> > > +  | |Driver |  ||  |Driver | |
> > > +  | +---+  ||  +---+ |
> > > +  |   ^||^   |
> > > +  |   ||||   |
> > > +  |   v||v   |
> > > +  | +---+  ||  +---+ |
> > > +  | |Thunderbolt|  ||  |Thunderbolt| |
> > > +  | |Controller |<-++->|Controller | |
> > > +  | |with ICM   |  ||  |with ICM   | |
> > > +  | |enabled|  ||  |enabled| |
> > > +  | +---+  ||  +---+ |
> > > +  ++++
> > > +
> > > +Files
> > > +=
> > > +
> > > +The following files are located in the drivers/thunderbolt/icm directory:
> > > +
> > > +- icm_nhi.c/h:   These files allow communication with the firmware
> > (Intel
> > > +  Connection Manager) based controller. They also create an interface
> > > +for
> > > +  netlink communication with a user space daemon.
> > > +
> > > +- net.c/net.h:   These files implement the 'eth' interface for the
> > > +  Thunderbolt(TM) Networking.
> > 
> > You don't have to list the files, right?
> > 
> > > +
> > > +Interface to User Space
> > > +===
> > > +
> > > +The interface to the user space module is implemented through a Generic
> > Netlink.
> > 
> > Huh?  Not a normal network device?
> > 
> > > +This is 

RE: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

[Levy, Amir (Jer)]

On Thu, Nov 10 2016, 01:44 PM, Greg KH wrote:
> On Thu, Nov 10, 2016 at 11:39:19AM +, Levy, Amir (Jer) wrote:
> > > And how about getting some internal-Intel kernel developers to
> > > review and sign-off on this code?  Don't make the community do the
> > > review when you have access to resources like this.  You have an
> > > internal mailing list for this very purpose, use it!
> > >
> >
> > The review with the internal-Intel kernel developers was done before
> > submitting the first patch set.
> 
> Then why is their signed-off-by:s not on the patchset showing that they
> "bless" this series?
> 

Working on it.

> thanks,
> 
> greg k-h

--
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 v9 7/8] thunderbolt: Networking doc

[Levy, Amir (Jer)]

On Wed, Nov 9 2016, 06:00 PM, Greg KH wrote:
> On Wed, Nov 09, 2016 at 04:20:07PM +0200, Amir Levy wrote:
> > Adding Thunderbolt(TM) networking documentation.
> >
> > Signed-off-by: Amir Levy 
> > ---
> >  Documentation/00-INDEX   |   2 +
> >  Documentation/thunderbolt/networking.txt | 132
> > +++
> 
> Note, new files should be in .rst format, and live in the new subdirectory for
> them (somewhere in Documentation, don't know off the top of my head...)
> 
> >  2 files changed, 134 insertions(+)
> >  create mode 100644 Documentation/thunderbolt/networking.txt
> >
> > diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index
> > 3acc4f1..0239e68 100644
> > --- a/Documentation/00-INDEX
> > +++ b/Documentation/00-INDEX
> > @@ -440,6 +440,8 @@ this_cpu_ops.txt
> > - List rationale behind and the way to use this_cpu operations.
> >  thermal/
> > - directory with information on managing thermal issues (CPU/temp)
> > +thunderbolt/
> > +   - directory with info regarding Thunderbolt.
> >  trace/
> > - directory with info on tracing technologies within linux
> > unaligned-memory-access.txt
> 
> This change is probably not needed.
> 
> > diff --git a/Documentation/thunderbolt/networking.txt
> > b/Documentation/thunderbolt/networking.txt
> > new file mode 100644
> > index 000..88d1c12
> > --- /dev/null
> > +++ b/Documentation/thunderbolt/networking.txt
> > @@ -0,0 +1,132 @@
> > +Intel Thunderbolt(TM) Networking driver
> > +===
> > +
> > +Copyright(c) 2013 - 2016 Intel Corporation.
> > +
> > +Contact Information:
> > +Intel Thunderbolt mailing list 
> > +Edited by Amir Levy 
> > +
> > +Overview
> > +
> > +
> > +* The Thunderbolt Networking driver enables peer to peer networking
> > +on non-Apple
> > +  platforms running Linux.
> > +
> > +* The driver creates a virtual Ethernet device that enables computer
> > +to computer
> > +  communication over the Thunderbolt cable.
> > +
> > +* Using Thunderbolt Networking you can perform high speed file
> > +transfers between
> > +  computers, perform PC migrations and/or set up small workgroups
> > +with shared
> > +  storage without compromising any other Thunderbolt functionality.
> > +
> > +* The driver is located in drivers/thunderbolt/icm.
> > +
> > +* This driver will function only on non-Apple platforms with firmware
> > +based
> > +  Thunderbolt controllers that support Thunderbolt Networking.
> > +
> > +  ++++
> > +  |Host 1  ||Host 2  |
> > +  ||||
> > +  |   +---+||+---+   |
> > +  |   |Network||||Network|   |
> > +  |   |Stack  ||||Stack  |   |
> > +  |   +---+||+---+   |
> > +  |   ^||^   |
> > +  |   ||||   |
> > +  |   v||v   |
> > +  | +---+  ||  +---+ |
> > +  | |Thunderbolt|  ||  |Thunderbolt| |
> > +  | |Networking |  ||  |Networking | |
> > +  | |Driver |  ||  |Driver | |
> > +  | +---+  ||  +---+ |
> > +  |   ^||^   |
> > +  |   ||||   |
> > +  |   v||v   |
> > +  | +---+  ||  +---+ |
> > +  | |Thunderbolt|  ||  |Thunderbolt| |
> > +  | |Controller |<-++->|Controller | |
> > +  | |with ICM   |  ||  |with ICM   | |
> > +  | |enabled|  ||  |enabled| |
> > +  | +---+  ||  +---+ |
> > +  ++++
> > +
> > +Files
> > +=
> > +
> > +The following files are located in the drivers/thunderbolt/icm directory:
> > +
> > +- icm_nhi.c/h: These files allow communication with the firmware
> (Intel
> > +  Connection Manager) based controller. They also create an interface
> > +for
> > +  netlink communication with a user space daemon.
> > +
> > +- net.c/net.h: These files implement the 'eth' interface for the
> > +  Thunderbolt(TM) Networking.
> 
> You don't have to list the files, right?
> 
> > +
> > +Interface to User Space
> > +===
> > +
> > +The interface to the user space module is implemented through a Generic
> Netlink.
> 
> Huh?  Not a normal network device?
> 
> > +This is the communications protocol between the Thunderbolt driver
> > +and the user space application.
> 
> What userspace application?
> 
> > +Note that this interface mediates user space communication with ICM.
> 
> What is ICM?
> 
> > +(Existing Linux tools can be used to configure the network
> > 

Re: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

[Greg KH]

On Thu, Nov 10, 2016 at 11:39:19AM +, Levy, Amir (Jer) wrote:
> > And how about getting some internal-Intel kernel developers to review and
> > sign-off on this code?  Don't make the community do the review when you
> > have access to resources like this.  You have an internal mailing list for 
> > this
> > very purpose, use it!
> > 
> 
> The review with the internal-Intel kernel developers was done before 
> submitting
> the first patch set.

Then why is their signed-off-by:s not on the patchset showing that they
"bless" this series?

thanks,

greg k-h
--
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 v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

[Levy, Amir (Jer)]

On Wed, Nov 9 2016, 06:02 PM, Greg KH wrote:
> On Wed, Nov 09, 2016 at 04:20:00PM +0200, Amir Levy wrote:
> > This driver enables Thunderbolt Networking on non-Apple platforms
> > running Linux.
> >
> > Thunderbolt Networking provides peer-to-peer connections to transfer
> > files between computers, perform PC migrations, and/or set up small
> > workgroups with shared storage.
> >
> > This is a virtual connection that emulates an Ethernet adapter that
> > enables Ethernet networking with the benefit of Thunderbolt superfast
> > medium capability.
> >
> > Thunderbolt Networking enables two hosts and several devices that have
> > a Thunderbolt controller to be connected together in a linear (Daisy
> > chain) series from a single port.
> >
> > Thunderbolt Networking for Linux is compatible with Thunderbolt
> > Networking on systems running macOS or Windows and also supports
> > Thunderbolt generation 2 and 3 controllers.
> >
> > Note that all pre-existing Thunderbolt generation 3 features, such as
> > USB, Display and other Thunderbolt device connectivity will continue
> > to function exactly as they did prior to enabling Thunderbolt Networking.
> >
> > Code and Software Specifications:
> > This kernel code creates a virtual ethernet device for computer to
> > computer communication over a Thunderbolt cable.
> > The new driver is a separate driver to the existing Thunderbolt driver.
> > It is designed to work on systems running Linux that interface with
> > Intel Connection Manager (ICM) firmware based Thunderbolt controllers
> > that support Thunderbolt Networking.
> > The kernel code operates in coordination with the Thunderbolt user-
> > space daemon to implement full Thunderbolt networking functionality.
> >
> > Hardware Specifications:
> > Thunderbolt Hardware specs have not yet been published but are used
> > where necessary for register definitions.
> >
> > Acked-by: Andreas Noever 
> > Tested-by: Mario Limonciello 
> 
> This whole series is acked and tested by these people?  If so, why did you not
> include that in each patch?
> 

Will add in next patch set.

> And how about getting some internal-Intel kernel developers to review and
> sign-off on this code?  Don't make the community do the review when you
> have access to resources like this.  You have an internal mailing list for 
> this
> very purpose, use it!
> 

The review with the internal-Intel kernel developers was done before submitting
the first patch set.
Version 9 that we have here isn't so different from Version 0.

> thanks,
> 
> greg k-h

--
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 v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking

[Greg KH]

On Wed, Nov 09, 2016 at 04:20:00PM +0200, Amir Levy wrote:
> This driver enables Thunderbolt Networking on non-Apple platforms
> running Linux.
> 
> Thunderbolt Networking provides peer-to-peer connections to transfer
> files between computers, perform PC migrations, and/or set up small
> workgroups with shared storage.
> 
> This is a virtual connection that emulates an Ethernet adapter that
> enables Ethernet networking with the benefit of Thunderbolt superfast
> medium capability.
> 
> Thunderbolt Networking enables two hosts and several devices that
> have a Thunderbolt controller to be connected together in a linear
> (Daisy chain) series from a single port.
> 
> Thunderbolt Networking for Linux is compatible with Thunderbolt
> Networking on systems running macOS or Windows and also supports
> Thunderbolt generation 2 and 3 controllers.
> 
> Note that all pre-existing Thunderbolt generation 3 features, such as
> USB, Display and other Thunderbolt device connectivity will continue
> to function exactly as they did prior to enabling Thunderbolt Networking.
> 
> Code and Software Specifications:
> This kernel code creates a virtual ethernet device for computer to
> computer communication over a Thunderbolt cable.
> The new driver is a separate driver to the existing Thunderbolt driver.
> It is designed to work on systems running Linux that
> interface with Intel Connection Manager (ICM) firmware based
> Thunderbolt controllers that support Thunderbolt Networking.
> The kernel code operates in coordination with the Thunderbolt user-
> space daemon to implement full Thunderbolt networking functionality.
> 
> Hardware Specifications:
> Thunderbolt Hardware specs have not yet been published but are used
> where necessary for register definitions. 
> 
> Acked-by: Andreas Noever 
> Tested-by: Mario Limonciello 

This whole series is acked and tested by these people?  If so, why did
you not include that in each patch?

And how about getting some internal-Intel kernel developers to review
and sign-off on this code?  Don't make the community do the review when
you have access to resources like this.  You have an internal mailing
list for this very purpose, use it!

thanks,

greg k-h
--
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 v9 7/8] thunderbolt: Networking doc

[Greg KH]

On Wed, Nov 09, 2016 at 04:20:07PM +0200, Amir Levy wrote:
> Adding Thunderbolt(TM) networking documentation.
> 
> Signed-off-by: Amir Levy 
> ---
>  Documentation/00-INDEX   |   2 +
>  Documentation/thunderbolt/networking.txt | 132 
> +++

Note, new files should be in .rst format, and live in the new
subdirectory for them (somewhere in Documentation, don't know off the
top of my head...)

>  2 files changed, 134 insertions(+)
>  create mode 100644 Documentation/thunderbolt/networking.txt
> 
> diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
> index 3acc4f1..0239e68 100644
> --- a/Documentation/00-INDEX
> +++ b/Documentation/00-INDEX
> @@ -440,6 +440,8 @@ this_cpu_ops.txt
>   - List rationale behind and the way to use this_cpu operations.
>  thermal/
>   - directory with information on managing thermal issues (CPU/temp)
> +thunderbolt/
> + - directory with info regarding Thunderbolt.
>  trace/
>   - directory with info on tracing technologies within linux
>  unaligned-memory-access.txt

This change is probably not needed.

> diff --git a/Documentation/thunderbolt/networking.txt 
> b/Documentation/thunderbolt/networking.txt
> new file mode 100644
> index 000..88d1c12
> --- /dev/null
> +++ b/Documentation/thunderbolt/networking.txt
> @@ -0,0 +1,132 @@
> +Intel Thunderbolt(TM) Networking driver
> +===
> +
> +Copyright(c) 2013 - 2016 Intel Corporation.
> +
> +Contact Information:
> +Intel Thunderbolt mailing list 
> +Edited by Amir Levy 
> +
> +Overview
> +
> +
> +* The Thunderbolt Networking driver enables peer to peer networking on 
> non-Apple
> +  platforms running Linux.
> +
> +* The driver creates a virtual Ethernet device that enables computer to 
> computer
> +  communication over the Thunderbolt cable.
> +
> +* Using Thunderbolt Networking you can perform high speed file transfers 
> between
> +  computers, perform PC migrations and/or set up small workgroups with shared
> +  storage without compromising any other Thunderbolt functionality.
> +
> +* The driver is located in drivers/thunderbolt/icm.
> +
> +* This driver will function only on non-Apple platforms with firmware based
> +  Thunderbolt controllers that support Thunderbolt Networking.
> +
> +  ++++
> +  |Host 1  ||Host 2  |
> +  ||||
> +  |   +---+||+---+   |
> +  |   |Network||||Network|   |
> +  |   |Stack  ||||Stack  |   |
> +  |   +---+||+---+   |
> +  |   ^||^   |
> +  |   ||||   |
> +  |   v||v   |
> +  | +---+  ||  +---+ |
> +  | |Thunderbolt|  ||  |Thunderbolt| |
> +  | |Networking |  ||  |Networking | |
> +  | |Driver |  ||  |Driver | |
> +  | +---+  ||  +---+ |
> +  |   ^||^   |
> +  |   ||||   |
> +  |   v||v   |
> +  | +---+  ||  +---+ |
> +  | |Thunderbolt|  ||  |Thunderbolt| |
> +  | |Controller |<-++->|Controller | |
> +  | |with ICM   |  ||  |with ICM   | |
> +  | |enabled|  ||  |enabled| |
> +  | +---+  ||  +---+ |
> +  ++++
> +
> +Files
> +=
> +
> +The following files are located in the drivers/thunderbolt/icm directory:
> +
> +- icm_nhi.c/h:   These files allow communication with the firmware (Intel
> +  Connection Manager) based controller. They also create an interface for
> +  netlink communication with a user space daemon.
> +
> +- net.c/net.h:   These files implement the 'eth' interface for the
> +  Thunderbolt(TM) Networking.

You don't have to list the files, right?

> +
> +Interface to User Space
> +===
> +
> +The interface to the user space module is implemented through a Generic 
> Netlink.

Huh?  Not a normal network device?

> +This is the communications protocol between the Thunderbolt driver and the 
> user
> +space application.

What userspace application?

> +Note that this interface mediates user space communication with ICM.

What is ICM?

> +(Existing Linux tools can be used to configure the network interface.)

Why aren't they sufficient for everything here?

> +
> +The Thunderbolt Daemon utilizes this interface to communicate with the 
> driver.

What "Thunderbolt Daemon"?  What is "this"?

> +To be accessed by the user space module, both kernel and user space modules
> +have to register with the 

Re: [RFC PATCH v3 01/20] x86: Documentation for AMD Secure Memory Encryption (SME)

[Borislav Petkov]

On Wed, Nov 09, 2016 at 06:34:39PM -0600, Tom Lendacky wrote:
> This patch adds a Documenation entry to decribe the AMD Secure Memory
> Encryption (SME) feature.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  Documentation/kernel-parameters.txt |5 +++
>  Documentation/x86/amd-memory-encryption.txt |   40 
> +++
>  2 files changed, 45 insertions(+)
>  create mode 100644 Documentation/x86/amd-memory-encryption.txt
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 030e9e9..4c730b0 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2282,6 +2282,11 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   memory contents and reserves bad memory
>   regions that are detected.
>  
> + mem_encrypt=[X86-64] Enable AMD Secure Memory Encryption (SME)
> + Memory encryption is disabled by default, using this
> + switch, memory encryption can be enabled.

I'd say here:

"Force-enable memory encryption if it is disabled in the
BIOS."

> + on: enable memory encryption
> +
>   meye.*= [HW] Set MotionEye Camera parameters
>   See Documentation/video4linux/meye.txt.
>  
> diff --git a/Documentation/x86/amd-memory-encryption.txt 
> b/Documentation/x86/amd-memory-encryption.txt
> new file mode 100644
> index 000..788d871
> --- /dev/null
> +++ b/Documentation/x86/amd-memory-encryption.txt
> @@ -0,0 +1,40 @@
> +Secure Memory Encryption (SME) is a feature found on AMD processors.
> +
> +SME provides the ability to mark individual pages of memory as encrypted 
> using
> +the standard x86 page tables.  A page that is marked encrypted will be
> +automatically decrypted when read from DRAM and encrypted when written to
> +DRAM.  SME can therefore be used to protect the contents of DRAM from 
> physical
> +attacks on the system.
> +
> +A page is encrypted when a page table entry has the encryption bit set (see
> +below how to determine the position of the bit).  The encryption bit can be
> +specified in the cr3 register, allowing the PGD table to be encrypted. Each
> +successive level of page tables can also be encrypted.
> +
> +Support for SME can be determined through the CPUID instruction. The CPUID
> +function 0x801f reports information related to SME:
> +
> + 0x801f[eax]:
> + Bit[0] indicates support for SME
> + 0x801f[ebx]:
> + Bit[5:0]  pagetable bit number used to enable memory encryption
> + Bit[11:6] reduction in physical address space, in bits, when
> +   memory encryption is enabled (this only affects system
> +   physical addresses, not guest physical addresses)
> +
> +If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to
> +determine if SME is enabled and/or to enable memory encryption:
> +
> + 0xc0010010:
> + Bit[23]   0 = memory encryption features are disabled
> +   1 = memory encryption features are enabled
> +
> +Linux relies on BIOS to set this bit if BIOS has determined that the 
> reduction
> +in the physical address space as a result of enabling memory encryption (see
> +CPUID information above) will not conflict with the address space resource
> +requirements for the system.  If this bit is not set upon Linux startup then
> +Linux itself will not set it and memory encryption will not be possible.
> +
> +SME support is configurable through the AMD_MEM_ENCRYPT config option.
> +Additionally, the mem_encrypt=on command line parameter is required to 
> activate
> +memory encryption.

So how am I to understand this? We won't have TSME or we will but it
will be off by default and users will have to enable it in the BIOS or
will have to boot with mem_encrypt=on...?

Can you please expand on all the possible options there would be
available to users?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
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/4] x86: enable User-Mode Instruction Prevention

[Stas Sergeev]

Hi!

I don't know the context of that discussion, so I'll only
comment on the dosemu part.

10.11.2016 09:46, Ricardo Neri пишет:

I took a closer look at the dosemu code. It appears that it does not
purposely utilize SGDT to obtain the descriptor table while in vm86. It
does use SGDT (in protected mode) to emulate certain functionality such
as the Virtual xxx Driver. In such a case, UMIP needs to be disabled.
However, this code seems to be disabled [1].

Indeed.
The code you've found, was copied from wine, because
dosemu supports windows-3.1. But sgdt is in win32s part
that is disabled in dosemu. It is however enabled in wine, or
at least it was when I ported the VxD code from there. So you
may want to ask wine devs if they still use sgdt and vm86.
In dosemu, if we ever enable win32s support, we won't rely
on sgdt. In fact, when some prot mode program under dosemu
uses GDT selectors, in a fault handler we replace them with
LDT selectors.


  dosemu includes an i386
emulator that in some cases uses the actual instructions of the host
system.

In dosemu2 code, the places you've found, now contain this:
error("SGDT not implemented\n");
If we ever support SGDT, we'll use some emulation/fake values.

So overall, dosemu is not going to willingly use sgdt in any
near future. But the programs running under vm86 or in prot mode
may do so. This is very uncommon though, especially under dosemu,
because it supports only a "polite" programs - those that work
under win95's dos prompt. No one would get sufficiently hurt if
sgdt under vm86 will somehow change from its current behaviour.

You can ask wine people for their sgdt use in win32s subsystem.
--
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: [Ksummit-discuss] Including images on Sphinx documents

[Jani Nikula]

On Thu, 10 Nov 2016, Markus Heiser  wrote:
> Could this POC persuade you, if so, I send a more elaborate RFC,
> what do you think about?

Sorry, I do not wish to be part of this.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
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/4] x86/cpufeature: Add User-Mode Instruction Prevention definitions

[Borislav Petkov]

On Wed, Nov 09, 2016 at 07:24:43PM -0800, Ricardo Neri wrote:
> I intended this feature to be configurable at build time in case someone
> wants to build a kernel without it; similar to other features such as
> SMAP. Is this not needed? Should Linux be built with this feature always
> enabled?
> 
> This feature could always be disabled via a kernel parameter, though;
> even if Linux is built with it.

It probably is a good idea to have it build-time configurable for the
embedded folks. But you can do a before and after build and look at
the vmlinux size and see how much it has grown. If it is only a couple
of KBs I guess we can drop the config option even but I know there are
people who still care about KBs too...

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 
--
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