> From: Jason Gunthorpe
> Sent: Tuesday, February 18, 2025 11:36 PM
>
> 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,
> > +
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
On Tue, Feb 18, 2025 at 11:29:59AM -0400, Jason Gunthorpe wrote:
> 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 (ato
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 +
>
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 situation is made clear in the
'note
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
32 matches
Mail list logo
