[Xen-devel] [libvirt test] 105657: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   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
 build-arm64-xsm   5 xen-buildfail   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
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  c89a6e7878e630718cce0af940e9c070c132ce30
baseline version:
 libvirt  2841e6756d5807a4119e004bc5fb8e7d70806458

Last test of basis   105624  2017-02-08 04:21:59 Z1 days
Testing same since   105657  2017-02-09 04:20:10 Z0 days1 attempts


People who touched revisions under test:
  Jim Fehlig 
  Joao Martins 
  Michal Privoznik 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  fail
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsfail
 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-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 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

[Xen-devel] [PATCH V2] common/vm_event: Prevent guest locking with large max_vcpus

[Razvan Cojocaru]

It is currently possible for the guest to lock when subscribing
to synchronous vm_events if max_vcpus is larger than the
number of available ring buffer slots. This patch no longer
blocks already paused VCPUs, fixing the issue for this use
case, and wakes up as many blocked VCPUs as there are slots
available in the ring buffer, eliminating the blockage for
asynchronous events.

Signed-off-by: Razvan Cojocaru 
---
 xen/common/vm_event.c | 27 +++
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 82ce8f1..76c4e2c 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -127,26 +127,11 @@ static unsigned int vm_event_ring_available(struct 
vm_event_domain *ved)
 static void vm_event_wake_blocked(struct domain *d, struct vm_event_domain 
*ved)
 {
 struct vcpu *v;
-int online = d->max_vcpus;
 unsigned int avail_req = vm_event_ring_available(ved);
 
 if ( avail_req == 0 || ved->blocked == 0 )
 return;
 
-/*
- * We ensure that we only have vCPUs online if there are enough free slots
- * for their memory events to be processed.  This will ensure that no
- * memory events are lost (due to the fact that certain types of events
- * cannot be replayed, we need to ensure that there is space in the ring
- * for when they are hit).
- * See comment below in vm_event_put_request().
- */
-for_each_vcpu ( d, v )
-if ( test_bit(ved->pause_flag, >pause_flags) )
-online--;
-
-ASSERT(online == (d->max_vcpus - ved->blocked));
-
 /* We remember which vcpu last woke up to avoid scanning always linearly
  * from zero and starving higher-numbered vcpus under high load */
 if ( d->vcpu )
@@ -160,13 +145,13 @@ static void vm_event_wake_blocked(struct domain *d, 
struct vm_event_domain *ved)
 if ( !v )
 continue;
 
-if ( !(ved->blocked) || online >= avail_req )
+if ( !(ved->blocked) || avail_req == 0 )
break;
 
 if ( test_and_clear_bit(ved->pause_flag, >pause_flags) )
 {
 vcpu_unpause(v);
-online++;
+avail_req--;
 ved->blocked--;
 ved->last_vcpu_wake_up = k;
 }
@@ -280,8 +265,9 @@ void vm_event_put_request(struct domain *d,
 int free_req;
 unsigned int avail_req;
 RING_IDX req_prod;
+struct vcpu *curr = current;
 
-if ( current->domain != d )
+if ( curr->domain != d )
 {
 req->flags |= VM_EVENT_FLAG_FOREIGN;
 #ifndef NDEBUG
@@ -316,8 +302,9 @@ void vm_event_put_request(struct domain *d,
  * See the comments above wake_blocked() for more information
  * on how this mechanism works to avoid waiting. */
 avail_req = vm_event_ring_available(ved);
-if( current->domain == d && avail_req < d->max_vcpus )
-vm_event_mark_and_pause(current, ved);
+if( curr->domain == d && avail_req < d->max_vcpus /* &&
+!atomic_read(>vm_event_pause_count) */ )
+vm_event_mark_and_pause(curr, ved);
 
 vm_event_ring_unlock(ved);
 
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v6 01/24] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

[Yi Sun]

On 17-02-08 10:56:55, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 08, 2017 at 04:15:53PM +0800, Yi Sun wrote:
> > +  Every MSR stores a CBM value. A capacity bitmask (CBM) provides a hint 
> > to the
> > +  hardware indicating the cache space an application should be limited to 
> > as
> 
> s/application/VM/ ?
> 
> > +  well as providing an indication of overlap and isolation in the 
> > CAT-capable
> > +  cache from other applications contending for the cache.
> 
> s/application/VM/ ?
> 
> Perhaps 'domain' as you use that later in the document?
> 
> > +  PSR features in future). In some cases, a VM is permitted to have a COS
> 
> I noticed you say 'domain' later on in the document. Would it make
> sense to replace s/VM/domain/ to be same in this design?
> 
I think domain should be better.

> > +  - Member `ops`
> > +
> > +`ops` maintains a callback function list of the feature. It will 
> > be introduced
> > +in details later at `4. Feature operation functions structure`.
> 
> I think you can just do:
> 
> [Feature operation functions structure]
> 
> And when you run `pandoc -toc -o intel_psr_cat_cdp.pdf
> intel_psr_cat_cdp.pandoc`
> 
> it will provide the right link (which you can follow) to the proper
> section.

I tried this command but encountered below error.

$ pandoc -toc -o intel_psr_cat_cdp.pdf docs/features/intel_psr_cat_cdp.pandoc
pandoc: cannot produce pdf output with oc writer

> > +root@:~$ xl psr-cat-cbm-set -l2 1 0x7f
> > +
> > +root@:~$ xl psr-cat-show -l2 1
> > +Socket ID   : 0
> > +Default CBM : 0xff
> > +   ID NAME CBM
> > +1 ubuntu140x7f
> > +
> > +# Areas for improvement
> > +
> > +N/A
> 
> I would say that using '0x7f' is not very user-friendly. It really
> would be good if that changed to something easier to grok.
> 
I agree that '0x7f' is not user-friendly. This needs the user know some HW
details.

> For example if I am system admin and I look at:
> 
>+++++++++
>| M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
>+++++++++
>   COS0 | A  | A  | A  | A  ||||| Isolated Bitmask
>+++++++++
>   COS1 ||||| A  | A  |||
>+++++++++
>   COS2 ||||||| A  | A  |
>+++++++++
> 
> I would think that giving an guest 'M7->M4' means it has more
> cache than M3->M2 or M1->M0.
> 
> But that is not spelled in details. Or what happens if I do:
>+++++++++
>| M7 | M6 | M5 | M4 | M3 | M2 | M1 | M0 |
>+++++++++
>   COS0 |||||| A  ||| Isolated Bitmask
>+++++++++
>   COS1 ||||||| A  ||
>+++++++++
>   COS2 |||||||| A  |
>+++++++++
> 
> Does that have the same effect as the previous one?
> I would think not, but perhaps it is the same (we set
> three 'pools').
> 
No, this has different effect. One bit means a quantity of cache capacity, e.g.
1 bit equals 1M. For first case, 0 uses 4M cache, 1 uses 2M, 2 uses 2M. For
second case, all three use 1M respectively. 

Although '0x7F' is not user friendly, it gives the ability to control the
granularity of cache allocation. Furthermore, the implementation in Xen is low
level interface and we should provide the most flexibility to users. I think
the upper layer, e.g. libvirt, may do further wrapper to provide more user
friendly interfaces.

Thanks,
Sun Yi

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

Re: [Xen-devel] arm: alloc_heap_pages allocates already allocated page

[Vijay Kilari]

On Wed, Feb 8, 2017 at 9:12 PM, Julien Grall  wrote:
>
>
> On 08/02/17 14:18, Julien Grall wrote:
>> Hi,
>>
>> On 07/02/17 15:59, Vijay Kilari wrote:
>>> On Tue, Feb 7, 2017 at 6:57 PM, Julien Grall  wrote:


 On 07/02/2017 13:25, Vijay Kilari wrote:
>
> On Tue, Feb 7, 2017 at 6:30 PM, Julien Grall  wrote:
>>
>>
>> One more thing, if Xen 4.7 was able to go up to booting Dom0 without any
>> patches on a NUMA board. I would recommend to try to bisect and see if
>> you
>> can find an offending commit.
>
>
>   Yes, with plain 4.7 panic is not seen


 Can you please bisect Xen? It could save us a bit of time to understand
 what's going on.
>>>
>>> ubuntu@ubuntu:~/xen_upstream_new/xen$ git bisect bad
>>> 493f535a06b5b4041c0745e954780dd5d6f80581 is the first bad commit
>>> commit 493f535a06b5b4041c0745e954780dd5d6f80581
>>> Author: Julien Grall 
>>> Date:   Thu Sep 15 12:28:36 2016 +0100
>>>
>>> xen/arm: p2m: Re-implement p2m_insert_mapping using p2m_set_entry
>>>
>>> The function p2m_insert_mapping can be re-implemented using the generic
>>> function p2m_set_entry.
>>>
>>> Note that the mapping is not reverted anymore if Xen fails to insert a
>>> mapping. This was added to ensure the MMIO are not kept half-mapped
>>> in case of failure and to follow the x86 counterpart. This was removed
>>> on the x86 part by commit c3c756bd "x86/p2m: use large pages for MMIO
>>> mappings" and I think we should let the caller taking care of it.
>>>
>>> Finally drop the operation INSERT in apply_* as nobody is using it
>>> anymore. Note that the functions could have been dropped in one go at 
>>> the
>>> end, however I find easier to drop the operations one by one avoiding a
>>> big deletion in the patch that convert the last operation.
>>>
>>> Signed-off-by: Julien Grall 
>>> Reviewed-by: Stefano Stabellini 
>>> Tested-by: Tamas K Lengyel 
>>>
>>
>> I think I have managed to reproduce the crash at boot time though the stack
>> trace is different (see below). This sounds like to me a memory corruption,
>> I will dig down and see what I can find.
>
> Hmmm after all the issue might be different. My DT was describing some
> LPIs but Xen had no check. So we ended up to overrun the buffer.
>
> This hack patch should tell whether you have LPIs described in your DT:
>
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index a5348f2..0631441 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -238,6 +238,10 @@ int gic_irq_xlate(const u32 *intspec, unsigned int 
> intsize,
>  if ( out_type )
>  *out_type = intspec[2] & IRQ_TYPE_SENSE_MASK;
>
> +/* Be crude for now */
> +if ( *out_hwirq > 1024 )
> +return -EINVAL;
> +
>  return 0;
>  }
>
  still I hit the error.

> If you hit an error, I would recommend to drop them. If not and still have 
> the issue
> few things I would recommend to try:
> - A different compiler version
> - Look at the state of the heap everytime you allocate/free a page

OK
>
> Cheers,
>
> --
> Julien Grall

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

[Xen-devel] [xen-unstable test] 105648: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd   3 host-install(3)broken REGR. vs. 105629
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 105629
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105629

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 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-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  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  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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-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-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  58b4db0832de1ee355a342feea7e1545219bef12
baseline version:
 xen  63e1d01b8fd948b3e0fa3beea494e407668aa43b

Last test of basis   105629  2017-02-08 06:54:04 Z0 days
Failing since105640  2017-02-08 14:19:37 Z0 days2 attempts
Testing same since   105648  2017-02-08 22:14:42 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Baptiste Daroussin 
  Fatih Acar 
  George Dunlap 
  Ian Jackson 

[Xen-devel] [qemu-mainline test] 105656: regressions - FAIL

[osstest service owner]

flight 105656 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105656/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 

[Xen-devel] [ovmf baseline-only test] 68540: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68540 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68540/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ad1cd1aa09c0a8660c857de916105b1fd566ca8c
baseline version:
 ovmf 9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac

Last test of basis68539  2017-02-08 22:50:35 Z0 days
Testing same since68540  2017-02-09 02:46:33 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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.


commit ad1cd1aa09c0a8660c857de916105b1fd566ca8c
Author: Jiaxin Wu 
Date:   Wed Feb 8 12:56:54 2017 +0800

NetworkPkg/NetworkPkg.uni: Define the prompt and help information for 
PcdAllowHttpConnections

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Fu Siyuan 
Reviewed-by: Ye Ting 

commit 27fd61af01453b997ef1b79b91dfb7fa65d2e253
Author: Jiaxin Wu 
Date:   Wed Feb 8 11:56:54 2017 +0800

MdeModulePkg/DxeHttpLib: Correct the return status for the HTTP 
Port/ContentLength

Replace AsciiStrDecimalToUintn with AsciiStrDecimalToUintnS to
return the correct status for the HTTP Port/ContentLength.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Fu Siyuan 
Reviewed-by: Ye Ting 

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

[Xen-devel] [qemu-mainline test] 105654: regressions - FAIL

[osstest service owner]

flight 105654 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105654/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

[Haozhong Zhang]

On 02/08/17 10:31 +, Wei Liu wrote:

On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote:

On 01/27/17 17:11 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang wrote:
> > If any error code is returned when creating a domain, stop the domain
> > creation.
>
> This looks like it is a bug-fix that can be spun off from this
> patchset?
>

Yes, if everyone considers it's really a bug and the fix does not
cause compatibility problem (e.g. xl w/o this patch does not abort the
domain creation if it fails to connect to QEMU VNC port).



I'm two minded here. If the failure to connect is caused by some
temporary glitches in QEMU and we're sure it will eventually succeed,
there is no need to abort domain creation. If failure to connect is due
to permanent glitches, we should abort.



Sorry, I should say "*query* QEMU VNC port" instead of *connect*.

libxl__qmp_initializations() currently does following tasks.
1/ Create a QMP socket.

  I think all failures in 1/ should be considered as permanent. It
  does not only fail the following tasks, but also fails the device
  hotplug which needs to cooperate with QEMU.

2/ If 1/ succeeds, query qmp about parameters of serial port and fill
  them in xenstore.
3/ If 1/ and 2/ succeed, set and query qmp about parameters (password,
  address, port) of VNC and fill them in xenstore.

  If we assume Xen always send the correct QMP commands and
  parameters, the QMP failures in 2/ and 3/ will be caused by QMP
  socket errors (see qmp_next()), which are hard to tell whether they
  are permanent or temporal. However, if the missing of serial port
  or VNC is considered as not affecting the execution of guest
  domain, we may ignore failures here.


OOI how did you discover this issue? That could be the key to understand
the issue here.


The next patch adds code in libxl__qmp_initialization() to query qmp
about vNVDIMM parameters (e.g. the base gpfn which is calculated by
QEMU) and return error code if it fails. While I was developing that
patch, I found xl didn't stop even if bugs in my QEMU patches failed
the code in my Xen patch.

Maybe we could let libxl__qmp_initializations() report whether a
failure can be tolerant. For non-tolerant failures (e.g. those in 1/),
xl should stop. For tolerant failures (e.g. those in 2/ and 3/), xl
can continue, but it needs to warn those failures.

Thanks,
Haozhong



Wei.


Thanks,
Haozhong

> >
> > Signed-off-by: Haozhong Zhang 
> > ---
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > ---
> >  tools/libxl/libxl_create.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index d986cd2..24e8368 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -1499,7 +1499,9 @@ static void domcreate_devmodel_started(libxl__egc 
*egc,
> >  if (dcs->sdss.dm.guest_domid) {
> >  if (d_config->b_info.device_model_version
> >  == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
> > -libxl__qmp_initializations(gc, domid, d_config);
> > +ret = libxl__qmp_initializations(gc, domid, d_config);
> > +if (ret)
> > +goto error_out;
> >  }
> >  }
> >
> > --
> > 2.10.1
> >
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel


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


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

[Xen-devel] [ovmf test] 105652: all pass - PUSHED

[osstest service owner]

flight 105652 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105652/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ad1cd1aa09c0a8660c857de916105b1fd566ca8c
baseline version:
 ovmf 9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac

Last test of basis   105636  2017-02-08 11:45:18 Z0 days
Testing same since   105652  2017-02-09 00:45:19 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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=ovmf
+ revision=ad1cd1aa09c0a8660c857de916105b1fd566ca8c
+ . ./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 /home/osstest/repos/lock ./ap-push ovmf 
ad1cd1aa09c0a8660c857de916105b1fd566ca8c
+ branch=ovmf
+ revision=ad1cd1aa09c0a8660c857de916105b1fd566ca8c
+ . ./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/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' xad1cd1aa09c0a8660c857de916105b1fd566ca8c = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

[Xen-devel] [xen-unstable-smoke test] 105653: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  9d5617cd89e7b285afa785b9a9d3495f4e2dffae
baseline version:
 xen  58b4db0832de1ee355a342feea7e1545219bef12

Last test of basis   105642  2017-02-08 16:04:21 Z0 days
Failing since105644  2017-02-08 18:01:23 Z0 days5 attempts
Testing same since   105653  2017-02-09 01:01:03 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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=xen-unstable-smoke
+ revision=9d5617cd89e7b285afa785b9a9d3495f4e2dffae
+ . ./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 /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
9d5617cd89e7b285afa785b9a9d3495f4e2dffae
+ branch=xen-unstable-smoke
+ revision=9d5617cd89e7b285afa785b9a9d3495f4e2dffae
+ . ./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/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x9d5617cd89e7b285afa785b9a9d3495f4e2dffae = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : 

Re: [Xen-devel] [PATCH 0/9] libxl: spolit up libxl.c

[Zhang Chen]

On 02/09/2017 12:54 AM, Wei Liu wrote:

And CC Zhangchen


Thanks, I will apply this patch set before test my patch.


Zhang Chen



On Wed, Feb 08, 2017 at 02:35:27PM +, Wei Liu wrote:

Cc Yi Sun as well.

Haozhong and Yi: This is just a heads-up -- Juergen from SuSE took the
time to split libxl.c so things are better organised. It's likely this
series will go in before yours, so you will then need to rebase your
series. I don't expect there to be much breakage because it is all
mechanical, but rebasing is still work for you.

Let us know if you have any concern so that we can coordinate this.

Wei.

On Wed, Feb 08, 2017 at 02:13:37PM +0100, Juergen Gross wrote:

libxl.c has become rather large. Split it up into multiple files.

Code movement only. No functional change intended.

Juergen Gross (9):
   libxl: adjust copyright comment of libxl.c
   libxl: carve out cpupool specific functions from libxl.c
   libxl: carve out scheduler specific functions from libxl.c
   libxl: carve out disk specific functions from libxl.c
   libxl: carve out console specific functions from libxl.c
   libxl: carve out memory specific functions from libxl.c
   libxl: move device specific functions out of libxl.c
   libxl: carve out tmem specific functions from libxl.c
   libxl: carve out domain specific functions from libxl.c

  tools/libxl/Makefile |4 +-
  tools/libxl/libxl.c  | 6252 +-
  tools/libxl/libxl_console.c  |  862 ++
  tools/libxl/libxl_cpupool.c  |  443 +++
  tools/libxl/libxl_device.c   |  435 ++-
  tools/libxl/libxl_disk.c | 1258 +
  tools/libxl/libxl_domain.c   | 1744 
  tools/libxl/libxl_internal.h |8 +-
  tools/libxl/libxl_mem.c  |  601 
  tools/libxl/libxl_sched.c|  915 +++
  tools/libxl/libxl_tmem.c |  167 ++
  11 files changed, 6424 insertions(+), 6265 deletions(-)
  create mode 100644 tools/libxl/libxl_console.c
  create mode 100644 tools/libxl/libxl_cpupool.c
  create mode 100644 tools/libxl/libxl_disk.c
  create mode 100644 tools/libxl/libxl_domain.c
  create mode 100644 tools/libxl/libxl_mem.c
  create mode 100644 tools/libxl/libxl_sched.c
  create mode 100644 tools/libxl/libxl_tmem.c

--
2.10.2



.



--
Thanks
Zhang Chen




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

[Xen-devel] [linux-linus test] 105641: regressions - FAIL

[osstest service owner]

flight 105641 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105641/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2 16 guest-saverestore.2 fail in 105625 REGR. vs. 
59254

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl16 guest-saverestore.2 fail in 105616 pass in 105625
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail in 105616 
pass in 105641
 test-amd64-i386-xl-xsm  14 guest-saverestore fail in 105616 pass in 105641
 test-amd64-amd64-xl17 guest-localmigrate/x10 fail in 105625 pass in 105616
 test-amd64-amd64-pair 21 guest-migrate/src_host/dst_host fail in 105625 pass 
in 105641
 test-amd64-amd64-xl-xsm 17 guest-localmigrate/x10 fail in 105625 pass in 105641
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-localmigrate fail in 105625 
pass in 105641
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
105625 pass in 105641
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 105625 pass in 105641
 test-amd64-amd64-xl-credit2  14 guest-saverestore  fail pass in 105625
 test-amd64-i386-xl   15 guest-localmigrate fail pass in 105625
 test-amd64-amd64-xl  16 guest-saverestore.2fail pass in 105625
 test-amd64-i386-xl-xsm   17 guest-localmigrate/x10 fail pass in 105625

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-i386-libvirt  14 guest-saverestorefail blocked in 59254
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-i386-pvgrub 21 leak-check/check fail in 105625 baseline 
untested
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail in 105625 blocked in 
59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 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-cubietruck 12 

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Stefano Stabellini]

On Thu, 9 Feb 2017, Julien Grall wrote:
> On 08/02/2017 23:28, Tamas K Lengyel wrote:
> > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  wrote:
> > > Hi Tamas,
> > > 
> > > Can you please try to configure your e-mail client to use '>' rather than
> > > '
> > > '? It makes quite hard to read the e-mail.
> > 
> > Hm, not sure why it switched but should be fine now.
> > 
> > > On 08/02/2017 20:15, Tamas K Lengyel wrote:
> > > > 
> > > > 
> > > > 
> > > > On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
> > > > > wrote:
> > > > On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
> > > 
> > > 
> > > > If platform_hvc() consumes an SMC, it's considered part of the Xen
> > > > API.
> > > > Visible but not filterable by a monitor.
> > > > 
> > > > 
> > > > Platforms can then dictate which SMC calls are better handled within
> > > > Xen and
> > > > which ones can be exposed to dom0 user-space.
> > > > 
> > > > In addition, there could be a hypercall to disable platform specific
> > > > handling
> > > > in Xen alltogether for a given guest. Then everything goes to dom0
> > > > user-space.
> > > > 
> > > > It's a little messy...
> > > > 
> > > > 
> > > > 
> > > > That is messy and I would not want any SMCs reaching the firmware when
> > > > the monitor application is in use. The monitor interface is disabled by
> > > > default and there aren't any known usecases where the SMC has to reach
> > > > both the firmware and the monitor application as well. So I think it is
> > > > safe to just make the two things mutually exclusive.
> > > 
> > > 
> > > If you look at the SMC Calling Convention [1] both HVC and SMC are
> > > considered a conduit for service call to the secure firmware or
> > > hypervisor.
> > > It would be up to the hypervisor deciding what to do.
> > > 
> > > Lets imagine the guest is deciding to use HVC to access the secure
> > > firmware
> > > (AFAIU this patch series is adding that), are you going to monitor all the
> > > HVCs (including hypercall)?
> > 
> > There are some fundamental differences between HVC and SMC calls
> > though. An HVC can only land in the hypervisor, so as a hypercall, I
> > would expect it to be something I can deny via XSM. That is a
> > sufficient option for now to block the path to the firmware. If we end
> > up needing to support an application that uses that hypercall for
> > something critical, then yes, it would also need to be hooked into the
> > monitor system. At the moment this is not necessary.
> 
> My point is not about what is necessary at the moment. But what is right
> things to do. If you look at the spec, HVC are not only for hypercall, but any
> other kind of services. Why would you deny something that is valid from the
> specification (see 5.2.1)?
> 
> "The SMC calling convention, however, does not specify which instruction
> (either SMC or HVC) to use to invoke a
> particular service."

To have a generic solution, we need a way to specify a set of HVC/SMC
calls that get monitored and a set that get handled in Xen (platform
specific or otherwise). I think it is OK not to do both, at least at the
beginning, but we might want to add that feature in the future.

As much as I would like to see that, in respect to this series, I don't
think we should ask Edgar to introduce such a mechanism. However, we do
need to decide what Xen should do when platform_hvc is implemented and
monitor is also enabled.

I think the default should be to only call platform_hvc, because there
are many valid monitoring use-cases which don't require those few
platform specific SMC/HVC calls to be forwarded to the monitor.

However, if we did that, we would break Tamas' scenario. Thus, I suggest
we also introduce a simple compile time option or Xen command line
option to forward all platform_hvc calls to the monitor instead of
implementing them in Xen. Something like "MONITOR_OVERRIDE". In the
future, we can replace it with a more generic framework to dynamically
configure at runtime which SMC/HVC calls get forwarded.

What do you think?


> > So if we are landing in do_trap_smc from an HVC call, I think it would
> > be better to introduce a separate function for it rather then just
> > bunching the two together here.
> > 
> > > 
> > > Similarly, non-modified baremetal app could use SMC to power on/off the
> > > vCPU
> > > (see PSCI spec). Will you emulate that in the monitor app?
> > 
> > Yes, the underlying setup requires that everything that is expected
> > from the firmware to be performed either by the monitor app, or have
> > the monitor app further delegate it somewhere that can perform the
> > task. That can be either the firmware itself (if its safe), or an
> > isolated VM if it is possible to perform the task there. I wouldn't
> > call this emulation necessarily btw.
> 
> You haven't understood my point. Xen is currently emulating PSCI call 

[Xen-devel] [qemu-mainline test] 105643: regressions - FAIL

[osstest service owner]

flight 105643 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105643/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 

Re: [Xen-devel] [PATCH 0/9] libxl: spolit up libxl.c

[Haozhong Zhang]

On 02/08/17 14:35 +, Wei Liu wrote:

Cc Yi Sun as well.

Haozhong and Yi: This is just a heads-up -- Juergen from SuSE took the
time to split libxl.c so things are better organised. It's likely this
series will go in before yours, so you will then need to rebase your
series. I don't expect there to be much breakage because it is all
mechanical, but rebasing is still work for you.



Thank you for the remind. As this series does not introduce functional
changes and most of libxl changes for NVDIMM already went into a
separate libxl_nvdimm.c in my patches, the rebase should be trivial
for me.

Haozhong


Let us know if you have any concern so that we can coordinate this.

Wei.

On Wed, Feb 08, 2017 at 02:13:37PM +0100, Juergen Gross wrote:

libxl.c has become rather large. Split it up into multiple files.

Code movement only. No functional change intended.

Juergen Gross (9):
  libxl: adjust copyright comment of libxl.c
  libxl: carve out cpupool specific functions from libxl.c
  libxl: carve out scheduler specific functions from libxl.c
  libxl: carve out disk specific functions from libxl.c
  libxl: carve out console specific functions from libxl.c
  libxl: carve out memory specific functions from libxl.c
  libxl: move device specific functions out of libxl.c
  libxl: carve out tmem specific functions from libxl.c
  libxl: carve out domain specific functions from libxl.c

 tools/libxl/Makefile |4 +-
 tools/libxl/libxl.c  | 6252 +-
 tools/libxl/libxl_console.c  |  862 ++
 tools/libxl/libxl_cpupool.c  |  443 +++
 tools/libxl/libxl_device.c   |  435 ++-
 tools/libxl/libxl_disk.c | 1258 +
 tools/libxl/libxl_domain.c   | 1744 
 tools/libxl/libxl_internal.h |8 +-
 tools/libxl/libxl_mem.c  |  601 
 tools/libxl/libxl_sched.c|  915 +++
 tools/libxl/libxl_tmem.c |  167 ++
 11 files changed, 6424 insertions(+), 6265 deletions(-)
 create mode 100644 tools/libxl/libxl_console.c
 create mode 100644 tools/libxl/libxl_cpupool.c
 create mode 100644 tools/libxl/libxl_disk.c
 create mode 100644 tools/libxl/libxl_domain.c
 create mode 100644 tools/libxl/libxl_mem.c
 create mode 100644 tools/libxl/libxl_sched.c
 create mode 100644 tools/libxl/libxl_tmem.c

--
2.10.2



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

[Xen-devel] [ovmf baseline-only test] 68539: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68539 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68539/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac
baseline version:
 ovmf cc20411062137e5d820a33db73d41f97dae74368

Last test of basis68538  2017-02-08 15:21:15 Z0 days
Testing same since68539  2017-02-08 22:50:35 Z0 days1 attempts


People who touched revisions under test:
  Ruiyu Ni 
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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.


commit 9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac
Author: Star Zeng 
Date:   Tue Jan 17 17:58:26 2017 +0800

SecurityPkg HashLibRouter: Avoid incorrect PcdTcg2HashAlgorithmBitmap

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=244

Currently, when software HashLib (HashLibBaseCryptoRouter) and related
HashInstanceLib instances are used, PcdTcg2HashAlgorithmBitmap is
expected to be configured to 0 in platform dsc.
But PcdTcg2HashAlgorithmBitmap has default value 0x in
SecurityPkg.dec, and some platforms forget to configure it to 0 or
still configure it to 0x in platform dsc, that will make final
PcdTcg2HashAlgorithmBitmap value incorrect.

This patch is to add CONSTRUCTOR in HashLib (HashLibBaseCryptoRouter)
and PcdTcg2HashAlgorithmBitmap will be set to 0 in the CONSTRUCTOR.

Current HASH_LIB_PEI_ROUTER_GUID HOB created in
HashLibBaseCryptoRouterPei is shared between modules that link
HashLibBaseCryptoRouterPei.
To avoid mutual interference, separated HASH_LIB_PEI_ROUTER_GUID HOBs
with gEfiCallerIdGuid Identifier will be created for those modules.

This patch is also to add check in HashLib (HashLibBaseCryptoRouter)
for the mismatch of supported HashMask between modules that may link
different HashInstanceLib instances, warning will be reported if
mismatch is found.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by: Chao Zhang 

commit 00e39b0939574d7c2ce5dbd14f0aa2c1297e42fe
Author: Ruiyu Ni 
Date:   Mon Feb 6 10:00:33 2017 +0800

MdeModulePkg/UefiBootManagerLib: Initialize Handle before using it

BmExpandMediaDevicePath contains a bug that it uses the
uninitialized Handle.

Since the function is called when the Handle supports BlockIo
or SimpleFileSystem, when there is no SimpleFileSystem installed
on the Handle, BlockIo is *guaranteed* to be installed on the Handle.
The fix initializes the Handle by locating the BlockIo protocol
from the device path.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jeff Fan 
Reviewed-by: Sunny Wang 

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

Re: [Xen-devel] [PATCH v2 1/2] x86/vmx: Introduce a bitfield structure for EPT_VIOLATION EXIT_QUALIFICATIONs

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, February 08, 2017 6:43 PM
> 
> This results in rather more readable code.  No functional change.
> 
> All fields currently specified are included, but commented out as no support
> for their use is present.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v6] x86/hvm: add vcpu parameter to guest memory copy function

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, February 08, 2017 9:37 PM
> 
> >>> On 07.02.17 at 18:35,  wrote:
> > Current __hvm_copy assumes that the destination memory belongs to the 
> > current
> > vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
> > functions are used with current being the idle vcpu. Add a new vcpu
> > parameter
> > to hvm copy in order to solve that. Note that only hvm_copy_to_guest_phys is
> > changed to take a vcpu parameter, because that's the only one at the moment
> > that's required in order to build a PVHv2 Dom0.
> >
> > While there, also assert that the passed vcpu belongs to a HVM guest.
> >
> > Signed-off-by: Roger Pau Monné 
> 
> Various Cc-s missing here, btw.
> 
> Jan
> 

Reviewed-by: Kevin Tian 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/4] x86/vmx: improve vmread_safe()

[Tian, Kevin]

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, February 08, 2017 6:10 PM
> 
> The original function doesn't distinguish between Valid and Invalid
> VMfails.  Improved function returns error code depending on the outcome:
> 
> VMsucceed: 0
>   VMfailValid: VM Instruction Error Number
> VMfailInvalid: VMX_INSN_FAIL_INVALID (~0)
> 
> Existing users of __vmread_safe() are updated and double underscore
> prefix is removed from the function's name because such prefixes are
> reserved to a compiler.
> 
> Signed-off-by: Sergey Dyasli 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v3 1/4] x86/vmx: introduce vmwrite_safe()

[Tian, Kevin]

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Wednesday, February 08, 2017 6:10 PM
> 
> Any fail during the original __vmwrite() leads to BUG() which can be
> easily exploited from a guest in the nested vmx mode.
> 
> The new function returns error code depending on the outcome:
> 
>   VMsucceed: 0
> VMfailValid: VM Instruction Error Number
>   VMfailInvalid: a new VMX_INSN_FAIL_INVALID
> 
> A new macro GAS_VMX_OP is introduced in order to improve the
> readability of asm.  Existing ASM_FLAG_OUT macro is reused and copied
> into asm_defns.h
> 
> Signed-off-by: Sergey Dyasli 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

[Stefano Stabellini]

On Wed, 8 Feb 2017, Bhupinder Thakur wrote:
> Hi Julien,
> 
> On 3 February 2017 at 19:38, Julien Grall  wrote:
> > So if I understand correctly, you don't receive anymore output. Correct?
> > Have you tried to see whether the pl011 driver is receiving interrupt or
> > even Linux calling it.
> 
> The pl011 driver is not receiving the interrupts (I put a
> HYPERVISOR_console_io() call inside the interrupt handler and I do not
> see the print on the xen console) . When the console is in this state,
> if I keep typing the characters on the console then Xen keeps raising
> the interrupts (for each character typed) but all those interrupts are
> marked as inflight. So it seems that interrupt is not getting cleared
> in GIC. Which GIC function can I look at to further debug what is the
> issue?
> 
> Earlier, when I used to manually write characters to /dev/ttyAMA0 then
> I used to receive the interrupts all fine.

DomU doesn't get emulated PL011 interrupts from Xen? Make sure you don't
mark the interrupt as a real hardware interrupt by mistake
(GICH_V2_LR_HW). At the same time, check that the virtual PL011
interrupt has been added correctly to the LRs
(xen/arch/arm/gic-v2.c:gicv2_update_lr).

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Julien Grall]

On 08/02/2017 23:28, Tamas K Lengyel wrote:

On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  wrote:

Hi Tamas,

Can you please try to configure your e-mail client to use '>' rather than '
'? It makes quite hard to read the e-mail.


Hm, not sure why it switched but should be fine now.


On 08/02/2017 20:15, Tamas K Lengyel wrote:




On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
> wrote:
On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:




If platform_hvc() consumes an SMC, it's considered part of the Xen
API.
Visible but not filterable by a monitor.


Platforms can then dictate which SMC calls are better handled within
Xen and
which ones can be exposed to dom0 user-space.

In addition, there could be a hypercall to disable platform specific
handling
in Xen alltogether for a given guest. Then everything goes to dom0
user-space.

It's a little messy...



That is messy and I would not want any SMCs reaching the firmware when
the monitor application is in use. The monitor interface is disabled by
default and there aren't any known usecases where the SMC has to reach
both the firmware and the monitor application as well. So I think it is
safe to just make the two things mutually exclusive.



If you look at the SMC Calling Convention [1] both HVC and SMC are
considered a conduit for service call to the secure firmware or hypervisor.
It would be up to the hypervisor deciding what to do.

Lets imagine the guest is deciding to use HVC to access the secure firmware
(AFAIU this patch series is adding that), are you going to monitor all the
HVCs (including hypercall)?


There are some fundamental differences between HVC and SMC calls
though. An HVC can only land in the hypervisor, so as a hypercall, I
would expect it to be something I can deny via XSM. That is a
sufficient option for now to block the path to the firmware. If we end
up needing to support an application that uses that hypercall for
something critical, then yes, it would also need to be hooked into the
monitor system. At the moment this is not necessary.


My point is not about what is necessary at the moment. But what is right 
things to do. If you look at the spec, HVC are not only for hypercall, 
but any other kind of services. Why would you deny something that is 
valid from the specification (see 5.2.1)?


"The SMC calling convention, however, does not specify which instruction 
(either SMC or HVC) to use to invoke a

particular service."



So if we are landing in do_trap_smc from an HVC call, I think it would
be better to introduce a separate function for it rather then just
bunching the two together here.



Similarly, non-modified baremetal app could use SMC to power on/off the vCPU
(see PSCI spec). Will you emulate that in the monitor app?


Yes, the underlying setup requires that everything that is expected
from the firmware to be performed either by the monitor app, or have
the monitor app further delegate it somewhere that can perform the
task. That can be either the firmware itself (if its safe), or an
isolated VM if it is possible to perform the task there. I wouldn't
call this emulation necessarily btw.


You haven't understood my point. Xen is currently emulating PSCI call 
for the guest to allow powering up and down the CPUs and other stuff. If 
you decide to trap all the SMCs, you would have to handle them.


And yes it is emulation as you don't seem to be willing passing those 
SMC to the firmware or even back to Xen. If we expect a VM to emulate a 
trusted firmware, then you have a security problem. Some hardware may be 
only accessible through the secure world and I doubt some trusted app 
vendor will be willing to move cryptography stuff in non secure world. I 
would highly recommend to skim through the OP-TEE thread, it will 
provide you some insights of the constraints.


Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 105650: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   5 xen-buildfail REGR. vs. 105642

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  04dbb71096143b54f8b5e1acfce8d55150609d3f
baseline version:
 xen  58b4db0832de1ee355a342feea7e1545219bef12

Last test of basis   105642  2017-02-08 16:04:21 Z0 days
Testing same since   105644  2017-02-08 18:01:23 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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


Not pushing.


commit 04dbb71096143b54f8b5e1acfce8d55150609d3f
Author: Andrew Cooper 
Date:   Tue Feb 7 14:01:29 2017 +

x86/p2m: Stop other vcpus using a nested p2m before clearing it

Until the IPI has completed, other processors might be running on this 
nested
p2m object.  clear_domain_page() does not guarantee to make 8-byte atomic
updates, which means that a pagewalk on a remote processor might encounter a
partial update.

This is currently safe as other issues prevents a nested p2m ever being 
shared
between two cpus (although this is contrary to the original plan).

Setting p2m->np2m_base to P2M_BASE_EADDR before the IPI ensures that the 
IPI'd
processors won't continue to use the flushed mappings.

While modifying this function, remove all the trailing whitespace and tweak
style in the affected areas.

Signed-off-by: Andrew Cooper 
Reviewed-by: Tim Deegan 
Reviewed-by: Jan Beulich 

commit 11c397c207dda26084be8a5da5bd78c74b4b3651
Author: Andrew Cooper 
Date:   Wed Dec 7 13:52:02 2016 +

x86/time: Adjust init-time handling of pit0_ticks

There is no need for the volatile cast in the timer interrupt; the compiler
may not elide the update.  This reduces the generated assembly from a read,
local modify, write to a single add instruction.

Drop the memory barriers from timer_irq_works(), as they are not needed.
pit0_ticks is only modified by timer_interrupt() running on the same CPU, so
all that is required is a volatile reference to prevent the compiler from
eliding the second read.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH] xen/arm: Fix ARM build following c/s 11c397c

[Stefano Stabellini]

On Wed, 8 Feb 2017, Andrew Cooper wrote:
> On 08/02/2017 19:24, Julien Grall wrote:
> >
> >
> > On 08/02/17 19:21, Andrew Cooper wrote:
> >> On 08/02/17 19:13, Julien Grall wrote:
> >>> Hi Andrew,
> >>>
> >>> On 08/02/17 19:10, Andrew Cooper wrote:
>  c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE()
>  which is
>  different to the definiton in smmu.c
> >
> > Forgot this one s/definiton/definition/
> >
> 
>  The SMMU code included a scalar typecheck, which is worth keeping
>  in the
>  common case, given ACCESS_ONCE()'s restrictions.  However, express the
>  typecheck differently so as to avoid Coverity compliants about unused
> >>>
> >>> s/compliants/complaint/
> >>
> >> In this case, it is multiple individual complains about unused
> >> individual variables, so "complaints" is scans perfectly well.
> >>
> >> An alternative would be "to avoid Coverity complaining about..." if you
> >> prefer?
> >
> > Sorry I was flagging the typo "i" and "a" inverted and not the plural.
> 
> Ah, sorry.  I hadn't even spotted that.
> 
> Will fix both.
>

I fixed the commit message and applied.

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

Re: [Xen-devel] [PATCH] xen/arm64: Don't zero BSS when booting using EFI

[Stefano Stabellini]

On Wed, 8 Feb 2017, Julien Grall wrote:
> Commit 146786b "efi: create efi_enabled()" introduced a variable
> efi_flags stored in BSS and used to pass information between the stub
> and Xen. However on ARM, BSS is zeroed after the stub has finished to
> run and before Xen is started. This means that the bits set in efi_flags
> will be lost.
> 
> We were not affected before because all the variables used to pass
> information between Xen and the stub are living in initdata or data.
> 
> Looking at the description of the field SizeOfRawData in the PE/COFF
> header (see [1]):
> 
> "If this is less than VirtualSize, the remainder of the section is
> zero-filled. Because the SizeOfRawData field is rounded but the
> VirtualSize field is not, it is possible for SizeOfRawData to be greater
> than VirtualSize as well. When a section contains only uninitialized
> data, this field should be zero."
> 
> Both VirtualSize and SizeOfRawData are correctly set in the header (see
> arch/arm/arm64/head.S) so the EFI firmware will zero BSS for us.
> 
> Therefore we don't need to zero BSS before running the EFI stub and can
> skip the one between the EFI stub and Xen.
> 
> To avoid another branch instruction, slightly refactor the code. The
> register x26 is allocated to hold whether BSS is skipped. The value will
> be:
> - 0 when the code is running on CPU0 and EFI is not used
> - 1 when EFI is used or running on other processor than the boot one.
> 
> [1] 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
> CC: Jan Beulich 
> CC: Daniel Kiper 
> CC: Andrew Cooper 
> 
> This patch fix ACPI boot on Xen ARM. Without it Xen thinks it is not
> running on EFI and will not try to find the RDSP.
> 
> I did not put the reviewed-by/acked-by tag as there was some request
> to clarify the comments.
> 
> Changes in v2:
> - Update comment in the code
> ---
>  xen/arch/arm/arm64/head.S | 23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 3f63d2a..3a54356 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -65,7 +65,7 @@
>   *  x23 - UART address
>   *  x24 - cpuid
>   *  x25 - identity map in place
> - *  x26 -
> + *  x26 - skip_zero_bss
>   *  x27 -
>   *  x28 -
>   *  x29 -
> @@ -232,6 +232,10 @@ section_table:
>  .long   0xe0500020   /* Characteristics (section flags) */
>  .align  5
>  real_start:
> +/* BSS should be zeroed when booting without EFI */
> +mov   x26, #0/* x26 := skip_zero_bss */
> +
> +real_start_efi:
>  msr   DAIFSet, 0xf   /* Disable all interrupts */
>  
>  /* Save the bootloader arguments in less-clobberable registers */
> @@ -261,6 +265,8 @@ GLOBAL(init_secondary)
>  sub   x20, x19, x0   /* x20 := phys-offset */
>  
>  mov   x22, #1/* x22 := is_secondary_cpu */
> +/* Boot CPU already zero BSS so skip it on secondary CPUs. */
> +mov   x26, #1/* X26 := skip_zero_bss */
>  
>  common_start:
>  mov   x24, #0/* x24 := CPU ID. Initialy zero until we
> @@ -314,8 +320,8 @@ common_start:
>  
>  el2:PRINT("- Xen starting at EL2 -\r\n")
>  
> -/* Zero BSS On the boot CPU to avoid nasty surprises */
> -cbnz  x22, skip_bss
> +/* Zero BSS only when requested */
> +cbnz  x26, skip_bss
>  
>  PRINT("- Zero BSS -\r\n")
>  ldr   x0, =__bss_start   /* Load start & end of bss */
> @@ -787,7 +793,16 @@ ENTRY(efi_xen_start)
>  mov   x1, xzr
>  mov   x2, xzr
>  mov   x3, xzr
> -b real_start
> +/*
> + * The EFI stub and Xen may share some information living in
> + * BSS. Don't zero BSS to avoid loosing them.
> + *
> + * Note that the EFI firmware has already zeroed BSS for us
> + * before jump into the stub.
> + */
> +mov   x26, #1   /* x26 := skip_zero_bss */
> +
> +b real_start_efi
>  ENDPROC(efi_xen_start)
>  
>  /*
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  wrote:
> Hi Tamas,
>
> Can you please try to configure your e-mail client to use '>' rather than '
> '? It makes quite hard to read the e-mail.

Hm, not sure why it switched but should be fine now.

> On 08/02/2017 20:15, Tamas K Lengyel wrote:
>>
>>
>>
>> On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
>> > wrote:
>> On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
>
>
>> If platform_hvc() consumes an SMC, it's considered part of the Xen
>> API.
>> Visible but not filterable by a monitor.
>>
>>
>> Platforms can then dictate which SMC calls are better handled within
>> Xen and
>> which ones can be exposed to dom0 user-space.
>>
>> In addition, there could be a hypercall to disable platform specific
>> handling
>> in Xen alltogether for a given guest. Then everything goes to dom0
>> user-space.
>>
>> It's a little messy...
>>
>>
>>
>> That is messy and I would not want any SMCs reaching the firmware when
>> the monitor application is in use. The monitor interface is disabled by
>> default and there aren't any known usecases where the SMC has to reach
>> both the firmware and the monitor application as well. So I think it is
>> safe to just make the two things mutually exclusive.
>
>
> If you look at the SMC Calling Convention [1] both HVC and SMC are
> considered a conduit for service call to the secure firmware or hypervisor.
> It would be up to the hypervisor deciding what to do.
>
> Lets imagine the guest is deciding to use HVC to access the secure firmware
> (AFAIU this patch series is adding that), are you going to monitor all the
> HVCs (including hypercall)?

There are some fundamental differences between HVC and SMC calls
though. An HVC can only land in the hypervisor, so as a hypercall, I
would expect it to be something I can deny via XSM. That is a
sufficient option for now to block the path to the firmware. If we end
up needing to support an application that uses that hypercall for
something critical, then yes, it would also need to be hooked into the
monitor system. At the moment this is not necessary.

So if we are landing in do_trap_smc from an HVC call, I think it would
be better to introduce a separate function for it rather then just
bunching the two together here.

>
> Similarly, non-modified baremetal app could use SMC to power on/off the vCPU
> (see PSCI spec). Will you emulate that in the monitor app?

Yes, the underlying setup requires that everything that is expected
from the firmware to be performed either by the monitor app, or have
the monitor app further delegate it somewhere that can perform the
task. That can be either the firmware itself (if its safe), or an
isolated VM if it is possible to perform the task there. I wouldn't
call this emulation necessarily btw.

Tamas

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

[Xen-devel] [linux-3.18 baseline-only test] 68537: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68537 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68537/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
68474

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail REGR. vs. 68474
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 68474
 test-amd64-amd64-xl-rtds 11 guest-start  fail blocked in 68474
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) fail blocked in 
68474
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 68474
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 68474
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 68474
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68474

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux53752ea210016b548cfc3898e6a5ea338fcb6c2c
baseline version:
 linux8433e5c9c8304b750c519ce3e0940dab675f6573

Last test of basis68474  2017-01-25 03:27:52 Z   14 days
Testing same since68537  2017-02-08 15:20:08 Z0 days1 attempts


People who touched 

[Xen-devel] [xen-unstable-smoke test] 105647: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   5 xen-buildfail REGR. vs. 105642

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  04dbb71096143b54f8b5e1acfce8d55150609d3f
baseline version:
 xen  58b4db0832de1ee355a342feea7e1545219bef12

Last test of basis   105642  2017-02-08 16:04:21 Z0 days
Testing same since   105644  2017-02-08 18:01:23 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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


Not pushing.


commit 04dbb71096143b54f8b5e1acfce8d55150609d3f
Author: Andrew Cooper 
Date:   Tue Feb 7 14:01:29 2017 +

x86/p2m: Stop other vcpus using a nested p2m before clearing it

Until the IPI has completed, other processors might be running on this 
nested
p2m object.  clear_domain_page() does not guarantee to make 8-byte atomic
updates, which means that a pagewalk on a remote processor might encounter a
partial update.

This is currently safe as other issues prevents a nested p2m ever being 
shared
between two cpus (although this is contrary to the original plan).

Setting p2m->np2m_base to P2M_BASE_EADDR before the IPI ensures that the 
IPI'd
processors won't continue to use the flushed mappings.

While modifying this function, remove all the trailing whitespace and tweak
style in the affected areas.

Signed-off-by: Andrew Cooper 
Reviewed-by: Tim Deegan 
Reviewed-by: Jan Beulich 

commit 11c397c207dda26084be8a5da5bd78c74b4b3651
Author: Andrew Cooper 
Date:   Wed Dec 7 13:52:02 2016 +

x86/time: Adjust init-time handling of pit0_ticks

There is no need for the volatile cast in the timer interrupt; the compiler
may not elide the update.  This reduces the generated assembly from a read,
local modify, write to a single add instruction.

Drop the memory barriers from timer_irq_works(), as they are not needed.
pit0_ticks is only modified by timer_interrupt() running on the same CPU, so
all that is required is a volatile reference to prevent the compiler from
eliding the second read.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
(qemu changes not included)

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

[Xen-devel] [ovmf baseline-only test] 68538: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68538 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68538/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf cc20411062137e5d820a33db73d41f97dae74368
baseline version:
 ovmf d03c056b2946cc2f83b6d206297915dadc08f230

Last test of basis68535  2017-02-08 07:47:26 Z0 days
Testing same since68538  2017-02-08 15:21:15 Z0 days1 attempts


People who touched revisions under test:
  Liming Gao 
  lushifex 
  Rebecca Cran 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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.


commit cc20411062137e5d820a33db73d41f97dae74368
Author: lushifex 
Date:   Wed Feb 8 10:42:35 2017 +0800

Vlv2DeviceRefCodePkg: Fixed thermal issue.

Fixed System auto shutdown when it reached minus 20 degree.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lushifex 
Reviewed-by: David Wei 

commit c6de4b9611e260d6147cea073183d9339e9b7c3e
Author: Liming Gao 
Date:   Wed Feb 8 14:49:21 2017 +0800

EdkCompatibilityPkg: Fix some typos of "according"

Cc: Feng Tian 
Cc: Star Zeng 
Cc: Siyuan Fu 
Cc: Jiaxin Wu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Rebecca Cran 
Reviewed-by: Liming Gao 
Reviewed-by: Star Zeng 
Reviewed-by: Feng Tian 
Reviewed-by: He Junjie 
Reviewed-by: Fu Siyuan 
Reviewed-by: Wu Jiaxin 

commit b0206b16177ec1a08a600c404dc6870ddba58e4c
Author: Liming Gao 
Date:   Wed Feb 8 14:48:44 2017 +0800

NetworkPkg: Fix some typos of "according"

Cc: Feng Tian 
Cc: Star Zeng 
Cc: Siyuan Fu 
Cc: Jiaxin Wu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Rebecca Cran 
Reviewed-by: Liming Gao 
Reviewed-by: Star Zeng 
Reviewed-by: Feng Tian 
Reviewed-by: He Junjie 
Reviewed-by: Fu Siyuan 
Reviewed-by: Wu Jiaxin 

commit 24648548886af2563f7a0c2f42da18bb89e40b2d
Author: Liming Gao 
Date:   Wed Feb 8 14:48:02 2017 +0800

MdeModulePkg: Fix some typos of "according"

Cc: Feng Tian 
Cc: Star Zeng 
Cc: Siyuan Fu 
Cc: Jiaxin Wu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Rebecca Cran 
Reviewed-by: Liming Gao 
Reviewed-by: Star Zeng 
Reviewed-by: Feng Tian 
Reviewed-by: He Junjie 
Reviewed-by: Fu Siyuan 
Reviewed-by: Wu Jiaxin 

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

Re: [Xen-devel] [libvirt] [PATCH 2/2] libxl: fix dom0 maximum memory setting

[Jim Fehlig]

Joao Martins wrote:
> On 02/08/2017 04:06 PM, Jim Fehlig wrote:
>> Joao Martins wrote:
>>> On 02/02/2017 10:31 PM, Jim Fehlig wrote:
 When the libxl driver is initialized, it creates a virDomainDef
 object for dom0 and adds it to the list of domains. Total memory
 for dom0 was being set from the max_memkb field of libxl_dominfo
 struct retrieved from libxl, but this field can be set to
 LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum memory has not been
 explicitly set by the user.

 This patch adds some simple parsing of the Xen commandline,
 looking for a dom0_mem parameter that also specifies a 'max' value.
 If not specified, dom0 maximum memory is effectively all physical
 host memory.

 Signed-off-by: Jim Fehlig 
 ---
  src/libxl/libxl_conf.c   | 75 
 
  src/libxl/libxl_conf.h   |  3 ++
  src/libxl/libxl_driver.c |  2 +-
  3 files changed, 79 insertions(+), 1 deletion(-)

 diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
 index b5186f2..bfe0e92 100644
 --- a/src/libxl/libxl_conf.c
 +++ b/src/libxl/libxl_conf.c
 @@ -34,6 +34,7 @@
  #include "internal.h"
  #include "virlog.h"
  #include "virerror.h"
 +#include "c-ctype.h"
  #include "datatypes.h"
  #include "virconf.h"
  #include "virfile.h"
 @@ -1530,6 +1531,80 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr 
 cfg,
  
  }
  
 +/*
 + * dom0's maximum memory can be controled by the user with the 'dom0_mem' 
 Xen
 + * command line parameter. E.g. to set dom0's initial memory to 4G and max
 + * memory to 8G: dom0_mem=4G,max:8G
 + *
 + * If not constrained by the user, dom0 can effectively use all host 
 memory.
 + * This function returns the configured maximum memory for dom0 in 
 kilobytes,
 + * either the user-specified value or total physical memory as a default.
 + */
 +unsigned long long
 +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg)
 +{
 +char **cmd_tokens = NULL;
 +char **mem_tokens = NULL;
 +size_t i;
 +size_t j;
 +unsigned long long ret;
 +libxl_physinfo physinfo;
 +
 +if (cfg->verInfo->commandline == NULL ||
 +!(cmd_tokens = virStringSplit(cfg->verInfo->commandline, " ", 0)))
 +goto physmem;
 +
 +for (i = 0; cmd_tokens[i] != NULL; i++) {
 +if (!STRPREFIX(cmd_tokens[i], "dom0_mem="))
 +continue;
 +
 +if (!(mem_tokens = virStringSplit(cmd_tokens[i], ",", 0)))
 +break;
 +for (j = 0; mem_tokens[j] != NULL; j++) {
 +if (STRPREFIX(mem_tokens[j], "max:")) {
 +char *p = mem_tokens[j] + 4;
 +unsigned long long multiplier = 1;
 +
 +while (c_isdigit(*p))
 +p++;
 +if (virStrToLong_ull(mem_tokens[j] + 4, , 10, ) < 0)
 +break;
 +if (*p) {
 +switch (*p) {
 +case 'k':
 +case 'K':
 +multiplier = 1024;
 +break;
 +case 'm':
 +case 'M':
 +multiplier = 1024 * 1024;
 +break;
 +case 'g':
 +case 'G':
 +multiplier = 1024 * 1024 * 1024;
 +break;
 +}
 +}
 +ret = (ret * multiplier) / 1024;
 +goto cleanup;
 +}
 +}
 +}
 +
 + physmem:
 +/* No 'max' specified in dom0_mem, so dom0 can use all physical 
 memory */
 +libxl_physinfo_init();
 +libxl_get_physinfo(cfg->ctx, );
>>> Despite being an unlikely event, libxl_get_physinfo can fail here - I think 
>>> you
>>> need to check the return value here.
>> Bummer. I was hoping this function could always return a sane value for dom0 
>> max
>> memory. But I'm not really sure what that would be if libxl_get_physinfo 
>> failed.
>>
> Yeah, We probably have some serious concerns if this fails. And given that
> libxlAddDom0 happens early while bootstrapping the libxl module, it might be
> good to warn the user (following similar pattern throughout the rest of the 
> code):
> 
> virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
>_("libxl_get_physinfo_info failed"));
> 
> or perhaps simply VIR_WARN?
> 
 +ret = (physinfo.total_pages * cfg->verInfo->pagesize) / 1024;
 +libxl_physinfo_dispose();
 +
 + cleanup:
 +virStringListFree(cmd_tokens);
 +virStringListFree(mem_tokens);
 +

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Julien Grall]

Hi Tamas,

Can you please try to configure your e-mail client to use '>' rather 
than ''? It makes quite hard to read the e-mail.


On 08/02/2017 20:15, Tamas K Lengyel wrote:



On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
> wrote:
On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:



If platform_hvc() consumes an SMC, it's considered part of the Xen API.
Visible but not filterable by a monitor.


Platforms can then dictate which SMC calls are better handled within
Xen and
which ones can be exposed to dom0 user-space.

In addition, there could be a hypercall to disable platform specific
handling
in Xen alltogether for a given guest. Then everything goes to dom0
user-space.

It's a little messy...



That is messy and I would not want any SMCs reaching the firmware when
the monitor application is in use. The monitor interface is disabled by
default and there aren't any known usecases where the SMC has to reach
both the firmware and the monitor application as well. So I think it is
safe to just make the two things mutually exclusive.


If you look at the SMC Calling Convention [1] both HVC and SMC are 
considered a conduit for service call to the secure firmware or 
hypervisor. It would be up to the hypervisor deciding what to do.


Lets imagine the guest is deciding to use HVC to access the secure 
firmware (AFAIU this patch series is adding that), are you going to 
monitor all the HVCs (including hypercall)?


Similarly, non-modified baremetal app could use SMC to power on/off the 
vCPU (see PSCI spec). Will you emulate that in the monitor app?


So I think we need to be consistent across HVC and SMC call. And 
mutually exclusive does not sound right to me for HVC.


Cheers,

[1] 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028b/index.html



--
Julien Grall

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

[Xen-devel] [xen-unstable test] 105640: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 105629
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 105629

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 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-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  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  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-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
 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-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  93a3fbaf16f4b66c7866f42c2699c7af636f2933
baseline version:
 xen  63e1d01b8fd948b3e0fa3beea494e407668aa43b

Last test of basis   105629  2017-02-08 06:54:04 Z0 days
Testing same since   105640  2017-02-08 14:19:37 Z0 days1 attempts


People who touched revisions under test:
  Baptiste Daroussin 
  Fatih Acar 
  Nikita Kozlov 
  Vincent Legout 
  Wei Liu 

Re: [Xen-devel] [PATCH v2] xen/p2m: Fix p2m_flush_table for non-nested cases

[Tamas Lengyel]

On Wed, Feb 8, 2017 at 11:12 AM, George Dunlap 
wrote:

> On 08/02/17 17:29, Tim Deegan wrote:
> > At 17:22 + on 08 Feb (1486574546), George Dunlap wrote:
> >> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
> >> nested p2m tables whenever the host p2m table changed.  Unfortunately
> >> in the process, it added a filter to p2m_flush_table() function so
> >> that the p2m would only be flushed if it was being used as a nested
> >> p2m.  This meant that the p2m was not being flushed at all for altp2m
> >> callers.
> >>
> >> Only check np2m_base if p2m_class is set to p2m_nested.
> >>
> >> NB that this is not a security issue: The only time this codepath is
> >> called is in cases where either nestedp2m or altp2m is enabled, and
> >> neither of them are in security support.
> >>
> >> Reported-by: Matt Leinhos 
> >> Signed-off-by: George Dunlap 
> >> CC: Tamas K Lengyel 
> >> ---
> >>  xen/arch/x86/mm/p2m.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> >> index 6548e9f..0af2ec1 100644
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -1627,7 +1627,9 @@ p2m_flush_table(struct p2m_domain *p2m)
> >>  ASSERT(page_list_empty(>pod.super));
> >>  ASSERT(page_list_empty(>pod.single));
> >>
> >> -if ( p2m->np2m_base == P2M_BASE_EADDR )
> >> +/* No need to flush if it's already empty */
> >> +if ( p2m->p2m_class == p2m_nested &&
> >> + p2m->np2m_base == P2M_BASE_EADDR )
> >
> > Looks like p2m_is_nestedp2m(p2m) is the usual idiom.  Either way:
> >
> > Reviewed-by: Tim Deegan 
>
> Right -- I'll change it to the usual idiom and check it in after I've
> gotten a test report (or waited a reasonable amount of time).


Tested-by: Tamas K Lengyel 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 105645: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   5 xen-buildfail REGR. vs. 105642

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  04dbb71096143b54f8b5e1acfce8d55150609d3f
baseline version:
 xen  58b4db0832de1ee355a342feea7e1545219bef12

Last test of basis   105642  2017-02-08 16:04:21 Z0 days
Testing same since   105644  2017-02-08 18:01:23 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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


Not pushing.


commit 04dbb71096143b54f8b5e1acfce8d55150609d3f
Author: Andrew Cooper 
Date:   Tue Feb 7 14:01:29 2017 +

x86/p2m: Stop other vcpus using a nested p2m before clearing it

Until the IPI has completed, other processors might be running on this 
nested
p2m object.  clear_domain_page() does not guarantee to make 8-byte atomic
updates, which means that a pagewalk on a remote processor might encounter a
partial update.

This is currently safe as other issues prevents a nested p2m ever being 
shared
between two cpus (although this is contrary to the original plan).

Setting p2m->np2m_base to P2M_BASE_EADDR before the IPI ensures that the 
IPI'd
processors won't continue to use the flushed mappings.

While modifying this function, remove all the trailing whitespace and tweak
style in the affected areas.

Signed-off-by: Andrew Cooper 
Reviewed-by: Tim Deegan 
Reviewed-by: Jan Beulich 

commit 11c397c207dda26084be8a5da5bd78c74b4b3651
Author: Andrew Cooper 
Date:   Wed Dec 7 13:52:02 2016 +

x86/time: Adjust init-time handling of pit0_ticks

There is no need for the volatile cast in the timer interrupt; the compiler
may not elide the update.  This reduces the generated assembly from a read,
local modify, write to a single add instruction.

Drop the memory barriers from timer_irq_works(), as they are not needed.
pit0_ticks is only modified by timer_interrupt() running on the same CPU, so
all that is required is a volatile reference to prevent the compiler from
eliding the second read.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH 1/2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

[Waiman Long]

On 02/08/2017 02:05 PM, Peter Zijlstra wrote:
> On Wed, Feb 08, 2017 at 01:00:24PM -0500, Waiman Long wrote:
>> It was found when running fio sequential write test with a XFS ramdisk
>> on a 2-socket x86-64 system, the %CPU times as reported by perf were
>> as follows:
>>
>>  71.27%  0.28%  fio  [k] down_write
>>  70.99%  0.01%  fio  [k] call_rwsem_down_write_failed
>>  69.43%  1.18%  fio  [k] rwsem_down_write_failed
>>  65.51% 54.57%  fio  [k] osq_lock
>>   9.72%  7.99%  fio  [k] __raw_callee_save___kvm_vcpu_is_preempted
>>   4.16%  4.16%  fio  [k] __kvm_vcpu_is_preempted
>>
>> So making vcpu_is_preempted() a callee-save function has a pretty high
>> cost associated with it. As vcpu_is_preempted() is called within the
>> spinlock, mutex and rwsem slowpaths, there isn't much to gain by making
>> it callee-save. So it is now changed to a normal function call instead.
>>
> Numbers for bare metal too please.

I will run the test on bare metal, but I doubt there will be noticeable
difference.

Cheers,
Longman


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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias  wrote:

> On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
> > On Wed, Feb 08, 2017 at 04:58:44PM +, Julien Grall wrote:
> > > Hi Tamas,
> > >
> > > On 08/02/17 16:40, Tamas K Lengyel wrote:
> > > >On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
> > > >> wrote:
> > > >On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
> > > >> On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall <
> julien.gr...@arm.com
> > > >> wrote:
> > > >I considered this approach a bit but it has several problems IMO.
> > > >These may not be unsolvable or even problems for monitoring but
> > > >they do introduce complexity into the solution.
> > > >
> > > >1. Some SMC calls may depend on the core they are issued from.
> > > >   If taking a detour to dom0, this becomes messy to guarantee.
> > > >
> > > >2. Overall complexity increases very significantly and it becomes
> > > >   quite hard to follow/review how these calls get handled.
> > > >   In particular once you consider solving #1.
> > > >
> > > >3. There are certain calls that perhaps not even dom0 should have
> > > >   direct access to. This means that Xen may need to filter some
> of
> > > >   them anyway.
> > > >
> > > >Some examples may be:
> > > >
> > > >SMC calls:
> > > >* To directly turn off or suspend cores
> > > >* To turn off DDR or RAMs that Xen is using
> > > >* To a solution specific Trusted OS pinned to a specific core
> > > >* For PSCI
> > > >* Etc
> > > >
> > > >I would prefer if we could find a way for monitoring to play
> nicely
> > > >with Xen implementing the SMC mediators.
> > > >Perhaps we could allow calls that Xen consumes to be
> monitored/inspected
> > > >but not modified. Or there might be other ways.
> > > >
> > > >Best regards,
> > > >Edgar
> > > >
> > > >
> > > >Hi Edgar,
> > > >certainly there are many cases where the system would become very
> > > >complex when there is functionality like what you describe in the TZ
> > > >that needs to be made accessible via SMC. The setup I described is
> > > >experimental only, and the underlying assumption is that the TZ is
> > > >working jointly with the monitor application (ie. both are aware of
> each
> > > >other). So it is really not intended to work with just any firmware.
> > >
> > > How do you expect TrustZone to work with the monitor application? If
> you
> > > think about modifying Trustzone, it seems a requirement difficult to
> achieve
> > > as some Trusted OS are proprietary or difficult to replace on a phone.
> > >
> > > >
> > > >So I think for the sake of reducing complexity, having the monitor
> > > >system be exclusive when enabled should make everyone's life simpler.
> > > >Having a passive monitoring mode as you suggest is certainly an
> option,
> > > >although it should not be the only option, exclusive routing of SMCs
> > > >through monitor applications should still be available to be
> configured
> > > >by the user. Since I really don't know of any usecases where passive
> > > >monitoring of SMCs is required, I don't think we should go that route.
> > >
> > > I see the SMC trap similar to a register trap. The monitor app will
> look at
> > > the register value and potentially modify it. What would be the issue
> to do
> > > the same for SMC?
> >
> > Yes, I think this would work if we can keep the SMC processing on the
> same
> > core (after it's been accepted by monitor filters). If not accepted by
> > filters, we'd just ignore the SMC processing and return registers
> provided
> > by the monitor (or something along those lines).
> >
> >
> > > I think a such model would fit the requirement for everyone. The
> monitor app
> > > can filter if necessary, and Xen would handle the mediation between
> multiple
>
> Any ideas on how we can support monitor filtering while at the same time
> having Xen processing calls? How do we wait for a response from the monitor
> and then (if allowed) issue the SMC from the right core?
>

There is a return path from the monitor application when the monitor
request has been processed. See
http://xenbits.xenproject.org/gitweb/?p=xen.git;a=blob;f=xen/common/vm_event.c;h=82ce8f1561384f6059c5ea152e3b0a55e63094a8;hb=HEAD#l402.
We can do a call-down to an ARM specific handler that would then issue the
SMC to the firmware if the monitor app specified that it is OK to do so. It
is relatively easily to implement but I don't think it's a feature that
anyone needs at the moment.


>
> Or we could make these approaches mutually exclusive.
>

That is what I would like to see.


> If platform_hvc() consumes an SMC, it's considered part of the Xen API.
> Visible but not filterable by a monitor.
>

> Platforms can then dictate which SMC calls are better handled within Xen
> 

Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt

[Julien Grall]

Hi,

On 24/01/17 22:19, David Scott wrote:
> 
>> On 24 Jan 2017, at 11:35, Ian Jackson  wrote:
>>
>> Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no 
>> ocamlopt"):
>>> Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
>>> package lacks ocamlopt.
>> ...
>>> This does not actually fix the real problem.  I'm unsure how to fix it
>>> properly, for the following reasons:
>>
>> Can I have some input from ocaml folks ?
>>
>> The first ARM64 boxes in the Xen Project test lab are in principle now
>> online, but this bug is stopping osstest actually getting as far as
>> trying to boot Xen.
>>
>>> ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
>>> `ocamlc'.  However our ocaml Makefiles seem to explicitly call
>>> $(OCAMLOPT) in some places and and $(OCAMLC) in others.
> 
> I’m terrible at reading m4 and am really bad with autoconf so I may have
> got this wrong but does it set OCAMLC to `ocamlopt` or `ocamlc.opt`? Where
> 
> `ocamlc`: outputs bytecode, and is a bytecode executable itself
> `ocamlc.opt`: outputs bytecode, and is a native code executable itself
> `ocamlopt`: outputs native code, and is a bytecode executable itself
> `ocamlopt.opt`: outputs native code, and is a native code executable itself
> 
> Both `ocamlc` and `ocamlc.opt` should be interchangeable: same command-line
> arguments, exactly the same output. Same for `ocamlopt` and `ocamlopt.opt`.
> 
> I _think_ the m4 is looking for `ocamlc.opt` because it’s an optimised native
> (therefore faster) version of `ocamlc`. It should be fine to set `OCAMLC`
> to either.
> 
> The tools/ocaml/Makefile.rules does contain rules for both bytecode outputs
> (e.g. *.cmo *.cma) and native code outputs (*.cmx *.cmxa). I believe *.cmi
> can be created by either ocamlc (ocamlc.opt) or ocamlopt (ocamlopt.opt).
> 
> I’m a bit suspicious of the tools/ocaml/xenstored/Makefile where it refers
> directly to *.cmxa files which are native-code only— I don’t see how that
> could work for bytecode outputs.
> 
> Do you have a link to the build failure?

Here a link for the build failure:

http://logs.test-lab.xenproject.org/osstest/logs/105644/build-arm64/5.ts-xen-build.log

Cheers,

-- 
Julien Grall

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

Re: [Xen-devel] Xen 4.9 Development Update

[Oleksandr Andrushchenko]

On 02/08/2017 09:29 PM, Julien Grall wrote:

Hi Oleksandr,

On 08/02/17 18:56, Oleksandr Andrushchenko wrote:

On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:

On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:

(CC Konrad)

Hi Oleksandr,

On 31/01/17 13:51, Oleksandr Andrushchenko wrote:

On 01/30/2017 05:33 PM, Julien Grall wrote:

This email only tracks big items for xen.git tree. Please reply for
items you
woulk like to see in 4.9 so that people have an idea what is going
on and
prioritise accordingly.
== PV Drivers ==

*  Xen transport for 9pfs
-  Stefano Stabellini

*  PV calls
-  Stefano Stabellini


Are you considering other PV protocols for this drop? E.g.
multi-touch support, sound and display?

That would be up to you and Konrad :).

I think we only have one left from Oleksandr.

That is correct (namely displif is on my list)

Two of them have been
reviewed by me today.

Anyway, I am going to track any big inflight items even those not
planned
for next release. This will give us an overview of what's going on.

What is the list of PV protocols you have in mind? And do you know
who will
work on it?

Also, I should probably track separately the backend/frontend support
if you
plan to upstream them later.
We do. We only miss the corresponding protocols in the trees (both 
Xen and

the kernel), so we can start updating *existing* backs/fronts/libs for
sndif/displif/DRM zero-copy/multi-touch and get those ready for 
upstreaming


Ok, I will add separate items for the backend/frontend of each PV 
drivers. Shall I put your name under them?
I mostly work on protocol/kernel side, so for the frontends/protocols - 
yes, please
For the backends and backend helper library - Oleksandr Grytsov will be 
the right guy


Cheers,


Thank you

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

Re: [Xen-devel] [PATCH] xen/arm: Fix ARM build following c/s 11c397c

[Andrew Cooper]

On 08/02/2017 19:24, Julien Grall wrote:
>
>
> On 08/02/17 19:21, Andrew Cooper wrote:
>> On 08/02/17 19:13, Julien Grall wrote:
>>> Hi Andrew,
>>>
>>> On 08/02/17 19:10, Andrew Cooper wrote:
 c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE()
 which is
 different to the definiton in smmu.c
>
> Forgot this one s/definiton/definition/
>

 The SMMU code included a scalar typecheck, which is worth keeping
 in the
 common case, given ACCESS_ONCE()'s restrictions.  However, express the
 typecheck differently so as to avoid Coverity compliants about unused
>>>
>>> s/compliants/complaint/
>>
>> In this case, it is multiple individual complains about unused
>> individual variables, so "complaints" is scans perfectly well.
>>
>> An alternative would be "to avoid Coverity complaining about..." if you
>> prefer?
>
> Sorry I was flagging the typo "i" and "a" inverted and not the plural.

Ah, sorry.  I hadn't even spotted that.

Will fix both.

~Andrew

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Edgar E. Iglesias]

On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
> On Wed, Feb 08, 2017 at 04:58:44PM +, Julien Grall wrote:
> > Hi Tamas,
> > 
> > On 08/02/17 16:40, Tamas K Lengyel wrote:
> > >On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
> > >> wrote:
> > >On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
> > >> On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall  > >> wrote:
> > >I considered this approach a bit but it has several problems IMO.
> > >These may not be unsolvable or even problems for monitoring but
> > >they do introduce complexity into the solution.
> > >
> > >1. Some SMC calls may depend on the core they are issued from.
> > >   If taking a detour to dom0, this becomes messy to guarantee.
> > >
> > >2. Overall complexity increases very significantly and it becomes
> > >   quite hard to follow/review how these calls get handled.
> > >   In particular once you consider solving #1.
> > >
> > >3. There are certain calls that perhaps not even dom0 should have
> > >   direct access to. This means that Xen may need to filter some of
> > >   them anyway.
> > >
> > >Some examples may be:
> > >
> > >SMC calls:
> > >* To directly turn off or suspend cores
> > >* To turn off DDR or RAMs that Xen is using
> > >* To a solution specific Trusted OS pinned to a specific core
> > >* For PSCI
> > >* Etc
> > >
> > >I would prefer if we could find a way for monitoring to play nicely
> > >with Xen implementing the SMC mediators.
> > >Perhaps we could allow calls that Xen consumes to be 
> > > monitored/inspected
> > >but not modified. Or there might be other ways.
> > >
> > >Best regards,
> > >Edgar
> > >
> > >
> > >Hi Edgar,
> > >certainly there are many cases where the system would become very
> > >complex when there is functionality like what you describe in the TZ
> > >that needs to be made accessible via SMC. The setup I described is
> > >experimental only, and the underlying assumption is that the TZ is
> > >working jointly with the monitor application (ie. both are aware of each
> > >other). So it is really not intended to work with just any firmware.
> > 
> > How do you expect TrustZone to work with the monitor application? If you
> > think about modifying Trustzone, it seems a requirement difficult to achieve
> > as some Trusted OS are proprietary or difficult to replace on a phone.
> > 
> > >
> > >So I think for the sake of reducing complexity, having the monitor
> > >system be exclusive when enabled should make everyone's life simpler.
> > >Having a passive monitoring mode as you suggest is certainly an option,
> > >although it should not be the only option, exclusive routing of SMCs
> > >through monitor applications should still be available to be configured
> > >by the user. Since I really don't know of any usecases where passive
> > >monitoring of SMCs is required, I don't think we should go that route.
> > 
> > I see the SMC trap similar to a register trap. The monitor app will look at
> > the register value and potentially modify it. What would be the issue to do
> > the same for SMC?
> 
> Yes, I think this would work if we can keep the SMC processing on the same
> core (after it's been accepted by monitor filters). If not accepted by
> filters, we'd just ignore the SMC processing and return registers provided
> by the monitor (or something along those lines).
> 
> 
> > I think a such model would fit the requirement for everyone. The monitor app
> > can filter if necessary, and Xen would handle the mediation between multiple

Any ideas on how we can support monitor filtering while at the same time
having Xen processing calls? How do we wait for a response from the monitor
and then (if allowed) issue the SMC from the right core?

Or we could make these approaches mutually exclusive.
If platform_hvc() consumes an SMC, it's considered part of the Xen API.
Visible but not filterable by a monitor.

Platforms can then dictate which SMC calls are better handled within Xen and
which ones can be exposed to dom0 user-space.

In addition, there could be a hypercall to disable platform specific handling
in Xen alltogether for a given guest. Then everything goes to dom0 user-space.

It's a little messy...


> > guests. I would also recommend to read the thread about OP-TEE support in
> > Xen (see [1]).
> >

BTW, my comment below was regarding the interrupts discussion in the OP-TEE
thread, in case it seemed totally off-topic :-)

> 
> We have a similar issue with interrupts from Firmware. I've not implemented
> this part in this series but at some point I'm going to have to.
> 
> Essentially I'm looking at handling an IPI in Xen and forwarding an SGI or
> a virtual inject of the IPI to the guest that was targeted. Future work...
> 
> Cheers,
> Edgar
> 
> > Cheers,
> > 

Re: [Xen-devel] Xen 4.9 Development Update

[Julien Grall]

Hi Oleksandr,

On 08/02/17 18:56, Oleksandr Andrushchenko wrote:

On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:

On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:

(CC Konrad)

Hi Oleksandr,

On 31/01/17 13:51, Oleksandr Andrushchenko wrote:

On 01/30/2017 05:33 PM, Julien Grall wrote:

This email only tracks big items for xen.git tree. Please reply for
items you
woulk like to see in 4.9 so that people have an idea what is going
on and
prioritise accordingly.
== PV Drivers ==

*  Xen transport for 9pfs
-  Stefano Stabellini

*  PV calls
-  Stefano Stabellini


Are you considering other PV protocols for this drop? E.g.
multi-touch support, sound and display?

That would be up to you and Konrad :).

I think we only have one left from Oleksandr.

That is correct (namely displif is on my list)

Two of them have been
reviewed by me today.

Anyway, I am going to track any big inflight items even those not
planned
for next release. This will give us an overview of what's going on.

What is the list of PV protocols you have in mind? And do you know
who will
work on it?

Also, I should probably track separately the backend/frontend support
if you
plan to upstream them later.

We do. We only miss the corresponding protocols in the trees (both Xen and
the kernel), so we can start updating *existing* backs/fronts/libs for
sndif/displif/DRM zero-copy/multi-touch and get those ready for upstreaming


Ok, I will add separate items for the backend/frontend of each PV 
drivers. Shall I put your name under them?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen 4.9 Development Update

[Julien Grall]

On 08/02/17 18:17, Konrad Rzeszutek Wilk wrote:

On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:

(CC Konrad)

Hi Oleksandr,

On 31/01/17 13:51, Oleksandr Andrushchenko wrote:


On 01/30/2017 05:33 PM, Julien Grall wrote:

This email only tracks big items for xen.git tree. Please reply for
items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.
== PV Drivers ==

*  Xen transport for 9pfs
   -  Stefano Stabellini

*  PV calls
   -  Stefano Stabellini


Are you considering other PV protocols for this drop? E.g.
multi-touch support, sound and display?


That would be up to you and Konrad :).


I think we only have one left from Oleksandr. Two of them have been
reviewed by me today.


2 more cool new features for next release! I will move them in the 
completed category when merged.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: Fix ARM build following c/s 11c397c

[Julien Grall]

On 08/02/17 19:21, Andrew Cooper wrote:

On 08/02/17 19:13, Julien Grall wrote:

Hi Andrew,

On 08/02/17 19:10, Andrew Cooper wrote:

c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE()
which is
different to the definiton in smmu.c


Forgot this one s/definiton/definition/



The SMMU code included a scalar typecheck, which is worth keeping in the
common case, given ACCESS_ONCE()'s restrictions.  However, express the
typecheck differently so as to avoid Coverity compliants about unused


s/compliants/complaint/


In this case, it is multiple individual complains about unused
individual variables, so "complaints" is scans perfectly well.

An alternative would be "to avoid Coverity complaining about..." if you
prefer?


Sorry I was flagging the typo "i" and "a" inverted and not the plural.






variables.


OOI, the variable is marked as "__maybe_unused", so why Coverity would
complaint?


The entire purpose of Coverity is to second guess what the programmer
actually wrote when it looks suspicious.

As for this specific example, I believe that the annotation doesn't even
survive into the GCC Abstract Syntax Tree, which means Coverity doesn't
get to see it.  Even if it does, the complaint of "This variable is
unused - why do you need it?" is still valid.


Oh, thank you for the explanation.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: Fix ARM build following c/s 11c397c

[Andrew Cooper]

On 08/02/17 19:13, Julien Grall wrote:
> Hi Andrew,
>
> On 08/02/17 19:10, Andrew Cooper wrote:
>> c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE()
>> which is
>> different to the definiton in smmu.c
>>
>> The SMMU code included a scalar typecheck, which is worth keeping in the
>> common case, given ACCESS_ONCE()'s restrictions.  However, express the
>> typecheck differently so as to avoid Coverity compliants about unused
>
> s/compliants/complaint/

In this case, it is multiple individual complains about unused
individual variables, so "complaints" is scans perfectly well.

An alternative would be "to avoid Coverity complaining about..." if you
prefer?

>
>> variables.
>
> OOI, the variable is marked as "__maybe_unused", so why Coverity would
> complaint?

The entire purpose of Coverity is to second guess what the programmer
actually wrote when it looks suspicious.

As for this specific example, I believe that the annotation doesn't even
survive into the GCC Abstract Syntax Tree, which means Coverity doesn't
get to see it.  Even if it does, the complaint of "This variable is
unused - why do you need it?" is still valid.

~Andrew

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

Re: [Xen-devel] [DOC v4] Xen transport for 9pfs

[Konrad Rzeszutek Wilk]

> ## Ring Setup
> 
> The shared page has the following layout:
> 
> typedef uint32_t XEN_9PFS_RING_IDX;
> 
> struct xen_9pfs_intf {
>   XEN_9PFS_RING_IDX in_cons, in_prod;
>   uint8_t pad[56];
>   XEN_9PFS_RING_IDX out_cons, out_prod;
> 
>   uint32_t ring_order;
> /* this is an array of (1 << ring_order) elements */
>   grant_ref_t ref[1];
> };
> 
> /* not actually C compliant (ring_order changes from ring to ring) */
> struct ring_data {
> char in[((1 << ring_order) << PAGE_SHIFT) / 2];
> char out[((1 << ring_order) << PAGE_SHIFT) / 2];
> };
> 

This is the same comment about the the PV Calls structure.

Would it make sense to add the 'in_events' and 'out_events'
as a notification mechanism?


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

Re: [Xen-devel] [PATCH] xen/arm: Fix ARM build following c/s 11c397c

[Julien Grall]

Hi Andrew,

On 08/02/17 19:10, Andrew Cooper wrote:

c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE() which is
different to the definiton in smmu.c

The SMMU code included a scalar typecheck, which is worth keeping in the
common case, given ACCESS_ONCE()'s restrictions.  However, express the
typecheck differently so as to avoid Coverity compliants about unused


s/compliants/complaint/


variables.


OOI, the variable is marked as "__maybe_unused", so why Coverity would 
complaint?




Signed-off-by: Andrew Cooper 


Acked-by: Julien Grall 

Cheers,


---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/drivers/passthrough/arm/smmu.c | 10 --
 xen/include/xen/lib.h  |  5 -
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index cf8b8b8..06c0a45 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -198,16 +198,6 @@ typedef paddr_t phys_addr_t;

 #define VA_BITS0   /* Only used for configuring stage-1 
input size */

-/* The macro ACCESS_ONCE start to be replaced in Linux in favor of
- * {READ, WRITE}_ONCE. Rather than introducing in the common code, keep a
- * version here. We will have to drop it when the SMMU code in Linux will
- * switch to {READ, WRITE}_ONCE.
- */
-#define __ACCESS_ONCE(x) ({ \
-__maybe_unused typeof(x) __var = 0; \
-   (volatile typeof(x) *)&(x); })
-#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
-
 #define MODULE_DEVICE_TABLE(type, name)
 #define module_param_named(name, value, type, perm)
 #define MODULE_PARM_DESC(_parm, desc)
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 1976e4b..995a85a 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -56,7 +56,10 @@

 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x))

-#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+#define __ACCESS_ONCE(x) ({ \
+(void)(typeof(x))0; /* Scalar typecheck. */ \
+(volatile typeof(x) *)&(x); })
+#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))

 #define MASK_EXTR(v, m) (((v) & (m)) / ((m) & -(m)))
 #define MASK_INSR(v, m) (((v) * ((m) & -(m))) & (m))



--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 105644: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 15 guest-localmigrate/x10 fail REGR. 
vs. 105642
 build-armhf   5 xen-buildfail REGR. vs. 105642

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass

version targeted for testing:
 xen  04dbb71096143b54f8b5e1acfce8d55150609d3f
baseline version:
 xen  58b4db0832de1ee355a342feea7e1545219bef12

Last test of basis   105642  2017-02-08 16:04:21 Z0 days
Testing same since   105644  2017-02-08 18:01:23 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  fail
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt 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


Not pushing.


commit 04dbb71096143b54f8b5e1acfce8d55150609d3f
Author: Andrew Cooper 
Date:   Tue Feb 7 14:01:29 2017 +

x86/p2m: Stop other vcpus using a nested p2m before clearing it

Until the IPI has completed, other processors might be running on this 
nested
p2m object.  clear_domain_page() does not guarantee to make 8-byte atomic
updates, which means that a pagewalk on a remote processor might encounter a
partial update.

This is currently safe as other issues prevents a nested p2m ever being 
shared
between two cpus (although this is contrary to the original plan).

Setting p2m->np2m_base to P2M_BASE_EADDR before the IPI ensures that the 
IPI'd
processors won't continue to use the flushed mappings.

While modifying this function, remove all the trailing whitespace and tweak
style in the affected areas.

Signed-off-by: Andrew Cooper 
Reviewed-by: Tim Deegan 
Reviewed-by: Jan Beulich 

commit 11c397c207dda26084be8a5da5bd78c74b4b3651
Author: Andrew Cooper 
Date:   Wed Dec 7 13:52:02 2016 +

x86/time: Adjust init-time handling of pit0_ticks

There is no need for the volatile cast in the timer interrupt; the compiler
may not elide the update.  This reduces the generated assembly from a read,
local modify, write to a single add instruction.

Drop the memory barriers from timer_irq_works(), as they are not needed.
pit0_ticks is only modified by timer_interrupt() running on the same CPU, so
all that is required is a volatile reference to prevent the compiler from
eliding the second read.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
(qemu changes not included)

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

[Xen-devel] [PATCH] xen/arm: Fix ARM build following c/s 11c397c

[Andrew Cooper]

c/s 11c397c broke the ARM build by introducing a common ACCESS_ONCE() which is
different to the definiton in smmu.c

The SMMU code included a scalar typecheck, which is worth keeping in the
common case, given ACCESS_ONCE()'s restrictions.  However, express the
typecheck differently so as to avoid Coverity compliants about unused
variables.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/drivers/passthrough/arm/smmu.c | 10 --
 xen/include/xen/lib.h  |  5 -
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index cf8b8b8..06c0a45 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -198,16 +198,6 @@ typedef paddr_t phys_addr_t;
 
 #define VA_BITS0   /* Only used for configuring stage-1 
input size */
 
-/* The macro ACCESS_ONCE start to be replaced in Linux in favor of
- * {READ, WRITE}_ONCE. Rather than introducing in the common code, keep a
- * version here. We will have to drop it when the SMMU code in Linux will
- * switch to {READ, WRITE}_ONCE.
- */
-#define __ACCESS_ONCE(x) ({ \
-__maybe_unused typeof(x) __var = 0; \
-   (volatile typeof(x) *)&(x); })
-#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
-
 #define MODULE_DEVICE_TABLE(type, name)
 #define module_param_named(name, value, type, perm)
 #define MODULE_PARM_DESC(_parm, desc)
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 1976e4b..995a85a 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -56,7 +56,10 @@
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x))
 
-#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+#define __ACCESS_ONCE(x) ({ \
+(void)(typeof(x))0; /* Scalar typecheck. */ \
+(volatile typeof(x) *)&(x); })
+#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
 
 #define MASK_EXTR(v, m) (((v) & (m)) / ((m) & -(m)))
 #define MASK_INSR(v, m) (((v) * ((m) & -(m))) & (m))
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 2/2] locking/mutex, rwsem: Reduce vcpu_is_preempted() calling frequency

[Waiman Long]

On 02/08/2017 02:05 PM, Peter Zijlstra wrote:
> On Wed, Feb 08, 2017 at 01:00:25PM -0500, Waiman Long wrote:
>> As the vcpu_is_preempted() call is pretty costly compared with other
>> checks within mutex_spin_on_owner() and rwsem_spin_on_owner(), they
>> are done at a reduce frequency of once every 256 iterations.
> That's just disgusting.

I do have some doubt myself on the effectiveness of this patch. Anyway,
it is the first patch that I think is more beneficial.

Cheers,
Longman


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

Re: [Xen-devel] [PATCH v3] xen/arm: fix rank/vgic lock inversion bug

[Julien Grall]

Hi Stefano,

On 02/02/17 22:56, Stefano Stabellini wrote:

On Thu, 2 Feb 2017, Julien Grall wrote:

On 01/02/17 23:23, Stefano Stabellini wrote:

On Wed, 1 Feb 2017, Julien Grall wrote:

On 31/01/2017 23:49, Stefano Stabellini wrote:

On Fri, 27 Jan 2017, Julien Grall wrote:

On 03/01/17 23:29, Stefano Stabellini wrote:

For LPIs, there is no activate state. So as soon as they are EOIed, they
might
come up again. Depending on how will we handle irq migration, your
scenario
will become true. I am not sure if we should take into account LPIs right
now.

To be honest, I don't much like the idea of kicking the other vCPU. But I
don't have a better idea in order to clear the LRs.


What if we skip the interrupt if it's an LPI, and we kick the other vcpu
and wait if it's an SPI? Software should be more tolerant of lost
interrupts in case of LPIs. We are also considering rate-limiting them
anyway, which implies the possibility of skipping some LPIs at times.


I will skip the answer here, as your suggestion to solve the inversion 
lock sounds better.






Me neither, that's why I was proposing a different solution instead. We
still have the option to take the right lock in vgic_migrate_irq:

http://marc.info/?l=xen-devel=148237289620471

The code is more complex, but I think it's safe in all cases.


It is not only complex but also really confusing as we would have a variable
protected by two locks, both lock does not need to be taken at the same time.


Yes, but there is a large in-code comment about it :-)



I may have an idea to avoid completely the lock in vgic_get_target_vcpu. The
lock is only here to read the target vcpu in the rank, the rest does not need
a lock, right? So could not we read the target vcpu atomically instead?


Yes, I think that could solve the lock inversion bug:

- remove the spin_lock in vgic_get_target_vcpu and replace it with an atomic 
read
- replace rank->vcpu writes with atomic writes

However, it would not solve the other issu affecting the current code:
http://marc.info/?l=xen-devel=148218667104072, which is related to the
problem you mentioned about irq_set_affinity and list_del_init in
gic_update_one_lr not being separated by a barrier. Arguably, that bug
could be solved separately.  It would be easier to solve that bug by one
of these approaches:

1) use the same (vgic) lock in gic_update_one_lr and vgic_migrate_irq
2) remove the irq_set_affinity call from gic_update_one_lr

where 1) is the approach taken by v2 of this series and 2) is the
approach taken by this patch.


I think there is a easier solution. You want to make sure that any 
writes (particularly list_del_init) before routing the IRQ are visible 
to the other processors. So a simple barrier in both side should be 
enough here.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] locking/mutex, rwsem: Reduce vcpu_is_preempted() calling frequency

[Peter Zijlstra]

On Wed, Feb 08, 2017 at 01:00:25PM -0500, Waiman Long wrote:
> As the vcpu_is_preempted() call is pretty costly compared with other
> checks within mutex_spin_on_owner() and rwsem_spin_on_owner(), they
> are done at a reduce frequency of once every 256 iterations.

That's just disgusting.

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

Re: [Xen-devel] [PATCH 1/2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

[Peter Zijlstra]

On Wed, Feb 08, 2017 at 01:00:24PM -0500, Waiman Long wrote:
> It was found when running fio sequential write test with a XFS ramdisk
> on a 2-socket x86-64 system, the %CPU times as reported by perf were
> as follows:
> 
>  71.27%  0.28%  fio  [k] down_write
>  70.99%  0.01%  fio  [k] call_rwsem_down_write_failed
>  69.43%  1.18%  fio  [k] rwsem_down_write_failed
>  65.51% 54.57%  fio  [k] osq_lock
>   9.72%  7.99%  fio  [k] __raw_callee_save___kvm_vcpu_is_preempted
>   4.16%  4.16%  fio  [k] __kvm_vcpu_is_preempted
> 
> So making vcpu_is_preempted() a callee-save function has a pretty high
> cost associated with it. As vcpu_is_preempted() is called within the
> spinlock, mutex and rwsem slowpaths, there isn't much to gain by making
> it callee-save. So it is now changed to a normal function call instead.
> 

Numbers for bare metal too please.

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

Re: [Xen-devel] [PATCH v6 04/24] x86: refactor psr: implement CPU init and free flow.

[Konrad Rzeszutek Wilk]

> > +static void cpu_fini_work(unsigned int cpu)
> > +{
> > +unsigned int socket = cpu_to_socket(cpu);
> > +
> > +if ( !socket_cpumask[socket] || cpumask_empty(socket_cpumask[socket]) )
> 
> I fear I don't understand this.
> 
> Looking at 65a399ac it says:
> 
> +.notifier_call = cpu_callback,
> +/*
> + * Ensure socket_cpumask is still valid in CPU_DEAD notification
> + * (E.g. our CPU_DEAD notification should be called ahead of
> + * cpu_smpboot_free).
> 
> Which means that socket_cpumask[socket] should have an value.
> 
> In fact cpumask_any(socket_cpumask[socket]) will return true at this
> point.
> 
> Which means that code above gets called if this psr_cpu_fini is called
> _after_ cpu_smpboot_free (b/c socket_cpumask[socket] will be NULL), see
> cpu_smpboot_free.
> 
> But with .priority being -1 that won't happen.
> 
> But lets ignore that, lets say it does get called _after_
> cpu_smpboot_free. In which case the first part of the 'if' condition
> is true and we end up doing: cpumask_empty(NULL) which will result
> in an page fault.
> 
> I think this is a bug.

I missed the fact that we call this function on CPU_UP_CANCELED
_and_ CPU_DEAD and that remove_siblinginfo is called before CPU_DEAD.

So say the socket is being onlined and we are the first CPU on
that (CPU=2).


1) CPU_UP_PREPARE notifier calls psr_cpu_prepare which allocates
   'feat_l3_cat'.

2). Some other notifies dies and we end up calling CPU_UP_CANCELED.
   psr_cpu_fini -> cpu_fini_work:

   Since __cpu_up has not been called that means
   socket_cpumask[socket] == NULL

   and we enter free_feature.

   It does 'if !(socket_info + socket)' effectively. And that is false
   as init_psr was the one initializing that array which means the
   pointer (info aka socket_info + socket) certainly is not NULL.

   Anyhow this means free_feature tries to walk the list - but 'info'
   is full of zeros.

   Which means list_for_each_entry_safe is going to blow when trying
   to set 'n' (as pos is zero aka NULL).

   Perhaps you want an INIT_LIST_HEAD in 'init_psr' so that free_feature
   can be idempotent?

   Or perhaps you need '&&' in the if conditional (and naturally
   remove the !)?

   I wonder what other CPU notifiers are guilty of this..


Lets try another example:

1) CPU_UP_PREPARE notifier calls psr_cpu_prepare which allocates
   'feat_l3_cat'.

2) All notifiers were OK, the __cpu_up has been called. The
   socket_cpumask[socket] = 

3) All notifiers are called with CPU_ONLINE.
   All good.


..some time later ..

4). CPU is brought down. Notifiers for CPU_DOWN_PREPARE are called
   [psr is not part of it]

5) CPU notifiers CPU_DEAD are called. They all have to return
NOTIFY_DONE otherwise we hit 'BUG_ON'

   We call psr_cpu_fini -> cpu_fini_work

   socket_cpumask[socket] has some data, so the first conditional
   is false:

( !socket_cpumask[socket] ||

   the second:

cpumask_empty(socket_cpumask[socket]) )

   is true as take_cpu_down -> __cpu_disable -> remove_siblinginfo

   was called before us.(and this is the first CPU in the socket).

   And we call free_feature.
   which is correct and we free our data.

   And the 'cpumask_empty' guards us so that we only call this
   on the very last CPU.


  And we would still call this if the conditional was:

  if ( socket_cpumask[socket] && cpumask_empty(socket_cpumask[socket]))

  I think?

Feel free to poke holes at my analysis - I am sure I missed some edge
case.

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

Re: [Xen-devel] Xen 4.9 Development Update

[Tamas K Lengyel]

>
>
> *  Altp2m for ARM
>   -  Sergej Proskurin
>

This was a GSoC project last summer that unfortunately didn't make the
merge window. I'll probably pick it up sometime in the future and get it
rebased but it is unlikely to happen for 4.9.

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

Re: [Xen-devel] Xen 4.9 Development Update

[Oleksandr Andrushchenko]

On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:

On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:

(CC Konrad)

Hi Oleksandr,

On 31/01/17 13:51, Oleksandr Andrushchenko wrote:

On 01/30/2017 05:33 PM, Julien Grall wrote:

This email only tracks big items for xen.git tree. Please reply for
items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.
== PV Drivers ==

*  Xen transport for 9pfs
-  Stefano Stabellini

*  PV calls
-  Stefano Stabellini


Are you considering other PV protocols for this drop? E.g.
multi-touch support, sound and display?

That would be up to you and Konrad :).

I think we only have one left from Oleksandr.

That is correct (namely displif is on my list)

Two of them have been
reviewed by me today.

Anyway, I am going to track any big inflight items even those not planned
for next release. This will give us an overview of what's going on.

What is the list of PV protocols you have in mind? And do you know who will
work on it?

Also, I should probably track separately the backend/frontend support if you
plan to upstream them later.

We do. We only miss the corresponding protocols in the trees (both Xen and
the kernel), so we can start updating *existing* backs/fronts/libs for
sndif/displif/DRM zero-copy/multi-touch and get those ready for upstreaming


Cheers,

--
Julien Grall



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

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

[Dario Faggioli]

On Wed, 2017-02-08 at 10:02 -0700, Jan Beulich wrote:
> > > > On 08.02.17 at 17:48,  wrote:
> > Am I looking in the wrong places / misunderstood anything?
> 
> Well, me having done the backports didn't imply me committing them
> right away; I wanted them to first undergo some testing. 
>
Ok, right, I see it now. Thanks for clarifying (again).

> I hope to
> get to that tomorrow. If you want to wait for what I have to appear
> there, that's of course fine.
> 
So, patches applies cleanly to 4.8, as you've probably seen already.

As per 4.7, I've prepared a branch for you:

 git://xenbits.xen.org/people/dariof/xen.git 
for-jan/staging-4.7/credit2-cpupool-fixes
 
http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/heads/for-jan/staging-4.7/credit2-cpupool-fixes
 https://travis-ci.org/fdario/xen/builds/199709757

I've only quickly tested it so far, and I have to leave now. I'll play
with it a bit more tomorrow morning and let you know how it goes.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/8] xen/arm: acpi: Rework acpi_boot_table_init error paths

[Julien Grall]

Hi Andrew,

On 03/02/17 20:44, Andrew Cooper wrote:

On 03/02/17 19:18, Julien Grall wrote:

@@ -260,16 +257,22 @@ int __init acpi_boot_table_init(void)
 error = acpi_table_init();
 if ( error )
 {
-disable_acpi();
-return error;
+printk("%s: Unable to initialize table parser (%d)\n",
+   __FUNCTION__, error);


As a nit, please use __func__.

It is standard C, whereas __FUNCTION__ is a GCCism.

(On that note, there are very few remaining uses in the hypervisor - let
me submit a patch killing the remaining uses.)


I will fix it and try to remember for next time.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/p2m: Reposition p2m_teardown_nestedp2m() to avoid its forward declaration

[George Dunlap]

On 07/02/17 18:43, Andrew Cooper wrote:
> While adjusting these functions, use unsigned int rather than uint8_t for the
> loop variable, and fix the whitespace style.
> 
> No functional change.

I think changing a variable from 8 to 64 bits might count as a
functional change; but anyway:

Reviewed-by: George Dunlap 

> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: George Dunlap 
> ---
>  xen/arch/x86/mm/p2m.c | 36 +---
>  1 file changed, 17 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 6548e9f..7675e9c 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -147,15 +147,29 @@ static void p2m_teardown_hostp2m(struct domain *d)
>  }
>  }
>  
> -static void p2m_teardown_nestedp2m(struct domain *d);
> +static void p2m_teardown_nestedp2m(struct domain *d)
> +{
> +unsigned int i;
> +struct p2m_domain *p2m;
> +
> +for ( i = 0; i < MAX_NESTEDP2M; i++ )
> +{
> +if ( !d->arch.nested_p2m[i] )
> +continue;
> +p2m = d->arch.nested_p2m[i];
> +list_del(>np2m_list);
> +p2m_free_one(p2m);
> +d->arch.nested_p2m[i] = NULL;
> +}
> +}
>  
>  static int p2m_init_nestedp2m(struct domain *d)
>  {
> -uint8_t i;
> +unsigned int i;
>  struct p2m_domain *p2m;
>  
>  mm_lock_init(>arch.nested_p2m_lock);
> -for (i = 0; i < MAX_NESTEDP2M; i++)
> +for ( i = 0; i < MAX_NESTEDP2M; i++ )
>  {
>  d->arch.nested_p2m[i] = p2m = p2m_init_one(d);
>  if ( p2m == NULL )
> @@ -171,22 +185,6 @@ static int p2m_init_nestedp2m(struct domain *d)
>  return 0;
>  }
>  
> -static void p2m_teardown_nestedp2m(struct domain *d)
> -{
> -uint8_t i;
> -struct p2m_domain *p2m;
> -
> -for (i = 0; i < MAX_NESTEDP2M; i++)
> -{
> -if ( !d->arch.nested_p2m[i] )
> -continue;
> -p2m = d->arch.nested_p2m[i];
> -list_del(>np2m_list);
> -p2m_free_one(p2m);
> -d->arch.nested_p2m[i] = NULL;
> -}
> -}
> -
>  static void p2m_teardown_altp2m(struct domain *d)
>  {
>  unsigned int i;
> 


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

Re: [Xen-devel] [PATCH] xenbus: Neaten xenbus_va_dev_error

[Joe Perches]

On Wed, 2017-02-08 at 12:14 -0500, Boris Ostrovsky wrote:
> On 02/08/2017 11:05 AM, Joe Perches wrote:
> > On Wed, 2017-02-08 at 10:33 -0500, Boris Ostrovsky wrote:
> > > On 02/08/2017 06:33 AM, Joe Perches wrote:
> > > > This function error patch can be simplified, so do so.
> > > > 
> > > > Remove fail: label and somewhat obfuscating, used once "error_path"
> > > > function.
> > 
> > btw: I left it alone, but likely
> > 
> > #define PRINTF_BUFFER_SIZE 4096
> > 
> > is probably excessive as the maximum printk
> > buffer is 1024.
> > 
> > The xenbus_write might be longer though so
> > maybe it's OK to use 4096, but there is some
> > inequivalence there.
> > 
> 
> xenbus_write() handles writes up to 4K. However we are filling the
> buffer with sprintf() which I assume is limited to 1K too

vsnprintf is bounded only by addressable memory. ie: (void *)-1

> so it indeed
> doesn't seem useful to have PRINTF_BUFFER_SIZE set to 4.
> 
> -boris
> 

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

Re: [Xen-devel] Xen 4.9 Development Update

[Konrad Rzeszutek Wilk]

On Wed, Feb 08, 2017 at 06:03:00PM +, Julien Grall wrote:
> (CC Konrad)
> 
> Hi Oleksandr,
> 
> On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
> > 
> > On 01/30/2017 05:33 PM, Julien Grall wrote:
> > > This email only tracks big items for xen.git tree. Please reply for
> > > items you
> > > woulk like to see in 4.9 so that people have an idea what is going on and
> > > prioritise accordingly.
> > > == PV Drivers ==
> > > 
> > > *  Xen transport for 9pfs
> > >-  Stefano Stabellini
> > > 
> > > *  PV calls
> > >-  Stefano Stabellini
> > > 
> > Are you considering other PV protocols for this drop? E.g.
> > multi-touch support, sound and display?
> 
> That would be up to you and Konrad :).

I think we only have one left from Oleksandr. Two of them have been
reviewed by me today.
> 
> Anyway, I am going to track any big inflight items even those not planned
> for next release. This will give us an overview of what's going on.
> 
> What is the list of PV protocols you have in mind? And do you know who will
> work on it?
> 
> Also, I should probably track separately the backend/frontend support if you
> plan to upstream them later.
> 
> Cheers,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH v2] xen/p2m: Fix p2m_flush_table for non-nested cases

[George Dunlap]

On 08/02/17 17:29, Tim Deegan wrote:
> At 17:22 + on 08 Feb (1486574546), George Dunlap wrote:
>> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
>> nested p2m tables whenever the host p2m table changed.  Unfortunately
>> in the process, it added a filter to p2m_flush_table() function so
>> that the p2m would only be flushed if it was being used as a nested
>> p2m.  This meant that the p2m was not being flushed at all for altp2m
>> callers.
>>
>> Only check np2m_base if p2m_class is set to p2m_nested.
>>
>> NB that this is not a security issue: The only time this codepath is
>> called is in cases where either nestedp2m or altp2m is enabled, and
>> neither of them are in security support.
>>
>> Reported-by: Matt Leinhos 
>> Signed-off-by: George Dunlap 
>> CC: Tamas K Lengyel 
>> ---
>>  xen/arch/x86/mm/p2m.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 6548e9f..0af2ec1 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1627,7 +1627,9 @@ p2m_flush_table(struct p2m_domain *p2m)
>>  ASSERT(page_list_empty(>pod.super));
>>  ASSERT(page_list_empty(>pod.single));
>>  
>> -if ( p2m->np2m_base == P2M_BASE_EADDR )
>> +/* No need to flush if it's already empty */
>> +if ( p2m->p2m_class == p2m_nested &&
>> + p2m->np2m_base == P2M_BASE_EADDR )
> 
> Looks like p2m_is_nestedp2m(p2m) is the usual idiom.  Either way:
> 
> Reviewed-by: Tim Deegan 

Right -- I'll change it to the usual idiom and check it in after I've
gotten a test report (or waited a reasonable amount of time).

 -George


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

Re: [Xen-devel] [PATCH] x86/p2m: Stop other vcpus using a nested p2m before clearing it

[George Dunlap]

On 08/02/17 18:06, George Dunlap wrote:
> On 08/02/17 13:20, Andrew Cooper wrote:
>> On 08/02/17 13:13, Jan Beulich wrote:
>> On 07.02.17 at 19:48,  wrote:
 Until the IPI has completed, other processors might be running on this 
 nested
 p2m object.  clear_domain_page() does not guarantee to make 8-byte atomic
 updates, which means that a pagewalk on a remote processor might encounter 
 a
 partial update.

 This is currently safe as other issues prevents a nested p2m ever being 
 shared
 between two cpus (although this is contrary to the original plan).

 Setting p2m->np2m_base to P2M_BASE_EADDR before the IPI ensures that the 
 IPI'd
 processors won't continue to use the flushed mappings.

 While modifying this function, remove all the trailing whitespace and tweak
 style in the affected areas.

 Signed-off-by: Andrew Cooper 
>>> Reviewed-by: Jan Beulich 
>>> but ...
>>>
 @@ -1633,19 +1635,21 @@ p2m_flush_table(struct p2m_domain *p2m)
  
  /* This is no longer a valid nested p2m for any address space */
  p2m->np2m_base = P2M_BASE_EADDR;
 -
 -/* Zap the top level of the trie */
 -mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
 -clear_domain_page(mfn);
  
  /* Make sure nobody else is using this p2m table */
  nestedhvm_vmcx_flushtlb(p2m);
  
 +/* Zap the top level of the trie */
>>> s/trie/tree/ here, as you touch it anyway?
>>
>> Trie here refers to the datastructure https://en.wikipedia.org/wiki/Trie
>> which is the structure implemented by processor pagetables.  It is more
>> specific than just calling them trees.
> 
> Never heard that before, but we seem to already have at least six
> instances in the hypervisor (and an ocaml file called 'trie.mli'), so I
> guess there's precedent. :-)
> 
> Reviewed-by: George Dunlap 
> 
> I'll check this one in.

Or maybe I won't. :-)

 -George


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

Re: [Xen-devel] [PATCH] x86/p2m: Stop other vcpus using a nested p2m before clearing it

[George Dunlap]

On 08/02/17 13:20, Andrew Cooper wrote:
> On 08/02/17 13:13, Jan Beulich wrote:
> On 07.02.17 at 19:48,  wrote:
>>> Until the IPI has completed, other processors might be running on this 
>>> nested
>>> p2m object.  clear_domain_page() does not guarantee to make 8-byte atomic
>>> updates, which means that a pagewalk on a remote processor might encounter a
>>> partial update.
>>>
>>> This is currently safe as other issues prevents a nested p2m ever being 
>>> shared
>>> between two cpus (although this is contrary to the original plan).
>>>
>>> Setting p2m->np2m_base to P2M_BASE_EADDR before the IPI ensures that the 
>>> IPI'd
>>> processors won't continue to use the flushed mappings.
>>>
>>> While modifying this function, remove all the trailing whitespace and tweak
>>> style in the affected areas.
>>>
>>> Signed-off-by: Andrew Cooper 
>> Reviewed-by: Jan Beulich 
>> but ...
>>
>>> @@ -1633,19 +1635,21 @@ p2m_flush_table(struct p2m_domain *p2m)
>>>  
>>>  /* This is no longer a valid nested p2m for any address space */
>>>  p2m->np2m_base = P2M_BASE_EADDR;
>>> -
>>> -/* Zap the top level of the trie */
>>> -mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
>>> -clear_domain_page(mfn);
>>>  
>>>  /* Make sure nobody else is using this p2m table */
>>>  nestedhvm_vmcx_flushtlb(p2m);
>>>  
>>> +/* Zap the top level of the trie */
>> s/trie/tree/ here, as you touch it anyway?
> 
> Trie here refers to the datastructure https://en.wikipedia.org/wiki/Trie
> which is the structure implemented by processor pagetables.  It is more
> specific than just calling them trees.

Never heard that before, but we seem to already have at least six
instances in the hypervisor (and an ocaml file called 'trie.mli'), so I
guess there's precedent. :-)

Reviewed-by: George Dunlap 

I'll check this one in.

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

Re: [Xen-devel] Xen 4.9 Development Update

[Julien Grall]

(CC Konrad)

Hi Oleksandr,

On 31/01/17 13:51, Oleksandr Andrushchenko wrote:


On 01/30/2017 05:33 PM, Julien Grall wrote:

This email only tracks big items for xen.git tree. Please reply for
items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.
== PV Drivers ==

*  Xen transport for 9pfs
   -  Stefano Stabellini

*  PV calls
   -  Stefano Stabellini


Are you considering other PV protocols for this drop? E.g.
multi-touch support, sound and display?


That would be up to you and Konrad :).

Anyway, I am going to track any big inflight items even those not 
planned for next release. This will give us an overview of what's going on.


What is the list of PV protocols you have in mind? And do you know who 
will work on it?


Also, I should probably track separately the backend/frontend support if 
you plan to upstream them later.


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH 2/2] locking/mutex, rwsem: Reduce vcpu_is_preempted() calling frequency

[Waiman Long]

As the vcpu_is_preempted() call is pretty costly compared with other
checks within mutex_spin_on_owner() and rwsem_spin_on_owner(), they
are done at a reduce frequency of once every 256 iterations.

Signed-off-by: Waiman Long 
---
 kernel/locking/mutex.c  | 5 -
 kernel/locking/rwsem-xadd.c | 6 --
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index ad2d9e2..2ece0c4 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -423,6 +423,7 @@ bool mutex_spin_on_owner(struct mutex *lock, struct 
task_struct *owner,
 struct ww_acquire_ctx *ww_ctx, struct mutex_waiter 
*waiter)
 {
bool ret = true;
+   int loop = 0;
 
rcu_read_lock();
while (__mutex_owner(lock) == owner) {
@@ -436,9 +437,11 @@ bool mutex_spin_on_owner(struct mutex *lock, struct 
task_struct *owner,
 
/*
 * Use vcpu_is_preempted to detect lock holder preemption issue.
+* As vcpu_is_preempted is more costly to use, it is called at
+* a reduced frequencey (once every 256 iterations).
 */
if (!owner->on_cpu || need_resched() ||
-   vcpu_is_preempted(task_cpu(owner))) {
+  (!(++loop & 0xff) && vcpu_is_preempted(task_cpu(owner {
ret = false;
break;
}
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 2ad8d8d..7a884a6 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -351,6 +351,7 @@ static inline bool rwsem_can_spin_on_owner(struct 
rw_semaphore *sem)
 static noinline bool rwsem_spin_on_owner(struct rw_semaphore *sem)
 {
struct task_struct *owner = READ_ONCE(sem->owner);
+   int loop = 0;
 
if (!rwsem_owner_is_writer(owner))
goto out;
@@ -367,10 +368,11 @@ static noinline bool rwsem_spin_on_owner(struct 
rw_semaphore *sem)
 
/*
 * abort spinning when need_resched or owner is not running or
-* owner's cpu is preempted.
+* owner's cpu is preempted. The preemption check is done at
+* a lower frequencey because of its high cost.
 */
if (!owner->on_cpu || need_resched() ||
-   vcpu_is_preempted(task_cpu(owner))) {
+  (!(++loop & 0xff) && vcpu_is_preempted(task_cpu(owner {
rcu_read_unlock();
return false;
}
-- 
1.8.3.1


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

[Xen-devel] [PATCH 1/2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

[Waiman Long]

It was found when running fio sequential write test with a XFS ramdisk
on a 2-socket x86-64 system, the %CPU times as reported by perf were
as follows:

 71.27%  0.28%  fio  [k] down_write
 70.99%  0.01%  fio  [k] call_rwsem_down_write_failed
 69.43%  1.18%  fio  [k] rwsem_down_write_failed
 65.51% 54.57%  fio  [k] osq_lock
  9.72%  7.99%  fio  [k] __raw_callee_save___kvm_vcpu_is_preempted
  4.16%  4.16%  fio  [k] __kvm_vcpu_is_preempted

So making vcpu_is_preempted() a callee-save function has a pretty high
cost associated with it. As vcpu_is_preempted() is called within the
spinlock, mutex and rwsem slowpaths, there isn't much to gain by making
it callee-save. So it is now changed to a normal function call instead.

With this patch applied, the aggregrate bandwidth of the fio sequential
write test increased slightly from 2563.3MB/s to 2588.1MB/s (about 1%).

Signed-off-by: Waiman Long 
---
 arch/x86/include/asm/paravirt.h   | 2 +-
 arch/x86/include/asm/paravirt_types.h | 2 +-
 arch/x86/kernel/kvm.c | 7 ++-
 arch/x86/kernel/paravirt-spinlocks.c  | 6 ++
 arch/x86/xen/spinlock.c   | 4 +---
 5 files changed, 7 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 864f57b..2515885 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -676,7 +676,7 @@ static __always_inline void pv_kick(int cpu)
 
 static __always_inline bool pv_vcpu_is_preempted(int cpu)
 {
-   return PVOP_CALLEE1(bool, pv_lock_ops.vcpu_is_preempted, cpu);
+   return PVOP_CALL1(bool, pv_lock_ops.vcpu_is_preempted, cpu);
 }
 
 #endif /* SMP && PARAVIRT_SPINLOCKS */
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index bb2de45..88dc852 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -309,7 +309,7 @@ struct pv_lock_ops {
void (*wait)(u8 *ptr, u8 val);
void (*kick)(int cpu);
 
-   struct paravirt_callee_save vcpu_is_preempted;
+   bool (*vcpu_is_preempted)(int cpu);
 };
 
 /* This contains all the paravirt structures: we get a convenient
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 099fcba..eb3753d 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -595,7 +595,6 @@ __visible bool __kvm_vcpu_is_preempted(int cpu)
 
return !!src->preempted;
 }
-PV_CALLEE_SAVE_REGS_THUNK(__kvm_vcpu_is_preempted);
 
 /*
  * Setup pv_lock_ops to exploit KVM_FEATURE_PV_UNHALT if present.
@@ -614,10 +613,8 @@ void __init kvm_spinlock_init(void)
pv_lock_ops.wait = kvm_wait;
pv_lock_ops.kick = kvm_kick_cpu;
 
-   if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
-   pv_lock_ops.vcpu_is_preempted =
-   PV_CALLEE_SAVE(__kvm_vcpu_is_preempted);
-   }
+   if (kvm_para_has_feature(KVM_FEATURE_STEAL_TIME))
+   pv_lock_ops.vcpu_is_preempted = __kvm_vcpu_is_preempted;
 }
 
 #endif /* CONFIG_PARAVIRT_SPINLOCKS */
diff --git a/arch/x86/kernel/paravirt-spinlocks.c 
b/arch/x86/kernel/paravirt-spinlocks.c
index 6259327..da050bc 100644
--- a/arch/x86/kernel/paravirt-spinlocks.c
+++ b/arch/x86/kernel/paravirt-spinlocks.c
@@ -24,12 +24,10 @@ __visible bool __native_vcpu_is_preempted(int cpu)
 {
return false;
 }
-PV_CALLEE_SAVE_REGS_THUNK(__native_vcpu_is_preempted);
 
 bool pv_is_native_vcpu_is_preempted(void)
 {
-   return pv_lock_ops.vcpu_is_preempted.func ==
-   __raw_callee_save___native_vcpu_is_preempted;
+   return pv_lock_ops.vcpu_is_preempted == __native_vcpu_is_preempted;
 }
 
 struct pv_lock_ops pv_lock_ops = {
@@ -38,7 +36,7 @@ struct pv_lock_ops pv_lock_ops = {
.queued_spin_unlock = PV_CALLEE_SAVE(__native_queued_spin_unlock),
.wait = paravirt_nop,
.kick = paravirt_nop,
-   .vcpu_is_preempted = PV_CALLEE_SAVE(__native_vcpu_is_preempted),
+   .vcpu_is_preempted = __native_vcpu_is_preempted,
 #endif /* SMP */
 };
 EXPORT_SYMBOL(pv_lock_ops);
diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
index 25a7c43..c85bb8f 100644
--- a/arch/x86/xen/spinlock.c
+++ b/arch/x86/xen/spinlock.c
@@ -114,8 +114,6 @@ void xen_uninit_lock_cpu(int cpu)
per_cpu(irq_name, cpu) = NULL;
 }
 
-PV_CALLEE_SAVE_REGS_THUNK(xen_vcpu_stolen);
-
 /*
  * Our init of PV spinlocks is split in two init functions due to us
  * using paravirt patching and jump labels patching and having to do
@@ -138,7 +136,7 @@ void __init xen_init_spinlocks(void)
pv_lock_ops.queued_spin_unlock = 
PV_CALLEE_SAVE(__pv_queued_spin_unlock);
pv_lock_ops.wait = xen_qlock_wait;
pv_lock_ops.kick = xen_qlock_kick;
-   pv_lock_ops.vcpu_is_preempted = PV_CALLEE_SAVE(xen_vcpu_stolen);
+   pv_lock_ops.vcpu_is_preempted = xen_vcpu_stolen;
 }
 
 static __init int xen_parse_nopvspin(char *arg)
-- 
1.8.3.1

Re: [Xen-devel] Xen 4.9 Development Update

[Julien Grall]

Hi Wei,

On 30/01/17 15:45, Wei Liu wrote:

On Mon, Jan 30, 2017 at 03:32:49PM +, Julien Grall wrote:
[...]


I think it would be good to main two lists.  One of "the stuff people
are working on overall", and "the subset of it intended/expected for the
forthcoming release".

Stuff will invariably slip, but even if the work isn't intended for the
forthcoming release, it it still useful to see if anyone in the
community is working on a related topic.


I am thinking to re-introduce the state of a series (none, fair, ok, good,
done) as it was done in the past [1].

"The states are: none -> fair -> ok -> good -> done

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs"



We (I?) ditched them because they weren't that useful.  "None" is just
signalling of intent, which doesn't carry enough of meaningful
information.  "Fair", "ok" and "good" are all subjective -- we've seen
"good" series slipped due to last minute issues.

If we really want status, I would suggest more concrete status:

  design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed

These are more tangible and objective.


I agree this is more objective but we loose the time estimation. The number
of revisions sent depends a lot on the contributor, complexity of the
series... So a series tagged wip.v5 might be in better shape of one tagged
wip.v10.


Yes, that's true. I've given up on hoping a certain thing manage to get
in a certain release. This is just how open source software development
works -- upstream has no very limited leverage on what people do. :-)

The value of revision number, imo, is that it objectively indicate if a
project is going on well or not. Say, a project in rfc.v10 or wip.v25 is
definitely alarming -- we (RM and committers) probably need to do
something process-wise to get it back on track.  That probably includes
understanding the issues / disputes between parties, provide
suggestions, mediate and sometimes make difficult decisions on various
issues.


Sounds good to me. I will have a try implementing this on the next 
iteration.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] common/vm_event: Prevent guest locking with large max_vcpus

[Razvan Cojocaru]

On 02/08/2017 07:20 PM, Andrew Cooper wrote:
> On 08/02/17 17:08, Razvan Cojocaru wrote:
>> On 02/08/2017 06:25 PM, Tamas K Lengyel wrote:
>>>
>>> On Wed, Feb 8, 2017 at 2:00 AM, Razvan Cojocaru
>>> > wrote:
>>>
>>> It is currently possible for the guest to lock when subscribing
>>> to synchronous vm_events if max_vcpus is larger than the
>>> number of available ring buffer slots. This patch no longer
>>> blocks already paused VCPUs, fixing the issue for this use
>>> case.
>>>
>>> Signed-off-by: Razvan Cojocaru >> >
>>> ---
>>>  xen/common/vm_event.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
>>> index 82ce8f1..2005a64 100644
>>> --- a/xen/common/vm_event.c
>>> +++ b/xen/common/vm_event.c
>>> @@ -316,7 +316,8 @@ void vm_event_put_request(struct domain *d,
>>>   * See the comments above wake_blocked() for more information
>>>   * on how this mechanism works to avoid waiting. */
>>>  avail_req = vm_event_ring_available(ved);
>>> -if( current->domain == d && avail_req < d->max_vcpus )
>>> +if( current->domain == d && avail_req < d->max_vcpus &&
>>> +!atomic_read( >vm_event_pause_count ) )
>>>  vm_event_mark_and_pause(current, ved);
>>>
>>>
>>> Hi Razvan,
>>> I would also like to have the change made in this patch that unblocks
>>> the vCPUs as soon as a spot opens up on the ring. Doing just what this
>>> patch has will not solve the problem if there are asynchronous events used.
>> Fair enough, I thought that might need more discussion and thus put into
>> a subsequent patch, but I'll modify that as well, give it a spin and
>> submit V2.
> 
> If you are spinning a v2, please pull current out into a variable at the
> start (more efficient), and atomic_read() doesn't need spaces inside.

Will do.


Thanks,
Razvan

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

[Xen-devel] [qemu-mainline test] 105639: regressions - FAIL

[osstest service owner]

flight 105639 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105639/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 

Re: [Xen-devel] [PATCH v2] xen/p2m: Fix p2m_flush_table for non-nested cases

[Tim Deegan]

At 17:22 + on 08 Feb (1486574546), George Dunlap wrote:
> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
> nested p2m tables whenever the host p2m table changed.  Unfortunately
> in the process, it added a filter to p2m_flush_table() function so
> that the p2m would only be flushed if it was being used as a nested
> p2m.  This meant that the p2m was not being flushed at all for altp2m
> callers.
> 
> Only check np2m_base if p2m_class is set to p2m_nested.
> 
> NB that this is not a security issue: The only time this codepath is
> called is in cases where either nestedp2m or altp2m is enabled, and
> neither of them are in security support.
> 
> Reported-by: Matt Leinhos 
> Signed-off-by: George Dunlap 
> CC: Tamas K Lengyel 
> ---
>  xen/arch/x86/mm/p2m.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 6548e9f..0af2ec1 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1627,7 +1627,9 @@ p2m_flush_table(struct p2m_domain *p2m)
>  ASSERT(page_list_empty(>pod.super));
>  ASSERT(page_list_empty(>pod.single));
>  
> -if ( p2m->np2m_base == P2M_BASE_EADDR )
> +/* No need to flush if it's already empty */
> +if ( p2m->p2m_class == p2m_nested &&
> + p2m->np2m_base == P2M_BASE_EADDR )

Looks like p2m_is_nestedp2m(p2m) is the usual idiom.  Either way:

Reviewed-by: Tim Deegan 

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Edgar E. Iglesias]

On Wed, Feb 08, 2017 at 04:58:44PM +, Julien Grall wrote:
> Hi Tamas,
> 
> On 08/02/17 16:40, Tamas K Lengyel wrote:
> >On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
> >> wrote:
> >On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
> >> On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall  >> wrote:
> >I considered this approach a bit but it has several problems IMO.
> >These may not be unsolvable or even problems for monitoring but
> >they do introduce complexity into the solution.
> >
> >1. Some SMC calls may depend on the core they are issued from.
> >   If taking a detour to dom0, this becomes messy to guarantee.
> >
> >2. Overall complexity increases very significantly and it becomes
> >   quite hard to follow/review how these calls get handled.
> >   In particular once you consider solving #1.
> >
> >3. There are certain calls that perhaps not even dom0 should have
> >   direct access to. This means that Xen may need to filter some of
> >   them anyway.
> >
> >Some examples may be:
> >
> >SMC calls:
> >* To directly turn off or suspend cores
> >* To turn off DDR or RAMs that Xen is using
> >* To a solution specific Trusted OS pinned to a specific core
> >* For PSCI
> >* Etc
> >
> >I would prefer if we could find a way for monitoring to play nicely
> >with Xen implementing the SMC mediators.
> >Perhaps we could allow calls that Xen consumes to be monitored/inspected
> >but not modified. Or there might be other ways.
> >
> >Best regards,
> >Edgar
> >
> >
> >Hi Edgar,
> >certainly there are many cases where the system would become very
> >complex when there is functionality like what you describe in the TZ
> >that needs to be made accessible via SMC. The setup I described is
> >experimental only, and the underlying assumption is that the TZ is
> >working jointly with the monitor application (ie. both are aware of each
> >other). So it is really not intended to work with just any firmware.
> 
> How do you expect TrustZone to work with the monitor application? If you
> think about modifying Trustzone, it seems a requirement difficult to achieve
> as some Trusted OS are proprietary or difficult to replace on a phone.
> 
> >
> >So I think for the sake of reducing complexity, having the monitor
> >system be exclusive when enabled should make everyone's life simpler.
> >Having a passive monitoring mode as you suggest is certainly an option,
> >although it should not be the only option, exclusive routing of SMCs
> >through monitor applications should still be available to be configured
> >by the user. Since I really don't know of any usecases where passive
> >monitoring of SMCs is required, I don't think we should go that route.
> 
> I see the SMC trap similar to a register trap. The monitor app will look at
> the register value and potentially modify it. What would be the issue to do
> the same for SMC?

Yes, I think this would work if we can keep the SMC processing on the same
core (after it's been accepted by monitor filters). If not accepted by
filters, we'd just ignore the SMC processing and return registers provided
by the monitor (or something along those lines).


> I think a such model would fit the requirement for everyone. The monitor app
> can filter if necessary, and Xen would handle the mediation between multiple
> guests. I would also recommend to read the thread about OP-TEE support in
> Xen (see [1]).
>

We have a similar issue with interrupts from Firmware. I've not implemented
this part in this series but at some point I'm going to have to.

Essentially I'm looking at handling an IPI in Xen and forwarding an SGI or
a virtual inject of the IPI to the guest that was targeted. Future work...

Cheers,
Edgar

> Cheers,
> 
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg02220.html
> 
> -- 
> Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 105642: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  58b4db0832de1ee355a342feea7e1545219bef12
baseline version:
 xen  c562d7a2f5efd3716ab0b70c0c4d1dbebb55a215

Last test of basis   105637  2017-02-08 13:03:41 Z0 days
Testing same since   105642  2017-02-08 16:04:21 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Juergen Gross 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  fail
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt 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=xen-unstable-smoke
+ revision=58b4db0832de1ee355a342feea7e1545219bef12
+ . ./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 /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
58b4db0832de1ee355a342feea7e1545219bef12
+ branch=xen-unstable-smoke
+ revision=58b4db0832de1ee355a342feea7e1545219bef12
+ . ./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/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x58b4db0832de1ee355a342feea7e1545219bef12 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : 

[Xen-devel] [PATCH v2] xen/p2m: Fix p2m_flush_table for non-nested cases

[George Dunlap]

Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
nested p2m tables whenever the host p2m table changed.  Unfortunately
in the process, it added a filter to p2m_flush_table() function so
that the p2m would only be flushed if it was being used as a nested
p2m.  This meant that the p2m was not being flushed at all for altp2m
callers.

Only check np2m_base if p2m_class is set to p2m_nested.

NB that this is not a security issue: The only time this codepath is
called is in cases where either nestedp2m or altp2m is enabled, and
neither of them are in security support.

Reported-by: Matt Leinhos 
Signed-off-by: George Dunlap 
---
CC: Andrew Cooper 
CC: Jan Beulich 
CC: Tim Deegan 
CC: Tamas K Lengyel 
---
 xen/arch/x86/mm/p2m.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 6548e9f..0af2ec1 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1627,7 +1627,9 @@ p2m_flush_table(struct p2m_domain *p2m)
 ASSERT(page_list_empty(>pod.super));
 ASSERT(page_list_empty(>pod.single));
 
-if ( p2m->np2m_base == P2M_BASE_EADDR )
+/* No need to flush if it's already empty */
+if ( p2m->p2m_class == p2m_nested &&
+ p2m->np2m_base == P2M_BASE_EADDR )
 {
 p2m_unlock(p2m);
 return;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] common/vm_event: Prevent guest locking with large max_vcpus

[Andrew Cooper]

On 08/02/17 17:08, Razvan Cojocaru wrote:
> On 02/08/2017 06:25 PM, Tamas K Lengyel wrote:
>>
>> On Wed, Feb 8, 2017 at 2:00 AM, Razvan Cojocaru
>> > wrote:
>>
>> It is currently possible for the guest to lock when subscribing
>> to synchronous vm_events if max_vcpus is larger than the
>> number of available ring buffer slots. This patch no longer
>> blocks already paused VCPUs, fixing the issue for this use
>> case.
>>
>> Signed-off-by: Razvan Cojocaru > >
>> ---
>>  xen/common/vm_event.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
>> index 82ce8f1..2005a64 100644
>> --- a/xen/common/vm_event.c
>> +++ b/xen/common/vm_event.c
>> @@ -316,7 +316,8 @@ void vm_event_put_request(struct domain *d,
>>   * See the comments above wake_blocked() for more information
>>   * on how this mechanism works to avoid waiting. */
>>  avail_req = vm_event_ring_available(ved);
>> -if( current->domain == d && avail_req < d->max_vcpus )
>> +if( current->domain == d && avail_req < d->max_vcpus &&
>> +!atomic_read( >vm_event_pause_count ) )
>>  vm_event_mark_and_pause(current, ved);
>>
>>
>> Hi Razvan,
>> I would also like to have the change made in this patch that unblocks
>> the vCPUs as soon as a spot opens up on the ring. Doing just what this
>> patch has will not solve the problem if there are asynchronous events used.
> Fair enough, I thought that might need more discussion and thus put into
> a subsequent patch, but I'll modify that as well, give it a spin and
> submit V2.

If you are spinning a v2, please pull current out into a variable at the
start (more efficient), and atomic_read() doesn't need spaces inside.

~Andrew

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Wed, Feb 8, 2017 at 9:58 AM, Julien Grall  wrote:

> Hi Tamas,
>
> On 08/02/17 16:40, Tamas K Lengyel wrote:
>
>> On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
>> > wrote:
>> On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
>> > On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall > > wrote:
>> I considered this approach a bit but it has several problems IMO.
>> These may not be unsolvable or even problems for monitoring but
>> they do introduce complexity into the solution.
>>
>> 1. Some SMC calls may depend on the core they are issued from.
>>If taking a detour to dom0, this becomes messy to guarantee.
>>
>> 2. Overall complexity increases very significantly and it becomes
>>quite hard to follow/review how these calls get handled.
>>In particular once you consider solving #1.
>>
>> 3. There are certain calls that perhaps not even dom0 should have
>>direct access to. This means that Xen may need to filter some of
>>them anyway.
>>
>> Some examples may be:
>>
>> SMC calls:
>> * To directly turn off or suspend cores
>> * To turn off DDR or RAMs that Xen is using
>> * To a solution specific Trusted OS pinned to a specific core
>> * For PSCI
>> * Etc
>>
>> I would prefer if we could find a way for monitoring to play nicely
>> with Xen implementing the SMC mediators.
>> Perhaps we could allow calls that Xen consumes to be
>> monitored/inspected
>> but not modified. Or there might be other ways.
>>
>> Best regards,
>> Edgar
>>
>>
>> Hi Edgar,
>> certainly there are many cases where the system would become very
>> complex when there is functionality like what you describe in the TZ
>> that needs to be made accessible via SMC. The setup I described is
>> experimental only, and the underlying assumption is that the TZ is
>> working jointly with the monitor application (ie. both are aware of each
>> other). So it is really not intended to work with just any firmware.
>>
>
> How do you expect TrustZone to work with the monitor application? If you
> think about modifying Trustzone, it seems a requirement difficult to
> achieve as some Trusted OS are proprietary or difficult to replace on a
> phone.
>

It is not intended to work with just any TrustZone. In the proposed system
the TZ is specifically designed to minimize the codebase that is running at
that privilege level. We mostly envisioned critical integrity and security
checks to be in the TZ while all "normal" TZ applications would be
delegated to VMs - still protected from the untrusted guest, but a
potential exploit would just land the attacker in another VM rather then
the TZ. At the moment it is just an experimental setup, so I don't expect
it to be a drop-in solution for off-the-shelf phones in the near future.


>
>
>> So I think for the sake of reducing complexity, having the monitor
>> system be exclusive when enabled should make everyone's life simpler.
>> Having a passive monitoring mode as you suggest is certainly an option,
>> although it should not be the only option, exclusive routing of SMCs
>> through monitor applications should still be available to be configured
>> by the user. Since I really don't know of any usecases where passive
>> monitoring of SMCs is required, I don't think we should go that route.
>>
>
> I see the SMC trap similar to a register trap. The monitor app will look
> at the register value and potentially modify it. What would be the issue to
> do the same for SMC?
>

I don't see an issue with the monitor application modifying register values
on a trapped SMC. The issue I have is if the SMC is still forwarded to the
firmware by Xen afterwards. In the usecase I described the firmware should
under no situation be accessible from an untrusted guest directly.


>
> I think a such model would fit the requirement for everyone. The monitor
> app can filter if necessary, and Xen would handle the mediation between
> multiple guests. I would also recommend to read the thread about OP-TEE
> support in Xen (see [1]).
>

Just modifying registers would not really accomplish filtering. We could
introduce a vm_event response flag so the monitor application would be able
to tell Xen whether it's OK to forward the SMC to the firmware or not. That
is an option, even if I don't have a usecase for it.

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

Re: [Xen-devel] [PATCH] x86/mm: Alter is_xen_fixed_mfn() to use mfn_t

[George Dunlap]

On 08/02/17 13:07, Jan Beulich wrote:
 On 07.02.17 at 19:57,  wrote:
>> --- a/xen/include/xen/mm.h
>> +++ b/xen/include/xen/mm.h
>> @@ -599,4 +599,10 @@ static inline void filtered_flush_tlb_mask(uint32_t 
>> tlbflush_timestamp)
>>  }
>>  }
>>  
>> +static inline bool is_xen_fixed_mfn(mfn_t mfn)
>> +{
>> +return (pfn_to_paddr(mfn_x(mfn)) >= __pa(&_start) &&
>> +pfn_to_paddr(mfn_x(mfn)) <= __pa(&_end));
>> +}
> 
> Even if you only morph what's been there before, I do think the
> latter wants to be < instead of <= . With that adjusted
> Reviewed-by: Jan Beulich 
> but I'm also unconvinced it wouldn't be better to compare PFNs
> instead of physical addresses here.

Not positive this falls under my remit but just in case:

Acked-by: George Dunlap 

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

Re: [Xen-devel] [PATCH] xenbus: Neaten xenbus_va_dev_error

[Boris Ostrovsky]

On 02/08/2017 11:05 AM, Joe Perches wrote:
> On Wed, 2017-02-08 at 10:33 -0500, Boris Ostrovsky wrote:
>> On 02/08/2017 06:33 AM, Joe Perches wrote:
>>> This function error patch can be simplified, so do so.
>>>
>>> Remove fail: label and somewhat obfuscating, used once "error_path"
>>> function.
> btw: I left it alone, but likely
>
> #define PRINTF_BUFFER_SIZE 4096
>
> is probably excessive as the maximum printk
> buffer is 1024.
>
> The xenbus_write might be longer though so
> maybe it's OK to use 4096, but there is some
> inequivalence there.
>

xenbus_write() handles writes up to 4K. However we are filling the
buffer with sprintf() which I assume is limited to 1K too so it indeed
doesn't seem useful to have PRINTF_BUFFER_SIZE set to 4.

-boris


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

Re: [Xen-devel] [PATCH] common/vm_event: Prevent guest locking with large max_vcpus

[Razvan Cojocaru]

On 02/08/2017 06:25 PM, Tamas K Lengyel wrote:
> 
> 
> On Wed, Feb 8, 2017 at 2:00 AM, Razvan Cojocaru
> > wrote:
> 
> It is currently possible for the guest to lock when subscribing
> to synchronous vm_events if max_vcpus is larger than the
> number of available ring buffer slots. This patch no longer
> blocks already paused VCPUs, fixing the issue for this use
> case.
> 
> Signed-off-by: Razvan Cojocaru  >
> ---
>  xen/common/vm_event.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 82ce8f1..2005a64 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -316,7 +316,8 @@ void vm_event_put_request(struct domain *d,
>   * See the comments above wake_blocked() for more information
>   * on how this mechanism works to avoid waiting. */
>  avail_req = vm_event_ring_available(ved);
> -if( current->domain == d && avail_req < d->max_vcpus )
> +if( current->domain == d && avail_req < d->max_vcpus &&
> +!atomic_read( >vm_event_pause_count ) )
>  vm_event_mark_and_pause(current, ved);
> 
> 
> Hi Razvan,
> I would also like to have the change made in this patch that unblocks
> the vCPUs as soon as a spot opens up on the ring. Doing just what this
> patch has will not solve the problem if there are asynchronous events used.

Fair enough, I thought that might need more discussion and thus put into
a subsequent patch, but I'll modify that as well, give it a spin and
submit V2.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v6] x86/iommu: add IOMMU entries for p2m_mmio_direct pages

[George Dunlap]

On 07/02/17 17:28, Roger Pau Monne wrote:
> There's nothing wrong with allowing the domain to perform DMA transfers to
> MMIO areas that it already can access from the CPU, and this allows us to
> remove the hack in set_identity_p2m_entry for PVH Dom0.
> 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Andrew Cooper 
> Reviewed-by: Kevin Tian 

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

[Jan Beulich]

>>> On 08.02.17 at 08:31,  wrote:
>>  From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, February 06, 2017 11:38 PM
>> 
>> >>> On 06.02.17 at 15:48,  wrote:
>> > On Mon, 2017-02-06 at 07:26 -0700, Jan Beulich wrote:
>> >> >
>> >> > >
>> >> > > >
>> >> > > > On 06.02.17 at 14:55,  wrote:
>> >> > Switch its return type to bool to match its use, and simplify the
>> >> > ARM
>> >> > implementation slightly.
>> >> >
>> >> > No functional change.
>> >> >
>> >> > Signed-off-by: Andrew Cooper 
>> >> Reviewed-by: Jan Beulich 
>> >>
>> >> And perhaps that's what should be used in epte_get_entry_emt()
>> >> instead of !mfn_valid() in David's patch. David, would you be okay
>> >> with your patch changed to that effect upon commit?
>> >
>> > I don't think that works, at least not literally
>> > s/!mfn_valid()/is_iomem_page()/
>> >
>> > In my patch, mfn_valid() is checked *after* we've processed the
>> > 'direct_mmio' case that all MMIO should hit. In a sane world I think
>> > it's *only* actually catching INVALID_MFN, and probably should never
>> > match on any other value of mfn.
>> >
>> > I don't quite understand why we pass 'direct_mmio' in as a separate
>> > argument. Perhaps there's scope for doing a sanity check that
>> > 'direct_mmio == is_iomem_page(mfn)' — because when would that *not* be
>> > true?
>> 
>> Likely never. The reasons for why this was done the way it is
>> escape me. Adding VMX maintainers once again.
> 
> I'm not the original author of that code. Here is what I found from the 
> code:
> 
> There are two places caring direct_mmio: resolve_misconfig and ept_
> set_entry. It's decided upon p2m type:
> 
>   int emt = epte_get_entry_emt(p2m->domain, gfn, _mfn(e.mfn),
> level * EPT_TABLE_ORDER, ,
> e.sa_p2mt == p2m_mmio_direct);
> 
> I'm not sure whether p2m_mmio_direct always makes is_iomem_page
> true. If true then yes we may not require this parameter at all.

From an abstract perspective the two should always correlate. We
may want to take an intermediate step though and first only add
checking, and perhaps a release later remove the extra parameter
if the check never triggered for anyone.

Jan

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

Re: [Xen-devel] [libvirt] [PATCH 2/2] libxl: fix dom0 maximum memory setting

[Joao Martins]

On 02/08/2017 04:06 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> On 02/02/2017 10:31 PM, Jim Fehlig wrote:
>>> When the libxl driver is initialized, it creates a virDomainDef
>>> object for dom0 and adds it to the list of domains. Total memory
>>> for dom0 was being set from the max_memkb field of libxl_dominfo
>>> struct retrieved from libxl, but this field can be set to
>>> LIBXL_MEMKB_DEFAULT (~0ULL) if dom0 maximum memory has not been
>>> explicitly set by the user.
>>>
>>> This patch adds some simple parsing of the Xen commandline,
>>> looking for a dom0_mem parameter that also specifies a 'max' value.
>>> If not specified, dom0 maximum memory is effectively all physical
>>> host memory.
>>>
>>> Signed-off-by: Jim Fehlig 
>>> ---
>>>  src/libxl/libxl_conf.c   | 75 
>>> 
>>>  src/libxl/libxl_conf.h   |  3 ++
>>>  src/libxl/libxl_driver.c |  2 +-
>>>  3 files changed, 79 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
>>> index b5186f2..bfe0e92 100644
>>> --- a/src/libxl/libxl_conf.c
>>> +++ b/src/libxl/libxl_conf.c
>>> @@ -34,6 +34,7 @@
>>>  #include "internal.h"
>>>  #include "virlog.h"
>>>  #include "virerror.h"
>>> +#include "c-ctype.h"
>>>  #include "datatypes.h"
>>>  #include "virconf.h"
>>>  #include "virfile.h"
>>> @@ -1530,6 +1531,80 @@ int libxlDriverConfigLoadFile(libxlDriverConfigPtr 
>>> cfg,
>>>  
>>>  }
>>>  
>>> +/*
>>> + * dom0's maximum memory can be controled by the user with the 'dom0_mem' 
>>> Xen
>>> + * command line parameter. E.g. to set dom0's initial memory to 4G and max
>>> + * memory to 8G: dom0_mem=4G,max:8G
>>> + *
>>> + * If not constrained by the user, dom0 can effectively use all host 
>>> memory.
>>> + * This function returns the configured maximum memory for dom0 in 
>>> kilobytes,
>>> + * either the user-specified value or total physical memory as a default.
>>> + */
>>> +unsigned long long
>>> +libxlDriverGetDom0MaxmemConf(libxlDriverConfigPtr cfg)
>>> +{
>>> +char **cmd_tokens = NULL;
>>> +char **mem_tokens = NULL;
>>> +size_t i;
>>> +size_t j;
>>> +unsigned long long ret;
>>> +libxl_physinfo physinfo;
>>> +
>>> +if (cfg->verInfo->commandline == NULL ||
>>> +!(cmd_tokens = virStringSplit(cfg->verInfo->commandline, " ", 0)))
>>> +goto physmem;
>>> +
>>> +for (i = 0; cmd_tokens[i] != NULL; i++) {
>>> +if (!STRPREFIX(cmd_tokens[i], "dom0_mem="))
>>> +continue;
>>> +
>>> +if (!(mem_tokens = virStringSplit(cmd_tokens[i], ",", 0)))
>>> +break;
>>> +for (j = 0; mem_tokens[j] != NULL; j++) {
>>> +if (STRPREFIX(mem_tokens[j], "max:")) {
>>> +char *p = mem_tokens[j] + 4;
>>> +unsigned long long multiplier = 1;
>>> +
>>> +while (c_isdigit(*p))
>>> +p++;
>>> +if (virStrToLong_ull(mem_tokens[j] + 4, , 10, ) < 0)
>>> +break;
>>> +if (*p) {
>>> +switch (*p) {
>>> +case 'k':
>>> +case 'K':
>>> +multiplier = 1024;
>>> +break;
>>> +case 'm':
>>> +case 'M':
>>> +multiplier = 1024 * 1024;
>>> +break;
>>> +case 'g':
>>> +case 'G':
>>> +multiplier = 1024 * 1024 * 1024;
>>> +break;
>>> +}
>>> +}
>>> +ret = (ret * multiplier) / 1024;
>>> +goto cleanup;
>>> +}
>>> +}
>>> +}
>>> +
>>> + physmem:
>>> +/* No 'max' specified in dom0_mem, so dom0 can use all physical memory 
>>> */
>>> +libxl_physinfo_init();
>>> +libxl_get_physinfo(cfg->ctx, );
>> Despite being an unlikely event, libxl_get_physinfo can fail here - I think 
>> you
>> need to check the return value here.
> 
> Bummer. I was hoping this function could always return a sane value for dom0 
> max
> memory. But I'm not really sure what that would be if libxl_get_physinfo 
> failed.
> 
Yeah, We probably have some serious concerns if this fails. And given that
libxlAddDom0 happens early while bootstrapping the libxl module, it might be
good to warn the user (following similar pattern throughout the rest of the 
code):

virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
   _("libxl_get_physinfo_info failed"));

or perhaps simply VIR_WARN?

>>> +ret = (physinfo.total_pages * cfg->verInfo->pagesize) / 1024;
>>> +libxl_physinfo_dispose();
>>> +
>>> + cleanup:
>>> +virStringListFree(cmd_tokens);
>>> +virStringListFree(mem_tokens);
>>> +return ret;
>>> +}
>>> +
>>> +
>>>  #ifdef LIBXL_HAVE_DEVICE_CHANNEL
>>>  static int
>>>  libxlPrepareChannel(virDomainChrDefPtr channel,
>>> diff --git 

[Xen-devel] [linux-next test] 105633: regressions - FAIL

[osstest service owner]

flight 105633 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105633/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm   17 guest-localmigrate/x10   fail REGR. vs. 105625
 test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 105625
 test-amd64-i386-xl   17 guest-localmigrate/x10   fail REGR. vs. 105625

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10  fail blocked in 105625
 test-amd64-amd64-xl-rtds 14 guest-saverestore   fail blocked in 105625
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail blocked in 
105625
 test-armhf-armhf-libvirt   13 saverestore-support-check fail blocked in 105625
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail blocked in 
105625
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 105625
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail like 105625
 test-amd64-amd64-xl-xsm  17 guest-localmigrate/x10   fail  like 105625
 test-amd64-amd64-xl  17 guest-localmigrate/x10   fail  like 105625
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105625
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105625
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105625
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105625

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-xsm  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-amd64-amd64-libvirt-vhd 11 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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-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
 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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 linuxe3e6c5f3544c5d05c6b3b309a34f4f2c3537e993
baseline version:
 linux926af6273fc683cd98cd0ce7bf0d04a02eed6742

Last test of basis  (not found) 
Failing since 0  1970-01-01 00:00:00 Z 17205 

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

[Jan Beulich]

>>> On 08.02.17 at 17:48,  wrote:
> On Fri, 2017-02-03 at 08:40 -0700, Jan Beulich wrote:
>> > > > > > On 17.01.17 at 18:26,  wrote:
>> > > While I did manage to backport "xen: credit2: use the correct
>> > > scratch
>> > > cpumask" and "xen: credit2: fix shutdown/suspend when playing
>> > > with
>> > > cpupools" also to 4.7, this one is even worse for me to deal with
>> > > (purely by its subject I'd assume it's applicable): Its first
>> > > hunk
>> > > applies
>> > > fine, but then everything breaks.
>> > > 
>> > I see. Sorry for that.
>> > 
>> > Is it ok if I give it a try myself and, if I manage, send you the
>> > backported patch?
>> 
>> Yes, I should probably have phrased my earlier reply that way.
>> 
> Well, I only wanted to double check whether you were meaning "please
> provide backport" or "let's give up". :-)
> 
> But now that I'm looking into this, I need to double check something
> again. So, as far as I've understood, you want the following 3 patches
> to be backported to both 4.8 and 4.7:
> 
>  xen: credit2: use the correct scratch cpumask
>  xen: credit2: fix shutdown/suspend when playing with cpupools
>  xen: credit2: never consider CPUs outside of our cpupool
> 
> And you're saying you already have done some of them, but I don't seem
> to be able to find _any_ of them in any of the following branches:
> 
>   staging-4.8 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/staging-4.8 
>   stable-4.8 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 
>   staging-4.7 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/staging-4.7 
>   stable-4.7 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 
> 
> Am I looking in the wrong places / misunderstood anything?

Well, me having done the backports didn't imply me committing them
right away; I wanted them to first undergo some testing. I hope to
get to that tomorrow. If you want to wait for what I have to appear
there, that's of course fine.

Jan


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

Re: [Xen-devel] [PATCH 0/9] libxl: spolit up libxl.c

[Wei Liu]

And CC Zhangchen

On Wed, Feb 08, 2017 at 02:35:27PM +, Wei Liu wrote:
> Cc Yi Sun as well.
> 
> Haozhong and Yi: This is just a heads-up -- Juergen from SuSE took the
> time to split libxl.c so things are better organised. It's likely this
> series will go in before yours, so you will then need to rebase your
> series. I don't expect there to be much breakage because it is all
> mechanical, but rebasing is still work for you.
> 
> Let us know if you have any concern so that we can coordinate this.
> 
> Wei.
> 
> On Wed, Feb 08, 2017 at 02:13:37PM +0100, Juergen Gross wrote:
> > libxl.c has become rather large. Split it up into multiple files.
> > 
> > Code movement only. No functional change intended.
> > 
> > Juergen Gross (9):
> >   libxl: adjust copyright comment of libxl.c
> >   libxl: carve out cpupool specific functions from libxl.c
> >   libxl: carve out scheduler specific functions from libxl.c
> >   libxl: carve out disk specific functions from libxl.c
> >   libxl: carve out console specific functions from libxl.c
> >   libxl: carve out memory specific functions from libxl.c
> >   libxl: move device specific functions out of libxl.c
> >   libxl: carve out tmem specific functions from libxl.c
> >   libxl: carve out domain specific functions from libxl.c
> > 
> >  tools/libxl/Makefile |4 +-
> >  tools/libxl/libxl.c  | 6252 
> > +-
> >  tools/libxl/libxl_console.c  |  862 ++
> >  tools/libxl/libxl_cpupool.c  |  443 +++
> >  tools/libxl/libxl_device.c   |  435 ++-
> >  tools/libxl/libxl_disk.c | 1258 +
> >  tools/libxl/libxl_domain.c   | 1744 
> >  tools/libxl/libxl_internal.h |8 +-
> >  tools/libxl/libxl_mem.c  |  601 
> >  tools/libxl/libxl_sched.c|  915 +++
> >  tools/libxl/libxl_tmem.c |  167 ++
> >  11 files changed, 6424 insertions(+), 6265 deletions(-)
> >  create mode 100644 tools/libxl/libxl_console.c
> >  create mode 100644 tools/libxl/libxl_cpupool.c
> >  create mode 100644 tools/libxl/libxl_disk.c
> >  create mode 100644 tools/libxl/libxl_domain.c
> >  create mode 100644 tools/libxl/libxl_mem.c
> >  create mode 100644 tools/libxl/libxl_sched.c
> >  create mode 100644 tools/libxl/libxl_tmem.c
> > 
> > -- 
> > 2.10.2
> > 

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

Re: [Xen-devel] unmodified drivers

[Juergen Gross]

On 08/02/17 17:41, Jan Beulich wrote:
 On 08.02.17 at 17:32,  wrote:
>> Is it still appropriate to have the unmodified_drivers subdirectory in
>> Xen's git repository?
>>
>> I think it should be either moved to a separate repository or just
>> deleted.
> 
> Having a separate repo for these few files would seem overkill to
> me. As to deleting them - I'd prefer them to still stay around for a
> little while, but of course if everyone wants them gone I can do
> with keeping a local copy somewhere.

I don't think a local copy would be necessary. Everything will be
available in old branches.

There are lots of small repositories on xenbits.xen.org. Why not
move the drivers to a new one if you want to keep it?

>> Having Linux kernel sources in the Xen repository seems to be
>> wrong.
> 
> The original idea (as can be seen from the tree layout) was for
> them to not necessarily stay there alone.

Right. Windows pv drivers have their repositories, too.


Juergen

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Julien Grall]

Hi Tamas,

On 08/02/17 16:40, Tamas K Lengyel wrote:

On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias
> wrote:
On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
> On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall > wrote:
I considered this approach a bit but it has several problems IMO.
These may not be unsolvable or even problems for monitoring but
they do introduce complexity into the solution.

1. Some SMC calls may depend on the core they are issued from.
   If taking a detour to dom0, this becomes messy to guarantee.

2. Overall complexity increases very significantly and it becomes
   quite hard to follow/review how these calls get handled.
   In particular once you consider solving #1.

3. There are certain calls that perhaps not even dom0 should have
   direct access to. This means that Xen may need to filter some of
   them anyway.

Some examples may be:

SMC calls:
* To directly turn off or suspend cores
* To turn off DDR or RAMs that Xen is using
* To a solution specific Trusted OS pinned to a specific core
* For PSCI
* Etc

I would prefer if we could find a way for monitoring to play nicely
with Xen implementing the SMC mediators.
Perhaps we could allow calls that Xen consumes to be monitored/inspected
but not modified. Or there might be other ways.

Best regards,
Edgar


Hi Edgar,
certainly there are many cases where the system would become very
complex when there is functionality like what you describe in the TZ
that needs to be made accessible via SMC. The setup I described is
experimental only, and the underlying assumption is that the TZ is
working jointly with the monitor application (ie. both are aware of each
other). So it is really not intended to work with just any firmware.


How do you expect TrustZone to work with the monitor application? If you 
think about modifying Trustzone, it seems a requirement difficult to 
achieve as some Trusted OS are proprietary or difficult to replace on a 
phone.




So I think for the sake of reducing complexity, having the monitor
system be exclusive when enabled should make everyone's life simpler.
Having a passive monitoring mode as you suggest is certainly an option,
although it should not be the only option, exclusive routing of SMCs
through monitor applications should still be available to be configured
by the user. Since I really don't know of any usecases where passive
monitoring of SMCs is required, I don't think we should go that route.


I see the SMC trap similar to a register trap. The monitor app will look 
at the register value and potentially modify it. What would be the issue 
to do the same for SMC?


I think a such model would fit the requirement for everyone. The monitor 
app can filter if necessary, and Xen would handle the mediation between 
multiple guests. I would also recommend to read the thread about OP-TEE 
support in Xen (see [1]).


Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg02220.html


--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

[Dario Faggioli]

On Fri, 2017-02-03 at 08:40 -0700, Jan Beulich wrote:
> > > > > > On 17.01.17 at 18:26,  wrote:
> > > While I did manage to backport "xen: credit2: use the correct
> > > scratch
> > > cpumask" and "xen: credit2: fix shutdown/suspend when playing
> > > with
> > > cpupools" also to 4.7, this one is even worse for me to deal with
> > > (purely by its subject I'd assume it's applicable): Its first
> > > hunk
> > > applies
> > > fine, but then everything breaks.
> > > 
> > I see. Sorry for that.
> > 
> > Is it ok if I give it a try myself and, if I manage, send you the
> > backported patch?
> 
> Yes, I should probably have phrased my earlier reply that way.
> 
Well, I only wanted to double check whether you were meaning "please
provide backport" or "let's give up". :-)

But now that I'm looking into this, I need to double check something
again. So, as far as I've understood, you want the following 3 patches
to be backported to both 4.8 and 4.7:

 xen: credit2: use the correct scratch cpumask
 xen: credit2: fix shutdown/suspend when playing with cpupools
 xen: credit2: never consider CPUs outside of our cpupool

And you're saying you already have done some of them, but I don't seem
to be able to find _any_ of them in any of the following branches:

  staging-4.8 
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/staging-4.8
  stable-4.8 
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8
  staging-4.7 
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/staging-4.7
  stable-4.7 
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7

Am I looking in the wrong places / misunderstood anything?

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 05/24] x86: refactor psr: implement Domain init/free and schedule flows.

[Konrad Rzeszutek Wilk]

On Wed, Feb 08, 2017 at 04:15:57PM +0800, Yi Sun wrote:
> This patch implements the Domain init/free and schedule flows.
> 
> Signed-off-by: Yi Sun 

Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] unmodified drivers

[Jan Beulich]

>>> On 08.02.17 at 17:32,  wrote:
> Is it still appropriate to have the unmodified_drivers subdirectory in
> Xen's git repository?
> 
> I think it should be either moved to a separate repository or just
> deleted.

Having a separate repo for these few files would seem overkill to
me. As to deleting them - I'd prefer them to still stay around for a
little while, but of course if everyone wants them gone I can do
with keeping a local copy somewhere.

> Having Linux kernel sources in the Xen repository seems to be
> wrong.

The original idea (as can be seen from the tree layout) was for
them to not necessarily stay there alone.

Jan


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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Wed, Feb 8, 2017 at 1:31 AM, Edgar E. Iglesias  wrote:

> On Tue, Feb 07, 2017 at 05:24:03PM -0700, Tamas K Lengyel wrote:
> > On Tue, Feb 7, 2017 at 1:51 PM, Julien Grall 
> wrote:
> >
> > > Hi Tamas,
> > >
> > > On 07/02/2017 20:38, Tamas K Lengyel wrote:
> > >
> > >>
> > >>
> > >> On Tue, Feb 7, 2017 at 12:42 PM, Edgar E. Iglesias
> > >> > wrote:
> > >>
> > >> From: "Edgar E. Iglesias"  > >> >
> > >>
> > >> Allow platform_hvc to handle guest SMC calls (as well as
> > >> HVC calls) in a platform specific way.
> > >>
> > >> Signed-off-by: Edgar E. Iglesias  > >> >
> > >> ---
> > >>  xen/arch/arm/traps.c | 5 +
> > >>  1 file changed, 5 insertions(+)
> > >>
> > >> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > >> index 33950d9..1bedc6e 100644
> > >> --- a/xen/arch/arm/traps.c
> > >> +++ b/xen/arch/arm/traps.c
> > >> @@ -2623,6 +2623,11 @@ static void do_trap_smc(struct
> cpu_user_regs
> > >> *regs, const union hsr hsr)
> > >>  if ( current->domain->arch.monitor.privileged_call_enabled )
> > >>  rc = monitor_smc();
> > >>
> > >>
> > >> I think you should check that rc is still 0 at this point as the vCPU
> > >> might already be paused and the event forwarded to a monitor
> subscriber.
> > >>
> > >
> > > SMC are used to access the secure firmware (e.g power management) and
> will
> > > be used by the guest to access the secure firmware. Today, the code is
> > > expecting all event to be trapped by the monitor app and software
> emulated.
> > > However, some SMCs may be needed to be forwarded to the secure
> firmware,
> > > how do you expect it to work together?
> > >
> > > It is something I already brought up when SMC trap was added and it is
> > > probably time to figure out what to do because this will not be the
> first
> > > series bringing the problem. For instance if you want to do video
> decoding
> > > or even payment on Android you may need to access the secure firmware
> for
> > > cryptography. At the same time, you also want to be able to monitor
> your
> > > guest.
> > >
> >
> >
> > Hi Julien,
> > monitoring SMCs using the monitor system should be incompatible with Xen
> > routing the SMCs elsewhere. Since the monitor system is disabled by
> default
> > I think this should be fine for everyone and not get in the way of people
> > accessing the firmware in other usecases or routing SMCs elsewhere as
> > needed.
> >
> > As for applications that want to use SMC monitoring but also access the
> > firmware, it can be accomplished by the monitor application on behalf of
> > the VM.  While this adds a detour, this detour is by design as it adds a
> > layer between untrusted VMs and the TZ so that any potential exploit
> > targeting the TZ would first have to go through the monitor application
> > (see https://www.sec.in.tum.de/publications/publication/322 for more
> info
> > on the idea).
>
> I considered this approach a bit but it has several problems IMO.
> These may not be unsolvable or even problems for monitoring but
> they do introduce complexity into the solution.
>
> 1. Some SMC calls may depend on the core they are issued from.
>If taking a detour to dom0, this becomes messy to guarantee.
>
> 2. Overall complexity increases very significantly and it becomes
>quite hard to follow/review how these calls get handled.
>In particular once you consider solving #1.
>
> 3. There are certain calls that perhaps not even dom0 should have
>direct access to. This means that Xen may need to filter some of
>them anyway.
>
> Some examples may be:
>
> SMC calls:
> * To directly turn off or suspend cores
> * To turn off DDR or RAMs that Xen is using
> * To a solution specific Trusted OS pinned to a specific core
> * For PSCI
> * Etc
>
> I would prefer if we could find a way for monitoring to play nicely
> with Xen implementing the SMC mediators.
> Perhaps we could allow calls that Xen consumes to be monitored/inspected
> but not modified. Or there might be other ways.
>
> Best regards,
> Edgar
>

Hi Edgar,
certainly there are many cases where the system would become very complex
when there is functionality like what you describe in the TZ that needs to
be made accessible via SMC. The setup I described is experimental only, and
the underlying assumption is that the TZ is working jointly with the
monitor application (ie. both are aware of each other). So it is really not
intended to work with just any firmware.

So I think for the sake of reducing complexity, having the monitor system
be exclusive when enabled should make everyone's life simpler. Having a
passive monitoring mode as you suggest is certainly an option, although it
should not be the only option, 

[Xen-devel] unmodified drivers

[Juergen Gross]

Is it still appropriate to have the unmodified_drivers subdirectory in
Xen's git repository?

I think it should be either moved to a separate repository or just
deleted. Having Linux kernel sources in the Xen repository seems to be
wrong.

Thoughts?


Juergen

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

Re: [Xen-devel] [PATCH] common/vm_event: Prevent guest locking with large max_vcpus

[Tamas K Lengyel]

On Wed, Feb 8, 2017 at 2:00 AM, Razvan Cojocaru 
wrote:

> It is currently possible for the guest to lock when subscribing
> to synchronous vm_events if max_vcpus is larger than the
> number of available ring buffer slots. This patch no longer
> blocks already paused VCPUs, fixing the issue for this use
> case.
>
> Signed-off-by: Razvan Cojocaru 
> ---
>  xen/common/vm_event.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
> index 82ce8f1..2005a64 100644
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -316,7 +316,8 @@ void vm_event_put_request(struct domain *d,
>   * See the comments above wake_blocked() for more information
>   * on how this mechanism works to avoid waiting. */
>  avail_req = vm_event_ring_available(ved);
> -if( current->domain == d && avail_req < d->max_vcpus )
> +if( current->domain == d && avail_req < d->max_vcpus &&
> +!atomic_read( >vm_event_pause_count ) )
>  vm_event_mark_and_pause(current, ved);
>

Hi Razvan,
I would also like to have the change made in this patch that unblocks the
vCPUs as soon as a spot opens up on the ring. Doing just what this patch
has will not solve the problem if there are asynchronous events used.

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

[Xen-devel] [xen-unstable baseline-only test] 68534: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68534 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68534/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail REGR. vs. 68533

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
REGR. vs. 68533
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 68533
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 68533
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68533
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) fail like 68533
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 68533
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 68533
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 68533
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 68533

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-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-amd64-i386-libvirt  12 migrate-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
 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  63e1d01b8fd948b3e0fa3beea494e407668aa43b
baseline version:
 xen  2733b800c9a2086d46379d3eb3f480eb5fd433ea

Last test of basis68533  2017-02-07 16:45:24 Z0 days
Testing same since68534  2017-02-08 07:23:10 Z0 days1 attempts

Re: [Xen-devel] [PATCH] xen/p2m: Remove np2m-specific filter from generic p2m_flush_table

[George Dunlap]

On 08/02/17 10:02, Tim Deegan wrote:
> At 03:44 -0700 on 31 Jan (1485834259), Jan Beulich wrote:
> On 30.01.17 at 16:17,  wrote:
>>> Commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159 added flushing of
>>> nested p2m tables whenever the host p2m table changed.  Unfortunately
>>> in the process, it added a filter to the generic p2m_flush_table()
>>> function so that the p2m would only be flushed if it was being used as
>>> a nested p2m.  This meant that the p2m was not being flushed at all
>>> for altp2m callers.
>>>
>>> Instead do the nested p2m filtering in p2m_flush_nestedp2m().
> 
> I think it would be better to fix the test in p2m_flush_table() so it
> understands altp2m's use of tables.  That way we won't have to deal
> with filtering at other call sites, as Jan points out.  Also, this:
> 
>>>  for ( i = 0; i < MAX_NESTEDP2M; i++ )
>>> -p2m_flush_table(d->arch.nested_p2m[i]);
>>> +{
>>> +struct p2m_domain *p2m = d->arch.nested_p2m[i];
>>> +if ( p2m->np2m_base != P2M_BASE_EADDR )
>>> +p2m_flush_table(p2m);
>>> +}
> 
> moves the check of np2m_base outside the lock.  That might be OK but
> it's definitely a bit subtle.

Hrm, yes that's not so great.  v2 coming up.

 -George

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

Re: [Xen-devel] [PATCH v6 04/24] x86: refactor psr: implement CPU init and free flow.

[Konrad Rzeszutek Wilk]

.snip..
> +static void free_feature(struct psr_socket_info *info)
> +{
> +struct feat_node *feat, *next;
> +
> +if ( !info )
> +return;
> +
> +/*
> + * Free resources of features. But we do not free global feature list
> + * entry, like feat_l3_cat. Although it may cause a few memory leak,
> + * it is OK simplify things.

it is OK as it simplifies things.
> + */
> +list_for_each_entry_safe(feat, next, >feat_list, list)
> +{
> +__clear_bit(feat->feature, >feat_mask);
> +list_del(>list);
> +xfree(feat);
> +}
> +}
> +
> +/* L3 CAT functions implementation. */
> +static void l3_cat_init_feature(struct cpuid_leaf regs,
> +struct feat_node *feat,
> +struct psr_socket_info *info)
> +{
> +struct psr_cat_hw_info l3_cat;

Having experienced a few times myself forgetting to set
_all_ the entries a structure allocated on the stack and then
debugging for hours - perhaps you could do:

l3_cat = { };

Which forces the compiler to initialize _all_ the values to zero.
> +unsigned int socket;
> +
> +/* No valid value so do not enable feature. */
> +if ( !regs.a || !regs.b )

You use regs.d below. Would it make sense to check for that value as
well?

Or is a value of 0 for cox_max OK? I would think so, but not exactly
sure.

> +return;
> +
> +l3_cat.cbm_len = (regs.a & CAT_CBM_LEN_MASK) + 1;
> +l3_cat.cos_max = min(opt_cos_max, regs.d & CAT_COS_MAX_MASK);
> +
> +/* cos=0 is reserved as default cbm(all bits within cbm_len are 1). */
> +feat->cos_reg_val[0] = (1ull << l3_cat.cbm_len) - 1;
> +
> +feat->feature = PSR_SOCKET_L3_CAT;
> +ASSERT(!test_bit(PSR_SOCKET_L3_CAT, >feat_mask));
> +__set_bit(PSR_SOCKET_L3_CAT, >feat_mask);
> +
> +feat->info.l3_cat_info = l3_cat;
> +
> +info->nr_feat++;
> +
> +/* Add this feature into list. */
> +list_add_tail(>list, >feat_list);
> +
> +socket = cpu_to_socket(smp_processor_id());
> +if ( !opt_cpu_info )
> +return;
> +
> +printk(XENLOG_INFO "L3 CAT: enabled on socket %u, cos_max:%u, 
> cbm_len:%u\n",
> +   socket, feat->info.l3_cat_info.cos_max,
> +   feat->info.l3_cat_info.cbm_len);
> +}
> +
> +static const struct feat_ops l3_cat_ops = {
> +};
> +
>  static void __init parse_psr_bool(char *s, char *value, char *feature,
>unsigned int mask)
>  {
> @@ -180,6 +257,9 @@ static void __init parse_psr_param(char *s)
>  if ( val_str && !strcmp(s, "rmid_max") )
>  opt_rmid_max = simple_strtoul(val_str, NULL, 0);
>  
> +if ( val_str && !strcmp(s, "cos_max") )
> +opt_cos_max = simple_strtoul(val_str, NULL, 0);
> +
>  s = ss + 1;
>  } while ( ss );
>  }
> @@ -335,18 +415,107 @@ void psr_domain_free(struct domain *d)
>  psr_free_rmid(d);
>  }
>  
> +static void cpu_init_work(void)
> +{
> +struct psr_socket_info *info;
> +unsigned int socket;
> +unsigned int cpu = smp_processor_id();
> +struct feat_node *feat;
> +struct cpuid_leaf regs = {.a = 0, .b = 0, .c = 0, .d = 0};
> +
> +if ( !cpu_has(_cpu_data, X86_FEATURE_PQE) )
> +return;
> +else if ( current_cpu_data.cpuid_level < PSR_CPUID_LEVEL_CAT )
> +{
> +__clear_bit(X86_FEATURE_PQE, current_cpu_data.x86_capability);
> +return;
> +}
> +
> +socket = cpu_to_socket(cpu);
> +info = socket_info + socket;
> +if ( info->feat_mask )
> +return;
> +
> +INIT_LIST_HEAD(>feat_list);
> +spin_lock_init(>ref_lock);
> +
> +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 0, );
> +if ( regs.b & PSR_RESOURCE_TYPE_L3 )
> +{
> +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 1, );
> +
> +feat = feat_l3_cat;
> +/* psr_cpu_prepare will allocate it on subsequent CPU onlining. */
> +feat_l3_cat = NULL;
> +feat->ops = l3_cat_ops;
> +
> +l3_cat_init_feature(regs, feat, info);
> +}
> +}
> +
> +static void cpu_fini_work(unsigned int cpu)
> +{
> +unsigned int socket = cpu_to_socket(cpu);
> +
> +if ( !socket_cpumask[socket] || cpumask_empty(socket_cpumask[socket]) )

I fear I don't understand this.

Looking at 65a399ac it says:

+.notifier_call = cpu_callback,
+/*
+ * Ensure socket_cpumask is still valid in CPU_DEAD notification
+ * (E.g. our CPU_DEAD notification should be called ahead of
+ * cpu_smpboot_free).

Which means that socket_cpumask[socket] should have an value.

In fact cpumask_any(socket_cpumask[socket]) will return true at this
point.

Which means that code above gets called if this psr_cpu_fini is called
_after_ cpu_smpboot_free (b/c socket_cpumask[socket] will be NULL), see
cpu_smpboot_free.

But with .priority being -1 that won't happen.

But lets ignore that, lets say it does get called _after_
cpu_smpboot_free. In which case the first part of the 'if' condition
is true and we end up 

[Xen-devel] [ovmf test] 105636: all pass - PUSHED

[osstest service owner]

flight 105636 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105636/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac
baseline version:
 ovmf cc20411062137e5d820a33db73d41f97dae74368

Last test of basis   105631  2017-02-08 07:46:13 Z0 days
Testing same since   105636  2017-02-08 11:45:18 Z0 days1 attempts


People who touched revisions under test:
  Ruiyu Ni 
  Star Zeng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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=ovmf
+ revision=9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac
+ . ./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 /home/osstest/repos/lock ./ap-push ovmf 
9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac
+ branch=ovmf
+ revision=9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac
+ . ./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/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x9fe9cf9acb475af9317dcdaf32a93f1cb77d95ac = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ 

Re: [Xen-devel] [PATCH 0/9] libxl: spolit up libxl.c

[Juergen Gross]

On 08/02/17 17:12, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH 0/9] libxl: spolit up libxl.c"):
>> Okay, more precise wording:
> 
> Thanks.
> 
>> Changes are:
>> - moving functions into new or existing sources
>> - modification of Copyright comment
> 
>> - made two functions non-static: libxl__get_memory_target(),
>>   xcinfo2xlinfo()
>> - made one function static: libxl__device_frontend_path()
> 
> Can you split these out into their own patch(es) ?
> 
>> - removed some trailing spaces in moved code
> 
> And split this one out too ?
> 
> Sorry to be pernickety, but this will make it much easier to check
> what you have done automatically, without trying read the whole thing
> by eye !

Okay.


Juergen


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

Re: [Xen-devel] Enabling vm_event for a guest with more VCPUs than available ring buffer slots freezes the virtual machine

[Tamas K Lengyel]

On Tue, Feb 7, 2017 at 11:48 PM, Razvan Cojocaru 
wrote:

> On 02/08/2017 01:23 AM, Tamas K Lengyel wrote:
> >
> >
> > On Tue, Feb 7, 2017 at 1:41 PM, Razvan Cojocaru
> > > wrote:
> >
> > On 02/07/2017 10:20 PM, Tamas K Lengyel wrote:
> > >
> > >
> > > On Tue, Feb 7, 2017 at 11:57 AM, Razvan Cojocaru
> > > 
> >  > >> wrote:
> > >
> > > On 02/07/2017 08:39 PM, Andrew Cooper wrote:
> > > > On 07/02/17 18:31, Razvan Cojocaru wrote:
> > > >> On 02/07/2017 08:15 PM, Tamas K Lengyel wrote:
> > > >>>
> > > >>> On Tue, Feb 7, 2017 at 9:53 AM, Razvan Cojocaru
> > > >>>  com>
> >  >>
> > >  > 
> > >  >  > > >>>
> > > >>> Hello,
> > > >>>
> > > >>> Setting, e.g. 16 VCPUs for a HVM guest, ends up
> > blocking the
> > > guest
> > > >>> completely when subscribing to vm_events, apparently
> > because
> > > of this
> > > >>> code in xen/common/vm_event.c:
> > > >>>
> > > >>> 315 /* Give this vCPU a black eye if necessary, on
> the
> > > way out.
> > > >>> 316  * See the comments above wake_blocked() for
> more
> > > information
> > > >>> 317  * on how this mechanism works to avoid
> > waiting. */
> > > >>> 318 avail_req = vm_event_ring_available(ved);
> > > >>> 319 if( current->domain == d && avail_req <
> > d->max_vcpus )
> > > >>> 320 vm_event_mark_and_pause(current, ved);
> > > >>>
> > > >>> It would appear that even if the guest only has 2
> online
> > > VCPUs, the
> > > >>> "avail_req < d->max_vcpus" condition will pause
> > current, and we
> > > >>> eventually end up with all the VCPUs paused.
> > > >>>
> > > >>> An ugly hack ("avail_req < 2") has allowed booting a
> guest
> > > with many
> > > >>> VCPUs (max_vcpus, the guest only brings 2 VCPUs
> online),
> > > however that's
> > > >>> just to prove that that was the culprit - a real
> > solution to
> > > this needs
> > > >>> more in-depth understading of the issue and potential
> > > solution. That's
> > > >>> basically very old code (pre-2012 at least) that got
> moved
> > > around into
> > > >>> the current shape of Xen today - please CC anyone
> relevant
> > > to the
> > > >>> discussion that you're aware of.
> > > >>>
> > > >>> Thoughts?
> > > >>>
> > > >>>
> > > >>> I think is a side-effect of the growth of the vm_event
> > structure
> > > and the
> > > >>> fact that we have a single page ring. The check
> > effectively sets a
> > > >>> threshold of having enough space for each vCPU to place at
> > least one
> > > >>> more event on the ring, and if that's not the case it gets
> > > paused. OTOH
> > > >>> I think this would only have an effect on asynchronous
> events,
> > > for all
> > > >>> other events the vCPU is already paused. Is that the case
> > you have?
> > > >> No, on the contrary, all my events are synchronous (the
> VCPU is
> > > paused
> > > >> waiting for the vm_event reply).
> > > >>
> > > >> I've debugged this a bit, and the problem seems to be that
> > > >> vm_event_wake_blocked() breaks here:
> > > >>
> > > >> 150 /* We remember which vcpu last woke up to avoid
> > scanning
> > > always
> > > >> linearly
> > > >> 151  * from zero and starving higher-numbered vcpus
> under
> > > high load */
> > > >> 152 if ( d->vcpu )
> > > >> 153 {
> > > >> 154 int i, j, k;
> > > >> 155
> > > >> 156 for (i = ved->last_vcpu_wake_up + 1, j = 0; j <
> > > >> d->max_vcpus; i++, j++)
> > > >> 157 {
> > > >> 158 k = i % d->max_vcpus;
> > > >> 159 v = d->vcpu[k];
> > > >> 160 if ( !v )
> > > >> 161 continue;
> > > >> 162
> > > >> 163 if ( !(ved->blocked) || online >= avail_req
> )
> > > >> 164break;
> > >   

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

[George Dunlap]

On 08/02/17 16:11, Dario Faggioli wrote:
> On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
>> Callers to libxl_cpupool_create() can either request a specific pool
>> id, or request that Xen do it for them.  But at the moment, the
>> "automatic" selection is indicated by using a magic value, 0.  This
>> is
>> undesirable both because it doesn't obviously have meaning, but also
>> because '0' is a valid cpupool (albeit one which at the moment can't
>> be changed).
>>
>> Introduce a constant, LIBXL_CPUPOOL_POOLID_ANY, to indicate this
>> instead.  Still accept '0' as meaning "ANY" for backwards
>> compatibility.
>>
>> Signed-off-by: George Dunlap 
>>
> Reviewed-by: Dario Faggioli 
> 
> With one remark.
> 
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -2086,6 +2086,12 @@ int libxl_tmem_shared_auth(libxl_ctx *ctx,
>> uint32_t domid, char* uuid,
>>  int libxl_tmem_freeable(libxl_ctx *ctx);
>>  
>>  int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
>> +
>> +/* 
>> + * Set poolid to LIBXL_CPUOOL_POOLID_ANY to have Xen choose a
>> + * free poolid for you.
>> + */
>> +#define LIBXL_CPUPOOL_POOLID_ANY 0x
>>
> Do we want this to be here, or in libxl_types.idl.
> 
> Asking because, AFAICT, it's the only one LIBXL_FOO_BAR defined like
> this. I appreciate that there's few point in making this an enum, as it
> is only one value, and will most likely remain so, but still, I thought
> I'd at least bring this up.
> 
> FWIW, my Reviewed-by stands both if it is kept as is, and if it is
> moved to IDL.

Well there's things like:

#define LIBXL_PCI_FUNC_ALL (~0U)

#define LIBXL_TIMER_MODE_DEFAULT -1
#define LIBXL_MEMKB_DEFAULT ~0ULL

#define LIBXL_RDM_MEM_BOUNDARY_MEMKB_DEFAULT (2048 * 1024)

#define LIBXL_MS_VM_GENID_LEN 16

#define LIBXL_SUSPEND_DEBUG 1
#define LIBXL_SUSPEND_LIVE 2

Many of which seem similar in some ways.  Enums I think are meant to be
exhaustive (as in, contain all possible options), not be special cases.

But I'm happy to defer to the tools maintainers.

 -George

> 
> Regards,
> Dario
> 


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