Re: [PATCH 1/1 V2] AMD Family15h Model10-1Fh erratum 746 Workaround

2013-01-24 Thread Borislav Petkov
On Wed, Jan 23, 2013 at 12:13:28PM -0600, suravee.suthikulpa...@amd.com wrote: From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com Changes from V1: * Fix logic that check the processor model. * Clear writing enable bit after apply the workaround * Change function name You need a

Re: [PATCH V4] IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround

2013-01-24 Thread Borislav Petkov
](D0F2xF4_x90[2]) = 1b. This patch corrects that for those which do not enable this workaround. Signed-off-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com Acked-by: Borislav Petkov b...@suse.de Thanks for the good work. -- Regards/Gruss, Boris. Sent from a fat crate under my desk

Re: [PATCH 1/3] iommu/amd: Add logic to decode AMD IOMMU event flag

2013-04-02 Thread Borislav Petkov
On Tue, Apr 02, 2013 at 04:33:36PM +0200, Joerg Roedel wrote: Hi Suravee, On Wed, Mar 27, 2013 at 06:51:23PM -0500, suravee.suthikulpa...@amd.com wrote: From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com Add logic to decode AMD IOMMU event flag based on information from AMD

Re: [PATCH 1/3] iommu/amd: Add logic to decode AMD IOMMU event flag

2013-04-02 Thread Borislav Petkov
On Tue, Apr 02, 2013 at 05:03:04PM +0200, Joerg Roedel wrote: On Tue, Apr 02, 2013 at 04:40:37PM +0200, Borislav Petkov wrote: While you guys are at it, can someone fix this too pls (ASUS board with a PD on it). [0.220342] [Firmware Bug]: AMD-Vi: IOAPIC[9] not in IVRS table

Re: [PATCH V3] iommu/amd: Add logic to decode AMD IOMMU event flag

2013-04-08 Thread Borislav Petkov
On Mon, Apr 08, 2013 at 02:33:32PM +, Suthikulpanit, Suravee wrote: Joerg, Do you have any more feedback about this patch? Thanks, Suravee From: suravee.suthikulpa...@amd.com [suravee.suthikulpa...@amd.com] Sent: Tuesday, April 02, 2013

Re: [PATCH] intel-iommu: Fix leaks in pagetable freeing

2013-10-02 Thread Borislav Petkov
the pagetables, but does it without any apparent performance loss versus the current broken version. Signed-off-by: Alex Williamson alex.william...@redhat.com Reviewed-by: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Joerg Roedel j...@8bytes.org Signed-off-by: Borislav Petkov b...@suse.de

Re: [PATCH] x86, irq: Keep IRQ assignment for PCI devices during suspend/hibernation

2014-07-31 Thread Borislav Petkov
Hi, On Thu, Jul 31, 2014 at 10:41:36PM +0800, Jiang Liu wrote: Really appreciate your help. There are two issues left according to the log messages. first of all: A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A:

Re: [PATCH] iommu/amd: Implement syscore_ops.shutdown()

2014-08-04 Thread Borislav Petkov
On Sat, Aug 02, 2014 at 10:25:39AM +0800, Jiang Liu wrote: During hibernation or shutdown, AMD iommu generates warnings on some platforms as below: [ 89.089832] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 domain=0x0009 address=0x0080 flags=0x0020] [ 89.102239] AMD-Vi:

Re: [PATCH] iommu/vt-d: Do not BUG_ON in intel_unmap if no domain

2014-08-04 Thread Borislav Petkov
On Mon, Aug 04, 2014 at 01:23:06PM +0200, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de This BUG_ON is easy to trigger with device-hotplug (e.g. SR-IOV). The device_notifier function in the Intel IOMMU driver listens to the BUS_NOTIFY_DEL_DEVICE event and frees the domain for the

Re: [PATCH V3 2/2] debugfs: don't assume sizeof(bool) to be 4 bytes

2015-09-16 Thread Borislav Petkov
On Tue, Sep 15, 2015 at 01:47:32PM -0400, Steven Rostedt wrote: > What do others think when there's a change that goes across the board > this much? BCC OK with you, as just an FYI, I'm doing this? Or should > just the lists be enough and if you don't see it, too bad? Bcc sounds good to me.

Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak

2015-12-02 Thread Borislav Petkov
On Wed, Dec 02, 2015 at 05:36:32PM +, Catalin Marinas wrote: > Defending kmemleak here ;). Oh sure, by all means. I'm also assuming it comes across that I wasn't attacking kmemleak. I had the same arguments with KASAN and other stuff in the past. > Tracking page allocations in kmemleak by

Re: [PATCH 2/9] 8250/Kconfig: add config option CONFIG_SERIAL_8250_AMD

2015-12-04 Thread Borislav Petkov
On Fri, Dec 04, 2015 at 11:24:19AM +0800, Wang Hongcheng wrote: > Add config option CONFIG_SERIAL_8250_AMD in use of AMD carrizo. > Because carrizo's UART DMA device is an amba device, it selects > ARM_AMBA option. Anything uses amba devices must select ARM_AMBA. > > Signed-off-by: Wang

Re: [PATCH 8/9] Documentation: Add ivrs_acpihid kernel parameter description

2015-12-04 Thread Borislav Petkov
On Fri, Dec 04, 2015 at 11:24:25AM +0800, Wang Hongcheng wrote: > From: Wan Zongshun > > Add ivrs_acpihid kernel parameter description, > like ivrs_acpihid[00:14.5]=AMD0020:0. > > Signed-off-by: Wan Zongshun > --- > Documentation/kernel-parameters.txt

Re: [PATCH 8/9] Documentation: Add ivrs_acpihid kernel parameter description

2015-12-04 Thread Borislav Petkov
On Fri, Dec 04, 2015 at 01:19:35PM +, Wan, Vincent wrote: > > > + ivrs_acpihid[HW,X86_64] > > > + Provide an override to the ACPI-HID:UID<->DEVICE-ID > > > + mapping provided in the IVRS ACPI table. For > > > + example, to map UART-HID:UID

Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak

2015-12-02 Thread Borislav Petkov
On Wed, Dec 02, 2015 at 02:18:44PM +0100, Michael Wang wrote: > Do you mean this could be a real kmemleak? Could you please provide > more details? Did you read Joerg's last mail? > Yeah, but it would be better to solve it, otherwise whoever saw this > report will need to go into the amd-iommu,

Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak

2015-12-02 Thread Borislav Petkov
On Wed, Dec 02, 2015 at 01:31:38PM +0100, Michael Wang wrote: > It's not my work or your work... it's a defect in the module and maintainer > should take responsibility on fixing it, correct? Well, you said "actually we just want to get rid of this annoying report on obj won't leak..." It sounds

Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak

2015-12-02 Thread Borislav Petkov
On Wed, Dec 02, 2015 at 02:01:55PM +0100, Michael Wang wrote: > Yeah.. it's a little complicated since we have our own kernel tree and this > won't be a problem for us, but we really prefer to help fix it in mainline > too, as long as this is really a defect, so others could save time on research

Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak

2015-12-02 Thread Borislav Petkov
On Wed, Dec 02, 2015 at 02:48:47PM +0100, Michael Wang wrote: > I'm not sure why amd-iommu use get_page not kmalloc to initialize the > pointer table, but if it's necessary then the conflict will be there, > it's not the fault of driver or kmemleak, but the design require them > to cooperate with

Re: [RFC PATCH v2] iommu/amd: gray the 'irq_remap_table' object for kmemleak

2015-12-02 Thread Borislav Petkov
On Wed, Dec 02, 2015 at 03:09:18PM +0100, Michael Wang wrote: > This tool will help improve the kernel, AFAIK it's already made it's > best, if you got any idea on how to make it even better that would be > great, but at this moment, it still need few of care :-P I think you're replying to my

Re: [PATCH 2/2] iommu/amd: Destroy api_lock mutex when freeing domain

2016-06-15 Thread Borislav Petkov
On Wed, Jun 15, 2016 at 05:53:15PM +, Vesely, Jan wrote: > There are no specific bugs/oopses that these patches fix (that I'm > aware of). Both were found while I was familiarizing myself with the > code looking for memory corruption (which turned out to be [0]). > Either issue would be very

Re: [PATCH V3 1/5] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header

2016-02-10 Thread Borislav Petkov
On Thu, Feb 11, 2016 at 01:42:52AM +0700, Suravee Suthikulpanit wrote: > The reason I picked this location to place the header file is because > there is already an existing include/linux/perf/arm_pmu.h file there. I don't think anything arch-specific belongs in generic kernel header paths. >

Re: [PATCH V3 1/5] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header

2016-02-10 Thread Borislav Petkov
On Thu, Feb 11, 2016 at 01:56:43AM +0700, Suravee Suthikulpanit wrote: > Ah.. agree then ;) So, I should branch off that tree of yours with the file > already moved. Could you point me to it? Not my tree, tip/master: http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git, the master branch.

Re: [PATCH V4 2/6] perf/amd/iommu: Modify functions to query max banks and counters

2016-02-18 Thread Borislav Petkov
On Thu, Feb 11, 2016 at 04:15:23PM +0700, Suravee Suthikulpanit wrote: > Currently, amd_iommu_pc_get_max_[banks|counters]() require devid, > which should not be the case. Why? Commit message could use an explanation. > Also, these don't properly support > multi-IOMMU system. > > Current and

Re: [PATCH V4 4/6] perf/amd/iommu: Introduce get_iommu_bnk_cnt_evt_idx

2016-02-18 Thread Borislav Petkov
On Thu, Feb 11, 2016 at 04:15:25PM +0700, Suravee Suthikulpanit wrote: > Introduce a helper function to calculate bit-index for assigning > performance counter assignment. > > Signed-off-by: Suravee Suthikulpanit > --- > arch/x86/events/amd/iommu.c | 19

Re: [PATCH V4 5/6] perf/amd/iommu: Enable support for multiple IOMMUs

2016-02-18 Thread Borislav Petkov
On Thu, Feb 11, 2016 at 04:15:26PM +0700, Suravee Suthikulpanit wrote: > The current amd_iommu_pc_get_set_reg_val() does not support muli-IOMMU multi > system. This patch replace amd_iommu_pc_get_set_reg_val() with You don't need to say in the commit message what this patch does - I think most

Re: [PATCH V4 6/6] perf/amd/iommu: Clean up print messages pr_debug

2016-02-18 Thread Borislav Petkov
On Thu, Feb 11, 2016 at 04:15:27PM +0700, Suravee Suthikulpanit wrote: > From: Suravee Suthikulpanit > > This patch declares pr_fmt for perf/amd_iommu, removes unnecessary > pr_debug, and clean up error messages. For the next version, move all the cleanups first

Re: [PATCH V5 02/10] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header

2016-03-18 Thread Borislav Petkov
On Fri, Mar 18, 2016 at 05:06:23PM +0700, Suravee Suthikulpanit wrote: > If not here, where would you prefer? Consolidating it to > arch/x86/include/asm/amd-iommu.h)? > > And if that's the case, should I also move include/linux/amd-iommu.h as > well? Yeah, so arch/x86/include/asm/ has all the

Re: [PATCH V5 02/10] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header

2016-03-15 Thread Borislav Petkov
On Tue, Mar 15, 2016 at 07:39:31AM +0700, Suravee Suthikulpanit wrote: > What if I just merge the newly introduced arch/x86/include/perf/amd/iommu.h > into the include/linux/amd-iommu.h? I do not see the point of having to > separate things out into two files. Except that this header has

Re: [PATCH V5 02/10] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header

2016-03-14 Thread Borislav Petkov
On Mon, Mar 14, 2016 at 08:37:02PM +0700, Suravee Suthikulpanit wrote: > Basically, we are trying to match the current Perf hierarchy for AMD IOMMU > (arch/x86/events/amd/iommu.c). I can put it into > arch/x86/include/asm/perf_amd_iommu.h. What would you prefer? Yeah, I was going to say the same

Re: [PATCH V5 02/10] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header

2016-03-19 Thread Borislav Petkov
On Fri, Mar 18, 2016 at 02:07:25PM +0700, Suravee Suthikulpanit wrote: > Actually the exposed APIs (in both files) are from the AMD IOMMU driver, > which is not necessary x86-specific. They mostly use struct pci_dev, which > is also arch-agnostic. It is correct that the current IOMMU IP is only >

Re: [PATCH V5 02/10] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header

2016-03-20 Thread Borislav Petkov
On Fri, Mar 18, 2016 at 12:11:01PM +0100, Joerg Roedel wrote: > On Fri, Mar 18, 2016 at 11:39:18AM +0100, Borislav Petkov wrote: > > Yeah, so arch/x86/include/asm/ has all the x86-specific stuff which is > > not exported to userspace, so moving stuff there makes sense to me. >

Re: [PATCH V5 02/10] perf/amd/iommu: Consolidate and move perf_event_amd_iommu header

2016-03-20 Thread Borislav Petkov
On Fri, Mar 18, 2016 at 04:09:33PM +0700, Suravee Suthikulpanit wrote: > But the whole point is that since we are moving it to consolidate these > duplicated declarations, I think we should just put it in the most common > place. The include/linux/amd-iommu.h file is already there. It's not like

[PATCH 07/10] x86/cpufeature: Remove cpu_has_apic

2016-04-04 Thread Borislav Petkov
From: Borislav Petkov <b...@suse.de> Signed-off-by: Borislav Petkov <b...@suse.de> Cc: oprofile-l...@lists.sf.net Cc: iommu@lists.linux-foundation.org Cc: linux...@vger.kernel.org --- arch/x86/events/core.c | 2 +- arch/x86/include/asm/cpufeature.h| 1

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

2016-04-27 Thread Borislav Petkov
On Wed, Apr 27, 2016 at 06:41:37PM +0200, Pavel Machek wrote: > Hey look, SME slowed down 30% since being initially merged into > kernel! How is that breaking bisection? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___

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

2016-04-27 Thread Borislav Petkov
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. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ iommu mailing list

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

2016-04-27 Thread Borislav Petkov
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. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

2016-05-10 Thread Borislav Petkov
On Tue, May 10, 2016 at 02:43:58PM +0100, Matt Fleming wrote: > Is it not possible to maintain some kind of kernel virtual address > mapping so memremap*() and friends can figure out when to twiddle the > mapping attributes and map with/without encryption? I guess we can move the sme_* specific

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

2016-05-10 Thread Borislav Petkov
On Tue, May 10, 2016 at 01:23:35PM +0200, Paolo Bonzini wrote: > It can send plaintext packets that will be stored encrypted in memory. > (Of course the hypervisor can do that too if it has access to the guest > network). And then what? You need to find out where exactly (which pages) got the

Re: [PATCH v9 8/8] perf/amd/iommu: Enable support for multiple IOMMUs

2017-02-08 Thread Borislav Petkov
s/amd_iommu_x > > where x is the IOMMU index. This allows users to specify > different events to be programmed onto performance counters > of each IOMMU. > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Borislav Petkov <b...@alien8.de> > Signed-

Re: [PATCH v9 5/8] perf/amd/iommu: Modify functions to query max banks and counters

2017-02-08 Thread Borislav Petkov
MU > perf implementation only supports a single IOMMU. A subsequent > patch will add support for multiple IOMMUs, and will use a proper IOMMU index. > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Joerg Roedel &l

Re: [PATCH v9 6/8] perf/amd/iommu: Modify amd_iommu_pc_get_set_reg_val() to allow specifying IOMMU

2017-02-08 Thread Borislav Petkov
repares the driver > for supporting multi-IOMMU in subsequent patch. > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Joerg Roedel <j...@8bytes.org> > Signed-off-by: Suravee Suthikulpanit <suravee.suthik

Re: [PATCH v8 7/9] perf/amd/iommu: Check return value when set and get counter value

2017-01-22 Thread Borislav Petkov
the PMU. > > Also, in perf_iommu_read(), we need to check the return value from > amd_iommu_get_reg() before using the value. So basically you wanna say: "Add amd_iommu_{g,s}et_reg() error handling." > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Borislav Petkov

Re: [PATCH v8 6/9] perf/amd/iommu: Modify amd_iommu_pc_get_set_reg_val() API to allow specifying IOMMU index

2017-01-22 Thread Borislav Petkov
_iommu_proto.h. > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Joerg Roedel <j...@8bytes.org> > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> > --- > arch/x86/events/amd

Re: [PATCH v8 5/9] perf/amd/iommu: Modify functions to query max banks and counters

2017-01-22 Thread Borislav Petkov
eclaration in > amd_iommu_proto.h. This sentence can go away: never write "what" the patch is doing - always "why" it is doing it. > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Borislav Petkov <b...@alien8.de> > Cc: Joerg Roedel <j...@8bytes.org>

Re: [PATCH v8 8/9] perf/amd/iommu: Fix sysfs perf attribute groups

2017-01-22 Thread Borislav Petkov
On Mon, Jan 16, 2017 at 01:23:35AM -0600, Suravee Suthikulpanit wrote: > From: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> > > Introduce static amd_iommu_attr_groups to simplify the > sysfs attributes initialization code. > > Cc: Peter Zijlstra <pet...@in

Re: [PATCH v8 9/9] perf/amd/iommu: Enable support for multiple IOMMUs

2017-01-22 Thread Borislav Petkov
s/amd_iommu_x > > where x is the IOMMU index. This allows users to specify > different events to be programed onto performance counters "programmed" Please introduce a spellchecker into your patch creation workflow. > of each IOMMU. > > Cc: Peter Zijlstra <pet.

Re: [PATCH v8 9/9] perf/amd/iommu: Enable support for multiple IOMMUs

2017-01-25 Thread Borislav Petkov
On Wed, Jan 25, 2017 at 10:46:53AM +0100, Peter Zijlstra wrote: > Which is absolutely insane. Right, IMO, the simplest thing to do for your purposes is to embed a struct amd_iommu pointer into struct perf_amd_iommu at init time so that you don't have to do all that crazy dance in the PMU

Re: [RFC PATCH v4 06/28] x86: Add support to enable SME during early boot processing

2017-02-21 Thread Borislav Petkov
On Tue, Feb 21, 2017 at 08:55:30AM -0600, Tom Lendacky wrote: > Actually, %rbp will have the encryption bit set in it at the time of the > check so if SME is active we won't take the jump to .Lskip_fixup. Ha, I didn't think of that! Do you see now what I mean with being explicit in the asm boot

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

2017-02-21 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:45:09AM -0600, Tom Lendacky wrote: > Boot data (such as EFI related data) is not encrypted when the system is > booted and needs to be mapped decrypted. Add support to apply the proper > attributes to the EFI page tables and to the early_memremap and memremap > APIs to

Re: [RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption

2017-02-22 Thread Borislav Petkov
On Tue, Feb 21, 2017 at 11:18:08AM -0600, Tom Lendacky wrote: > It's the latter. It's really only used for working with values that > will either be written to or read from cr3. I'll add some comments > around the macros as well as expand on it in the commit message. Ok, that makes sense.

Re: [RFC PATCH v4 06/28] x86: Add support to enable SME during early boot processing

2017-02-20 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:43:19AM -0600, Tom Lendacky wrote: > This patch adds support to the early boot code to use Secure Memory > Encryption (SME). Support is added to update the early pagetables with > the memory encryption mask and to encrypt the kernel in place. > > The routines to set

Re: [RFC PATCH v4 08/28] x86: Extend the early_memremap support with additional attrs

2017-02-20 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:43:48AM -0600, Tom Lendacky wrote: > Add to the early_memremap support to be able to specify encrypted and early_memremap() Please append "()" to function names in your commit messages text. > decrypted mappings with and without write-protection. The use of >

Re: [RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption

2017-02-20 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote: > Adding general kernel support for memory encryption includes: > - Modify and create some page table macros to include the Secure Memory > Encryption (SME) memory encryption mask Let's not write it like some technical document:

Re: [RFC PATCH v4 07/28] x86: Provide general kernel support for memory encryption

2017-02-20 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:43:32AM -0600, Tom Lendacky wrote: > Adding general kernel support for memory encryption includes: > - Modify and create some page table macros to include the Secure Memory > Encryption (SME) memory encryption mask > - Modify and create some macros for calculating

Re: [RFC PATCH v4 09/28] x86: Add support for early encryption/decryption of memory

2017-02-20 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:43:58AM -0600, Tom Lendacky wrote: > Add support to be able to either encrypt or decrypt data in place during > the early stages of booting the kernel. This does not change the memory > encryption attribute - it is used for ensuring that data present in either > an

Re: [RFC PATCH v4 10/28] x86: Insure that boot memory areas are mapped properly

2017-02-20 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:44:11AM -0600, Tom Lendacky wrote: > The boot data and command line data are present in memory in a decrypted > state and are copied early in the boot process. The early page fault > support will map these areas as encrypted, so before attempting to copy > them, add

Re: [RFC PATCH v4 11/28] x86: Add support to determine the E820 type of an address

2017-02-20 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:44:30AM -0600, Tom Lendacky wrote: > This patch adds support to return the E820 type associated with an address s/This patch adds/Add/ > range. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/e820/api.h |2 ++ >

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

2017-02-24 Thread Borislav Petkov
On Thu, Feb 23, 2017 at 03:34:30PM -0600, Tom Lendacky wrote: > Hmm... maybe I'm missing something here. This doesn't have anything to > do with kexec or efi_reuse_config. This has to do with the fact that I said kexec because kexec uses the setup_data mechanism to pass config tables to the

Re: [RFC PATCH v4 14/28] Add support to access boot related data in the clear

2017-02-24 Thread Borislav Petkov
On Fri, Feb 24, 2017 at 09:04:21AM -0600, Tom Lendacky wrote: > I looked at doing that but you get into this cyclical situation unless > you specifically map each setup data elemement as decrypted. This is ok > for early_memremap since we have early_memremap_decrypted() but a new >

Re: [RFC PATCH v4 05/28] x86: Add Secure Memory Encryption (SME) support

2017-02-25 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:43:07AM -0600, Tom Lendacky wrote: > Add support for Secure Memory Encryption (SME). This initial support > provides a Kconfig entry to build the SME support into the kernel and > defines the memory encryption mask that will be used in subsequent > patches to mark pages

Re: [RFC PATCH v4 18/28] x86: DMA support for memory encryption

2017-02-25 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:46:04AM -0600, Tom Lendacky wrote: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to

Re: [RFC PATCH v4 16/28] x86: Add support for changing memory encryption attribute

2017-02-22 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:45:35AM -0600, Tom Lendacky wrote: > Add support for changing the memory encryption attribute for one or more > memory pages. "This will be useful when we, , for example." > Signed-off-by: Tom Lendacky > --- >

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

2017-02-18 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:41:59AM -0600, Tom Lendacky wrote: > create mode 100644 Documentation/x86/amd-memory-encryption.txt > create mode 100644 arch/x86/include/asm/mem_encrypt.h > create mode 100644 arch/x86/kernel/mem_encrypt_boot.S > create mode 100644 arch/x86/kernel/mem_encrypt_init.c

Re: [RFC PATCH v4 00/28] x86: Secure Memory Encryption (AMD)

2017-02-21 Thread Borislav Petkov
On Tue, Feb 21, 2017 at 12:42:45PM -0500, Rik van Riel wrote: > Do we want that in kernel/ or in arch/x86/mm/ ? If you'd ask me, I don't have a strong preference. It is a pile of functionality which is part of the SME feature and as such, it is closer to the CPU. So arch/x86/cpu/sme.c or so. But

Re: [PATCH v9 8/8] perf/amd/iommu: Enable support for multiple IOMMUs

2017-02-15 Thread Borislav Petkov
On Wed, Feb 15, 2017 at 02:13:29PM +0700, Suravee Suthikulpanit wrote: > > So you can define a static struct pmu in the driver and do struct > > assignment directly instead of writing them one-by-one. > > I believe this is the same suggestion you have made in V8. Here's what I mean: --- diff

Re: [PATCH v9 0/8] perf/amd/iommu: Enable multi-IOMMU support

2017-02-15 Thread Borislav Petkov
On Tue, Feb 07, 2017 at 02:40:28AM -0600, Suravee Suthikulpanit wrote: > From: Suravee Suthikulpanit > > This patch series modifies the existing IOMMU and Perf drivers to support > systems with multiple IOMMUs by allocating an amd_iommu PMU per IOMMU > instance. >

Re: [PATCH v9 0/8] perf/amd/iommu: Enable multi-IOMMU support

2017-02-15 Thread Borislav Petkov
On Wed, Feb 15, 2017 at 11:44:24AM +0100, Jiri Olsa wrote: > does it say unsupported when you omit -a? Yeah, it does dump the event name like it was counting but then it says . For example: amd_iommu_0/... > [jolsa@krava perf]$ ./perf stat -e 'cpu/cpu-cycles/' ^ Haha, I

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

2017-02-16 Thread Borislav Petkov
Ok, this time detailed review :-) On Thu, Feb 16, 2017 at 09:42:11AM -0600, Tom Lendacky wrote: > This patch adds a Documenation entry to decribe the AMD Secure Memory > Encryption (SME) feature. Please introduce a spellchecker into your patch creation workflow. I see two typos in one line.

Re: [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature

2017-02-16 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:42:36AM -0600, Tom Lendacky wrote: > Update the CPU features to include identifying and reporting on the > Secure Memory Encryption (SME) feature. SME is identified by CPUID > 0x801f, but requires BIOS support to enable it (set bit 23 of > SYS_CFG MSR). Only show

Re: [RFC PATCH v4 03/28] x86: Add the Secure Memory Encryption CPU feature

2017-02-16 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 01:42:13PM -0600, Tom Lendacky wrote: > I realize it's a bit more code and expands the changes but I thought it > would be a bit clearer as to what was going on this way. And then the > follow on patch for the physical address reduction goes in nicely, too. Well, the code

Re: [RFC PATCH v4 05/28] x86: Add Secure Memory Encryption (SME) support

2017-02-17 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:43:07AM -0600, Tom Lendacky wrote: > Add support for Secure Memory Encryption (SME). This initial support > provides a Kconfig entry to build the SME support into the kernel and > defines the memory encryption mask that will be used in subsequent > patches to mark pages

Re: [RFC PATCH v4 04/28] x86: Handle reduction in physical address size with SME

2017-02-17 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:42:54AM -0600, Tom Lendacky wrote: > When System Memory Encryption (SME) is enabled, the physical address > space is reduced. Adjust the x86_phys_bits value to reflect this > reduction. > > Signed-off-by: Tom Lendacky > --- >

Re: [RFC PATCH v4 02/28] x86: Set the write-protect cache mode for full PAT support

2017-02-17 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:42:25AM -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 <b...@suse.de> > Signed-off-by: Tom L

Re: [PATCH v8 3/9] perf/amd/iommu: Misc fix up perf_iommu_read

2017-01-19 Thread Borislav Petkov
one doesn't read like a sentence. > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Borislav Petkov <b...@alien8.de> > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> > --- > arch/x86/events/amd/iommu.c | 23 --- > 1 file c

Re: [PATCH v8 2/9] perf/amd/iommu: Clean up perf_iommu_enable_event

2017-01-18 Thread Borislav Petkov
t is a function. > * Make use macros BIT(x) "Make use"? > This should not affect logic and functionality. > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Borislav Petkov <b...@alien8.de> > Signed-off-by: Suravee Suthikulpanit <suravee.suthik

Re: [PATCH v8 4/9] iommu/amd: Introduce amd_iommu_get_num_iommus()

2017-01-19 Thread Borislav Petkov
as static. > > This function will also be used by Perf AMD IOMMU driver. > > Cc: Borislav Petkov <b...@alien8.de> > Cc: Joerg Roedel <j...@8bytes.org> > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> > --- > arch/x86/events/amd/iommu.h

Re: [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME

2017-03-01 Thread Borislav Petkov
On Tue, Feb 28, 2017 at 05:19:51PM -0600, Tom Lendacky wrote: > Device drivers don't supply set_dma_mask() since that is part of the > dma_map_ops structure. The fm10k_pf.c file function is unrelated to this > (it's part of an internal driver structure). The dma_map_ops structure > is setup by the

Re: [RFC PATCH v4 21/28] x86: Check for memory encryption on the APs

2017-03-01 Thread Borislav Petkov
On Tue, Feb 28, 2017 at 05:28:48PM -0600, Tom Lendacky wrote: > That's a good idea, I'll expand on that. I probably won't be that > direct in my comment though :) You either haven't dealt with firmware long enough or you're much better person than me. :-))) -- Regards/Gruss, Boris. Good

Re: [RFC PATCH v4 27/28] x86: Add support to encrypt the kernel in-place

2017-03-01 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:48:08AM -0600, Tom Lendacky wrote: > This patch adds the support to encrypt the kernel in-place. This is > done by creating new page mappings for the kernel - a decrypted > write-protected mapping and an encrypted mapping. The kernel is encyrpted s/encyrpted/encrypted/

Re: [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME

2017-02-27 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:46:19AM -0600, Tom Lendacky wrote: > Add warnings to let the user know when bounce buffers are being used for > DMA when SME is active. Since the bounce buffers are not in encrypted > memory, these notifications are to allow the user to determine some > appropriate

Re: [RFC PATCH v4 21/28] x86: Check for memory encryption on the APs

2017-02-27 Thread Borislav Petkov
On Thu, Feb 16, 2017 at 09:46:47AM -0600, Tom Lendacky wrote: > Add support to check if memory encryption is active in the kernel and that > it has been enabled on the AP. If memory encryption is active in the kernel > but has not been enabled on the AP, then set the SYS_CFG MSR bit to enable >

Re: [RFC PATCH v2 02/20] x86: Set the write-protect cache mode for full PAT support

2016-08-24 Thread Borislav Petkov
arch/x86/mm/pat.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: Borislav Petkov <b...@suse.de> -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- ___ iommu mailing list iommu

Re: [RFC PATCH v2 05/20] x86: Add the Secure Memory Encryption cpu feature

2016-09-02 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:36:22PM -0500, Tom Lendacky wrote: > Update the cpu features to include identifying and reporting on the > Secure Memory Encryption feature. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/cpufeature.h|7 +-- >

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

2016-09-02 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: > Adding general kernel support for memory encryption includes: > - Modify and create some page table macros to include the Secure Memory > Encryption (SME) memory encryption mask > - Update kernel boot support to call an SME routine

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

2016-09-05 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: > Adding general kernel support for memory encryption includes: > - Modify and create some page table macros to include the Secure Memory > Encryption (SME) memory encryption mask > - Update kernel boot support to call an SME routine

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

2016-09-05 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:36:46PM -0500, Tom Lendacky wrote: > Adding general kernel support for memory encryption includes: > - Modify and create some page table macros to include the Secure Memory > Encryption (SME) memory encryption mask > - Update kernel boot support to call an SME routine

Re: [RFC PATCH v2 09/20] x86: Add support for early encryption/decryption of memory

2016-09-06 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:37:10PM -0500, Tom Lendacky wrote: > This adds support to be able to either encrypt or decrypt data during > the early stages of booting the kernel. This does not change the memory > encryption attribute - it is used for ensuring that data present in > either an

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

2016-09-02 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:35:39PM -0500, Tom Lendacky wrote: > This patch adds a Documenation entry to decribe the AMD Secure Memory > Encryption (SME) feature. > > Signed-off-by: Tom Lendacky > --- > Documentation/x86/amd-memory-encryption.txt | 35 >

Re: [RFC PATCH v2 03/20] x86: Secure Memory Encryption (SME) build enablement

2016-09-02 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:35:59PM -0500, Tom Lendacky wrote: > Provide the Kconfig support to build the SME support in the kernel. > > Signed-off-by: Tom Lendacky > --- > arch/x86/Kconfig |9 + > 1 file changed, 9 insertions(+) > > diff --git

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

2016-09-08 Thread Borislav Petkov
On Thu, Sep 08, 2016 at 08:26:27AM -0500, Tom Lendacky wrote: > When does this value get initialized? Since _PAGE_ENC is #defined to > sme_me_mask, which is not set until the boot process begins, I'm afraid > we'd end up using the initial value of sme_me_mask, which is zero. Do > I have that

Re: [RFC PATCH v2 07/20] x86: Provide general kernel support for memory encryption

2016-09-07 Thread Borislav Petkov
On Wed, Sep 07, 2016 at 09:30:54AM -0500, Tom Lendacky wrote: > _PAGE_ENC is #defined as sme_me_mask and sme_me_mask has already been > set (or not set) at this point - so it will be the mask if SME is > active or 0 if SME is not active. Yeah, I remember :-) > sme_early_init() is merely

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

2016-09-07 Thread Borislav Petkov
On Wed, Sep 07, 2016 at 09:02:38AM -0500, Tom Lendacky wrote: > Ugh.. I thought I caught all of these. Obviously not. I'll go through > all the patches on this. What you could do is run all patches through scripts/checkpatch.pl and fix those issues which make sense to you. What I'm saying is,

Re: [RFC PATCH v2 11/20] mm: Access BOOT related data in the clear

2016-09-09 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:37:38PM -0500, Tom Lendacky wrote: > BOOT data (such as EFI related data) is not encyrpted when the system is > booted and needs to be accessed as non-encrypted. Add support to the > early_memremap API to identify the type of data being accessed so that > the proper

Re: [RFC PATCH v2 10/20] x86: Insure that memory areas are encrypted when possible

2016-09-09 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:37:23PM -0500, Tom Lendacky wrote: > Encrypt memory areas in place when possible (e.g. zero page, etc.) so > that special handling isn't needed afterwards. > > Signed-off-by: Tom Lendacky > --- > arch/x86/kernel/head64.c | 93 >

Re: [RFC PATCH v2 14/20] x86: DMA support for memory encryption

2016-09-12 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:38:07PM -0500, Tom Lendacky wrote: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to

Re: [RFC PATCH v2 15/20] iommu/amd: AMD IOMMU support for memory encryption

2016-09-12 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:38:20PM -0500, Tom Lendacky wrote: > Add support to the AMD IOMMU driver to set the memory encryption mask if > memory encryption is enabled. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/mem_encrypt.h |2 ++ >

Re: [RFC PATCH v2 16/20] x86: Check for memory encryption on the APs

2016-09-12 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:38:29PM -0500, Tom Lendacky wrote: > Add support to check if memory encryption is active in the kernel and that > it has been enabled on the AP. If memory encryption is active in the kernel > but has not been enabled on the AP then do not allow the AP to continue > start

Re: [RFC PATCH v2 19/20] x86: Access the setup data through debugfs un-encrypted

2016-09-14 Thread Borislav Petkov
On Wed, Sep 14, 2016 at 09:29:41AM -0500, Tom Lendacky wrote: > This is still required because just using the __va() would still cause > the mapping created to have the encryption bit set. The ioremap call > will result in the mapping not having the encryption bit set. I meant this:

Re: [RFC PATCH v2 12/20] x86: Add support for changing memory encryption attribute

2016-09-09 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:37:49PM -0500, Tom Lendacky wrote: > This patch adds support to be change the memory encryption attribute for > one or more memory pages. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/cacheflush.h |3 + >

Re: [RFC PATCH v2 13/20] x86: Decrypt trampoline area if memory encryption is active

2016-09-09 Thread Borislav Petkov
On Mon, Aug 22, 2016 at 05:37:57PM -0500, Tom Lendacky wrote: > When Secure Memory Encryption is enabled, the trampoline area must not > be encrypted. A cpu running in real mode will not be able to decrypt s/cpu/CPU/... always :-) > memory that has been encrypted because it will not be able to

  1   2   3   4   >