[Xen-devel] [xen-unstable test] 104004: tolerable FAIL

[osstest service owner]

flight 104004 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104004/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   6 xen-boot   fail pass in 104003
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail pass in 104003

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104003
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104003
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104003
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104003
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104003
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104003
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104003
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104003
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104003
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 104003

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 104003 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 104003 never 
pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ee524f2bfa681ad116b8ae925fa8f3f18ee12ba5
baseline version:
 xen  ee524f2bfa681ad116b8ae925fa8f3f18ee12ba5

Last test of basis   104004  2017-01-03 01:59:38 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17169 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  

Re: [Xen-devel] [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

[Jan Beulich]

>>> On 22.12.16 at 19:19,  wrote:
> On 12/22/2016 11:44 AM, Roger Pau Monne wrote:
>> On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
>> On 22.12.16 at 17:17,  wrote:
 On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
 Why would Xen need to be able to parse the AML that is intended to be
 executed by dom0? I'd think that all the hypervisor would need to do is
 to load it into memory, not any different from how it's done for regular
 guests.
>>> Well, if Dom0 executed the unmodified _MAT, it would get back
>>> data relating to the physical CPU. Roger is overriding MADT to
>>> present virtual CPU information to Dom0, and this would likewise
>>> need to happen for the _MAT return value.
> 
> By "unmodified _MAT" you mean system's _MAT?  Why can't we provide our
> own that will return _MAT object properly adjusted for dom0? We are
> going to provide our own (i.e. not system's) DSDT, aren't we?

For Dom0? No, I didn't think so. We can't reasonably edit the host's,
and we also can't craft our own (that works only for DomU).

Jan


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

Re: [Xen-devel] [PATCH v2 1/5] Remove hardcoded strict -Werror checking

[Jan Beulich]

>>> On 29.12.16 at 18:30,  wrote:
> On 29/12/2016 17:10, George Dunlap wrote:
>> On Tue, Dec 27, 2016 at 5:07 PM, Andrew Cooper
>>  wrote:
>>> On 27/12/16 15:53, Jan Beulich wrote:
>>> "Jan Beulich"  12/27/16 4:42 PM >>>
>>> Alistair Francis  12/22/16 8:14 PM >>>
>> Everyone seems fairly open to an override. Is a environment variable,
>> which if set will disable Werror acceptable? Something like NO_ERROR=Y
>> which will result in no -Werror being appended.
> I dislike environment variables for such purposes, and would prefer
> requiring
> such to be added as make options. If it was an environment variable, it
> should start with XEN_. And its name should fully reflect the purpose,
> i.e. I
> shouldn't have to guess what kinds of errors would be suppressed. Perhaps
> WARN_NO_ERROR?
 That said, I'm not sure everyone agreed on putting an override in place. I
 think
 Andrew had made it quite clear that there is a reason for -Werror to be in
 use,
 and we shouldn't encourage people weakening code by tolerating warnings
 (even if for the purpose of upstream integration no warnings will be
 permitted
 anyway, due to -Werror remaining the default).
>>>
>>> For development, -Werror should remain the default.
>>>
>>> For downstream integration, an ability to override -Werror is useful for
>>> distros, especially in cases of using a newer compiler than the code was
>>> ever developed against.
>>>
>>> However, it should definitely be the case that a positive choice needs to be
>>> taken to disable -Werror, which should hopefully make people thing twice
>>> about doing so.
>> Wouldn't it make more sense to disable -Werror for the release?
> 
> -1.  This is not a sensible suggestion IMO.
> 
> The reason for switching off debugging for a release is because there is
> a runtime overhead of the debugging, and we don't provide security
> support in case the ASSERT()s are a little too aggressive.
> 
> The reason behind using -Werror doesn't change at the point of a
> release.  A warning on a release branch is just as important to fix as a
> warning on master.

The more that, with changed optimization settings, warnings
occasionally change too (potentially pointing out so far overlooked
issues). If _all_ our downstreams participated in at least RC testing,
the whole situation might be a little different, but without that I
think we should rather hope for them to report issues with compiler
versions no-one of us tried to build with.

Jan


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

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

[Jan Beulich]

>>> On 23.12.16 at 13:24,  wrote:
> On December 22, 2016 4:12 PM, Jan Beulich wrote:
> On 21.12.16 at 06:44,  wrote:
>>> --- a/xen/arch/x86/hvm/vmx/intr.c
>>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>>> @@ -315,9 +315,13 @@ void vmx_intr_assist(void)
>>>  * Set eoi_exit_bitmap for periodic timer interrup to cause
>>EOI-induced VM
>>>  * exit, then pending periodic time interrups have the chance
>>to be injected
>>>  * for compensation
>>> +* Set eoi_exit_bitmap for intack.vector when it's higher than
>>pending
>>> +* periodic time interrupts. This way we can guarantee there's
>>always a chance
>>> +* to post periodic time interrupts when periodic time
>>interrupts becomes the
>>> +* highest one
>>>  */
>>>  if (pt_vector != -1)
>>> -vmx_set_eoi_exit_bitmap(v, pt_vector);
>>> +vmx_set_eoi_exit_bitmap(v, intack.vector);
>>
>>The comment does not clarify why max(pt_vector, intack.vector) is not
>>needed. And I'd expect you to add ASSERT(intack.vector >= pt_vector) then,
>>to prove this (and one might argue that this addition could be sufficient
>>documentation, albeit perhaps a brief comment next to the assertion
>>would help readers of this non-trivial piece of code).
>>
> Kevin or Jan..
> ASSERT(...) is ok to me.. Could you help me give a brief comment? 

I don't see why you couldn't simply use what Kevin said in reply
to my earlier question regarding the lack of max() here.

Jan


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

[Xen-devel] [libvirt test] 104005: tolerable all pass - PUSHED

[osstest service owner]

flight 104005 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104005/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 103915
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 103915
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 103915
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 103915

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  0735ddf744f95cd9f88c5f8465b1a64883710d37
baseline version:
 libvirt  866641d4c5706413393913fdb3bb1cd077683d21

Last test of basis   103915  2016-12-25 04:19:51 Z9 days
Testing same since   104005  2017-01-03 04:20:30 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Michal Privoznik 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=0735ddf744f95cd9f88c5f8465b1a64883710d37
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w 

Re: [Xen-devel] AMD VMMCALL and VM86 mode

[Andrew Cooper]

On 25/12/2016 07:47, Suravee Suthikulpanit wrote:
>
>
> On 12/12/16 01:37, Andrew Cooper wrote:
>> On 11/12/16 17:33, Boris Ostrovsky wrote:
>>> - andrew.coop...@citrix.com wrote:
>>>
 On 09/12/16 19:55, Andrew Cooper wrote:
> On 09/12/16 19:55, Boris Ostrovsky wrote:
>> On 12/09/2016 02:01 PM, Andrew Cooper wrote:
>>> Hello,
>>>
>>> While working on XSA-192, I found a curious thing.  On AMD
 hardware, the
>>> VMMCALL instruction appears to behave like a nop if executed in
 VM86
>>> mode.  All other processor modes work fine.
>>>
>>> The documentation suggests it should be valid in any situation,
 but I
>>> never get a #VMEXIT from it.
>> And I assume GENERAL2_INTERCEPT_VMMCALL is set (which is what we
 have in
>> Xen by default)?
> Yes, because I have already used hypercalls to get text to the
 console
> before entering vm86 mode.
>
>> What happens if you don't set it?
> Let me do some hacking and see.
 Outside of vm86 mode, VMMCALL raises #UD, which is expected as it
 wasn't
 intercepted.

 From within vm86 mode, I now get #GP rather than #UD.

 There is certainly an argument to be made that VMMCALL inside vm86
 mode
 should trap to the vm86 monitor and #GP would be the expected way of
 that happening, but this also doesn't match the documentation.
>>>
>>> Just curious: why do you think #GP could be a reasonable exception
>>> here?
>>
>> In vm86 mode, #GP is raised for privileged instructions which should
>> break for auditing in the vm86 monitor.  It would be reasonable to
>> include "talking to the hypervisor" as a privileged action.
>>
>>> It's #UD because if not intercepted it doesn't make sense to execute
>>> it.
>>
>> I agree with this, if privilege isn't considered an issue.  If a
>> hypervisor doesn't actually get involved, the instruction shouldn't
>> complete.
>>
>>> But either way, I think AMD should clarify this. Suravee, can you
>>> find out what the expected behavior is?
>>
>> IMO, it should either consistently #GP and break to the vm86 monitor, or
>> #UD/#VMEXIT depending on whether it is intercepted by the hypervisor.
>> Either way the documentation should be clarified.
>>
>> Having said this, given that its behaviour is consistent on any AMD
>> processor I choose to try, and given that vm86 mode is very legacy these
>> days, I doubt a reasonable argument can be made to fixing the behaviour.
>>
>> ~Andrew
>>
>

Appologies for the delays replying.  To answer your questions out of
order...

> What processors are you using to reproduce this behavior?

I am still out of the office until tomorrow, so haven't been able to do
more thorough testing.

I am observing expected behaviour on:

(XEN) CPU Vendor: AMD, Family 16 (0x10), Model 2 (0x2), Stepping 3 (raw
00100f23)

And observing incorrect behaviour on:

(XEN) CPU Vendor: AMD, Family 21 (0x15), Model 96 (0x60), Stepping 1
(raw 00660f01)

I note from your AVIC series that this machine should be capable, but it
it is an SDP running with microcode version 0x600610b which (now I think
about it) could easily be the source of this issue.

> So, just to confirm your observation. When executing VMMCALL in vm86
> mode with the hypervisor is set to intercept VMMCALL and not-intercept
> VMMCALL, you are seeing #GP in both cases or just in the later?

Seeing #GP when not intercepted, and a something resembling a nop when
intercepted.

> According to the HW folks, in the vm86 mode, we should observe the
> same behavior as in protected mode. (e.g. #UD in guest if not
> intercept VMMCALL, and #vmexit if intercept)

Having checked on the one other processor I have easy external access
to, this does indeed appear to be the case for Fam 0x10 processors.

> Could you please describe how you are reproducing this behavior?

I have a short XTF test which demonstrates the issue, but it would
probably be better to rule out SDP/microcode issues first.  I can find a
BKDG for Fam 15h, Model 60h-6fh processors, but not a revision guide. 
Where can I find and get the latest microcode?

Thanks,

~Andrew

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

Re: [Xen-devel] [PATCH v2 09/10] x86/SVM: Hook up miscellaneous AVIC functions

[Andrew Cooper]

On 31/12/2016 05:46, Suravee Suthikulpanit wrote:
> Hook up virtual_intr_delivery_enabled and deliver_posted_intr functions
> when AVIC is enabled.
>
> Signed-off-by: Suravee Suthikulpanit 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Jan Beulich 
> Cc: Boris Ostrovsky 
> ---
>  xen/arch/x86/hvm/svm/svm.c | 26 +-
>  xen/include/asm-x86/hvm/svm/avic.h |  3 +++
>  2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index 922f48f..7c0cda0 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1438,6 +1438,11 @@ static int svm_cpu_up(void)
>  return 0;
>  }
>  
> +static inline int svm_avic_enabled(void)
> +{
> +return svm_avic;
> +}
> +
>  const struct hvm_function_table * __init start_svm(void)
>  {
>  bool_t printed = 0;
> @@ -1472,16 +1477,27 @@ const struct hvm_function_table * __init 
> start_svm(void)
>  P(cpu_has_svm_decode, "DecodeAssists");
>  P(cpu_has_pause_filter, "Pause-Intercept Filter");
>  P(cpu_has_tsc_ratio, "TSC Rate MSR");
> -P(cpu_has_svm_avic, "AVIC");
> -#undef P
> -
> -if ( !printed )
> -printk(" - none\n");
>  
>  svm_function_table.hap_supported = !!cpu_has_svm_npt;
>  svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
>  ((cpuid_edx(0x8001) & 0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0);
>  
> +if ( !cpu_has_svm_avic )
> +svm_avic = 0;
> +
> +if ( svm_avic )
> +{
> +svm_function_table.deliver_posted_intr  = 
> svm_avic_deliver_posted_intr;
> +svm_function_table.virtual_intr_delivery_enabled = svm_avic_enabled;
> +P(cpu_has_svm_avic, "AVIC (enabled)");
> +}
> +else
> +P(cpu_has_svm_avic, "AVIC (disabled)");
> +#undef P
> +
> +if ( !printed )
> +printk(" - none\n");
> +
>  return _function_table;
>  }
>  
> diff --git a/xen/include/asm-x86/hvm/svm/avic.h 
> b/xen/include/asm-x86/hvm/svm/avic.h
> index 1676e01..5be3e76 100644
> --- a/xen/include/asm-x86/hvm/svm/avic.h
> +++ b/xen/include/asm-x86/hvm/svm/avic.h
> @@ -41,4 +41,7 @@ void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs 
> *regs);
>  void svm_avic_vmexit_do_noaccel(struct cpu_user_regs *regs);
>  
>  void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vector);
> +
> +void setup_avic_dump(void);
> +
>  #endif /* _SVM_AVIC_H_ */

This hunk should be in the subsquent patch.  Otherwise, Reviewed-by:
Andrew Cooper 


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

Re: [Xen-devel] [PATCH v2 08/10] x86/SVM: Add interrupt management code via AVIC

[Andrew Cooper]

On 31/12/2016 05:45, Suravee Suthikulpanit wrote:
> Enabling AVIC implicitly disables the V_IRQ, V_INTR_PRIO, V_IGN_TPR,
> and V_INTR_VECTOR fields in the VMCB Control Word. Therefore, this patch
> introduces new interrupt injection code via AVIC backing page.
>
> Signed-off-by: Suravee Suthikulpanit 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Jan Beulich 
> Cc: Boris Ostrovsky 
> ---
>  xen/arch/x86/hvm/svm/avic.c| 28 
>  xen/arch/x86/hvm/svm/intr.c|  4 
>  xen/arch/x86/hvm/svm/svm.c | 12 ++--
>  xen/include/asm-x86/hvm/svm/avic.h |  1 +
>  4 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> index 6351c8e..faa5e45 100644
> --- a/xen/arch/x86/hvm/svm/avic.c
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -636,6 +636,34 @@ void svm_avic_vmexit_do_noaccel(struct cpu_user_regs 
> *regs)
>  return;
>  }
>  
> +void svm_avic_deliver_posted_intr(struct vcpu *v, u8 vec)
> +{
> +struct vlapic *vlapic = vcpu_vlapic(v);
> +
> +/* Fallback to use non-AVIC if vcpu is not enabled with AVIC. */
> +if ( !svm_avic_vcpu_enabled(v) )
> +{
> +if ( !vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) 
> )
> +vcpu_kick(v);
> +return;
> +}
> +
> +if ( !(guest_cpu_user_regs()->eflags & X86_EFLAGS_IF) )
> +return;

Won't this discard the interrupt?

> +
> +if ( vlapic_test_and_set_vector(vec, >regs->data[APIC_IRR]) )
> +return;
> +
> +/*
> + * If vcpu is running on another cpu, hit the doorbell to signal
> + * it to process interrupt. Otherwise, kick it.
> + */
> +if ( v->is_running && (v != current) )
> +wrmsrl(AVIC_DOORBELL, cpu_data[v->processor].apicid);

Hmm - my gut feeling is that this is racy without holding the scheduler
lock for the target pcpu.  Nothing (I am aware of) excludes ->is_running
and ->processor changing behind our back.

CC'ing George and Dario for their input.

~Andrew

> +else
> +vcpu_kick(v);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
>


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

Re: [Xen-devel] [PATCH v2 07/10] x86/SVM: Add vcpu scheduling support for AVIC

[Andrew Cooper]

On 31/12/2016 05:45, Suravee Suthikulpanit wrote:
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> index c0b7151..6351c8e 100644
> --- a/xen/arch/x86/hvm/svm/avic.c
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -73,6 +73,79 @@ avic_get_phy_apic_id_ent(const struct vcpu *v, unsigned 
> int index)
>  return _phy_apic_id_table[index];
>  }
>  
> +static void avic_vcpu_load(struct vcpu *v)
> +{
> +struct arch_svm_struct *s = >arch.hvm_svm;
> +int h_phy_apic_id;
> +struct avic_phy_apic_id_ent entry;
> +
> +if ( !s->avic_last_phy_id )
> +return;

What is the purpose of this check?  The VM should uniformly be using
AVIC or not.

> +
> +if ( test_bit(_VPF_blocked, >pause_flags) )
> +return;

This has better never be true if the scheduler has decides to context
switch into v's state.

~Andrew

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

Re: [Xen-devel] [PATCH v2 06/10] x86/SVM: Add AVIC vmexit handlers

[Andrew Cooper]

On 31/12/2016 05:45, Suravee Suthikulpanit wrote:
> VMEXIT_DO_NOACCEL:
> This oocurs when a guest access to an APIC register that cannot be

"occurs"

> accelerated by AVIC. In this case, Xen tries to emulate register accesses.
>
> This fault is also generated if an EOI isattempted when the highest priority

"is attempted"

> @@ -122,6 +125,8 @@ int svm_avic_dom_init(struct domain *d)
>  clear_domain_page(_mfn(mfn));
>  d->arch.hvm_domain.svm.avic_phy_apic_id_table_mfn = mfn;
>  
> +spin_lock_init(>arch.hvm_domain.svm.avic_ldr_mode_lock);
> +

I think this hunk belongs in the previous patch.

>  return ret;
>   err_out:
>  svm_avic_dom_destroy(d);
> @@ -222,6 +227,338 @@ int svm_avic_init_vmcb(struct vcpu *v)
>  }
>  
>  /*
> + * Note:
> + * This function handles the AVIC_INCOMP_IPI #vmexit when AVIC is enabled.
> + * The hardware generates this fault when an IPI could not be delivered
> + * to all targeted guest virtual processors because at least one guest
> + * virtual processor was not allocated to a physical core at the time.
> + */
> +void svm_avic_vmexit_do_incomp_ipi(struct cpu_user_regs *regs)
> +{
> +struct vcpu *curr = current;
> +struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb;
> +u32 icrh = vmcb->exitinfo1 >> 32;
> +u32 icrl = vmcb->exitinfo1;
> +u32 id = vmcb->exitinfo2 >> 32;
> +u32 index = vmcb->exitinfo2 && 0xFF;
> +
> +switch ( id )
> +{
> +case AVIC_INCMP_IPI_ERR_INVALID_INT_TYPE:
> +/*
> + * AVIC hardware handles the delivery of
> + * IPIs when the specified Message Type is Fixed
> + * (also known as fixed delivery mode) and
> + * the Trigger Mode is edge-triggered. The hardware
> + * also supports self and broadcast delivery modes
> + * specified via the Destination Shorthand(DSH)
> + * field of the ICRL. Logical and physical APIC ID
> + * formats are supported. All other IPI types cause
> + * a #VMEXIT, which needs to emulated.
> + */
> +vlapic_reg_write(curr, APIC_ICR2, icrh);
> +vlapic_reg_write(curr, APIC_ICR, icrl);
> +break;

Please have a newline between break and case.

> +case AVIC_INCMP_IPI_ERR_TARGET_NOT_RUN:
> +{
> +/*
> + * At this point, we expect that the AVIC HW has already
> + * set the appropriate IRR bits on the valid target
> + * vcpus. So, we just need to kick the appropriate vcpu.
> + */
> +struct vcpu *curc;
> +struct domain *curd = curr->domain;

currd is the more common name for this, and I would use a plain v
instead of curc as it isn't curr.

> +uint32_t dest = GET_xAPIC_DEST_FIELD(icrh);
> +uint32_t short_hand = icrl & APIC_SHORT_MASK;
> +bool dest_mode = !!(icrl & APIC_DEST_MASK);
> +
> +for_each_vcpu ( curd, curc )
> +{
> +if ( curc != curr &&
> + vlapic_match_dest(vcpu_vlapic(curc), vcpu_vlapic(curr),
> +   short_hand, dest, dest_mode) )
> +{
> +vcpu_kick(curc);
> +break;
> +}
> +}
> +break;
> +}
> +case AVIC_INCMP_IPI_ERR_INV_TARGET:
> +dprintk(XENLOG_ERR,
> +"SVM: %s: Invalid IPI target (icr=%#08x:%08x, idx=%u)\n",
> +__func__, icrh, icrl, index);
> +break;

Shouldn't this case be emulated to raise appropriate APIC errors in the
guests view?

> +case AVIC_INCMP_IPI_ERR_INV_BK_PAGE:
> +dprintk(XENLOG_ERR,
> +"SVM: %s: Invalid bk page (icr=%#08x:%08x, idx=%u)\n",
> +__func__, icrh, icrl, index);
> +break;
> +default:
> +dprintk(XENLOG_ERR, "SVM: %s: Unknown IPI interception (%#x)\n",
> +__func__, id);

These two cases are an error in Xen's setup, or the hardware.  They
should be gprintk()s (so as not to disappear in release builds), and
cause a domain_crash().

> +}
> +}
> +
> +static struct avic_log_apic_id_ent *
> +avic_get_logical_id_entry(const struct vcpu *v, u32 ldr, bool flat)
> +{
> +unsigned int index;
> +struct avic_log_apic_id_ent *avic_log_apid_id_table;
> +const struct svm_domain *d = >domain->arch.hvm_domain.svm;
> +unsigned int dest_id = GET_APIC_LOGICAL_ID(ldr);
> +
> +if ( !dest_id )
> +return NULL;
> +
> +if ( flat )
> +{
> +index = ffs(dest_id) - 1;
> +if ( index > 7 )
> +return NULL;
> +}
> +else
> +{
> +unsigned int cluster = (dest_id & 0xf0) >> 4;
> +int apic = ffs(dest_id & 0x0f) - 1;
> +
> +if ( (apic < 0) || (apic > 7) || (cluster >= 0xf) )
> +return NULL;
> +index = (cluster << 2) + apic;
> +}
> +
> +ASSERT(index <= 255);
> +
> +avic_log_apid_id_table = mfn_to_virt(d->avic_log_apic_id_table_mfn);

As with the phsyical table, this is buggy above 5TB, and should 

Re: [Xen-devel] [PATCH v2 05/10] x86/HVM/SVM: Add AVIC initialization code

[Andrew Cooper]

On 31/12/2016 05:45, Suravee Suthikulpanit wrote:
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> new file mode 100644
> index 000..b62f982
> --- /dev/null
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -0,0 +1,232 @@
> +/*
> + * avic.c: implements AMD Advance Virtual Interrupt Controller (AVIC) support
> + * Copyright (c) 2016, Advanced Micro Devices, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * Note: Current max index allowed for physical APIC ID table is 255.
> + */
> +#define AVIC_PHY_APIC_ID_MAX0xFF
> +
> +#define AVIC_DOORBELL   0xc001011b
> +
> +#define AVIC_HPA_SHIFT  12
> +#define AVIC_HPA_MASK   (((1ULL << 40) - 1) << AVIC_HPA_SHIFT)

What does this mask represent?  I have spotted a truncation bug below,
but how to fix the issue depends on the meaning of the mask.

The only limits I can see in the spec is that the host physical
addresses must be present in system RAM, which presumably means they
should follow maxphysaddr like everything else?

> +#define AVIC_VAPIC_BAR_MASK AVIC_HPA_MASK
> +
> +/*
> + * Note:
> + * Currently, svm-avic mode is not supported with nested virtualization.
> + * Therefore, it is not yet currently enabled by default. Once the support
> + * is in-place, this should be enabled by default.
> + */
> +bool svm_avic = 0;
> +boolean_param("svm-avic", svm_avic);

We are trying to avoid the proliferation of top-level options.  Please
could you introduce a "svm=" option which takes avic as a sub-boolean,
similar to how iommu= currently works?

> +
> +static struct avic_phy_apic_id_ent *
> +avic_get_phy_apic_id_ent(const struct vcpu *v, unsigned int index)

The Physical APIC table is per-domain, not per-cpu according to the
spec.  This function should take a struct domain, although I don't think
you need it at all (see below).

> +{
> +struct avic_phy_apic_id_ent *avic_phy_apic_id_table;
> +struct svm_domain *d = >domain->arch.hvm_domain.svm;
> +
> +if ( !d->avic_phy_apic_id_table_mfn )
> +return NULL;
> +
> +/*
> +* Note: APIC ID = 0xff is used for broadcast.
> +*   APIC ID > 0xff is reserved.
> +*/
> +if ( index >= 0xff )
> +return NULL;
> +
> +avic_phy_apic_id_table = mfn_to_virt(d->avic_phy_apic_id_table_mfn);

This is unsafe and will break on hosts with more than 5TB of RAM.

As you allocate avic_phy_apic_id_table_mfn with alloc_domheap_page(),
you must use {map,unmap}_domain_page() to get temporary mappings (which
will use mfn_to_virt() in the common case), or use
{map,unmap}_domain_page_global() to get permanent mappings.

As the values in here need modifying across a schedule, I would suggest
making a global mapping at create time, and storing the result in a
properly-typed pointer.

> +
> +return _phy_apic_id_table[index];
> +}
> +
> +int svm_avic_dom_init(struct domain *d)
> +{
> +int ret = 0;
> +struct page_info *pg;
> +unsigned long mfn;

mfn_t please, which would also highlight the type error in svm_domain.

> +
> +if ( !svm_avic )
> +return 0;

|| !has_vlapic(d)

HVMLite domains may legitimately be configured without an LAPIC at all.

> +
> +/*
> + * Note:
> + * AVIC hardware walks the nested page table to check permissions,
> + * but does not use the SPA address specified in the leaf page
> + * table entry since it uses  address in the AVIC_BACKING_PAGE pointer
> + * field of the VMCB. Therefore, we set up a dummy page for APIC _mfn(0).
> + */
> +if ( !d->arch.hvm_domain.svm.avic_access_page_done )
> +{
> +set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE),
> +   _mfn(0), PAGE_ORDER_4K,
> +   p2m_get_hostp2m(d)->default_access);
> +d->arch.hvm_domain.svm.avic_access_page_done = true;

I don't see the purpose of this avic_access_page_done boolean, even in
later patches.

> +}
> +
> +/* Init AVIC logical APIC ID table */
> +pg = alloc_domheap_page(d, MEMF_no_owner);
> +if ( !pg )
> +{
> +gdprintk(XENLOG_ERR,
> +"%d: AVIC logical APIC ID table could not be allocated.\n",
> +d->domain_id);

Do we 

[Xen-devel] [distros-debian-sid test] 68305: tolerable FAIL

[Platform Team regression test user]

flight 68305 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68305/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-armhf-sid-netboot-pygrub  9 debian-di-install fail like 68274
 test-amd64-i386-amd64-sid-netboot-pygrub  9 debian-di-install  fail like 68274
 test-amd64-i386-i386-sid-netboot-pvgrub  9 debian-di-install   fail like 68274
 test-amd64-amd64-amd64-sid-netboot-pvgrub  9 debian-di-install fail like 68274
 test-amd64-amd64-i386-sid-netboot-pygrub  9 debian-di-install  fail like 68274

baseline version:
 flight   68274

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


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

Re: [Xen-devel] domains names

[Andrew Cooper]

On 02/01/2017 14:01, Yessine Daoud wrote:
> Hello,
>
> Why xen does not print domains names when dumping domains information
> (using "q" on xen console) ?

Because the hypervisor doesn't know the textural names given to domains
by the toolstack.

You must identify domains by domid.

~Andrew

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

[Xen-devel] domains names

[Yessine Daoud]

Hello,

Why xen does not print domains names when dumping domains information
(using "q" on xen console) ?

Regards,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 104003: tolerable FAIL

[osstest service owner]

flight 104003 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104003/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat  fail pass in 104002

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104002
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104002
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104002
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104002
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104002
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104002
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104002
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 104002
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 104002

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ee524f2bfa681ad116b8ae925fa8f3f18ee12ba5
baseline version:
 xen  ee524f2bfa681ad116b8ae925fa8f3f18ee12ba5

Last test of basis   104003  2017-01-02 01:58:36 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17168 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass