On Fri, May 05, 2017 at 02:08:37PM -0400, Rob Clark wrote:
> It looks like it *used* to make sense to free the device. But now it is
> embedded in 'struct iommu' (which is allocated or embedded in something
> that the device allocated).
>
> Spotted when testing qcom_iommu with CONFIG_DEBUG_TEST_D
On Fri, May 05, 2017 at 02:56:00PM -0400, Rob Clark wrote:
> On Fri, May 5, 2017 at 2:24 PM, Greg KH wrote:
> > On Fri, May 05, 2017 at 02:08:37PM -0400, Rob Clark wrote:
> >> It looks like it *used* to make sense to free the device. But now it is
> >> embedded
On Wed, Feb 06, 2013 at 07:40:50PM -0700, Shuah Khan wrote:
> On Wed, 2013-02-06 at 13:12 +0100, Joerg Roedel wrote:
> > On Tue, Feb 05, 2013 at 06:57:21AM -0700, Shuah Khan wrote:
> > > Thanks much. I will hang on to this test system for testing your fix.
> >
> > Okay, here is the simple fix for
On Wed, Oct 02, 2013 at 10:44:31AM +0200, Borislav Petkov wrote:
> On Sat, Jun 15, 2013 at 10:27:19AM -0600, Alex Williamson wrote:
> > At best the current code only seems to free the leaf pagetables and
> > the root. If you're unlucky enough to have a large gap (like any
> > QEMU guest with more
On Thu, Dec 12, 2013 at 11:39:20AM +, Grant Likely wrote:
> On Thu, 12 Dec 2013 09:57:05 +0200, Hiroshi Doyu wrote:
> > IOMMU devices on the bus need to be poplulated first, then iommu
> > master devices are done later.
> >
> > With CONFIG_OF_IOMMU, "iommus=" DT binding would be used to ident
On Sat, Feb 08, 2014 at 06:29:31PM +0100, Antonios Motakis wrote:
> From: Kim Phillips
>
> Needed by drivers, such as the vfio platform driver [1], seeking to
> bypass bind_store()'s driver_match_device(), and bind to any device
> via a private sysfs bind file.
>
> [1] https://lkml.org/lkml/2013
On Fri, Feb 14, 2014 at 11:00:31PM +, Stuart Yoder wrote:
>
>
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Friday, February 14, 2014 4:27 PM
> > To: Antonios Motakis
> > Cc: alex.william...@redhat.com; kvm
On Sat, Feb 15, 2014 at 04:33:44PM +, Stuart Yoder wrote:
> > > Why? driver_probe_device() allows a driver to explicitly bind
> > > to a specific device. What is conceptually wrong with allowing
> > > that?
> >
> > Because that's not how a bus should work, and the fact that no other
> > sub
On Thu, Feb 20, 2014 at 10:34:35PM +, Stuart Yoder wrote:
>
>
> > -Original Message-
> > From: Yoder Stuart-B08248
> > Sent: Saturday, February 15, 2014 12:19 PM
> > To: 'Greg KH'
> > Cc: Antonios Motakis; alex.william...@redha
On Wed, Mar 26, 2014 at 10:39:57PM +0100, Antonios Motakis wrote:
>
> Of note is that new_id doesn't work particularly well for platform devices.
Nor should it. Platform devices suck horribly, and "ids" mean nothing
to them, so you shouldn't even try this. Use a "real" bus and it should
be fine
On Mon, Mar 31, 2014 at 06:47:51PM +, Stuart Yoder wrote:
> I also, was at the point where I thought we should perhaps just
> go with current mechanisms and implement new_id for the platform
> bus...but Greg's recent response is 'platform devices suck' and it sounds
> like he would reject a new
On Tue, Apr 01, 2014 at 10:28:54AM -0600, Alex Williamson wrote:
> The driver_override field allows us to specify the driver for a device
> rather than relying on the driver to provide a positive match of the
> device. This shortcuts the existing process of looking up the vendor
> and device ID, a
On Tue, Apr 01, 2014 at 06:52:12PM -0500, Kim Phillips wrote:
> On Tue, 01 Apr 2014 10:28:54 -0600
> Alex Williamson wrote:
>
> > The driver_override field allows us to specify the driver for a device
> > rather than relying on the driver to provide a positive match of the
> > device. This short
On Tue, May 27, 2014 at 09:07:42PM -0600, Bjorn Helgaas wrote:
> On Tue, May 20, 2014 at 08:53:21AM -0600, Alex Williamson wrote:
> > The driver_override field allows us to specify the driver for a device
> > rather than relying on the driver to provide a positive match of the
> > device. This sho
On Tue, May 27, 2014 at 09:07:42PM -0600, Bjorn Helgaas wrote:
> On Tue, May 20, 2014 at 08:53:21AM -0600, Alex Williamson wrote:
> > The driver_override field allows us to specify the driver for a device
> > rather than relying on the driver to provide a positive match of the
> > device. This sho
On Mon, Jun 02, 2014 at 07:42:58PM -0500, Kim Phillips wrote:
> Needed by platform device drivers, such as the upcoming
> vfio-platform driver, in order to bypass the existing OF, ACPI,
> id_table and name string matches, and successfully be able to be
> bound to any device, like so:
>
> echo vfio
On Fri, Jun 06, 2014 at 02:45:06PM +0300, Eli Billauer wrote:
> Hello Joerg.
>
>
> On 05/06/14 00:25, Joerg Roedel wrote:
> >
> >What you are trying to do should work with dma_alloc_noncoherent(). The
> >API allows partial syncs on this memory, so you should be fine.
> Please try to put yourself
On Mon, Jun 09, 2014 at 02:09:53PM +0100, David Woodhouse wrote:
> This missing IOTLB flush was added as a minor, inconsequential bug-fix
> in commit ea8ea460c ("iommu/vt-d: Clean up and fix page table clear/free
> behaviour") in 3.15. It wasn't originally intended for -stable but a
> couple of use
On Tue, Jun 17, 2014 at 05:21:54PM +0200, Joerg Roedel wrote:
> On Tue, Jun 17, 2014 at 10:29:19PM +0800, Jeff Liu wrote:
> > From: Jie Liu
> >
> > kset_create_and_add() has been fixed to return the actual error
> > code ptr rather than NULL, so update iommu_init() to check the
> > return value v
On Mon, Jun 02, 2014 at 07:42:58PM -0500, Kim Phillips wrote:
> Needed by platform device drivers, such as the upcoming
> vfio-platform driver, in order to bypass the existing OF, ACPI,
> id_table and name string matches, and successfully be able to be
> bound to any device, like so:
>
> echo vfio
On Mon, Jan 28, 2019 at 05:43:01PM +0800, Nicolas Boichat wrote:
> L1 tables are allocated with __get_dma_pages, and therefore already
> ignored by kmemleak.
>
> Without this, the kernel would print this error message on boot,
> when the first L1 table is allocated:
>
> [2.810533] kmemleak: T
On Thu, Jan 31, 2019 at 06:17:31PM +0800, lantianyu1...@gmail.com wrote:
> From: Lan Tianyu
>
> Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
> set x2apic destination mode to physcial mode when x2apic is available
> and Hyper-V IOMMU driver makes sure cpus assigned with IO-
On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1...@gmail.com wrote:
> --- /dev/null
> +++ b/drivers/iommu/hyperv-iommu.c
> @@ -0,0 +1,189 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#define pr_fmt(fmt) "HYPERV-IR: " fmt
Minor nit, you never do any pr_*() calls, so this isn't needed,
On Wed, Mar 11, 2020 at 05:07:10PM +0100, Christoph Hellwig wrote:
> Ever since the generic platform device code started allocating DMA masks
> itself the code to allocate and leak a private DMA mask in
> platform_device_register_full has been superflous. More so the fact that
> it unconditionally
On Wed, Mar 11, 2020 at 05:15:51PM +0100, Christoph Hellwig wrote:
> On Wed, Mar 11, 2020 at 05:14:23PM +0100, Greg KH wrote:
> > On Wed, Mar 11, 2020 at 05:07:10PM +0100, Christoph Hellwig wrote:
> > > Ever since the generic platform device code started allocating DMA masks
>
On Wed, Apr 08, 2020 at 01:59:00PM +0200, Christoph Hellwig wrote:
> vm_map_ram can keep mappings around after the vm_unmap_ram. Using that
> with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Greg Kroah-Hartman
__
On Tue, May 26, 2020 at 07:57:49PM +0200, Alexander Dahl wrote:
> The intermediate result of the old term (4UL * 1024 * 1024 * 1024) is
> 4 294 967 296 or 0x1 which is no problem on 64 bit systems. The
> patch does not change the later overall result of 0x10 for
> MAX_DMA32_PFN. The n
On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> For some platform devices like iommu, particually ARM smmu, users may
> care about the numa locality. for example, if threads and drivers run
> near iommu, they may get much better performance on dma_unmap_sg.
> For other platform device
On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> For some platform devices like iommu, particually ARM smmu, users may
> care about the numa locality. for example, if threads and drivers run
> near iommu, they may get much better performance on dma_unmap_sg.
> For other platform device
On Tue, Jun 02, 2020 at 05:09:57AM +, Song Bao Hua (Barry Song) wrote:
> > >
> > > Platform devices are NUMA? That's crazy, and feels like a total abuse
> > > of platform devices and drivers that really should belong on a "real"
> > > bus.
> >
> > I am not sure if it is an abuse of platform d
On Fri, May 11, 2012 at 04:55:35PM -0600, Alex Williamson wrote:
> IOMMU groups allow IOMMU drivers to represent DMA visibility
> and isolation of devices. Multiple devices may be grouped
> together for the purposes of DMA. Placing a pointer on
> struct device enable easy access for things like s
On Fri, May 11, 2012 at 04:55:41PM -0600, Alex Williamson wrote:
> IOMMU device groups are currently a rather vague associative notion
> with assembly required by the user or user level driver provider to
> do anything useful. This patch intends to grow the IOMMU group concept
> into something a b
On Fri, May 11, 2012 at 05:58:01PM -0600, Alex Williamson wrote:
> On Fri, 2012-05-11 at 16:38 -0700, Greg KH wrote:
> > On Fri, May 11, 2012 at 04:55:35PM -0600, Alex Williamson wrote:
> > > IOMMU groups allow IOMMU drivers to represent DMA visibility
> > > and isol
On Thu, Oct 25, 2012 at 09:06:02AM +0300, Hiroshi Doyu wrote:
> On Wed, 24 Oct 2012 17:01:21 +0200
> Joerg Roedel wrote:
>
> > On Thu, Oct 18, 2012 at 08:35:10AM +0300, Hiroshi Doyu wrote:
> > > From: Hiro Sugawara
> > >
> > > Fix a deadly typo in macro definition.
> > >
> > > Signed-off-by: H
On Tue, Oct 17, 2017 at 10:17:01AM +0200, Christoph Hellwig wrote:
> Looks fine:
>
> Reviewed-by: Christoph Hellwig
>
> Greg, do you want to take this or should I queue it up in the
> dma-mapping tree?
You can take it, thanks!
Acked-by: Greg Kroah-Hartman
_
On Wed, Mar 21, 2018 at 12:25:22PM +0530, Nipun Gupta wrote:
> It's bus specific aspect to map a given device on the bus and
> relevant firmware description of its DMA configuration.
> So, this change introduces '/dma_configure/' as bus callback
> giving flexibility to busses for implementing its o
On Wed, Mar 21, 2018 at 12:25:23PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if
On Wed, Mar 21, 2018 at 04:28:46PM +, Nipun Gupta wrote:
>
>
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Wednesday, March 21, 2018 15:05
> > To: Nipun Gupta
> > Cc: robin.mur...@arm.com; h...@lst.de;
On Fri, Mar 30, 2018 at 09:15:30AM +0200, Christoph Hellwig wrote:
> Can you resend the current state of affairs so we can get it in for
> 4.17?
Changes to the driver core and 3 different busses 2 days before 4.16 is
out, preventing any testing at all in linux-next? This needs to wait
for the nex
On Wed, Apr 03, 2019 at 09:02:36AM +0100, John Garry wrote:
> On 28/03/2019 10:08, John Garry wrote:
> > In commit 376991db4b64 ("driver core: Postpone DMA tear-down until after
> > devres release"), we changed the ordering of tearing down the device DMA
> > ops and releasing all the device's resou
On Thu, Jun 13, 2019 at 01:16:32PM -0400, Alan Stern wrote:
> On Thu, 13 Jun 2019, Christoph Hellwig wrote:
>
> > On Wed, Jun 12, 2019 at 10:43:11AM -0400, Alan Stern wrote:
> > > Would it be okay to rely on the assumption that USB block devices never
> > > have block size < 512? (We could even
On Fri, Jun 14, 2019 at 03:47:22PM +0200, Christoph Hellwig wrote:
> comedi_buf.c abuse the DMA API in gravely broken ways, as it assumes it
> can call virt_to_page on the result, and the just remap it as uncached
> using vmap. Disable the driver until this API abuse has been fixed.
>
> Signed-of
On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
> > Perhaps a hint as to how we can fix this up? This is the first time
> > I've heard of the comedi code not handling dma properly.
>
> I
On Mon, Jul 29, 2019 at 05:36:09PM +0100, Dmitry Safonov wrote:
> Hi Greg,
>
> On 7/29/19 5:30 PM, gre...@linuxfoundation.org wrote:
> >
> > This is a note to let you know that I've just added the patch titled
> >
> > iommu/vt-d: Don't queue_iova() if there is no flush queue
> >
> > to the
On Wed, Jun 24, 2020 at 08:41:21AM +, Suravee Suthikulpanit wrote:
> Currently, an integer is used to specify the size in unmap_sg().
> With 2GB worth of pages (512k 4k pages), it requires 31 bits
> (i.e. (1 << 19) << 12), which overflows the integer, and ends up
> unmapping more pages than int
On Wed, Jun 24, 2020 at 01:58:27PM +0200, Joerg Roedel wrote:
> Hi Greg,
>
> On Wed, Jun 24, 2020 at 11:09:06AM +0200, Greg KH wrote:
> > So what exact stable kernel version(s) do you want to see this patch
> > applied to?
>
> It is needed in kernels <= v5.4. Li
On Thu, Sep 10, 2020 at 07:40:38AM +0200, Christoph Hellwig wrote:
> From: Jim Quinlan
>
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offs
On Thu, Sep 10, 2020 at 11:13:51AM +0200, Christoph Hellwig wrote:
> On Thu, Sep 10, 2020 at 09:53:51AM +0200, Greg KH wrote:
> > > /*
> > >* Please refer to usb_alloc_dev() to see why we set
> > > - * dma_mask and dma_pfn_offset.
&
On Thu, Mar 17, 2022 at 04:17:07PM +, Robin Murphy wrote:
> Between me trying to get rid of iommu_present() and Mario wanting to
> support the AMD equivalent of DMAR_PLATFORM_OPT_IN, scrutiny has shown
> that the iommu_dma_protection attribute is being far too optimistic.
> Even if an IOMMU mig
On Mon, Jun 27, 2022 at 07:18:12PM +0800, Yicong Yang wrote:
> Hi Greg,
>
> Since the kernel side of this device has been reviewed for 8 versions with
> all comments addressed and no more comment since v9 posted in 5.19-rc1,
> is it ok to merge it first (for Patch 1-3 and 7-8)?
I am not the maint
On Wed, Jan 27, 2021 at 04:38:26PM -0800, Jianxiong Gao wrote:
> NVMe driver and other applications may depend on the data offset
> to operate correctly. Currently when unaligned data is mapped via
> SWIOTLB, the data is mapped as slab aligned with the SWIOTLB. This
> patch adds an option to make s
On Mon, Feb 01, 2021 at 10:30:14AM -0800, Jianxiong Gao wrote:
> NVMe driver and other applications may depend on the data offset
> to operate correctly. Currently when unaligned data is mapped via
> SWIOTLB, the data is mapped as slab aligned with the SWIOTLB. This
> patch adds an option to make s
On Thu, Feb 04, 2021 at 08:30:28PM +0100, Christoph Hellwig wrote:
> From: Jianxiong Gao
>
> Some devices rely on the address offset in a page to function
> correctly (NVMe driver as an example). These devices may use
> a different page size than the Linux kernel. The address offset
> has to be p
On Tue, Feb 09, 2021 at 09:41:56AM +0100, Christoph Hellwig wrote:
> Sorry for being a little pushy, any chance we could get this reviewed
> in time for the 5.12 merge window?
No objection from me, my ack is already on the patch that you need it
for :)
thanks,
greg k-h
__
On Tue, Feb 09, 2021 at 09:05:40AM +, obayashi.yoshim...@socionext.com
wrote:
> > > As the drivers are currently under development and Socionext has
> > > chosen 5.4 stable kernel for their development. So I will let
> > > Obayashi-san answer this if it's possible for them to migrate to 5.10
>
On Tue, Feb 09, 2021 at 05:17:46PM +0800, Zhou Wang wrote:
> On 2021/2/8 6:02, Andy Lutomirski wrote:
> >
> >
> >> On Feb 7, 2021, at 12:31 AM, Zhou Wang wrote:
> >>
> >> SVA(share virtual address) offers a way for device to share process
> >> virtual
> >> address space safely, which makes mor
On Tue, Feb 09, 2021 at 10:19:07AM +, obayashi.yoshim...@socionext.com
wrote:
> > How do you judge "mature"?
>
> My basic criteria are
> * Function is exist, but bug fix is necessary: "mature"
> * Function extension is necessary: "immature"
>
> > And again, if a feature isn't present in a
On Tue, Feb 09, 2021 at 07:58:15PM +0800, Zhou Wang wrote:
> On 2021/2/9 17:37, Greg KH wrote:
> > On Tue, Feb 09, 2021 at 05:17:46PM +0800, Zhou Wang wrote:
> >> On 2021/2/8 6:02, Andy Lutomirski wrote:
> >>>
> >>>
> >>>> On Feb 7, 2021
On Mon, Mar 29, 2021 at 11:25:11AM +0530, Bhaskar Chowdhury wrote:
> On 07:29 Mon 29 Mar 2021, Christoph Hellwig wrote:
> > I really don't think these typo patchbomb are that useful. I'm all
> > for fixing typos when working with a subsystem, but I'm not sure these
> > patchbombs help anything.
>
On Mon, Apr 12, 2021 at 01:27:35PM -0700, Saeed Mirzamohammadi wrote:
> The IOMMU driver calculates the guest addressability for a DMA request
> based on the value of the mgaw reported from the IOMMU. However, this
> is a fused value and as mentioned in the spec, the guest width
> should be calcu
On Tue, Apr 13, 2021 at 11:05:34AM -0700, Saeed Mirzamohammadi wrote:
> Hi Greg,
>
> I don’t have any commit ID since the fix is not in mainline or any Linus’
> tree yet. The driver has completely changed for newer stable versions (and
> also mainline) and the fix only applies for 5.4, 4.19, and
On Mon, Apr 12, 2021 at 01:27:35PM -0700, Saeed Mirzamohammadi wrote:
> The IOMMU driver calculates the guest addressability for a DMA request
> based on the value of the mgaw reported from the IOMMU. However, this
> is a fused value and as mentioned in the spec, the guest width
> should be calcula
On Wed, Apr 14, 2021 at 10:49:41AM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> UIO HV driver should not load in the isolation VM for security reason.
> Return ENOTSUPP in the hv_uio_probe() in the isolation VM.
>
> Signed-off-by: Tianyu Lan
> ---
> drivers/uio/uio_hv_generic.c | 5 +
>
On Tue, Apr 27, 2021 at 01:34:27PM +0200, Corentin Labbe wrote:
> Hello
>
> I try to debug some DMA problem on next-20210427, and so I have enabled
> CONFIG_DMA_API_DEBUG=y.
> But the dma-api directory does show up in debugfs, but lot of other directory
> exists in it.
Does it show up properly
On Tue, Apr 27, 2021 at 01:32:50PM +0100, Robin Murphy wrote:
> On 2021-04-27 12:39, Greg KH wrote:
> > On Tue, Apr 27, 2021 at 01:34:27PM +0200, Corentin Labbe wrote:
> > > Hello
> > >
> > > I try to debug some DMA problem on next-20210427, and so I have e
On Mon, May 17, 2021 at 02:45:01PM +0200, Jack Wang wrote:
> Christoph Biedl 于2021年5月17日周一 下午2:25写道：
> >
> > Jack Wang wrote...
> >
> > > Christoph Biedl 于2021年5月17日周一
> > > 下午1:52写道：
> > > >
> > > > Christoph Biedl wrote...
> > > >
> > > > > Thanks for taking care, unfortunately no improvement
On Tue, May 18, 2021 at 12:30:15AM +0200, Christoph Biedl wrote:
> Greg KH wrote...
>
> > On Mon, May 17, 2021 at 02:45:01PM +0200, Jack Wang wrote:
>
> > > So it's caused by this commit[1], and it should be fixed by latest
> > > 5.10.38-rc1
> > >
On Mon, May 17, 2021 at 05:55:12PM +0800, Xie Yongji wrote:
> +struct vduse_dev {
> + struct vduse_vdpa *vdev;
> + struct device dev;
> + struct cdev cdev;
You now have 2 reference counted devices controling the lifespace of a
single structure. A mess that is guaranteed to go wrong.
On Mon, May 31, 2021 at 02:19:37PM +0800, Yongji Xie wrote:
> Hi Greg,
>
> Thanks a lot for the review!
>
> On Mon, May 31, 2021 at 12:56 PM Greg KH wrote:
> >
> > On Mon, May 17, 2021 at 05:55:12PM +0800, Xie Yongji wrote:
> > > +struct vduse_dev {
On Mon, Jun 21, 2021 at 04:52:43PM -0700, Douglas Anderson wrote:
> Right now things are a bit awkward if a driver would like a chance to
> run before some of the more "automatic" things (pinctrl, DMA, IOMMUs,
> ...) happen to a device. This patch aims to fix that problem by
> introducing the conce
On Mon, Jun 21, 2021 at 04:52:44PM -0700, Douglas Anderson wrote:
> How to control the "strictness" of an IOMMU is a bit of a mess right
> now. As far as I can tell, right now:
> * You can set the default to "non-strict" and some devices (right now,
> only PCI devices) can request to run in "stri
On Mon, Jun 21, 2021 at 04:52:45PM -0700, Douglas Anderson wrote:
> At the moment the generic IOMMU framework reaches into the PCIe device
> to check the "untrusted" state and uses this information to figure out
> if it should be running the IOMMU in strict or non-strict mode. Let's
> instead set t
On Mon, Jun 21, 2021 at 04:52:48PM -0700, Douglas Anderson wrote:
> IOMMUs can be run in "strict" mode or in "non-strict" mode. The
> quick-summary difference between the two is that in "strict" mode we
> wait until everything is flushed out when we unmap DMA memory. In
> "non-strict" we don't.
>
On Wed, Jul 14, 2021 at 02:02:50PM +0800, Jason Wang wrote:
>
> 在 2021/7/14 下午1:54, Michael S. Tsirkin 写道:
> > On Wed, Jul 14, 2021 at 01:45:39PM +0800, Jason Wang wrote:
> > > > +static int vduse_dev_msg_sync(struct vduse_dev *dev,
> > > > + struct vduse_dev_msg *msg)
On Thu, Jul 29, 2021 at 03:35:02PM +0800, Xie Yongji wrote:
> +/*
> + * The basic configuration of a VDUSE device, which is used by
> + * VDUSE_CREATE_DEV ioctl to create a VDUSE device.
> + */
> +struct vduse_dev_config {
Please document this structure using kernel doc so we know what all the
fie
On Fri, Aug 27, 2021 at 01:21:02PM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Mark vmbus ring buffer visible with set_memory_decrypted() when
> establish gpadl handle.
>
> Signed-off-by: Tianyu Lan
> ---
> Change since v3:
>* Change vmbus_teardown_gpadl() parameter and put gpadl ha
On Fri, Aug 27, 2021 at 01:21:03PM -0400, Tianyu Lan wrote:
> From: Tianyu Lan
>
> Hyperv provides GHCB protocol to write Synthetic Interrupt
> Controller MSR registers in Isolation VM with AMD SEV SNP
> and these registers are emulated by hypervisor directly.
> Hyperv requires to write SINTx MSR
On Sat, Aug 28, 2021 at 02:39:14PM +0800, Bixuan Cui wrote:
> Save the msg context to desc when the msi interrupt is requested.
> The drivers can use it in special scenarios(such as resume).
>
> Signed-off-by: Bixuan Cui
> ---
> drivers/base/platform-msi.c | 3 +++
> 1 file changed, 3 insertions
On Fri, Sep 25, 2020 at 11:45:05AM +, Suravee Suthikulpanit wrote:
> When using 128-bit interrupt-remapping table entry (IRTE) (a.k.a GA mode),
> current driver disables interrupt remapping when it updates the IRTE
> so that the upper and lower 64-bit values can be updated safely.
>
> However,
On Wed, Jan 06, 2021 at 11:41:20AM +0800, Claire Chang wrote:
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes in the device tree.
>
> Signed-off-by: Claire Chang
> ---
> include/linux/device.h | 4 ++
> include/linux/swiotlb.h | 7 +-
>
On Mon, Jan 11, 2021 at 07:43:35AM -0800, Marc Orr wrote:
> This patch updates dma_direct_unmap_sg() to mark each scatter/gather
> entry invalid, after it's unmapped. This fixes two issues:
>
> 1. It makes the unmapping code able to tolerate a double unmap.
> 2. It prevents the NVMe driver from er
On Wed, Jan 13, 2021 at 12:51:26PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 06, 2021 at 08:50:03AM +0100, Greg KH wrote:
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -413,6 +413,7 @@ struct dev_links_info {
> > > * @dm
On Wed, Jan 20, 2021 at 09:42:43AM +, David Woodhouse wrote:
> On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> > From: David Woodhouse
> >
> > Instead of bailing out completely, such a unit can still be used for
> > interrupt remapping.
> >
> > Signed-off-by: David Woodhouse
>
On Wed, Jan 20, 2021 at 03:55:05PM +, David Woodhouse wrote:
> On Wed, 2021-01-20 at 13:06 +0100, Greg KH wrote:
> > On Wed, Jan 20, 2021 at 09:42:43AM +, David Woodhouse wrote:
> > > On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote:
> > &
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 tree
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: dx
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.
> >
> >
On Mon, Apr 30, 2018 at 11:57:20AM +0530, Nipun Gupta wrote:
> Signed-off-by: Nipun Gupta
> ---
I can't take patches without any changelog text at all, sorry. Please
fix up and resend.
greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
h
On Mon, May 14, 2018 at 12:20:20PM -0500, Gary R Hook wrote:
> Provide base enablement for using debugfs to expose internal data of an
> IOMMU driver. When called, create the /sys/kernel/debug/iommu directory.
>
> Emit a strong warning at boot time to indicate that this feature is
> enabled.
>
>
On Tue, May 29, 2018 at 01:23:23PM -0500, Gary R Hook wrote:
> Implement a skeleton framework for debugfs support in the
> AMD IOMMU. Add a hidden boolean to Kconfig that is defined
> for the AMD IOMMU when general IOMMY DebugFS support is
> enabled.
>
> Signed-off-by: Gary R Hook
> ---
> driver
On Tue, May 29, 2018 at 01:23:14PM -0500, Gary R Hook wrote:
> Provide base enablement for using debugfs to expose internal data of an
> IOMMU driver. When called, create the /sys/kernel/debug/iommu directory.
>
> Emit a strong warning at boot time to indicate that this feature is
> enabled.
>
>
On Tue, Jun 05, 2018 at 11:58:13AM -0500, Gary R Hook wrote:
> On 05/29/2018 01:39 PM, Greg KH wrote:
> > On Tue, May 29, 2018 at 01:23:23PM -0500, Gary R Hook wrote:
> > > Implement a skeleton framework for debugfs support in the
> > > AMD IOMMU. Add a hidden boolean
On Tue, Jun 05, 2018 at 12:01:41PM -0500, Gary R Hook wrote:
> > > +/**
> > > + * iommu_debugfs_new_driver_dir - create a vendor directory under
> > > debugfs/iommu
> > > + * @vendor: name of the vendor-specific subdirectory to create
> > > + *
> > > + * This function is called by an IOMMU driver
On Tue, Jul 17, 2018 at 12:41:04PM +0100, Sudip Mukherjee wrote:
> Hi Mathias,
>
> On Sat, Jun 30, 2018 at 10:07:04PM +0100, Sudip Mukherjee wrote:
> > Hi Mathias,
> >
> > On Fri, Jun 29, 2018 at 02:41:13PM +0300, Mathias Nyman wrote:
> > > On 27.06.2018 14:59, Sudip Mukherjee wrote:
> > > > > >
On Tue, Jul 17, 2018 at 02:20:00PM +0100, Sudip Mukherjee wrote:
> Hi Greg,
>
> On Tue, Jul 17, 2018 at 02:04:11PM +0200, Greg KH wrote:
> > On Tue, Jul 17, 2018 at 12:41:04PM +0100, Sudip Mukherjee wrote:
> > > Hi Mathias,
> > >
> > > On Sat, Jun 30,
On Tue, Jul 17, 2018 at 10:31:38AM -0400, Alan Stern wrote:
> On Tue, 17 Jul 2018, Greg KH wrote:
>
> > > From: Sudip Mukherjee
> > > Date: Tue, 10 Jul 2018 09:50:00 +0100
> > > Subject: [PATCH] hacky solution to mem-corruption
> >
On Mon, Sep 14, 2015 at 09:17:08PM +0530, Viresh Kumar wrote:
> On 14-09-15, 17:39, Arnd Bergmann wrote:
> > On Monday 14 September 2015 09:21:54 Viresh Kumar wrote:
> > > diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> > > index b4c216bab22b..bea8e425a8de 100644
> > > --- a/drivers/ac
On Fri, Oct 09, 2015 at 12:41:03PM -0600, Alex Williamson wrote:
> This allows us to more easily create a "vfio" module that includes
> multiple files. No code change, rename and Makefile update only.
>
> Signed-off-by: Alex Williamson
> ---
> drivers/vfio/Makefile|1
> drivers/vfio/vf
On Thu, Jul 07, 2022 at 02:56:34PM +0800, kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 088b9c375534d905a4d337c78db3b3bfbb52c4a0 Add linux-next
> specific files for 20220706
>
> Error/Warning reports:
>
> htt
99 matches
Mail list logo
