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

2016-04-27 Thread Pavel Machek
Hi! > 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 w

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

2016-04-27 Thread Pavel Machek
On Tue 2016-04-26 17:56:14, Tom Lendacky wrote: > Provide the Kconfig support to build the SME support in the kernel. Probably should go last in the series? > Signed-off-by: Tom Lendacky > --- > arch/x86/Kconfig |9 + > 1 file changed, 9 insertions(+) > > diff --git a/arch/x86/Kco

Re: [RFC PATCH v1 03/18] x86: Secure Memory Encryption (SME) support

2016-04-27 Thread Pavel Machek
On Tue 2016-04-26 17:56:26, Tom Lendacky wrote: > Provide support for Secure Memory Encryption (SME). This initial support > defines the memory encryption mask as a variable for quick access and an > accessor for retrieving the number of physical addressing bits lost if > SME is enabled. > > Signe

Re: [RFC PATCH v1 18/18] x86: Add support to turn on Secure Memory Encryption

2016-04-27 Thread Pavel Machek
Hi! > This patch adds the support to check for and enable SME when available > on the processor and when the mem_encrypt=on command line option is set. > This consists of setting the encryption mask, calculating the number of > physical bits of addressing lost and encrypting the kernel "in place."

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

2016-04-27 Thread Pavel Machek
On Wed 2016-04-27 16:05:20, Borislav Petkov wrote: > On Tue, Mar 22, 2016 at 02:00:58PM +0100, Pavel Machek wrote: > > Why would I want SME on my system? My system seems to work without it. > > Your system doesn't have it and SME is default off. That does not answer the qu

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

2016-04-27 Thread Pavel Machek
On Wed 2016-04-27 16:39:51, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 04:30:45PM +0200, Pavel Machek wrote: > > That does not answer the question. "Why would I want SME on my > > system?". > > Because your question wasn't formulated properly. Here'

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

2016-04-27 Thread Pavel Machek
On Wed 2016-04-27 10:17:36, Tom Lendacky wrote: > On 03/22/2016 08:01 AM, Pavel Machek wrote: > > On Tue 2016-04-26 17:56:14, Tom Lendacky wrote: > >> Provide the Kconfig support to build the SME support in the kernel. > > > > > > Probably should go last

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

2016-04-27 Thread Pavel Machek
On Wed 2016-04-27 16:39:51, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 04:30:45PM +0200, Pavel Machek wrote: > > That does not answer the question. "Why would I want SME on my > > system?". > > Because your question wasn't formulated properly. Here'

Re: [RFC PATCH v1 02/18] x86: Secure Memory Encryption (SME) build enablement

2016-04-27 Thread Pavel Machek
On Wed 2016-04-27 17:41:40, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 05:30:10PM +0200, Pavel Machek wrote: > > Doing it early will break bisect, right? > > How exactly? Please do tell. Hey look, SME slowed down 30% since being initially mer

[PATCH] fix double ;;s in code

2018-02-17 Thread Pavel Machek
Fix double ;;'s in code. Signed-off-by: Pavel Machek diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c index 9d27331..ec12fe1 100644 --- a/arch/arc/kernel/setup.c +++ b/arch/arc/kernel/setup.c @@ -373,7 +373,7 @@ static void arc_chk_core_config(void) { struct cpuinf

Re: [PATCH] fix double ;;s in code

2018-02-19 Thread Pavel Machek
On Mon 2018-02-19 16:41:35, Daniel Vetter wrote: > On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote: > > > > > > Le 17/02/2018 à 22:19, Pavel Machek a écrit : > > > > > > Fix double ;;'s in code. > > > > > > Signed-

Re: [PATCH] fix double ;;s in code

2018-02-24 Thread Pavel Machek
Hi! > > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c > > index 53f7275..cfb42f5 100644 > > --- a/drivers/soc/imx/gpc.c > > +++ b/drivers/soc/imx/gpc.c > > @@ -348,7 +348,7 @@ static int imx_gpc_old_dt_init(struct device *dev, > > struct regmap *regmap, > > if (i == 1) {

Re: [PATCH 4.19 17/32] iommu/vt-d: Dont queue_iova() if there is no flush queue

2019-08-03 Thread Pavel Machek
Hi! > --- a/drivers/iommu/intel-iommu.c > +++ b/drivers/iommu/intel-iommu.c > @@ -3721,7 +3721,7 @@ static void intel_unmap(struct device *d > > freelist = domain_unmap(domain, start_pfn, last_pfn); > > - if (intel_iommu_strict) { > + if (intel_iommu_strict || !has_iova_flush_que

Re: [PATCH v2 0/7] Tighten PCI security, expose dev location in sysfs

2020-07-06 Thread Pavel Machek
Hi! > * The first 3 patches tighten the PCI security using ACS, and take care > of a border case. > * The 4th patch takes care of PCI bug. > * 5th and 6th patches expose a device's location into the sysfs to allow > admin to make decision based on that. I see no patch for Documentation -- new

Re: [RFC PATCH 1/7] vfio/spimdev: Add documents for WarpDrive framework

2018-08-06 Thread Pavel Machek
Hi! > WarpDrive is a common user space accelerator framework. Its main component > in Kernel is called spimdev, Share Parent IOMMU Mediated Device. It exposes spimdev is really unfortunate name. It looks like it has something to do with SPI, but it does not. > +++ b/Documentation/warpdrive/war