[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 06/12] xen/gnttab: Pass max_{grant, maptrack}_frames into grant_table_create()
On 15/08/18 14:04, Julien Grall wrote: > Hi Andrew, > > On 08/13/2018 11:01 AM, Andrew Cooper wrote: >> ... rather than setting the limits up after domain_create() has >> completed. >> >> This removes all the gnttab infrastructure for calculating the number >> of dom0 >> grant frames, opting instead to require the dom0 construction code to >> pass a >> sane value in via the configuration. >> >> In practice, this now means that there is never a partially >> constructed grant >> table for a reference-able domain. >> >> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> >> --- >> CC: Jan Beulich <JBeulich@xxxxxxxx> >> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx> >> CC: Julien Grall <julien.grall@xxxxxxx> >> CC: Wei Liu <wei.liu2@xxxxxxxxxx> >> >> v2: >> * Split/rearrange to avoid the post-domain-create error path. >> --- >> xen/arch/arm/domain_build.c | 3 ++- >> xen/arch/arm/setup.c | 12 ++++++++++++ >> xen/arch/x86/setup.c | 3 +++ >> xen/common/domain.c | 3 ++- >> xen/common/grant_table.c | 16 +++------------- >> xen/include/asm-arm/grant_table.h | 12 ------------ >> xen/include/asm-x86/grant_table.h | 5 ----- >> xen/include/xen/grant_table.h | 6 ++---- >> 8 files changed, 24 insertions(+), 36 deletions(-) >> >> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c >> index 1351572..737e0f3 100644 >> --- a/xen/arch/arm/domain_build.c >> +++ b/xen/arch/arm/domain_build.c >> @@ -2079,7 +2079,8 @@ static void __init find_gnttab_region(struct >> domain *d, >> * enough space for a large grant table >> */ >> kinfo->gnttab_start = __pa(_stext); >> - kinfo->gnttab_size = gnttab_dom0_frames() << PAGE_SHIFT; >> + kinfo->gnttab_size = min_t(unsigned int, opt_max_grant_frames, >> + PFN_DOWN(_etext - _stext)) << >> PAGE_SHIFT; > > > I agree with Jan's comment on v1 that there is a risk someone will > update the size here but ... > > >> #ifdef CONFIG_ARM_32 >> /* >> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c >> index 45f3841..3d3b30c 100644 >> --- a/xen/arch/arm/setup.c >> +++ b/xen/arch/arm/setup.c >> @@ -20,6 +20,7 @@ >> #include <xen/compile.h> >> #include <xen/device_tree.h> >> #include <xen/domain_page.h> >> +#include <xen/grant_table.h> >> #include <xen/types.h> >> #include <xen/string.h> >> #include <xen/serial.h> >> @@ -693,6 +694,17 @@ void __init start_xen(unsigned long >> boot_phys_offset, >> struct domain *dom0; >> struct xen_domctl_createdomain dom0_cfg = { >> .max_evtchn_port = -1, >> + >> + /* >> + * The region used by Xen on the memory will never be mapped >> in DOM0 >> + * memory layout. Therefore it can be used for the grant table. >> + * >> + * Only use the text section as it's always present and will >> contain >> + * enough space for a large grant table >> + */ >> + .max_grant_frames = min_t(unsigned int, opt_max_grant_frames, >> + PFN_DOWN(_etext - _stext)), > > ... not here. So I would prefer if we either keep an helper to find > the size of pass that size around to domain_build. Do we store the > size in the domain information? I have to admit that I'm somewhat perplexed by ARM's find_gnttab_region(), and I'm not sure why it exists. The value is available from d->grant_table.max_grant_frames but ISTR finding that the order of construction meant that it wasn't available when needed (although this was all from code inspection, so I could very easily be wrong). ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |