[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.