[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 08/12] xen/x86: setup PVHv2 Dom0 CPUs



>>> On 29.07.16 at 18:29, <roger.pau@xxxxxxxxxx> wrote:
> Initialize Dom0 BSP/APs and setup the memory and IO permissions.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> ---
> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> The logic used to setup the CPUID leaves is extremely simplistic (and
> probably wrong for hardware different than mine). I'm not sure what's the
> best way to deal with this, the code that currently sets the CPUID leaves
> for HVM guests lives in libxc, maybe moving it xen/common would be better?

Why don't you just set them from their respective hardware values?

> +static int __init hvm_setup_cpus(struct domain *d, paddr_t entry,
> +                                 paddr_t start_info)
> +{
> +    vcpu_hvm_context_t cpu_ctx;
> +    struct vcpu *v = d->vcpu[0];
> +    int cpu, i, rc;
> +    struct {
> +        uint32_t index;
> +        uint32_t count;
> +    } cpuid_leaves[] = {
> +        {0, XEN_CPUID_INPUT_UNUSED},
> +        {1, XEN_CPUID_INPUT_UNUSED},
> +        {2, XEN_CPUID_INPUT_UNUSED},
> +        {4, 0},
> +        {4, 1},
> +        {4, 2},
> +        {4, 3},
> +        {4, 4},
> +        {7, 0},
> +        {0xa, XEN_CPUID_INPUT_UNUSED},
> +        {0xd, 0},
> +        {0x80000000, XEN_CPUID_INPUT_UNUSED},
> +        {0x80000001, XEN_CPUID_INPUT_UNUSED},
> +        {0x80000002, XEN_CPUID_INPUT_UNUSED},
> +        {0x80000003, XEN_CPUID_INPUT_UNUSED},
> +        {0x80000004, XEN_CPUID_INPUT_UNUSED},
> +        {0x80000005, XEN_CPUID_INPUT_UNUSED},
> +        {0x80000006, XEN_CPUID_INPUT_UNUSED},
> +        {0x80000007, XEN_CPUID_INPUT_UNUSED},
> +        {0x80000008, XEN_CPUID_INPUT_UNUSED},
> +    };
> +
> +    printk("** Setting up BSP/APs **\n");
> +
> +    cpu = v->processor;
> +    for ( i = 1; i < d->max_vcpus; i++ )
> +    {
> +        cpu = cpumask_cycle(cpu, &dom0_cpus);
> +        setup_dom0_vcpu(d, i, cpu);
> +    }
> +
> +    memset(&cpu_ctx, 0, sizeof(cpu_ctx));
> +
> +    cpu_ctx.mode = VCPU_HVM_MODE_32B;
> +
> +    cpu_ctx.cpu_regs.x86_32.ebx = start_info;
> +    cpu_ctx.cpu_regs.x86_32.eip = entry;
> +    cpu_ctx.cpu_regs.x86_32.cr0 = X86_CR0_PE | X86_CR0_ET;
> +
> +    cpu_ctx.cpu_regs.x86_32.cs_limit = ~0u;
> +    cpu_ctx.cpu_regs.x86_32.ds_limit = ~0u;
> +    cpu_ctx.cpu_regs.x86_32.ss_limit = ~0u;
> +    cpu_ctx.cpu_regs.x86_32.tr_limit = 0x67;
> +    cpu_ctx.cpu_regs.x86_32.cs_ar = 0xc9b;
> +    cpu_ctx.cpu_regs.x86_32.ds_ar = 0xc93;
> +    cpu_ctx.cpu_regs.x86_32.ss_ar = 0xc93;
> +    cpu_ctx.cpu_regs.x86_32.tr_ar = 0x8b;

Much of this should be power on state of a HVM vCPU anyway, so
it's not immediately clear why all of this is needed.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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