Re: [PATCH v9 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC
On 06/04/2022 14:44, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 01.04.2022 12:47, Jane Malalane wrote:
>> Introduce a new per-domain creation x86 specific flag to
>> select whether hardware assisted virtualization should be used for
>> x{2}APIC.
>>
>> A per-domain option is added to xl in order to select the usage of
>> x{2}APIC hardware assisted virtualization, as well as a global
>> configuration option.
>>
>> Having all APIC interaction exit to Xen for emulation is slow and can
>> induce much overhead. Hardware can speed up x{2}APIC by decoding the
>> APIC access and providing a VM exit with a more specific exit reason
>> than a regular EPT fault or by altogether avoiding a VM exit.
>>
>> On the other hand, being able to disable x{2}APIC hardware assisted
>> virtualization can be useful for testing and debugging purposes.
>>
>> Note:
>>
>> - vmx_install_vlapic_mapping doesn't require modifications regardless
>> of whether the guest has "Virtualize APIC accesses" enabled or not,
>> i.e., setting the APIC_ACCESS_ADDR VMCS field is fine so long as
>> virtualize_apic_accesses is supported by the CPU.
>>
>> - Both per-domain and global assisted_x{2}apic options are not part of
>> the migration stream, unless explicitly set in the configuration file,
>> so it is safe to migrate a guest that doesn't have assisted_x{2}apic
>> set in its config file between hosts that have different support for
>> hardware assisted x{2}APIC virtualization.
>
> While I can agree this is the case as far as your changes are concerned,
> it reads as if this was a broader statement. Since hypervisor CPUID leaf
> contents can change across such a migration (which is pre-existing
> behavior), I'm not convinced the statement is generally applicable.
I see, I will make this clearer to only reference the toolstack setting.
Thanks,
Jane.
Re: [PATCH v9 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC
On Fri, Apr 01, 2022 at 11:47:13AM +0100, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
>
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware assisted virtualization, as well as a global
> configuration option.
>
> Having all APIC interaction exit to Xen for emulation is slow and can
> induce much overhead. Hardware can speed up x{2}APIC by decoding the
> APIC access and providing a VM exit with a more specific exit reason
> than a regular EPT fault or by altogether avoiding a VM exit.
>
> On the other hand, being able to disable x{2}APIC hardware assisted
> virtualization can be useful for testing and debugging purposes.
>
> Note:
>
> - vmx_install_vlapic_mapping doesn't require modifications regardless
> of whether the guest has "Virtualize APIC accesses" enabled or not,
> i.e., setting the APIC_ACCESS_ADDR VMCS field is fine so long as
> virtualize_apic_accesses is supported by the CPU.
>
> - Both per-domain and global assisted_x{2}apic options are not part of
> the migration stream, unless explicitly set in the configuration file,
> so it is safe to migrate a guest that doesn't have assisted_x{2}apic
> set in its config file between hosts that have different support for
> hardware assisted x{2}APIC virtualization.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jane Malalane
Reviewed-by: Roger Pau Monné
Thanks, Roger.
Re: [PATCH v9 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC
On Fri, Apr 01, 2022 at 11:47:13AM +0100, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
>
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware assisted virtualization, as well as a global
> configuration option.
>
> Having all APIC interaction exit to Xen for emulation is slow and can
> induce much overhead. Hardware can speed up x{2}APIC by decoding the
> APIC access and providing a VM exit with a more specific exit reason
> than a regular EPT fault or by altogether avoiding a VM exit.
>
> On the other hand, being able to disable x{2}APIC hardware assisted
> virtualization can be useful for testing and debugging purposes.
>
> Note:
>
> - vmx_install_vlapic_mapping doesn't require modifications regardless
> of whether the guest has "Virtualize APIC accesses" enabled or not,
> i.e., setting the APIC_ACCESS_ADDR VMCS field is fine so long as
> virtualize_apic_accesses is supported by the CPU.
>
> - Both per-domain and global assisted_x{2}apic options are not part of
> the migration stream, unless explicitly set in the configuration file,
> so it is safe to migrate a guest that doesn't have assisted_x{2}apic
> set in its config file between hosts that have different support for
> hardware assisted x{2}APIC virtualization.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Jane Malalane
Reviewed-by: Anthony PERARD # tools
Thanks,
--
Anthony PERARD
Re: [PATCH v9 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC
On 01.04.2022 12:47, Jane Malalane wrote:
> Introduce a new per-domain creation x86 specific flag to
> select whether hardware assisted virtualization should be used for
> x{2}APIC.
>
> A per-domain option is added to xl in order to select the usage of
> x{2}APIC hardware assisted virtualization, as well as a global
> configuration option.
>
> Having all APIC interaction exit to Xen for emulation is slow and can
> induce much overhead. Hardware can speed up x{2}APIC by decoding the
> APIC access and providing a VM exit with a more specific exit reason
> than a regular EPT fault or by altogether avoiding a VM exit.
>
> On the other hand, being able to disable x{2}APIC hardware assisted
> virtualization can be useful for testing and debugging purposes.
>
> Note:
>
> - vmx_install_vlapic_mapping doesn't require modifications regardless
> of whether the guest has "Virtualize APIC accesses" enabled or not,
> i.e., setting the APIC_ACCESS_ADDR VMCS field is fine so long as
> virtualize_apic_accesses is supported by the CPU.
>
> - Both per-domain and global assisted_x{2}apic options are not part of
> the migration stream, unless explicitly set in the configuration file,
> so it is safe to migrate a guest that doesn't have assisted_x{2}apic
> set in its config file between hosts that have different support for
> hardware assisted x{2}APIC virtualization.
While I can agree this is the case as far as your changes are concerned,
it reads as if this was a broader statement. Since hypervisor CPUID leaf
contents can change across such a migration (which is pre-existing
behavior), I'm not convinced the statement is generally applicable.
> Suggested-by: Andrew Cooper
> Signed-off-by: Jane Malalane
Reviewed-by: Jan Beulich # hypervisor
Jan
