On Tue, Mar 12, 2024 at 11:53:46AM +0100, Jan Beulich wrote: > On 12.03.2024 11:24, Roger Pau Monné wrote: > >> --- a/xen/arch/x86/setup.c > >> +++ b/xen/arch/x86/setup.c > >> @@ -1806,6 +1806,9 @@ void asmlinkage __init noreturn __start_xen(unsigned > >> long mbi_p) > >> mmio_ro_ranges = rangeset_new(NULL, "r/o mmio ranges", > >> RANGESETF_prettyprint_hex); > >> > >> + /* Needs to happen after E820 processing but before IOMMU init */ > >> + xhci_dbc_uart_reserve_ram(); > > > > Overall it might be better if some generic solution for all users of > > iommu_add_extra_reserved_device_memory() could be implemented, > > +1
In that case, is the approach with iommu_get_extra_reserved_device_memory() okay (and a comment that it will have a side effect...) ? > > but I'm > > unsure whether the intention is for the interface to always be used > > against RAM. > > I think we can work from that assumption for now. Ok, I'll add a comment about that. I guess, if needed in the future, iommu_add_extra_reserved_device_memory() can gain an extra parameter to distinguish RAM from non-RAM mappings. BTW should e820_change_range_type() return 1 in case of mapping already having the right type? Otherwise, if one wants to use iommu_add_extra_reserved_device_memory() on already reserved memory, the e820_change_range_type() would fail. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
signature.asc
Description: PGP signature
