[PATCH] xen: disable reporting hw virtualized lapic availability on PVH guests

[PATCH] xen: disable reporting hw virtualized lapic availability on PVH guests

[Roger Pau Monne]

Even if the hardware reports support for virtualized lapic, it should
not be exposed to PVH guests, since they don't have a lapic at all.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
---
 xen/arch/x86/hvm/vmx/vmx.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index d45fb7f..ecc010e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1660,7 +1660,7 @@ void vmx_hypervisor_cpuid_leaf(uint32_t sub_idx,
                                uint32_t *eax, uint32_t *ebx,
                                uint32_t *ecx, uint32_t *edx)
 {
-    if ( sub_idx != 0 )
+    if ( sub_idx != 0 || is_pvh_vcpu(current) )
         return;
     if ( cpu_has_vmx_apic_reg_virt )
         *eax |= XEN_HVM_CPUID_APIC_ACCESS_VIRT;
-- 
1.7.7.5 (Apple Git-26)


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

Re: [PATCH] xen: disable reporting hw virtualized lapic availability on PVH guests

[Jan Beulich]

>>> On 04.06.14 at 12:12, <roger.pau@citrix.com> wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1660,7 +1660,7 @@ void vmx_hypervisor_cpuid_leaf(uint32_t sub_idx,
>                                 uint32_t *eax, uint32_t *ebx,
>                                 uint32_t *ecx, uint32_t *edx)
>  {
> -    if ( sub_idx != 0 )
> +    if ( sub_idx != 0 || is_pvh_vcpu(current) )
>          return;
>      if ( cpu_has_vmx_apic_reg_virt )

The addition would belong on this line imo (in the && !is_pvh form).

Jan

Re: [PATCH] xen: disable reporting hw virtualized lapic availability on PVH guests

[Roger Pau Monné]

On 04/06/14 12:45, Jan Beulich wrote:
>>>> On 04.06.14 at 12:12, <roger.pau@citrix.com> wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1660,7 +1660,7 @@ void vmx_hypervisor_cpuid_leaf(uint32_t sub_idx,
>>                                 uint32_t *eax, uint32_t *ebx,
>>                                 uint32_t *ecx, uint32_t *edx)
>>  {
>> -    if ( sub_idx != 0 )
>> +    if ( sub_idx != 0 || is_pvh_vcpu(current) )
>>          return;
>>      if ( cpu_has_vmx_apic_reg_virt )
> 
> The addition would belong on this line imo (in the && !is_pvh form).

Then I would also have to add another is_pvh gate on the next if:

    if ( cpu_has_vmx_virtualize_x2apic_mode && cpu_has_vmx_apic_reg_virt &&
         cpu_has_vmx_virtual_intr_delivery && !is_pvh_vcpu(current) )
        *eax |= XEN_HVM_CPUID_X2APIC_VIRT;

IMHO it seems easier to gate it on the first if and just
return, although I understand it is more correct to gate
it on a feature by feature basis.

Roger.

Re: [PATCH] xen: disable reporting hw virtualized lapic availability on PVH guests

[Jan Beulich]

>>> On 04.06.14 at 12:53, <roger.pau@citrix.com> wrote:
> On 04/06/14 12:45, Jan Beulich wrote:
>>>>> On 04.06.14 at 12:12, <roger.pau@citrix.com> wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -1660,7 +1660,7 @@ void vmx_hypervisor_cpuid_leaf(uint32_t sub_idx,
>>>                                 uint32_t *eax, uint32_t *ebx,
>>>                                 uint32_t *ecx, uint32_t *edx)
>>>  {
>>> -    if ( sub_idx != 0 )
>>> +    if ( sub_idx != 0 || is_pvh_vcpu(current) )
>>>          return;
>>>      if ( cpu_has_vmx_apic_reg_virt )
>> 
>> The addition would belong on this line imo (in the && !is_pvh form).
> 
> Then I would also have to add another is_pvh gate on the next if:
> 
>     if ( cpu_has_vmx_virtualize_x2apic_mode && cpu_has_vmx_apic_reg_virt &&
>          cpu_has_vmx_virtual_intr_delivery && !is_pvh_vcpu(current) )
>         *eax |= XEN_HVM_CPUID_X2APIC_VIRT;
> 
> IMHO it seems easier to gate it on the first if and just
> return, although I understand it is more correct to gate
> it on a feature by feature basis.

Right, also to avoid unnecessary future code churn.

Jan