On Tue, Feb 18, 2025 at 12:37:28PM +0100, David Hildenbrand wrote:
> On 18.02.25 04:55, 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 s
On Mon, Feb 17, 2025 at 09:37:26AM +, Marc Zyngier wrote:
> Mark Brown wrote:
> > On Fri, Feb 14, 2025 at 09:24:03AM +, Marc Zyngier wrote:
> > > Why SVCR? This isn't a register, just an architected accessor to
> > > PSTATE.{ZA,SM}. Userspace already has direct access to PSTATE, so I
> >
Sorry, fell behind on things again...
Thorsten Leemhuis writes:
>> - It would be awfully nice if we could provide this advice in exactly
>> one place in the document. This is one of our most important docs,
>> and it is far too long to expect new contributors to read through and
>> absorb
Mauro Carvalho Chehab writes:
>> WARNING: Documentation/ABI/testing/sysfs-class-cxl not found
>
> I need to double-check verify this one, as it didn't appear on
> my tests. Are you getting it against docs-next or linux-next?
I get this one too, FWIW.
I've gone ahead and applied the series, but
Lorenzo Stoakes writes:
> Add a reference to my new book, The Linux Memory Manager, an in-depth
> exploration of the memory management subsystem, to
> process/kernel-docs.rst.
>
> This is not yet published, but the full draft is available on pre-order, so
> it seems worthwhile adding it here. The
On Tue, Feb 18, 2025 at 03:08:46PM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 18, 2025 at 11:02:23AM -0800, Nicolin Chen wrote:
> > > > > This already holds the streams_mutex across all of this, do you think
> > > > > we should get rid of the vmaster_rwsem and hold the streams_mutex on
> > > > > w
On Tue, Feb 18, 2025 at 11:02:23AM -0800, Nicolin Chen wrote:
> > > > This already holds the streams_mutex across all of this, do you think
> > > > we should get rid of the vmaster_rwsem and hold the streams_mutex on
> > > > write instead?
> > >
> > > They are per master v.s. per smmu. The latter
On Tue, Feb 18, 2025 at 02:50:46PM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 18, 2025 at 10:28:04AM -0800, Nicolin Chen wrote:
> > On Tue, Feb 18, 2025 at 01:18:21PM -0400, Jason Gunthorpe wrote:
> > > On Fri, Jan 24, 2025 at 04:30:42PM -0800, Nicolin Chen wrote:
> > >
> > > > @@ -1831,31 +1831,
On Tue, Feb 18, 2025 at 06:17:15PM +, Pranjal Shrivastava wrote:
> On Tue, Feb 18, 2025 at 05:24:08AM +, Tian, Kevin wrote:
> > > From: Nicolin Chen
> > > Sent: Saturday, January 25, 2025 8:31 AM
> > >
> > > There is a DoS concern on the shared hardware event queue among devices
> > > pas
On Tue, Feb 18, 2025 at 06:17:15PM +, Pranjal Shrivastava wrote:
> > Is MEV available only in nested mode? Otherwise it perhaps makes
> > sense to turn it on in all configurations in IOMMUFD paths...
>
> I think the arm-smmu-v3's iommufd implementation only supports nested
> which could be th
On Tue, Feb 18, 2025 at 10:28:04AM -0800, Nicolin Chen wrote:
> On Tue, Feb 18, 2025 at 01:18:21PM -0400, Jason Gunthorpe wrote:
> > On Fri, Jan 24, 2025 at 04:30:42PM -0800, Nicolin Chen wrote:
> >
> > > @@ -1831,31 +1831,30 @@ static int arm_smmu_handle_event(struct
> > > arm_smmu_device *smmu,
On Tue, Feb 18, 2025 at 01:18:21PM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 24, 2025 at 04:30:42PM -0800, Nicolin Chen wrote:
>
> > @@ -1831,31 +1831,30 @@ static int arm_smmu_handle_event(struct
> > arm_smmu_device *smmu,
> > return -EOPNOTSUPP;
> > }
>
> There is still the f
On Tue, Feb 18, 2025 at 05:24:08AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Saturday, January 25, 2025 8:31 AM
> >
> > There is a DoS concern on the shared hardware event queue among devices
> > passed through to VMs, that too many translation failures that belong to
> > VMs cou
On Tue, Feb 18, 2025 at 02:08:05PM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 18, 2025 at 09:47:50AM -0800, Nicolin Chen wrote:
> > > > +int iommufd_veventq_alloc(struct iommufd_ucmd *ucmd)
> > > > +{
> > > > + struct iommu_veventq_alloc *cmd = ucmd->cmd;
> > > > + struct iommufd_veven
On Tue, Feb 18, 2025 at 01:21:20PM -0400, Jason Gunthorpe wrote:
> On Fri, Jan 24, 2025 at 04:30:43PM -0800, Nicolin Chen wrote:
> > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> > @@ -1051,7 +1051,7 @@ void arm_smmu_get_ste_used(const __l
On Tue, Feb 18, 2025 at 09:47:50AM -0800, Nicolin Chen wrote:
> I think we can do:
> if (!list_empty(list)) {
> struct iommufd_vevent *next;
>
> next = list_first_entry(list, struct iommufd_vevent, node);
> if (next == &veventq->overflow) {
>
On Tue, Feb 18, 2025 at 05:13:47AM +, Tian, Kevin wrote:
> > From: Nicolin Chen
> > Sent: Saturday, January 25, 2025 8:31 AM
> > +
> > +/*
> > + * An iommufd_veventq object represents an interface to deliver vIOMMU
> > events to
> > + * the user space. It is created/destroyed by the user space
gt; *inode, struct file *filep)
> > {
> > struct iommufd_eventq *eventq = filep->private_data;
> >
> > + if (eventq->obj.type == IOMMUFD_OBJ_VEVENTQ) {
> > + atomic_set(&eventq_to_veventq(eventq)->sequence, 0);
> > +
On Fri, Jan 24, 2025 at 04:30:42PM -0800, Nicolin Chen wrote:
> @@ -1831,31 +1831,30 @@ static int arm_smmu_handle_event(struct
> arm_smmu_device *smmu,
> return -EOPNOTSUPP;
> }
There is still the filter at the top:
switch (event->id) {
case EVT_ID_TRANSLATI
Hello,
On 2/18/25 09:43, Lorenzo Stoakes wrote:
> Add a reference to my new book, The Linux Memory Manager, an in-depth
> exploration of the memory management subsystem, to
> process/kernel-docs.rst.
>
> This is not yet published, but the full draft is available on pre-order, so
> it seems worthwh
On Fri, Jan 24, 2025 at 04:30:43PM -0800, Nicolin Chen wrote:
> There is a DoS concern on the shared hardware event queue among devices
> passed through to VMs, that too many translation failures that belong to
> VMs could overflow the shared hardware event queue if those VMs or their
> VMMs don't
On Fri, Jan 24, 2025 at 04:30:41PM -0800, Nicolin Chen wrote:
> + int ret;
> struct arm_smmu_ste ste;
> struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> + struct arm_smmu_attach_state state = {
> + .master = master,
> + };
> +
> + ret = arm_smmu_at
On Fri, Jan 24, 2025 at 04:30:40PM -0800, Nicolin Chen wrote:
> With the introduction of the new objects, update the doc to reflect that.
>
> Reviewed-by: Lu Baolu
> Reviewed-by: Kevin Tian
> Signed-off-by: Nicolin Chen
> ---
> Documentation/userspace-api/iommufd.rst | 17 +
>
On Fri, Jan 24, 2025 at 04:30:36PM -0800, Nicolin Chen wrote:
> +int iommufd_viommu_report_event(struct iommufd_viommu *viommu,
> + enum iommu_veventq_type type, void *event_data,
> + size_t data_len)
> +{
> + struct iommufd_veventq *veven
On Fri, Jan 24, 2025 at 04:30:35PM -0800, Nicolin Chen wrote:
> This is a reverse search v.s. iommufd_viommu_find_dev, as drivers may want
> to convert a struct device pointer (physical) to its virtual device ID for
> an event injection to the user space VM.
>
> Again, this avoids exposing more co
On Fri, Jan 24, 2025 at 04:30:34PM -0800, Nicolin Chen wrote:
> + list_add_tail(&vevent->node, &eventq->deliver);
> + vevent->on_list = true;
> + vevent->header.sequence = atomic_read(&veventq->sequence);
> + if (atomic_read(&veventq->sequence) == INT_MAX)
> + atomic_set
On 18.02.25 04:55, 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 pages should not be properly refc
On Tue, Feb 18, 2025 at 04:20:06PM +0800, David Gow wrote:
> On Mon, 17 Feb 2025 at 19:00, Thomas Weißschuh
> wrote:
> >
> > Currently testing of userspace and in-kernel API use two different
> > frameworks. kselftests for the userspace ones and Kunit for the
> > in-kernel ones. Besides their diff
On Mon, 17 Feb 2025 at 19:00, Thomas Weißschuh
wrote:
>
> Currently testing of userspace and in-kernel API use two different
> frameworks. kselftests for the userspace ones and Kunit for the
> in-kernel ones. Besides their different scopes, both have different
> strengths and limitations:
>
> Kuni
> From: Nicolin Chen
> Sent: Saturday, January 25, 2025 8:31 AM
>
> When attaching a device to a vIOMMU-based nested domain, vdev_id must
> be
> present. Add a piece of code hard-requesting it, preparing for a vEVENTQ
> support in the following patch. Then, update the TEST_F.
>
> A HWPT-based ne
> From: Nicolin Chen
> Sent: Saturday, January 25, 2025 8:31 AM
>
> Similar to iommu_report_device_fault, this allows IOMMU drivers to report
> vIOMMU events from threaded IRQ handlers to user space hypervisors.
>
> Reviewed-by: Lu Baolu
> Signed-off-by: Nicolin Chen
Reviewed-by: Kevin Tian
> From: Nicolin Chen
> Sent: Saturday, January 25, 2025 8:31 AM
>
> There is a DoS concern on the shared hardware event queue among devices
> passed through to VMs, that too many translation failures that belong to
> VMs could overflow the shared hardware event queue if those VMs or their
> VMMs
> From: Nicolin Chen
> Sent: Saturday, January 25, 2025 8:31 AM
>
> Aside from the IOPF framework, iommufd provides an additional pathway to
> report hardware events, via the vEVENTQ of vIOMMU infrastructure.
>
> Define an iommu_vevent_arm_smmuv3 uAPI structure, and report stage-1
> events
> in
> From: Nicolin Chen
> Sent: Saturday, January 25, 2025 8:31 AM
>
> Trigger vEVENTs by feeding an idev ID and validating the returned output
> virt_ids whether they equal to the value that was set to the vDEVICE.
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Kevin Tian
> From: Nicolin Chen
> Sent: Saturday, January 25, 2025 8:31 AM
>
> The handler will get vDEVICE object from the given mdev and convert it to
> its per-vIOMMU virtual ID to mimic a real IOMMU driver.
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Kevin Tian
> From: Nicolin Chen
> Sent: Saturday, January 25, 2025 8:31 AM
> +
> +/*
> + * An iommufd_veventq object represents an interface to deliver vIOMMU
> events to
> + * the user space. It is created/destroyed by the user space and associated
> with
> + * vIOMMU object(s) during the allocations.
s/ob
> From: Nicolin Chen
> Sent: Saturday, January 25, 2025 8:31 AM
>
> There is no need to keep them in the header. The vEVENTQ version of these
> two functions will turn out to be a different implementation and will not
> share with this fault version. Thus, move them out of the header.
>
> Signed
On Mon, Feb 17, 2025 at 02:30:59PM -0800, Boqun Feng wrote:
>On Mon, Feb 17, 2025 at 09:18:42AM +, Wei Yang wrote:
>> On Mon, Feb 17, 2025 at 04:02:53PM +0800, Alan Huang wrote:
>> >On Feb 17, 2025, at 15:41, Wei Yang wrote:
>> >>
>> >> On Mon, Feb 17, 2025 at 10:22:53AM +0800, Alan Huang wro
ore space out of it, if that would even be needed.
> >>
> >
> > netmem skb are real sk_buff, with the modification that frags are not
>
> We were discussing ubuf_info allocation, take a look at
> msg_zerocopy_alloc(), it has nothing to do with netmems and all that.
>
On Mon, Feb 17, 2025 at 09:18:42AM +, Wei Yang wrote:
> On Mon, Feb 17, 2025 at 04:02:53PM +0800, Alan Huang wrote:
> >On Feb 17, 2025, at 15:41, Wei Yang wrote:
> >>
> >> On Mon, Feb 17, 2025 at 10:22:53AM +0800, Alan Huang wrote:
> >>> On Feb 17, 2025, at 10:12, Boqun Feng wrote:
>
>
On 17.02.25 05:29, Alistair Popple wrote:
On Mon, Feb 10, 2025 at 07:45:09PM +0100, David Hildenbrand wrote:
On 04.02.25 23:48, Alistair Popple wrote:
Currently DAX folio/page reference counts are managed differently to normal
pages. To allow these to be managed the same as normal pages introdu
will select the most appropriate enabled size for a
> > given allocation.
> >
> > +khugepaged use max_ptes_none scaled to the order of the enabled mTHP size
> > to
> > +determine collapses. When using mTHPs its recommended to set max_ptes_none
> > low.
> &
On Mon, Feb 17, 2025 at 8:04 AM Usama Arif wrote:
>
>
>
> On 11/02/2025 00:40, Nico Pache wrote:
> > The new transparent_hugepage=defer option allows for a more conservative
> > approach to THPs. Document its usage in the transhuge admin-guide.
> >
> > Signed-off-by: Nico Pache
> > ---
> > Docum
On Mon, Feb 17, 2025 at 7:59 AM Usama Arif wrote:
>
>
>
> On 11/02/2025 00:40, Nico Pache wrote:
> > setting /transparent_hugepages/enabled=always allows applications
> > to benefit from THPs without having to madvise. However, the pf handler
> > takes very few considerations to decide weather or
On Mon, Feb 17, 2025 at 7:54 AM Usama Arif wrote:
>
>
>
> On 11/02/2025 00:40, Nico Pache wrote:
> > This series is a follow-up to [1], which adds mTHP support to khugepaged.
> > mTHP khugepaged support was necessary for the global="defer" and
> > mTHP="inherit" case (and others) to make sense.
>
On 11/02/2025 00:40, Nico Pache wrote:
> This series is a follow-up to [1], which adds mTHP support to khugepaged.
> mTHP khugepaged support was necessary for the global="defer" and
> mTHP="inherit" case (and others) to make sense.
>
Hi Nico,
Thanks for the patches!
Why is mTHP khugepaged a
On 11/02/2025 00:40, Nico Pache wrote:
> setting /transparent_hugepages/enabled=always allows applications
> to benefit from THPs without having to madvise. However, the pf handler
> takes very few considerations to decide weather or not to actually use a
> THP. This can lead to a lot of wasted
On 11/02/2025 00:40, Nico Pache wrote:
> The new transparent_hugepage=defer option allows for a more conservative
> approach to THPs. Document its usage in the transhuge admin-guide.
>
> Signed-off-by: Nico Pache
> ---
> Documentation/admin-guide/mm/transhuge.rst | 22 +-
>
behavior that leads to continously collapsing to a larger
> +mTHP size. max_ptes_shared and max_ptes_swap have no effect when collapsing
> to a
> +mTHP, and mTHP collapse will fail on shared or swapped out pages.
> +
This paragraph definitely belongs in the khugepaged series, as it doesn&#x
On Fri, 14 Feb 2025 15:13:52 +,
Mark Brown wrote:
>
> On Fri, Feb 14, 2025 at 09:24:03AM +, Marc Zyngier wrote:
> > Mark Brown wrote:
>
> > Just to be clear: I do not intend to review a series that doesn't
> > cover the full gamut of KVM from day 1. Protected mode is an absolute
> > req
On Mon, Feb 17, 2025 at 04:02:53PM +0800, Alan Huang wrote:
>On Feb 17, 2025, at 15:41, Wei Yang wrote:
>>
>> On Mon, Feb 17, 2025 at 10:22:53AM +0800, Alan Huang wrote:
>>> On Feb 17, 2025, at 10:12, Boqun Feng wrote:
Hi Wei,
The change loosk good to me, thanks!
On Feb 17, 2025, at 15:41, Wei Yang wrote:
>
> On Mon, Feb 17, 2025 at 10:22:53AM +0800, Alan Huang wrote:
>> On Feb 17, 2025, at 10:12, Boqun Feng wrote:
>>>
>>> Hi Wei,
>>>
>>> The change loosk good to me, thanks!
>>>
>>> I queued the patch for futher reviews and tests with some changes in
On Mon, Feb 17, 2025 at 10:22:53AM +0800, Alan Huang wrote:
>On Feb 17, 2025, at 10:12, Boqun Feng wrote:
>>
>> Hi Wei,
>>
>> The change loosk good to me, thanks!
>>
>> I queued the patch for futher reviews and tests with some changes in the
>> commit log (for title formating and a bit more exp
On Mon, Feb 10, 2025 at 07:45:09PM +0100, David Hildenbrand wrote:
> On 04.02.25 23:48, Alistair Popple wrote:
> > Currently DAX folio/page reference counts are managed differently to normal
> > pages. To allow these to be managed the same as normal pages introduce
> > vmf_insert_folio_pmd. This wi
On Sat, Feb 15, 2025 at 1:25 PM Akihiko Odaki wrote:
>
> On 2025/02/14 0:43, Michael S. Tsirkin wrote:
> > On Thu, Feb 13, 2025 at 06:23:55PM +0900, Akihiko Odaki wrote:
> >> On 2025/02/13 16:18, Michael S. Tsirkin wrote:
> >>>
> >>> Commit log needs some work.
> >>>
> >>> So my understanding is,
On Mon, Feb 17, 2025 at 10:22:53AM +0800, Alan Huang wrote:
> On Feb 17, 2025, at 10:12, Boqun Feng wrote:
> >
> > Hi Wei,
> >
> > The change loosk good to me, thanks!
> >
> > I queued the patch for futher reviews and tests with some changes in the
> > commit log (for title formating and a bit
On Feb 17, 2025, at 10:12, Boqun Feng wrote:
>
> Hi Wei,
>
> The change loosk good to me, thanks!
>
> I queued the patch for futher reviews and tests with some changes in the
> commit log (for title formating and a bit more explanation), please see
> below.
>
> Regards,
> Boqun
>
> On Wed, Ja
Hi Wei,
The change loosk good to me, thanks!
I queued the patch for futher reviews and tests with some changes in the
commit log (for title formating and a bit more explanation), please see
below.
Regards,
Boqun
On Wed, Jan 01, 2025 at 08:23:06AM +, Wei Yang wrote:
> The example code for "E
On Sunday, February 16, 2025 3:04 AM, Jakub Kicinski wrote:
>On Sat, 15 Feb 2025 11:01:59 -0800 Jakub Kicinski wrote:
>> On Fri, 7 Feb 2025 10:19:39 +0800 Song Yoong Siang wrote:
>> > Extend the XDP Tx metadata framework so that user can requests launch time
>> > hardware offload, where the Ether
On Sat, 15 Feb 2025 11:01:59 -0800 Jakub Kicinski wrote:
> On Fri, 7 Feb 2025 10:19:39 +0800 Song Yoong Siang wrote:
> > Extend the XDP Tx metadata framework so that user can requests launch time
> > hardware offload, where the Ethernet device will schedule the packet for
> > transmission at a pre
On Fri, 7 Feb 2025 10:19:39 +0800 Song Yoong Siang wrote:
> Extend the XDP Tx metadata framework so that user can requests launch time
> hardware offload, where the Ethernet device will schedule the packet for
> transmission at a pre-determined time called launch time. The value of
> launch time i
On 2025/02/14 0:43, Michael S. Tsirkin wrote:
On Thu, Feb 13, 2025 at 06:23:55PM +0900, Akihiko Odaki wrote:
On 2025/02/13 16:18, Michael S. Tsirkin wrote:
Commit log needs some work.
So my understanding is, this patch does not do much functionally,
but makes adding the hash feature easier. O
On Fri, Feb 14, 2025 at 4:47 PM Rasmus Villemoes
wrote:
>
> On Fri, 14 Feb 2025 at 17:53, Tamir Duberstein wrote:
> >
> > On Fri, Feb 14, 2025 at 11:02 AM Andy Shevchenko
> > wrote:
> > >
> > > On Fri, Feb 14, 2025 at 04:35:12PM +0100, Petr Mladek wrote:
>
> > > > I have just quickly tested this
On Fri, 14 Feb 2025 at 17:53, Tamir Duberstein wrote:
>
> On Fri, Feb 14, 2025 at 11:02 AM Andy Shevchenko
> wrote:
> >
> > On Fri, Feb 14, 2025 at 04:35:12PM +0100, Petr Mladek wrote:
> > > I have just quickly tested this before leaving for a week.
> > > And I am fine with the result.
> >
Than
On Fri, Jan 24, 2025 at 04:30:32PM -0800, Nicolin Chen wrote:
> The fault object was designed exclusively for hwpt's IO page faults (PRI).
> But its queue implementation can be reused for other purposes too, such as
> hardware IRQ and event injections to user space.
>
> Meanwhile, a fault object h
On Fri, Jan 24, 2025 at 04:30:30PM -0800, Nicolin Chen wrote:
> There is no need to keep them in the header. The vEVENTQ version of these
> two functions will turn out to be a different implementation and will not
> share with this fault version. Thus, move them out of the header.
>
> Signed-off-b
On Fri, Feb 14, 2025 at 11:02 AM Andy Shevchenko
wrote:
>
> On Fri, Feb 14, 2025 at 04:35:12PM +0100, Petr Mladek wrote:
> > On Mon 2025-02-10 13:23:21, Tamir Duberstein wrote:
> > > This is one of just 3 remaining "Test Module" kselftests (the others
> > > being bitmap and scanf), the rest having
On Fri, Feb 14, 2025 at 04:35:12PM +0100, Petr Mladek wrote:
> On Mon 2025-02-10 13:23:21, Tamir Duberstein wrote:
> > This is one of just 3 remaining "Test Module" kselftests (the others
> > being bitmap and scanf), the rest having been converted to KUnit.
> >
> > I tested this using:
> >
> > $
On Mon 2025-02-10 13:23:21, Tamir Duberstein wrote:
> This is one of just 3 remaining "Test Module" kselftests (the others
> being bitmap and scanf), the rest having been converted to KUnit.
>
> I tested this using:
>
> $ tools/testing/kunit/kunit.py run --arch arm64 --make_options LLVM=1 printf
On Fri, Feb 14, 2025 at 09:24:03AM +, Marc Zyngier wrote:
> Mark Brown wrote:
> Just to be clear: I do not intend to review a series that doesn't
> cover the full gamut of KVM from day 1. Protected mode is an absolute
> requirement. It is the largest KVM deployment, and Android phones the
> o
> > > +/* The number of packets dropped because of no buffer available, no PPE
> > > + * buffer assigned to these packets.
> > > + */
> > > +static void ppe_port_rx_drop_counter_get(struct ppe_device *ppe_dev,
> > > + struct seq_file *seq)
> > > +{
> > > + u32 reg,
On 11/02/2025 06:57, Deepak Gupta wrote:
> On Mon, Feb 10, 2025 at 10:35:47PM +0100, Clément Léger wrote:
>> Add basic infrastructure to support the FWFT extension in KVM.
>>
>> Signed-off-by: Clément Léger
>> ---
>> arch/riscv/include/asm/kvm_host.h | 4 +
>> arch/riscv/include/asm/k
On Fri, 14 Feb 2025 01:57:43 +,
Mark Brown wrote:
>
> I've removed the RFC tag from this version of the series, but the items
> that I'm looking for feedback on remains the same:
>
> - The userspace ABI, in particular:
> - The vector length used for the SVE registers, access to the SVE
>
On Fri, Jan 24, 2025 at 04:30:29PM -0800, Nicolin Chen wrote:
> This is on Github:
> https://github.com/nicolinc/iommufd/commits/iommufd_veventq-v6
>
> Testing with RMR patches for MSI:
> https://github.com/nicolinc/iommufd/commits/iommufd_veventq-v6-with-rmr
> Paring QEMU branch for testing:
> ht
Em Thu, 13 Feb 2025 19:15:28 -0800
Randy Dunlap escreveu:
> Hi Mauro,
>
>
> On 2/13/25 4:06 AM, Mauro Carvalho Chehab wrote:
> > Hi Jon,
> >
> > That's the second version of the Python kernel-doc tool.
> >
> > As the previous version, I tried to stay as close as possible of the
> > original
On 2/11/2025 9:55 PM, Andrew Lunn wrote:
+#define PRINT_COUNTER_PREFIX(desc, cnt_type) \
+ seq_printf(seq, "%-16s %16s", desc, cnt_type)
+
+#define PRINT_CPU_CODE_COUNTER(cnt, code) \
+ seq_printf(seq, "%10u(cpucode:%d)", cnt, code)
+
+#define PRINT_DROP_CODE
On 2/12/2025 9:58 AM, Jie Gan wrote:
+static int qcom_ppe_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ppe_device *ppe_dev;
+ void __iomem *base;
+ int ret, num_icc;
I think it's better with:
int num_icc = ARRAY_SIZE(ppe_icc_data);
This
Hi Mauro,
On 2/13/25 4:06 AM, Mauro Carvalho Chehab wrote:
> Hi Jon,
>
> That's the second version of the Python kernel-doc tool.
>
> As the previous version, I tried to stay as close as possible of the original
> Perl implementation, as it helps to double check if each function was
> properly
Mauro Carvalho Chehab writes:
> This series increases the minimal requirements for Sphinx and Python, and
> drop some backward-compatible code from Sphinx extension.
OK, I've gone ahead and applied this series - let's see who screams...
Thanks,
jon
Em Thu, 13 Feb 2025 13:06:17 +0100
Mauro Carvalho Chehab escreveu:
> +def dump_function(self, ln, prototype):
> +
...
> +(r"""
> + __attribute__\s*\(\(
> +(?:
> +[\w\s]++ # attribute name
> +(?:\([^)]*+
On Thu, Feb 13, 2025 at 06:23:55PM +0900, Akihiko Odaki wrote:
> On 2025/02/13 16:18, Michael S. Tsirkin wrote:
> >
> > Commit log needs some work.
> >
> > So my understanding is, this patch does not do much functionally,
> > but makes adding the hash feature easier. OK.
> >
> > On Thu, Feb 13,
lds for devmem skbs, and having
to start adding skb_is_devmem() checks through all code in the skb
handlers that touch the fields being overwritten in the devmem case.
No, I don't think we can re-use random fields in the skb for devmem.
stashing the binding in ubuf_info_ops (very hacky).
On 2025/02/13 16:18, Michael S. Tsirkin wrote:
Commit log needs some work.
So my understanding is, this patch does not do much functionally,
but makes adding the hash feature easier. OK.
On Thu, Feb 13, 2025 at 03:54:06PM +0900, Akihiko Odaki wrote:
tun used to simply advance iov_iter when it
Commit log needs some work.
So my understanding is, this patch does not do much functionally,
but makes adding the hash feature easier. OK.
On Thu, Feb 13, 2025 at 03:54:06PM +0900, Akihiko Odaki wrote:
> tun used to simply advance iov_iter when it needs to pad virtio header,
> which leaves the
On Wed, 2025-02-12 at 13:58 +0100, Mauro Carvalho Chehab wrote:
> > WARNING: Documentation/ABI/testing/sysfs-class-cxl not found
>
> I need to double-check verify this one, as it didn't appear on
> my tests. Are you getting it against docs-next or linux-next?
>
This is moved to obsolete/ by 5731
's also not a real sk_buff, so maybe maintainers wouldn't mind
> reusing some more space out of it, if that would even be needed.
>
netmem skb are real sk_buff, with the modification that frags are not
readable, only in the case that the netmem is unreadable. I would not
approve o
On 2/10/25 21:09, Mina Almasry wrote:
On Wed, Feb 5, 2025 at 4:20 AM Pavel Begunkov wrote:
On 2/3/25 22:39, Mina Almasry wrote:
...
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index bb2b751d274a..3ff8f568c382 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@
Em Wed, 12 Feb 2025 18:25:15 +0700
Bagas Sanjaya escreveu:
> On Tue, Feb 11, 2025 at 07:22:54AM +0100, Mauro Carvalho Chehab wrote:
> > Now that ABI creates a python dictionary, use automarkup to create cross
> > references for ABI symbols as well.
>
> I get three new warnings:
>
> WARNING:
On Tue, Feb 11, 2025 at 07:22:54AM +0100, Mauro Carvalho Chehab wrote:
> Now that ABI creates a python dictionary, use automarkup to create cross
> references for ABI symbols as well.
I get three new warnings:
WARNING: /sys/devices/system/cpu/cpuX/topology/physical_package_id is defined 2
times
On 2/11/2025 9:58 PM, Jie Luo wrote:
On 2/10/2025 10:12 AM, Jie Gan wrote:
+static int ppe_clock_init_and_reset(struct ppe_device *ppe_dev)
+{
+ unsigned long ppe_rate = ppe_dev->clk_rate;
+ struct device *dev = ppe_dev->dev;
+ struct reset_control *rstc;
+ struct clk_bulk_data
On 2/11/2025 9:04 PM, Andrew Lunn wrote:
+#ifndef __PPE_H__
+#define __PPE_H__
+
+#include
+#include
+
+struct device;
#include ?
+struct regmap;
Same with previous one, include it's header file?
If the structure is opaque at this level, it is fine to not include
the header. There is
On Tue, Feb 11, 2025 at 07:19:00AM +0100, Mauro Carvalho Chehab wrote:
> This series increases the minimal requirements for Sphinx and Python, and
> drop some backward-compatible code from Sphinx extension.
>
> Looking at Sphinx release dates:
>
> Release 2.4.0 (released Feb 09, 2020)
>
On Tue, Feb 11, 2025 at 11:31:28AM +0100, Clément Léger wrote:
On 11/02/2025 06:43, Deepak Gupta wrote:
+static int kvm_sbi_fwft_get(struct kvm_vcpu *vcpu, unsigned long
feature,
+ unsigned long *value)
+{
+ int ret;
+ struct kvm_sbi_fwft_config *conf;
+
+ ret = kvm_fwf
On 2/10/2025 10:47 AM, Jie Gan wrote:
diff --git a/Documentation/devicetree/bindings/net/qcom,ipq9574-
ppe.yaml b/Documentation/devicetree/bindings/net/qcom,ipq9574-ppe.yaml
new file mode 100644
index ..be6f9311eebb
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qcom,ip
On 2/10/2025 10:12 AM, Jie Gan wrote:
+static int ppe_clock_init_and_reset(struct ppe_device *ppe_dev)
+{
+ unsigned long ppe_rate = ppe_dev->clk_rate;
+ struct device *dev = ppe_dev->dev;
+ struct reset_control *rstc;
+ struct clk_bulk_data *clks;
+ struct clk *clk;
+ int re
> +#define PRINT_COUNTER_PREFIX(desc, cnt_type) \
> + seq_printf(seq, "%-16s %16s", desc, cnt_type)
> +
> +#define PRINT_CPU_CODE_COUNTER(cnt, code)\
> + seq_printf(seq, "%10u(cpucode:%d)", cnt, code)
> +
> +#define PRINT_DROP_CODE_COUNTER(cnt, port, code) \
> +
> +/* Scheduler configuration for the assigning and releasing buffers for the
> + * packet passing through PPE, which is different per SoC.
> + */
> +static const struct ppe_scheduler_bm_config ipq9574_ppe_sch_bm_config[] = {
> + {1, 0, 0, 0, 0},
> + {1, 1, 0, 0, 0},
> + {1, 0, 5, 0, 0}
> + /* Configure BM flow control related threshold. */
> + PPE_BM_PORT_FC_SET_WEIGHT(bm_fc_val, port_cfg.weight);
> + PPE_BM_PORT_FC_SET_RESUME_OFFSET(bm_fc_val, port_cfg.resume_offset);
> + PPE_BM_PORT_FC_SET_RESUME_THRESHOLD(bm_fc_val, port_cfg.resume_ceil);
> + PPE_BM_PORT_FC
> +/* Assign the share buffer number 1550 to group 0 by default. */
> +static const int ipq9574_ppe_bm_group_config = 1550;
To a large extent, the comment is useless. What should be in the
comment is why, not what.
Andrew
1 - 100 of 2802 matches
Mail list logo
