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

Re: [PATCH 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Jane Malalane <Jane.Malalane@xxxxxxxxxx>
  • Date: Tue, 8 Feb 2022 13:27:33 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Y3vyjGmOZne3/GeAe6z9lN/7bVMLGOOhguo1PRsgLmA=; b=WQrqUrCFpW/w9Fhy+h+Mvh9sRaN+iDCxsO1+YtOgqaGFRUDDX3+Mr99kWvXXWDmNg7j+Mbu1muK56CbRWsckCRXQ9/8sC+MGej1knyk4X5Bq8yt4rlBAwVTMQKtizqqjRw7HxgaM8Xm0zUMcpKvcQBfWT9SZm942/n9PsMDVvux8S3yO0KhtFdFENMyX7STB1J0GEMBkL6dS72Jm99YUHCllkGJRApY7sWneJHzvA/uOrNwpCLWmn/0zSVRCRymhIP/wL927Hr94iGriYkKDIlZNu4Q8mNnYkKcUbXlAHYdiJxohat7rxJl/YuOX2E0rIIcYuIUMzJrqrWCYZ6448A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J9o+HWAsIEbk0hkt8LjJHrOxC0/w5L8oUwiEnN7Uj3TbAeG1Qmwsb56XnlvoTipJUUMaV7b6F7VmASgH+2g38u45z1N9H5x6brIKJ6g0Nzf0+ZF1/YEJhIiuFQXWTHd7coWDk29XWK9JLmsgW0kLXuPNTzku2oc5+q2jsqIt1dh27DfWwdJKaNLvMpxs05LTqLIwZzXmx6jv/hyLUcGhrw2Q+D1x0XcX23vj7K1qCh8CHSUfvrwZPPar/w+EKUqPXMH31d8fPusyeLTVQFLg9ZFCs00m5k5NGLRzq7rUM+9Mh237MbkkHCWt/TNXbLGclH6Rl3eC5ioP9a8RKWn1nA==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Wei Liu <wl@xxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, "Juergen Gross" <jgross@xxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, "George Dunlap" <George.Dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, "Stefano Stabellini" <sstabellini@xxxxxxxxxx>, Christian Lindig <christian.lindig@xxxxxxxxxx>, David Scott <dave@xxxxxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 08 Feb 2022 13:27:59 +0000
  • Ironport-data: A9a23:kamsBKBHQasiMRVW/23lw5YqxClBgxIJ4kV8jS/XYbTApDMjgWRWz jcaW23TOPiLMTSkc49waYix80IE756DnIcwQQY4rX1jcSlH+JHPbTi7wuYcHM8wwunrFh8PA xA2M4GYRCwMo/u1Si6FatANl1ElvU2zbue6WL6s1hxZH1c+En970UI7wobVv6Yz6TSHK1LV0 T/Ni5W31G+Ng1aY5UpNtspvADs21BjDkGtwUm4WPJinj3eH/5UhN7oNJLnZEpfNatI88thW5 Qr05OrREmvxp3/BAz4++1rxWhVirrX6ZWBihpfKMkQLb9crSiEai84G2PQghUh/tDuisMAr0 /R3qL/vWwsvHZLPvto7TEwNe81+FfUuFL7vJHG+tYqYzlHccmuqyPJrZK00FdRGoKAtWzgIr KFGbmBWBvyAr7veLLaTaOBqi4IGJc3iOIoZt1lrzC3DDOZgSpfGK0nPzYEFjWts3pkRdRrYT 41ENShWQE7wWBpkOnYMK7Uup+KygXaqJlW0r3rK/PFqsgA/1jdZ3LHzPfLPd9eNRMETmVyXz krd5HjwCBweMN2ZyBKG/2iqi+uJmjn0MKoCGbv9+vN0jVm7wm0IFAZQRVa9ueO+iEO1R5RYM UN80hQpqa8+5Um6VO7XVhezoGOHlhMEUt8WGOo/gCmSzoLE7gDfAXILJhZDYtE7sM49RRQxy 0SE2djuAFRHsqCRSH+b3qeZq3W1Iyd9BW0NfygfViMe/sLu5oo0i3ryos1LSfDvyIevQHepn m7M/HNWa6gvYdAj6KuQ0kCdmBOWu7uWXAIzxTrUeFyD8VYsDGK6XLCA5V/e5PdGCY+WSFido XQJ8/SjAPAy4YKlz3LUHrhUdF29z7PcaWCH3wYzd3U032n1oxaekZZsDCaSzauDGuINYnfXb UDaomu9D7cDbSLxPcebj29cYvnGLJQM9/y4DJg4jfIUO/CdkTNrGwk0NCatM5jFyhRErE3GE c7znTyQJXgbE7976zG9Wv0Q17Qmrghnmz+PHMGilkr2i+PFDJJwdVviGAHfBt3VEYve+FmFm zqhH5fiJ+pjvB3WPXCMrN97waEiJnknH5Hmw/G7hcbYSjeK7FoJUqeLqZt4ItQNt/0Myo/go yHsMmcFmQGXrSCWdm2iNCs5AJuxBskXkJ7OFXF1Vbpe8yN4OtjHAWZ2X8ZfQITLA8Q5laEtF KReK5zbahmNIxyekwkggVDGhNUKXDyghB6UPjrjZz46fpV6QBfO9MOidQzqnBTixALt3Sfni 7H/hA7dX7QZQAFuUJTfZP61lgvjtnkBguNiGUDPJ4ALKknr9YFrLQ33j+M2fJ5QeUmSmGPC2 lbEGwocqMnMv5QxrIvDi5ebotr7COB5BEdbQTXWtO7kKSnA82O/6oZcS+LULyvFXWb59fz6N +VYxv3xKtMdm1NOv9YuGrpn1/tmtdDuu6Vb3kJvG3CSNwanDbZpI3+n28hTt/ISmu8F6FXuA k/Wo4tUI7SEPs/hAWU9Hgt9Y7TRz+wQlxnT8e8xfBfw6hho8efVSk5VJRSN1nBQdeMnLIM/z O49k8cK8Ajj2AEyO9OLgy0IpWSBKnsMD/cuup0AWdK5jwMqzhdJYIDGCz+w65aKMo0ePk4vK z6SpazDm7UDmRaSLyttTSDAjbhHmJADmBFW11tTdV2Gl+3MiuIzwBAMoy88SR5Yz0kf3u9+U oSx25aZ+UlaE+9UufV+
  • Ironport-hdrordr: A9a23:ipsCPKwmkk6V3KwCBDXfKrPxgeskLtp133Aq2lEZdPULSKOlfp GV8MjziyWYtN9IYgBcpTiBUJPwJE81bfZOkMYs1MSZLXXbUQyTXc9fBOrZsnHd8kjFmNK1up 0QCpSWZOeAbmSSyPyKmjVQcOxQgeVvkprY/ds2pk0FJWoBCsFdBkVCe32m+yVNNVJ77PECZf 6hD7981lydkAMsH6OG7xc+Lor+juyOsKijTQ8NBhYh5gXLpyiv8qTGHx+R2Qpbey9TwJ85mF K10zDR1+GGibWW2xXc32jc49B9g9360OZOA8SKl4w8NijssAC1f45sMofy/wzd4dvfqmrCou O85yvIDP4DrE85uVvF5ycF7jOQlQrGLUWSkGNwz0GT+fARDwhKdPapzbgpDCcxrXBQ5u2UmZ g7rl6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOLFuI4O5gLZvtX+9Kq1wVB4SKbpXZd VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06GlODTlIZssKY3jBKlDQhpnFoifA3jzMF7tYwWpNE7+ PLPuBhk6xPVNYfaeZ4CP0aScW6B2TRSVbHMX6UI17gCKYbUki94aLf8fEw/qWnaZYIxJw9lN DIV05Zr3c7fwb0BciHzPRwg2bwqaWGLEPQI+1llutEU4zHNc7W2He4OSATeuOb0ociPvE=
  • Ironport-sdr: 4lE400Ip5bVwgrbuvD9CpygLmbBZWmg1SZ5pveTHLEamln4hSMQPDPzFKw2KzVyLo3i8Fdlpjp D9SmfjQL9EuB/6W3kKgpeiWLZYsqpX1onpHQfxM4QQ6O5DUIDvQ+Fw5ufBHnLXvAsTdKdNzWAX WjWvpbjmAhL0qDSdyVU9pZJXWEAUdTauI798p8ErgvV9++znpk5SsrItoaLzEDQ8ywANh/Bfun N7HH/l5oUdzx3cogriUXNcU6k9+vXPROwgPmxfOU/o3nKgDO9HyzfdddAVS1FcwwdZ68BFpJ9b vNl7/OQeqg1o8/XK8n7KjSQK
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYE5eVWWLwfSz8JEi35sISHqV9YKx9DnUAgAypmgA=
  • Thread-topic: [PATCH 2/2] x86/xen: Allow per-domain usage of hardware virtualized APIC

On 31/01/2022 12:05, Jan Beulich wrote:
> On 27.01.2022 17:01, 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 vitualization, 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 running APIC
>> read/write accesses without taking a VM exit.
> 
> This is odd to read for a patch which makes it possible to _turn off_
> acceleration. Instead it would be interesting to know what problems
> you have encountered making it desirable to have a way to turn this off.

Hi Jan,

After speaking to Andrew he told me of a performance regression that was 
reported some time ago when enabling apicv related to the pass-through 
LAPIC timer of a HVM guest causing Xen to intercept the LAPIC timer MSR, 
making anything that uses the LAPIC timer end up slower than it was 
before. So, adressing your comment here, other than mentioning how being 
able to disable acceleration for apicv can be useful when testing and 
debugging, do you think it's worth mentioning (in more detail) that this 
perf problem exists, in the commit message.

Thanks,

Jane.

> 
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -3342,16 +3342,19 @@ static void vmx_install_vlapic_mapping(struct vcpu 
>> *v)
>>   
>>   void vmx_vlapic_msr_changed(struct vcpu *v)
>>   {
>> -    int virtualize_x2apic_mode;
>> +    int virtualize_xapic_mode, virtualize_x2apic_mode;
> 
> Please switch to bool as you touch and extend this.
> 
>>       struct vlapic *vlapic = vcpu_vlapic(v);
>>       unsigned int msr;
>>   
>> +    virtualize_xapic_mode = ( cpu_has_vmx_virtualize_apic_accesses &&
>> +                              v->domain->arch.hvm.assisted_xapic );
> 
> Please don't clone the bad use of blanks immediately inside parentheses
> here; instead, ...
> 
>>       virtualize_x2apic_mode = ( (cpu_has_vmx_apic_reg_virt ||
>>                                   cpu_has_vmx_virtual_intr_delivery) &&
>> -                               cpu_has_vmx_virtualize_x2apic_mode );
>> +                               cpu_has_vmx_virtualize_x2apic_mode &&
>> +                               v->domain->arch.hvm.assisted_x2apic );
> 
> ... since you're touching this anyway, please consider correcting
> the style violation here.
> 
> However - do you need these expressions anymore? The per-domain fields
> can only be set if the respective CPU capabilities exit.
> 
>> --- a/xen/arch/x86/include/asm/hvm/domain.h
>> +++ b/xen/arch/x86/include/asm/hvm/domain.h
>> @@ -117,6 +117,12 @@ struct hvm_domain {
>>   
>>       bool                   is_s3_suspended;
>>   
>> +    /* xAPIC hardware assisted emulation. */
>> +    bool assisted_xapic;
>> +
>> +    /* x2APIC hardware assisted emulation. */
>> +    bool assisted_x2apic;
>> +
>>       /* hypervisor intercepted msix table */
>>       struct list_head       msixtbl_list;
> 
> Please follow how adjacent code pads types / names here.
> 
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -1115,7 +1115,8 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
>> uint32_t leaf,
>>           if ( !is_hvm_domain(d) || subleaf != 0 )
>>               break;
>>   
>> -        if ( cpu_has_vmx_apic_reg_virt )
>> +        if ( cpu_has_vmx_apic_reg_virt &&
>> +             v->domain->arch.hvm.assisted_xapic )
>>               res->a |= XEN_HVM_CPUID_APIC_ACCESS_VIRT;
>>   
>>           /*
>> @@ -1126,7 +1127,8 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
>> uint32_t leaf,
>>            */
>>           if ( cpu_has_vmx_virtualize_x2apic_mode &&
>>                cpu_has_vmx_apic_reg_virt &&
>> -             cpu_has_vmx_virtual_intr_delivery )
>> +             cpu_has_vmx_virtual_intr_delivery &&
>> +             v->domain->arch.hvm.assisted_x2apic )
>>               res->a |= XEN_HVM_CPUID_X2APIC_VIRT;
> 
> Same remark as above - can't you now use _just_ the per-domain field?
> In this latter of the two cases this would then also mean bringing
> the CPU feature checks in line with what vmx_vlapic_msr_changed()
> does (as also pointed out for patch 1). Albeit it might be best to
> have a prereq patch fixing the issue, which could then be backported.
> 
> Jan
> 
> 

 


Rackspace

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