[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 05/11] mm: move modify_identity_mmio to global file and drop __init
On Tue, Sep 12, 2017 at 11:53:49AM +0100, Julien Grall wrote: > Hi Roger, > > On 14/08/17 15:28, Roger Pau Monne wrote: > > And also allow it to do non-identity mappings by adding a new > > parameter. > > > > This function will be needed in order to map the BARs from PCI devices > > into the Dom0 p2m (and is also used by the x86 Dom0 builder). While > > there fix the function to use gfn_t and mfn_t instead of unsigned long > > for memory addresses. > > > Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> > > --- > > Cc: Jan Beulich <jbeulich@xxxxxxxx> > > Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > > --- > > Changes since v4: > > - Guard the function with CONFIG_HAS_PCI only. > > - s/non-trival/non-negligible in the comment. > > - Change XENLOG_G_WARNING to XENLOG_WARNING like the original > > function. > > > > Changes since v3: > > - Remove the dummy modify_identity_mmio helper in dom0_build.c > > - Try to make the comment in modify MMIO less scary. > > - Clarify commit message. > > - Only build the function for x86 or if there's PCI support. > > > > Changes since v2: > > - Use mfn_t and gfn_t. > > - Remove stray newline. > > --- > > xen/arch/x86/hvm/dom0_build.c | 30 ++---------------------------- > > xen/common/memory.c | 40 > > ++++++++++++++++++++++++++++++++++++++++ > > xen/include/xen/p2m-common.h | 3 +++ > > 3 files changed, 45 insertions(+), 28 deletions(-) > > > > diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c > > index 04a8682d33..c65eb8503f 100644 > > --- a/xen/arch/x86/hvm/dom0_build.c > > +++ b/xen/arch/x86/hvm/dom0_build.c > > @@ -61,32 +61,6 @@ static struct acpi_madt_interrupt_override __initdata > > *intsrcovr; > > static unsigned int __initdata acpi_nmi_sources; > > static struct acpi_madt_nmi_source __initdata *nmisrc; > > -static int __init modify_identity_mmio(struct domain *d, unsigned long pfn, > > - unsigned long nr_pages, const bool > > map) > > -{ > > - int rc; > > - > > - for ( ; ; ) > > - { > > - rc = (map ? map_mmio_regions : unmap_mmio_regions) > > - (d, _gfn(pfn), nr_pages, _mfn(pfn)); > > - if ( rc == 0 ) > > - break; > > - if ( rc < 0 ) > > - { > > - printk(XENLOG_WARNING > > - "Failed to identity %smap [%#lx,%#lx) for d%d: %d\n", > > - map ? "" : "un", pfn, pfn + nr_pages, d->domain_id, rc); > > - break; > > - } > > - nr_pages -= rc; > > - pfn += rc; > > - process_pending_softirqs(); > > - } > > - > > - return rc; > > -} > > - > > /* Populate a HVM memory range using the biggest possible order. */ > > static int __init pvh_populate_memory_range(struct domain *d, > > unsigned long start, > > @@ -397,7 +371,7 @@ static int __init pvh_setup_p2m(struct domain *d) > > * Memory below 1MB is identity mapped. > > * NB: this only makes sense when booted from legacy BIOS. > > */ > > - rc = modify_identity_mmio(d, 0, MB1_PAGES, true); > > + rc = modify_mmio(d, _gfn(0), _mfn(0), MB1_PAGES, true); > > if ( rc ) > > { > > printk("Failed to identity map low 1MB: %d\n", rc); > > @@ -964,7 +938,7 @@ static int __init pvh_setup_acpi(struct domain *d, > > paddr_t start_info) > > nr_pages = PFN_UP((d->arch.e820[i].addr & ~PAGE_MASK) + > > d->arch.e820[i].size); > > - rc = modify_identity_mmio(d, pfn, nr_pages, true); > > + rc = modify_mmio(d, _gfn(pfn), _mfn(pfn), nr_pages, true); > > if ( rc ) > > { > > printk("Failed to map ACPI region [%#lx, %#lx) into Dom0 > > memory map\n", > > diff --git a/xen/common/memory.c b/xen/common/memory.c > > index b2066db07e..86824edb09 100644 > > --- a/xen/common/memory.c > > +++ b/xen/common/memory.c > > @@ -1465,6 +1465,46 @@ int prepare_ring_for_helper( > > return 0; > > } > > +#if defined(CONFIG_HAS_PCI) > > +int modify_mmio(struct domain *d, gfn_t gfn, mfn_t mfn, unsigned long > > nr_pages, > > + bool map) > > +{ > > I don't think this is correct to move this function in common code without > making sure that all arch have *map_mmio_regions supporting preemption. > > This is actually not the case on ARM and IHMO should be fixed before getting > this function common. Otherwise you will expose a security issue the day > vCPI will get supported on ARM. I could add something like: #ifndef CONFIG_X86 /* XXX ARM!? */ ret = -E2BIG; /* Must break hypercall up as this could take a while. */ if ( nr_mfns > 64 ) break; #endif That's what's done in XEN_DOMCTL_memory_mapping. > > + int rc; > > + > > + /* > > + * ATM this function should only be used by the hardware domain > > + * because it doesn't support preemption/continuation, and as such > > + * can take a non-negligible amount of time. Note that it periodically > > + * calls process_pending_softirqs in order to avoid stalling the > > system. > > + */ > > + ASSERT(is_hardware_domain(d)); > > + > > + for ( ; ; ) > > + { > > + rc = (map ? map_mmio_regions : unmap_mmio_regions) > > As mentioned in an earlier version, on ARM map_mmio_regions will map the > MMIO with very strict attribute (no-unaligned access, non-gatherable,...). > This will not be correct for some BARs. So I think we should provide the > attribute type in parameter of modify_mmio to know the memory attribute. As I understand it, current mapping attributes albeit slow will work fine? At least they are the same as the ones used by XEN_DOMCTL_memory_mapping which is how MMIO is mapped to a DomU ATM, hence I don't think this is a priority at such early state. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |