On 22.08.2022 23:30, Andrew Cooper wrote:
> arch_domain_create() can't blindly write into d->arch.hvm union. Move the
> logic into hvm_domain_initialise(), which involves passing config down.
>
> Fixes: 2ce11ce249a3 ("x86/HVM: allow per-domain usage of hardware virtualized
> APIC")
> Signed-off-by: Andrew Cooper <[email protected]>
Reviewed-by: Jan Beulich <[email protected]>
preferably with a small adjustment (see below).
> This does not fix XenServer's wall of red from testing, but I have at least
> figured out what's going on. There's a piece of plain RAM in place of a
> working LAPIC MMIO mapping (accelerated or otherwise), which causes HVMLoader
> to spin in a tight loop waiting for CPU 1 to come up after failing to send an
> INIT-SIPI-SIPI.
Where's that page of plain RAM coming from? And do you meanwhile
understand why XenServer testing is exposing the issue while osstest
isn't?
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -576,7 +576,8 @@ static int cf_check hvm_print_line(
> return X86EMUL_OKAY;
> }
>
> -int hvm_domain_initialise(struct domain *d)
> +int hvm_domain_initialise(struct domain *d,
> + struct xen_domctl_createdomain *config)
May I ask for const to be added here? Unless you anticipate the
function might legitimately modify the config data?
Jan
