One question on xen_cpuid in pv guest

One question on xen_cpuid in pv guest

[Jiang, Yunhong]

I have a question to xen_cpuid() in pv_ops guest. Currently the cpuid will be trapped to xen HV for emulation. So why do we still use cpuid_leaf1_edx_mask/cpuid_leaf1_ecx_mask to do mask in guest side? Havn't that been achieved in hypervisor already?

Thanks
Yunhong Jiang

Re: One question on xen_cpuid in pv guest

[Jeremy Fitzhardinge]

On 07/28/09 20:19, Jiang, Yunhong wrote:
> I have a question to xen_cpuid() in pv_ops guest. Currently the cpuid will be trapped to xen HV for emulation. So why do we still use cpuid_leaf1_edx_mask/cpuid_leaf1_ecx_mask to do mask in guest side? Havn't that been achieved in hypervisor already?
>   

Not entirely, or consistently.  In general Xen masks features which are
outright forbidden for the guest to use, but leaves things that might
possibly be useful - we still need to mask those out.  It also fails to
mask some newer features which are not usable in guests (like GByte
pages and XSAVE), so we need to mask those anyway.  For domU, the set of
mask flags is under the control of the domain config file; a
misconfiguration could enable flags that the kernel can simply not use.

    J

RE: One question on xen_cpuid in pv guest

[Jiang, Yunhong]

Jeremy, thanks for clarification, but I still not sure about following code in pv_ops dom0. Since the Local APIC is owned by Xen totally, why is it not "outright forbidden for the guest"?


    if (!xen_initial_domain())
        cpuid_leaf1_edx_mask &=
            ~((1 << X86_FEATURE_APIC) |  /* disable local APIC */
              (1 << X86_FEATURE_ACPI));  /* disable ACPI */

Thanks
Yunhong Jiang

Jeremy Fitzhardinge wrote:
> On 07/28/09 20:19, Jiang, Yunhong wrote:
>> I have a question to xen_cpuid() in pv_ops guest. Currently
> the cpuid will be trapped to xen HV for emulation. So why do
> we still use cpuid_leaf1_edx_mask/cpuid_leaf1_ecx_mask to do
> mask in guest side? Havn't that been achieved in hypervisor already?
>> 
> 
> Not entirely, or consistently.  In general Xen masks features which
> are outright forbidden for the guest to use, but leaves things that
> might possibly be useful - we still need to mask those out.  It also
> fails to mask some newer features which are not usable in guests
> (like GByte pages and XSAVE), so we need to mask those anyway.  For
> domU, 
> the set of
> mask flags is under the control of the domain config file; a
> misconfiguration could enable flags that the kernel can simply not
> use. 
> 
>    J

Re: One question on xen_cpuid in pv guest

[Jeremy Fitzhardinge]

On 07/29/09 22:44, Jiang, Yunhong wrote:
> Jeremy, thanks for clarification, but I still not sure about following code in pv_ops dom0. Since the Local APIC is owned by Xen totally, why is it not "outright forbidden for the guest"?
>
>
>     if (!xen_initial_domain())
>         cpuid_leaf1_edx_mask &=
>             ~((1 << X86_FEATURE_APIC) |  /* disable local APIC */
>               (1 << X86_FEATURE_ACPI));  /* disable ACPI */
>   

Some of the approaches to implementing dom0 pretend the local APIC
exists in order to fool various code-paths into doing the right thing
(for example, getting the kernel to parse all the MADT tables, which it
won't do if there's no local APIC).

Historically I think the policy has been for Xen to explicitly blacklist
features which turn out to be problematic when they become problematic,
rather than whitelist features known to be safe.

    J