在 2019年07月19日 01:47, Lendacky, Thomas 写道:
> On 7/17/19 10:28 PM, Thiago Jung Bauermann wrote:
>> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
>> appear in generic kernel code because it forces non-x86 architectures to
>> define the sev_active() function, which
Hi Will,
On Thu, Jul 11, 2019 at 10:58 PM Will Deacon wrote:
>
> Hi everyone,
>
> This is a significant rework of the RFC I previously posted here:
>
> https://lkml.kernel.org/r/20190611134603.4253-1-will.dea...@arm.com
>
> But this time, it looks like it might actually be worthwhile according
From: Florian Fainelli
[ Upstream commit 4b4b077cbd0a998aebaa72c199e06b8a4c8dcfee ]
With architectures allowing the kernel to be placed almost arbitrarily
in memory (e.g.: ARM64), it is possible to have the kernel resides at
physical addresses above 4GB, resulting in neither the default CMA
From: Florian Fainelli
[ Upstream commit 4b4b077cbd0a998aebaa72c199e06b8a4c8dcfee ]
With architectures allowing the kernel to be placed almost arbitrarily
in memory (e.g.: ARM64), it is possible to have the kernel resides at
physical addresses above 4GB, resulting in neither the default CMA
On Wed, 12 Jun 2019 08:28:51 +0800
Lu Baolu wrote:
> The domain_init() and md_domain_init() do almost the same job.
> Consolidate them to avoid duplication.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel-iommu.c | 123 +++-
> 1 file changed, 36
On 7/18/19 4:52 AM, Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
Other than m68k, mips, and arm64, everybody else that doesn't have
ARCH_NO_COHERENT_DMA_MMAP set uses this default
On 7/18/19 5:31 AM, Christoph Hellwig wrote:
On Tue, Jul 16, 2019 at 10:43:33PM -0400, Al Farleigh wrote:
re: the dma-direct code commit below
I have bisected the kernel to isolate a PCI board problem on my AMD x86-64
ASROCK system. The board worked at (Fedora kernel) 4.18.16 but stopped when
Thomas Gleixner writes:
> On Fri, 12 Jul 2019, Thiago Jung Bauermann wrote:
>> diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
>> index b310a9c18113..f2e399fb626b 100644
>> --- a/include/linux/mem_encrypt.h
>> +++ b/include/linux/mem_encrypt.h
>> @@ -21,23 +21,11 @@
>>
Lendacky, Thomas writes:
> On 7/17/19 10:28 PM, Thiago Jung Bauermann wrote:
>> Hello,
>>
>> This version is mostly about splitting up patch 2/3 into three separate
>> patches, as suggested by Christoph Hellwig. Two other changes are a fix in
>> patch 1 which wasn't selecting
On Thu, Jul 18, 2019 at 05:42:18PM +, Lendacky, Thomas wrote:
> You may want to try and build the out-of-tree nvidia driver just to be
> sure you can remove the EXPORT_SYMBOL(). But I believe that was related
> to the DMA mask check, which now removed, may no longer be a problem.
Out of tree
On 7/17/19 10:28 PM, Thiago Jung Bauermann wrote:
> Hello,
>
> This version is mostly about splitting up patch 2/3 into three separate
> patches, as suggested by Christoph Hellwig. Two other changes are a fix in
> patch 1 which wasn't selecting ARCH_HAS_MEM_ENCRYPT for s390 spotted by
> Janani
On 7/17/19 10:28 PM, Thiago Jung Bauermann wrote:
> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
> appear in generic kernel code because it forces non-x86 architectures to
> define the sev_active() function, which doesn't make a lot of sense.
>
> To solve this
On 7/17/19 10:28 PM, Thiago Jung Bauermann wrote:
> Now that generic code doesn't reference them, move sme_active() and
> sme_me_mask to x86's .
>
> Also remove the export for sme_active() since it's only used in files that
> won't be built as modules. sme_me_mask on the other hand is used in
>
On 7/17/19 10:28 PM, Thiago Jung Bauermann wrote:
> sme_active() is an x86-specific function so it's better not to call it from
> generic code. Christoph Hellwig mentioned that "There is no reason why we
> should have a special debug printk just for one specific reason why there
> is a requirement
On 7/17/19 10:28 PM, Thiago Jung Bauermann wrote:
> sme_active() is an x86-specific function so it's better not to call it from
> generic code.
>
> There's no need to mention which memory encryption feature is active, so
> just use a more generic message. Besides, other architectures will have
>
On 7/18/19 5:31 AM, Christoph Hellwig wrote:
On Tue, Jul 16, 2019 at 10:43:33PM -0400, Al Farleigh wrote:
re: the dma-direct code commit below
I have bisected the kernel to isolate a PCI board problem on my AMD x86-64
ASROCK system. The board worked at (Fedora kernel) 4.18.16 but stopped when
Halil Pasic writes:
> On Thu, 18 Jul 2019 10:44:56 +0200
> Christoph Hellwig wrote:
>
>> > -/* are we a protected virtualization guest? */
>> > -bool sev_active(void)
>> > -{
>> > - return is_prot_virt_guest();
>> > -}
>> > -
>> > bool force_dma_unencrypted(struct device *dev)
>> > {
>> >
Christoph Hellwig writes:
>> -/* are we a protected virtualization guest? */
>> -bool sev_active(void)
>> -{
>> -return is_prot_virt_guest();
>> -}
>> -
>> bool force_dma_unencrypted(struct device *dev)
>> {
>> -return sev_active();
>> +return is_prot_virt_guest();
>> }
>
> Do
On 7/18/19 4:31 AM, Christoph Hellwig wrote:
> On Tue, Jul 16, 2019 at 10:43:33PM -0400, Al Farleigh wrote:
>> re: the dma-direct code commit below
>>
>> I have bisected the kernel to isolate a PCI board problem on my AMD x86-64
>> ASROCK system. The board worked at (Fedora kernel) 4.18.16 but
On Thu, 18 Jul 2019 10:44:56 +0200
Christoph Hellwig wrote:
> > -/* are we a protected virtualization guest? */
> > -bool sev_active(void)
> > -{
> > - return is_prot_virt_guest();
> > -}
> > -
> > bool force_dma_unencrypted(struct device *dev)
> > {
> > - return sev_active();
> > +
On Thu, Jul 18, 2019 at 02:42:26PM +0800, Yong Wu wrote:
> The MediaTek SMI adding device_link patch looks reveal a deadlock
> issue reported in [1], This patch is to fix this deadlock issue.
Can you please describe in words what this issue is and how the patch
addresses it?
> This is the
On Thu, 2019-07-18 at 11:15 +0200, Christoph Hellwig wrote:
> On Wed, Jul 17, 2019 at 05:31:34PM +0200, Nicolas Saenz Julienne wrote:
> > Historically devices with ZONE_DMA32 have been assumed to be able to
> > address at least the lower 4GB of ram for DMA. This is still the defualt
> > behavior
Yi,
On 7/5/19 1:06 PM, Liu, Yi L wrote:
> From: Liu Yi L
>
> This patch adds vfio support to bind guest translation structure
> to host iommu. VFIO exposes iommu programming capability to user-
> space. Guest is a user-space application in host under KVM solution.
> For SVA usage in Virtual
On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
> On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
> > > Other than m68k, mips, and arm64, everybody else that doesn't have
> > > ARCH_NO_COHERENT_DMA_MMAP set uses this default implementation, so
> > > I assume
On Tue, Jul 16, 2019 at 10:43:33PM -0400, Al Farleigh wrote:
> re: the dma-direct code commit below
>
> I have bisected the kernel to isolate a PCI board problem on my AMD x86-64
> ASROCK system. The board worked at (Fedora kernel) 4.18.16 but stopped when
> moving to (Fedora kernel) 5.0. I then
On Wed, Jul 17, 2019 at 05:31:34PM +0200, Nicolas Saenz Julienne wrote:
> Historically devices with ZONE_DMA32 have been assumed to be able to
> address at least the lower 4GB of ram for DMA. This is still the defualt
> behavior yet the Raspberry Pi 4 is limited to the first GB of memory.
> This
> -/* are we a protected virtualization guest? */
> -bool sev_active(void)
> -{
> - return is_prot_virt_guest();
> -}
> -
> bool force_dma_unencrypted(struct device *dev)
> {
> - return sev_active();
> + return is_prot_virt_guest();
> }
Do we want to keep the comment for
On Thu, Jul 18, 2019 at 12:28:57AM -0300, Thiago Jung Bauermann wrote:
> Secure Encrypted Virtualization is an x86-specific feature, so it shouldn't
> appear in generic kernel code because it forces non-x86 architectures to
> define the sev_active() function, which doesn't make a lot of sense.
>
On Thu, Jul 18, 2019 at 12:28:56AM -0300, Thiago Jung Bauermann wrote:
> Now that generic code doesn't reference them, move sme_active() and
> sme_me_mask to x86's .
>
> Also remove the export for sme_active() since it's only used in files that
> won't be built as modules. sme_me_mask on the
On Thu, Jul 18, 2019 at 12:28:55AM -0300, Thiago Jung Bauermann wrote:
> sme_active() is an x86-specific function so it's better not to call it from
> generic code. Christoph Hellwig mentioned that "There is no reason why we
> should have a special debug printk just for one specific reason why
On Thu, Jul 18, 2019 at 12:28:54AM -0300, Thiago Jung Bauermann wrote:
> sme_active() is an x86-specific function so it's better not to call it from
> generic code.
>
> There's no need to mention which memory encryption feature is active, so
> just use a more generic message. Besides, other
Hi Jacob,
On 6/9/19 3:44 PM, Jacob Pan wrote:
> When Shared Virtual Memory is exposed to a guest via vIOMMU, scalable
> IOTLB invalidation may be passed down from outside IOMMU subsystems.
> This patch adds invalidation functions that can be used for additional
> translation cache types.
>
>
Hi Ashok,
On 7/16/19 7:04 PM, Raj, Ashok wrote:
> Hi Eric
>
> Jacob is on sabbatical, so i'll give it my best shot :-)
>
> Yi/Kevin can jump in...
>
> On Tue, Jul 16, 2019 at 06:45:51PM +0200, Auger Eric wrote:
>> Hi Jacob,
>>
>> On 6/9/19 3:44 PM, Jacob Pan wrote:
>>> When supporting guest
The MediaTek SMI adding device_link patch looks reveal a deadlock
issue reported in [1], This patch is to fix this deadlock issue.
This is the detailed log:
[4.664194] ==
[4.670368] WARNING: possible circular locking dependency detected
34 matches
Mail list logo
