On 02/20/2018 09:38 AM, Graham Moore wrote:
> The Stratix10 SoCFPGA uses the PL330 DMAC. This patch adds the PL330
> DMAC to the Stratix10 device tree.
>
> Signed-off-by: Graham Moore
> ---
> arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 19 +++
> 1 file changed, 19 inse
On Mon, Mar 5, 2018 at 9:00 AM, wrote:
> From: Patrice Chotard
>
> Since dtc v1.4.6-9-gaadd0b65c987, aliases property name must
> be lowercase only.
> This allows to fix following warnings when compiling dtb
> with W=1 option :
I'm so glad to see fixes before the dtc update landed in the kernel
> Is this patch under your radar? Should I keep pushing for it or just give up?
Applied to for-next, thanks for your patience and your preparational
work needed to get this upstream!
We will see in linux-next if there slipped in some new drivers which
need fixing, but we have a full cycle to get
Am Donnerstag, den 01.03.2018, 11:20 -0800 schrieb Andrey Smirnov:
> With MFD and watchdog drivers for RAVE SP device support added by
> 538ee27290fa ("mfd: Add driver for RAVE Supervisory Processor") and
> c3bb33345721 ("watchdog: Add RAVE SP watchdog driver") add
> corresponding DT node for RDU2.
Am Donnerstag, den 01.03.2018, 11:20 -0800 schrieb Andrey Smirnov:
> With MFD and watchdog drivers for RAVE SP device support added by
> 538ee27290fa ("mfd: Add driver for RAVE Supervisory Processor") and
> c3bb33345721 ("watchdog: Add RAVE SP watchdog driver") add
> corresponding DT node for RDU.
Jernej Skrabec:
> +&hdmi_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> +};
This node is added to all the DTS files you enabled HDMI on. Is it
something that could be instead put to the DTSI file?
Joonas
Hi OuYang,
On Mon, 5 Mar 2018 22:53:46 +0800
OuYang ZhiZhong wrote:
> Section was not properly computed. The value of OOB region definition is
> always ECC section 0 information in the OOB area, but we want to get all
> the ECC bytes information, so we should call
> mtd_ooblayout_ecc(mtd, secti
On Sun, Mar 04, 2018 at 03:11:09PM +0100, Hans de Goede wrote:
> On 01-03-18 18:17, Mark Brown wrote:
> > Sure, but do such userspaces exist - ChromeOS or something for example?
> ChromeOS has a more or less standard userspace I believe.
No, they've got their own sound server for historical reas
On Sun, Mar 4, 2018 at 8:31 PM, Jan Kiszka wrote:
> From: Otavio Pontes
>
> Use the PCI mmconfig base address exported by jailhouse in boot
> parameters in order to access the memory mapped PCI configuration space.
>
FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Otavio Pontes
> [Jan: re
On 05/03/18 15:00, Nipun Gupta wrote:
-Original Message-
From: Robin Murphy [mailto:robin.mur...@arm.com]
Sent: Monday, March 05, 2018 20:23
To: Nipun Gupta ; will.dea...@arm.com;
mark.rutl...@arm.com; catalin.mari...@arm.com
Cc: io...@lists.linux-foundation.org; robh...@kernel.org; h.
On 03/05/2018 06:24 AM, John Garry wrote:
>>> I am seeing issue(log below) with this patchset on our platfrom.
>>> i have tried using your v2 branch [1]
>>>
>>> root@borg-1>perf_acme>> ./perf --version
>>> perf version 4.16.rc1.g087f7ca
>>> root@borg-1>perf_acme>> ./perf stat -e bus_access_rd sleep
Arushi Singhal,
Am Samstag, 3. März 2018, 15:02:33 CET schrieb Arushi Singhal:
> Add spaces around ('=' and '<'), to conform to the Linux
> kernel coding style. Issue found using checkpatch.
please fix real issues. Coding style fixes to existing code just add too much
churn. Except for drivers/
On Fri, Mar 02, 2018 at 11:20:49AM -0500, Nicholas Lowell wrote:
> +++ b/drivers/regulator/gpio-regulator.c
> @@ -196,6 +196,7 @@ of_get_gpio_regulator_config(struct device *dev, struct
> device_node *np,
> break;
> }
> config->gpios[i].gpio = gpio;
> + config->gpios[i].label = config->suppl
Hi Thiebaud
On Wed, Sep 20, 2017 at 10:13 AM, Thiebaud Weksteen wrote:
> With TPM 2.0 specification, the event logs may only be accessible by
> calling an EFI Boot Service. Modify the EFI stub to copy the log area to
> a new Linux-specific EFI configuration table so it remains accessible
> once b
Below is the list of build error/warning regressions/improvements in
v4.16-rc4[1] compared to v4.15[2].
Summarized:
- build errors: +11/-6
- build warnings: +1510/-1466
JFYI, when comparing v4.16-rc4[1] to v4.16-rc3[3], the summaries are:
- build errors: +10/-1
- build warnings: +47244/-3
From: Samuel Mendoza-Jonas
Date: Mon, 5 Mar 2018 11:39:05 +1100
> Add a generic netlink family for NCSI. This supports three commands;
> NCSI_CMD_PKG_INFO which returns information on packages and their
> associated channels, NCSI_CMD_SET_INTERFACE which allows a specific
> package or package/ch
On Mon, Mar 5, 2018 at 4:56 AM, Baolin Wang wrote:
> The Spreadtrum PMIC EIC controller contains only one bank of debounce EIC,
> and this bank contains 16 EICs. Each EIC can only be used as input mode,
> as well as supporting the debounce and the capability to trigger interrupts
> when detecting
On Mon, 2018-03-05 at 08:16 -0600, Rob Herring wrote:
> On Fri, Mar 2, 2018 at 5:27 PM, Sean Wang wrote:
> > On Fri, 2018-03-02 at 09:42 -0600, Rob Herring wrote:
> >> On Fri, Feb 23, 2018 at 06:16:36PM +0800, sean.w...@mediatek.com wrote:
> >> > From: Sean Wang
> >> >
> >> > There is 2GB DDR3 av
On Mon, Mar 5, 2018 at 4:41 PM, Geert Uytterhoeven wrote:
> JFYI, when comparing v4.16-rc4[1] to v4.16-rc3[3], the summaries are:
> - build errors: +10/-1
+ /kisskb/src/drivers/net/ethernet/intel/i40e/i40e_ethtool.c: error:
implicit declaration of function 'cmpxchg64'
[-Werror=implicit-functi
On 05/03/18 15:08, Christoph Hellwig wrote:
We should not add any new hardocded busses here. Please mark them in
OF/ACPI.
Unfortunately for us, fsl-mc is conceptually rather like PCI in that
it's software-discoverable and the only thing described in DT is the bus
"host", thus we need the sam
On Mon, Mar 05, 2018 at 01:48:16PM +0100, Mylène Josserand wrote:
> --- /dev/null
> +++ b/sound/soc/codecs/pcm1789-i2c.c
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * PCM1789 ASoC I2C driver
> + *
> + * Copyright (c) Bootlin 2018
> + *
> + * Mylène Josserand
> + *
> + * Th
On Mon, Jan 22, 2018 at 12:36:56PM +0100, Peter Rosin wrote:
> Can be used during probe to double check that the probed device is
> what is expected.
>
> Loosely based on code from Adrian Fiergolski .
>
> Signed-off-by: Peter Rosin
In general, nice! I wanted to have such a function in the core
On Mon, Mar 05, 2018 at 12:32:13PM +, srinivas.kandaga...@linaro.org wrote:
> +int dapm_pinctrl_event(struct snd_soc_dapm_widget *w,
> +struct snd_kcontrol *kcontrol, int event)
> +{
> + struct snd_soc_dapm_pinctrl_priv *priv = w->priv;
> + struct pinctrl *p = w->pi
On Fri, Mar 2, 2018 at 3:50 PM, Shanker Donthineni
wrote:
> diff --git a/arch/arm64/include/asm/cpucaps.h
> b/arch/arm64/include/asm/cpucaps.h
> index bb26382..6ecc249 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -43,7 +43,7 @@
> #define ARM64_SVE
> @@ -97,59 +98,83 @@ static const struct chip_desc chips[] = {
> .nchans = 2,
> .enable = 0x4,
> .muxtype = pca954x_ismux,
> + .id = { .manufacturer_id = I2C_DEVICE_ID_NONE },
Can't we just leave this empty and add a NULL pointer check below
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Monday, March 05, 2018 21:07
> To: Nipun Gupta ; will.dea...@arm.com;
> mark.rutl...@arm.com; catalin.mari...@arm.com
> Cc: io...@lists.linux-foundation.org; robh...@kernel.org; h...@lst.de;
> m.szyprow...@sam
On Mon, Mar 05, 2018 at 09:52:19AM -0600, Timur Tabi wrote:
> On Fri, Mar 2, 2018 at 3:50 PM, Shanker Donthineni
> wrote:
> > diff --git a/arch/arm64/include/asm/cpucaps.h
> > b/arch/arm64/include/asm/cpucaps.h
> > index bb26382..6ecc249 100644
> > --- a/arch/arm64/include/asm/cpucaps.h
> > +++ b
Hi,
On 03/05/2018 03:15 PM, Heiko Stuebner wrote:
Hi Daniel,
Am Montag, 5. März 2018, 13:45:11 CET schrieb Daniel Schultz:
The CLK_O_SEL default is synchronous to XI input clock, which is 25 MHz.
Set CLK_O_SEL to channel A transmit clock so we have 125 MHz on CLK_OUT.
Signed-off-by: Daniel S
Hi Shanker,
On Fri, Mar 02, 2018 at 03:50:18PM -0600, Shanker Donthineni wrote:
> The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
> V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
> the standard call SMCCC_ARCH_WORKAROUND_1 for Falkor chips instead
> of Silico
On 2018-03-05 16:53, Wolfram Sang wrote:
>
>> @@ -97,59 +98,83 @@ static const struct chip_desc chips[] = {
>> .nchans = 2,
>> .enable = 0x4,
>> .muxtype = pca954x_ismux,
>> +.id = { .manufacturer_id = I2C_DEVICE_ID_NONE },
>
> Can't we just leav
On Mon, 2018-02-26 at 18:42 +0200, Andy Shevchenko wrote:
> On Mon, Feb 26, 2018 at 4:56 PM, Eugeniy Paltsev
> wrote:
>
> > + chip->core_clk = devm_clk_get(chip->dev, "core-clk");
>
> Does the name come from datasheet?
>
> > + chip->cfgr_clk = devm_clk_get(chip->dev, "cfgr-clk");
>
On 05/03/2018 at 15:49:10 +, Mark Brown wrote:
> On Mon, Mar 05, 2018 at 01:48:16PM +0100, Mylène Josserand wrote:
>
> > --- /dev/null
> > +++ b/sound/soc/codecs/pcm1789-i2c.c
> > @@ -0,0 +1,76 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * PCM1789 ASoC I2C driver
> > + *
> > + *
Hi Maciej,
On Mon, Mar 5, 2018 at 11:40 AM, Maciej Purski wrote:
> Hi Fabio,
> thank you for your response.
> Could you tell me on which board precisely (on which DTS) has this issue
> occurred?
I tested it on a imx6dl-wandboard.dtb.
kernelci.org also shows other imx6 boards that cannot boot wi
On Mon, Mar 05, 2018 at 04:57:15PM +0100, Alexandre Belloni wrote:
> On 05/03/2018 at 15:49:10 +, Mark Brown wrote:
> > Please don't mix C and C++ style comments in a single comment like this
> > - it looks unintentional. Just use the same style for the whole thing.
> > You also don't need to
On Mon, Mar 05, 2018 at 12:33:29PM +1100, Oliver wrote:
> On Thu, Mar 1, 2018 at 10:40 AM, Logan Gunthorpe wrote:
> > @@ -429,10 +429,7 @@ static void __nvme_submit_cmd(struct nvme_queue *nvmeq,
> > {
> > u16 tail = nvmeq->sq_tail;
>
> > - if (nvmeq->sq_cmds_io)
> > -
> On 5 Mar 2018, at 17:23, Daniel Micay wrote:
> I didn't suggest this as the way of implementing fine-grained
> randomization but rather a small starting point for hardening address
> space layout further. I don't think it should be tied to a mmap flag
> but rather something like a personality fl
On 2018-03-05 16:51, Wolfram Sang wrote:
> On Mon, Jan 22, 2018 at 12:36:56PM +0100, Peter Rosin wrote:
>> Can be used during probe to double check that the probed device is
>> what is expected.
>>
>> Loosely based on code from Adrian Fiergolski .
>>
>> Signed-off-by: Peter Rosin
>
> In general,
On Thu, Mar 01, 2018 at 03:28:37PM -0300, Fabio Estevam wrote:
> On Thu, Mar 1, 2018 at 3:19 PM, Fabio Estevam wrote:
> > Running linux-next 20180301 on a imx6q-sabresd the following
> > regmap-debugfs warnings are seen:
> This only happens when the regmap name is 'dummy'.
> [0.083651] vdd1
On 03/05/2018 11:26 AM, Joerg Roedel wrote:
From: Joerg Roedel
Warn the user in case the performance can be significantly
improved by switching to a 64-bit kernel.
Suggested-by: Andy Lutomirski
Signed-off-by: Joerg Roedel
---
arch/x86/mm/pti.c | 16
1 file changed, 16 ins
On Mon, 2018-03-05 at 10:55 +0100, Romain Izard wrote:
> The TTY buffer is 4096 bytes large, throttling when there are only 128
> free bytes left, and unthrottling when there are only 128 bytes available.
> But the TTY buffer is filled from an intermediate flip buffer that
> contains up to 64 KiB
On 2018-03-04 23:28, Rafael J. Wysocki wrote:
use the expected idle period
duration returned by cpuidle_select() to tell tick_nohz_idle_go_idle()
whether or not to stop the tick.
I assume that at the point of going idle, the actual next scheduling
tick may happen anywhere between now and 1/HZ.
On Mon, Mar 05, 2018 at 08:33:20AM -0600, Eric W. Biederman wrote:
>
> Moving this discussion to a public list as discussing how to reduce the
> number of rcu variants does not make sense in private. We should have
> an archive of such discussions.
>
> Ingo Molnar writes:
>
> > * Paul E. McKen
On Fri, Mar 02, 2018 at 04:12:40PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
> Commit 9b947a13e7f6 ("regmap: use debugfs even when no device")
> allows the usage of regmap debugfs even when there is no device
> associated, which causes several warnings like this:
> (NULL device *): Faile
From: Markus Elfring
Date: Mon, 5 Mar 2018 17:12:34 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Use memdup_user() rather than duplicating its implementation
Improve a size determination in two functions
drivers/misc/vmw_vmci/vm
On Thu, Mar 01, 2018 at 03:40:30PM +0100, Niklas Cassel wrote:
> On Wed, Feb 28, 2018 at 02:21:48PM +, Lorenzo Pieralisi wrote:
> > On Tue, Feb 27, 2018 at 12:59:05PM +0100, Niklas Cassel wrote:
> > > A 64-bit BAR uses the succeeding BAR for the upper bits, therefore
> > > we cannot call pci_ep
Hi Arnaldo,
On 05.03.2018 18:06, Arnaldo Carvalho de Melo wrote:
> Em Mon, Mar 05, 2018 at 02:35:02PM +0300, Alexey Budankov escreveu:
>>
>> Here is a series of small patches that implement exposing type of
>> context-switch-out event as a part of PERF_RECORD_SWITCH[_CPU_WIDE] record.
>>
>> Intro
From: Markus Elfring
Date: Mon, 5 Mar 2018 16:40:29 +0100
* Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.
This issue was detected by using the Coccinelle software.
* Return directly after this function call failed at the beginning.
* Delete the l
From: Markus Elfring
Date: Mon, 5 Mar 2018 17:00:19 +0100
Replace the specification of data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detect
On 03/05/2018 07:02 AM, Bartosz Golaszewski wrote:
2018-03-01 17:44 GMT+01:00 David Lechner :
On 03/01/2018 02:36 AM, Bartosz Golaszewski wrote:
2018-02-28 22:40 GMT+01:00 David Lechner :
On 02/28/2018 06:38 AM, Bartosz Golaszewski wrote:
I think I found the reason for the strange crashe
On Mon, Mar 05, 2018 at 04:09:31PM +0300, Ilya Smith wrote:
> > On 4 Mar 2018, at 23:56, Matthew Wilcox wrote:
> > Thinking about this more ...
> >
> > - When you call munmap, if you pass in the same (addr, length) that were
> > used for mmap, then it should unmap the guard pages as well (that
IA32_TME_ACTIVATE MSR (0x982) can be used to check if BIOS has enabled
TME and MKTME. It includes which encryption policy/algorithm is selected
for TME or available for MKTME. For MKTME, the MSR also enumerates how
many KeyIDs are available.
We would need to exclude KeyID bits from physical addres
The new helpers checks if page is encrypted and with which keyid.
They use anon_vma get the information.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/mktme.h | 14 ++
arch/x86/mm/mktme.c | 17 +
2 files changed, 31 insertions(+)
diff --git a/ar
CPUID.0x7.0x0:EDX[18] indicates whether Intel CPU support PCONFIG instruction.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/cpufeatures.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index d5f42a303e74.
Intel PCONFIG targets are enumerated via new CPUID leaf 0x1b. This patch
detects all supported targets of PCONFIG and implements helper to check
if the target is supported.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/intel_pconfig.h | 15 +++
arch/x86/kernel/cpu/Makefile
As on allocation of encrypted page, we need to flush cache before
returning page to free pool. Failing to do this may lead to data
corruption.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/mm/mktme.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/x86/mm/mktme.c b/arch/x
Add new config option to enabled/disable Multi-Key Total Memory
Encryption support.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/Kconfig | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 99aecb2caed3..e1b377443899 100644
--- a/arch
> ..._TEN should definitely be cleared.
> ..._SLAVE will probably be cleared anyway.
> ..._HOST_NOTIFY, ..._WAKE and ..._SCCB I don't know about?
Not relevant for device_id reading.
> Are there others? The bits aren't that densely populated which makes
> me worry that I'm missing something...
H
The hardware/CPU does not enforce coherency between mappings of the
same physical page with different KeyIDs or encrypt ion keys.
We are responsible for cache management.
We have to flush cache on allocation and freeing of encrypted page.
Failing to do this may lead to data corruption.
Zeroing of
We store KeyID in upper bits for vm_page_prot that match position of
KeyID in PTE. vma_keyid() extracts KeyID from vm_page_prot.
VMA is encrypted if KeyID is non-zero. vma_is_encrypted() checks that.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/mktme.h | 9 +
arch/x86/mm/
VMAs with different KeyID do not mix together. Only VMAs with the same
KeyID are compatible.
Signed-off-by: Kirill A. Shutemov
---
include/linux/mm.h | 7 +++
mm/mmap.c | 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
ind
Encrypted VMA would have KeyID stored in vma->vm_page_prot. This way we
don't need to do anything special to setup encrypted page table entries
and don't need to reserve space for KeyID in a VMA.
This patch changes _PAGE_CHG_MASK to include KeyID bits. Otherwise they
are going to be stripped from
On 05/03/2018 15:39, William Cohen wrote:
On 03/05/2018 06:24 AM, John Garry wrote:
I am seeing issue(log below) with this patchset on our platfrom.
i have tried using your v2 branch [1]
root@borg-1>perf_acme>> ./perf --version
perf version 4.16.rc1.g087f7ca
root@borg-1>perf_acme>> ./perf stat
mktme_nr_keyids holds number of KeyIDs available for MKTME, excluding
KeyID zero which used by TME. MKTME KeyIDs start from 1.
mktme_keyid_shift holds shift of KeyID within physical address.
mktme_keyid_mask holds mask to extract KeyID from physical address.
Signed-off-by: Kirill A. Shutemov
--
Hi Ming,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/irq/core]
[also build test WARNING on v4.16-rc4 next-20180305]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Mon, Mar 05, 2018 at 04:55:56PM +0100, Peter Rosin wrote:
> On 2018-03-05 16:53, Wolfram Sang wrote:
> >
> >> @@ -97,59 +98,83 @@ static const struct chip_desc chips[] = {
> >>.nchans = 2,
> >>.enable = 0x4,
> >>.muxtype = pca954x_ismux,
> >> + .id =
This patch implements helpers to check if given VMA is encrypted and
with which KeyID.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/mktme.h | 14 ++
arch/x86/mm/mktme.c | 11 +++
2 files changed, 25 insertions(+)
diff --git a/arch/x86/include/asm/mktme
The patch adds new gfp flag to indicate that we're allocating encrypted
page.
Architectural code may need to do special preparation for encrypted
pages such as flushing cache to avoid aliasing.
Signed-off-by: Kirill A. Shutemov
---
include/linux/gfp.h| 12
include/linux
shmem/tmpfs uses pseudo vma to allocate page with correct NUMA policy.
The pseudo vma doesn't have vm_page_prot set. We are going to encode
encryption KeyID in vm_page_prot. Having garbage there causes problems.
Zero out all unused fields in the pseudo vma.
Signed-off-by: Kirill A. Shutemov
---
Hi everybody,
Here's updated version of my patchset that brings support of MKTME.
It's not yet complete, but I think it worth sharing to get early feedback.
Things that are missing:
- kmap() is not yet wired up to support tempoprary mappings of encrypted
pages. It's requried to allow kernel
Change page allocation path to pass __GFP_ENCRYPT on allocation pages
for encrypted VMAs.
There are two different path where __GFP_ENCRYPT has to be set. One for
kernel compiled with CONFIG_NUMA enabled and the second for kernel
without NUMA support.
Signed-off-by: Kirill A. Shutemov
---
includ
MKTME claims several upper bits of the physical address in a page table
entry to encode KeyID. It effectively shrinks number of bits for
physical address. We should exclude KeyID bits from physical addresses.
For instance, if CPU enumerates 52 physical address bits and number of
bits claimed for K
Pages for encrypted VMAs have to be allocated in a special way:
we would need to propagate down not only desired NUMA node but also
whether the page is encrypted.
It complicates not-so-trivial routine of huge page allocation in
khugepaged even more. I also puts more pressure on page allocator:
we
AMD SME claims one bit from physical address to indicate whether the
page is encrypted or not. To achieve that we clear out the bit from
__PHYSICAL_MASK.
The capability to adjust __PHYSICAL_MASK is required beyond AMD SME.
For instance for upcoming Intel Multi-Key Total Memory Encryption.
Let's f
MKTME enabling requires a way to find out which encryption KeyID has to
be used to access the page. There's not enough space in struct page to
store this information.
As a way out we can store it in anon_vma for the page: all pages in the
same anon_vma tree will be encrypted with the same KeyID.
MKTME_KEY_PROG allows to manipulate MKTME keys in the CPU.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/intel_pconfig.h | 50
1 file changed, 50 insertions(+)
diff --git a/arch/x86/include/asm/intel_pconfig.h
b/arch/x86/include/asm/intel_pconf
On 2 March 2018 at 12:26, Auger Eric wrote:
> Hi Marc,
> On 02/03/18 12:11, Marc Zyngier wrote:
>> On Fri, 02 Mar 2018 10:44:48 +,
>> Auger Eric wrote:
>>> I understand the get/set is called as part of the migration process.
>>> So my understanding is the benefit of this series is migration fa
Freeing encrypted pages may require special treatment such as flush
cache to avoid aliasing.
Anonymous pages cannot be mapped back once the last mapcount is gone.
That's a good place to add hook to free encrypted page. At later point
we may not have valid anon_vma around to get KeyID.
Signed-off-
CPUID.0x7.0x0:ECX[13] indicates whether CPU supports Intel Total Memory
Encryption.
Signed-off-by: Kirill A. Shutemov
---
arch/x86/include/asm/cpufeatures.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 3508318b
On Mon, Mar 5, 2018 at 5:25 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> It can happen that we enter the kernel from kernel-mode and
> on the entry-stack. The most common way this happens is when
> we get an exception while loading the user-space segment
> registers on the kernel-to-userspace
On Mon, Mar 05, 2018 at 09:51:29AM -0500, Brian Gerst wrote:
> For the IRET fault case you will still need to catch it in the
> exception code. See the 64-bit code (.Lerror_bad_iret) for example.
> For 32-bit, you could just expand that check to cover the whole exit
> prologue after the CR3 switch
Hi Shawn,
On 28 February 2018 01:53, Shawn Lin wrote:
> On 2018/2/27 23:05, Phil Edworthy wrote:
> > On 27 February 2018 14:42, Shawn Lin wrote:
> >> On 2018/2/27 22:31, Phil Edworthy wrote:
> >>> On 27 February 2018 14:28, Shawn Lin wrote:
> 在 2018/2/27 21:55, Phil Edworthy 写道:
> > Since
On 2 March 2018 at 11:11, Marc Zyngier wrote:
> On Fri, 02 Mar 2018 10:44:48 +,
> Auger Eric wrote:
>> I understand the get/set is called as part of the migration process.
>> So my understanding is the benefit of this series is migration fails in
>> those cases:
>>
>> >=0.2 source -> 0.1 desti
The "Power Architecture 64-Bit ELF V2 ABI" says in section 2.3.2.3:
[...] There are several rules that must be adhered to in order to ensure
reliable and consistent call chain backtracing:
* Before a function calls any other function, it shall establish its
own stack frame, whose size shall be
On Mon, Mar 05, 2018 at 04:36:20PM +0100, Thomas Ilsche wrote:
> I fear that might even create positive feedback loops on the
> heuristic, which will take into account the sleep durations for
> sched tick wakeups in sort of a self fulfilling prophecy:
> 1) The heuristic predicts to wake up in less
Patches look good to me.
Reviewed-by: Andi Kleen
Hi Rob
On 03/05/2018 04:28 PM, Rob Herring wrote:
> On Mon, Mar 5, 2018 at 9:00 AM, wrote:
>> From: Patrice Chotard
>>
>> Since dtc v1.4.6-9-gaadd0b65c987, aliases property name must
>> be lowercase only.
>> This allows to fix following warnings when compiling dtb
>> with W=1 option :
>
> I'm
In order to make struct tpm_buf the first class object for constructing TPM
commands, this patch set migrates all TPM 2.0 commands to use it. The next
step after this is to migrate TPM 1.2 commands in a subsequent patch set.
Finally, tpm_transmit_cmd() can take simply struct tpm_buf as its argument
In order to make struct tpm_buf the first class object for constructing TPM
commands, migrate tpm2_shutdown() to use it. In addition, removed the klog
entry when tpm_transmit_cmd() fails because tpm_tansmit_cmd() already
prints an error message.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tp
In order to make struct tpm_buf the first class object for constructing TPM
commands, migrate tpm2_get_tpm_pt() to use it.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm2-cmd.c | 63 +
1 file changed, 23 insertions(+), 40 deletions(-)
diff --
From: James Bottomley
My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
(necessitating a reboot). The problem seems to be that the TPM gets into a
state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
all tests have run to completion), but instead returns
In order to make struct tpm_buf the first class object for constructing
TPM commands, migrate tpm2_get_random() to use it. In addition, removed
remaining references to struct tpm2_cmd. All of them use it to acquire
the length of the response, which can be achieved by using
tpm_buf_length().
Signed
In order to make struct tpm_buf the first class object for constructing TPM
commands, migrate tpm2_probe() to use it.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm2-cmd.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/char/tpm/
Hi Will,
On 03/05/2018 09:56 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Fri, Mar 02, 2018 at 03:50:18PM -0600, Shanker Donthineni wrote:
>> The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
>> V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
>> the standard cal
... to avoid an unnecessary attach/detach of the iommu_group to the
newly created iommu_domain. This also saves us a context-cache and an
IOTLB flush.
This is possible because allocating an iommu_domain for the iommu_group
we're attaching is enough to understand whether a fitting iommu_domain
alr
On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote:
> +static inline bool page_encrypted(struct page *page)
> +{
> + /* All pages with non-zero KeyID are encrypted */
> + return page_keyid(page) != 0;
> +}
Is this true? I thought there was a KEYID_NO_ENCRYPT "Do not encrypt
memory when this
On Mon, Mar 05, 2018 at 05:49:28PM +0100, Torsten Duwe wrote:
> The "Power Architecture 64-Bit ELF V2 ABI" says in section 2.3.2.3:
>
> [...] There are several rules that must be adhered to in order to ensure
> reliable and consistent call chain backtracing:
>
> * Before a function calls any othe
On 03/05/2018 04:30 PM, Wolfram Sang wrote:
>
>> Is this patch under your radar? Should I keep pushing for it or just give up?
>
> Applied to for-next, thanks for your patience and your preparational
> work needed to get this upstream!
>
Great, thanks a lot for your help!
> We will see in linu
On 05/03/18 09:00 AM, Keith Busch wrote:
On Mon, Mar 05, 2018 at 12:33:29PM +1100, Oliver wrote:
On Thu, Mar 1, 2018 at 10:40 AM, Logan Gunthorpe wrote:
@@ -429,10 +429,7 @@ static void __nvme_submit_cmd(struct nvme_queue *nvmeq,
{
u16 tail = nvmeq->sq_tail;
- if (nvmeq->
Hi Linus,
Please pull the following Kselftest update for 4.16-rc5.
This kselftest fixes update has a fix for regression in memory-hotplug
install script that prevents the test from running on the target.
Diff for the update is attached.
thanks,
-- Shuah
The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
the standard call SMCCC_ARCH_WORKAROUND_1 for Falkor chips instead
of Silicon provider service ID 0xC2001700.
Signed-off-by: Shanker Donthineni
---
Chnages since v
101 - 200 of 1157 matches
Mail list logo
