Andrew Morton wrote:
> On Thu, 9 Jan 2025 23:05:56 -0800 Dan Williams
> wrote:
>
> > > - Remove PTE_DEVMAP definitions from Loongarch which were added since
> > >this series was initially written.
> > [..]
> > >
> > > base-commit: e25c8d66f6786300b680866c0e0139981273feba
> >
> > If this i
On Sat, Jan 4, 2025 at 2:37 AM Matthew Maurer wrote:
>
> From: Sami Tolvanen
>
> Previously, two things stopped Rust from using MODVERSIONS:
> 1. Rust symbols are occasionally too long to be represented in the
>original versions table
> 2. Rust types cannot be properly hashed by the existing
On Thu, 9 Jan 2025 23:05:56 -0800 Dan Williams wrote:
> > - Remove PTE_DEVMAP definitions from Loongarch which were added since
> >this series was initially written.
> [..]
> >
> > base-commit: e25c8d66f6786300b680866c0e0139981273feba
>
> If this is going to go through nvdimm.git I will ne
On Fri, Jan 10, 2025 at 03:49:50PM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 10, 2025 at 11:27:53AM -0800, Nicolin Chen wrote:
> > On Fri, Jan 10, 2025 at 01:48:42PM -0400, Jason Gunthorpe wrote:
> > > On Tue, Jan 07, 2025 at 09:10:09AM -0800, Nicolin Chen wrote:
> > >
> > > > +static ssize_t io
On Fri, Jan 10, 2025 at 04:21:35PM -0800, Jacob Keller wrote:
> However, all of the existing tooling we have for the kernel does not
> support the date, and I think its not worth trying to change it at this
> point. It doesn't make sense to break all this tooling for information
> which is accessib
On Fri, Jan 10, 2025 at 01:38:06PM +0900, Akihiko Odaki wrote:
> On 2025/01/09 21:46, Willem de Bruijn wrote:
> > Akihiko Odaki wrote:
> > > On 2025/01/09 16:31, Michael S. Tsirkin wrote:
> > > > On Thu, Jan 09, 2025 at 03:58:44PM +0900, Akihiko Odaki wrote:
> > > > > tun used to simply advance iov
s.
It is also possible to make future drivers with existing kernels and
QEMU by ensuring they will not read num_buffers when
VIRTIO_NET_F_MRG_RXBUF has not negotiated, and that's what "[PATCH v3]
virtio-net: Ignore num_buffers when unused" does.
https://lore.kernel.org/r/2025011
On 2025/01/10 12:27, Jason Wang wrote:
On Thu, Jan 9, 2025 at 2:59 PM Akihiko Odaki wrote:
tun used to simply advance iov_iter when it needs to pad virtio header,
which leaves the garbage in the buffer as is. This is especially
problematic when tun starts to allow enabling the hash reporting
f
On Fri, Jan 10, 2025 at 11:27:13AM +0800, Jason Wang wrote:
> On Thu, Jan 9, 2025 at 2:59 PM Akihiko Odaki wrote:
> >
> > The specification says the device MUST set num_buffers to 1 if
> > VIRTIO_NET_F_MRG_RXBUF has not been negotiated.
>
> Have we agreed on how to fix the spec or not?
>
> As I
On 2025/01/09 23:06, Willem de Bruijn wrote:
Akihiko Odaki wrote:
Both tun and tap exposes the same set of virtio-net-related features.
Unify their implementations to ease future changes.
Signed-off-by: Akihiko Odaki
---
MAINTAINERS| 1 +
drivers/net/Kconfig| 5 ++
driv
On 2025/01/09 23:36, Willem de Bruijn wrote:
Akihiko Odaki wrote:
The added tests confirm tun can perform RSS and hash reporting, and
reject invalid configurations for them.
Signed-off-by: Akihiko Odaki
---
tools/testing/selftests/net/Makefile | 2 +-
tools/testing/selftests/net/tun.c
On 2025/01/09 23:13, Willem de Bruijn wrote:
Akihiko Odaki wrote:
They are useful to implement VIRTIO_NET_F_RSS and
VIRTIO_NET_F_HASH_REPORT.
Toeplitz potentially has users beyond virtio. I wonder if we should
from the start implement this as net/core/rss.c.
Or in lib/toeplitz.c just as like
On Fri, 10 Jan 2025 at 08:33, Joey Jiao wrote:
>
> From: "Jiao, Joey"
>
> The current design of KCOV risks frequent buffer overflows. To mitigate
> this, new modes are introduced: KCOV_TRACE_UNIQ_PC, KCOV_TRACE_UNIQ_EDGE,
> and KCOV_TRACE_UNIQ_CMP. These modes allow for the recording of unique
>
On 2025/01/09 23:28, Willem de Bruijn wrote:
Akihiko Odaki wrote:
Hash reporting
--
Allow the guest to reuse the hash value to make receive steering
consistent between the host and guest, and to save hash computation.
RSS
---
RSS is a receive steering algorithm that can be negotia
On 2025/01/10 19:23, Michael S. Tsirkin wrote:
On Fri, Jan 10, 2025 at 11:27:13AM +0800, Jason Wang wrote:
On Thu, Jan 9, 2025 at 2:59 PM Akihiko Odaki wrote:
The specification says the device MUST set num_buffers to 1 if
VIRTIO_NET_F_MRG_RXBUF has not been negotiated.
Have we agreed on how
On 1/10/2025 5:03 AM, Steven Rostedt wrote:
> On Fri, 10 Jan 2025 12:20:09 +
> yek...@red54.com wrote:
>
>> The old Fixes tag style is at least 10 years old. It lacks date
>> information, which can lead to misjudgment. So I added short author date
>> to avoid this. This make it clear at a g
On Fri, Jan 10, 2025 at 07:12:46AM +, Tian, Kevin wrote:
> > + if (!viommu)
> > + return -ENODEV;
> > + if (WARN_ON_ONCE(!viommu->ops || !viommu->ops-
> > >supports_veventq ||
> > +!viommu->ops->supports_veventq(type)))
> > + return -EOPNOTSUPP;
>
>
Akihiko Odaki wrote:
> On 2025/01/10 17:33, Michael S. Tsirkin wrote:
> > On Fri, Jan 10, 2025 at 01:38:06PM +0900, Akihiko Odaki wrote:
> >> On 2025/01/09 21:46, Willem de Bruijn wrote:
> >>> Akihiko Odaki wrote:
> On 2025/01/09 16:31, Michael S. Tsirkin wrote:
> > On Thu, Jan 09, 2025 at
On Fri, Jan 10, 2025 at 12:20:09PM +, yek...@red54.com wrote:
> From: 谢致邦 (XIE Zhibang)
>
> The old Fixes tag style is at least 10 years old. It lacks date
> information, which can lead to misjudgment. So I added short author date
> to avoid this. This make it clear at a glance and reduce
> m
From: 谢致邦 (XIE Zhibang)
The old Fixes tag style is at least 10 years old. It lacks date
information, which can lead to misjudgment. So I added short author date
to avoid this. This make it clear at a glance and reduce
misunderstandings.
For example:
Old Fixes tag style:
* Fixes: fd3040b9394c ("
On Fri, 10 Jan 2025 at 10:23, Marco Elver wrote:
> > From: "Jiao, Joey"
> >
> > The current design of KCOV risks frequent buffer overflows. To mitigate
> > this, new modes are introduced: KCOV_TRACE_UNIQ_PC, KCOV_TRACE_UNIQ_EDGE,
> > and KCOV_TRACE_UNIQ_CMP. These modes allow for the recording of
On Fri, 10 Jan 2025 12:20:09 +
yek...@red54.com wrote:
> The old Fixes tag style is at least 10 years old. It lacks date
> information, which can lead to misjudgment. So I added short author date
> to avoid this. This make it clear at a glance and reduce
> misunderstandings.
How can it lead t
On 1/10/2025 1:52 AM, Simon Horman wrote:
On Wed, Jan 08, 2025 at 09:47:14PM +0800, Luo Jie wrote:
Configure unicast and multicast hardware queues for the PPE
ports to enable packet forwarding between the ports.
Each PPE port is assigned with a range of queues. The queue ID
selection for a p
On 1/10/2025 4:11 AM, Simon Horman wrote:
On Thu, Jan 09, 2025 at 05:27:14PM +, Simon Horman wrote:
On Wed, Jan 08, 2025 at 09:47:11PM +0800, Luo Jie wrote:
The BM (Buffer Management) config controls the pause frame generated
on the PPE port. There are maximum 15 BM ports and 4 groups su
On 1/10/2025 1:42 AM, Simon Horman wrote:
On Wed, Jan 08, 2025 at 09:47:13PM +0800, Luo Jie wrote:
The PPE scheduler settings determine the priority of scheduling the
packet across the different hardware queues per PPE port.
Signed-off-by: Luo Jie
---
drivers/net/ethernet/qualcomm/ppe/ppe
On 1/9/2025 5:15 PM, Krzysztof Kozlowski wrote:
On Wed, Jan 08, 2025 at 09:47:08PM +0800, Luo Jie wrote:
+required:
+ - clocks
+ - clock-names
+ - resets
+ - interrupts
+ - interrupt-names
+
+ ethernet-ports:
This device really looks like DSA or other ethernet
On 1/10/2025 1:58 AM, Simon Horman wrote:
On Wed, Jan 08, 2025 at 09:47:15PM +0800, Luo Jie wrote:
PPE service code is a special code (0-255) that is defined by PPE for
PPE's packet processing stages, as per the network functions required
for the packet.
For packet being sent out by ARM core
On Fri, Jan 10, 2025 at 05:00:35PM +1100, Alistair Popple wrote:
> File systems call dax_break_mapping() prior to reallocating file
> system blocks to ensure the page is not undergoing any DMA or other
> accesses. Generally this is needed when a file is truncated to ensure
> that if a block is real
On Tue, Jan 07, 2025 at 09:10:07AM -0800, Nicolin Chen wrote:
> @@ -433,32 +434,35 @@ void iopt_remove_access(struct io_pagetable *iopt,
> u32 iopt_access_list_id);
> void iommufd_access_destroy_object(struct iommufd_object *obj);
>
> -/*
> - * An iommufd_fault object repr
On Tue, Jan 07, 2025 at 09:10:05AM -0800, Nicolin Chen wrote:
> The infrastructure of a fault object will be shared with a new vEVENTQ
> object in a following change. Add a helper for a vEVENTQ allocator to
> call it too.
>
> Reorder the iommufd_ctx_get and refcount_inc, to keep them symmetrical
>
On Tue, Jan 07, 2025 at 09:10:06AM -0800, Nicolin Chen wrote:
> The new vEVENTQ object will need a similar function for drivers to report
> the vIOMMU related events. Split the common part out to a smaller helper,
> and place it in the header so that CONFIG_IOMMUFD_DRIVER_CORE can include
> that in
On Tue, Jan 07, 2025 at 09:10:04AM -0800, Nicolin Chen wrote:
> Reorder the existing OBJ/IOCTL lists.
>
> Also run clang-format for the same coding style at line wrappings.
>
> No functional change.
>
> Reviewed-by: Lu Baolu
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/iommufd/main.c |
On Tue, Jan 07, 2025 at 09:10:08AM -0800, Nicolin Chen wrote:
> Rename the file, aligning with the new eventq object.
>
> Reviewed-by: Kevin Tian
> Reviewed-by: Lu Baolu
> Signed-off-by: Nicolin Chen
> ---
> drivers/iommu/iommufd/Makefile | 2 +-
> drivers/iommu/iommufd/{fault.c =
On Fri, Jan 10, 2025 at 05:00:33PM +1100, Alistair Popple wrote:
> Prior to freeing a block file systems supporting FS DAX must check
> that the associated pages are both unmapped from user-space and not
> undergoing DMA or other access from eg. get_user_pages(). This is
> achieved by unmapping the
On Fri, Jan 10, 2025 at 05:00:49PM +1100, Alistair Popple wrote:
> Currently fs dax pages are considered free when the refcount drops to
> one and their refcounts are not increased when mapped via PTEs or
> decreased when unmapped. This requires special logic in mm paths to
> detect that these page
On Sat, Jan 4, 2025 at 2:37 AM Matthew Maurer wrote:
>
> This patch series is intended for use alongside the Implement DWARF
> modversions series [1] to enable RUST and MODVERSIONS at the same
> time.
>
> Elsewhere, we've seen a desire for long symbol name support for LTO
> symbol names [2], and t
On Tue, Jan 07, 2025 at 09:10:11AM -0800, Nicolin Chen wrote:
> +/*
> + * Typically called in driver's threaded IRQ handler.
> + * The @type and @event_data must be defined in include/uapi/linux/iommufd.h
> + */
> +int iommufd_viommu_report_event(struct iommufd_viommu *viommu,
> +
On Tue, Jan 07, 2025 at 09:10:09AM -0800, Nicolin Chen wrote:
> +static ssize_t iommufd_veventq_fops_read(struct iommufd_eventq *eventq,
> + char __user *buf, size_t count,
> + loff_t *ppos)
> +{
> + size_t done = 0;
> +
On Fri, Jan 10, 2025 at 10:38:42AM -0800, Nicolin Chen wrote:
> > The virtual event queue should behave the same as if the physical
> > event queue overflows, and that logic should be in the smmu driver -
> > this should return some Exxx to indicate the queue is filled.
>
> Hmm, the driver only sc
On Fri, Jan 10, 2025 at 11:27:53AM -0800, Nicolin Chen wrote:
> On Fri, Jan 10, 2025 at 01:48:42PM -0400, Jason Gunthorpe wrote:
> > On Tue, Jan 07, 2025 at 09:10:09AM -0800, Nicolin Chen wrote:
> >
> > > +static ssize_t iommufd_veventq_fops_read(struct iommufd_eventq *eventq,
> > > +
On Fri, Jan 10, 2025 at 03:51:14PM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 10, 2025 at 10:38:42AM -0800, Nicolin Chen wrote:
> > > The virtual event queue should behave the same as if the physical
> > > event queue overflows, and that logic should be in the smmu driver -
> > > this should retur
On Fri, Jan 10, 2025 at 01:41:32PM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 07, 2025 at 09:10:11AM -0800, Nicolin Chen wrote:
> > +/*
> > + * Typically called in driver's threaded IRQ handler.
> > + * The @type and @event_data must be defined in
> > include/uapi/linux/iommufd.h
> > + */
> > +in
On Fri, Jan 10, 2025 at 10:51:49AM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 10, 2025 at 07:12:46AM +, Tian, Kevin wrote:
>
> > > + if (!viommu)
> > > + return -ENODEV;
> > > + if (WARN_ON_ONCE(!viommu->ops || !viommu->ops-
> > > >supports_veventq ||
> > > + !viommu-
On Fri, Jan 10, 2025 at 01:48:42PM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 07, 2025 at 09:10:09AM -0800, Nicolin Chen wrote:
>
> > +static ssize_t iommufd_veventq_fops_read(struct iommufd_eventq *eventq,
> > +char __user *buf, size_t count,
> > +
On 2025/01/10 17:33, Michael S. Tsirkin wrote:
On Fri, Jan 10, 2025 at 01:38:06PM +0900, Akihiko Odaki wrote:
On 2025/01/09 21:46, Willem de Bruijn wrote:
Akihiko Odaki wrote:
On 2025/01/09 16:31, Michael S. Tsirkin wrote:
On Thu, Jan 09, 2025 at 03:58:44PM +0900, Akihiko Odaki wrote:
tun us
On Fri, Jan 10, 2025 at 01:26:37PM -0400, Jason Gunthorpe wrote:
> +#define INIT_EVENTQ_FOPS(read_op, write_op) \
> + (struct file_operations){ \
> + .owner = THIS_MODULE, \
> + .open = nonseekab
On Fri, Jan 10, 2025 at 07:06:49AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Wednesday, January 8, 2025 1:10 AM
> > +
> > +int iommufd_veventq_alloc(struct iommufd_ucmd *ucmd)
> > +{
> > + struct iommu_veventq_alloc *cmd = ucmd->cmd;
> > + struct iommufd_veventq *veventq;
> >
On Fri, Jan 10, 2025 at 07:07:36AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Wednesday, January 8, 2025 1:10 AM
> > +
> > + xa_lock(&viommu->vdevs);
> > + xa_for_each(&viommu->vdevs, index, vdev) {
> > + if (vdev && vdev->dev == dev) {
> > + vdev_id
48 matches
Mail list logo
