RE: [PATCH v10 0/9] ACPI/IORT: Support for IORT RMR node

Thu, 21 Apr 2022 07:43:27 -0700 


> -----Original Message-----
> From: Steven Price [mailto:[email protected]]
> Sent: 21 April 2022 13:59
> To: Shameerali Kolothum Thodi <[email protected]>;
> [email protected]; [email protected];
> [email protected]
> Cc: Linuxarm <[email protected]>; [email protected];
> [email protected]; [email protected]; [email protected]; wanghuiqiang
> <[email protected]>; Guohanjun (Hanjun Guo)
> <[email protected]>; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> Subject: Re: [PATCH v10 0/9] ACPI/IORT: Support for IORT RMR node
> 
> On 20/04/2022 17:48, Shameer Kolothum wrote:
> > Hi
> >
> > v9 --> v10
> >  - Dropped patch #1 ("Add temporary RMR node flag definitions") since
> >    the ACPICA header updates patch is now in the mailing list[1]
> >  - Based on the suggestion from Christoph, introduced a
> >    resv_region_free_fw_data() callback in struct iommu_resv_region and
> >    used that to free RMR specific memory allocations.
> >
> > Though there is a small change from v9 with respect to how we free up
> > the FW specific data, I have taken the liberty to pick up the R-by and
> > T-by tags from Lorenzo, Steve and Laurentiu. But please do take a look
> > again and let me know.
> 
> I've given this a go and it works fine on my Juno setup. So do keep my
> T-by tag.

Many thanks for that.

> Sami has been kind enough to give me an updated firmware which also
> fixes the RMR node in the IORT. Although as mentioned before the details
> of the RMR node are currently being ignored so this doesn't change the
> functionality but silences the warning.
> 
> My concern is that with the RMR region effectively ignored we may see
> more broken firmware, and while a length of zero produces a warning, an
> otherwise incorrect length will currently "silently work" but mean that
> any future tightening would cause problems. For example if the SMMU
> driver were to recreate the mappings to only cover the region specified
> in the RMR it may not be large enough if the RMR base/length are not
> correct.

Not sure how we can further validate the RMR if the firmware provides an
incorrect one. I see your point of future tightening causing problems
with broken firmware. But then it is indeed a "broken firmware"...

 It's up to the maintainers as to whether they see this as a
> problem or not.

Hi Robin,

Any thoughts on this?

Thanks,
Shameer

_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu























					Reply via email to