On Fri, 4 Mar 2022 17:55:40 +0100
Greg KH wrote:
> On Fri, Mar 04, 2022 at 05:34:47PM +0100, Halil Pasic wrote:
> > On Fri, 4 Mar 2022 15:28:44 +0100
> > Greg KH wrote:
> >
> > > On Fri, Mar 04, 2022 at 02:58:58PM +0100, Halil Pasic wrote:
> > > > This reverts commit
Hi Joerg, Robin,
> Applied without stable tag for now. If needed, please consider
> re-sending it for stable when this patch is merged upstream.
> Yeah, having figured out the history, I ended up with the opinion that
> it was a missed corner-case optimisation opportunity, rather than an
>
On Fri, 4 Mar 2022, Christoph Hellwig wrote:
> On Thu, Mar 03, 2022 at 02:49:29PM -0800, Stefano Stabellini wrote:
> > On Thu, 3 Mar 2022, Christoph Hellwig wrote:
> > > On Wed, Mar 02, 2022 at 05:25:10PM -0800, Stefano Stabellini wrote:
> > > > Thinking more about it we actually need to drop the
On Fri, Mar 04, 2022 at 03:18:23PM -0500, Boris Ostrovsky wrote:
> This indeed allows dom0 to boot. Not sure I see where in the next patch this
> would have been fixed?
I thought it did, but it doesn't. In the meantime I've pushed out an
updated branch with this folded in to:
The pull request you sent on Fri, 4 Mar 2022 16:35:38 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.17-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3f509f5971bca38eeb543186131fb1b404262023
Thank you!
--
On 3/4/22 12:43 PM, Christoph Hellwig wrote:
On Fri, Mar 04, 2022 at 12:36:17PM -0500, Boris Ostrovsky wrote:
I bisected it to "x86: remove the IOMMU table infrastructure" but haven't
actually looked at the code yet.
That looks like the swiotlb buffer did not get initialized at all, but I
On Fri, Mar 04, 2022 at 05:29:08PM +0100, Halil Pasic wrote:
> No problem, I can do that. It isn't hard to squash things together, but
> when I was about to write the commit message, I had the feeling doing
> a revert is cleaner.
>
> Any other opinions?
One patch, not two.
On Fri, Mar 4, 2022 at 4:53 AM Robin Murphy wrote:
> On 2022-03-04 04:05, Gurchetan Singh wrote:
> > Hi everyone,
> >
> > With the current virtio setup, all of guest memory is shared with host
> > devices. There has been interest in changing this, to improve isolation
> of
> > guest memory and
Hi Michael,
On 3/4/22 10:12 AM, Michael Kelley (LINUX) wrote:
> From: Christoph Hellwig Sent: Tuesday, March 1, 2022 2:53 AM
>>
>> Power SVM wants to allocate a swiotlb buffer that is not restricted to low
>> memory for
>> the trusted hypervisor scheme. Consolidate the support for this into
From: Christoph Hellwig Sent: Tuesday, March 1, 2022 2:53 AM
>
> Power SVM wants to allocate a swiotlb buffer that is not restricted to low
> memory for
> the trusted hypervisor scheme. Consolidate the support for this into the
> swiotlb_init
> interface by adding a new flag.
Hyper-V
On Fri, Mar 04, 2022 at 12:36:17PM -0500, Boris Ostrovsky wrote:
>>> I bisected it to "x86: remove the IOMMU table infrastructure" but haven't
>>> actually looked at the code yet.
>> That looks like the swiotlb buffer did not get initialized at all, but I
>> can't really explain why.
>>
>> Can
On 3/4/22 12:28 PM, Christoph Hellwig wrote:
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
Not for me, I fail to boot with
[ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
total 0 (slots), used 0 (slots)
(this is iscsi root so I need the NIC).
On Wed, Mar 02, 2022 at 08:15:03AM -0500, Boris Ostrovsky wrote:
> Not for me, I fail to boot with
>
> [ 52.202000] bnxt_en :31:00.0: swiotlb buffer is full (sz: 256 bytes),
> total 0 (slots), used 0 (slots)
>
> (this is iscsi root so I need the NIC).
>
>
> I bisected it to "x86: remove the
On Fri, Mar 04, 2022 at 05:34:47PM +0100, Halil Pasic wrote:
> On Fri, 4 Mar 2022 15:28:44 +0100
> Greg KH wrote:
>
> > On Fri, Mar 04, 2022 at 02:58:58PM +0100, Halil Pasic wrote:
> > > This reverts commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e.
> >
> > Why???
>
> TLDR; We got v4 merged
On Fri, 4 Mar 2022 15:28:44 +0100
Greg KH wrote:
> On Fri, Mar 04, 2022 at 02:58:58PM +0100, Halil Pasic wrote:
> > This reverts commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e.
>
> Why???
TLDR; We got v4 merged instead of v7
>
> > Signed-off-by: Halil Pasic
>
> You need a blank line
On Thu, Mar 03, 2022 at 02:49:29PM -0800, Stefano Stabellini wrote:
> On Thu, 3 Mar 2022, Christoph Hellwig wrote:
> > On Wed, Mar 02, 2022 at 05:25:10PM -0800, Stefano Stabellini wrote:
> > > Thinking more about it we actually need to drop the xen_initial_domain()
> > > check otherwise some cases
On Fri, 4 Mar 2022 07:53:48 -0800
Christoph Hellwig wrote:
> On Fri, Mar 04, 2022 at 02:58:57PM +0100, Halil Pasic wrote:
> > Unfortunately, we ended up with the wrong version of the patch "fix info
> > leak with DMA_FROM_DEVICE" getting merged. We got v4 merged, but the
> > version we want is
On Fri, Mar 04, 2022 at 02:58:57PM +0100, Halil Pasic wrote:
> Unfortunately, we ended up with the wrong version of the patch "fix info
> leak with DMA_FROM_DEVICE" getting merged. We got v4 merged, but the
> version we want is v7 with some minor tweaks which were supposed to be
> applied by
On Fri, Mar 04, 2022 at 06:37:01PM +0800, Lu Baolu wrote:
> It's based on this series:
>
> https://lore.kernel.org/linux-iommu/yhy%2fawftokqll...@8bytes.org/
>
> which contains some cleanup in vt-d driver as well.
>
> If I re-base the series onto the vt-d branch, there will also be
> conflicts
Hi Linus,
The following changes since commit 754e0b0e35608ed5206d6a67a791563c631cec07:
Linux 5.17-rc4 (2022-02-13 12:13:30 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.17-rc6
for you to fetch changes up to
On Fri, Mar 04, 2022 at 02:58:59PM +0100, Halil Pasic wrote:
> The problem I'm addressing was discovered by the LTP test covering
> cve-2018-1000204.
>
> A short description of what happens follows:
> 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
>interface with:
On Fri, Mar 04, 2022 at 02:58:58PM +0100, Halil Pasic wrote:
> This reverts commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e.
Why???
> Signed-off-by: Halil Pasic
You need a blank line before this one.
also:
This is not the correct way to submit patches for inclusion in the
stable kernel
On 2022-03-04 13:55, Eric Auger wrote:
Hi Robin,
On 3/4/22 1:22 PM, Robin Murphy wrote:
On 2022-03-04 10:43, Lu Baolu wrote:
Hi Eric,
On 2022/3/4 18:34, Eric Auger wrote:
I hit a WARN_ON() when unbinding an e1000e driver just after boot:
sudo modprobe -v vfio-pci
echo vfio-pci | sudo tee
On 2022-03-04 04:46, yf.wang--- via iommu wrote:
From: Yunfei Wang
In alloc_iova_fast function, if an iova alloc request fail,
it will free the iova ranges present in the percpu iova
rcaches and free global iova rcache and then retry, but
flushing CPU iova rcaches only for each online CPU,
The problem I'm addressing was discovered by the LTP test covering
cve-2018-1000204.
A short description of what happens follows:
1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO
interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV
and a
Unfortunately, we ended up with the wrong version of the patch "fix info
leak with DMA_FROM_DEVICE" getting merged. We got v4 merged, but the
version we want is v7 with some minor tweaks which were supposed to be
applied by Christoph (swiotlb maintainer). After pointing this out, I
was asked by
This reverts commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e.
Signed-off-by: Halil Pasic
---
Documentation/core-api/dma-attributes.rst | 8
include/linux/dma-mapping.h | 8
kernel/dma/swiotlb.c | 3 +--
3 files changed, 1 insertion(+), 18
Hi Robin,
On 3/4/22 1:22 PM, Robin Murphy wrote:
> On 2022-03-04 10:43, Lu Baolu wrote:
>> Hi Eric,
>>
>> On 2022/3/4 18:34, Eric Auger wrote:
>>> I hit a WARN_ON() when unbinding an e1000e driver just after boot:
>>>
>>> sudo modprobe -v vfio-pci
>>> echo vfio-pci | sudo tee -a
>>>
On 2022-03-04 10:43, Lu Baolu wrote:
Hi Eric,
On 2022/3/4 18:34, Eric Auger wrote:
I hit a WARN_ON() when unbinding an e1000e driver just after boot:
sudo modprobe -v vfio-pci
echo vfio-pci | sudo tee -a
/sys/bus/pci/devices/0004:01:00.0/driver_override
vfio-pci
echo 0004:01:00.0 | sudo tee
On 2022-03-04 09:41, Joerg Roedel wrote:
On Fri, Mar 04, 2022 at 07:36:46AM +0800, Miles Chen wrote:
Hi Robin,
For various reasons based on the allocator behaviour and typical
use-cases at the time, when the max32_alloc_size optimisation was
introduced it seemed reasonable to couple the reset
Hi Eric,
On 2022/3/4 18:34, Eric Auger wrote:
I hit a WARN_ON() when unbinding an e1000e driver just after boot:
sudo modprobe -v vfio-pci
echo vfio-pci | sudo tee -a
/sys/bus/pci/devices/0004:01:00.0/driver_override
vfio-pci
echo 0004:01:00.0 | sudo tee -a /sys/bus/pci/drivers/e1000e/unbind
Hi Joerg,
On 2022/3/4 17:37, Joerg Roedel wrote:
Hi Baolu,
On Tue, Mar 01, 2022 at 10:01:47AM +0800, Lu Baolu wrote:
This includes patches queued for v5.18. It includes:
- [PATCH 1 ~ 11] Various cleanups, no intentional functional changes.
- [PATCH 12] Enable ATS in SoC-integrated
Hi Lu,
On 2/28/22 1:50 AM, Lu Baolu wrote:
> Multiple devices may be placed in the same IOMMU group because they
> cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture.
>
> This adds dma ownership management in
Il 04/03/22 11:05, Joerg Roedel ha scritto:
On Fri, Mar 04, 2022 at 05:57:19PM +0800, Yong Wu wrote:
Thanks for this info. I will re-send this patchset after the next -rc1.
Could you help apply Dafna's patchset at this time? This patchset
depends on it and it won't conflict with the others.
On Fri, Mar 04, 2022 at 05:57:19PM +0800, Yong Wu wrote:
> Thanks for this info. I will re-send this patchset after the next -rc1.
>
> Could you help apply Dafna's patchset at this time? This patchset
> depends on it and it won't conflict with the others.
Alright, picked up Dafna's patch-set.
On Wed, Dec 08, 2021 at 02:07:39PM +0200, Dafna Hirschfeld wrote:
> Sebastian Reichel (1):
> iommu/mediatek: Always check runtime PM status in tlb flush range
> callback
>
> Yong Wu (4):
> iommu/mediatek: Remove for_each_m4u in tlb_sync_all
> iommu/mediatek: Remove the power status
+iommu@lists.linux-foundation.org not iommu-request
On Thu, Mar 3, 2022 at 8:05 PM Gurchetan Singh
wrote:
> Hi everyone,
>
> With the current virtio setup, all of guest memory is shared with host
> devices. There has been interest in changing this, to improve isolation of
> guest memory and
On Fri, 2022-03-04 at 10:20 +0100, Joerg Roedel wrote:
> On Tue, Mar 01, 2022 at 03:49:18PM +0800, Yong Wu wrote:
> >
https://patchwork.kernel.org/project/linux-mediatek/list/?series=592275
>
> Okay, thanks for the clarification. So I can't include linux-next in
> my
> tree, so I think the best
On Fri, Mar 04, 2022 at 07:36:46AM +0800, Miles Chen wrote:
> Hi Robin,
>
> > For various reasons based on the allocator behaviour and typical
> > use-cases at the time, when the max32_alloc_size optimisation was
> > introduced it seemed reasonable to couple the reset of the tracked
> > size to
On Tue, Mar 01, 2022 at 02:26:21PM +0530, Vasant Hegde wrote:
> This series contains various cleanup and trivial fixes.
>
> Changes in v2:
> - Fixed error log message in patch 1 as suggested by Joerg.
>
>
> Suravee Suthikulpanit (2):
> iommu/amd: Improve error handling for
Hi Baolu,
On Tue, Mar 01, 2022 at 10:01:47AM +0800, Lu Baolu wrote:
> This includes patches queued for v5.18. It includes:
>
> - [PATCH 1 ~ 11] Various cleanups, no intentional functional changes.
> - [PATCH 12] Enable ATS in SoC-integrated devices listed in ACPI/SATC
> table.
>
On 04/03/2022 04:46, yf.wang--- via iommu wrote:
* MEDIATEK Confidentiality Notice
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable
On Tue, Mar 01, 2022 at 03:49:18PM +0800, Yong Wu wrote:
> https://patchwork.kernel.org/project/linux-mediatek/list/?series=592275
Okay, thanks for the clarification. So I can't include linux-next in my
tree, so I think the best option is to wait until v5.18-rc1 (or rather
-rc3, which is where I
43 matches
Mail list logo
