[Xen-devel] [xen-4.3-testing test] 85979: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 85979 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85979/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   3 host-install(3) broken REGR. vs. 83004
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 83004
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 83004
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 83004
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 83004

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   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-xend-qemut-winxpsp3 20 leak-check/checkfail never pass

version targeted for testing:
 xen  4db81940ee9eb82b3b3895c449ccbbab4a7147a4
baseline version:
 xen  ccc7adf9cff5d5f93720afcc1d0f7227d50feab2

Last test of basis83004  2016-02-18 14:47:44 Z   22 days
Failing since 84923  2016-03-01 13:41:07 Z   10 days   12 attempts
Testing same since85979  2016-03-11 05:16:24 Z1 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Konrad Rzeszutek Wilk 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64fail
 test-amd64-i386-xl-qemut-debianhvm-amd64 fail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64fail
 test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 

[Xen-devel] [ovmf test] 85985: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf c31313da22176002010abbcfcf5d5c5200d182ec
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   94 days
Failing since 65593  2015-12-08 23:44:51 Z   94 days  100 attempts
Testing same since85985  2016-03-11 07:52:52 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  Jordan Justen 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leif Lindholm 
  Liming Gao 
  Mark Rutland 
  Marvin Haeuser 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

[Xen-devel] [linux-3.10 baseline-only test] 44243: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-xsm  19 guest-start/debian.repeat fail REGR. vs. 44220
 test-amd64-amd64-libvirt-vhd 10 guest-start   fail REGR. vs. 44220

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 44220
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 44220
 build-amd64-rumpuserxen   6 xen-buildfail   like 44220
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 44220
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 44220
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 44220
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 44220

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 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-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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux19d0bd71d564448446bd851d752caf3e31520ac8
baseline version:
 linuxe39c17904aadf3a107b2bc292c03bfd9f850fd08

Last test of basis44220  2016-03-05 05:53:23 Z7 days
Testing same since44243  2016-03-11 21:26:39 Z0 days1 attempts


People who touched revisions under test:
  "J. Bruce Fields" 
  Andy Lutomirski 
  Arnd Bergmann 
  Borislav Petkov 
  Christian König 
  Daniele Palmas 
  Dave Airlie 
  David Woodhouse 
  Greg Kroah-Hartman 
  Harvey Hunt 
  Ingo Molnar 
  Jeff Layton 
  Johan Hovold 
  Kamal Mostafa 
  Pavel Shilovsky 
  Rafael J. Wysocki 
  Richard Weinberger 
  Shirish Pargaonkar 
  Soohoon Lee 
  Steve French 
  Takashi Iwai 
  Tejun Heo 
  Thomas Betker 
  Timothy Pearson 
  Todd Brandt 
  Todd E Brandt 
  Vittorio Alfieri 
  Yegor Yefremov 

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 

[Xen-devel] [linux-mingo-tip-master test] 85975: regressions - FAIL

[osstest service owner]

flight 85975 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85975/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 60684
 test-amd64-amd64-libvirt 14 guest-saverestore fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 
60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   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

version targeted for testing:
 linux850b3e382ede311722a4c20805c52ea079ffd92e
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  212 days
Failing since 60712  2015-08-15 18:33:48 Z  209 days  154 attempts
Testing same since85975  2016-03-11 04:27:23 Z1 days1 attempts

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Meng Xu]

I'm focusing on the style and the logic in the replenish handler:

>  /*
> @@ -160,6 +180,7 @@ struct rt_private {
>   */
>  struct rt_vcpu {
>  struct list_head q_elem;/* on the runq/depletedq list */
> +struct list_head replq_elem;/* on the repl event list */

missing space before /*

>
>  /* Up-pointers */
>  struct rt_dom *sdom;
> @@ -213,8 +234,14 @@ static inline struct list_head *rt_depletedq(const 
> struct scheduler *ops)
>  return _priv(ops)->depletedq;
>  }
>
> +static inline struct list_head *rt_replq(const struct scheduler *ops)
> +{
> +return _priv(ops)->replq;
> +}
> +
>  /*
> - * Queue helper functions for runq and depletedq
> + * Helper functions for manipulating the runqueue, the depleted queue,
> + * and the replenishment events queue.
>   */
>  static int
>  __vcpu_on_q(const struct rt_vcpu *svc)
> @@ -228,6 +255,18 @@ __q_elem(struct list_head *elem)
>  return list_entry(elem, struct rt_vcpu, q_elem);
>  }
>
> +static struct rt_vcpu *
> +replq_elem(struct list_head *elem)
> +{
> +return list_entry(elem, struct rt_vcpu, replq_elem);
> +}
> +
> +static int
> +vcpu_on_replq(const struct rt_vcpu *svc)
> +{
> +return !list_empty(>replq_elem);
> +}
> +
>  /*
>   * Debug related code, dump vcpu/cpu information
>   */
> @@ -288,7 +327,7 @@ rt_dump_pcpu(const struct scheduler *ops, int cpu)
>  static void
>  rt_dump(const struct scheduler *ops)
>  {
> -struct list_head *runq, *depletedq, *iter;
> +struct list_head *runq, *depletedq, *replq, *iter;
>  struct rt_private *prv = rt_priv(ops);
>  struct rt_vcpu *svc;
>  struct rt_dom *sdom;
> @@ -301,6 +340,7 @@ rt_dump(const struct scheduler *ops)
>
>  runq = rt_runq(ops);
>  depletedq = rt_depletedq(ops);
> +replq = rt_replq(ops);
>
>  printk("Global RunQueue info:\n");
>  list_for_each( iter, runq )
> @@ -316,6 +356,13 @@ rt_dump(const struct scheduler *ops)
>  rt_dump_vcpu(ops, svc);
>  }
>
> +printk("Global Replenishment Event info:\n");
> +list_for_each( iter, replq )
> +{
> +svc = replq_elem(iter);
> +rt_dump_vcpu(ops, svc);
> +}
> +
>  printk("Domain info:\n");
>  list_for_each( iter, >sdom )
>  {
> @@ -380,11 +427,77 @@ rt_update_deadline(s_time_t now, struct rt_vcpu *svc)
>  return;
>  }
>
> +/*
> + * A helper function that only removes a vcpu from a queue
> + * and it returns 1 if the vcpu was in front of the list.
> + */
> +static inline int
> +deadline_queue_remove(struct list_head *queue, struct list_head *elem)
> +{
> +int pos = 0;

Add an empty line here
Usually, the variable definition and the main function has an empty
line for seperation.

> +if ( queue->next != elem )
> +pos = 1;
> +
> +list_del_init(elem);
> +return !pos;
> +}
> +
>  static inline void
>  __q_remove(struct rt_vcpu *svc)
>  {
> -if ( __vcpu_on_q(svc) )
> -list_del_init(>q_elem);
> +ASSERT( __vcpu_on_q(svc) );
> +list_del_init(>q_elem);
> +}
> +
> +/*
> + * Removing a vcpu from the replenishment queue could
> + * re-program the timer for the next replenishment event
> + * if it was at the front of the list.
> + */
> +static inline void
> +__replq_remove(const struct scheduler *ops, struct rt_vcpu *svc)
> +{
> +struct rt_private *prv = rt_priv(ops);
> +struct list_head *replq = rt_replq(ops);
> +struct timer* repl_timer = prv->repl_timer;
> +
> +ASSERT( vcpu_on_replq(svc) );
> +
> +if ( deadline_queue_remove(replq, >replq_elem) )
> +{
> +/* re-arm the timer for the next replenishment event */
> +if ( !list_empty(replq) )
> +{
> +struct rt_vcpu *svc_next = replq_elem(replq->next);
> +set_timer(repl_timer, svc_next->cur_deadline);
> +}
> +else
> +stop_timer(repl_timer);
> +}
> +}
> +
> +/*
> + * An utility function that inserts a vcpu to a
> + * queue based on certain order (EDF). The returned
> + * value is 1 if a vcpu has been inserted to the
> + * front of a list.
> + */
> +static int
> +deadline_queue_insert(struct rt_vcpu * (*_get_q_elem)(struct list_head 
> *elem),
> +struct rt_vcpu *svc, struct list_head *elem, struct list_head *queue)
> +{
> +struct list_head *iter;
> +int pos = 0;
> +
> +list_for_each(iter, queue)

space after ( and before )
If not sure about the space, we can refer to the sched_credit.c for
the style as well, beside the CODING_STYLE file. :-)

> +{
> +struct rt_vcpu * iter_svc = (*_get_q_elem)(iter);
> +if ( svc->cur_deadline <= iter_svc->cur_deadline )
> +break;
> +pos++;
> +}
> +list_add_tail(elem, iter);
> +return !pos;
>  }
>
>  /*
> @@ -397,27 +510,62 @@ __runq_insert(const struct scheduler *ops, struct 
> rt_vcpu *svc)
>  {
>  struct rt_private *prv = rt_priv(ops);
>  struct list_head *runq = rt_runq(ops);
> -struct list_head *iter;
>
>  ASSERT( spin_is_locked(>lock) 

[Xen-devel] [linux-4.1 test] 85972: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 66399
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 85868 REGR. vs. 
66399

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2   6 xen-boot   fail in 85641 pass in 85972
 test-armhf-armhf-xl   15 guest-start/debian.repeat fail in 85641 pass in 85972
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 85868 pass 
in 85972
 test-armhf-armhf-xl-rtds 11 guest-startfail in 85868 pass in 85972
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 85641
 test-armhf-armhf-xl-xsm  11 guest-start fail pass in 85868

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-xsm  13 saverestore-support-check fail in 85868 never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-check fail in 85868 never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-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-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linuxb9a9cfdbf7254f4a231cc8ddf685cc29d3a9c6e5
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis66399  2015-12-15 18:20:39 Z   87 days
Failing since 78925  2016-01-24 13:50:39 Z   47 days   49 attempts
Testing same since85582  2016-03-06 13:53:34 Z5 days7 attempts


431 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 libvirt  1e34a8f91962a9a85ee6fc1478754736a5c36ff9
baseline version:
 libvirt  adefc561cc4c6a007529769c3df286f2ed461684

Last test of basis85871  2016-03-10 04:27:26 Z1 days
Testing same since85976  2016-03-11 04:25:00 Z0 days1 attempts


People who touched revisions under test:
  Chunyan Liu 
  Cole Robinson 
  Daniel P. Berrange 
  Jim Fehlig 
  Jiri Denemark 
  Marc-André Lureau 
  Marc-André Lureau 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=1e34a8f91962a9a85ee6fc1478754736a5c36ff9
+ . ./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
++ 

[Xen-devel] [xen-4.6-testing baseline-only test] 44242: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44242 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44242/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64 14 guest-saverestore.2 fail REGR. vs. 
44223
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 44223

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 44223
 test-amd64-amd64-xl  19 guest-start/debian.repeatfail   like 44223
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 44223
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 44223
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 44223
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44223
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44223
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 44223

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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
 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-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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 xen  e0493703a96c03aaafc8d179624b89b7cf600916
baseline version:
 xen  93371eb8f67460e336a116c41b6b036caaac3e2b

Last test of basis44223  2016-03-05 11:01:37 Z6 days
Testing same since44242  2016-03-11 15:49:07 Z0 days1 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 

Re: [Xen-devel] [RFC] tools: don't use qemu default config

[Konrad Rzeszutek Wilk]

On Fri, Mar 11, 2016 at 03:08:30PM -0700, Jim Fehlig wrote:
> I recently changed SUSE's Xen package to use the distro qemu instead of 
> building
> qemu-xen. This got some other eyes looking at Xen's use of qemu and it was
> noticed that libxl and xen-qemu-dom0-disk-backend.service do not include
> '-no-user-config' when invoking qemu. The latter also does not include
> '-nodefaults'. Commit 6ef823fd added '-nodefaults' to the qemu args created by
> libxl, but missed adding it to the qemu args in 
> xen-qemu-dom0-disk-backend.service.
> 
> I _think_ adding '-nodefaults' to the qemu args in the service file is
> non-controversial. What do folks think of also adding '-no-user-config'? It
> seems the global config in /etc/qemu/qemu.conf would end up being more
> problematic than helpful for Xen.

Is there a description (or URL) of what one can jam in there?

> 
> As a side note, the libvirt qemu driver includes '-no-user-config -nodefaults'
> in all its qemu invocations to avoid configuration which it doesn't control.
> 
> WRT qemu args, another suggestion was to explicitly specify 'accel=xen' in the
> machine arg. Together, these changes would e.g. result in the service file 
> qemu
> args changing slightly to
> 
>   -machine xenpv,accel=xen -xen-domid 0 -xen-attach -name dom0 \
>   -daemonize -no-user-config -nodefaults -display none \
>   -pidfile /var/run/xen/qemu-dom0.pid
> 
> If folks agree with these changes, I'll be happy to provide a patches for 
> libxl
> and the systemd service file. Thanks for your comments.
> 
> Regards,
> Jim
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v10 26/31] COLO proxy: implement setup/teardown of COLO proxy module

[Konrad Rzeszutek Wilk]

> +extern int colo_proxy_setup(libxl__colo_proxy_state *cps);
> +extern void colo_proxy_teardown(libxl__colo_proxy_state *cps);
>  #endif
> diff --git a/tools/libxl/libxl_colo_proxy.c b/tools/libxl/libxl_colo_proxy.c
> new file mode 100644
> index 000..e07e640
> --- /dev/null
> +++ b/tools/libxl/libxl_colo_proxy.c
> @@ -0,0 +1,230 @@
> +/*
> + * Copyright (C) 2015 FUJITSU LIMITED

2016?
> + * Author: Yang Hongyang 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described in file LICENSE.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU Lesser General Public License for more details.
> + */
> +
> +#include "libxl_osdeps.h" /* must come before any other headers */
> +
> +#include "libxl_internal.h"
> +#include "libxl_colo.h"
> +#include 
> +
> +#define NETLINK_COLO 28

Can you include a comment why 28? Why not 31415?

> +
> +enum colo_netlink_op {
> +COLO_QUERY_CHECKPOINT = (NLMSG_MIN_TYPE + 1),
> +COLO_CHECKPOINT,
> +COLO_FAILOVER,
> +COLO_PROXY_INIT,
> +COLO_PROXY_RESET, /* UNUSED, will be used for continuous FT */
> +};
> +
> +/* = colo-proxy: helper functions == */
> +
> +static int colo_proxy_send(libxl__colo_proxy_state *cps, uint8_t *buff,
> +   uint64_t size, int type)
> +{
> +struct sockaddr_nl sa;
> +struct nlmsghdr msg;
> +struct iovec iov;
> +struct msghdr mh;
> +int ret;
> +
> +STATE_AO_GC(cps->ao);
> +
> +memset(, 0, sizeof(sa));
> +sa.nl_family = AF_NETLINK;
> +sa.nl_pid = 0;
> +sa.nl_groups = 0;
> +
> +msg.nlmsg_len = NLMSG_SPACE(0);
> +msg.nlmsg_flags = NLM_F_REQUEST;
> +if (type == COLO_PROXY_INIT) {
> +msg.nlmsg_flags |= NLM_F_ACK;
> +}

I don't think you need the { }?

Ah, yup:

5. Block structure  

Every indented statement is braced apart from blocks that contain just  
one statement.  

> +msg.nlmsg_seq = 0;
> +/* This is untrusty */

Umm, can you be more specific pls?

> +msg.nlmsg_pid = cps->index;
> +msg.nlmsg_type = type;
> +
> +iov.iov_base = 
> +iov.iov_len = msg.nlmsg_len;
> +
> +mh.msg_name = 
> +mh.msg_namelen = sizeof(sa);
> +mh.msg_iov = 
> +mh.msg_iovlen = 1;
> +mh.msg_control = NULL;
> +mh.msg_controllen = 0;
> +mh.msg_flags = 0;
> +
> +ret = sendmsg(cps->sock_fd, , 0);
> +if (ret <= 0) {
> +LOG(ERROR, "can't send msg to kernel by netlink: %s",
> +strerror(errno));
> +}
> +
> +return ret;
> +}
> +
> +/* error: return -1, otherwise return 0 */
> +static int64_t colo_proxy_recv(libxl__colo_proxy_state *cps, uint8_t **buff,
> +   unsigned int timeout_us)
> +{
> +struct sockaddr_nl sa;
> +struct iovec iov;
> +struct msghdr mh = {
> +.msg_name = ,
> +.msg_namelen = sizeof(sa),
> +.msg_iov = ,
> +.msg_iovlen = 1,
> +};
> +struct timeval tv;
> +uint32_t size = 16384;
> +int64_t len = 0;
> +int ret;
> +
> +STATE_AO_GC(cps->ao);
> +uint8_t *tmp = libxl__malloc(NOGC, size);
> +
> +if (timeout_us) {
> +tv.tv_sec = timeout_us / 100;
> +tv.tv_usec = timeout_us % 100;
> +setsockopt(cps->sock_fd, SOL_SOCKET, SO_RCVTIMEO, , sizeof(tv));
> +}
> +
> +iov.iov_base = tmp;
> +iov.iov_len = size;
> +next:
> +ret = recvmsg(cps->sock_fd, , 0);
> +if (ret <= 0) {
> +if (errno != EAGAIN && errno != EWOULDBLOCK)

-EINTR ?

> +LOGE(ERROR, "can't recv msg from kernel by netlink");
> +goto err;
> +}
> +
> +len += ret;
> +if (mh.msg_flags & MSG_TRUNC) {
> +size += 16384;
> +tmp = libxl__realloc(NOGC, tmp, size);

You really should check 'tmp'.

If this loop continues on for some time the 'size' may be
in milions and this realloc will fail.

> +iov.iov_base = tmp + len;
> +iov.iov_len = size - len;
> +goto next;

> +}
> +
> +*buff = tmp;
> +ret = len;
> +goto out;
> +
> +err:
> +free(tmp);
> +*buff = NULL;
> +
> +out:
> +if (timeout_us) {
> +tv.tv_sec = 0;
> +tv.tv_usec = 0;
> +setsockopt(cps->sock_fd, SOL_SOCKET, SO_RCVTIMEO, , sizeof(tv));
> +}
> +return ret;
> +}
> +
> +/* = colo-proxy: setup and 

[Xen-devel] [RFC] tools: don't use qemu default config

[Jim Fehlig]

I recently changed SUSE's Xen package to use the distro qemu instead of building
qemu-xen. This got some other eyes looking at Xen's use of qemu and it was
noticed that libxl and xen-qemu-dom0-disk-backend.service do not include
'-no-user-config' when invoking qemu. The latter also does not include
'-nodefaults'. Commit 6ef823fd added '-nodefaults' to the qemu args created by
libxl, but missed adding it to the qemu args in 
xen-qemu-dom0-disk-backend.service.

I _think_ adding '-nodefaults' to the qemu args in the service file is
non-controversial. What do folks think of also adding '-no-user-config'? It
seems the global config in /etc/qemu/qemu.conf would end up being more
problematic than helpful for Xen.

As a side note, the libvirt qemu driver includes '-no-user-config -nodefaults'
in all its qemu invocations to avoid configuration which it doesn't control.

WRT qemu args, another suggestion was to explicitly specify 'accel=xen' in the
machine arg. Together, these changes would e.g. result in the service file qemu
args changing slightly to

  -machine xenpv,accel=xen -xen-domid 0 -xen-attach -name dom0 \
  -daemonize -no-user-config -nodefaults -display none \
  -pidfile /var/run/xen/qemu-dom0.pid

If folks agree with these changes, I'll be happy to provide a patches for libxl
and the systemd service file. Thanks for your comments.

Regards,
Jim

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

[Xen-devel] [linux-3.10 test] 85950: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 85254
 build-i386-rumpuserxen6 xen-buildfail   like 85254
 build-amd64-rumpuserxen   6 xen-buildfail   like 85254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 85254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 85254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux19d0bd71d564448446bd851d752caf3e31520ac8
baseline version:
 linuxe39c17904aadf3a107b2bc292c03bfd9f850fd08

Last test of basis85254  2016-03-03 23:24:10 Z7 days
Testing same since85852  2016-03-09 23:47:07 Z1 days2 attempts


People who touched revisions under test:
  "J. Bruce Fields" 
  Andy Lutomirski 
  Arnd Bergmann 
  Borislav Petkov 
  Christian König 
  Daniele Palmas 
  Dave Airlie 
  David Woodhouse 
  Greg Kroah-Hartman 
  Harvey Hunt 
  Ingo Molnar 
  Jeff Layton 
  Johan Hovold 
  Kamal Mostafa 
  Pavel Shilovsky 
  Rafael J. Wysocki 
  Richard Weinberger 
  Shirish Pargaonkar 
  Soohoon Lee 
  Steve French 
  Takashi Iwai 
  Tejun Heo 
  Thomas Betker 
  Timothy Pearson 
  Todd Brandt 
  Todd E Brandt 
  Vittorio Alfieri 
  Yegor Yefremov 

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 

Re: [Xen-devel] Storage Domain in Xen 4.4

[Paul Mogren]

On Fri, Mar 11, 2016 at 2:07 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:

> On Mon, Mar 07, 2016 at 04:46:39PM -0500, Paul Mogren wrote:
> > Hey all,
> >
> > I'm trying to get a storage domain up and running in Xen 4.4. I'm
> currently
> > using Ubuntu 14.04 for the dom0, storage domain and guest. I'm currently
> > following the steps here,
> > http://wiki.xenproject.org/wiki/Storage_driver_domains, but am not
> having
> > any luck.
> >
> > *I received this dmesg error on the guest during start-up:*
> > xenbus_probe_frontend: Timeout connecting to device: device/vbd/51715
> > (local state 3, remote state 2)
> >
> > This means the guest (in state 3) is initialised and waiting for a
> > connection from a peer, and the storage-domain (in state 2) is finished
> > with the early initialisation but is waiting for information from the
> peer
> > or hot-plug scripts. This would imply to me that there is a communication
>
>
> Right, like actually hooking up the disk (/home/storage/disk.img)?
> to the guest.
>
> Do you have anything in the storage domain to process udev? Ah wait you
> have 'disable_udev'.
>
> In which case I think you need the xl daemon to act for you?
>
> Roger would know but he is on vacation. CC-ing him just in case.
>
> > error between the xen-blkfront and xen-blkback drivers or an error in the
> > scripts.
> >
> > *However, on the storage-domain I receive this dmesg:*
> > [ 2987.170473] xen-blkback: event-channel 19
> > [ 2987.170761] xen-blkback: /local/domain/3/device/vbd/51715:using single
> > page: ring-ref 10
> > [ 2987.171319] xen-blkback: ring-pages:1, event-channel 19, protocol 1
> > (x86_64-abi) persistent grants
>
> >
> > Is this the information that the xen-blkback driver is waiting for? If
> so,
> > why does it not continue through the initialisation process? If not, what
> > information is the xen-blkback driver waiting for, and how do I ensure
> the
> > front-end and back-end drivers will establish a connection?
> >
> > I've attached the output of xenstore-ls and the dmesg outputs of the
> guest
> > and storage domain.
> >
> > Thanks in advanced,
> > Paul Mogren
>
> > tool = ""
> >  xenstored = ""
> > local = ""
> >  domain = ""
> >   0 = ""
> >name = "Domain-0"
> >domid = "0"
> >memory = ""
> > target = "6833564"
> > static-max = "4294967292"
> > freemem-slack = "247980"
> >device-model = ""
> > 0 = ""
> >  state = "running"
> >libxl = ""
> > disable_udev = "1"
> .. snip..
> >   2 = ""
> >vm = "/vm/081ff22d-7f4b-4c46-a6b1-4deed1edc1c2"
> >name = "storage-domain"
> >cpu = ""
> > 0 = ""
> >  availability = "online"
> > 1 = ""
> >  availability = "online"
> >memory = ""
> > static-max = "524288"
> > target = "524289"
> > videoram = "-1"
> >device = ""
> > suspend = ""
> >  event-channel = ""
> > vbd = ""
> ..
> >backend = ""
> > vbd = ""
> >  3 = ""
> >   51715 = ""
> >frontend = "/local/domain/3/device/vbd/51715"
> >params = "/home/storage/disk.img"
>
> >script = "/etc/xen/scripts/block"
> >frontend-id = "3"
> >online = "1"
> >removable = "0"
> >bootable = "1"
> >state = "2"
> >dev = "xvda3"
> >type = "phy"
> >mode = "w"
> >device-type = "disk"
> >max-ring-page-order = "4"
>
>
> >   3 = ""
> >vm = "/vm/23918c38-5db7-458d-a151-22726de62710"
> >name = "guest"
> >cpu = ""
> > 0 = ""
> >  availability = "online"
> > 1 = ""
> >  availability = "online"
> >memory = ""
> > static-max = "524288"
> > target = "524289"
> > videoram = "-1"
> >device = ""
> > suspend = ""
> >  event-channel = ""
> > vbd = ""
> .. snip..
> >  51715 = ""
> >   backend = "/local/domain/2/backend/vbd/3/51715"
> >   backend-id = "2"
> >   state = "3"
> >   virtual-device = "51715"
> >   device-type = "disk"
> >   protocol = "x86_64-abi"
> >   ring-ref = "10"
> >   event-channel = "19"
> >   feature-persistent = "1"
>


Thanks Konrad for the reply.

I actually got it working though. The problem was the image that I was
using (which I made with *'dd if=/dev/zero of=/home/storage/disk.img bs=1M
count=10'*) had to be mounted as a loop back device. So I just ran '*losetup
/dev/loop0 /home/storage/disk.img'* and changed the configuration file for
the guest to look for the target /dev/loop0.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools/xenstat: handle network interface name in upper case.

[Zhigang Wang]

Sorry I send this mail by mistake. Please ignore it. I send another one with 
correct commit message.

On 03/11/2016 03:13 PM, Zhigang Wang wrote:
> Oracle-Bug: 22879856
> 
> Signed-off-by: Zhigang Wang 
> ---
>  tools/xenstat/libxenstat/src/xenstat_linux.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c 
> b/tools/xenstat/libxenstat/src/xenstat_linux.c
> index 931b24e..d33eca1 100644
> --- a/tools/xenstat/libxenstat/src/xenstat_linux.c
> +++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
> @@ -101,6 +101,7 @@ int parseNetDevLine(char *line, char *iface, unsigned 
> long long *rxBytes, unsign
>   /* Temporary/helper variables */
>   int ret;
>   char *tmp;
> + char *tmp2;
>   int i = 0, x = 0, col = 0;
>   regex_t r;
>   regmatch_t matches[19];
> @@ -221,8 +222,11 @@ int parseNetDevLine(char *line, char *iface, unsigned 
> long long *rxBytes, unsign
>   }
>   else
>   /* There were errors when parsing this directly 
> in RE. strpbrk() helps */
> - if (iface != NULL)
> - strcpy(iface, strpbrk(tmp, 
> "abcdefghijklmnopqrstvuwxyz0123456789"));
> + if (iface != NULL) {
> + tmp2 = strpbrk(tmp, 
> "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789");
> + if (tmp2 != NULL)
> + strcpy(iface, tmp2);
> + }
>  
>   memset(tmp, 0, matches[i].rm_eo - 
> matches[i].rm_so);
>   }
> 


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

[Xen-devel] [PATCH] tools/xenstat: handle network interface name in uppercase.

[Zhigang Wang]

xentop will segmentation fault in this case:

  # ip link set eth1 down
  # ip link set eth1 name ETH
  # xentop

This patch will let xentop to handle all uppercase network interface name.

Signed-off-by: Zhigang Wang 
---
 tools/xenstat/libxenstat/src/xenstat_linux.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c 
b/tools/xenstat/libxenstat/src/xenstat_linux.c
index 931b24e..d33eca1 100644
--- a/tools/xenstat/libxenstat/src/xenstat_linux.c
+++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
@@ -101,6 +101,7 @@ int parseNetDevLine(char *line, char *iface, unsigned long 
long *rxBytes, unsign
/* Temporary/helper variables */
int ret;
char *tmp;
+   char *tmp2;
int i = 0, x = 0, col = 0;
regex_t r;
regmatch_t matches[19];
@@ -221,8 +222,11 @@ int parseNetDevLine(char *line, char *iface, unsigned long 
long *rxBytes, unsign
}
else
/* There were errors when parsing this directly 
in RE. strpbrk() helps */
-   if (iface != NULL)
-   strcpy(iface, strpbrk(tmp, 
"abcdefghijklmnopqrstvuwxyz0123456789"));
+   if (iface != NULL) {
+   tmp2 = strpbrk(tmp, 
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789");
+   if (tmp2 != NULL)
+   strcpy(iface, tmp2);
+   }
 
memset(tmp, 0, matches[i].rm_eo - 
matches[i].rm_so);
}
-- 
2.5.0


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

[Xen-devel] [PATCH] tools/xenstat: handle network interface name in upper case.

[Zhigang Wang]

Oracle-Bug: 22879856

Signed-off-by: Zhigang Wang 
---
 tools/xenstat/libxenstat/src/xenstat_linux.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c 
b/tools/xenstat/libxenstat/src/xenstat_linux.c
index 931b24e..d33eca1 100644
--- a/tools/xenstat/libxenstat/src/xenstat_linux.c
+++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
@@ -101,6 +101,7 @@ int parseNetDevLine(char *line, char *iface, unsigned long 
long *rxBytes, unsign
/* Temporary/helper variables */
int ret;
char *tmp;
+   char *tmp2;
int i = 0, x = 0, col = 0;
regex_t r;
regmatch_t matches[19];
@@ -221,8 +222,11 @@ int parseNetDevLine(char *line, char *iface, unsigned long 
long *rxBytes, unsign
}
else
/* There were errors when parsing this directly 
in RE. strpbrk() helps */
-   if (iface != NULL)
-   strcpy(iface, strpbrk(tmp, 
"abcdefghijklmnopqrstvuwxyz0123456789"));
+   if (iface != NULL) {
+   tmp2 = strpbrk(tmp, 
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789");
+   if (tmp2 != NULL)
+   strcpy(iface, tmp2);
+   }
 
memset(tmp, 0, matches[i].rm_eo - 
matches[i].rm_so);
}
-- 
2.5.0


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 85850 pass in 85924
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat   fail pass in 85850

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 85850
 build-i386-rumpuserxen6 xen-buildfail   like 85850
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85850
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 85850
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 85850
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 85850

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

version targeted for testing:
 xen  6890e07e483673ec5f946b7c4654275707924d6d
baseline version:
 xen  6890e07e483673ec5f946b7c4654275707924d6d

Last test of basis85924  2016-03-10 17:18:07 Z1 days
Testing same since0  1970-01-01 00:00:00 Z 16871 days0 attempts

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

[Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Tianyang Chen]

Budget replenishment and enforcement are separated by adding
a replenishment timer, which fires at the next most imminent
release time of all runnable vcpus.

A replenishment queue has been added to keep track of all vcpus that
are runnable.

The following functions have major changes to manage the replenishment
events and timer.

repl_handler(): It is a timer handler which is re-programmed
to fire at the nearest vcpu deadline to replenish vcpus.

rt_schedule(): picks the highest runnable vcpu based on cpu
affinity and ret.time will be passed to schedule(). If an idle
vcpu is picked, -1 is returned to avoid busy-waiting. repl_update()
has been removed.

rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of
picking one from the run queue.

rt_context_saved(): when context switching is finished, the
preempted vcpu will be put back into the runq.

Simplified funtional graph:

schedule.c SCHEDULE_SOFTIRQ:
rt_schedule():
[spin_lock]
burn_budget(scurr)
snext = runq_pick()
[spin_unlock]

sched_rt.c TIMER_SOFTIRQ
replenishment_timer_handler()
[spin_lock]
 {
replenish(i)
runq_tickle(i)
}>
program_timer()
[spin_lock]

Signed-off-by: Tianyang Chen 
Signed-off-by: Meng Xu 
Signed-off-by: Dagaen Golomb 
---
changes since v7:
Coding sytle.
Added a flag to indicate that a vcpu was depleted.
Added a local list including updated vcpus in the
timer handler. It is used to decide which vcpu should
tickle.

changes since v6:
Removed unnecessary vcpu_on_q() checks for runq_insert()
Renamed replenishment queue related functions without
underscores
New replq_reinsert() function for rt_vcpu_wake()

changes since v5:
Removed unnecessary vcpu_on_replq() checks
deadline_queue_insert() returns a flag to indicate if it's
needed to re-program the timer
Removed unnecessary timer checks
Added helper functions to remove vcpus from queues
coding style

Changes since v4:
removed unnecessary replenishment queue checks in vcpu_wake()
extended replq_remove() to all cases in vcpu_sleep()
used _deadline_queue_insert() helper function for both queues
_replq_insert() and _replq_remove() program timer internally

Changes since v3:
removed running queue.
added repl queue to keep track of repl events.
timer is now per scheduler.
timer is init on a valid cpu in a cpupool.
---
 xen/common/sched_rt.c |  435 ++---
 1 file changed, 340 insertions(+), 95 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index bfed2e2..58189cd 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -3,7 +3,9 @@
  * EDF scheduling is a real-time scheduling algorithm used in embedded field.
  *
  * by Sisu Xi, 2013, Washington University in Saint Louis
- * and Meng Xu, 2014, University of Pennsylvania
+ * Meng Xu, 2014-2016, University of Pennsylvania
+ * Tianyang Chen, 2016, University of Pennsylvania
+ * Dagaen Golomb, 2016, University of Pennsylvania
  *
  * based on the code of credit Scheduler
  */
@@ -16,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -87,7 +90,7 @@
 #define RTDS_DEFAULT_BUDGET (MICROSECS(4000))
 
 #define UPDATE_LIMIT_SHIFT  10
-#define MAX_SCHEDULE(MILLISECS(1))
+
 /*
  * Flags
  */
@@ -115,6 +118,18 @@
 #define RTDS_delayed_runq_add (1<<__RTDS_delayed_runq_add)
 
 /*
+ * The replenishment timer handler needs to check this bit
+ * to know where a replenished vcpu was, when deciding which
+ * vcpu should tickle.
+ * A replenished vcpu should tickle if it was moved from the
+ * depleted queue to the run queue.
+ * + Set in burn_budget() if a vcpu has zero budget left.
+ * + Cleared and checked in the repenishment handler.
+ */
+#define __RTDS_was_depleted 3
+#define RTDS_was_depleted (1<<__RTDS_was_depleted)
+
+/*
  * rt tracing events ("only" 512 available!). Check
  * include/public/trace.h for more details.
  */
@@ -142,6 +157,9 @@ static cpumask_var_t *_cpumask_scratch;
  */
 static unsigned int nr_rt_ops;
 
+/* handler for the replenishment timer */
+static void repl_handler(void *data);
+
 /*
  * Systme-wide private data, include global RunQueue/DepletedQ
  * Global lock is referenced by schedule_data.schedule_lock from all
@@ -152,7 +170,9 @@ struct rt_private {
 struct list_head sdom;  /* list of availalbe domains, used for dump */
 struct list_head runq;  /* ordered list of runnable vcpus */
 struct list_head depletedq; /* unordered list of depleted vcpus */
+struct list_head replq; /* ordered list of vcpus that need 
replenishment */
 cpumask_t tickled;  /* cpus been tickled */
+struct timer *repl_timer;   /* replenishment timer */
 };
 
 /*
@@ -160,6 +180,7 @@ struct 

Re: [Xen-devel] Storage Domain in Xen 4.4

[Konrad Rzeszutek Wilk]

On Mon, Mar 07, 2016 at 04:46:39PM -0500, Paul Mogren wrote:
> Hey all,
> 
> I'm trying to get a storage domain up and running in Xen 4.4. I'm currently
> using Ubuntu 14.04 for the dom0, storage domain and guest. I'm currently
> following the steps here,
> http://wiki.xenproject.org/wiki/Storage_driver_domains, but am not having
> any luck.
> 
> *I received this dmesg error on the guest during start-up:*
> xenbus_probe_frontend: Timeout connecting to device: device/vbd/51715
> (local state 3, remote state 2)
> 
> This means the guest (in state 3) is initialised and waiting for a
> connection from a peer, and the storage-domain (in state 2) is finished
> with the early initialisation but is waiting for information from the peer
> or hot-plug scripts. This would imply to me that there is a communication


Right, like actually hooking up the disk (/home/storage/disk.img)?
to the guest.

Do you have anything in the storage domain to process udev? Ah wait you
have 'disable_udev'.

In which case I think you need the xl daemon to act for you?

Roger would know but he is on vacation. CC-ing him just in case.

> error between the xen-blkfront and xen-blkback drivers or an error in the
> scripts.
> 
> *However, on the storage-domain I receive this dmesg:*
> [ 2987.170473] xen-blkback: event-channel 19
> [ 2987.170761] xen-blkback: /local/domain/3/device/vbd/51715:using single
> page: ring-ref 10
> [ 2987.171319] xen-blkback: ring-pages:1, event-channel 19, protocol 1
> (x86_64-abi) persistent grants

> 
> Is this the information that the xen-blkback driver is waiting for? If so,
> why does it not continue through the initialisation process? If not, what
> information is the xen-blkback driver waiting for, and how do I ensure the
> front-end and back-end drivers will establish a connection?
> 
> I've attached the output of xenstore-ls and the dmesg outputs of the guest
> and storage domain.
> 
> Thanks in advanced,
> Paul Mogren

> tool = ""
>  xenstored = ""
> local = ""
>  domain = ""
>   0 = ""
>name = "Domain-0"
>domid = "0"
>memory = ""
> target = "6833564"
> static-max = "4294967292"
> freemem-slack = "247980"
>device-model = ""
> 0 = ""
>  state = "running"
>libxl = ""
> disable_udev = "1"
.. snip..
>   2 = ""
>vm = "/vm/081ff22d-7f4b-4c46-a6b1-4deed1edc1c2"
>name = "storage-domain"
>cpu = ""
> 0 = ""
>  availability = "online"
> 1 = ""
>  availability = "online"
>memory = ""
> static-max = "524288"
> target = "524289"
> videoram = "-1"
>device = ""
> suspend = ""
>  event-channel = ""
> vbd = ""
..
>backend = ""
> vbd = ""
>  3 = ""
>   51715 = ""
>frontend = "/local/domain/3/device/vbd/51715"
>params = "/home/storage/disk.img"

>script = "/etc/xen/scripts/block"
>frontend-id = "3"
>online = "1"
>removable = "0"
>bootable = "1"
>state = "2"
>dev = "xvda3"
>type = "phy"
>mode = "w"
>device-type = "disk"
>max-ring-page-order = "4"


>   3 = ""
>vm = "/vm/23918c38-5db7-458d-a151-22726de62710"
>name = "guest"
>cpu = ""
> 0 = ""
>  availability = "online"
> 1 = ""
>  availability = "online"
>memory = ""
> static-max = "524288"
> target = "524289"
> videoram = "-1"
>device = ""
> suspend = ""
>  event-channel = ""
> vbd = ""
.. snip..
>  51715 = ""
>   backend = "/local/domain/2/backend/vbd/3/51715"
>   backend-id = "2"
>   state = "3"
>   virtual-device = "51715"
>   device-type = "disk"
>   protocol = "x86_64-abi"
>   ring-ref = "10"
>   event-channel = "19"
>   feature-persistent = "1"

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

[Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

[Andy Lutomirski]

This adds paravirt hooks for unsafe MSR access.  On native, they
call native_{read,write}_msr.  On Xen, they use
xen_{read,write}_msr_safe.

Nothing uses them yet for ease of bisection.  The next patch will
use them in rdmsrl, wrmsrl, etc.

I intentionally didn't make them OOPS on #GP on Xen.  I think that
should be done separately by the Xen maintainers.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/msr.h|  5 +++--
 arch/x86/include/asm/paravirt.h   | 11 +++
 arch/x86/include/asm/paravirt_types.h | 10 --
 arch/x86/kernel/paravirt.c|  2 ++
 arch/x86/xen/enlighten.c  | 23 +++
 5 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 1487054a1a70..13da359881d7 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -119,8 +119,9 @@ static inline unsigned long long 
native_read_msr_safe(unsigned int msr,
return EAX_EDX_VAL(val, low, high);
 }
 
-static inline void native_write_msr(unsigned int msr,
-   unsigned low, unsigned high)
+/* Can be uninlined because referenced by paravirt */
+notrace static inline void native_write_msr(unsigned int msr,
+   unsigned low, unsigned high)
 {
asm volatile("1: wrmsr\n"
 "2:\n"
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 2e49228ed9a3..68297d87e85c 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -129,6 +129,17 @@ static inline void wbinvd(void)
 
 #define get_kernel_rpl()  (pv_info.kernel_rpl)
 
+static inline u64 paravirt_read_msr(unsigned msr)
+{
+   return PVOP_CALL1(u64, pv_cpu_ops.read_msr, msr);
+}
+
+static inline void paravirt_write_msr(unsigned msr,
+ unsigned low, unsigned high)
+{
+   return PVOP_VCALL3(pv_cpu_ops.write_msr, msr, low, high);
+}
+
 static inline u64 paravirt_read_msr_safe(unsigned msr, int *err)
 {
return PVOP_CALL2(u64, pv_cpu_ops.read_msr_safe, msr, err);
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 5a06cccd36f0..b85aec45a1b8 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -155,8 +155,14 @@ struct pv_cpu_ops {
void (*cpuid)(unsigned int *eax, unsigned int *ebx,
  unsigned int *ecx, unsigned int *edx);
 
-   /* MSR operations.
-  err = 0/-EIO.  wrmsr returns 0/-EIO. */
+   /* Unsafe MSR operations.  These will warn or panic on failure. */
+   u64 (*read_msr)(unsigned int msr);
+   void (*write_msr)(unsigned int msr, unsigned low, unsigned high);
+
+   /*
+* Safe MSR operations.
+* read sets err to 0 or -EIO.  write returns 0 or -EIO.
+*/
u64 (*read_msr_safe)(unsigned int msr, int *err);
int (*write_msr_safe)(unsigned int msr, unsigned low, unsigned high);
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index 8aad95478ae5..f9583917c7c4 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -339,6 +339,8 @@ __visible struct pv_cpu_ops pv_cpu_ops = {
.write_cr8 = native_write_cr8,
 #endif
.wbinvd = native_wbinvd,
+   .read_msr = native_read_msr,
+   .write_msr = native_write_msr,
.read_msr_safe = native_read_msr_safe,
.write_msr_safe = native_write_msr_safe,
.read_pmc = native_read_pmc,
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index ff2df20d0067..548cd3e02b9e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1092,6 +1092,26 @@ static int xen_write_msr_safe(unsigned int msr, unsigned 
low, unsigned high)
return ret;
 }
 
+static u64 xen_read_msr(unsigned int msr)
+{
+   /*
+* This will silently swallow a #GP from RDMSR.  It may be worth
+* changing that.
+*/
+   int err;
+
+   return xen_read_msr_safe(msr, );
+}
+
+static void xen_write_msr(unsigned int msr, unsigned low, unsigned high)
+{
+   /*
+* This will silently swallow a #GP from WRMSR.  It may be worth
+* changing that.
+*/
+   xen_write_msr_safe(msr, low, high);
+}
+
 void xen_setup_shared_info(void)
 {
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
@@ -1222,6 +1242,9 @@ static const struct pv_cpu_ops xen_cpu_ops __initconst = {
 
.wbinvd = native_wbinvd,
 
+   .read_msr = xen_read_msr,
+   .write_msr = xen_write_msr,
+
.read_msr_safe = xen_read_msr_safe,
.write_msr_safe = xen_write_msr_safe,
 
-- 
2.5.0


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

[Xen-devel] [PATCH v3 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

This demotes an OOPS and likely panic due to a failed non-"safe" MSR
access to a WARN and, for RDMSR, a return value of zero.  If
panic_on_oops is set, then failed unsafe MSR accesses will still
oops and panic.

To be clear, this type of failure should *not* happen.  This patch
exists to minimize the chance of nasty undebuggable failures due on
systems that used to work due to a now-fixed CONFIG_PARAVIRT=y bug.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/msr.h | 10 --
 arch/x86/mm/extable.c  | 33 +
 2 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 93fb7c1cffda..1487054a1a70 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -92,7 +92,10 @@ static inline unsigned long long native_read_msr(unsigned 
int msr)
 {
DECLARE_ARGS(val, low, high);
 
-   asm volatile("rdmsr" : EAX_EDX_RET(val, low, high) : "c" (msr));
+   asm volatile("1: rdmsr\n"
+"2:\n"
+_ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_rdmsr_unsafe)
+: EAX_EDX_RET(val, low, high) : "c" (msr));
if (msr_tracepoint_active(__tracepoint_read_msr))
do_trace_read_msr(msr, EAX_EDX_VAL(val, low, high), 0);
return EAX_EDX_VAL(val, low, high);
@@ -119,7 +122,10 @@ static inline unsigned long long 
native_read_msr_safe(unsigned int msr,
 static inline void native_write_msr(unsigned int msr,
unsigned low, unsigned high)
 {
-   asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high) : "memory");
+   asm volatile("1: wrmsr\n"
+"2:\n"
+_ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)
+: : "c" (msr), "a"(low), "d" (high) : "memory");
if (msr_tracepoint_active(__tracepoint_read_msr))
do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
 }
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index 9dd7e4b7fcde..f310714e6e6d 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -49,6 +49,39 @@ bool ex_handler_ext(const struct exception_table_entry 
*fixup,
 }
 EXPORT_SYMBOL(ex_handler_ext);
 
+bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
+struct pt_regs *regs, int trapnr)
+{
+   WARN(1, "unsafe MSR access error: RDMSR from 0x%x",
+(unsigned int)regs->cx);
+
+   /* If panic_on_oops is set, don't try to recover. */
+   if (panic_on_oops)
+   return false;
+
+   regs->ip = ex_fixup_addr(fixup);
+   regs->ax = 0;
+   regs->dx = 0;
+   return true;
+}
+EXPORT_SYMBOL(ex_handler_rdmsr_unsafe);
+
+bool ex_handler_wrmsr_unsafe(const struct exception_table_entry *fixup,
+struct pt_regs *regs, int trapnr)
+{
+   WARN(1, "unsafe MSR access error: WRMSR to 0x%x (tried to write 
0x%08x%08x)\n",
+(unsigned int)regs->cx,
+(unsigned int)regs->dx, (unsigned int)regs->ax);
+
+   /* If panic_on_oops is set, don't try to recover. */
+   if (panic_on_oops)
+   return false;
+
+   regs->ip = ex_fixup_addr(fixup);
+   return true;
+}
+EXPORT_SYMBOL(ex_handler_wrmsr_unsafe);
+
 bool ex_has_fault_handler(unsigned long ip)
 {
const struct exception_table_entry *e;
-- 
2.5.0


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

[Xen-devel] [PATCH v3 1/5] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks

[Andy Lutomirski]

These hooks match the _safe variants, so name them accordingly.
This will make room for unsafe PV hooks.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/paravirt.h   | 33 +
 arch/x86/include/asm/paravirt_types.h |  8 
 arch/x86/kernel/paravirt.c|  4 ++--
 arch/x86/xen/enlighten.c  |  4 ++--
 4 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index f6192502149e..2e49228ed9a3 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -129,34 +129,35 @@ static inline void wbinvd(void)
 
 #define get_kernel_rpl()  (pv_info.kernel_rpl)
 
-static inline u64 paravirt_read_msr(unsigned msr, int *err)
+static inline u64 paravirt_read_msr_safe(unsigned msr, int *err)
 {
-   return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
+   return PVOP_CALL2(u64, pv_cpu_ops.read_msr_safe, msr, err);
 }
 
-static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned high)
+static inline int paravirt_write_msr_safe(unsigned msr,
+ unsigned low, unsigned high)
 {
-   return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
+   return PVOP_CALL3(int, pv_cpu_ops.write_msr_safe, msr, low, high);
 }
 
 /* These should all do BUG_ON(_err), but our headers are too tangled. */
 #define rdmsr(msr, val1, val2) \
 do {   \
int _err;   \
-   u64 _l = paravirt_read_msr(msr, &_err); \
+   u64 _l = paravirt_read_msr_safe(msr, &_err);\
val1 = (u32)_l; \
val2 = _l >> 32;\
 } while (0)
 
 #define wrmsr(msr, val1, val2) \
 do {   \
-   paravirt_write_msr(msr, val1, val2);\
+   paravirt_write_msr_safe(msr, val1, val2);   \
 } while (0)
 
 #define rdmsrl(msr, val)   \
 do {   \
int _err;   \
-   val = paravirt_read_msr(msr, &_err);\
+   val = paravirt_read_msr_safe(msr, &_err);   \
 } while (0)
 
 static inline void wrmsrl(unsigned msr, u64 val)
@@ -164,23 +165,23 @@ static inline void wrmsrl(unsigned msr, u64 val)
wrmsr(msr, (u32)val, (u32)(val>>32));
 }
 
-#define wrmsr_safe(msr, a, b)  paravirt_write_msr(msr, a, b)
+#define wrmsr_safe(msr, a, b)  paravirt_write_msr_safe(msr, a, b)
 
 /* rdmsr with exception handling */
-#define rdmsr_safe(msr, a, b)  \
-({ \
-   int _err;   \
-   u64 _l = paravirt_read_msr(msr, &_err); \
-   (*a) = (u32)_l; \
-   (*b) = _l >> 32;\
-   _err;   \
+#define rdmsr_safe(msr, a, b)  \
+({ \
+   int _err;   \
+   u64 _l = paravirt_read_msr_safe(msr, &_err);\
+   (*a) = (u32)_l; \
+   (*b) = _l >> 32;\
+   _err;   \
 })
 
 static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
 {
int err;
 
-   *p = paravirt_read_msr(msr, );
+   *p = paravirt_read_msr_safe(msr, );
return err;
 }
 
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 77db5616a473..5a06cccd36f0 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -155,10 +155,10 @@ struct pv_cpu_ops {
void (*cpuid)(unsigned int *eax, unsigned int *ebx,
  unsigned int *ecx, unsigned int *edx);
 
-   /* MSR, PMC and TSR operations.
-  err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
-   u64 (*read_msr)(unsigned int msr, int *err);
-   int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
+   /* MSR operations.
+  err = 0/-EIO.  wrmsr returns 0/-EIO. */
+   u64 (*read_msr_safe)(unsigned int msr, int *err);
+   int (*write_msr_safe)(unsigned int msr, unsigned low, unsigned high);
 
u64 (*read_pmc)(int counter);
 
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index f08ac28b8136..8aad95478ae5 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -339,8 +339,8 @@ __visible struct pv_cpu_ops pv_cpu_ops = {
.write_cr8 = native_write_cr8,
 #endif
.wbinvd = native_wbinvd,
-   .read_msr = native_read_msr_safe,
-   .write_msr = native_write_msr_safe,
+   .read_msr_safe = native_read_msr_safe,
+   .write_msr_safe = native_write_msr_safe,
.read_pmc = 

[Xen-devel] [PATCH v3 4/5] x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y

[Andy Lutomirski]

Enabling CONFIG_PARAVIRT had an unintended side effect: rdmsr turned
into rdmsr_safe and wrmsr turned into wrmsr_safe, even on bare
metal.  Undo that by using the new unsafe paravirt MSR hooks.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/paravirt.h | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 68297d87e85c..0c99f10874e4 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -151,24 +151,21 @@ static inline int paravirt_write_msr_safe(unsigned msr,
return PVOP_CALL3(int, pv_cpu_ops.write_msr_safe, msr, low, high);
 }
 
-/* These should all do BUG_ON(_err), but our headers are too tangled. */
 #define rdmsr(msr, val1, val2) \
 do {   \
-   int _err;   \
-   u64 _l = paravirt_read_msr_safe(msr, &_err);\
+   u64 _l = paravirt_read_msr(msr);\
val1 = (u32)_l; \
val2 = _l >> 32;\
 } while (0)
 
 #define wrmsr(msr, val1, val2) \
 do {   \
-   paravirt_write_msr_safe(msr, val1, val2);   \
+   paravirt_write_msr(msr, val1, val2);\
 } while (0)
 
 #define rdmsrl(msr, val)   \
 do {   \
-   int _err;   \
-   val = paravirt_read_msr_safe(msr, &_err);   \
+   val = paravirt_read_msr(msr);   \
 } while (0)
 
 static inline void wrmsrl(unsigned msr, u64 val)
-- 
2.5.0


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

[Xen-devel] [PATCH v3 0/5] Improve non-"safe" MSR access failure handling

[Andy Lutomirski]

Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently
turns all rdmsr and wrmsr operations into the safe variants without
any checks that the operations actually succeed.

With CONFIG_PARAVIRT=n, unchecked MSR failures OOPS and probably
cause boot to fail if they happen before init starts.

Neither behavior is very good, and it's particularly unfortunate that
the behavior changes depending on CONFIG_PARAVIRT.

In particular, KVM guests might be unwittingly depending on the
PARAVIRT=y behavior because CONFIG_KVM_GUEST currently depends on
CONFIG_PARAVIRT, and, because accesses in that case are completely
unchecked, we wouldn't even see a warning.

This series changes the native behavior, regardless of
CONFIG_PARAVIRT.  A non-"safe" MSR failure will give an informative
warning and will be fixed up -- native_read_msr will return zero,
and both reads and writes will continue where they left off.

If panic_on_oops is set, they will still OOPS and panic.

By using the shiny new custom exception handler infrastructure,
there should be no overhead on the success paths.

I didn't change the behavior on Xen, but, with this series applied,
it would be straightforward for the Xen maintainers to make the
corresponding change -- knowledge of whether the access is "safe" is
now propagated into the pvops.

Doing this is probably a prerequisite to sanely decoupling
CONFIG_KVM_GUEST and CONFIG_PARAVIRT, which would probably make
Arjan and the rest of the Clear Containers people happy :)

There's also room to reduce the code size of the "safe" variants
using custom exception handlers in the future.

Andy Lutomirski (5):
  x86/paravirt: Add _safe to the read_msr and write_msr PV hooks
  x86/msr: Carry on after a non-"safe" MSR access fails without
!panic_on_oops
  x86/paravirt: Add paravirt_{read,write}_msr
  x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y
  x86/msr: Set the return value to zero when native_rdmsr_safe fails

 arch/x86/include/asm/msr.h| 20 
 arch/x86/include/asm/paravirt.h   | 45 +--
 arch/x86/include/asm/paravirt_types.h | 14 +++
 arch/x86/kernel/paravirt.c|  6 +++--
 arch/x86/mm/extable.c | 33 +
 arch/x86/xen/enlighten.c  | 27 +++--
 6 files changed, 114 insertions(+), 31 deletions(-)

-- 
2.5.0


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

[Xen-devel] [PATCH v3 5/5] x86/msr: Set the return value to zero when native_rdmsr_safe fails

[Andy Lutomirski]

This will cause unchecked native_rdmsr_safe failures to return
deterministic results.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/msr.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 13da359881d7..e97e79f8a22b 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -109,7 +109,10 @@ static inline unsigned long long 
native_read_msr_safe(unsigned int msr,
asm volatile("2: rdmsr ; xor %[err],%[err]\n"
 "1:\n\t"
 ".section .fixup,\"ax\"\n\t"
-"3:  mov %[fault],%[err] ; jmp 1b\n\t"
+"3: mov %[fault],%[err]\n\t"
+"xorl %%eax, %%eax\n\t"
+"xorl %%edx, %%edx\n\t"
+"jmp 1b\n\t"
 ".previous\n\t"
 _ASM_EXTABLE(2b, 3b)
 : [err] "=r" (*err), EAX_EDX_RET(val, low, high)
-- 
2.5.0


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

Re: [Xen-devel] Request to revert superpage adjustments

[Daniel Kiper]

On Fri, Mar 11, 2016 at 09:35:19AM -0500, Konrad Rzeszutek Wilk wrote:
> > >>  Nor would
> > >> that deal with avoiding reserved regions not too far above 1Mb,
> > >> since at best the main payload can be relocatable (but certainly
> > >> not the binary seen by the boot loader, as at least multiboot1
> > >> doesn't support anything like that).
> > >
> > > The only reason Xen sits at the 1MB boundary is because of its ELF header.
> > >
> > > A plain binary with a multiboot header has no such restriction, although
> > > we flag an interested to have 4k alignment using the multiboot flags.
> > > There is no technical limitation causing Xen to be linked to run at 1MB;
> > > its just the way its alway been.  There is nothing preventing the entry
> > > point becoming properly relocatable.
>
> And one can make it be at 2MB - which is what Daniel's patches did.

IIRC, with my patches it could be anything which is multiple of 2 MiB.

> (CC-ing Daniel in case I got it wrong). We also needed GRUB2 patches
> to take into account relocating Xen at a different location.

Konrad is correct.

By the way, I would like to mention that probably next week all required
multiboot2 functionality will be available in upstream git tree and later
in GRUB2 2.02 release. This means that new multiboot2 features are almost
set in stone.

> > Without proper container format, how would the boot loader
> > know where to place the binary, or how to relocate it if it doesn't
> > get placed at its linked address? The only alternatives I see in
> > grub1 are a.out and a kludge of a.out, both of which - at the first
> > glance - also don't appear to do any relocation. And for the Linux
> > variant, as said, it doesn't look like it's compatible with us needing
> > multiple modules.

multiboot and multiboot2 (without my extensions) put image exactly at address
specified in ELF or multiboot2 header. This means that boot loader is not able
to relocate image during load. I do not mention that current version of Xen
(without my EFI/multiboot2 patches) is not able to understand relocation
(if it would be provided/executed by loader) too.

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v3 0/4] multiboot2: Add two extensions

[Daniel Kiper]

On Fri, Mar 11, 2016 at 06:33:15PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Friday, March 11, 2016, Daniel Kiper  wrote:
>
> > On Fri, Mar 11, 2016 at 04:44:00PM +0100, Vladimir 'phcoder' Serbinenko
> > wrote:
> >
> > [...]
> >
> > > multiboot2 spec is a rolling update.
> >
> > OK. So, I think that we should do this in that way:
> >   - apply this patch series after polishing;
> > I hope that it will happen next week,
>
>   - update multiboot2 doc,
> >   - add grub_relocator32_efi;
> > should it be 2.02 goal?
> >
> Only if it's small
>
> >   - agree and add support for ELF relocations;
> > should it be 2.02 goal?
> >
> Full ELF relocations are definitely not for 2.02
>
> >
> > Does it make sense?
> >
> yes

Great! Stay tuned... I will polish and repost this patch series next week.

Daniel

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

Re: [Xen-devel] [PATCH 2/3] x86emul: check host features alongside guest ones where needed

[Andrew Cooper]

On 11/03/16 17:34, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1093,6 +1093,22 @@ static bool_t vcpu_has(
>  #define vcpu_must_have_cx16() vcpu_must_have(0x0001, ECX, 13)
>  #define vcpu_must_have_avx()  vcpu_must_have(0x0001, ECX, 28)
>  
> +#ifdef __XEN__
> +/*
> + * Note the (subtle?) difference between vcpu_must_have_() and
> + * vcpu_must_have(): The former only checks guest feature flags,
> + * while the latter also checks host ones, i.e. is required to be used when
> + * emulation code is using the same instruction class for carrying out the
> + * actual operation).
> + */

This comment is now stale.

With this dropped, Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH 3/3] x86emul: support MOVBE and CRC32

[Jan Beulich]

The former in an attempt to at least gradually support all simple data
movement instructions. The latter just because it shares the opcode
with the former.

Signed-off-by: Jan Beulich 

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -78,7 +78,14 @@ static int cpuid(
 unsigned int *edx,
 struct x86_emulate_ctxt *ctxt)
 {
+unsigned int leaf = *eax;
+
 asm ("cpuid" : "+a" (*eax), "+c" (*ecx), "=d" (*edx), "=b" (*ebx));
+
+/* The emulator doesn't itself use MOVBE, so we can always run the test. */
+if ( leaf == 1 )
+*ecx |= 1U << 22;
+
 return X86EMUL_OKAY;
 }
 
@@ -605,6 +612,34 @@ int main(int argc, char **argv)
 printf("skipped\n");
 #endif
 
+printf("%-40s", "Testing movbe (%%ecx),%%eax...");
+instr[0] = 0x0f; instr[1] = 0x38; instr[2] = 0xf0; instr[3] = 0x01;
+regs.eflags = 0x200;
+regs.eip= (unsigned long)[0];
+regs.ecx= (unsigned long)res;
+regs.eax= 0x;
+*res= 0x12345678;
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (*res != 0x12345678) ||
+ (regs.eax != 0x78563412) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)[4]) )
+goto fail;
+printf("okay\n");
+
+printf("%-40s", "Testing movbe %%ax,(%%ecx)...");
+instr[0] = 0x66; instr[1] = 0x0f; instr[2] = 0x38; instr[3] = 0xf1; 
instr[4] = 0x01;
+regs.eip = (unsigned long)[0];
+rc = x86_emulate(, );
+if ( (rc != X86EMUL_OKAY) ||
+ (*res != 0x12341234) ||
+ (regs.eax != 0x78563412) ||
+ (regs.eflags != 0x200) ||
+ (regs.eip != (unsigned long)[5]) )
+goto fail;
+printf("okay\n");
+
 #define decl_insn(which) extern const unsigned char which[], which##_len[]
 #define put_insn(which, insn) ".pushsection .test, \"ax\", @progbits\n" \
   #which ": " insn "\n" \
--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -12,6 +12,7 @@ typedef bool bool_t;
 
 #define BUG() abort()
 #define ASSERT assert
+#define ASSERT_UNREACHABLE() assert(!__LINE__)
 
 #define cpu_has_amd_erratum(nr) 0
 #define mark_regs_dirty(r) ((void)(r))
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -16,6 +16,7 @@ CFLAGS += -msoft-float
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 $(call cc-option-add,CFLAGS,CC,-Wnested-externs)
 $(call as-insn-check,CFLAGS,CC,"vmcall",-DHAVE_GAS_VMX)
+$(call as-insn-check,CFLAGS,CC,"crc32 %eax$$(comma)%eax",-DHAVE_GAS_SSE4_2)
 $(call as-insn-check,CFLAGS,CC,"invept (%rax)$$(comma)%rax",-DHAVE_GAS_EPT)
 $(call as-insn-check,CFLAGS,CC,"rdfsbase %rax",-DHAVE_GAS_FSGSBASE)
 $(call as-insn-check,CFLAGS,CC,".equ \"x\"$$(comma)1", \
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -188,7 +188,7 @@ static uint8_t twobyte_table[256] = {
 ImplicitOps, ImplicitOps, ImplicitOps, 0,
 ImplicitOps, ImplicitOps, 0, 0,
 /* 0x38 - 0x3F */
-0, 0, 0, 0, 0, 0, 0, 0,
+DstReg|SrcMem|ModRM, 0, 0, 0, 0, 0, 0, 0,
 /* 0x40 - 0x47 */
 DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov,
 DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov,
@@ -1091,6 +1091,8 @@ static bool_t vcpu_has(
 #define vcpu_must_have_sse2() vcpu_must_have(0x0001, EDX, 26)
 #define vcpu_must_have_sse3() vcpu_must_have(0x0001, ECX,  0)
 #define vcpu_must_have_cx16() vcpu_must_have(0x0001, ECX, 13)
+#define vcpu_must_have_sse4_2() vcpu_must_have(0x0001, ECX, 20)
+#define vcpu_must_have_movbe() vcpu_must_have(0x0001, ECX, 22)
 #define vcpu_must_have_avx()  vcpu_must_have(0x0001, ECX, 28)
 
 #ifdef __XEN__
@@ -1503,8 +1505,9 @@ x86_emulate(
 /* Shadow copy of register state. Committed on successful emulation. */
 struct cpu_user_regs _regs = *ctxt->regs;
 
-uint8_t b, d, sib, sib_index, sib_base, twobyte = 0, rex_prefix = 0;
+uint8_t b, d, sib, sib_index, sib_base, rex_prefix = 0;
 uint8_t modrm = 0, modrm_mod = 0, modrm_reg = 0, modrm_rm = 0;
+enum { ext_none, ext_0f, ext_0f38 } ext = ext_none;
 union vex vex = {};
 unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes;
 bool_t lock_prefix = 0;
@@ -1600,9 +1603,18 @@ x86_emulate(
 /* Two-byte opcode? */
 if ( b == 0x0f )
 {
-twobyte = 1;
 b = insn_fetch_type(uint8_t);
 d = twobyte_table[b];
+switch ( b )
+{
+default:
+ext = ext_0f;
+break;
+case 0x38:
+b = insn_fetch_type(uint8_t);
+ext = ext_0f38;
+break;
+}
 }
 
 /* Unrecognised? */
@@ -1619,7 +1631,7 @@ x86_emulate(
 modrm = insn_fetch_type(uint8_t);
 modrm_mod = (modrm & 0xc0) >> 6;
 
-if ( !twobyte && ((b & ~1) == 0xc4) )
+

[Xen-devel] [PATCH 2/3] x86emul: check host features alongside guest ones where needed

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1093,6 +1093,22 @@ static bool_t vcpu_has(
 #define vcpu_must_have_cx16() vcpu_must_have(0x0001, ECX, 13)
 #define vcpu_must_have_avx()  vcpu_must_have(0x0001, ECX, 28)
 
+#ifdef __XEN__
+/*
+ * Note the (subtle?) difference between vcpu_must_have_() and
+ * vcpu_must_have(): The former only checks guest feature flags,
+ * while the latter also checks host ones, i.e. is required to be used when
+ * emulation code is using the same instruction class for carrying out the
+ * actual operation).
+ */
+#define host_and_vcpu_must_have(feat) ({ \
+generate_exception_if(!cpu_has_##feat, EXC_UD, -1); \
+vcpu_must_have_##feat(); \
+})
+#else
+#define host_and_vcpu_must_have(feat) vcpu_must_have_##feat()
+#endif
+
 static int
 in_longmode(
 struct x86_emulate_ctxt *ctxt,
@@ -3102,7 +3118,7 @@ x86_emulate(
 emulate_fpu_insn_memsrc("fildl", src.val);
 break;
 case 1: /* fisttp m32i */
-vcpu_must_have_sse3();
+host_and_vcpu_must_have(sse3);
 ea.bytes = 4;
 dst = ea;
 dst.type = OP_MEM;
@@ -3211,7 +3227,7 @@ x86_emulate(
 emulate_fpu_insn_memsrc("fldl", src.val);
 break;
 case 1: /* fisttp m64i */
-vcpu_must_have_sse3();
+host_and_vcpu_must_have(sse3);
 ea.bytes = 8;
 dst = ea;
 dst.type = OP_MEM;
@@ -3319,7 +3335,7 @@ x86_emulate(
 emulate_fpu_insn_memsrc("filds", src.val);
 break;
 case 1: /* fisttp m16i */
-vcpu_must_have_sse3();
+host_and_vcpu_must_have(sse3);
 ea.bytes = 2;
 dst = ea;
 dst.type = OP_MEM;
@@ -4115,9 +4131,9 @@ x86_emulate(
 if ( vex.opcx == vex_none )
 {
 if ( vex.pfx & VEX_PREFIX_DOUBLE_MASK )
-vcpu_must_have_sse2();
+host_and_vcpu_must_have(sse2);
 else
-vcpu_must_have_sse();
+host_and_vcpu_must_have(sse);
 ea.bytes = 16;
 SET_SSE_PREFIX(buf[0], vex.pfx);
 get_fpu(X86EMUL_FPU_xmm, );
@@ -4128,7 +4144,7 @@ x86_emulate(
 ((vex.reg != 0xf) &&
  ((ea.type == OP_MEM) ||
   !(vex.pfx & VEX_PREFIX_SCALAR_MASK;
-vcpu_must_have_avx();
+host_and_vcpu_must_have(avx);
 get_fpu(X86EMUL_FPU_ymm, );
 ea.bytes = 16 << vex.l;
 }
@@ -4361,16 +4377,16 @@ x86_emulate(
 {
 case vex_66:
 case vex_f3:
-vcpu_must_have_sse2();
+host_and_vcpu_must_have(sse2);
 buf[0] = 0x66; /* movdqa */
 get_fpu(X86EMUL_FPU_xmm, );
 ea.bytes = 16;
 break;
 case vex_none:
 if ( b != 0xe7 )
-vcpu_must_have_mmx();
+host_and_vcpu_must_have(mmx);
 else
-vcpu_must_have_sse();
+host_and_vcpu_must_have(sse);
 get_fpu(X86EMUL_FPU_mmx, );
 ea.bytes = 8;
 break;
@@ -4382,7 +4398,7 @@ x86_emulate(
 {
 fail_if((vex.opcx != vex_0f) || (vex.reg != 0xf) ||
 ((vex.pfx != vex_66) && (vex.pfx != vex_f3)));
-vcpu_must_have_avx();
+host_and_vcpu_must_have(avx);
 get_fpu(X86EMUL_FPU_ymm, );
 ea.bytes = 16 << vex.l;
 }
@@ -4688,7 +4704,7 @@ x86_emulate(
 generate_exception_if((modrm_reg & 7) != 1, EXC_UD, -1);
 generate_exception_if(ea.type != OP_MEM, EXC_UD, -1);
 if ( op_bytes == 8 )
-vcpu_must_have_cx16();
+host_and_vcpu_must_have(cx16);
 op_bytes *= 2;
 
 /* Get actual old value. */


x86emul: check host features alongside guest ones where needed

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1093,6 +1093,22 @@ static bool_t vcpu_has(
 #define vcpu_must_have_cx16() vcpu_must_have(0x0001, ECX, 13)
 #define vcpu_must_have_avx()  vcpu_must_have(0x0001, ECX, 28)
 
+#ifdef __XEN__
+/*
+ * Note the (subtle?) difference between vcpu_must_have_() and
+ * vcpu_must_have(): The former only checks guest feature flags,
+ * while the latter also checks host ones, i.e. is required to be used when
+ * emulation code is using the same instruction class for carrying out the
+ * actual operation).
+ */
+#define host_and_vcpu_must_have(feat) ({ \
+generate_exception_if(!cpu_has_##feat, EXC_UD, -1); \
+vcpu_must_have_##feat(); \
+})

[Xen-devel] [PATCH 1/3] x86: rename XMM* features to SSE*

[Jan Beulich]

The latter are their canonical names, used already in the instruction
emulator.

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

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -205,12 +205,12 @@ static void __init early_cpu_detect(void
c->x86_model += ((eax >> 16) & 0xF) << 4;
c->x86_mask = eax & 15;
edx &= ~cleared_caps[cpufeat_word(X86_FEATURE_FPU)];
-   ecx &= ~cleared_caps[cpufeat_word(X86_FEATURE_XMM3)];
+   ecx &= ~cleared_caps[cpufeat_word(X86_FEATURE_SSE3)];
if (edx & cpufeat_mask(X86_FEATURE_CLFLUSH))
c->x86_cache_alignment = ((ebx >> 8) & 0xff) * 8;
/* Leaf 0x1 capabilities filled in early for Xen. */
c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
-   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = ecx;
+   c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx;
 
if ( cpuid_eax(0x8000) >= 0x8008 )
paddr_bits = cpuid_eax(0x8008) & 0xff;
@@ -249,7 +249,7 @@ static void generic_identify(struct cpui
c->cpuid_level = cpuid_eax(0);
cpuid(0x0001, , , , );
c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
-   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = ecx;
+   c->x86_capability[cpufeat_word(X86_FEATURE_SSE3)] = ecx;
 
if ( cpu_has(c, X86_FEATURE_CLFLUSH) )
c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8;
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2029,7 +2029,7 @@ unsigned long hvm_cr4_guest_reserved_bit
  X86_CR4_PCE |
  (leaf1_edx & cpufeat_mask(X86_FEATURE_FXSR) ?
   X86_CR4_OSFXSR : 0) |
- (leaf1_edx & cpufeat_mask(X86_FEATURE_XMM) ?
+ (leaf1_edx & cpufeat_mask(X86_FEATURE_SSE) ?
   X86_CR4_OSXMMEXCPT : 0) |
  ((restore || nestedhvm_enabled(v->domain)) &&
   (leaf1_ecx & cpufeat_mask(X86_FEATURE_VMXE)) ?
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -1963,7 +1963,7 @@ int nvmx_msr_read_intercept(unsigned int
 data |= X86_CR4_PGE;
 if ( edx & cpufeat_mask(X86_FEATURE_FXSR) )
 data |= X86_CR4_OSFXSR;
-if ( edx & cpufeat_mask(X86_FEATURE_XMM) )
+if ( edx & cpufeat_mask(X86_FEATURE_SSE) )
 data |= X86_CR4_OSXMMEXCPT;
 if ( ecx & cpufeat_mask(X86_FEATURE_VMXE) )
 data |= X86_CR4_VMXE;
--- a/xen/include/asm-x86/amd.h
+++ b/xen/include/asm-x86/amd.h
@@ -22,7 +22,7 @@
cpufeat_mask(X86_FEATURE_CMOV)  | cpufeat_mask(X86_FEATURE_PAT)| \
cpufeat_mask(X86_FEATURE_PSE36) | cpufeat_mask(X86_FEATURE_CLFLUSH)| \
cpufeat_mask(X86_FEATURE_MMX)   | cpufeat_mask(X86_FEATURE_FXSR)   | \
-   cpufeat_mask(X86_FEATURE_XMM)   | cpufeat_mask(X86_FEATURE_XMM2))
+   cpufeat_mask(X86_FEATURE_SSE)   | cpufeat_mask(X86_FEATURE_SSE2))
 #define AMD_EXTFEATURES_K8_REV_C_ECX  0
 #define AMD_EXTFEATURES_K8_REV_C_EDX  (
   \
cpufeat_mask(X86_FEATURE_FPU)  | cpufeat_mask(X86_FEATURE_VME)   | \
@@ -48,7 +48,7 @@
 
 /* Family 0Fh, Revision E */
 #define AMD_FEATURES_K8_REV_E_ECX(AMD_FEATURES_K8_REV_D_ECX |  \
-   cpufeat_mask(X86_FEATURE_XMM3))
+   cpufeat_mask(X86_FEATURE_SSE3))
 #define AMD_FEATURES_K8_REV_E_EDX(AMD_FEATURES_K8_REV_D_EDX |  \
cpufeat_mask(X86_FEATURE_HT))
 #define AMD_EXTFEATURES_K8_REV_E_ECX (AMD_EXTFEATURES_K8_REV_D_ECX |\
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -38,8 +38,8 @@
 #define X86_FEATURE_MMX(0*32+23) /* Multimedia Extensions */
 #define X86_FEATURE_FXSR   (0*32+24) /* FXSAVE and FXRSTOR instructions 
(fast save and restore */
  /* of FPU context), and CR4.OSFXSR 
available */
-#define X86_FEATURE_XMM(0*32+25) /* Streaming SIMD Extensions 
*/
-#define X86_FEATURE_XMM2   (0*32+26) /* Streaming SIMD Extensions-2 */
+#define X86_FEATURE_SSE(0*32+25) /* Streaming SIMD Extensions 
*/
+#define X86_FEATURE_SSE2   (0*32+26) /* Streaming SIMD Extensions-2 */
 #define X86_FEATURE_SELFSNOOP  (0*32+27) /* CPU self snoop */
 #define X86_FEATURE_HT (0*32+28) /* Hyper-Threading */
 #define X86_FEATURE_ACC(0*32+29) /* Automatic clock control */
@@ -78,7 +78,7 @@
 #define X86_FEATURE_APERFMPERF   (3*32+16) /* APERFMPERF */
 
 /* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
-#define X86_FEATURE_XMM3   (4*32+ 0) /* Streaming SIMD Extensions-3 */
+#define X86_FEATURE_SSE3   (4*32+ 0) /* Streaming SIMD Extensions-3 */
 #define X86_FEATURE_PCLMULQDQ  (4*32+ 1) /* Carry-less mulitplication */
 #define X86_FEATURE_DTES64 (4*32+ 2) /* 64-bit Debug Store */
 #define X86_FEATURE_MWAIT  (4*32+ 3) /* Monitor/Mwait 

Re: [Xen-devel] [GRUB2 PATCH v3 0/4] multiboot2: Add two extensions

[Vladimir 'phcoder' Serbinenko]

On Friday, March 11, 2016, Daniel Kiper  wrote:

> On Fri, Mar 11, 2016 at 04:44:00PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
>
> [...]
>
> > multiboot2 spec is a rolling update.
>
> OK. So, I think that we should do this in that way:
>   - apply this patch series after polishing;
> I hope that it will happen next week,

  - update multiboot2 doc,
>   - add grub_relocator32_efi;
> should it be 2.02 goal?
>
Only if it's small

>   - agree and add support for ELF relocations;
> should it be 2.02 goal?
>
Full ELF relocations are definitely not for 2.02

>
> Does it make sense?
>
yes

>
> Daniel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/3] x86: instruction emulator improvements

[Jan Beulich]

1: x86: rename XMM* features to SSE*
2: x86emul: check host features alongside guest ones where needed
3: x86emul: support MOVBE and CRC32

Signed-off-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v3 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization

[Meng Xu]

On Fri, Mar 11, 2016 at 10:55 AM, Dario Faggioli
 wrote:
> On Fri, 2016-03-11 at 09:49 -0500, Meng Xu wrote:
>> > Yes.
>> > Consistency may be helpful to avoid some easy-to-avoid lock errors.
>> > Moreover, without my fix, I think it would not lead dead lock, as
>> > the pcidevs_lock is not being taken
>> > In IRQ context. Right?
>> I think without your fix, the deadlock may still happen due to the
>> rendezvous condition.
>>CPU A|CPU B
>>  | CPU C
>> Step 1| spin_lock   |
>> Step 2|   |
>> spin_lock_irq   |
>> Step 3|| wait for A to
>> unlock |
>> Step 4|
>>   | send rendezvous IPI to A and B
>> Step 5| receive IPI | wait for A to
>> unlock |
>> Step 6| wait for B to handle the IPI| wait for A to unlock |
>> Step 7| spin_unlock
>>
>>
>> Deadlock occurs at Step 6, IMO.
>>
>> Unless we can prove that rendezvous won't happen while
>> spin_lock_irqsave is taken, we have the deadlock hazard.
>>
> Yes. But, in the case of Quan's patch (without it, I mean), have you
> seen where in the code it is that we use spin_lock_irqsave()?
>
> It's inside a function that is called during Xen boot, whose callchain
> starts with iommu_setup(), from __start_xen(). Here's a (big, sorry)
> code snippet of what is around iommu_setup():
>
> ...
> init_idle_domain();
>
> this_cpu(stubs.addr) = alloc_stub_page(smp_processor_id(),
>_cpu(stubs).mfn);
> BUG_ON(!this_cpu(stubs.addr));
>
> trap_init();
> rcu_init();
>
> early_time_init();
>
> arch_init_memory();
>
> alternative_instructions();
>
> local_irq_enable();
>
> pt_pci_init();
>
> vesa_mtrr_init();
>
> acpi_mmcfg_init();
>
> early_msi_init();
>
> iommu_setup();/* setup iommu if available */
>
> smp_prepare_cpus(max_cpus);
>
> spin_debug_enable();
>
> /*
>  * Initialise higher-level timer functions. We do this fairly late
>  * (after interrupts got enabled) because the time bases and scale
>  * factors need to be updated regularly.
>  */
> init_xen_time();
> initialize_keytable();
> console_init_postirq();
>
> system_state = SYS_STATE_smp_boot;
> do_presmp_initcalls();
> for_each_present_cpu ( i )
> {
> /* Set up cpu_to_node[]. */
> srat_detect_node(i);
> /* Set up node_to_cpumask based on cpu_to_node[]. */
> numa_add_cpu(i);
>
> if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
> {
> int ret = cpu_up(i);
> if ( ret != 0 )
> printk("Failed to bring up CPU %u (error %d)\n", i, ret);
> }
> }
> printk("Brought up %ld CPUs\n", (long)num_online_cpus());
> ...
>
> As you can see, it is only *after* iommu_setup() that we call functions
> like smp_prepare_cpus(), do_presmp_initcalls(), and then the loop that
> waits for all the present CPUs to come online.
>
> What that means is that, at iommu_setup() time, there still is only one
> CPU online, and there is not much chances that one single CPU deadlocks
> in a rendezvous!
>
> Honestly, the biggest issue that I think Quan's patch solves, is that
> if we ever want/manage to move spin_debug_enable() up above it, then
> the BUG_ON in check_lock() would trigger the first time that
> pcidevs_lock would be taken with interrupts enabled.

Right! I got it now.. :-)
The lock is initialized as SPIN_LOCK_UNLOCKED.
check_lock() will trigger the BUG_ON when it is used in a interrupt
disabled situation.

>
> Until then, code is technically fine, and, as a matter of fact, I think
> that removing the locking from that particular instance would be an
> equally effective fix!
>
> All that being said, consistency is indeed important, and for the sake
> of it and for other reasons too, even if, strictly speaking, there
> isn't any actual buggy behavior to be fixed here, and it is worthwhile
> conforming to a locking pattern that is consistent with the rules that
> we sat ourselves, unless there's specific reasons not to.

I see. Even though no deadlock may happen, consistency can be the
reason to modify. :-)
But it's good to know the real reason of making the change, which
could be avoiding the deadlock, be consistency, or both.
It seems to me that this is more for consistency, and avoid the
potential deadlock (although not so sure if it will eventually happen,
it could be a hazard.).

Thank you, Dario and Quan, very much for your explanation! :-) They
are really helpful! :-D

BTW, I'm sorry for the messed format of the table. Let me reformat it here:

Condition 1 (C1): Can run in irq context?
  | spin_lock | spin_lock_irq | spin_lock_irqsave
C1 | No   |  Yes  | Yes
C2 |  No|  No | Yes

It may be too 

Re: [Xen-devel] help

[Wei Liu]

Add back xen-devel

On Fri, Mar 11, 2016 at 05:23:22PM +0100, Safa Hamza wrote:
> ok .. can u tell me how compile xen with debug symbols !!  i have xen-syms
> after compiling xen with "make dist-xen XEN_TARGET_ARCH=arm32
> CROSS_COMPILE=arm-linux-gnueabihf- CONFIG_EARLY_PRINTK=omap5432"   is this
> the kernel  with  debug symbols
> 

I'm not sure if you did the right thing because I've never done any ARM
development. I'll let other people answer your question.

Wei.

> On Fri, Mar 11, 2016 at 5:09 PM, Wei Liu  wrote:
> 
> > On Fri, Mar 11, 2016 at 11:02:26AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Mar 11, 2016 at 04:47:47PM +0100, Safa Hamza wrote:
> > > > now i did just like u said ...  a new error appears
> > >
> > > Adding XEn-devel back. Please reply all.
> > >
> > > >
> > **
> > > > U-Boot# fdt addr $dtb_addr_r
> > > > U-Boot# fdt resize
> > > > U-Boot# fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
> > > > U-Boot# fdt resize
> > > > U-Boot# fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\"
> > > > U-Boot# fdt resize
> > > > U-Boot# fdt mknode /chosen modules
> > > > U-Boot# fdt set /chosen/modules '#address-cells' <1>
> > > > U-Boot# fdt set /chosen/modules '#size-cells' <1>
> > > > U-Boot# fdt mknode /chosen/modules module@0
> > > > libfdt fdt_add_subnode(): FDT_ERR_NOSPACE
> > > >
> > **
> > > > but when i wrote  fdt resize before  fdt mknode /chosen/modules
> > module@0
> > > > this error disappear but still the execution stops as i mentioned
> > before
> > > >
> >
> > The message seems quite straight-forward to me -- one of the libfdt
> > function call failed with some error.
> >
> > I'm afraid you need to do some manual debugging to figure out what went
> > wrong.
> >
> > Wei.
> >
> > > > On Fri, Mar 11, 2016 at 4:20 PM, Konrad Rzeszutek Wilk <
> > > > konrad.w...@oracle.com> wrote:
> > > >
> > > > > On Fri, Mar 11, 2016 at 10:20:01AM -0500, Konrad Rzeszutek Wilk
> > wrote:
> > > > > > On Fri, Mar 11, 2016 at 04:05:58PM +0100, Safa Hamza wrote:
> > > > >
> > > > > And please do not drop Xen-devel. Adding it back on.
> > > > >
> > > > > > > i did like u said but nothing change ..
> > > > > > >
> > > > > >
> > > > > > No you didn't. See below:
> > > > > > > U-Boot# setenv dom0_bootargs 'console=hvc0,115200n8
> > earlyprintk=xen
> > > > > debug'
> > > > > >
> > > > > > You still have 115200n8
> > > > >
> > >
> > > ___
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> >

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

Re: [Xen-devel] Interested to participate in Outreachy Program

[sabiya kazi]

Hi Doug,
Can you tell me what steps I should follow for this project?
Regards,
Sabiya
On Mar 5, 2016 11:59 PM, "sabiya kazi"  wrote:

>
> Hi Doug,
>
> I would like to work on the project *Rust Bindings for libxl *as a part
> of Outreachy Program 2016.
>
> I have completed my B.E in Computer engineering from Pune Institute Of
> Computer Technology, Pune, India.
>
> I am using opensource software and I would like to contribute to
> opensource community. I am interested in learning system programming and
> virtualization concepts.
>
> Can you please suggest me how to go ahead for this project and
> for submitting my first patch, can you assign a task to work upon?
>
> Regards,
> -Sabiya
>
>
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

On Thu, Oct 1, 2015 at 12:15 AM, Ingo Molnar  wrote:
>
> * Andy Lutomirski  wrote:
>
>> > These could still be open coded in an inlined fashion, like the scheduler 
>> > usage.
>>
>> We could have a raw_rdmsr for those.
>>
>> OTOH, I'm still not 100% convinced that this warn-but-don't-die behavior is
>> worth the effort.  This isn't a frequent source of bugs to my knowledge, and 
>> we
>> don't try to recover from incorrect cr writes, out-of-bounds MMIO, etc, so 
>> do we
>> really gain much by rigging a recovery mechanism for rdmsr and wrmsr failures
>> for code that doesn't use the _safe variants?
>
> It's just the general principle really: don't crash the kernel on bootup. 
> There's
> few things more user hostile than that.
>
> Also, this would maintain the status quo: since we now (accidentally) don't 
> crash
> the kernel on distro kernels (but silently and unsafely ignore the faulting
> instruction), we should not regress that behavior (by adding the chance to 
> crash
> again), but improve upon it.

Just a heads up: the extable improvements in tip:ras/core make it
straightforward to get the best of all worlds: explicit failure
handling (written in C!), no fast path overhead whatsoever, and no new
garbage in the exception handlers.

Patches coming once I test them.

>
> Thanks,
>
> Ingo



-- 
Andy Lutomirski
AMA Capital Management, LLC

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

Re: [Xen-devel] [GRUB2 PATCH v3 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

On Fri, Mar 11, 2016 at 04:42:27PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Friday, March 11, 2016, Daniel Kiper  wrote:
>
> > On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko
> > wrote:
> > > On Wednesday, March 2, 2016, Daniel Kiper  > > wrote:
> > >
> > > > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit
> > platforms
> > > > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS.
> > > > Relocator
> > > > will set lower parts of %rax and %rbx accordingly to multiboot2
> > > > specification.
> > > > On the other hand processor mode, just before jumping into loaded
> > image,
> > > > will
> > > > be set accordingly to Unified Extensible Firmware Interface
> > Specification,
> > > > Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services.
> > This way
> > > > loaded image will be able to use EFI boot services without any issues.
> > > >
> > > > If idea is accepted I will prepare grub_relocator32_efi relocator too.
> >
> > OK, as I can see idea in general is accepted. Do you want
> > grub_relocator32_efi in 2.02 or 2.03 is OK?
> >
> Is there already a user for it? Or someone who is expected to adopt it
> shortly?

I have not heard anything about that. So, safely we can defer it to 2.03.
We should just reserve relevant numbers for required constants and say
somewhere that this feature is not implemented yet.

Daniel

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

[Xen-devel] [PATCH v2] vmx: Restore debug registers when injecting #DB traps

[Ross Lagerwall]

Commit a929bee0e652 ("x86/vmx: Fix injection of #DB traps following
XSA-156") prevents an infinite loop in certain #DB traps. However, it
changed the behavior to not call hvm_hw_inject_trap() for #DB and #AC
traps which which means that the debug registers are not restored
correctly and nullified commit b56ae5b48c38 ("VMX: fix/adjust trap
injection").

To fix this, restore the original code path through hvm_inject_trap(),
but ensure that the struct hvm_trap is populated with all the required
data.

Signed-off-by: Ross Lagerwall 
---
Changed in v2:
Use MASK_EXTR.
Only set instruction length for certain event types.

 xen/arch/x86/hvm/vmx/vmx.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9c5a388..bc4410f 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3091,24 +3091,31 @@ static int vmx_handle_eoi_write(void)
  * It is the callers responsibility to ensure that this function is only used
  * in the context of an appropriate vmexit.
  */
-static void vmx_propagate_intr(void)
+static void vmx_propagate_intr(unsigned long intr)
 {
-unsigned long intr, tmp;
-
-__vmread(VM_EXIT_INTR_INFO, );
-
-ASSERT(intr & INTR_INFO_VALID_MASK);
-
-__vmwrite(VM_ENTRY_INTR_INFO, intr);
+struct hvm_trap trap = {
+.vector = MASK_EXTR(intr, INTR_INFO_VECTOR_MASK),
+.type = MASK_EXTR(intr, INTR_INFO_INTR_TYPE_MASK),
+};
+unsigned long tmp;
 
 if ( intr & INTR_INFO_DELIVER_CODE_MASK )
 {
 __vmread(VM_EXIT_INTR_ERROR_CODE, );
-__vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, tmp);
+trap.error_code = tmp;
 }
+else
+trap.error_code = HVM_DELIVER_NO_ERROR_CODE;
+
+if ( trap.type >= X86_EVENTTYPE_SW_INTERRUPT )
+{
+__vmread(VM_EXIT_INSTRUCTION_LEN, );
+trap.insn_len = tmp;
+}
+else
+trap.insn_len = 0;
 
-__vmread(VM_EXIT_INSTRUCTION_LEN, );
-__vmwrite(VM_ENTRY_INSTRUCTION_LEN, tmp);
+hvm_inject_trap();
 }
 
 static void vmx_idtv_reinject(unsigned long idtv_info)
@@ -3366,7 +3373,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
 write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
 if ( !v->domain->debugger_attached )
-vmx_propagate_intr();
+vmx_propagate_intr(intr_info);
 else
 domain_pause_for_debugger();
 break;
@@ -3437,7 +3444,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 break;
 case TRAP_alignment_check:
 HVMTRACE_1D(TRAP, vector);
-vmx_propagate_intr();
+vmx_propagate_intr(intr_info);
 break;
 case TRAP_nmi:
 if ( MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK) !=
-- 
2.4.3


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

Re: [Xen-devel] [GRUB2 PATCH v3 0/4] multiboot2: Add two extensions

[Daniel Kiper]

On Fri, Mar 11, 2016 at 04:44:00PM +0100, Vladimir 'phcoder' Serbinenko wrote:

[...]

> multiboot2 spec is a rolling update.

OK. So, I think that we should do this in that way:
  - apply this patch series after polishing;
I hope that it will happen next week,
  - update multiboot2 doc,
  - add grub_relocator32_efi;
should it be 2.02 goal?
  - agree and add support for ELF relocations;
should it be 2.02 goal?

Does it make sense?

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images

[Daniel Kiper]

On Thu, Mar 10, 2016 at 09:44:31PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper  wrote:
>
> > Currently multiboot2 protocol loads image exactly at address specified in
> > ELF or multiboot2 header. This solution works quite well on legacy BIOS
> > platforms. It is possible because memory regions are placed at predictable
> > addresses (though I was not able to find any spec which says that it is
> > strong requirement, so, it looks that it is just a goodwill of hardware
> > designers). However, EFI platforms are more volatile. Even if required
> > memory regions live at specific addresses then they are sometimes simply
> > not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
> > OVMF). This means that you are not able to simply set up final image
> > destination on build time. You have to provide method to relocate image
> > contents to real load address which is usually different than load address
> > specified in ELF and multiboot2 headers.
> >
> > This patch provides all needed machinery to do self relocation in image
> > code.
> > First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load
> > addr),
> > align (required image alignment), preference (it says which memory regions
> > are
> > preferred by image, e.g. none, low, high) from
> > multiboot_header_tag_relocatable
> > header tag contained in binary. Later loader tries to fulfill request (not
> > only
> > that one) and if it succeeds then it informs image about real load address
> > via
> > multiboot_tag_base_addr tag. At this stage GRUB2 role is finished. Starting
> > from now executable must cope with relocations itself using whole static
> > and dynamic knowledge provided by boot loader.
> >
> > This patch does not provide functionality which could do relocations using
> > ELF relocation data.
>
> Can you add a check that image doesn't have any relocation entries? So that
> we fail nicely rather than loading half-working binary?

Make sense. I will do that.

Daniel

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

Re: [Xen-devel] [PATCH v3 3/3] libxl: rename checkpointed_stream to stream_type

[Wei Liu]

On Fri, Mar 11, 2016 at 01:39:04PM +0800, Wen Congyang wrote:
> Signed-off-by: Wen Congyang 
> ---
>  tools/libxl/libxl.c  |  4 ++--
>  tools/libxl/libxl.h  |  8 
>  tools/libxl/libxl_create.c   |  4 ++--
>  tools/libxl/libxl_dom_save.c |  6 +++---
>  tools/libxl/libxl_internal.h |  2 +-
>  tools/libxl/libxl_save_callout.c |  4 ++--
>  tools/libxl/libxl_stream_read.c  |  4 ++--
>  tools/libxl/libxl_stream_write.c |  2 +-
>  tools/libxl/libxl_types.idl  |  2 +-
>  tools/libxl/xl_cmdimpl.c | 16 
>  10 files changed, 30 insertions(+), 22 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 4cdc169..7c2c9fc 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -876,7 +876,7 @@ int libxl_domain_remus_start(libxl_ctx *ctx, 
> libxl_domain_remus_info *info,
>  dss->live = 1;
>  dss->debug = 0;
>  dss->remus = info;
> -dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_REMUS;
> +dss->stream_type = LIBXL_CHECKPOINTED_STREAM_REMUS;
>  
>  assert(info);
>  
> @@ -937,7 +937,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, 
> int fd, int flags,
>  dss->type = type;
>  dss->live = flags & LIBXL_SUSPEND_LIVE;
>  dss->debug = flags & LIBXL_SUSPEND_DEBUG;
> -dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_NONE;
> +dss->stream_type = LIBXL_CHECKPOINTED_STREAM_NONE;
>  
>  rc = libxl__fd_flags_modify_save(gc, dss->fd,
>   ~(O_NONBLOCK|O_NDELAY), 0,
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index f9e3ef5..86b1d06 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -863,6 +863,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
> libxl_mac *src);
>  #define LIBXL_HAVE_SRM_V1 1
>  
>  /*
> + * LIBXL_HAVE_STREAM_TYPE
> + *
> + * If this is define, then the libxl_domain_create_restore() interfaces;s
> + * parameter checkpointed_stream is renamed to stream_type
> + */
> +#define LIBXL_HAVE_STREAM_TYPE 1
> +
> +/*

I retract my ack on this patch because Andrew mentioned on IRC that you
introduced a new macro.

You should update your old one LIBXL_HAVE_CHECKPOINTED_STREAM instead.
The reason is your old code before this patch is not yet released, you
can change it at will.

Wei.

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

Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images

[Vladimir 'phcoder' Serbinenko]

>
>
> > > +  if (relocatable)
> > > +{
> > > +  if (base_addr > min_addr)
> > > +   grub_multiboot_payload_eip += base_addr - min_addr;
> > > +  else
> > > +   grub_multiboot_payload_eip -= min_addr - base_addr;
> > > +}
> > > +
> > >
> > Why is it relative to min_addr? Sounds like it should be just an offset
>
> Ugh... IIRC, it has meaning but I forgot what. I will check it.
> However, this means that I must put comment here.
>

Is it possible that you have confused link address and minimal loading
address? How is entry usually specified in ELF? How do you suggest it
should be done in mb headers?

>
> > from base addr. What do ET_DYN files use?
>
> I will take a look.
>
> Daniel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization

[Dario Faggioli]

On Fri, 2016-03-11 at 09:41 -0500, Meng Xu wrote:
> Thank you very much for your explanation and education! They are
> really helpful! :-D
> 
> Let me summarize: ;-)
> > 
> >  | spin_lock |
> spin_lock_irq | spin_lock_irqsave
> > 
> > Can run in irq context?  | No|  Yes
> | Yes
> > 
> > Can run in irq disabled context?   |
> > No|  No| Yes
>
The table came out mangled, at least in my mail reader. For what I can
see, I think I see the point you're trying to make, and it's hard to
say whether the table itself is right or wrong...

Probably, a table like this, is just not the best way with which to try
to represent things.

For instance, you seem to be saying that spin_lock() can't be used if
interrupts are disabled, which is not true.

For instance, it is perfectly fine to do the following:

    CPU:
    .
    spin_lock_irq(l1);
    .
    .
[1] spin_lock(l2);
    .
    .
[2] spin_unlock(l2);
    .
    .
    spin_unlock_irq(l1);
    .

Even if l2 is also taken in an interrupt handler. In fact, what we want
is make sure that such an interrupt handler that may take l2, does not
interrupt CPU in the [1]--[2] time frame... But that can't happen
because interrupts are already disabled, so just using spin_lock() is
ok, and should be done, as that's cheaper than spin_lock_irqsave().

Fact is, what really matters is whether or not a lock is taken both
inside and outside of IRQ context. As a matter of fact, it is mostly
the case that, if a lock is ever taken inside an interrupt handler,
then spin_lock_irqsave() is what you want... but this does not justify
coming up with a table like the one above and claiming it to be
general.

> Why deadlock may occur if we mix the spin_lock and
> spin_lock_irq(save)?
> If we mix the spin_lock and spin_lock_irq(save), and a group of CPUs
> rendezvousing in an IPI handler, we will have deadlock. Because the
> CPU A that takes spin_lock will wait for the rendezvousing condition
> to be satisfied, while the CPU B that takes th spin_lock_irq(save)
> will not enter into the rendezvousing condition (since it disable the
> interrupt). Then,
> CPU A waits for CPU B to handle the IPI to get out of the
> rendezvousing condition (kind of synchrous point), which won't until
> it gets the spin_lock.
> CPU B waits for CPU A to release the spin_lock, which won't until it
> get out of the rendezvousing condition;
> 
> Are my understanding and summary correct?
> 
Yes, this looks a decent explanation of the rendezvous-related spinlock
problem... Although I prefer the wording that we do have already in
check_lock() and in start_secondary(). :-D

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] help

[Wei Liu]

On Fri, Mar 11, 2016 at 11:02:26AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 11, 2016 at 04:47:47PM +0100, Safa Hamza wrote:
> > now i did just like u said ...  a new error appears
> 
> Adding XEn-devel back. Please reply all.
> 
> > **
> > U-Boot# fdt addr $dtb_addr_r
> > U-Boot# fdt resize
> > U-Boot# fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
> > U-Boot# fdt resize
> > U-Boot# fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\"
> > U-Boot# fdt resize
> > U-Boot# fdt mknode /chosen modules
> > U-Boot# fdt set /chosen/modules '#address-cells' <1>
> > U-Boot# fdt set /chosen/modules '#size-cells' <1>
> > U-Boot# fdt mknode /chosen/modules module@0
> > libfdt fdt_add_subnode(): FDT_ERR_NOSPACE
> > **
> > but when i wrote  fdt resize before  fdt mknode /chosen/modules module@0
> > this error disappear but still the execution stops as i mentioned before
> > 

The message seems quite straight-forward to me -- one of the libfdt
function call failed with some error.

I'm afraid you need to do some manual debugging to figure out what went
wrong.

Wei.

> > On Fri, Mar 11, 2016 at 4:20 PM, Konrad Rzeszutek Wilk <
> > konrad.w...@oracle.com> wrote:
> > 
> > > On Fri, Mar 11, 2016 at 10:20:01AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Mar 11, 2016 at 04:05:58PM +0100, Safa Hamza wrote:
> > >
> > > And please do not drop Xen-devel. Adding it back on.
> > >
> > > > > i did like u said but nothing change ..
> > > > >
> > > >
> > > > No you didn't. See below:
> > > > > U-Boot# setenv dom0_bootargs 'console=hvc0,115200n8 earlyprintk=xen
> > > debug'
> > > >
> > > > You still have 115200n8
> > >
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] help

[Safa Hamza]

i did just like u said ...  a new error appears
**
U-Boot# fdt addr $dtb_addr_r
U-Boot# fdt resize
U-Boot# fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
U-Boot# fdt resize
U-Boot# fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\"
U-Boot# fdt resize
U-Boot# fdt mknode /chosen modules
U-Boot# fdt set /chosen/modules '#address-cells' <1>
U-Boot# fdt set /chosen/modules '#size-cells' <1>
U-Boot# fdt mknode /chosen/modules module@0
libfdt fdt_add_subnode(): FDT_ERR_NOSPACE
**
but when i wrote  fdt resize before  fdt mknode /chosen/modules module@0
this error disappear but still the execution stops as i mentioned before

On Fri, Mar 11, 2016 at 5:02 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:

> On Fri, Mar 11, 2016 at 04:47:47PM +0100, Safa Hamza wrote:
> > now i did just like u said ...  a new error appears
>
> Adding XEn-devel back. Please reply all.
>
> >
> **
> > U-Boot# fdt addr $dtb_addr_r
> > U-Boot# fdt resize
> > U-Boot# fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
> > U-Boot# fdt resize
> > U-Boot# fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\"
> > U-Boot# fdt resize
> > U-Boot# fdt mknode /chosen modules
> > U-Boot# fdt set /chosen/modules '#address-cells' <1>
> > U-Boot# fdt set /chosen/modules '#size-cells' <1>
> > U-Boot# fdt mknode /chosen/modules module@0
> > libfdt fdt_add_subnode(): FDT_ERR_NOSPACE
> >
> **
> > but when i wrote  fdt resize before  fdt mknode /chosen/modules module@0
> > this error disappear but still the execution stops as i mentioned before
> >
> > On Fri, Mar 11, 2016 at 4:20 PM, Konrad Rzeszutek Wilk <
> > konrad.w...@oracle.com> wrote:
> >
> > > On Fri, Mar 11, 2016 at 10:20:01AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Mar 11, 2016 at 04:05:58PM +0100, Safa Hamza wrote:
> > >
> > > And please do not drop Xen-devel. Adding it back on.
> > >
> > > > > i did like u said but nothing change ..
> > > > >
> > > >
> > > > No you didn't. See below:
> > > > > U-Boot# setenv dom0_bootargs 'console=hvc0,115200n8 earlyprintk=xen
> > > debug'
> > > >
> > > > You still have 115200n8
> > >
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [GRUB2 PATCH v3 4/4] multiboot2: Add support for relocatable images

[Daniel Kiper]

On Thu, Mar 10, 2016 at 09:41:26PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper  wrote:
>
> > Currently multiboot2 protocol loads image exactly at address specified in
> > ELF or multiboot2 header. This solution works quite well on legacy BIOS
> > platforms. It is possible because memory regions are placed at predictable
> > addresses (though I was not able to find any spec which says that it is
> > strong requirement, so, it looks that it is just a goodwill of hardware
> > designers). However, EFI platforms are more volatile. Even if required
> > memory regions live at specific addresses then they are sometimes simply
> > not free (e.g. used by boot/runtime services on Dell PowerEdge R820 and
> > OVMF). This means that you are not able to simply set up final image
> > destination on build time. You have to provide method to relocate image
> > contents to real load address which is usually different than load address
> > specified in ELF and multiboot2 headers.
> >
> > This patch provides all needed machinery to do self relocation in image
> > code.
> > First of all GRUB2 reads min_addr (min. load addr), max_addr (max. load
> > addr),
> > align (required image alignment), preference (it says which memory regions
> > are
> > preferred by image, e.g. none, low, high) from
> > multiboot_header_tag_relocatable
> > header tag contained in binary. Later loader tries to fulfill request (not
> > only
> > that one) and if it succeeds then it informs image about real load address
> > via
> > multiboot_tag_base_addr tag. At this stage GRUB2 role is finished. Starting
> > from now executable must cope with relocations itself using whole static
> > and dynamic knowledge provided by boot loader.
> >
> > This patch does not provide functionality which could do relocations using
> > ELF relocation data. However, I was asked by Konrad Rzeszutek Wilk and
> > Vladimir
> > 'phcoder' Serbinenko to investigate that thing. It looks that relevant
> > machinery
> > could be added to existing code (including this patch) without huge effort.
> > Additionally, ELF relocation could live in parallel with self relocation
> > provided
> > by this patch. However, during research I realized that first of all we
> > should
> > establish the details how ELF relocatable image should look like and how
> > it should
> > be build. At least to build proper test/example files.
> >
> > As I saw multiboot2 protocol is able to consume ET_EXEC and ET_DYN ELF
> > files.
> > Potentially we can use ET_DYN file type. It can be build with gcc/ld -pie
> > option.
> > However, it contains a lot of unneeded stuff (e.g. INTERP, DYNAMIC,
> > GNU_EH_FRAME
> > program headers) and it could be quite difficult to drop them (Hmmm... Is
> > it
> > possible to build it properly with custom ld script?).
>
> How big are they? Are they a real problem?

ET_DYN file is ~2.5 times bigger then normal ET_EXEC (I has checked 
multiboot2.elf
from GRUB2). There is a chance that we can ignore most of stuff in ET_DYN, 
however,
it does not look nice. IMO, image should have only what is needed by loader.

> > So, I have checked ET_EXEC
> > file type. Sadly in this case linker by default resolves all local symbol
> > relocations
> > and removes relocation related sections. Fortunately it is possible to
> > leave them
> > as is with simple -q/--emit-relocs ld option. However, output file is
> > quite fragile
> > and any operation on it should be done with great care (e.g. strip should
> > be called
> > with --strip-unneeded option). So, this solution is not perfect too. It
> > means that
> > maybe we should look for better solution. However, I think that we should
> > not use
> > any custom tools and focus on functionalities provided by compiler and
> > binutils.
> > In this context ld scripts looks quite promising but maybe you have better
> > solutions.
> > So, what do you think about that?
> >
>  Another possibility is to use intermediary .o files like we do for modules
> and like Linux does for modules AFAIR.

Correct but I think that it would be better to have normal ET_EXEC or ET_DYN 
file.

> > This patch was tested with Xen image which uses that functionality.
> > However, this Xen
> > feature is still under development and new patchset will be released in
> > about 3-4 weeks.
> >
> > Signed-off-by: Daniel Kiper >
> > ---
> > v3 - suggestions/fixes:
> >- reduce number of casts
> >  (suggested by Konrad Rzeszutek Wilk),
> >- remove unneeded space at the end of line
> >  (suggested by Konrad Rzeszutek Wilk),
> >- improve commit message
> >  (suggested by Konrad Rzeszutek Wilk).
> > ---
> >  grub-core/loader/i386/multiboot_mbi.c |6 ++-
> >  grub-core/loader/multiboot.c  |   12 --
> >  grub-core/loader/multiboot_elfxx.c|   28 ++
> >  grub-core/loader/multiboot_mbi2.c |   65
> > ++---
> > 

Re: [Xen-devel] help

[Konrad Rzeszutek Wilk]

On Fri, Mar 11, 2016 at 04:47:47PM +0100, Safa Hamza wrote:
> now i did just like u said ...  a new error appears

Adding XEn-devel back. Please reply all.

> **
> U-Boot# fdt addr $dtb_addr_r
> U-Boot# fdt resize
> U-Boot# fdt set /chosen xen,xen-bootargs \"$xen_bootargs\"
> U-Boot# fdt resize
> U-Boot# fdt set /chosen xen,dom0-bootargs \"$dom0_bootargs\"
> U-Boot# fdt resize
> U-Boot# fdt mknode /chosen modules
> U-Boot# fdt set /chosen/modules '#address-cells' <1>
> U-Boot# fdt set /chosen/modules '#size-cells' <1>
> U-Boot# fdt mknode /chosen/modules module@0
> libfdt fdt_add_subnode(): FDT_ERR_NOSPACE
> **
> but when i wrote  fdt resize before  fdt mknode /chosen/modules module@0
> this error disappear but still the execution stops as i mentioned before
> 
> On Fri, Mar 11, 2016 at 4:20 PM, Konrad Rzeszutek Wilk <
> konrad.w...@oracle.com> wrote:
> 
> > On Fri, Mar 11, 2016 at 10:20:01AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Mar 11, 2016 at 04:05:58PM +0100, Safa Hamza wrote:
> >
> > And please do not drop Xen-devel. Adding it back on.
> >
> > > > i did like u said but nothing change ..
> > > >
> > >
> > > No you didn't. See below:
> > > > U-Boot# setenv dom0_bootargs 'console=hvc0,115200n8 earlyprintk=xen
> > debug'
> > >
> > > You still have 115200n8
> >

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

[Xen-devel] [PATCH] x86emul: special case far branch validation outside of long mode

[Jan Beulich]

In that case (with the new value being held in, or now in one case cast
to, a 32-bit variable) there's no need to go through the long mode part
of the checks.

Primarily this was meant to hopefully address Coverity ID 1355278, but
since the change produces smaller code as well I think we should use it
even if it doesn't help that (benign) warning.

Also it's more in line with jmp_rel() for commit_far_branch() to do the
_regs.eip update, so adjust that at once.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -652,13 +652,20 @@ do {
 _regs.eip = ip; \
 } while (0)
 
-#define validate_far_branch(cs, ip) \
-generate_exception_if(in_longmode(ctxt, ops) && (cs)->attr.fields.l \
-  ? !is_canonical_address(ip)   \
-  : (ip) > (cs)->limit, EXC_GP, 0)
+#define validate_far_branch(cs, ip) ({  \
+if ( sizeof(ip) <= 4 ) {\
+ASSERT(in_longmode(ctxt, ops) <= 0);\
+generate_exception_if((ip) > (cs)->limit, EXC_GP, 0);   \
+} else  \
+generate_exception_if(in_longmode(ctxt, ops) && \
+  (cs)->attr.fields.l   \
+  ? !is_canonical_address(ip)   \
+  : (ip) > (cs)->limit, EXC_GP, 0); \
+})
 
 #define commit_far_branch(cs, ip) ({\
 validate_far_branch(cs, ip);\
+_regs.eip = (ip);   \
 ops->write_segment(x86_seg_cs, cs, ctxt);   \
 })
 
@@ -2787,7 +2794,6 @@ x86_emulate(
  (rc = load_seg(x86_seg_cs, src.val, 1, , ctxt, ops)) ||
  (rc = commit_far_branch(, dst.val)) )
 goto done;
-_regs.eip = dst.val;
 break;
 }
 
@@ -2830,9 +2836,8 @@ x86_emulate(
 eflags &= 0x257fd5;
 _regs.eflags &= mask;
 _regs.eflags |= (eflags & ~mask) | 0x02;
-_regs.eip = eip;
 if ( (rc = load_seg(x86_seg_cs, sel, 1, , ctxt, ops)) ||
- (rc = commit_far_branch(, eip)) )
+ (rc = commit_far_branch(, (uint32_t)eip)) )
 goto done;
 break;
 }
@@ -3465,7 +3470,6 @@ x86_emulate(
 if ( (rc = load_seg(x86_seg_cs, sel, 0, , ctxt, ops)) ||
  (rc = commit_far_branch(, eip)) )
 goto done;
-_regs.eip = eip;
 break;
 }
 
@@ -3767,11 +3771,11 @@ x86_emulate(
   &_regs.eip, op_bytes, ctxt)) ||
  (rc = ops->write_segment(x86_seg_cs, , ctxt)) )
 goto done;
+_regs.eip = src.val;
 }
 else if ( (rc = load_seg(x86_seg_cs, sel, 0, , ctxt, ops)) ||
   (rc = commit_far_branch(, src.val)) )
 goto done;
-_regs.eip = src.val;
 
 dst.type = OP_NONE;
 break;



x86emul: special case far branch validation outside of long mode

In that case (with the new value being held in, or now in one case cast
to, a 32-bit variable) there's no need to go through the long mode part
of the checks.

Primarily this was meant to hopefully address Coverity ID 1355278, but
since the change produces smaller code as well I think we should use it
even if it doesn't help that (benign) warning.

Also it's more in line with jmp_rel() for commit_far_branch() to do the
_regs.eip update, so adjust that at once.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -652,13 +652,20 @@ do {
 _regs.eip = ip; \
 } while (0)
 
-#define validate_far_branch(cs, ip) \
-generate_exception_if(in_longmode(ctxt, ops) && (cs)->attr.fields.l \
-  ? !is_canonical_address(ip)   \
-  : (ip) > (cs)->limit, EXC_GP, 0)
+#define validate_far_branch(cs, ip) ({  \
+if ( sizeof(ip) <= 4 ) {\
+ASSERT(in_longmode(ctxt, ops) <= 0);\
+generate_exception_if((ip) > (cs)->limit, EXC_GP, 0);   \
+} else  \
+generate_exception_if(in_longmode(ctxt, ops) && \
+  (cs)->attr.fields.l   \
+  ? 

Re: [Xen-devel] [PATCH] flask: change default state to enforcing

[Daniel De Graaf]

On 03/11/2016 10:43 AM, Jan Beulich wrote:

On 11.03.16 at 16:39,  wrote:

On 03/11/2016 04:07 AM, Jan Beulich wrote:

On 10.03.16 at 19:30,  wrote:

This change will cause the boot to fail if you do not specify an XSM
policy during boot; if you need to load a policy from dom0, use the
"flask=late" boot parameter.


And what mode is the system in until that happens? From the
command line doc, I understand it would be in not-enforcing
mode, but that seems contrary to the code (already before
your change) setting flask_enforcing to 1 in that case.


The FLASK code does not deny any actions until a policy has been loaded,
so the flask_enforcing value only takes effect then.  With flask=late,
userspace code can also adjust the value (xl setenforce) before loading
the policy.


So doesn't this leave the system again in an insecure state then?

Jan


It does, at least until the policy is loaded.  The point of "flask=late" is
that dom0 loads the policy early in boot, preferably before creating any
domains.  Since all xen architectures now support loading the policy from
the bootloader, this is never a required mode of operation.  We did discuss
preventing the creation of domains without a policy loaded to avoid making
this mistake, but since this is no longer the default, I don't think that
type of guard isnecessary.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH v3 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization

[Dario Faggioli]

On Fri, 2016-03-11 at 09:49 -0500, Meng Xu wrote:
> > Yes.
> > Consistency may be helpful to avoid some easy-to-avoid lock errors.
> > Moreover, without my fix, I think it would not lead dead lock, as
> > the pcidevs_lock is not being taken
> > In IRQ context. Right?
> I think without your fix, the deadlock may still happen due to the
> rendezvous condition.
>    CPU A|CPU B
>  | CPU C
> Step 1| spin_lock   |
> Step 2|   |
> spin_lock_irq   |
> Step 3|| wait for A to
> unlock |
> Step 4|
>   | send rendezvous IPI to A and B
> Step 5| receive IPI | wait for A to
> unlock |
> Step 6| wait for B to handle the IPI| wait for A to unlock |
> Step 7| spin_unlock
> 
> 
> Deadlock occurs at Step 6, IMO.
> 
> Unless we can prove that rendezvous won't happen while
> spin_lock_irqsave is taken, we have the deadlock hazard.
> 
Yes. But, in the case of Quan's patch (without it, I mean), have you
seen where in the code it is that we use spin_lock_irqsave()?

It's inside a function that is called during Xen boot, whose callchain
starts with iommu_setup(), from __start_xen(). Here's a (big, sorry)
code snippet of what is around iommu_setup():

    ...
init_idle_domain();

this_cpu(stubs.addr) = alloc_stub_page(smp_processor_id(),
   _cpu(stubs).mfn);
BUG_ON(!this_cpu(stubs.addr));

trap_init();
rcu_init();

early_time_init();

arch_init_memory();

alternative_instructions();

local_irq_enable();

pt_pci_init();

vesa_mtrr_init();

acpi_mmcfg_init();

early_msi_init();

iommu_setup();/* setup iommu if available */

smp_prepare_cpus(max_cpus);

spin_debug_enable();

/*
 * Initialise higher-level timer functions. We do this fairly late
 * (after interrupts got enabled) because the time bases and scale
 * factors need to be updated regularly.
 */
init_xen_time();
initialize_keytable();
console_init_postirq();

system_state = SYS_STATE_smp_boot;
do_presmp_initcalls();
for_each_present_cpu ( i )
{
/* Set up cpu_to_node[]. */
srat_detect_node(i);
/* Set up node_to_cpumask based on cpu_to_node[]. */
numa_add_cpu(i);

if ( (num_online_cpus() < max_cpus) && !cpu_online(i) )
{
int ret = cpu_up(i);
if ( ret != 0 )
printk("Failed to bring up CPU %u (error %d)\n", i, ret);
}
}
printk("Brought up %ld CPUs\n", (long)num_online_cpus());
...

As you can see, it is only *after* iommu_setup() that we call functions
like smp_prepare_cpus(), do_presmp_initcalls(), and then the loop that
waits for all the present CPUs to come online.

What that means is that, at iommu_setup() time, there still is only one
CPU online, and there is not much chances that one single CPU deadlocks
in a rendezvous!

Honestly, the biggest issue that I think Quan's patch solves, is that
if we ever want/manage to move spin_debug_enable() up above it, then
the BUG_ON in check_lock() would trigger the first time that
pcidevs_lock would be taken with interrupts enabled.

Until then, code is technically fine, and, as a matter of fact, I think
that removing the locking from that particular instance would be an
equally effective fix!

All that being said, consistency is indeed important, and for the sake
of it and for other reasons too, even if, strictly speaking, there
isn't any actual buggy behavior to be fixed here, and it is worthwhile
conforming to a locking pattern that is consistent with the rules that
we sat ourselves, unless there's specific reasons not to.

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [GRUB2 PATCH v3 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Vladimir 'phcoder' Serbinenko]

On Friday, March 11, 2016, Daniel Kiper  wrote:

> On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
> > On Wednesday, March 2, 2016, Daniel Kiper  > wrote:
> >
> > > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit
> platforms
> > > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS.
> > > Relocator
> > > will set lower parts of %rax and %rbx accordingly to multiboot2
> > > specification.
> > > On the other hand processor mode, just before jumping into loaded
> image,
> > > will
> > > be set accordingly to Unified Extensible Firmware Interface
> Specification,
> > > Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services.
> This way
> > > loaded image will be able to use EFI boot services without any issues.
> > >
> > > If idea is accepted I will prepare grub_relocator32_efi relocator too.
>
> OK, as I can see idea in general is accepted. Do you want
> grub_relocator32_efi in 2.02 or 2.03 is OK?
>
> > > Signed-off-by: Daniel Kiper 
> >
> > > ---
> > > v3 - suggestions/fixes:
> > >- reuse grub-core/lib/i386/relocator64.S code
> > >  instead of creating separate assembly file
> > >  (suggested by Vladimir 'phcoder' Serbinenko),
> > >- grub_multiboot_boot() cleanup
> > >  (suggested by Vladimir 'phcoder' Serbinenko),
> > >- reuse multiboot_header_tag_entry_address struct instead
> > >  of creating new one for EFI 64-bit entry point
> > >  (suggested by Vladimir 'phcoder' Serbinenko).
> > > ---
> > >  grub-core/lib/i386/relocator.c|   48
> > > ++
> > >  grub-core/lib/i386/relocator64.S  |3 +++
> > >  grub-core/loader/multiboot.c  |   51
> > > +
> > >  grub-core/loader/multiboot_mbi2.c |   19 +++---
> > >  include/grub/i386/multiboot.h |   11 
> > >  include/grub/i386/relocator.h |   21 +++
> > >  include/multiboot2.h  |1 +
> > >  7 files changed, 145 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/grub-core/lib/i386/relocator.c
> > > b/grub-core/lib/i386/relocator.c
> > > index 71dd4f0..2b0c260 100644
> > > --- a/grub-core/lib/i386/relocator.c
> > > +++ b/grub-core/lib/i386/relocator.c
> > > @@ -69,6 +69,13 @@ extern grub_uint64_t grub_relocator64_rsi;
> > >  extern grub_addr_t grub_relocator64_cr3;
> > >  extern struct grub_i386_idt grub_relocator16_idt;
> > >
> > > +#ifdef GRUB_MACHINE_EFI
> > > +#ifdef __x86_64__
> > > +extern grub_uint8_t grub_relocator64_efi_start;
> > > +extern grub_uint8_t grub_relocator64_efi_end;
> > > +#endif
> > > +#endif
> > > +
> > >
> > Can we move this and all to a separate file to avoid too many #ifdef ?
>
> Do you think about grub-core/lib/i386/relocator-efi.c or something like
> that?
>
 grub-core/lib/x86_64/efi/relocator.c would probably fit in naming scheme
the best

> If yes then I do not think it is a problem.
>
> Daniel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [GRUB2 PATCH v3 0/4] multiboot2: Add two extensions

[Vladimir 'phcoder' Serbinenko]

On Friday, March 11, 2016, Daniel Kiper  wrote:

> On Fri, Mar 11, 2016 at 01:27:32PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
> > On Wednesday, March 9, 2016, Daniel Kiper  > wrote:
> >
> > > On Wed, Mar 02, 2016 at 05:51:36PM +0100, Daniel Kiper wrote:
> > > > Hi,
> > > >
> > > > This patch series:
> > > >   - enables EFI boot services usage in loaded images
> > > > by multiboot2 protocol,
> > > >   - add support for multiboot2 protocol compatible
> > > > relocatable images.
> > > >
> > > > Earlier versions of this patch series are extensively tested
> > > > and used internally at least in Oracle. It should be mentioned
> > > > that this release does not change any functionality introduced
> > > > by earlier releases. It just takes into account comments posted
> > > > by various people.
> > > >
> > > > Hmmm... Ugh... Cough... Is it possible to get this stuff
> > > > into 2.02 train?
> > >
> > > Andrei, Vladimir, ping?
> > >
> > They look reasonable for 2.02. Strictly speaking they're features but
> code
>
> Great! Thanks a lot!
>
> > is well isolated and the alternative is painful. I answered the
> individual
> > mails with review.
>
> I have some questions which I send you shortly.
>
> > Is there a followup with updating multiboot2 docs?
>
> Do you want to have updated docs in 2.02?
>
multiboot2 spec is a rolling update.

>
> By the way, where is multiboot2 doc file, which I should update, in git
> tree?
>
> Daniel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] flask: change default state to enforcing

[Jan Beulich]

>>> On 11.03.16 at 16:39,  wrote:
> On 03/11/2016 04:07 AM, Jan Beulich wrote:
> On 10.03.16 at 19:30,  wrote:
>>> This change will cause the boot to fail if you do not specify an XSM
>>> policy during boot; if you need to load a policy from dom0, use the
>>> "flask=late" boot parameter.
>>
>> And what mode is the system in until that happens? From the
>> command line doc, I understand it would be in not-enforcing
>> mode, but that seems contrary to the code (already before
>> your change) setting flask_enforcing to 1 in that case.
> 
> The FLASK code does not deny any actions until a policy has been loaded,
> so the flask_enforcing value only takes effect then.  With flask=late,
> userspace code can also adjust the value (xl setenforce) before loading
> the policy.

So doesn't this leave the system again in an insecure state then?

Jan


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

Re: [Xen-devel] [PATCH] vmx: Restore debug registers when injecting #DB traps

[Jan Beulich]

>>> On 11.03.16 at 15:51,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3091,24 +3091,23 @@ static int vmx_handle_eoi_write(void)
>   * It is the callers responsibility to ensure that this function is only used
>   * in the context of an appropriate vmexit.
>   */
> -static void vmx_propagate_intr(void)
> +static void vmx_propagate_intr(unsigned long intr)
>  {
> -unsigned long intr, tmp;
> -
> -__vmread(VM_EXIT_INTR_INFO, );
> -
> -ASSERT(intr & INTR_INFO_VALID_MASK);
> -
> -__vmwrite(VM_ENTRY_INTR_INFO, intr);
> +struct hvm_trap trap = {
> +.vector = intr & INTR_INFO_VECTOR_MASK,
> +.type = MASK_EXTR(intr, INTR_INFO_INTR_TYPE_MASK) };

Please use MASK_EXTR() for both. Also the closing brace would better
go on the next line.

> +unsigned long tmp;
>  
>  if ( intr & INTR_INFO_DELIVER_CODE_MASK )
>  {
>  __vmread(VM_EXIT_INTR_ERROR_CODE, );
> -__vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, tmp);
> +trap.error_code = tmp;
>  }
> -
> +else
> +trap.error_code = HVM_DELIVER_NO_ERROR_CODE;
>  __vmread(VM_EXIT_INSTRUCTION_LEN, );
> -__vmwrite(VM_ENTRY_INSTRUCTION_LEN, tmp);
> +trap.insn_len = tmp;

For this one I was unsure already for the original change (but it had
gone in already by the time I got to see it): The VM-exit instruction
length field is undefined (i.e. not necessarily zero) for the #AC
intercept case, and also for some (most) of the #DB ones. I therefore
think this needs some qualification, with zero getting used otherwise.

Jan


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

Re: [Xen-devel] [GRUB2 PATCH v3 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Vladimir 'phcoder' Serbinenko]

On Friday, March 11, 2016, Daniel Kiper  wrote:

> On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
> > On Wednesday, March 2, 2016, Daniel Kiper  > wrote:
> >
> > > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit
> platforms
> > > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS.
> > > Relocator
> > > will set lower parts of %rax and %rbx accordingly to multiboot2
> > > specification.
> > > On the other hand processor mode, just before jumping into loaded
> image,
> > > will
> > > be set accordingly to Unified Extensible Firmware Interface
> Specification,
> > > Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services.
> This way
> > > loaded image will be able to use EFI boot services without any issues.
> > >
> > > If idea is accepted I will prepare grub_relocator32_efi relocator too.
>
> OK, as I can see idea in general is accepted. Do you want
> grub_relocator32_efi in 2.02 or 2.03 is OK?
>
Is there already a user for it? Or someone who is expected to adopt it
shortly?

>
> > > Signed-off-by: Daniel Kiper 
> >
> > > ---
> > > v3 - suggestions/fixes:
> > >- reuse grub-core/lib/i386/relocator64.S code
> > >  instead of creating separate assembly file
> > >  (suggested by Vladimir 'phcoder' Serbinenko),
> > >- grub_multiboot_boot() cleanup
> > >  (suggested by Vladimir 'phcoder' Serbinenko),
> > >- reuse multiboot_header_tag_entry_address struct instead
> > >  of creating new one for EFI 64-bit entry point
> > >  (suggested by Vladimir 'phcoder' Serbinenko).
> > > ---
> > >  grub-core/lib/i386/relocator.c|   48
> > > ++
> > >  grub-core/lib/i386/relocator64.S  |3 +++
> > >  grub-core/loader/multiboot.c  |   51
> > > +
> > >  grub-core/loader/multiboot_mbi2.c |   19 +++---
> > >  include/grub/i386/multiboot.h |   11 
> > >  include/grub/i386/relocator.h |   21 +++
> > >  include/multiboot2.h  |1 +
> > >  7 files changed, 145 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/grub-core/lib/i386/relocator.c
> > > b/grub-core/lib/i386/relocator.c
> > > index 71dd4f0..2b0c260 100644
> > > --- a/grub-core/lib/i386/relocator.c
> > > +++ b/grub-core/lib/i386/relocator.c
> > > @@ -69,6 +69,13 @@ extern grub_uint64_t grub_relocator64_rsi;
> > >  extern grub_addr_t grub_relocator64_cr3;
> > >  extern struct grub_i386_idt grub_relocator16_idt;
> > >
> > > +#ifdef GRUB_MACHINE_EFI
> > > +#ifdef __x86_64__
> > > +extern grub_uint8_t grub_relocator64_efi_start;
> > > +extern grub_uint8_t grub_relocator64_efi_end;
> > > +#endif
> > > +#endif
> > > +
> > >
> > Can we move this and all to a separate file to avoid too many #ifdef ?
>
> Do you think about grub-core/lib/i386/relocator-efi.c or something like
> that?
> If yes then I do not think it is a problem.
>
> Daniel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-4.6-testing test] 85893: tolerable FAIL - PUSHED

[osstest service owner]

flight 85893 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85893/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu  3 host-install(3) broken in 85820 pass in 85893
 test-armhf-armhf-libvirt-qcow2 3 host-install(3) broken in 85820 pass in 85893
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 85820
 test-armhf-armhf-xl  11 guest-start fail pass in 85820
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 85820

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 85324
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 85324
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 85324
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 85324
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 85324

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl  12 migrate-support-check fail in 85820 never pass
 test-armhf-armhf-xl  13 saverestore-support-check fail in 85820 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-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   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
 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  e0493703a96c03aaafc8d179624b89b7cf600916
baseline version:
 xen  93371eb8f67460e336a116c41b6b036caaac3e2b

Last test of basis85324  2016-03-04 12:40:53 Z7 days
Testing same since85820  2016-03-09 16:14:17 Z1 days2 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 

Re: [Xen-devel] [PATCH] flask: change default state to enforcing

[Daniel De Graaf]

On 03/11/2016 04:07 AM, Jan Beulich wrote:

On 10.03.16 at 19:30,  wrote:

This change will cause the boot to fail if you do not specify an XSM
policy during boot; if you need to load a policy from dom0, use the
"flask=late" boot parameter.


And what mode is the system in until that happens? From the
command line doc, I understand it would be in not-enforcing
mode, but that seems contrary to the code (already before
your change) setting flask_enforcing to 1 in that case.


The FLASK code does not deny any actions until a policy has been loaded,
so the flask_enforcing value only takes effect then.  With flask=late,
userspace code can also adjust the value (xl setenforce) before loading
the policy.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [GRUB2 PATCH v3 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image

[Vladimir 'phcoder' Serbinenko]

On Friday, March 11, 2016, Daniel Kiper  wrote:

> On Thu, Mar 10, 2016 at 09:26:06PM +0100, Vladimir 'phcoder' Serbinenko
> wrote:
> > On Wednesday, March 2, 2016, Daniel Kiper  > wrote:
> >
> > > Add tags used to pass ImageHandle to loaded image if requested.
> > > It is used by at least ExitBootServices() function.
> > >
> > > Signed-off-by: Daniel Kiper 
> >
> > > ---
> > > v3 - suggestions/fixes:
> > >- mbi EFI related stuff size calculation
> > >  should depend on target architecture
> > >  (suggested by Konrad Rzeszutek Wilk),
> > >- use plain type instead of pointer
> > >  dereference as sizeof() argument
> > >  (suggested by Konrad Rzeszutek Wilk),
> > >- improve commit message
> > >  (suggested by Konrad Rzeszutek Wilk).
> > > ---
> > >  grub-core/loader/multiboot_mbi2.c |   50
> > > ++---
> > >  include/multiboot2.h  |   16 
> > >  2 files changed, 57 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/grub-core/loader/multiboot_mbi2.c
> > > b/grub-core/loader/multiboot_mbi2.c
> > > index a3dca90..7591edc 100644
> > > --- a/grub-core/loader/multiboot_mbi2.c
> > > +++ b/grub-core/loader/multiboot_mbi2.c
> > > @@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char
> > > *filename)
> > >   case MULTIBOOT_TAG_TYPE_NETWORK:
> > >   case MULTIBOOT_TAG_TYPE_EFI_MMAP:
> > >   case MULTIBOOT_TAG_TYPE_EFI_BS:
> > > + case MULTIBOOT_TAG_TYPE_EFI32_IH:
> > > + case MULTIBOOT_TAG_TYPE_EFI64_IH:
> > > break;
> > >
> > >   default:
> > > @@ -407,16 +409,22 @@ grub_multiboot_get_mbi_size (void)
> > >  + grub_get_multiboot_mmap_count ()
> > >  * sizeof (struct multiboot_mmap_entry)),
> > > MULTIBOOT_TAG_ALIGN)
> > >  + ALIGN_UP (sizeof (struct multiboot_tag_framebuffer),
> > > MULTIBOOT_TAG_ALIGN)
> > > +#ifdef GRUB_MACHINE_EFI
> > > +#ifdef __i386__
> > >  + ALIGN_UP (sizeof (struct multiboot_tag_efi32),
> MULTIBOOT_TAG_ALIGN)
> > > ++ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih),
> > > MULTIBOOT_TAG_ALIGN)
> > > +#endif
> > > +#ifdef __x86_64__
> > >  + ALIGN_UP (sizeof (struct multiboot_tag_efi64),
> MULTIBOOT_TAG_ALIGN)
> > > ++ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih),
> > > MULTIBOOT_TAG_ALIGN)
> > > +#endif
> > > ++ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
> > > +   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
> > > +#endif
> > >
> > It doesn't need to be exact. It's just an upper bound. Feel free to
> > simplify knowing this, removing few #ifdef.
>
> OK.
>
> > >  + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
> > > + sizeof (struct grub_acpi_rsdp_v10),
> MULTIBOOT_TAG_ALIGN)
> > >  + acpiv2_size ()
> > >  + net_size ()
> > > -#ifdef GRUB_MACHINE_EFI
> > > -+ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
> > > -   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
> > > -#endif
> > >  + sizeof (struct multiboot_tag_vbe) + MULTIBOOT_TAG_ALIGN - 1
> > >  + sizeof (struct multiboot_tag_apm) + MULTIBOOT_TAG_ALIGN - 1;
> > >  }
> > > @@ -907,11 +915,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
> > >
> > >if (keep_bs)
> > >  {
> > > -  struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
> > > -  tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
> > > -  tag->size = sizeof (struct multiboot_tag);
> > > -  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > > -   / sizeof (grub_properly_aligned_t);
> > > +  {
> > > +   struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
> > > +   tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
> > > +   tag->size = sizeof (struct multiboot_tag);
> > > +   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > > + / sizeof (grub_properly_aligned_t);
> > > +  }
> > > +
> > > +#ifdef __i386__
> > > +  {
> > > +   struct multiboot_tag_efi32_ih *tag = (struct
> > > multiboot_tag_efi32_ih *) ptrorig;
> > > +   tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
> > > +   tag->size = sizeof (struct multiboot_tag_efi32_ih);
> > > +   tag->pointer = (grub_addr_t) grub_efi_image_handle;
> > > +   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > > + / sizeof (grub_properly_aligned_t);
> > > +  }
> > > +#endif
> > > +
> > > +#ifdef __x86_64__
> > > +  {
> > > +   struct multiboot_tag_efi64_ih *tag = (struct
> > > multiboot_tag_efi64_ih *) ptrorig;
> > > +   tag->type = MULTIBOOT_TAG_TYPE_EFI64_IH;
> > > +   tag->size = sizeof (struct multiboot_tag_efi64_ih);
> > > +   tag->pointer = (grub_addr_t) grub_efi_image_handle;
> > > +   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > > + / sizeof 

[Xen-devel] [qemu-mainline baseline-only test] 44241: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44241 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44241/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 44235

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  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-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 qemuua648c137383d84bc4f95696e5293978d9541a26e
baseline version:
 qemuu97556fe80e4f7252300b3498b3477fb4295153a3

Last test of basis44235  2016-03-09 15:48:52 Z1 days
Testing same since44241  2016-03-11 10:18:46 Z0 days1 attempts


People who touched revisions under test:
  Amit Shah 
  Dr. David Alan Gilbert 
  Frediano Ziglio 
  Gabriel L. Somlo 
  Gabriel Somlo 
  Gerd Hoffmann 
  Jan Kiszka 

Re: [Xen-devel] help

[Konrad Rzeszutek Wilk]

On Fri, Mar 11, 2016 at 10:20:01AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 11, 2016 at 04:05:58PM +0100, Safa Hamza wrote:

And please do not drop Xen-devel. Adding it back on.

> > i did like u said but nothing change ..
> > 
> 
> No you didn't. See below:
> > U-Boot# setenv dom0_bootargs 'console=hvc0,115200n8 earlyprintk=xen debug'
> 
> You still have 115200n8

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

[Xen-devel] [PULL 17/53] msi_supported -> msi_nonbroken

[Michael S. Tsirkin]

Rename controller flag to make it clearer what it means.
Add some documentation as well.

Signed-off-by: Michael S. Tsirkin 
---
 include/hw/pci/msi.h   |  2 +-
 hw/i386/kvm/apic.c |  2 +-
 hw/i386/xen/xen_apic.c |  2 +-
 hw/intc/apic.c |  2 +-
 hw/intc/arm_gicv2m.c   |  2 +-
 hw/intc/openpic.c  |  2 +-
 hw/intc/openpic_kvm.c  |  2 +-
 hw/pci-bridge/pci_bridge_dev.c |  2 +-
 hw/pci/msi.c   | 19 ---
 hw/pci/msix.c  |  2 +-
 hw/ppc/spapr.c |  4 ++--
 hw/ppc/spapr_pci.c |  2 +-
 hw/s390x/s390-pci-bus.c|  2 +-
 13 files changed, 29 insertions(+), 16 deletions(-)

diff --git a/include/hw/pci/msi.h b/include/hw/pci/msi.h
index 50e452b..8124908 100644
--- a/include/hw/pci/msi.h
+++ b/include/hw/pci/msi.h
@@ -29,7 +29,7 @@ struct MSIMessage {
 uint32_t data;
 };
 
-extern bool msi_supported;
+extern bool msi_nonbroken;
 
 void msi_set_message(PCIDevice *dev, MSIMessage msg);
 MSIMessage msi_get_message(PCIDevice *dev, unsigned int vector);
diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c
index 694d398..3c7c8fa 100644
--- a/hw/i386/kvm/apic.c
+++ b/hw/i386/kvm/apic.c
@@ -186,7 +186,7 @@ static void kvm_apic_realize(DeviceState *dev, Error **errp)
   APIC_SPACE_SIZE);
 
 if (kvm_has_gsi_routing()) {
-msi_supported = true;
+msi_nonbroken = true;
 }
 }
 
diff --git a/hw/i386/xen/xen_apic.c b/hw/i386/xen/xen_apic.c
index 2b8d709..21d68ee 100644
--- a/hw/i386/xen/xen_apic.c
+++ b/hw/i386/xen/xen_apic.c
@@ -44,7 +44,7 @@ static void xen_apic_realize(DeviceState *dev, Error **errp)
 s->vapic_control = 0;
 memory_region_init_io(>io_memory, OBJECT(s), _apic_io_ops, s,
   "xen-apic-msi", APIC_SPACE_SIZE);
-msi_supported = true;
+msi_nonbroken = true;
 }
 
 static void xen_apic_set_base(APICCommonState *s, uint64_t val)
diff --git a/hw/intc/apic.c b/hw/intc/apic.c
index a299462..28c2ea5 100644
--- a/hw/intc/apic.c
+++ b/hw/intc/apic.c
@@ -874,7 +874,7 @@ static void apic_realize(DeviceState *dev, Error **errp)
 s->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, apic_timer, s);
 local_apics[s->idx] = s;
 
-msi_supported = true;
+msi_nonbroken = true;
 }
 
 static void apic_class_init(ObjectClass *klass, void *data)
diff --git a/hw/intc/arm_gicv2m.c b/hw/intc/arm_gicv2m.c
index 70c0b97..ebd368b 100644
--- a/hw/intc/arm_gicv2m.c
+++ b/hw/intc/arm_gicv2m.c
@@ -148,7 +148,7 @@ static void gicv2m_realize(DeviceState *dev, Error **errp)
 sysbus_init_irq(SYS_BUS_DEVICE(dev), >spi[i]);
 }
 
-msi_supported = true;
+msi_nonbroken = true;
 kvm_gsi_direct_mapping = true;
 kvm_msi_via_irqfd_allowed = kvm_irqfds_enabled();
 }
diff --git a/hw/intc/openpic.c b/hw/intc/openpic.c
index 903888c..7685250 100644
--- a/hw/intc/openpic.c
+++ b/hw/intc/openpic.c
@@ -1375,7 +1375,7 @@ static void fsl_common_init(OpenPICState *opp)
 
 opp->irq_msi = 224;
 
-msi_supported = true;
+msi_nonbroken = true;
 for (i = 0; i < opp->fsl->max_ext; i++) {
 opp->src[i].level = false;
 }
diff --git a/hw/intc/openpic_kvm.c b/hw/intc/openpic_kvm.c
index 4dcdb61..778af4a 100644
--- a/hw/intc/openpic_kvm.c
+++ b/hw/intc/openpic_kvm.c
@@ -239,7 +239,7 @@ static void kvm_openpic_realize(DeviceState *dev, Error 
**errp)
 memory_listener_register(>mem_listener, _space_memory);
 
 /* indicate pic capabilities */
-msi_supported = true;
+msi_nonbroken = true;
 kvm_kernel_irqchip = true;
 kvm_async_interrupts_allowed = true;
 
diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
index 100bb5e..862a2366 100644
--- a/hw/pci-bridge/pci_bridge_dev.c
+++ b/hw/pci-bridge/pci_bridge_dev.c
@@ -72,7 +72,7 @@ static int pci_bridge_dev_initfn(PCIDevice *dev)
 goto slotid_error;
 }
 if ((bridge_dev->flags & (1 << PCI_BRIDGE_DEV_F_MSI_REQ)) &&
-msi_supported) {
+msi_nonbroken) {
 err = msi_init(dev, 0, 1, true, true);
 if (err < 0) {
 goto msi_error;
diff --git a/hw/pci/msi.c b/hw/pci/msi.c
index 85f21b8..e0e64c2 100644
--- a/hw/pci/msi.c
+++ b/hw/pci/msi.c
@@ -34,8 +34,21 @@
 
 #define PCI_MSI_VECTORS_MAX 32
 
-/* Flag for interrupt controller to declare MSI/MSI-X support */
-bool msi_supported;
+/*
+ * Flag for interrupt controllers to declare broken MSI/MSI-X support.
+ * values: false - broken; true - non-broken.
+ *
+ * Setting this flag to false will remove MSI/MSI-X capability from all 
devices.
+ *
+ * It is preferrable for controllers to set this to true (non-broken) even if
+ * they do not actually support MSI/MSI-X: guests normally probe the controller
+ * type and do not attempt to enable MSI/MSI-X with interrupt controllers not
+ * supporting such, so removing the capability is not required, and
+ * it seems cleaner to have a given device 

Re: [Xen-devel] [PATCH v3 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization

[Meng Xu]

>
>> In fact, the deadlock arises because IRQs interrupt asynchronously what the
>> CPU is doing, and that can happen when the CPU has taken the lock already. 
>> But
>> if the 'asynchronous' part goes away, we really don't care whether a lock is 
>> take
>> at time t1 with IRQ enabled, and at time t2 with IRQ disabled, don't you 
>> think?
>>
>
> Yes.
> Consistency may be helpful to avoid some easy-to-avoid lock errors.
> Moreover, without my fix, I think it would not lead dead lock, as the 
> pcidevs_lock is not being taken
> In IRQ context. Right?

I think without your fix, the deadlock may still happen due to the
rendezvous condition.
   CPU A|CPU B
 | CPU C
Step 1| spin_lock   |
Step 2|   | spin_lock_irq   |
Step 3|| wait for A to unlock |
Step 4|
  | send rendezvous IPI to A and B
Step 5| receive IPI | wait for A to unlock |
Step 6| wait for B to handle the IPI| wait for A to unlock |
Step 7| spin_unlock


Deadlock occurs at Step 6, IMO.

Unless we can prove that rendezvous won't happen while
spin_lock_irqsave is taken, we have the deadlock hazard.

Actually, I'm not quite sure when the rendezvous condition may happen
in  this situation. So probably, in reality, we don't have the
rendezvous condition.

>
>
> For deadlock, I think the key problems are:
>   - A lock can be acquired from IRQ context
>   -The interrupt is delivered to the _same_CPU_ that already holds the lock.
>
>

This is one type of deadlock, not the one due to rendezvous condition,
I think. :-)

Thanks and Best Regards,

Meng

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH] flask: change default state to enforcing

[Konrad Rzeszutek Wilk]

On Fri, Mar 11, 2016 at 02:07:11AM -0700, Jan Beulich wrote:
> >>> On 10.03.16 at 19:30,  wrote:
> > This change will cause the boot to fail if you do not specify an XSM
> > policy during boot; if you need to load a policy from dom0, use the
> > "flask=late" boot parameter.
> 
> And what mode is the system in until that happens? From the
> command line doc, I understand it would be in not-enforcing
> mode, but that seems contrary to the code (already before
> your change) setting flask_enforcing to 1 in that case.
> 
> > Originally by Konrad Rzeszutek Wilk ; modified
> > to also change the default value of flask_enforcing so that the policy
> > is not still in permissive mode.  This also removes the (no longer
> > documented) command line argument directly changing that variable since
> > it has been superseded by the flask= parameter.
> > 
> > Signed-off-by: Daniel De Graaf 
> 
> Question now is - who is to be considered the author of this patch?

Daniel.


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

[Xen-devel] [PATCH] vmx: Restore debug registers when injecting #DB traps

[Ross Lagerwall]

Commit a929bee0e652 ("x86/vmx: Fix injection of #DB traps following
XSA-156") prevents an infinite loop in certain #DB traps. However, it
changed the behavior to not call hvm_hw_inject_trap() for #DB and #AC
traps which which means that the debug registers are not restored
correctly and nullified commit b56ae5b48c38 ("VMX: fix/adjust trap
injection").

To fix this, restore the original code path through hvm_inject_trap(),
but ensure that the struct hvm_trap is populated with all the required
data.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/hvm/vmx/vmx.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 9c5a388..1eddba5 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3091,24 +3091,23 @@ static int vmx_handle_eoi_write(void)
  * It is the callers responsibility to ensure that this function is only used
  * in the context of an appropriate vmexit.
  */
-static void vmx_propagate_intr(void)
+static void vmx_propagate_intr(unsigned long intr)
 {
-unsigned long intr, tmp;
-
-__vmread(VM_EXIT_INTR_INFO, );
-
-ASSERT(intr & INTR_INFO_VALID_MASK);
-
-__vmwrite(VM_ENTRY_INTR_INFO, intr);
+struct hvm_trap trap = {
+.vector = intr & INTR_INFO_VECTOR_MASK,
+.type = MASK_EXTR(intr, INTR_INFO_INTR_TYPE_MASK) };
+unsigned long tmp;
 
 if ( intr & INTR_INFO_DELIVER_CODE_MASK )
 {
 __vmread(VM_EXIT_INTR_ERROR_CODE, );
-__vmwrite(VM_ENTRY_EXCEPTION_ERROR_CODE, tmp);
+trap.error_code = tmp;
 }
-
+else
+trap.error_code = HVM_DELIVER_NO_ERROR_CODE;
 __vmread(VM_EXIT_INSTRUCTION_LEN, );
-__vmwrite(VM_ENTRY_INSTRUCTION_LEN, tmp);
+trap.insn_len = tmp;
+hvm_inject_trap();
 }
 
 static void vmx_idtv_reinject(unsigned long idtv_info)
@@ -3366,7 +3365,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
 write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
 if ( !v->domain->debugger_attached )
-vmx_propagate_intr();
+vmx_propagate_intr(intr_info);
 else
 domain_pause_for_debugger();
 break;
@@ -3437,7 +3436,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 break;
 case TRAP_alignment_check:
 HVMTRACE_1D(TRAP, vector);
-vmx_propagate_intr();
+vmx_propagate_intr(intr_info);
 break;
 case TRAP_nmi:
 if ( MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK) !=
-- 
2.4.3


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

Re: [Xen-devel] help

[Konrad Rzeszutek Wilk]

On Thu, Mar 10, 2016 at 09:04:22PM +0100, Safa Hamza wrote:
> hello
> i'm trying to run xen on omap5 following
> this
> http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM
> 
> the execution stops at this point
> 
> **
> U-Boot SPL 2013.10-rc2 (Mar 08 2016 - 14:23:51)
> OMAP5432 ES2.0
> SPL: Please implement spl_start_uboot() for your board
> SPL: Direct Linux boot not active!
> reading u-boot.img
> reading u-boot.img
> 
> 
> U-Boot 2013.10-rc2 (Mar 08 2016 - 14:23:51)
> 
> CPU  : OMAP5432 ES2.0
> Board: OMAP5432 uEVM
> I2C:   ready
> DRAM:  2 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
> 
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> mmc0 is current device
> reading boot.scr
> ** Unable to read file boot.scr **
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> ** File not found /boot/zImage **
> U-Boot# setenv dtb_addr_r 0x825f
> U-Boot# setenv xen_addr_r 0x9000
> U-Boot# setenv kernel_addr_r 0xa000
> U-Boot# setenv xen_bootargs 'sync_console console=dtuart dtuart=serial2'
> U-Boot# setenv dom0_bootargs 'console=hvc0,115200n8 earlyprintk=xen debug

That does not look right.

console=hvc0 earlyprintk=xen debug 

is more right.

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

Re: [Xen-devel] Request to revert superpage adjustments

[Andrew Cooper]

On 11/03/16 14:13, Jan Beulich wrote:
 On 11.03.16 at 14:21,  wrote:
>> On 11/03/16 12:06, Jan Beulich wrote:
>> On 11.03.16 at 10:22,  wrote:
 Sadly, c/s cf393624 "x86: use 2M superpages for text/data/bss mappings"
 exposes a bug in all Syslinux variants, including ISOlinux and
 PXELinux,  causing a failure to boot.

 Xen currently requires its bootloader to decompress it, and place it at
 the 1MB physical boundary.  The alignment adjustments changed the size
 of the decompressed (post mkelf32) image from 2.2MB to 7.1MB.  These
 restrictions should be fixed independently of this exposed bug.  The
 physical range between 0x10 and 0x10fffe is prime clobbering space
 for buggy BIOSes once the A20 line has been disabled (see c/s 1ed76797),
 and if any reserved memory exists between 1MB and 1MB+sizeof(xen), the
 bootloader wont be able to place Xen at its linked address.

 Grub and iPXE work perfectly well when booting Xen, which is why this is
 now clearly a Syslinux issue (all versions I cared to test, including
 4.x and 6.3 are broken).  However, it clobbers any ability for XenServer
 to do testing, as we PXEBoot our servers for install.  I expect a lot of
 other people will encounter issues once the 4.7 RCs get tested.

 Please revert c/s cf393624 and the following change (c/s 53aa3dde) which
 depends upon the former, until I can work around the existing
 restrictions.  After the restrictions are resolved, the patches can go
 back in, but I am fairly sure I will not have time to resolve the issues
 in the 4.7 timeframe.
>>> I'm kind of hesitant to do a wholesale revert, for two reasons:
>>>
>>> 1) The change would still be useful for xen.efi, which is relocatable
>>> already anyway.
>> The latter change strictly depends on .init having 2M alignment, so
>> needs to go either way.  As for making a split, I am already out of time
>> which is why I opted for the plain revert.
> How about I try to find time to put together a partial revert
> (hopefully early) next week?
>
>>> 2) I cannot currently see how you mean to address the issue:
>>> Even if you made our binary decompress itself, that would only
>>> paper over the issue, and (based on your description) only until
>>> even the compressed image exceeds a certain size.
>> Compressed, Xen is currently 700k and Linux weighs in at ~4MB, which is
>> half the size of the uncompressed Xen with superpages.
> Well, okay, there's some headroom (albeit my xen.gz binaries all are
> above 900k).
>
>>>  Nor would
>>> that deal with avoiding reserved regions not too far above 1Mb,
>>> since at best the main payload can be relocatable (but certainly
>>> not the binary seen by the boot loader, as at least multiboot1
>>> doesn't support anything like that).
>> The only reason Xen sits at the 1MB boundary is because of its ELF header.
>>
>> A plain binary with a multiboot header has no such restriction, although
>> we flag an interested to have 4k alignment using the multiboot flags. 
>> There is no technical limitation causing Xen to be linked to run at 1MB;
>> its just the way its alway been.  There is nothing preventing the entry
>> point becoming properly relocatable.
> Without proper container format, how would the boot loader
> know where to place the binary, or how to relocate it if it doesn't
> get placed at its linked address? The only alternatives I see in
> grub1 are a.out and a kludge of a.out, both of which - at the first
> glance - also don't appear to do any relocation. And for the Linux
> variant, as said, it doesn't look like it's compatible with us needing
> multiple modules.

There is no need for the loader to know or care about the linked address
of the binary.

32bit segment bases are a very easy way around this problem while the
binary locates a suitable region to extract itself into.  The entry %eip
can be inspected to generate a suitable segment base.

~Andrew

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

Re: [Xen-devel] [PATCH v3 3/3] libxl: rename checkpointed_stream to stream_type

[Wei Liu]

On Fri, Mar 11, 2016 at 01:39:04PM +0800, Wen Congyang wrote:
> Signed-off-by: Wen Congyang 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 1/3] libxc: move migration_stream's definition to xenguest.h

[Wei Liu]

On Fri, Mar 11, 2016 at 01:39:02PM +0800, Wen Congyang wrote:
> xc_domain_save() and xc_domain_restore's parameter will use this type,
> so it should be public.
> 
> Signed-off-by: Wen Congyang 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 2/3] tools: change checkpointed_stream's type from int to xc_migration_stream_t

[Wei Liu]

On Fri, Mar 11, 2016 at 01:39:03PM +0800, Wen Congyang wrote:
> checkpointed_stream is also renamed to stream_type
> 
> Signed-off-by: Wen Congyang 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization

[Meng Xu]

Hi Quan and Dario,

On Fri, Mar 11, 2016 at 5:35 AM, Dario Faggioli
 wrote:
> On Fri, 2016-03-11 at 06:54 +, Xu, Quan wrote:
>> On March 11, 2016 11:25am,  wrote:
>> >
>> > On Wed, Mar 9, 2016 at 8:17 AM, Quan Xu  wrote:
>> > >
>> > > pcidevs_lock should be held with interrupt enabled. However there
>> > > remains an exception in AMD IOMMU code, where the lock is
>> > > acquired
>> > > with interrupt disabled. This inconsistency might lead to
>> > > deadlock.
>> > Why will this inconsistency lead to deadlock?
>> > I understand the difference between spin_lock_irqsave(), which
>> > disable interrupt,
>> > and spin_lock(), which allows interrupt, however, I didn't get why
>> > misuse the
>> > spin_lock_irqsave() at the place of spin_lock() could potentially
>> > lead to a
>> > deadlock?
>>
>>  1).As Jan mentioned, The implication from disabling interrupts while
>> acquiring a lock is that the lock is also being acquired by some
>> interrupt handler.
>>   If you mix acquire types, the one not disabling interrupts is prone
>> to be interrupted, and the interrupt trying to get hold of the lock
>> the same CPU already owns.
>>
> The key issue is whether or not a lock can be acquired from IRQ context
> (i.e., in an interrupt handler, or a function called by that, as a
> result of an interrupt occurring).
>
> For lock that can, IRQ disabling variants must be used *everywhere* the
> lock is taken (so, e.g., not only when it is actually taken from IRQ
> context, just *always*!).
>
> If that rule is not honored, we are ok if the lock is taken on CPUA,
> and the interrupt handled on CPUB:
>
>   CPUA  CPUB
>   . .
>   . .
>   spin_lock(l)  .
>   . .
>   . . <-- Interrupt!
>   ..
>   .   spin_lock(l); //spins on l
>   .   x //spins on l
>   .   x //spins on l
>   spin_unlock(l)  . //takes l
>   .   .
>   .   spin_unlock(l);
>   . . <-- .
>   . .
>
> but the following can happen, if the interrupt is delivered to the CPU
> that has already taken the lock:
>
>  CPU
>  .
>  .
> [1]  spin_lock(l);   //takes l
>  .
>  . <-- Interrupt!
>.
>spin_lock(l) // CPU deadlocks
>
> If, in the latter case, spin_lock_irq(l) were used at [1], things would
> have been fine, as the interrupt wouldn't have occurred until l weren't
> released:
>
>   CPU
>   .
>   .
>   spin_lock_irq(l)//takes l
>   .
>   . < Interrupt!
>   .   -   //IRQs are disabled
>   .   -   //IRQs are disabled
>   .   -   //IRQs are disabled
>   spin_unlock_irq(l)  .   //IRQs re-hanbled
>   spin_lock_irq(l);   //takes l
>   .
>   .
>   spin_unlock_irq(l);
>  . <- .
>  .
>
> Note that whether spin_lock_irq() or spin_lock_irqsave() should be
> used, is completely independent from this, and it must be decided
> according to whether IRQs are disabled already or not when taking the
> lock. And (quite obviously, but since wre're here) it is fine to mix
> spin_lock_irq() and spin_lock_irqsave(), as they both disable
> interrupts, which is what matters.
>
> So, now, if we know for sure that a lock is _never_ever_ever_ taken
> from interrupt context, can we mix spin_lock() and spin_lock_irq() on
> it (for whatever reason)? Well, as far as the above reasoning is
> concerned, yes.
>
> In fact, the deadlock arises because IRQs interrupt asynchronously what
> the CPU is doing, and that can happen when the CPU has taken the lock
> already. But if the 'asynchronous' part goes away, we really don't care
> whether a lock is take at time t1 with IRQ enabled, and at time t2 with
> IRQ disabled, don't you think?
>
> Well, here it is where what the comment inside check_lock() describes
> comes into play. As quoted by Qaun already:
>
>>  2). Comment inside check_lock(),
>> we partition locks into IRQ-safe (always held with IRQs disabled) and
>> IRQ-unsafe (always held with IRQs enabled) types. The convention for
>> every lock must be consistently observed else we can deadlock in
>> IRQ-context rendezvous functions (__a rendezvous which gets every CPU
>> into IRQ context before any CPU is released from the rendezvous__).
>> If we can mix IRQ-disabled and IRQ-enabled callers, the following can
>> happen:
>>  * Lock is held by CPU A, with IRQs enabled
>>  * CPU B is spinning on same lock, with IRQs disabled
>>  * Rendezvous starts -- CPU A takes interrupt and enters rendezbous
>> spin
>>  * DEADLOCK -- CPU B will never enter rendezvous, CPU A will never
>> 

Re: [Xen-devel] Request to revert superpage adjustments

[Konrad Rzeszutek Wilk]

> >>  Nor would
> >> that deal with avoiding reserved regions not too far above 1Mb,
> >> since at best the main payload can be relocatable (but certainly
> >> not the binary seen by the boot loader, as at least multiboot1
> >> doesn't support anything like that).
> > 
> > The only reason Xen sits at the 1MB boundary is because of its ELF header.
> > 
> > A plain binary with a multiboot header has no such restriction, although
> > we flag an interested to have 4k alignment using the multiboot flags. 
> > There is no technical limitation causing Xen to be linked to run at 1MB;
> > its just the way its alway been.  There is nothing preventing the entry
> > point becoming properly relocatable.

And one can make it be at 2MB - which is what Daniel's patches did.
(CC-ing Daniel in case I got it wrong). We also needed GRUB2 patches
to take into account relocating Xen at a different location.

> 
> Without proper container format, how would the boot loader
> know where to place the binary, or how to relocate it if it doesn't
> get placed at its linked address? The only alternatives I see in
> grub1 are a.out and a kludge of a.out, both of which - at the first
> glance - also don't appear to do any relocation. And for the Linux
> variant, as said, it doesn't look like it's compatible with us needing
> multiple modules.
> 
> Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] Request to revert superpage adjustments

[Jan Beulich]

>>> On 11.03.16 at 14:21,  wrote:
> On 11/03/16 12:06, Jan Beulich wrote:
> On 11.03.16 at 10:22,  wrote:
>>> Sadly, c/s cf393624 "x86: use 2M superpages for text/data/bss mappings"
>>> exposes a bug in all Syslinux variants, including ISOlinux and
>>> PXELinux,  causing a failure to boot.
>>>
>>> Xen currently requires its bootloader to decompress it, and place it at
>>> the 1MB physical boundary.  The alignment adjustments changed the size
>>> of the decompressed (post mkelf32) image from 2.2MB to 7.1MB.  These
>>> restrictions should be fixed independently of this exposed bug.  The
>>> physical range between 0x10 and 0x10fffe is prime clobbering space
>>> for buggy BIOSes once the A20 line has been disabled (see c/s 1ed76797),
>>> and if any reserved memory exists between 1MB and 1MB+sizeof(xen), the
>>> bootloader wont be able to place Xen at its linked address.
>>>
>>> Grub and iPXE work perfectly well when booting Xen, which is why this is
>>> now clearly a Syslinux issue (all versions I cared to test, including
>>> 4.x and 6.3 are broken).  However, it clobbers any ability for XenServer
>>> to do testing, as we PXEBoot our servers for install.  I expect a lot of
>>> other people will encounter issues once the 4.7 RCs get tested.
>>>
>>> Please revert c/s cf393624 and the following change (c/s 53aa3dde) which
>>> depends upon the former, until I can work around the existing
>>> restrictions.  After the restrictions are resolved, the patches can go
>>> back in, but I am fairly sure I will not have time to resolve the issues
>>> in the 4.7 timeframe.
>> I'm kind of hesitant to do a wholesale revert, for two reasons:
>>
>> 1) The change would still be useful for xen.efi, which is relocatable
>> already anyway.
> 
> The latter change strictly depends on .init having 2M alignment, so
> needs to go either way.  As for making a split, I am already out of time
> which is why I opted for the plain revert.

How about I try to find time to put together a partial revert
(hopefully early) next week?

>> 2) I cannot currently see how you mean to address the issue:
>> Even if you made our binary decompress itself, that would only
>> paper over the issue, and (based on your description) only until
>> even the compressed image exceeds a certain size.
> 
> Compressed, Xen is currently 700k and Linux weighs in at ~4MB, which is
> half the size of the uncompressed Xen with superpages.

Well, okay, there's some headroom (albeit my xen.gz binaries all are
above 900k).

>>  Nor would
>> that deal with avoiding reserved regions not too far above 1Mb,
>> since at best the main payload can be relocatable (but certainly
>> not the binary seen by the boot loader, as at least multiboot1
>> doesn't support anything like that).
> 
> The only reason Xen sits at the 1MB boundary is because of its ELF header.
> 
> A plain binary with a multiboot header has no such restriction, although
> we flag an interested to have 4k alignment using the multiboot flags. 
> There is no technical limitation causing Xen to be linked to run at 1MB;
> its just the way its alway been.  There is nothing preventing the entry
> point becoming properly relocatable.

Without proper container format, how would the boot loader
know where to place the binary, or how to relocate it if it doesn't
get placed at its linked address? The only alternatives I see in
grub1 are a.out and a kludge of a.out, both of which - at the first
glance - also don't appear to do any relocation. And for the Linux
variant, as said, it doesn't look like it's compatible with us needing
multiple modules.

Jan


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

Re: [Xen-devel] [PATCH v3 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization

[Dario Faggioli]

On Fri, 2016-03-11 at 12:36 +, Xu, Quan wrote:
> On March 11, 2016 6:36pm,  wrote:
> > On Fri, 2016-03-11 at 06:54 +, Xu, Quan wrote:
> > > 
> > So, now, if we know for sure that a lock is _never_ever_ever_ taken
> > from
> > interrupt context, can we mix spin_lock() and spin_lock_irq() on it
> > (for whatever
> > reason)? Well, as far as the above reasoning is concerned, yes.
> > 
> I appreciate Dario's explanation.
> btw, be careful of spin_lock_irq(), which includes
> 'ASSERT(local_irq_is_enabled()'..
> 
It does. What about it? That is exactly what marks the difference
between spin_lock_irq() and spin_lock_irqsave(). In fact, the former
should not be used if interrupts are already disabled because then,
when calling the corresponding spin_unlock_irq(), they'd be re-enabled
while instead they shouldn't.

But as said, from the point of view of preventing deadlock, for locks
taken both from inside and outside IRQ context, they're equivalent.

> > 
> > In fact, the deadlock arises because IRQs interrupt asynchronously
> > what the
> > CPU is doing, and that can happen when the CPU has taken the lock
> > already. But
> > if the 'asynchronous' part goes away, we really don't care whether
> > a lock is take
> > at time t1 with IRQ enabled, and at time t2 with IRQ disabled,
> > don't you think?
> > 
> Yes.
> Consistency may be helpful to avoid some easy-to-avoid lock errors.
> Moreover, without my fix, I think it would not lead dead lock, as the
> pcidevs_lock is not being taken
> In IRQ context. Right? 
> 
> 
> For deadlock, I think the key problems are:
>   - A lock can be acquired from IRQ context
>   -The interrupt is delivered to the _same_CPU_ that already holds
> the lock.
> 
In your case, pcidevs_lock is certainly not being taken from both
inside and outside IRQ context. If it where, using spin_lock() --as it
happens basically everywhere in the code-- would be wrong, and using
spin_lock_irq[save]() --as it happens in the only case you're patching-
- would be what would be right!

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
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: sched: Add Meng as RTDS maintainer.

[Meng Xu]

Hi Wei and Quan,

On Fri, Mar 11, 2016 at 8:14 AM, Xu, Quan  wrote:
> On March 10, 2016 11:56pm, Wei Liu wrote:
>> On Thu, Mar 10, 2016 at 10:08:04AM -0500, Meng Xu wrote:
>> > On Thu, Mar 10, 2016 at 9:42 AM, Dario Faggioli
>> >  wrote:
>> > > Meng Xu is one of the maintainers of the RT-Xen project, which is
>> > > from where the RTDS scheduler comes. He also is the main author of
>> > > the version of RTDS that we currently have here upstream.
>> > >
>> > > Since the upstreaming effort, he's continued looking after the code,
>> > > engaging with the community, coming and presenting at XenSummits
>> > > and, last but not least, doing development himself as well as
>> > > directing the work of others, with the aim of improving the
>> > > scheduler.
>> > >
>> > > In summary, he has reached the point, both from thechnical and
>> > > community engagement point of views, where he can effectively serve
>> > > as a maintainer of RTDS code.
>> > >
>> > > Signed-off-by: Dario Faggioli 
>> > > ---
>> >
>> > Thank you very much for the good words, Dario! :-)
>> >
>> > Acked-by: Meng Xu 
>> >
>>
>> Congratulations and welcome on board!
>>
>
> Congratulations~~

Thank you very much! :-D

Best Regards,

Meng


---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [GRUB2 PATCH v3 3/4] multiboot2: Do not pass memory maps to image if EFI boot services are enabled

[Daniel Kiper]

On Thu, Mar 10, 2016 at 09:28:25PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper  wrote:
>
> > Do not pass memory maps to image if it asked for EFI boot services.
> > Main reason for not providing maps is because they will likely be
> > invalid. We do a few allocations after filling them, e.g. for relocator
> > needs. Usually we do not care as we would already finish boot services.
> > If we keep boot services then it is easier to not provide maps. However,
> > if image needs memory maps and they are not provided by bootloader then
> > it should get them itself just before ExitBootServices() call.
> >
> Patch gets too cluttered. Can you provide 2 variants: normal (for commit)
> and with ignoring whitespaces (for review)

Sure thing! I will prepare whole updated patch series next week.
I hope that it is OK for you.

Daniel

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

Re: [Xen-devel] [GRUB2 PATCH v3 2/4] multiboot2: Add tags used to pass ImageHandle to loaded image

[Daniel Kiper]

On Thu, Mar 10, 2016 at 09:26:06PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper  wrote:
>
> > Add tags used to pass ImageHandle to loaded image if requested.
> > It is used by at least ExitBootServices() function.
> >
> > Signed-off-by: Daniel Kiper >
> > ---
> > v3 - suggestions/fixes:
> >- mbi EFI related stuff size calculation
> >  should depend on target architecture
> >  (suggested by Konrad Rzeszutek Wilk),
> >- use plain type instead of pointer
> >  dereference as sizeof() argument
> >  (suggested by Konrad Rzeszutek Wilk),
> >- improve commit message
> >  (suggested by Konrad Rzeszutek Wilk).
> > ---
> >  grub-core/loader/multiboot_mbi2.c |   50
> > ++---
> >  include/multiboot2.h  |   16 
> >  2 files changed, 57 insertions(+), 9 deletions(-)
> >
> > diff --git a/grub-core/loader/multiboot_mbi2.c
> > b/grub-core/loader/multiboot_mbi2.c
> > index a3dca90..7591edc 100644
> > --- a/grub-core/loader/multiboot_mbi2.c
> > +++ b/grub-core/loader/multiboot_mbi2.c
> > @@ -172,6 +172,8 @@ grub_multiboot_load (grub_file_t file, const char
> > *filename)
> >   case MULTIBOOT_TAG_TYPE_NETWORK:
> >   case MULTIBOOT_TAG_TYPE_EFI_MMAP:
> >   case MULTIBOOT_TAG_TYPE_EFI_BS:
> > + case MULTIBOOT_TAG_TYPE_EFI32_IH:
> > + case MULTIBOOT_TAG_TYPE_EFI64_IH:
> > break;
> >
> >   default:
> > @@ -407,16 +409,22 @@ grub_multiboot_get_mbi_size (void)
> >  + grub_get_multiboot_mmap_count ()
> >  * sizeof (struct multiboot_mmap_entry)),
> > MULTIBOOT_TAG_ALIGN)
> >  + ALIGN_UP (sizeof (struct multiboot_tag_framebuffer),
> > MULTIBOOT_TAG_ALIGN)
> > +#ifdef GRUB_MACHINE_EFI
> > +#ifdef __i386__
> >  + ALIGN_UP (sizeof (struct multiboot_tag_efi32), MULTIBOOT_TAG_ALIGN)
> > ++ ALIGN_UP (sizeof (struct multiboot_tag_efi32_ih),
> > MULTIBOOT_TAG_ALIGN)
> > +#endif
> > +#ifdef __x86_64__
> >  + ALIGN_UP (sizeof (struct multiboot_tag_efi64), MULTIBOOT_TAG_ALIGN)
> > ++ ALIGN_UP (sizeof (struct multiboot_tag_efi64_ih),
> > MULTIBOOT_TAG_ALIGN)
> > +#endif
> > ++ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
> > +   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
> > +#endif
> >
> It doesn't need to be exact. It's just an upper bound. Feel free to
> simplify knowing this, removing few #ifdef.

OK.

> >  + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
> > + sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
> >  + acpiv2_size ()
> >  + net_size ()
> > -#ifdef GRUB_MACHINE_EFI
> > -+ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
> > -   + efi_mmap_size, MULTIBOOT_TAG_ALIGN)
> > -#endif
> >  + sizeof (struct multiboot_tag_vbe) + MULTIBOOT_TAG_ALIGN - 1
> >  + sizeof (struct multiboot_tag_apm) + MULTIBOOT_TAG_ALIGN - 1;
> >  }
> > @@ -907,11 +915,35 @@ grub_multiboot_make_mbi (grub_uint32_t *target)
> >
> >if (keep_bs)
> >  {
> > -  struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
> > -  tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
> > -  tag->size = sizeof (struct multiboot_tag);
> > -  ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > -   / sizeof (grub_properly_aligned_t);
> > +  {
> > +   struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
> > +   tag->type = MULTIBOOT_TAG_TYPE_EFI_BS;
> > +   tag->size = sizeof (struct multiboot_tag);
> > +   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > + / sizeof (grub_properly_aligned_t);
> > +  }
> > +
> > +#ifdef __i386__
> > +  {
> > +   struct multiboot_tag_efi32_ih *tag = (struct
> > multiboot_tag_efi32_ih *) ptrorig;
> > +   tag->type = MULTIBOOT_TAG_TYPE_EFI32_IH;
> > +   tag->size = sizeof (struct multiboot_tag_efi32_ih);
> > +   tag->pointer = (grub_addr_t) grub_efi_image_handle;
> > +   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > + / sizeof (grub_properly_aligned_t);
> > +  }
> > +#endif
> > +
> > +#ifdef __x86_64__
> > +  {
> > +   struct multiboot_tag_efi64_ih *tag = (struct
> > multiboot_tag_efi64_ih *) ptrorig;
> > +   tag->type = MULTIBOOT_TAG_TYPE_EFI64_IH;
> > +   tag->size = sizeof (struct multiboot_tag_efi64_ih);
> > +   tag->pointer = (grub_addr_t) grub_efi_image_handle;
> > +   ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
> > + / sizeof (grub_properly_aligned_t);
> > +  }
> > +#endif
> >  }
> >  #endif
> >
> > diff --git a/include/multiboot2.h b/include/multiboot2.h
> > index d96aa40..36a174f 100644
> > --- a/include/multiboot2.h
> > +++ b/include/multiboot2.h
> > @@ -60,6 +60,8 @@
> >  #define MULTIBOOT_TAG_TYPE_NETWORK   16
> >  #define MULTIBOOT_TAG_TYPE_EFI_MMAP  17

Re: [Xen-devel] [PATCH] xen: arm: zero EL2 pagetable pages before use

[Andrew Cooper]

On 11/03/16 13:13, Jan Beulich wrote:
 On 11.03.16 at 13:56,  wrote:
>> On 11/03/16 11:29, Jan Beulich wrote:
>> On 10.03.16 at 23:00,  wrote:
 @@ -771,6 +772,7 @@ void __init setup_frametable_mappings(paddr_t ps, 
 paddr_t pe)
  nr_second = frametable_size >> SECOND_SHIFT;
  second_base = alloc_boot_pages(nr_second, 1);
  second = mfn_to_virt(second_base);
 +memset(second, 0, nr_second * PAGE_SIZE);
  for ( i = 0; i < nr_second; i++ )
  {
  pte = mfn_to_xen_entry(second_base + i, WRITEALLOC);
>>> Along those lines here - use clear_page(), presumably by moving it
>>> into the loop.
>> This need only initialise the entries which are not filled by the loop,
>> which will only be the rounding size up to the next 2M or 32M boundary.
>>
>> Most of the content of 'second' is explicitly initialised, so zeroing it
>> all first is redundant.
> Well, I certainly don't know all the details of how this works on
> ARM, but the way I remember the original problem description
> (sent a few days ago) the problem was with bogus translations
> to be visible transiently. Of course all depends on whether the
> page tables that are being modified here are live ones, which
> I simply don't know.

Looking at the code here, second is hooked into the live pagetables
immediately after the loop.  Therefore, bogus translations will only be
present for the untouched PTEs which make up the alignment space.

However, it is probably best to defer to the ARM maintainers.

~Andrew

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

Re: [Xen-devel] [GRUB2 PATCH v3 1/4] i386/relocator: Add grub_relocator64_efi relocator

[Daniel Kiper]

On Thu, Mar 10, 2016 at 09:23:23PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 2, 2016, Daniel Kiper  wrote:
>
> > Add grub_relocator64_efi relocator. It will be used on EFI 64-bit platforms
> > when multiboot2 compatible image requests MULTIBOOT_TAG_TYPE_EFI_BS.
> > Relocator
> > will set lower parts of %rax and %rbx accordingly to multiboot2
> > specification.
> > On the other hand processor mode, just before jumping into loaded image,
> > will
> > be set accordingly to Unified Extensible Firmware Interface Specification,
> > Version 2.4 Errata B, section 2.3.4, x64 Platforms, boot services. This way
> > loaded image will be able to use EFI boot services without any issues.
> >
> > If idea is accepted I will prepare grub_relocator32_efi relocator too.

OK, as I can see idea in general is accepted. Do you want
grub_relocator32_efi in 2.02 or 2.03 is OK?

> > Signed-off-by: Daniel Kiper >
> > ---
> > v3 - suggestions/fixes:
> >- reuse grub-core/lib/i386/relocator64.S code
> >  instead of creating separate assembly file
> >  (suggested by Vladimir 'phcoder' Serbinenko),
> >- grub_multiboot_boot() cleanup
> >  (suggested by Vladimir 'phcoder' Serbinenko),
> >- reuse multiboot_header_tag_entry_address struct instead
> >  of creating new one for EFI 64-bit entry point
> >  (suggested by Vladimir 'phcoder' Serbinenko).
> > ---
> >  grub-core/lib/i386/relocator.c|   48
> > ++
> >  grub-core/lib/i386/relocator64.S  |3 +++
> >  grub-core/loader/multiboot.c  |   51
> > +
> >  grub-core/loader/multiboot_mbi2.c |   19 +++---
> >  include/grub/i386/multiboot.h |   11 
> >  include/grub/i386/relocator.h |   21 +++
> >  include/multiboot2.h  |1 +
> >  7 files changed, 145 insertions(+), 9 deletions(-)
> >
> > diff --git a/grub-core/lib/i386/relocator.c
> > b/grub-core/lib/i386/relocator.c
> > index 71dd4f0..2b0c260 100644
> > --- a/grub-core/lib/i386/relocator.c
> > +++ b/grub-core/lib/i386/relocator.c
> > @@ -69,6 +69,13 @@ extern grub_uint64_t grub_relocator64_rsi;
> >  extern grub_addr_t grub_relocator64_cr3;
> >  extern struct grub_i386_idt grub_relocator16_idt;
> >
> > +#ifdef GRUB_MACHINE_EFI
> > +#ifdef __x86_64__
> > +extern grub_uint8_t grub_relocator64_efi_start;
> > +extern grub_uint8_t grub_relocator64_efi_end;
> > +#endif
> > +#endif
> > +
> >
> Can we move this and all to a separate file to avoid too many #ifdef ?

Do you think about grub-core/lib/i386/relocator-efi.c or something like that?
If yes then I do not think it is a problem.

Daniel

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

Re: [Xen-devel] Request to revert superpage adjustments

[Andrew Cooper]

On 11/03/16 12:06, Jan Beulich wrote:
 On 11.03.16 at 10:22,  wrote:
>> Sadly, c/s cf393624 "x86: use 2M superpages for text/data/bss mappings"
>> exposes a bug in all Syslinux variants, including ISOlinux and
>> PXELinux,  causing a failure to boot.
>>
>> Xen currently requires its bootloader to decompress it, and place it at
>> the 1MB physical boundary.  The alignment adjustments changed the size
>> of the decompressed (post mkelf32) image from 2.2MB to 7.1MB.  These
>> restrictions should be fixed independently of this exposed bug.  The
>> physical range between 0x10 and 0x10fffe is prime clobbering space
>> for buggy BIOSes once the A20 line has been disabled (see c/s 1ed76797),
>> and if any reserved memory exists between 1MB and 1MB+sizeof(xen), the
>> bootloader wont be able to place Xen at its linked address.
>>
>> Grub and iPXE work perfectly well when booting Xen, which is why this is
>> now clearly a Syslinux issue (all versions I cared to test, including
>> 4.x and 6.3 are broken).  However, it clobbers any ability for XenServer
>> to do testing, as we PXEBoot our servers for install.  I expect a lot of
>> other people will encounter issues once the 4.7 RCs get tested.
>>
>> Please revert c/s cf393624 and the following change (c/s 53aa3dde) which
>> depends upon the former, until I can work around the existing
>> restrictions.  After the restrictions are resolved, the patches can go
>> back in, but I am fairly sure I will not have time to resolve the issues
>> in the 4.7 timeframe.
> I'm kind of hesitant to do a wholesale revert, for two reasons:
>
> 1) The change would still be useful for xen.efi, which is relocatable
> already anyway.

The latter change strictly depends on .init having 2M alignment, so
needs to go either way.  As for making a split, I am already out of time
which is why I opted for the plain revert.

>
> 2) I cannot currently see how you mean to address the issue:
> Even if you made our binary decompress itself, that would only
> paper over the issue, and (based on your description) only until
> even the compressed image exceeds a certain size.

Compressed, Xen is currently 700k and Linux weighs in at ~4MB, which is
half the size of the uncompressed Xen with superpages.

>  Nor would
> that deal with avoiding reserved regions not too far above 1Mb,
> since at best the main payload can be relocatable (but certainly
> not the binary seen by the boot loader, as at least multiboot1
> doesn't support anything like that).

The only reason Xen sits at the 1MB boundary is because of its ELF header.

A plain binary with a multiboot header has no such restriction, although
we flag an interested to have 4k alignment using the multiboot flags. 
There is no technical limitation causing Xen to be linked to run at 1MB;
its just the way its alway been.  There is nothing preventing the entry
point becoming properly relocatable.

~Andrew

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

Re: [Xen-devel] [PATCH 0/6] Support calling functions on dedicated physical cpu

[Peter Zijlstra]

On Fri, Mar 11, 2016 at 01:15:04PM +, One Thousand Gnomes wrote:
> On Fri, 11 Mar 2016 13:25:14 +0100
> Peter Zijlstra  wrote:
> 
> > On Fri, Mar 11, 2016 at 12:59:28PM +0100, Juergen Gross wrote:
> > > Some hardware (e.g. Dell Studio laptops) require special functions to
> > > be called on physical cpu 0 in order to avoid occasional hangs. When
> > > running as dom0 under Xen this could be achieved only via special boot
> > > parameters (vcpu pinning) limiting the hypervisor in it's scheduling
> > > decisions.  
> > 
> > So instead of telling Dell to get their act together and fix their damn
> > firmware, we're going to add the most horrid gunk to the kernel? How
> > does that make sense?
> 
> It's been normal forever. The convention with a lot of older BIOS crap
> was always that it should be called on the boot CPU (APM. PnPBIOS etc).
> 
> It's a stretch pre-EFI to even call it a "bug"

Yeah, I knew about the APM/PnP muck, but I was under the impression this
was about new hardware.


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

Re: [Xen-devel] [PATCH 0/6] Support calling functions on dedicated physical cpu

[One Thousand Gnomes]

On Fri, 11 Mar 2016 13:25:14 +0100
Peter Zijlstra  wrote:

> On Fri, Mar 11, 2016 at 12:59:28PM +0100, Juergen Gross wrote:
> > Some hardware (e.g. Dell Studio laptops) require special functions to
> > be called on physical cpu 0 in order to avoid occasional hangs. When
> > running as dom0 under Xen this could be achieved only via special boot
> > parameters (vcpu pinning) limiting the hypervisor in it's scheduling
> > decisions.  
> 
> So instead of telling Dell to get their act together and fix their damn
> firmware, we're going to add the most horrid gunk to the kernel? How
> does that make sense?

It's been normal forever. The convention with a lot of older BIOS crap
was always that it should be called on the boot CPU (APM. PnPBIOS etc).

It's a stretch pre-EFI to even call it a "bug"

Alan

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

Re: [Xen-devel] [GRUB2 PATCH v3 0/4] multiboot2: Add two extensions

[Daniel Kiper]

On Fri, Mar 11, 2016 at 01:27:32PM +0100, Vladimir 'phcoder' Serbinenko wrote:
> On Wednesday, March 9, 2016, Daniel Kiper  wrote:
>
> > On Wed, Mar 02, 2016 at 05:51:36PM +0100, Daniel Kiper wrote:
> > > Hi,
> > >
> > > This patch series:
> > >   - enables EFI boot services usage in loaded images
> > > by multiboot2 protocol,
> > >   - add support for multiboot2 protocol compatible
> > > relocatable images.
> > >
> > > Earlier versions of this patch series are extensively tested
> > > and used internally at least in Oracle. It should be mentioned
> > > that this release does not change any functionality introduced
> > > by earlier releases. It just takes into account comments posted
> > > by various people.
> > >
> > > Hmmm... Ugh... Cough... Is it possible to get this stuff
> > > into 2.02 train?
> >
> > Andrei, Vladimir, ping?
> >
> They look reasonable for 2.02. Strictly speaking they're features but code

Great! Thanks a lot!

> is well isolated and the alternative is painful. I answered the individual
> mails with review.

I have some questions which I send you shortly.

> Is there a followup with updating multiboot2 docs?

Do you want to have updated docs in 2.02?

By the way, where is multiboot2 doc file, which I should update, in git tree?

Daniel

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

Re: [Xen-devel] [PATCH] xen: sched: Add Meng as RTDS maintainer.

[Xu, Quan]

On March 10, 2016 11:56pm, Wei Liu wrote:
> On Thu, Mar 10, 2016 at 10:08:04AM -0500, Meng Xu wrote:
> > On Thu, Mar 10, 2016 at 9:42 AM, Dario Faggioli
> >  wrote:
> > > Meng Xu is one of the maintainers of the RT-Xen project, which is
> > > from where the RTDS scheduler comes. He also is the main author of
> > > the version of RTDS that we currently have here upstream.
> > >
> > > Since the upstreaming effort, he's continued looking after the code,
> > > engaging with the community, coming and presenting at XenSummits
> > > and, last but not least, doing development himself as well as
> > > directing the work of others, with the aim of improving the
> > > scheduler.
> > >
> > > In summary, he has reached the point, both from thechnical and
> > > community engagement point of views, where he can effectively serve
> > > as a maintainer of RTDS code.
> > >
> > > Signed-off-by: Dario Faggioli 
> > > ---
> >
> > Thank you very much for the good words, Dario! :-)
> >
> > Acked-by: Meng Xu 
> >
> 
> Congratulations and welcome on board!
> 

Congratulations~~
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen: arm: zero EL2 pagetable pages before use

[Jan Beulich]

>>> On 11.03.16 at 13:56,  wrote:
> On 11/03/16 11:29, Jan Beulich wrote:
> On 10.03.16 at 23:00,  wrote:
>>> @@ -771,6 +772,7 @@ void __init setup_frametable_mappings(paddr_t ps, 
>>> paddr_t pe)
>>>  nr_second = frametable_size >> SECOND_SHIFT;
>>>  second_base = alloc_boot_pages(nr_second, 1);
>>>  second = mfn_to_virt(second_base);
>>> +memset(second, 0, nr_second * PAGE_SIZE);
>>>  for ( i = 0; i < nr_second; i++ )
>>>  {
>>>  pte = mfn_to_xen_entry(second_base + i, WRITEALLOC);
>> Along those lines here - use clear_page(), presumably by moving it
>> into the loop.
> 
> This need only initialise the entries which are not filled by the loop,
> which will only be the rounding size up to the next 2M or 32M boundary.
> 
> Most of the content of 'second' is explicitly initialised, so zeroing it
> all first is redundant.

Well, I certainly don't know all the details of how this works on
ARM, but the way I remember the original problem description
(sent a few days ago) the problem was with bogus translations
to be visible transiently. Of course all depends on whether the
page tables that are being modified here are live ones, which
I simply don't know.

Jan


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

Re: [Xen-devel] [PATCH 2/6] sched: add function to execute a function synchronously on a physical cpu

[Juergen Gross]

On 11/03/16 13:57, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 01:48:12PM +0100, Juergen Gross wrote:
>> On 11/03/16 13:42, Peter Zijlstra wrote:
>>> how about something like:
>>>
>>> struct xen_callback_struct {
>>> struct work_struct  work;
>>> struct completion   done;
>   int (*func)(void*);
>>> void *  data;
>>> int ret;
>>> };
>>>
>>> static void xen_callback_f(struct work_struct *work)
>>> {
>>> struct xen_callback_struct *xcs = container_of(work, struct 
>>> xen_callback_struct, work);
>>>
>>> xcs->ret = xcs->func(xcs->data);
>>>
>>> complete(>done);
>>> }
>>>
>>> xen_call_on_cpu_sync(int cpu, int (*func)(void *), void *data)
>>> {
>>> struct xen_callback_state xcs = {
>>> .work = __WORK_INITIALIZER(xcs.work, xen_callback_f);
>>> .done = COMPLETION_INITIALIZER_ONSTACK(xcs.done),
>   .func = func,
>>> .data = data,
>>> };
>>>
>>> queue_work_on(, cpu);
>>> wait_for_completion();
>>>
>>> return xcs.ret;
>>> }
>>>
>>> No mucking about with the scheduler state, no new exported functions
>>> etc..
>>>
>>
>> Hey, I like it. Can't be limited to Xen as on bare metal the function
>> needs to be called on cpu 0, too. But avoiding the scheduler fiddling
>> is much better! As this seems to be required for Dell hardware only,
>> I could add it to some Dell base driver in case you don't want to add
>> it to core code.
> 
> Urgh yeah, saw that in your other mail. It looks like I should go look
> at set_cpus_allowed_ptr() abuse :/
> 
> Not sure where this would fit best, maybe somewhere near workqueue.c or
> smp.c.

At a first glance I think smp.c would be the better choice. I'll have a try.

Thanks,

Juergen


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

Re: [Xen-devel] [PATCH 2/6] sched: add function to execute a function synchronously on a physical cpu

[Peter Zijlstra]

On Fri, Mar 11, 2016 at 01:48:12PM +0100, Juergen Gross wrote:
> On 11/03/16 13:42, Peter Zijlstra wrote:
> > how about something like:
> > 
> > struct xen_callback_struct {
> > struct work_struct  work;
> > struct completion   done;
int (*func)(void*);
> > void *  data;
> > int ret;
> > };
> > 
> > static void xen_callback_f(struct work_struct *work)
> > {
> > struct xen_callback_struct *xcs = container_of(work, struct 
> > xen_callback_struct, work);
> > 
> > xcs->ret = xcs->func(xcs->data);
> > 
> > complete(>done);
> > }
> > 
> > xen_call_on_cpu_sync(int cpu, int (*func)(void *), void *data)
> > {
> > struct xen_callback_state xcs = {
> > .work = __WORK_INITIALIZER(xcs.work, xen_callback_f);
> > .done = COMPLETION_INITIALIZER_ONSTACK(xcs.done),
.func = func,
> > .data = data,
> > };
> > 
> > queue_work_on(, cpu);
> > wait_for_completion();
> > 
> > return xcs.ret;
> > }
> > 
> > No mucking about with the scheduler state, no new exported functions
> > etc..
> > 
> 
> Hey, I like it. Can't be limited to Xen as on bare metal the function
> needs to be called on cpu 0, too. But avoiding the scheduler fiddling
> is much better! As this seems to be required for Dell hardware only,
> I could add it to some Dell base driver in case you don't want to add
> it to core code.

Urgh yeah, saw that in your other mail. It looks like I should go look
at set_cpus_allowed_ptr() abuse :/

Not sure where this would fit best, maybe somewhere near workqueue.c or
smp.c.

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

Re: [Xen-devel] [PATCH] xen: arm: zero EL2 pagetable pages before use

[Andrew Cooper]

On 11/03/16 11:29, Jan Beulich wrote:
 On 10.03.16 at 23:00,  wrote:
> First of all - please correctly Cc maintainers (there were two recent
> changes for ARM).
>
>> --- a/xen/arch/arm/mm.c
>> +++ b/xen/arch/arm/mm.c
>> @@ -730,6 +730,7 @@ void __init setup_xenheap_mappings(unsigned long 
>> base_mfn,
>>  else
>>  {
>>  unsigned long first_mfn = alloc_boot_pages(1, 1);
>> +memset(mfn_to_virt(first_mfn), 0, PAGE_SIZE);
> If I was maintainer of this code, I would demand use of clear_page()
> and ask for insertion of the missing blank line here (separating
> declaration and statements).
>
>> @@ -771,6 +772,7 @@ void __init setup_frametable_mappings(paddr_t ps, 
>> paddr_t pe)
>>  nr_second = frametable_size >> SECOND_SHIFT;
>>  second_base = alloc_boot_pages(nr_second, 1);
>>  second = mfn_to_virt(second_base);
>> +memset(second, 0, nr_second * PAGE_SIZE);
>>  for ( i = 0; i < nr_second; i++ )
>>  {
>>  pte = mfn_to_xen_entry(second_base + i, WRITEALLOC);
> Along those lines here - use clear_page(), presumably by moving it
> into the loop.

This need only initialise the entries which are not filled by the loop,
which will only be the rounding size up to the next 2M or 32M boundary.

Most of the content of 'second' is explicitly initialised, so zeroing it
all first is redundant.

~Andrew

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

Re: [Xen-devel] [PATCH 2/6] sched: add function to execute a function synchronously on a physical cpu

[Juergen Gross]

On 11/03/16 13:42, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 01:19:50PM +0100, Peter Zijlstra wrote:
>> On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
>>> +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
>>> +{
>>> +   cpumask_var_t old_mask;
>>> +   int ret;
>>> +
>>> +   if (cpu >= nr_cpu_ids)
>>> +   return -EINVAL;
>>> +
>>> +   if (!alloc_cpumask_var(_mask, GFP_KERNEL))
>>> +   return -ENOMEM;
>>> +
>>> +   cpumask_copy(old_mask, >cpus_allowed);
>>> +   ret = set_cpus_allowed_ptr(current, cpumask_of(cpu));
>>> +   if (ret)
>>> +   goto out;
>>
>> So what happens if someone does sched_setaffinity() right about here?
>>
>>> +
>>> +   ret = func(par);
>>> +
>>> +   set_cpus_allowed_ptr(current, old_mask);
>>> +
>>> +out:
>>> +   free_cpumask_var(old_mask);
>>> +   return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(call_sync_on_phys_cpu);
>>
>> This is disgusting, and you're adding this to !Xen kernels too.
> 
> how about something like:
> 
> struct xen_callback_struct {
>   struct work_struct  work;
>   struct completion   done;
>   void *  data;
>   int ret;
> };
> 
> static void xen_callback_f(struct work_struct *work)
> {
>   struct xen_callback_struct *xcs = container_of(work, struct 
> xen_callback_struct, work);
> 
>   xcs->ret = xcs->func(xcs->data);
> 
>   complete(>done);
> }
> 
> xen_call_on_cpu_sync(int cpu, int (*func)(void *), void *data)
> {
>   struct xen_callback_state xcs = {
>   .work = __WORK_INITIALIZER(xcs.work, xen_callback_f);
>   .done = COMPLETION_INITIALIZER_ONSTACK(xcs.done),
>   .data = data,
>   };
> 
>   queue_work_on(, cpu);
>   wait_for_completion();
> 
>   return xcs.ret;
> }
> 
> No mucking about with the scheduler state, no new exported functions
> etc..
> 

Hey, I like it. Can't be limited to Xen as on bare metal the function
needs to be called on cpu 0, too. But avoiding the scheduler fiddling
is much better! As this seems to be required for Dell hardware only,
I could add it to some Dell base driver in case you don't want to add
it to core code.


Juergen

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

Re: [Xen-devel] [PATCH 2/6] sched: add function to execute a function synchronously on a physical cpu

[Peter Zijlstra]

On Fri, Mar 11, 2016 at 01:43:53PM +0100, Juergen Gross wrote:
> On 11/03/16 13:19, Peter Zijlstra wrote:
> > On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
> >> +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
> >> +{
> >> +  cpumask_var_t old_mask;
> >> +  int ret;
> >> +
> >> +  if (cpu >= nr_cpu_ids)
> >> +  return -EINVAL;
> >> +
> >> +  if (!alloc_cpumask_var(_mask, GFP_KERNEL))
> >> +  return -ENOMEM;
> >> +
> >> +  cpumask_copy(old_mask, >cpus_allowed);
> >> +  ret = set_cpus_allowed_ptr(current, cpumask_of(cpu));
> >> +  if (ret)
> >> +  goto out;
> > 
> > So what happens if someone does sched_setaffinity() right about here?
> 
> Aah, okay. Seems I should add preempt_disable() in this patch already
> and retry the set_cpus_allowed_ptr() in case cpus_allowed has changed.

Doesn't help, you should simply not _ever_ touch this for random tasks.

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

Re: [Xen-devel] [PATCH 2/6] sched: add function to execute a function synchronously on a physical cpu

[Juergen Gross]

On 11/03/16 13:19, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
>> +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
>> +{
>> +cpumask_var_t old_mask;
>> +int ret;
>> +
>> +if (cpu >= nr_cpu_ids)
>> +return -EINVAL;
>> +
>> +if (!alloc_cpumask_var(_mask, GFP_KERNEL))
>> +return -ENOMEM;
>> +
>> +cpumask_copy(old_mask, >cpus_allowed);
>> +ret = set_cpus_allowed_ptr(current, cpumask_of(cpu));
>> +if (ret)
>> +goto out;
> 
> So what happens if someone does sched_setaffinity() right about here?

Aah, okay. Seems I should add preempt_disable() in this patch already
and retry the set_cpus_allowed_ptr() in case cpus_allowed has changed.

> 
>> +
>> +ret = func(par);
>> +
>> +set_cpus_allowed_ptr(current, old_mask);
>> +
>> +out:
>> +free_cpumask_var(old_mask);
>> +return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(call_sync_on_phys_cpu);
> 
> This is disgusting, and you're adding this to !Xen kernels too.

Sure. It is called on !Xen kernels too. Without Xen it is just omitting
the vcpu pinning. I've copied above logic from dcdbas/i8k (it was open
coded twice).

BTW: I tried to get rid of the complete logic to call a function on cpu
0 only. It was rejected by the Dell maintainers.


Juergen

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

Re: [Xen-devel] [PATCH 2/6] sched: add function to execute a function synchronously on a physical cpu

[Peter Zijlstra]

On Fri, Mar 11, 2016 at 01:19:50PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
> > +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
> > +{
> > +   cpumask_var_t old_mask;
> > +   int ret;
> > +
> > +   if (cpu >= nr_cpu_ids)
> > +   return -EINVAL;
> > +
> > +   if (!alloc_cpumask_var(_mask, GFP_KERNEL))
> > +   return -ENOMEM;
> > +
> > +   cpumask_copy(old_mask, >cpus_allowed);
> > +   ret = set_cpus_allowed_ptr(current, cpumask_of(cpu));
> > +   if (ret)
> > +   goto out;
> 
> So what happens if someone does sched_setaffinity() right about here?
> 
> > +
> > +   ret = func(par);
> > +
> > +   set_cpus_allowed_ptr(current, old_mask);
> > +
> > +out:
> > +   free_cpumask_var(old_mask);
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(call_sync_on_phys_cpu);
> 
> This is disgusting, and you're adding this to !Xen kernels too.

how about something like:

struct xen_callback_struct {
struct work_struct  work;
struct completion   done;
void *  data;
int ret;
};

static void xen_callback_f(struct work_struct *work)
{
struct xen_callback_struct *xcs = container_of(work, struct 
xen_callback_struct, work);

xcs->ret = xcs->func(xcs->data);

complete(>done);
}

xen_call_on_cpu_sync(int cpu, int (*func)(void *), void *data)
{
struct xen_callback_state xcs = {
.work = __WORK_INITIALIZER(xcs.work, xen_callback_f);
.done = COMPLETION_INITIALIZER_ONSTACK(xcs.done),
.data = data,
};

queue_work_on(, cpu);
wait_for_completion();

return xcs.ret;
}

No mucking about with the scheduler state, no new exported functions
etc..

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

Re: [Xen-devel] [PATCH v3 1/2] IOMMU/spinlock: Fix a bug found in AMD IOMMU initialization

[Xu, Quan]

On March 11, 2016 6:36pm,  wrote:
> On Fri, 2016-03-11 at 06:54 +, Xu, Quan wrote:
> > On March 11, 2016 11:25am,  wrote:
> > >
> > > On Wed, Mar 9, 2016 at 8:17 AM, Quan Xu  wrote:
> > > >
> > > > pcidevs_lock should be held with interrupt enabled. However there
> > > > remains an exception in AMD IOMMU code, where the lock is acquired
> > > > with interrupt disabled. This inconsistency might lead to
> > > > deadlock.
> > > Why will this inconsistency lead to deadlock?
> > > I understand the difference between spin_lock_irqsave(), which
> > > disable interrupt, and spin_lock(), which allows interrupt, however,
> > > I didn't get why misuse the
> > > spin_lock_irqsave() at the place of spin_lock() could potentially
> > > lead to a deadlock?
> >
> >  1).As Jan mentioned, The implication from disabling interrupts while
> > acquiring a lock is that the lock is also being acquired by some
> > interrupt handler.
> >   If you mix acquire types, the one not disabling interrupts is prone
> > to be interrupted, and the interrupt trying to get hold of the lock
> > the same CPU already owns.
> >
> The key issue is whether or not a lock can be acquired from IRQ context 
> (i.e., in
> an interrupt handler, or a function called by that, as a result of an 
> interrupt
> occurring).
> 
> For lock that can, IRQ disabling variants must be used *everywhere* the lock 
> is
> taken (so, e.g., not only when it is actually taken from IRQ context, just
> *always*!).
> 
> If that rule is not honored, we are ok if the lock is taken on CPUA, and the
> interrupt handled on CPUB:
> 
>   CPUA              CPUB
>   .                 .
>   .                 .
>   spin_lock(l)      .
>   .                 .
>   .                 . <-- Interrupt!
>   .                        .
>   .                       spin_lock(l); //spins on l
>   .                       x             //spins on l
>   .                       x             //spins on l
>   spin_unlock(l)          .             //takes l
>   .                       .
>   .                       spin_unlock(l);
>   .                 . <-- .
>   .                 .
> 
> but the following can happen, if the interrupt is delivered to the CPU that 
> has
> already taken the lock:
> 
>      CPU
>      .
>      .
> [1]  spin_lock(l);       //takes l
>      .
>      . <-- Interrupt!
>            .
>            spin_lock(l) // CPU deadlocks
> 
> If, in the latter case, spin_lock_irq(l) were used at [1], things would have 
> been
> fine, as the interrupt wouldn't have occurred until l weren't
> released:
> 
>   CPU
>   .
>   .
>   spin_lock_irq(l)                        //takes l
>   .
>   . < Interrupt!
>   .                   -                   //IRQs are disabled
>   .                   -                   //IRQs are disabled
>   .                   -                   //IRQs are disabled
>   spin_unlock_irq(l)  .                   //IRQs re-hanbled
>                       spin_lock_irq(l);   //takes l
>                       .
>                       .
>                       spin_unlock_irq(l);
>  . <- .
>  .
> 
> Note that whether spin_lock_irq() or spin_lock_irqsave() should be used, is
> completely independent from this, and it must be decided according to whether
> IRQs are disabled already or not when taking the lock. And (quite obviously, 
> but
> since wre're here) it is fine to mix
> spin_lock_irq() and spin_lock_irqsave(), as they both disable interrupts, 
> which is
> what matters.
> 
> So, now, if we know for sure that a lock is _never_ever_ever_ taken from
> interrupt context, can we mix spin_lock() and spin_lock_irq() on it (for 
> whatever
> reason)? Well, as far as the above reasoning is concerned, yes.
> 
I appreciate Dario's explanation.
btw, be careful of spin_lock_irq(), which includes 
'ASSERT(local_irq_is_enabled()'..

> In fact, the deadlock arises because IRQs interrupt asynchronously what the
> CPU is doing, and that can happen when the CPU has taken the lock already. But
> if the 'asynchronous' part goes away, we really don't care whether a lock is 
> take
> at time t1 with IRQ enabled, and at time t2 with IRQ disabled, don't you 
> think?
> 

Yes.
Consistency may be helpful to avoid some easy-to-avoid lock errors.
Moreover, without my fix, I think it would not lead dead lock, as the 
pcidevs_lock is not being taken
In IRQ context. Right? 


For deadlock, I think the key problems are:
  - A lock can be acquired from IRQ context
  -The interrupt is delivered to the _same_CPU_ that already holds the lock.

Quan

> Well, here it is where what the comment inside check_lock() describes comes
> into play. As quoted by Qaun already:
> 
> >  2). Comment inside check_lock(),
> > we partition locks into IRQ-safe (always held with IRQs disabled) and
> > IRQ-unsafe (always held with IRQs enabled) types. The convention for
> > every lock must be consistently observed else we can deadlock in
> > 

Re: [Xen-devel] [PATCH 0/6] Support calling functions on dedicated physical cpu

[Pali Rohár]

On Friday 11 March 2016 13:25:14 Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 12:59:28PM +0100, Juergen Gross wrote:
> > Some hardware (e.g. Dell Studio laptops) require special functions to
> > be called on physical cpu 0 in order to avoid occasional hangs. When
> > running as dom0 under Xen this could be achieved only via special boot
> > parameters (vcpu pinning) limiting the hypervisor in it's scheduling
> > decisions.
> 
> So instead of telling Dell to get their act together and fix their damn
> firmware, we're going to add the most horrid gunk to the kernel? How
> does that make sense?

Hi Peter! That problem is for old laptops and I doubt that Dell would
fix and distribute patches for 5-15 years old laptops...

-- 
Pali Rohár
pali.ro...@gmail.com

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

Re: [Xen-devel] [GRUB2 PATCH v3 0/4] multiboot2: Add two extensions

[Vladimir 'phcoder' Serbinenko]

On Wednesday, March 9, 2016, Daniel Kiper  wrote:

> On Wed, Mar 02, 2016 at 05:51:36PM +0100, Daniel Kiper wrote:
> > Hi,
> >
> > This patch series:
> >   - enables EFI boot services usage in loaded images
> > by multiboot2 protocol,
> >   - add support for multiboot2 protocol compatible
> > relocatable images.
> >
> > Earlier versions of this patch series are extensively tested
> > and used internally at least in Oracle. It should be mentioned
> > that this release does not change any functionality introduced
> > by earlier releases. It just takes into account comments posted
> > by various people.
> >
> > Hmmm... Ugh... Cough... Is it possible to get this stuff
> > into 2.02 train?
>
> Andrei, Vladimir, ping?
>
They look reasonable for 2.02. Strictly speaking they're features but code
is well isolated and the alternative is painful. I answered the individual
mails with review. Is there a followup with updating multiboot2 docs?

>
> Daniel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/6] Support calling functions on dedicated physical cpu

[Peter Zijlstra]

On Fri, Mar 11, 2016 at 12:59:28PM +0100, Juergen Gross wrote:
> Some hardware (e.g. Dell Studio laptops) require special functions to
> be called on physical cpu 0 in order to avoid occasional hangs. When
> running as dom0 under Xen this could be achieved only via special boot
> parameters (vcpu pinning) limiting the hypervisor in it's scheduling
> decisions.

So instead of telling Dell to get their act together and fix their damn
firmware, we're going to add the most horrid gunk to the kernel? How
does that make sense?

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

Re: [Xen-devel] [PATCH 2/6] sched: add function to execute a function synchronously on a physical cpu

[Peter Zijlstra]

On Fri, Mar 11, 2016 at 12:59:30PM +0100, Juergen Gross wrote:
> +int call_sync_on_phys_cpu(unsigned cpu, int (*func)(void *), void *par)
> +{
> + cpumask_var_t old_mask;
> + int ret;
> +
> + if (cpu >= nr_cpu_ids)
> + return -EINVAL;
> +
> + if (!alloc_cpumask_var(_mask, GFP_KERNEL))
> + return -ENOMEM;
> +
> + cpumask_copy(old_mask, >cpus_allowed);
> + ret = set_cpus_allowed_ptr(current, cpumask_of(cpu));
> + if (ret)
> + goto out;

So what happens if someone does sched_setaffinity() right about here?

> +
> + ret = func(par);
> +
> + set_cpus_allowed_ptr(current, old_mask);
> +
> +out:
> + free_cpumask_var(old_mask);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(call_sync_on_phys_cpu);

This is disgusting, and you're adding this to !Xen kernels too.

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

Re: [Xen-devel] Request to revert superpage adjustments

[Jan Beulich]

>>> On 11.03.16 at 10:22,  wrote:
> Sadly, c/s cf393624 "x86: use 2M superpages for text/data/bss mappings"
> exposes a bug in all Syslinux variants, including ISOlinux and
> PXELinux,  causing a failure to boot.
> 
> Xen currently requires its bootloader to decompress it, and place it at
> the 1MB physical boundary.  The alignment adjustments changed the size
> of the decompressed (post mkelf32) image from 2.2MB to 7.1MB.  These
> restrictions should be fixed independently of this exposed bug.  The
> physical range between 0x10 and 0x10fffe is prime clobbering space
> for buggy BIOSes once the A20 line has been disabled (see c/s 1ed76797),
> and if any reserved memory exists between 1MB and 1MB+sizeof(xen), the
> bootloader wont be able to place Xen at its linked address.
> 
> Grub and iPXE work perfectly well when booting Xen, which is why this is
> now clearly a Syslinux issue (all versions I cared to test, including
> 4.x and 6.3 are broken).  However, it clobbers any ability for XenServer
> to do testing, as we PXEBoot our servers for install.  I expect a lot of
> other people will encounter issues once the 4.7 RCs get tested.
> 
> Please revert c/s cf393624 and the following change (c/s 53aa3dde) which
> depends upon the former, until I can work around the existing
> restrictions.  After the restrictions are resolved, the patches can go
> back in, but I am fairly sure I will not have time to resolve the issues
> in the 4.7 timeframe.

I'm kind of hesitant to do a wholesale revert, for two reasons:

1) The change would still be useful for xen.efi, which is relocatable
already anyway.

2) I cannot currently see how you mean to address the issue:
Even if you made our binary decompress itself, that would only
paper over the issue, and (based on your description) only until
even the compressed image exceeds a certain size. Nor would
that deal with avoiding reserved regions not too far above 1Mb,
since at best the main payload can be relocatable (but certainly
not the binary seen by the boot loader, as at least multiboot1
doesn't support anything like that).

Jan


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

[Xen-devel] [xen-4.4-testing test] 85888: regressions - FAIL

[osstest service owner]

flight 85888 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85888/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 85031

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 85031
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 85031
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 85031

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  0ae1e719118d8aa6754b19fb388038632fa768b3
baseline version:
 xen  83c5e46c5d6af7adc4bc46cf41e415e34846c719

Last test of basis85031  2016-03-02 06:38:02 Z9 days
Testing same since85888  2016-03-10 07:45:07 Z1 days1 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   

[Xen-devel] [PATCH 0/6] Support calling functions on dedicated physical cpu

[Juergen Gross]

Some hardware (e.g. Dell Studio laptops) require special functions to
be called on physical cpu 0 in order to avoid occasional hangs. When
running as dom0 under Xen this could be achieved only via special boot
parameters (vcpu pinning) limiting the hypervisor in it's scheduling
decisions.

This patch series is adding a generic function to be able to temporarily
pin a (virtual) cpu to a dedicated physical cpu for executing above
mentioned functions on that specific cpu. The drivers (dcdbas and i8k)
requiring this functionality are modified accordingly.

Juergen Gross (6):
  xen: sync xen header
  sched: add function to execute a function synchronously on a physical
cpu
  dcdbas: make use of call_sync_on_phys_cpu()
  hwmon: use call_sync_on_phys_cpu() for dell-smm i8k
  virt, sched: add cpu pinning to call_sync_on_phys_cpu()
  xen: add xen_pin_vcpu() to support calling functions on a dedicated
pcpu

 arch/x86/include/asm/hypervisor.h |   9 
 arch/x86/xen/enlighten.c  |  40 +++
 drivers/firmware/dcdbas.c |  46 --
 drivers/hwmon/dell-smm-hwmon.c|  27 +-
 include/linux/sched.h |  31 
 include/xen/interface/sched.h | 100 +++---
 kernel/sched/core.c   |  30 
 7 files changed, 224 insertions(+), 59 deletions(-)

-- 
2.6.2


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