On 04/27/2016 09:39 AM, Andy Lutomirski wrote:
> On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky wrote:
>> This RFC patch series provides support for AMD's new Secure Memory
>> Encryption (SME) feature.
>>
>> SME can be used to mark individual pages of memory as encrypted through the
>> page tables.
On Wed, 2016-04-27 at 21:17 +0300, Michael S. Tsirkin wrote:
>
> > Because it's a dirty hack in the *wrong* place.
>
> No one came up with a better one so far :(
Seriously?
Take a look at drivers/iommu/intel-iommu.c. It has quirks for all kinds
of shitty devices that have to be put in passthrou
On Wed, Apr 27, 2016 at 04:15:35PM +0100, David Woodhouse wrote:
> On Wed, 2016-04-27 at 18:05 +0300, Michael S. Tsirkin wrote:
> >
> > I really don't get it.
> >
> > There's exactly one device that works now and needs the work-around and
> > so that we need to support, and that is virtio. It hap
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.
___
io
On 27/04/16 17:41, Pavel Machek wrote:
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 merged into
kerne
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 merged into
kernel!
On 03/22/2016 08:03 AM, Pavel Machek wrote:
> 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 add
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's some text from
> the 0th mail which you c
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
iommu@lists.linux-f
On Wed, Apr 27, 2016 at 8:31 AM, Borislav Petkov wrote:
> On Wed, Apr 27, 2016 at 08:12:56AM -0700, Andy Lutomirski wrote:
>> I think there are some errata
>
> Isn't that addressed by the first branch of the if-test in pat_init():
>
> if ((c->x86_vendor == X86_VENDOR_INTEL) &&
>
On Wed, Apr 27, 2016 at 08:12:56AM -0700, Andy Lutomirski wrote:
> I think there are some errata
Isn't that addressed by the first branch of the if-test in pat_init():
if ((c->x86_vendor == X86_VENDOR_INTEL) &&
(((c->x86 == 0x6) && (c->x86_model <= 0xd)) ||
((c->x
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 in the series?
>
> Yeah, I've seen argume
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 in the series?
Yeah, I've seen arguments both ways for this. Doing it early
allows compiling and test
On Wed, 2016-04-27 at 18:05 +0300, Michael S. Tsirkin wrote:
>
> I really don't get it.
>
> There's exactly one device that works now and needs the work-around and
> so that we need to support, and that is virtio. It happens to have
> exactly the same issue on all platforms.
False. We have other
On Wed, Apr 27, 2016 at 8:05 AM, Tom Lendacky wrote:
> On 04/27/2016 09:47 AM, Andy Lutomirski wrote:
>> On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky
>> wrote:
>>> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky
wrote:
> For AMD proce
On Wed, Apr 27, 2016 at 7:54 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 27, 2016 at 07:43:07AM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin wrote:
>> > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote:
>> >> On Wed, Apr 27, 2016 at 7:23 AM,
On Wed, Apr 27, 2016 at 04:58:51PM +0200, Joerg Roedel wrote:
> On Wed, Apr 27, 2016 at 05:54:57PM +0300, Michael S. Tsirkin wrote:
> > Point is, QEMU is not the only virtio implementation out there.
> > So we can't know no virtio implementations have an IOMMU as long as
> > linux supports this IOM
On Wed, Apr 27, 2016 at 04:23:32PM +0200, Joerg Roedel wrote:
> On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
> > One correction: it's a feature of the device in the system.
> > There could be a mix of devices bypassing and not
> > bypassing the IOMMU.
>
> No, it really is no
On Wed, Apr 27, 2016 at 04:56:32PM +0200, Joerg Roedel wrote:
> On Wed, Apr 27, 2016 at 05:34:30PM +0300, Michael S. Tsirkin wrote:
> > On Wed, Apr 27, 2016 at 04:23:32PM +0200, Joerg Roedel wrote:
>
> > QEMU can choose to bypass IOMMU for one device and not the other.
> > IOMMU in QEMU isn't invo
On 04/27/2016 09:47 AM, Andy Lutomirski wrote:
> On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky wrote:
>> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
>>> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky
>>> wrote:
For AMD processors that support PAT, set the write-protect cache mode
(_P
On Wed, Apr 27, 2016 at 05:54:57PM +0300, Michael S. Tsirkin wrote:
> Point is, QEMU is not the only virtio implementation out there.
> So we can't know no virtio implementations have an IOMMU as long as
> linux supports this IOMMU.
> virtio always used physical addresses since it was born and if i
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's some text from
> the 0th mail which you c
On Wed, Apr 27, 2016 at 05:34:30PM +0300, Michael S. Tsirkin wrote:
> On Wed, Apr 27, 2016 at 04:23:32PM +0200, Joerg Roedel wrote:
> QEMU can choose to bypass IOMMU for one device and not the other.
> IOMMU in QEMU isn't involved when it's bypassed.
And it is QEMU's task to tell the OS, right? A
On Wed, Apr 27, 2016 at 07:43:07AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin wrote:
> > On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote:
> >> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote:
> >> > On Wed, Apr 27, 2016 at 04:37:04PM +0
On Wed, Apr 27, 2016 at 7:38 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote:
>> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote:
>> > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
>> >> One correction: it's a feature of th
On Wed, Apr 27, 2016 at 7:44 AM, Tom Lendacky wrote:
> On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
>> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky
>> wrote:
>>> For AMD processors that support PAT, set the write-protect cache mode
>>> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect v
On 04/27/2016 09:33 AM, Andy Lutomirski wrote:
> On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky wrote:
>> For AMD processors that support PAT, set the write-protect cache mode
>> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
>
> What's the purpose of using the WP memory type
On Tue, Apr 26, 2016 at 3:55 PM, Tom Lendacky wrote:
> This RFC patch series provides support for AMD's new Secure Memory
> Encryption (SME) feature.
>
> SME can be used to mark individual pages of memory as encrypted through the
> page tables. A page of memory that is marked encrypted will be aut
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's some text from
the 0th mail which you could've found on your own:
"The following links provide additi
On Wed, Apr 27, 2016 at 07:31:43AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote:
> > On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
> >> One correction: it's a feature of the device in the system.
> >> There could be a mix of devices bypa
On Tue, Apr 26, 2016 at 3:56 PM, Tom Lendacky wrote:
> For AMD processors that support PAT, set the write-protect cache mode
> (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05).
What's the purpose of using the WP memory type?
--Andy
_
On 03/22/2016 08:00 AM, Pavel Machek wrote:
> 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
On Wed, Apr 27, 2016 at 7:23 AM, Joerg Roedel wrote:
> On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
>> One correction: it's a feature of the device in the system.
>> There could be a mix of devices bypassing and not
>> bypassing the IOMMU.
>
> No, it really is not. A device
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 question. "Why would I wan
On Wed, Apr 27, 2016 at 04:37:04PM +0300, Michael S. Tsirkin wrote:
> One correction: it's a feature of the device in the system.
> There could be a mix of devices bypassing and not
> bypassing the IOMMU.
No, it really is not. A device can't chose to bypass the IOMMU. But the
IOMMU can chose to le
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.
_
On Wed, Apr 27, 2016 at 01:18:21PM +0100, David Woodhouse wrote:
>
> > > On some systems, including Xen and any system with a physical device
> > > that speaks virtio behind a physical IOMMU, we must use the DMA API
> > > for virtio DMA to work at all.
> > >
> > > Add a feature bit to detect that
On ARM HW the capability of IRQ remapping is abstracted on
MSI controller side. MSI_FLAG_IRQ_REMAPPING is used to advertise
this [1].
To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when MSI_FLAG_IRQ_REMAPPING is set.
The capability of IRQ remapping is abstracted on IOMMU side on
some archs. There is a existing flag IOMMU_CAP_INTR_REMAP for this.
To have a universal flag to test this capability for different
archs on PCI side, we set PCI_BUS_FLAGS_MSI_REMAP for PCI buses
when IOMMU_CAP_INTR_REMAP is set.
Signe
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."
Any IODA host bridge have the capability of IRQ remapping.
So we set PCI_BUS_FLAGS_MSI_REMAP when this kind of host birdge
is detected.
Signed-off-by: Yongji Xie
---
arch/powerpc/platforms/powernv/pci-ioda.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/platforms/po
We introduce a new pci_bus_flags, PCI_BUS_FLAGS_MSI_REMAP
which indicates all devices on the bus are protected by the
hardware which supports IRQ remapping(intel naming).
This flag will be used to know whether it's safe to expose
MSI-X tables of PCI BARs to userspace. Because the capability
of IRQ
This patch enables mmapping MSI-X tables if hardware supports
interrupt remapping which can ensure that a given pci device
can only shoot the MSIs assigned for it.
With MSI-X table mmapped, we also need to expose the
read/write interface which will be used to access MSI-X table.
Signed-off-by: Yo
Current vfio-pci implementation disallows to mmap the page
containing MSI-X table in case that users can write to MSI-X
table and generate an incorrect MSIs.
However, this will cause some performance issue when there
are some critical device registers in the same page as the
MSI-X table. We have
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
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
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
> > On some systems, including Xen and any system with a physical device
> > that speaks virtio behind a physical IOMMU, we must use the DMA API
> > for virtio DMA to work at all.
> >
> > Add a feature bit to detect that: VIRTIO_F_IOMMU_PLATFORM.
> >
> > If not there, we preserve historic behavi
48 matches
Mail list logo
