[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/3] [not-for-unstable] xen/arm: vgic-v3: Delay the initialization of the domain information
Hi Andrew, On 09/04/2018 08:53 PM, Andrew Cooper wrote: On 04/09/18 20:35, Julien Grall wrote:Hi, On 09/04/2018 08:21 PM, Julien Grall wrote:A follow-up patch will require to know the number of vCPUs when initializating the vGICv3 domain structure. However this information is not available at domain creation. This is only known once XEN_DOMCTL_max_vpus is called for that domain. In order to get the max vCPUs around, delay the domain part of the vGIC v3 initialization until the first vCPU of the domain is initialized. Signed-off-by: Julien Grall <julien.grall@xxxxxxx> --- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> This is nasty but I can't find a better way for Xen 4.11 and older. This is not necessary for unstable as the number of vCPUs is known at domain creation. Andrew, I have CCed you to know whether you have a better idea where to place this call on Xen 4.11 and older.I just noticed that d->max_vcpus is initialized after arch_domain_create. So without this patch on Xen 4.12, it will not work. This is getting nastier because arch_domain_init is the one initialize the value returned by dom0_max_vcpus. So I am not entirely sure what to do here.The positioning after arch_domain_create() is unfortunate, but I couldn’t manage better with ARM's current behaviour and Jan's insistence that the allocation of d->vcpu was common. I'd prefer if the dependency could be broken and the allocation moved earlier. One option might be to have an arch_check_domainconfig() (or similar?) which is called very early on and can sanity check the values, including cross-checking the vgic and max_vcpus settings? It could even be responsible for mutating XEN_DOMCTL_CONFIG_GIC_NATIVE into the correct real value. I think it is doable without too much trouble on Arm. I can have a look at this for Xen 4.12 once this series is merged. As for your patch here, its a gross hack, but its probably the best which can be done. I have to admit that I'm surprised/concerned that Xen has lasted this long with such a fundamental gap in domain creation. I am surprised too. Hopefully your rework will make everything easier to use. Cheers, -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |