Re: [Xen-devel] [PATCH for 4.7] pvusb: add missing definition to usbif.h

[Juergen Gross]

On 05/05/16 11:22, Wei Liu wrote:
> On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote:
>> On 05/05/16 11:02, Wei Liu wrote:
>>> On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote:
 The pvusb request structure contains the transfer_flags member which
 is missing definitions of it's semantics.

 Add the definition of the USBIF_SHORT_NOT_OK flag.

 Signed-off-by: Juergen Gross 
 ---
 Please consider taking this patch for 4.7 release. I believe this is the
 last bit missing for support of qemu based pvusb backend. The risk of the
 patch should be zero, as no Xen component is using this header.
 ---
  xen/include/public/io/usbif.h | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/xen/include/public/io/usbif.h b/xen/include/public/io/usbif.h
 index 9ef0cdc..4053c24 100644
 --- a/xen/include/public/io/usbif.h
 +++ b/xen/include/public/io/usbif.h
 @@ -187,6 +187,7 @@ struct usbif_urb_request {
/* basic urb parameter */
uint32_t pipe;
uint16_t transfer_flags;
 +#define USBIF_SHORT_NOT_OK0x0001
>>>
>>> Where does this come from? Should it be surrounded by define guard?
>>
>> I just wasn't defined up to now (to be precise: transfer_flags was just
>> copied from the related URB struct member in the frontend, so the
>> interface was based on some Linux kernel internals, and the qemu backend
>> used a literal "1" for testing the flag).
>>
>>> #ifndef USBIF_SHORT_NOT_OK
>>> #define USBIF_SHORT_NOT_OK 0x0001
>>> #endif
>>>
>>> Why does it need to be in our public header? If we end up taking this
>>> I think it should at least start with XEN_ prefix.
>>
>> This is just a part of the pvusb interface. So it should be defined in
>> the appropriate header file.
>>
> 
> OK. I get it now.
> 
>> Regarding prefix: I can do this, but in this case I'd prefer to add the
>> prefix to all definitions in the header. As there are currently no
>> in-tree users of this header, the risk would still be zero. :-)
>>
>> Thoughts?
>>
> 
> Actually not all public #define are prefixed by XEN_ (netif.h does,
> blkif.h doesn't) so I won't insists on this. But I still using XEN_
> prefix is better.

Sure. But I think it should be consistent at header file level. So in
my opinion the question is: should I change all definitions in usbif.h
to use the XEN_ prefix or should I add the new definition without
prefix?


Juergen

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/2] xen: add pvUSB backend

[Juergen Gross]

On 05/05/16 12:13, Anthony PERARD wrote:
> On Wed, May 04, 2016 at 10:25:03AM +0200, Juergen Gross wrote:
>> On 03/05/16 17:06, Anthony PERARD wrote:
>>> On Thu, Mar 10, 2016 at 04:19:30PM +0100, Juergen Gross wrote:
 +static void usbback_bh(void *opaque)
 +{
 +struct usbback_info *usbif;
 +struct usbif_urb_back_ring *urb_ring;
 +struct usbback_req *usbback_req;
 +RING_IDX rc, rp;
 +unsigned int more_to_do;
 +
 +usbif = opaque;
 +if (usbif->ring_error) {
 +return;
 +}
 +
 +urb_ring = >urb_ring;
 +rc = urb_ring->req_cons;
 +rp = urb_ring->sring->req_prod;
>>>
>>> Maybe use atomic_read() here to avoid req_prod been read more than once.
>>
>> Hmm. This isn't done in the other backends.
>>
>> TBH: what would happen if req_prod would be read multiple times? In the
>> worst case we would see a new request from the guest which we would have
>> missed without the atomic_read().
> 
> If the guest is misbehaving, it maybe could provoke QEMU to handle more
> request. I'm not sure.

I don't think this would add any risk to dom0. A misbehaving guest
writing arbitrary values to ->req_prod could influence qemu activity
in just the same way regardless whether atomic_read() is used on qemu
side or not. The only difference would be that with atomic_read() the
additional qemu activity would be delayed until the next invocation
of the function.

> For this use of atomic_read, I'm mostly refering to XSA-155[1] and a
> conversation[2].

The main problem with XSA-155 was modification of the request's contents
by the guest after verification by the backend happened. This is not
related to reading the producer's ring index.

I should use RING_COPY_REQUEST(), however.


Juergen

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

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  149 days
Failing since 65593  2015-12-08 23:44:51 Z  149 days  220 attempts
Testing same since93585  2016-05-06 03:33:16 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Sunny Wang 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 

[Xen-devel] [xen-unstable test] 93563: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt   3 host-install(3)  broken in 93538 pass in 93563
 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 93538 pass in 
93563
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
in 93538 pass in 93563
 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 93538 pass in 
93563
 test-armhf-armhf-libvirt  4 host-ping-check-native fail in 93538 pass in 93563
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 
93538
 test-armhf-armhf-xl-arndale   6 xen-bootfail pass in 93538

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 93515
 build-amd64-rumpuserxen   6 xen-buildfail   like 93515
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93515
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93515
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93515
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93515
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 93515
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 93515

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-arndale  12 migrate-support-check fail in 93538 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 93538 never 
pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f8d4c1d5c59eb328480957ff6f1bccaf113b4921
baseline version:
 xen  adf7d04317b4c4e60db42314ad874a45d80e65b9

Last test of basis93515  2016-05-05 03:30:10 Z1 days
Testing same since93538  2016-05-05 13:13:31 Z0 days2 attempts


People who touched revisions under test:
  Paul Lai 
  Wei Liu 

jobs:
 build-amd64-xsm  

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 44a7d08b5a935347a35507fb5db42659a96b3452
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  149 days
Failing since 65593  2015-12-08 23:44:51 Z  149 days  219 attempts
Testing same since93576  2016-05-06 01:43:15 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Sunny Wang 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 

Re: [Xen-devel] [PATCH v3 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

[Xu, Quan]

On May 05, 2016 7:03 PM, George Dunlap  wrote:
> On 05/05/16 07:53, Xu, Quan wrote:
> > On May 04, 2016 9:49 PM, George Dunlap 
> wrote:
> >> On Fri, Apr 29, 2016 at 10:25 AM, Quan Xu  wrote:
> >>> When IOMMU mapping is failed, we issue a best effort rollback,
> >>> stopping IOMMU mapping, unmapping the previous IOMMU maps and
> >> then
> >>> reporting the error up to the call trees. When rollback is not
> >>> feasible (in early initialization phase or trade-off of complexity)
> >>> for the hardware domain, we do things on a best effort basis, only
> >>> throwing
> >> out an error message.
> >>>
> >>> IOMMU unmapping should perhaps continue despite an error, in an
> >>> attempt to do best effort cleanup.
> >>>
> >>> Signed-off-by: Quan Xu 
> >>>
> >>> CC: Keir Fraser 
> >>> CC: Jan Beulich 
> >>> CC: Andrew Cooper 
> >>> CC: Jun Nakajima 
> >>> CC: Kevin Tian 
> >>> CC: George Dunlap 
> >>> ---
> >>>  xen/arch/x86/mm.c   | 13 -
> >>>  xen/arch/x86/mm/p2m-ept.c   | 27 +--
> >>>  xen/arch/x86/mm/p2m-pt.c| 24 
> >>>  xen/arch/x86/mm/p2m.c   | 11 +--
> >>>  xen/drivers/passthrough/iommu.c | 14 +-
> >>>  5 files changed, 75 insertions(+), 14 deletions(-)
> >>>
> >>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index
> >>> a42097f..427097d 100644
> >>> --- a/xen/arch/x86/mm.c
> >>> +++ b/xen/arch/x86/mm.c
> >>> @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info
> >> *page, unsigned long type,
> >>> int preemptible)  {
> >>>  unsigned long nx, x, y = page->u.inuse.type_info;
> >>> -int rc = 0;
> >>> +int rc = 0, ret = 0;
> >>>
> >>>  ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
> >>>
> >>> @@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info
> >> *page, unsigned long type,
> >>>  if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
> >>>  {
> >>>  if ( (x & PGT_type_mask) == PGT_writable_page )
> >>> -iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
> >>> +ret = iommu_unmap_page(d, mfn_to_gmfn(d,
> >> page_to_mfn(page)));
> >>>  else if ( type == PGT_writable_page )
> >>> -iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
> >>> -   page_to_mfn(page),
> >>> -   IOMMUF_readable|IOMMUF_writable);
> >>> +ret = iommu_map_page(d, mfn_to_gmfn(d,
> page_to_mfn(page)),
> >>> + page_to_mfn(page),
> >>> +
> >>> + IOMMUF_readable|IOMMUF_writable);
> >>>  }
> >>>  }
> >>>
> >>> @@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info
> >> *page, unsigned long type,
> >>>  if ( (x & PGT_partial) && !(nx & PGT_partial) )
> >>>  put_page(page);
> >>>
> >>> +if ( !rc )
> >>> +rc = ret;
> >>> +
> >>>  return rc;
> >>>  }
> >>>
> >>> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> >>> index 1ed5b47..df87944 100644
> >>> --- a/xen/arch/x86/mm/p2m-ept.c
> >>> +++ b/xen/arch/x86/mm/p2m-ept.c
> >>> @@ -821,6 +821,8 @@ out:
> >>>  if ( needs_sync )
> >>>  ept_sync_domain(p2m);
> >>>
> >>> +ret = 0;
> >>> +
> >>>  /* For host p2m, may need to change VT-d page table.*/
> >>>  if ( rc == 0 && p2m_is_hostp2m(p2m) && need_iommu(d) &&
> >>>   need_modify_vtd_table )
> >>> @@ -831,11 +833,29 @@ out:
> >>>  {
> >>>  if ( iommu_flags )
> >>>  for ( i = 0; i < (1 << order); i++ )
> >>> -iommu_map_page(d, gfn + i, mfn_x(mfn) + i, 
> >>> iommu_flags);
> >>> +{
> >>> +rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
> >>> + iommu_flags);
> >>> +
> >>> +if ( !ret && unlikely(rc) )
> >>> +{
> >>> +while ( i-- )
> >>> +iommu_unmap_page(d, gfn + i);
> >>> +
> >>> +ret = rc;
> >>> +break;
> >>> +}
> >>> +}
> >>>  else
> >>>  for ( i = 0; i < (1 << order); i++ )
> >>> -iommu_unmap_page(d, gfn + i);
> >>> +{
> >>> +rc = iommu_unmap_page(d, gfn + i);
> >>> +
> >>> +if ( !ret && unlikely(rc) )
> >>> +ret = rc;
> >>> +}
> >>>  }
> >>> +
> >>> +rc = 0;
> >>>  }
> >>
> >> So the reason for doing this thing with setting ret=0, then using rc,
> >> then setting rc to zero, is to make sure that the change is
> >> 

Re: [Xen-devel] problem about using xl create to start a domU

[Shannon Zhao]

Below is the output of xenstore-ls:

root@genericarmv8:/home# xenstore-ls -f
/tool = ""
/tool/xenstored = ""
/local = ""
/local/domain = ""
/local/domain/0 = ""
/local/domain/0/domid = "0"
/local/domain/0/name = "Domain-0"
/vm = ""
/libxl = ""

"ps -ef" prints:

root  1050 1  0 Jul10 ?00:00:00
/usr/local/sbin/xenstored --pid-file /var/run/xenstored.pid

root  1135 1  0 Jul10 ?00:00:00
/usr/local/sbin/xenconsoled --pid-file=/var/run/xenconsoled.pid


On 2016/5/5 18:36, Stefano Stabellini wrote:
> CC'ing new Julien's email address.
> 
> On Thu, 5 May 2016, Stefano Stabellini wrote:
>> It looks like something is wrong with xenstore. Is xenstored running?
>> Can you do xenstore-ls in dom0?
>>
>> On Thu, 5 May 2016, Shannon Zhao wrote:
>>> Hi,
>>>
>>> I'm going to create a domU for XEN on ARM64. I'm following [1] to cross
>>> compile the xen tools and [2] to create domU. One thing different is
>>> that I'm using Build_AEMv8A-AEMv8A fastmodel.
>>>
>>> After executing "/etc/init.d/xencommons start", xl list shows:
>>>
>>> Name   ID   Mem VCPUs  State   Time(s)
>>> Domain-0   0   256 2 r-  27.3
>>>
>>> Then I execute "losetup /dev/loop0 domU.img" and xl create domU.cfg, it
>>> prints below logs:
>>> Parsing config from domU.cfg
>>> libxl: error: libxl_device.c:1033:device_backend_callback: unable to add
>>> device with path /local/domain/0/backend/vbd/1/51712
>>> libxl: error: libxl_create.c:1252:domcreate_launch_dm: unable to add
>>> disk devices
>>> libxl: error: libxl_device.c:1033:device_backend_callback: unable to
>>> remove device with path /local/domain/0/backend/vbd/1/51712
>>> libxl: error: libxl.c:1636:devices_destroy_cb: libxl__devices_destroy
>>> failed for 1
>>> libxl: error: libxl.c:1564:libxl__destroy_domid: non-existant domain 1
>>> libxl: error: libxl.c:1523:domain_destroy_callback: unable to destroy
>>> guest with domid 1
>>> libxl: error: libxl.c:1452:domain_destroy_cb: destruction of domain 1 failed
>>>
>>> Is there anything I missed?
>>>
>>> [1]http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling
>>> [2]https://wiki.linaro.org/LEG/Engineering/Virtualization/Xen_on_ARMv8_Foundation
>>>
>>> Thanks,
>>> -- 
>>> Shannon
>>>
>>
> 
> .
> 

-- 
Shannon


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

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  149 days
Failing since 65593  2015-12-08 23:44:51 Z  149 days  218 attempts
Testing same since93530  2016-05-05 09:42:35 Z0 days5 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao 

Re: [Xen-devel] [PATCH for-4.7 1/2] init: drop GNU-isms for sleep command

[Andrew Cooper]

On 05/05/16 21:18, Doug Goldstein wrote:
> Most implementations of the sleep command only take integers. GNU
> coreutils has a GNU extension to allow any floating point number to be
> passed but we shouldn't depend on that.
>
> Signed-off-by: Doug Goldstein 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH for-4.7 2/2] init: shebang should be the first line

[Andrew Cooper]

On 05/05/16 21:18, Doug Goldstein wrote:
> The shebang was not on the first line in the init script and it should
> be.
>
> Signed-off-by: Doug Goldstein 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH for-4.7 2/2] init: shebang should be the first line

[Doug Goldstein]

The shebang was not on the first line in the init script and it should
be.

Signed-off-by: Doug Goldstein 
---
 tools/hotplug/Linux/init.d/xendriverdomain.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/hotplug/Linux/init.d/xendriverdomain.in 
b/tools/hotplug/Linux/init.d/xendriverdomain.in
index 3720dea..5fd4e9a 100644
--- a/tools/hotplug/Linux/init.d/xendriverdomain.in
+++ b/tools/hotplug/Linux/init.d/xendriverdomain.in
@@ -1,4 +1,3 @@
-
 #!/bin/bash
 #
 # xendriverdomainScript to start services needed in a Xen driver domain
-- 
2.7.3


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

[Xen-devel] [PATCH for-4.7 1/2] init: drop GNU-isms for sleep command

[Doug Goldstein]

Most implementations of the sleep command only take integers. GNU
coreutils has a GNU extension to allow any floating point number to be
passed but we shouldn't depend on that.

Signed-off-by: Doug Goldstein 
---
 tools/hotplug/Linux/block-iscsi   | 2 +-
 tools/hotplug/Linux/init.d/xencommons.in  | 4 ++--
 tools/hotplug/Linux/init.d/xendriverdomain.in | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/hotplug/Linux/block-iscsi b/tools/hotplug/Linux/block-iscsi
index 8e36852..3615905 100644
--- a/tools/hotplug/Linux/block-iscsi
+++ b/tools/hotplug/Linux/block-iscsi
@@ -74,7 +74,7 @@ find_device()
 {
 count=0
 while [ ! -e /dev/disk/by-path/*"$iqn"-lun-0 ]; do
-sleep 0.1
+sleep 1
 count=`expr $count + 1`
 if [ count = 100 ]; then
 # 10s timeout while waiting for iSCSI disk to settle
diff --git a/tools/hotplug/Linux/init.d/xencommons.in 
b/tools/hotplug/Linux/init.d/xencommons.in
index 21e9133..eeac8ab 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -107,14 +107,14 @@ do_stop () {
 echo Stopping xenconsoled
if read 2>/dev/null <$XENCONSOLED_PIDFILE pid; then
kill $pid
-   while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done
+   while kill -9 $pid >/dev/null 2>&1; do sleep 1; done
rm -f $XENCONSOLED_PIDFILE
fi
 
echo Stopping QEMU
if read 2>/dev/null <$QEMU_PIDFILE pid; then
kill $pid
-   while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done
+   while kill -9 $pid >/dev/null 2>&1; do sleep 1; done
rm -f $QEMU_PIDFILE
fi
 
diff --git a/tools/hotplug/Linux/init.d/xendriverdomain.in 
b/tools/hotplug/Linux/init.d/xendriverdomain.in
index dd5f3a3..3720dea 100644
--- a/tools/hotplug/Linux/init.d/xendriverdomain.in
+++ b/tools/hotplug/Linux/init.d/xendriverdomain.in
@@ -56,7 +56,7 @@ do_stop () {
 echo Stopping xl devd...
if read 2>/dev/null <$XLDEVD_PIDFILE pid; then
kill $pid
-   while kill -9 $pid >/dev/null 2>&1; do sleep 0.1; done
+   while kill -9 $pid >/dev/null 2>&1; do sleep 1; done
rm -f $XLDEVD_PIDFILE
fi
 }
-- 
2.7.3


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

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  149 days
Failing since 65593  2015-12-08 23:44:51 Z  148 days  217 attempts
Testing same since93530  2016-05-05 09:42:35 Z0 days4 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao 

Re: [Xen-devel] [PATCH] flask/policy: don't audit commandline / build_id queries

[Wei Liu]

On Thu, May 05, 2016 at 11:49:55AM -0500, Doug Goldstein wrote:
> From: Daniel De Graaf 
> 
> Signed-off-by: Daniel De Graaf 
> Signed-off-by: Doug Goldstein 

Reviewed-by: Wei Liu 
Release-acked-by: Wei Liu 

> ---
>  tools/flask/policy/policy/modules/xen/xen.te | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
> b/tools/flask/policy/policy/modules/xen/xen.te
> index bef33b0..0b1c955 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.te
> +++ b/tools/flask/policy/policy/modules/xen/xen.te
> @@ -155,6 +155,15 @@ allow domain_type xen_t:version {
>  xen_changeset xen_pagesize xen_guest_handle
>  };
>  
> +# These queries don't need auditing when denied.  They can be
> +# encountered in normal operation by xl or by reading sysfs files in
> +# Linux, so without this they will show up in the logs.  Since these
> +# operations return valid responses (like "denied"), hiding the denials
> +# should not break anything.
> +dontaudit domain_type xen_t:version {
> +xen_commandline xen_build_id
> +};
> +
>  
> ###
>  #
>  # Domain creation
> -- 
> 2.7.3
> 
> 
> ___
> 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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt   3 host-install(3) broken REGR. vs. 93515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 93515
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 93515
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)broken REGR. vs. 93515
 test-armhf-armhf-libvirt  4 host-ping-check-nativefail REGR. vs. 93515

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 93515
 build-amd64-rumpuserxen   6 xen-buildfail   like 93515
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93515
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93515
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93515
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 93515

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-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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-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-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-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-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  f8d4c1d5c59eb328480957ff6f1bccaf113b4921
baseline version:
 xen  adf7d04317b4c4e60db42314ad874a45d80e65b9

Last test of basis93515  2016-05-05 03:30:10 Z0 days
Testing same since93538  2016-05-05 13:13:31 Z0 days1 attempts


People who touched revisions under test:
  Paul Lai 
  Wei Liu 

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 v3 6/9] tools/xen-access: add test-case for ARM SMC

[Tamas K Lengyel]

On May 5, 2016 10:29, "Jan Beulich"  wrote:
>
>
> i.A. Jan Beulich
> Software Engineering Consultant
> Attachmate Group
> Nördlicher Zubringer 9-11
> 40470 Düsseldorf
> jbeul...@suse.com
> SUSE
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nürnberg)
>
> >>> Tamas K Lengyel  05/04/16 7:18 PM >>>
> >On May 4, 2016 09:35, "Jan Beulich"  wrote:
> >>
> >> >>> On 04.05.16 at 16:51,  wrote:
> >> > --- a/tools/tests/xen-access/xen-access.c
> >> > +++ b/tools/tests/xen-access/xen-access.c
> >> > @@ -1,4 +1,3 @@
> >> > -/*
> >> >   * xen-access.c
> >> >   *
> >> >   * Exercises the basic per-page access mechanisms
> >>
> >> Are you saying this still builds with such a change?
> >
> >It builds fine, so not sure what you mean.
>
> Perhaps the patch here isn't what you test? I can't see how a file with
the
> beginning of a comment removed can build.
>
> Jan

Yea, the typo was introduced somewhere midway in the process.. Oh well,
will resend.

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

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  149 days
Failing since 65593  2015-12-08 23:44:51 Z  148 days  216 attempts
Testing same since93530  2016-05-05 09:42:35 Z0 days3 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao 

Re: [Xen-devel] [PATCH] flask/policy: don't audit commandline / build_id queries

[Konrad Rzeszutek Wilk]

On Thu, May 05, 2016 at 11:49:55AM -0500, Doug Goldstein wrote:
> From: Daniel De Graaf 
> 
> Signed-off-by: Daniel De Graaf 
> Signed-off-by: Doug Goldstein 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  tools/flask/policy/policy/modules/xen/xen.te | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
> b/tools/flask/policy/policy/modules/xen/xen.te
> index bef33b0..0b1c955 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.te
> +++ b/tools/flask/policy/policy/modules/xen/xen.te
> @@ -155,6 +155,15 @@ allow domain_type xen_t:version {
>  xen_changeset xen_pagesize xen_guest_handle
>  };
>  
> +# These queries don't need auditing when denied.  They can be
> +# encountered in normal operation by xl or by reading sysfs files in
> +# Linux, so without this they will show up in the logs.  Since these
> +# operations return valid responses (like "denied"), hiding the denials
> +# should not break anything.
> +dontaudit domain_type xen_t:version {
> +xen_commandline xen_build_id
> +};
> +
>  
> ###
>  #
>  # Domain creation
> -- 
> 2.7.3
> 
> 
> ___
> 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

[Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

[Lars Kurth]

Hi everyone,

I updated http://wiki.xenproject.org/wiki/Xen_Project_Test_Days and created 
http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions (note that we only 
have one page for all RC's now to avoid unnecessary copy and pasting).

For those who want new features to be tested, please expect to 
a) Explain what to test (a very short description of the feature)
b) Add some instructions on how to test (e.g. some command line instructions)

You can add a new headline (an example is marked with TODO) to either
- 
http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_ARM_Test_Instructions
- 
http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Specific_x86_Test_Instructions
- OR 
http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RC_specific_things_to_test
 (under a specific RC heading)

I will start promoting Test Days from early next week (on the blog, but also on 
the mailing lists). The more specific test instructions for Xen 4.7 related 
features, the better the coverage will be and the more likely people are to 
actually test.

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

[Xen-devel] [PATCH] flask/policy: don't audit commandline / build_id queries

[Doug Goldstein]

From: Daniel De Graaf 

Signed-off-by: Daniel De Graaf 
Signed-off-by: Doug Goldstein 
---
 tools/flask/policy/policy/modules/xen/xen.te | 9 +
 1 file changed, 9 insertions(+)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index bef33b0..0b1c955 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -155,6 +155,15 @@ allow domain_type xen_t:version {
 xen_changeset xen_pagesize xen_guest_handle
 };
 
+# These queries don't need auditing when denied.  They can be
+# encountered in normal operation by xl or by reading sysfs files in
+# Linux, so without this they will show up in the logs.  Since these
+# operations return valid responses (like "denied"), hiding the denials
+# should not break anything.
+dontaudit domain_type xen_t:version {
+xen_commandline xen_build_id
+};
+
 ###
 #
 # Domain creation
-- 
2.7.3


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

Re: [Xen-devel] [RFC 00/16] xen/arm: Introduce alternative runtime patching for ARM64

[Julien Grall]

On 05/05/16 17:34, Julien Grall wrote:
> Hello,
> 
> Some of the processor erratum will require to modify code sequence. As those
> modifications may impact the performance, they should only be enabled on
> affected cores. Furthermore, Xen may also want to take advantage of new
> hardware features coming up with v8.1 and v8.2.
> 
> The first part of the series adds the alternative infrastructure, most of the
> code is based on Linux v4.6-rc3. The rest of the series implements errata
> for Cortex-A57 and Cortex-A53.

I forgot to mention that I have pushed a branch with the series on
xenbits:

git://xenbits.xen.org/people/julieng/xen-unstable.git branch alternative-rfc

> Yours sincerely,
> 
> Julien Grall (16):
>xen/arm: Makefile: Sort the entries alphabetically
>xen/arm: Include the header asm-arm/system.h in asm-arm/page.h
>xen/arm: Add macros to handle the MIDR
>xen/arm: arm64: Import flush_icache_range from Linux v4.6-rc3
>xen/arm: Add cpu_hwcap bitmap
>xen/arm64: Add an helper to invalidate all instruction caches
>xen/arm: arm64: Move the define BRK_BUG_FRAME into a separate header
>xen/arm: arm64: Reserve a brk immediate to fault on purpose
>xen/arm: arm64: Add helpers to decode and encode branch instructions
>xen/arm: Introduce alternative runtime patching
>xen/arm: Detect silicon revision and set cap bits accordingly
>xen/arm: Document the errata implemented in Xen
>xen/arm: arm64: Add Cortex-A53 cache errata workaround
>xen/arm: arm64: Add cortex-A57 erratum 832075 workaround
>xen/arm: traps: Don't inject a fault if the translation VA -> IPA
>  fails
>xen/arm: arm64: Document Cortex-A57 erratum 834220
> 
>   docs/misc/arm/silicon-errata.txt  |  50 +
>   xen/arch/arm/Kconfig  |  96 +
>   xen/arch/arm/Makefile |  41 +++
>   xen/arch/arm/alternative.c| 217 
> ++
>   xen/arch/arm/arm32/Makefile   |   9 +-
>   xen/arch/arm/arm64/Makefile   |  13 ++-
>   xen/arch/arm/arm64/cache.S|  51 +
>   xen/arch/arm/arm64/insn.c | 213 
> +
>   xen/arch/arm/cpuerrata.c  |  52 +
>   xen/arch/arm/cpufeature.c |  50 +
>   xen/arch/arm/platforms/Makefile   |   2 +-
>   xen/arch/arm/setup.c  |  11 ++
>   xen/arch/arm/smpboot.c|   3 +
>   xen/arch/arm/traps.c  |  37 ++-
>   xen/arch/arm/xen.lds.S|   7 ++
>   xen/include/asm-arm/alternative.h | 165 +
>   xen/include/asm-arm/arm64/brk.h   |  39 +++
>   xen/include/asm-arm/arm64/bug.h   |   5 +-
>   xen/include/asm-arm/arm64/insn.h  |  88 
>   xen/include/asm-arm/arm64/io.h|  21 +++-
>   xen/include/asm-arm/arm64/page.h  |  13 ++-
>   xen/include/asm-arm/cpuerrata.h   |   6 ++
>   xen/include/asm-arm/cpufeature.h  |  47 +
>   xen/include/asm-arm/insn.h|  22 
>   xen/include/asm-arm/page.h|   3 +
>   xen/include/asm-arm/processor.h   |  43 +++-
>   26 files changed, 1260 insertions(+), 44 deletions(-)
>   create mode 100644 docs/misc/arm/silicon-errata.txt
>   create mode 100644 xen/arch/arm/alternative.c
>   create mode 100644 xen/arch/arm/arm64/insn.c
>   create mode 100644 xen/arch/arm/cpuerrata.c
>   create mode 100644 xen/arch/arm/cpufeature.c
>   create mode 100644 xen/include/asm-arm/alternative.h
>   create mode 100644 xen/include/asm-arm/arm64/brk.h
>   create mode 100644 xen/include/asm-arm/arm64/insn.h
>   create mode 100644 xen/include/asm-arm/cpuerrata.h
>   create mode 100644 xen/include/asm-arm/insn.h
> 

-- 
Julien Grall

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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Jan Beulich]

>>> Razvan Cojocaru  05/05/16 11:24 AM >>>
>On 05/04/2016 04:42 PM, Jan Beulich wrote:
> On 04.05.16 at 13:32,  wrote:
>>> But while implementing a stub that falls back to the actual LOCK CMPXCHG
>>> and replacing hvm_copy_to_guest_virt() with it would indeed be an
>>> improvement (with the added advantage of being able to treat
>>> non-emulated LOCK CMPXCHG cases), I don't understand how that would
>>> solve the read-modify-write atomicity problem.
>>>
>>> AFAICT, this would only solve the write problem. Assuming we have VCPU1
>>> and VCPU2 emulating a LOCKed instruction expecting rmw atomicity, the
>>> stub alone would not prevent this:
>>>
>>> VCPU1: read, modify
>>> VCPU2: read, modify, write
>>> VCPU1: write
>> 
>> I'm not sure I follow what you mean here: Does the above represent
>> what the guest does, or what the hypervisor does as steps to emulate
>> a _single_ guest instruction? In the former case, I don't see what
>> you're after. And in the latter case I don't understand why you think
>> using CMPXCHG instead of WRITE wouldn't help.
>
>Briefly, this is the scenario: assuming a guest with two VCPUs and an
>introspection application that has restricted access to a page, the
>guest runs two LOCK instructions that touch the page, causing a page
>fault for each instruction. This further translates to two EPT fault
>vm_events being placed in the ring buffer.
>
>By the time the introspection application polls the event channel, both
>VCPUs are paused, waiting for replies to the vm_events.
>
>If the monitoring application processes both events (puts both replies,
>with the emulate option on, in the ring buffer), then signals the event
>channel, it is possible that both VCPUs get woken up, ending up running
>x86_emulate() simultaneously.
>
>In this case, my understanding is that just using CMPXCHG will not work
>(although it is clearly superior to the current implementation), because
>the read part and the write part of x86_emulate() (when LOCKed
>instructions are involved) should be executed atomically, but writing
>the CMPXCHG stub would only make sure that two simultaneous writes won't
>occur.
>
>In other words, this would still be possible (atomicity would still not
>be guaranteed for LOCKed instructions):
>
>VCPU1: read
>VCPU2: read, write
>VCPU1: write
>
>when what we want for LOCKed instructions is:
>
>VCPU1: read, write
>VCPU2: read, write

Okay, in short I take this to mean "single instruction" as answer to my actual
question.

>Am I misunderstanding how x86_emulate() works?

No, but I suppose you're misunderstanding what I'm trying to suggest. What you
write above is not what will result when using CMPXCHG. Instead what we'll have
is

vCPU1: read
vCPU2: read
vCPU2: cmpxchg
vCPU1: cmpxchg

Note that the second cmpxchg will fail unless the first one wrote back an
unchanged value. Hence vCPU1 will be told to re-execute the instruction.

Jan


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

Re: [Xen-devel] [PATCH v2 for-4.7 5/6] xen/xsplice: add ELFOSABI_FREEBSD as a supported OSABI for payloads

[Roger Pau Monne]

On Wed, May 04, 2016 at 04:34:26AM -0600, Jan Beulich wrote:
> >>> On 04.05.16 at 11:48,  wrote:
> > On Tue, May 03, 2016 at 08:17:15AM -0600, Jan Beulich wrote:
> >> >>> On 03.05.16 at 12:55,  wrote:
> >> > The calling convention used by the FreeBSD ELF OSABI is exactly the same 
> >> > as
> >> > the the one defined by System V, so payloads with a FreeBSD OSABI should 
> >> > be
> >> > accepted by the xsplice machinery.
> >> 
> >> Well, you realize that the ABI is more than just the calling convention?
> >> I.e. your patch basically says ELFOSABI_NONE == ELFOSABI_FREEBSD,
> >> in which case I wonder why the latter exists in the first place. Is there
> >> a proper document somewhere describing everything the latter implies,
> >> so that one can check whether for xSplice purposes such similar
> >> treatment is indeed okay? Until then I'm afraid I'm opposed to this going
> >> in.
> > 
> > The FreeBSD elf OSABI only has a meaning for userspace applications, it's 
> > used by FreeBSD in order to detect if an application is native or if it 
> > needs to be run in the linuxator (the Linux emulator, or any other emulator 
> > that is available and matches the ELF OSABI specified in the binary FWIW).
> > 
> > THe only difference from SYSV to FreeBSD OSABI is the sysentvec that's 
> > selected inside of the FreeBSD kernel (the ABI between the kernel and the 
> > user-space application), but of course this doesn't apply to kernel code, 
> > which is what Xen and the xsplice payloads are. Sadly this is not written 
> > anywhere.
> 
> Well, okay, in that case I agree the patch should be fine.

Would you like me to resend this with a more expanded commit message, or are 
you going to squash my explanation in the commit message?

Thanks, Roger.

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

[Xen-devel] [RFC 10/16] xen/arm: Introduce alternative runtime patching

[Julien Grall]

Some of the processor erratum will require to modify code sequence.
As those modifications may impact the performance, they should only
be enabled on affected cores. Furthermore, Xen may also want to take
advantage of new hardware features coming up with v8.1 and v8.2.

This patch adds an infrastructure to patch Xen during boot time
depending on the "features" available on the platform.

This code is based on the file arch/arm64/kernel/alternative.c in
Linux 4.6-rc3. Any references to arm64 have been dropped to make the
code as generic as possible.

Furthermore, in Xen the executable sections (.text and .init.text)
are always mapped read-only and enforced by SCTLR.WNX. So it is not
possible to directly patch Xen.

To by-pass this restriction, a temporary writeable mapping is made with
vmap. This mapping will be used to write the new instructions.

Lastly, runtime patching is currently not necessary for ARM32. So the
code is only enabled for ARM64.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/Kconfig  |   5 +
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/alternative.c| 217 ++
 xen/arch/arm/setup.c  |   8 ++
 xen/arch/arm/xen.lds.S|   7 ++
 xen/include/asm-arm/alternative.h | 165 +
 xen/include/asm-arm/arm64/insn.h  |  16 +++
 7 files changed, 419 insertions(+)
 create mode 100644 xen/arch/arm/alternative.c
 create mode 100644 xen/include/asm-arm/alternative.h

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 6231cd5..9b3e66b 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM_64
def_bool y
depends on 64BIT
select HAS_GICV3
+select ALTERNATIVE
 
 config ARM
def_bool y
@@ -46,6 +47,10 @@ config ACPI
 config HAS_GICV3
bool
 
+# Select ALTERNATIVE if the architecture supports runtime patching
+config ALTERNATIVE
+bool
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 9122f78..2d330aa 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -4,6 +4,7 @@ subdir-y += platforms
 subdir-$(CONFIG_ARM_64) += efi
 subdir-$(CONFIG_ACPI) += acpi
 
+obj-$(CONFIG_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.o
 obj-y += cpu.o
 obj-y += cpufeature.o
diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
new file mode 100644
index 000..0a5d1c8
--- /dev/null
+++ b/xen/arch/arm/alternative.c
@@ -0,0 +1,217 @@
+/*
+ * alternative runtime patching
+ * inspired by the x86 version
+ *
+ * Copyright (C) 2014 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define __ALT_PTR(a,f)  (u32 *)((void *)&(a)->f + (a)->f)
+#define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
+#define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
+
+extern const struct alt_instr __alt_instructions[], __alt_instructions_end[];
+
+struct alt_region {
+const struct alt_instr *begin;
+const struct alt_instr *end;
+};
+
+/*
+ * Check if the target PC is within an alternative block.
+ */
+static bool_t branch_insn_requires_update(const struct alt_instr *alt,
+  unsigned long pc)
+{
+unsigned long replptr;
+
+if ( is_active_kernel_text(pc) )
+return 1;
+
+replptr = (unsigned long)ALT_REPL_PTR(alt);
+if ( pc >= replptr && pc <= (replptr + alt->alt_len) )
+return 0;
+
+/*
+ * Branching into *another* alternate sequence is doomed, and
+ * we're not even trying to fix it up.
+ */
+BUG();
+}
+
+static u32 get_alt_insn(const struct alt_instr *alt,
+const u32 *insnptr, const u32 *altinsnptr)
+{
+u32 insn;
+
+insn = le32_to_cpu(*altinsnptr);
+
+if ( insn_is_branch_imm(insn) )
+{
+s32 offset = insn_get_branch_offset(insn);
+unsigned long target;
+
+target = (unsigned long)altinsnptr + offset;
+
+/*
+ * If we're branching inside the alternate sequence,
+ * do not rewrite the instruction, as it is already
+ * correct. Otherwise, generate the new instruction.
+ */
+if ( branch_insn_requires_update(alt, target) )
+{
+

[Xen-devel] [RFC 07/16] xen/arm: arm64: Move the define BRK_BUG_FRAME into a separate header

[Julien Grall]

New immediates will be defined in the future. To keep track of the
immediates allocated, gather all of them in a separate header.

Also rename BRK_BUG_FRAME to BKR_BUG_FRAME_IMM.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/traps.c|  2 +-
 xen/include/asm-arm/arm64/brk.h | 26 ++
 xen/include/asm-arm/arm64/bug.h |  5 ++---
 3 files changed, 29 insertions(+), 4 deletions(-)
 create mode 100644 xen/include/asm-arm/arm64/brk.h

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1828ea1..c0325d5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1205,7 +1205,7 @@ static void do_trap_brk(struct cpu_user_regs *regs, const 
union hsr hsr)
 
 switch (hsr.brk.comment)
 {
-case BRK_BUG_FRAME:
+case BRK_BUG_FRAME_IMM:
 if ( do_bug_frame(regs, regs->pc) )
 goto die;
 
diff --git a/xen/include/asm-arm/arm64/brk.h b/xen/include/asm-arm/arm64/brk.h
new file mode 100644
index 000..7867b07
--- /dev/null
+++ b/xen/include/asm-arm/arm64/brk.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_ARM_ARM64_BRK
+#define __ASM_ARM_ARM64_BRK
+
+/*
+ * #imm16 values used for BRK instruction generation
+ * 0x001: xen-mode BUG() and WARN() traps
+ */
+#define BRK_BUG_FRAME_IMM   1
+
+#endif /* !__ASM_ARM_ARM64_BRK */
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/arm64/bug.h b/xen/include/asm-arm/arm64/bug.h
index 42b0e4f..59f664d 100644
--- a/xen/include/asm-arm/arm64/bug.h
+++ b/xen/include/asm-arm/arm64/bug.h
@@ -2,9 +2,8 @@
 #define __ARM_ARM64_BUG_H__
 
 #include 
+#include 
 
-#define BRK_BUG_FRAME 1
-
-#define BUG_INSTR "brk " __stringify(BRK_BUG_FRAME)
+#define BUG_INSTR "brk " __stringify(BRK_BUG_FRAME_IMM)
 
 #endif /* __ARM_ARM64_BUG_H__ */
-- 
1.9.1


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

[Xen-devel] [RFC 09/16] xen/arm: arm64: Add helpers to decode and encode branch instructions

[Julien Grall]

We may need to update branch instruction when patching Xen.

The code has been imported from the files arch/arm64/kernel/insn.c
and arch/arm64/include/asm/insn.h in Linux v4.6-rc3.

Note that only the necessary helpers have been imported.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/arm64/Makefile  |   1 +
 xen/arch/arm/arm64/insn.c| 213 +++
 xen/include/asm-arm/arm64/insn.h |  72 +
 xen/include/asm-arm/insn.h   |  22 
 4 files changed, 308 insertions(+)
 create mode 100644 xen/arch/arm/arm64/insn.c
 create mode 100644 xen/include/asm-arm/arm64/insn.h
 create mode 100644 xen/include/asm-arm/insn.h

diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index 39c6ac6..c1fa43f 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -5,6 +5,7 @@ obj-$(EARLY_PRINTK) += debug.o
 obj-y += domctl.o
 obj-y += domain.o
 obj-y += entry.o
+obj-y += insn.o
 obj-y += smpboot.o
 obj-y += traps.o
 obj-y += vfp.o
diff --git a/xen/arch/arm/arm64/insn.c b/xen/arch/arm/arm64/insn.c
new file mode 100644
index 000..54a6b62
--- /dev/null
+++ b/xen/arch/arm/arm64/insn.c
@@ -0,0 +1,213 @@
+/*
+ * Based on Linux arch/arm64/kernel/insn.c
+ *
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu 
+ *
+ * Copyright (C) 2014-2016 Zi Shen Lim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+bool aarch64_insn_is_branch_imm(u32 insn)
+{
+   return (aarch64_insn_is_b(insn) || aarch64_insn_is_bl(insn) ||
+   aarch64_insn_is_tbz(insn) || aarch64_insn_is_tbnz(insn) ||
+   aarch64_insn_is_cbz(insn) || aarch64_insn_is_cbnz(insn) ||
+   aarch64_insn_is_bcond(insn));
+}
+
+static int aarch64_get_imm_shift_mask(enum aarch64_insn_imm_type type,
+   u32 *maskp, int *shiftp)
+{
+   u32 mask;
+   int shift;
+
+   switch (type) {
+   case AARCH64_INSN_IMM_26:
+   mask = BIT(26) - 1;
+   shift = 0;
+   break;
+   case AARCH64_INSN_IMM_19:
+   mask = BIT(19) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_16:
+   mask = BIT(16) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_14:
+   mask = BIT(14) - 1;
+   shift = 5;
+   break;
+   case AARCH64_INSN_IMM_12:
+   mask = BIT(12) - 1;
+   shift = 10;
+   break;
+   case AARCH64_INSN_IMM_9:
+   mask = BIT(9) - 1;
+   shift = 12;
+   break;
+   case AARCH64_INSN_IMM_7:
+   mask = BIT(7) - 1;
+   shift = 15;
+   break;
+   case AARCH64_INSN_IMM_6:
+   case AARCH64_INSN_IMM_S:
+   mask = BIT(6) - 1;
+   shift = 10;
+   break;
+   case AARCH64_INSN_IMM_R:
+   mask = BIT(6) - 1;
+   shift = 16;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   *maskp = mask;
+   *shiftp = shift;
+
+   return 0;
+}
+
+#define ADR_IMM_HILOSPLIT  2
+#define ADR_IMM_SIZE   SZ_2M
+#define ADR_IMM_LOMASK ((1 << ADR_IMM_HILOSPLIT) - 1)
+#define ADR_IMM_HIMASK ((ADR_IMM_SIZE >> ADR_IMM_HILOSPLIT) - 1)
+#define ADR_IMM_LOSHIFT29
+#define ADR_IMM_HISHIFT5
+
+u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn)
+{
+   u32 immlo, immhi, mask;
+   int shift;
+
+   switch (type) {
+   case AARCH64_INSN_IMM_ADR:
+   shift = 0;
+   immlo = (insn >> ADR_IMM_LOSHIFT) & ADR_IMM_LOMASK;
+   immhi = (insn >> ADR_IMM_HISHIFT) & ADR_IMM_HIMASK;
+   insn = (immhi << ADR_IMM_HILOSPLIT) | immlo;
+   mask = ADR_IMM_SIZE - 1;
+   break;
+   default:
+   if (aarch64_get_imm_shift_mask(type, , ) < 0) {
+   printk(XENLOG_ERR "aarch64_insn_decode_immediate: 
unknown immediate encoding %d\n",
+  type);
+   return 0;
+   }
+   }
+
+   return (insn >> shift) & mask;
+}
+
+u32 

[Xen-devel] [RFC 14/16] xen/arm: arm64: Add cortex-A57 erratum 832075 workaround

[Julien Grall]

The ARM erratum 832075 applies to certain revisions of Cortex-A57, one
of the workarounds is to change device loads into using load-acquire
semantics.

Use the alternative framework to enable the workaround only on affected
cores.

Whilst a guest could trigger the deadlock, it can be broken when the
processor is receiving an interrupt. As the Xen scheduler will always setup
a timer (firing to every 1ms to 300ms depending on the running time
slice) on each processor, the deadlock would last only few milliseconds
and only affects the guest time slice.

Therefore a malicious guest could only hurt itself. Note that all the
guests should implement/enable the workaround for the affected cores.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Update the commit message to explain why it is not necessary
to take care of possible deadlock from the guest.
---
 docs/misc/arm/silicon-errata.txt |  1 +
 xen/arch/arm/Kconfig | 20 
 xen/arch/arm/cpuerrata.c |  9 +
 xen/include/asm-arm/arm64/io.h   | 21 +
 xen/include/asm-arm/cpufeature.h |  3 ++-
 xen/include/asm-arm/processor.h  |  2 ++
 6 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 9a2983b..ab2e5bc 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -46,3 +46,4 @@ stable hypervisors.
 | ARM| Cortex-A53  | #824069 | ARM64_ERRATUM_824069
|
 | ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
+| ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 6e4c769..0c3d66d 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -122,6 +122,26 @@ config ARM64_ERRATUM_819472
  the kernel if an affected CPU is detected.
 
  If unsure, say Y.
+
+config ARM64_ERRATUM_832075
+   bool "Cortex-A57: 832075: possible deadlock on mixing exclusive memory 
accesses with device loads"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 832075 on Cortex-A57 parts up to r1p2.
+
+ Affected Cortex-A57 parts might deadlock when exclusive load/store
+ instructions to Write-Back memory are mixed with Device loads.
+
+ The workaround is to promote device loads to use Load-Acquire
+ semantics.
+ Please note that this does not necessarily enable the workaround,
+ as it depends on the alternative framework, which will only patch
+ the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index 211b520..48fc87a 100644
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata.c
@@ -34,6 +34,15 @@ static const struct arm_cpu_capabilities arm_errata[] = {
 MIDR_RANGE(MIDR_CORTEX_A53, 0x00, 0x01),
 },
 #endif
+#ifdef CONFIG_ARM64_ERRATUM_832075
+{
+/* Cortex-A57 r0p0 - r1p2 */
+.desc = "ARM erratum 832075",
+.capability = ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE,
+MIDR_RANGE(MIDR_CORTEX_A57, 0x00,
+   (1 << MIDR_VARIANT_SHIFT) | 2),
+},
+#endif
 {},
 };
 
diff --git a/xen/include/asm-arm/arm64/io.h b/xen/include/asm-arm/arm64/io.h
index f80156f..30bfc78 100644
--- a/xen/include/asm-arm/arm64/io.h
+++ b/xen/include/asm-arm/arm64/io.h
@@ -22,6 +22,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * Generic IO read/write.  These perform native-endian accesses.
@@ -49,28 +50,40 @@ static inline void __raw_writeq(u64 val, volatile void 
__iomem *addr)
 static inline u8 __raw_readb(const volatile void __iomem *addr)
 {
 u8 val;
-asm volatile("ldrb %w0, [%1]" : "=r" (val) : "r" (addr));
+asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
+ "ldarb %w0, [%1]",
+ ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+ : "=r" (val) : "r" (addr));
 return val;
 }
 
 static inline u16 __raw_readw(const volatile void __iomem *addr)
 {
 u16 val;
-asm volatile("ldrh %w0, [%1]" : "=r" (val) : "r" (addr));
+asm volatile(ALTERNATIVE("ldrh %w0, [%1]",
+ "ldarh %w0, [%1]",
+ ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
+ : "=r" (val) : "r" (addr));
 return val;
 }
 
 static inline u32 __raw_readl(const volatile void __iomem *addr)
 {
 u32 val;
-asm volatile("ldr %w0, [%1]" : "=r" (val) : "r" (addr));
+asm volatile(ALTERNATIVE("ldr %w0, [%1]",
+ "ldar %w0, 

[Xen-devel] [RFC 11/16] xen/arm: Detect silicon revision and set cap bits accordingly

[Julien Grall]

After each CPU has been started, we iterate through a list of CPU
errata to detect CPUs which need from hypervisor code patches.

For each bug there is a function which check if that a particular CPU is
affected. This needs to be done on every CPUs to cover heterogenous
system properly.

If a certain erratum has been detected, the capability bit will be set
and later the call to apply_alternatives() will trigger the actual code
patching.

The code is based on the file arch/arm64/kernel/cpu_errata.c in Linux
v4.6-rc3.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/cpuerrata.c | 26 ++
 xen/arch/arm/cpufeature.c| 16 
 xen/arch/arm/setup.c |  3 +++
 xen/arch/arm/smpboot.c   |  3 +++
 xen/include/asm-arm/cpuerrata.h  |  6 ++
 xen/include/asm-arm/cpufeature.h | 15 +++
 7 files changed, 70 insertions(+)
 create mode 100644 xen/arch/arm/cpuerrata.c
 create mode 100644 xen/include/asm-arm/cpuerrata.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 2d330aa..307578c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -7,6 +7,7 @@ subdir-$(CONFIG_ACPI) += acpi
 obj-$(CONFIG_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.o
 obj-y += cpu.o
+obj-y += cpuerrata.o
 obj-y += cpufeature.o
 obj-y += decode.o
 obj-y += device.o
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
new file mode 100644
index 000..52d39f8
--- /dev/null
+++ b/xen/arch/arm/cpuerrata.c
@@ -0,0 +1,26 @@
+#include 
+#include 
+#include 
+
+#define MIDR_RANGE(model, min, max) \
+.matches = is_affected_midr_range,  \
+.midr_model = model,\
+.midr_range_min = min,  \
+.midr_range_max = max
+
+static bool_t __maybe_unused
+is_affected_midr_range(const struct arm_cpu_capabilities *entry)
+{
+return MIDR_IS_CPU_MODEL_RANGE(boot_cpu_data.midr.bits, entry->midr_model,
+   entry->midr_range_min,
+   entry->midr_range_max);
+}
+
+static const struct arm_cpu_capabilities arm_errata[] = {
+{},
+};
+
+void check_local_cpu_errata(void)
+{
+update_cpu_capabilities(arm_errata, "enabled workaround for");
+}
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 7a1b56b..aa7c5b1 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -24,6 +24,22 @@
 
 DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
 
+void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
+ const char *info)
+{
+int i;
+
+for ( i = 0; caps[i].matches; i++ )
+{
+if ( !caps[i].matches([i]) )
+continue;
+
+if ( !cpus_have_cap(caps[i].capability) && caps[i].desc )
+printk("%s: %s\n", info, caps[i].desc);
+cpus_set_cap(caps[i].capability);
+}
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index c4389ef..67eb13b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,6 +172,8 @@ static void __init processor_id(void)
 }
 
 processor_setup();
+
+check_local_cpu_errata();
 }
 
 void dt_unreserved_regions(paddr_t s, paddr_t e,
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index c5109bf..3f5a77b 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -316,6 +317,8 @@ void start_secondary(unsigned long boot_phys_offset,
 local_irq_enable();
 local_abort_enable();
 
+check_local_cpu_errata();
+
 printk(XENLOG_DEBUG "CPU %u booted.\n", smp_processor_id());
 
 startup_cpu_idle_loop();
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
new file mode 100644
index 000..8ffd7ba
--- /dev/null
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -0,0 +1,6 @@
+#ifndef __ARM_CPUERRATA_H
+#define __ARM_CPUERRATA_H
+
+void check_local_cpu_errata(void);
+
+#endif /* __ARM_CPUERRATA_H */
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 2bebad1..fb57295 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -62,6 +62,21 @@ static inline void cpus_set_cap(unsigned int num)
 __set_bit(num, cpu_hwcaps);
 }
 
+struct arm_cpu_capabilities {
+const char *desc;
+u16 capability;
+bool_t (*matches)(const struct arm_cpu_capabilities *);
+union {
+struct {/* To be used for eratum handling only */
+u32 midr_model;
+u32 midr_range_min, midr_range_max;
+};
+};
+};
+
+void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
+ const char *info);
+
 #endif /* __ASSEMBLY__ */
 
 

[Xen-devel] [RFC 06/16] xen/arm64: Add an helper to invalidate all instruction caches

[Julien Grall]

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/arm64/page.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 29a32cf..fbdc8fb 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -24,6 +24,12 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
  * inline asm operand) */
 #define __clean_and_invalidate_dcache_one(R) "dc  civac, %" #R ";"
 
+/* Invalidate all instruction caches in Inner Shareable domain to PoU */
+static inline void invalidate_icache(void)
+{
+asm volatile ("ic ialluis");
+}
+
 /*
  * Flush all hypervisor mappings from the TLB of the local processor.
  *
-- 
1.9.1


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

[Xen-devel] [RFC 13/16] xen/arm: arm64: Add Cortex-A53 cache errata workaround

[Julien Grall]

The ARM errata 819472, 827319 and 824069 define the same workaround for
these hardware issues in certain Cortex-A53 parts.

The cache instructions "dc cvac" and "dc cvau" need to be upgraded to
"dc civac".

Use the alternative framework to replace those instructions only on
affected cores.

Whilst the errata affect cache instructions issued at any exception
level, it is not necessary to trap EL1/EL0 data cache instructions
access in order to upgrade them. Indeed the data cache corruption would
always be at the address used by the data cache instructions. Note that
this address could point to a shared memory between guests and the
hypervisors, however all the information present in it are be validated
before any use.

Therefore a malicious guest could only hurt itself. Note that all the
guests should implement/enable the workaround for the affected cores.

Signed-off-by: Julien Grall 
---
 docs/misc/arm/silicon-errata.txt |  3 ++
 xen/arch/arm/Kconfig | 71 
 xen/arch/arm/arm64/cache.S   |  8 -
 xen/arch/arm/cpuerrata.c | 17 ++
 xen/include/asm-arm/arm64/page.h |  7 +++-
 xen/include/asm-arm/cpufeature.h |  4 ++-
 xen/include/asm-arm/processor.h  |  6 
 7 files changed, 113 insertions(+), 3 deletions(-)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index 3f0d32b..9a2983b 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -42,4 +42,7 @@ stable hypervisors.
 | Implementor| Component   | Erratum ID  | Kconfig 
|
 
++-+-+-+
 | ARM| Cortex-A15  | #766422 | N/A 
|
+| ARM| Cortex-A53  | #827319 | ARM64_ERRATUM_827319
|
+| ARM| Cortex-A53  | #824069 | ARM64_ERRATUM_824069
|
+| ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 9b3e66b..6e4c769 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -53,6 +53,77 @@ config ALTERNATIVE
 
 endmenu
 
+menu "ARM errata workaround via the alternative framework"
+   depends on ALTERNATIVE
+
+config ARM64_ERRATUM_827319
+   bool "Cortex-A53: 827319: Data cache clean instructions might cause 
overlapping transactions to the interconnect"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 827319 on Cortex-A53 parts up to r0p2 with an AMBA 5 CHI
+ master interface and an L2 cache.
+
+ Under certain conditions this erratum can cause a clean line eviction
+ to occur at the same time as another transaction to the same address
+ on the AMBA 5 CHI interface, which can cause data corruption if the
+ interconnect reorders the two transactions.
+
+ The workaround promotes data cache clean instructions to
+ data cache clean-and-invalidate.
+ Please note that this does not necessarily enable the workaround,
+ as it depends on the alternative framework, which will only patch
+ the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
+config ARM64_ERRATUM_824069
+   bool "Cortex-A53: 824069: Cache line might not be marked as clean after 
a CleanShared snoop"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 824069 on Cortex-A53 parts up to r0p2 when it is connected
+ to a coherent interconnect.
+
+ If a Cortex-A53 processor is executing a store or prefetch for
+ write instruction at the same time as a processor in another
+ cluster is executing a cache maintenance operation to the same
+ address, then this erratum might cause a clean cache line to be
+ incorrectly marked as dirty.
+
+ The workaround promotes data cache clean instructions to
+ data cache clean-and-invalidate.
+ Please note that this option does not necessarily enable the
+ workaround, as it depends on the alternative framework, which will
+ only patch the kernel if an affected CPU is detected.
+
+ If unsure, say Y.
+
+config ARM64_ERRATUM_819472
+   bool "Cortex-A53: 819472: Store exclusive instructions might cause data 
corruption"
+   default y
+   depends on ARM_64
+   help
+ This option adds an alternative code sequence to work around ARM
+ erratum 819472 on Cortex-A53 parts up to r0p1 with an L2 cache
+ present when it is connected to a coherent interconnect.
+
+ If the processor is executing a load and store exclusive 

[Xen-devel] [RFC 16/16] xen/arm: arm64: Document Cortex-A57 erratum 834220

[Julien Grall]

The ARM erratum applies to certain revisions of Cortex-A57. The
processor may report a Stage 2 translation fault as the result of
Stage 1 fault for load crossing a page boundary when there is a
permission fault or device memory fault at stage 1 and a translation
fault at Stage 2.

So Xen needs to check that Stage 1 translation does not generate a fault
before handling the Stage 2 fault. If it is a Stage 1 translation fault,
return to the guest to let the processor injecting the correct fault.

Only document it as this is already the behavior of the fault handlers.
Note that some optimization could be done to avoid unecessary translation
fault. This is because HPFAR_EL2 is valid for more use case. For the moment,
the code is left unmodified.

Signed-off-by: Julien Grall 
---
 docs/misc/arm/silicon-errata.txt |  1 +
 xen/arch/arm/traps.c | 30 ++
 2 files changed, 31 insertions(+)

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
index ab2e5bc..1ac365d 100644
--- a/docs/misc/arm/silicon-errata.txt
+++ b/docs/misc/arm/silicon-errata.txt
@@ -47,3 +47,4 @@ stable hypervisors.
 | ARM| Cortex-A53  | #819472 | ARM64_ERRATUM_819472
|
 | ARM| Cortex-A57  | #852523 | N/A 
|
 | ARM| Cortex-A57  | #832075 | ARM64_ERRATUM_832075
|
+| ARM| Cortex-A57  | #834220 | N/A 
|
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 3acdba0..bbd5309 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2396,6 +2396,21 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
 };
 
+/*
+ * Erratum #834220: The processor may report a Stage 2
+ * translation fault as the result of Stage 1 fault for load
+ * crossing a page boundary when there is a permission fault or
+ * device memory alignment fault at Stage 1 and a translation
+ * fault at Stage 2.
+ *
+ * So Xen needs to check that the Stage 1 translation does not
+ * generate a fault before handling stage 2 fault. If it is a Stage
+ * 1 translation fault, return to the guest to let the processor
+ * injecting the correct fault.
+ *
+ * XXX: This can be optimized to avoid some unecessary
+ * translation.
+ */
 if ( hsr.iabt.s1ptw )
 gpa = get_faulting_ipa();
 else
@@ -2445,6 +2460,21 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 info.gva = READ_SYSREG64(FAR_EL2);
 #endif
 
+/*
+ * Erratum #834220: The processor may report a Stage 2
+ * translation fault as the result of Stage 1 fault for load
+ * crossing a page boundary when there is a permission fault or
+ * device memory alignment fault at Stage 1 and a translation
+ * fault at Stage 2.
+ *
+ * So Xen needs to check that the Stage 1 translation does not
+ * generate a fault before handling stage 2 fault. If it is a Stage
+ * 1 translation fault, return to the guest to let the processor
+ * injecting the correct fault.
+ *
+ * XXX: This can be optimized to avoid some unecessary
+ * translation.
+ */
 if ( dabt.s1ptw )
 info.gpa = get_faulting_ipa();
 else
-- 
1.9.1


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

[Xen-devel] [RFC 12/16] xen/arm: Document the errata implemented in Xen

[Julien Grall]

The new document will help to keep track of all the erratum that Xen is
able to handle.

The text is based on the Linux doc in Documents/arm64/silicon-errata.txt.

Also list the current errata that Xen is aware of.

Signed-off-by: Julien Grall 
---
 docs/misc/arm/silicon-errata.txt | 45 
 1 file changed, 45 insertions(+)
 create mode 100644 docs/misc/arm/silicon-errata.txt

diff --git a/docs/misc/arm/silicon-errata.txt b/docs/misc/arm/silicon-errata.txt
new file mode 100644
index 000..3f0d32b
--- /dev/null
+++ b/docs/misc/arm/silicon-errata.txt
@@ -0,0 +1,45 @@
+Silicon Errata and Software Workarounds
+===
+
+It is an unfortunate fact of life that hardware is often produced with
+so-called "errata", which can cause it to deviate from the architecture
+under specific circumstances.  For hardware produced by ARM, these
+errata are broadly classified into the following categories:
+
+  Category A: A critical error without a viable workaround.
+  Category B: A significant or critical error with an acceptable
+  workaround.
+  Category C: A minor error that is not expected to occur under normal
+  operation.
+
+For more information, consult one of the "Software Developers Errata
+Notice" documents available on infocenter.arm.com (registration
+required).
+
+As far as Xen is concerned, Category B errata may require some special
+treatment in the hypervisor. For example, avoiding a particular sequence
+of code, or configuring the processor in a particular way. A less common
+situation may require similar actions in order to declassify a Category A
+erratum into a Category C erratum. These are collectively known as
+"software workarounds" and are only required in the minority of cases
+(e.g. those cases that both require a non-secure workaround *and* can
+be triggered by Linux).
+
+For software workarounds that may adversely impact systems unaffected by
+the erratum in question, a Kconfig entry is added under "ARM errata
+workarounds via the alternatives framework". These are enabled by default
+and patched in at runtime when an affected CPU is detected. For
+less-intrusive workarounds, a Kconfig option is not available and the code
+is structured (preferably with a comment) in such a way that the erratum
+will not be hit.
+
+This approach can make it slightly onerous to determine exactly which
+errata are worked around in an arbitrary hypervisor source tree, so this
+file acts as a registry of software workarounds in the Xen hypervisor and
+will be updated when new workarounds are committed and backported to
+stable hypervisors.
+
+| Implementor| Component   | Erratum ID  | Kconfig 
|
+++-+-+-+
+| ARM| Cortex-A15  | #766422 | N/A 
|
+| ARM| Cortex-A57  | #852523 | N/A 
|
-- 
1.9.1


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

[Xen-devel] [RFC 15/16] xen/arm: traps: Don't inject a fault if the translation VA -> IPA fails

[Julien Grall]

Based on ARM ARM (D4.5.3 in ARM DDI 0486A and B3.12.7 in ARM DDI 0406C.c),
a Stage 1 translation error has priority over a Stage 2 translation error.

Therefore gva_to_ipa can only fail if another vCPU is playing with the
page table.

Rather than injecting a custom fault, replay the instruction and let the
processor injecting the correct fault.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/traps.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c0325d5..3acdba0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2410,7 +2410,7 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 
 rc = gva_to_ipa(gva, , GV2M_READ);
 if ( rc == -EFAULT )
-goto bad_insn_abort;
+return; /* Try again */
 }
 
 rc = p2m_mem_access_check(gpa, gva, npfec);
@@ -2422,7 +2422,6 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 break;
 }
 
-bad_insn_abort:
 inject_iabt_exception(regs, gva, hsr.len);
 }
 
@@ -2452,7 +2451,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 {
 rc = gva_to_ipa(info.gva, , GV2M_READ);
 if ( rc == -EFAULT )
-goto bad_data_abort;
+return; /* Try again */
 }
 
 switch ( dabt.dfsc & 0x3f )
-- 
1.9.1


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

[Xen-devel] [RFC 08/16] xen/arm: arm64: Reserve a brk immediate to fault on purpose

[Julien Grall]

It may not possible to return a proper error when encoding an
instruction. Instead, a handcrafted instruction will be returned.

Also, provide the encoding for the faulting instruction.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/arm64/brk.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/xen/include/asm-arm/arm64/brk.h b/xen/include/asm-arm/arm64/brk.h
index 7867b07..04442c4 100644
--- a/xen/include/asm-arm/arm64/brk.h
+++ b/xen/include/asm-arm/arm64/brk.h
@@ -12,8 +12,21 @@
 /*
  * #imm16 values used for BRK instruction generation
  * 0x001: xen-mode BUG() and WARN() traps
+ * 0x002: for triggering a fault on purpose (reserved)
  */
 #define BRK_BUG_FRAME_IMM   1
+#define BRK_FAULT_IMM   2
+
+/*
+ * BRK instruction encoding
+ * The #imm16 value should be placed at bits[20:5] within BRK ins
+ */
+#define AARCH64_BREAK_MON 0xd420
+
+/*
+ * BRK instruction for provoking a fault on purpose
+ */
+#define AARCH64_BREAK_FAULT (AARCH64_BREAK_MON | (BRK_FAULT_IMM << 5))
 
 #endif /* !__ASM_ARM_ARM64_BRK */
 /*
-- 
1.9.1


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

[Xen-devel] [RFC 04/16] xen/arm: arm64: Import flush_icache_range from Linux v4.6-rc3

[Julien Grall]

Flushing the icache will required when the support Xen patching will be
added.

Also import the macro icache_line_size which is used by
flush_icache_range.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/arm64/cache.S | 45 +
 xen/include/asm-arm/page.h |  2 ++
 2 files changed, 47 insertions(+)

diff --git a/xen/arch/arm/arm64/cache.S b/xen/arch/arm/arm64/cache.S
index eff4e16..bc5a8f7 100644
--- a/xen/arch/arm/arm64/cache.S
+++ b/xen/arch/arm/arm64/cache.S
@@ -30,6 +30,51 @@
.endm
 
 /*
+ * icache_line_size - get the minimum I-cache line size from the CTR register.
+ */
+   .macro  icache_line_size, reg, tmp
+   mrs \tmp, ctr_el0   // read CTR
+   and \tmp, \tmp, #0xf// cache line size encoding
+   mov \reg, #4// bytes per word
+   lsl \reg, \reg, \tmp// actual cache line size
+   .endm
+
+/*
+ * flush_icache_range(start,end)
+ *
+ * Ensure that the I and D caches are coherent within specified region.
+ * This is typically used when code has been written to a memory region,
+ * and will be executed.
+ *
+ * - start   - virtual start address of region
+ * - end - virtual end address of region
+ */
+ENTRY(flush_icache_range)
+   dcache_line_size x2, x3
+   sub x3, x2, #1
+   bic x4, x0, x3
+1:
+   dc  cvau, x4// clean D line to PoU
+   add x4, x4, x2
+   cmp x4, x1
+   b.lo1b
+   dsb ish
+
+   icache_line_size x2, x3
+   sub x3, x2, #1
+   bic x4, x0, x3
+1:
+   ic  ivau, x4// invalidate I line PoU
+   add x4, x4, x2
+   cmp x4, x1
+   b.lo1b
+   dsb ish
+   isb
+   mov x0, #0
+   ret
+ENDPROC(flush_icache_range)
+
+/*
  * __flush_dcache_area(kaddr, size)
  *
  * Ensure that the data held in the page kaddr is written back to the
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 05d9f82..a94e826 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -328,6 +328,8 @@ static inline int clean_and_invalidate_dcache_va_range
 return 0;
 }
 
+int flush_icache_range(unsigned long start, unsigned long end);
+
 /* Macros for flushing a single small item.  The predicate is always
  * compile-time constant so this will compile down to 3 instructions in
  * the common case. */
-- 
1.9.1


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

[Xen-devel] [RFC 02/16] xen/arm: Include the header asm-arm/system.h in asm-arm/page.h

[Julien Grall]

The header asm-arm/page.h makes use of the macro dsb defined in the header
asm-arm/system.h. Currently, the includer has to specify both of them.

This can be avoided by including asm-arm/system.h in asm-arm/page.h.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/page.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index a94e978..05d9f82 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -84,6 +84,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
  * level and l4 is the root of the trie, the ARM pagetables follow ARM's
-- 
1.9.1


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

[Xen-devel] [RFC 05/16] xen/arm: Add cpu_hwcap bitmap

[Julien Grall]

This will be used to know if a feature, which Xen cares, is available accross
all the CPUs.

This code is a light version of arch/arm64/kernel/cpufeature.c from
Linux v4.6-rc3.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/cpufeature.c| 34 ++
 xen/include/asm-arm/cpufeature.h | 29 +
 3 files changed, 64 insertions(+)
 create mode 100644 xen/arch/arm/cpufeature.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 8e0d2f6..9122f78 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -6,6 +6,7 @@ subdir-$(CONFIG_ACPI) += acpi
 
 obj-y += bootfdt.o
 obj-y += cpu.o
+obj-y += cpufeature.o
 obj-y += decode.o
 obj-y += device.o
 obj-y += domain.o
diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
new file mode 100644
index 000..7a1b56b
--- /dev/null
+++ b/xen/arch/arm/cpufeature.c
@@ -0,0 +1,34 @@
+/*
+ * Contains CPU feature definitions
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 7b519cd..2bebad1 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -35,6 +35,35 @@
 #endif
 #define cpu_has_security  (boot_cpu_feature32(security) > 0)
 
+#define ARM_NCAPS   0
+
+#ifndef __ASSEMBLY__
+
+#include 
+#include 
+#include 
+
+extern DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
+
+static inline bool_t cpus_have_cap(unsigned int num)
+{
+if ( num >= ARM_NCAPS )
+return 0;
+
+return test_bit(num, cpu_hwcaps);
+}
+
+static inline void cpus_set_cap(unsigned int num)
+{
+if (num >= ARM_NCAPS)
+printk(XENLOG_WARNING "Attempt to set an illegal CPU capability (%d >= 
%d)\n",
+   num, ARM_NCAPS);
+else
+__set_bit(num, cpu_hwcaps);
+}
+
+#endif /* __ASSEMBLY__ */
+
 #endif
 /*
  * Local variables:
-- 
1.9.1


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

[Xen-devel] [RFC 03/16] xen/arm: Add macros to handle the MIDR

[Julien Grall]

Add new macros to easily get different parts of the register and to
check if a given MIDR match a CPU model range. The latter will be really
useful to handle errata later.

The macros have been imported from the header arch64/include/asm/cputype.h
in Linux v4.6-rc3

Also remove MIDR_MASK which is unused.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/processor.h | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 6789cd0..1b701c5 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -9,7 +9,40 @@
 #include 
 
 /* MIDR Main ID Register */
-#define MIDR_MASK0xff00
+#define MIDR_REVISION_MASK  0xf
+#define MIDR_RESIVION(midr) ((midr) & MIDR_REVISION_MASK)
+#define MIDR_PARTNUM_SHIFT  4
+#define MIDR_PARTNUM_MASK   (0xfff << MIDR_PARTNUM_SHIFT)
+#define MIDR_PARTNUM(midr) \
+(((midr) & MIDR_PARTNUM_MASK) >> MIDR_PARTNUM_SHIFT)
+#define MIDR_ARCHITECTURE_SHIFT 16
+#define MIDR_ARCHITECTURE_MASK  (0xf << MIDR_ARCHITECTURE_SHIFT)
+#define MIDR_ARCHITECTURE(midr) \
+(((midr) & MIDR_ARCHITECTURE_MASK) >> MIDR_ARCHITECTURE_SHIFT)
+#define MIDR_VARIANT_SHIFT  20
+#define MIDR_VARIANT_MASK   (0xf << MIDR_VARIANT_SHIFT)
+#define MIDR_VARIANT(midr) \
+(((midr) & MIDR_VARIANT_MASK) >> MIDR_VARIANT_SHIFT)
+#define MIDR_IMPLEMENTOR_SHIFT  24
+#define MIDR_IMPLEMENTOR_MASK   (0xff << MIDR_IMPLEMENTOR_SHIFT)
+#define MIDR_IMPLEMENTOR(midr) \
+(((midr) & MIDR_IMPLEMENTOR_MASK) >> MIDR_IMPLEMENTOR_SHIFT)
+
+#define MIDR_CPU_MODEL(imp, partnum)\
+(((imp) << MIDR_IMPLEMENTOR_SHIFT) |\
+ (0xf   << MIDR_ARCHITECTURE_SHIFT) |   \
+ ((partnum) << MIDR_PARTNUM_SHIFT))
+
+#define MIDR_CPU_MODEL_MASK \
+ (MIDR_IMPLEMENTOR_MASK | MIDR_PARTNUM_MASK | MIDR_ARCHITECTURE_MASK)
+
+#define MIDR_IS_CPU_MODEL_RANGE(midr, model, rv_min, rv_max)\
+({  \
+u32 _model = (midr) & MIDR_CPU_MODEL_MASK;  \
+u32 _rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK);\
+\
+_model == (model) && _rv >= (rv_min) && _rv <= (rv_max);\
+})
 
 /* MPIDR Multiprocessor Affinity Register */
 #define _MPIDR_UP   (30)
-- 
1.9.1


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

[Xen-devel] [RFC 00/16] xen/arm: Introduce alternative runtime patching for ARM64

[Julien Grall]

Hello,

Some of the processor erratum will require to modify code sequence. As those
modifications may impact the performance, they should only be enabled on
affected cores. Furthermore, Xen may also want to take advantage of new
hardware features coming up with v8.1 and v8.2.

The first part of the series adds the alternative infrastructure, most of the
code is based on Linux v4.6-rc3. The rest of the series implements errata
for Cortex-A57 and Cortex-A53.

Yours sincerely,

Julien Grall (16):
  xen/arm: Makefile: Sort the entries alphabetically
  xen/arm: Include the header asm-arm/system.h in asm-arm/page.h
  xen/arm: Add macros to handle the MIDR
  xen/arm: arm64: Import flush_icache_range from Linux v4.6-rc3
  xen/arm: Add cpu_hwcap bitmap
  xen/arm64: Add an helper to invalidate all instruction caches
  xen/arm: arm64: Move the define BRK_BUG_FRAME into a separate header
  xen/arm: arm64: Reserve a brk immediate to fault on purpose
  xen/arm: arm64: Add helpers to decode and encode branch instructions
  xen/arm: Introduce alternative runtime patching
  xen/arm: Detect silicon revision and set cap bits accordingly
  xen/arm: Document the errata implemented in Xen
  xen/arm: arm64: Add Cortex-A53 cache errata workaround
  xen/arm: arm64: Add cortex-A57 erratum 832075 workaround
  xen/arm: traps: Don't inject a fault if the translation VA -> IPA
fails
  xen/arm: arm64: Document Cortex-A57 erratum 834220

 docs/misc/arm/silicon-errata.txt  |  50 +
 xen/arch/arm/Kconfig  |  96 +
 xen/arch/arm/Makefile |  41 +++
 xen/arch/arm/alternative.c| 217 ++
 xen/arch/arm/arm32/Makefile   |   9 +-
 xen/arch/arm/arm64/Makefile   |  13 ++-
 xen/arch/arm/arm64/cache.S|  51 +
 xen/arch/arm/arm64/insn.c | 213 +
 xen/arch/arm/cpuerrata.c  |  52 +
 xen/arch/arm/cpufeature.c |  50 +
 xen/arch/arm/platforms/Makefile   |   2 +-
 xen/arch/arm/setup.c  |  11 ++
 xen/arch/arm/smpboot.c|   3 +
 xen/arch/arm/traps.c  |  37 ++-
 xen/arch/arm/xen.lds.S|   7 ++
 xen/include/asm-arm/alternative.h | 165 +
 xen/include/asm-arm/arm64/brk.h   |  39 +++
 xen/include/asm-arm/arm64/bug.h   |   5 +-
 xen/include/asm-arm/arm64/insn.h  |  88 
 xen/include/asm-arm/arm64/io.h|  21 +++-
 xen/include/asm-arm/arm64/page.h  |  13 ++-
 xen/include/asm-arm/cpuerrata.h   |   6 ++
 xen/include/asm-arm/cpufeature.h  |  47 +
 xen/include/asm-arm/insn.h|  22 
 xen/include/asm-arm/page.h|   3 +
 xen/include/asm-arm/processor.h   |  43 +++-
 26 files changed, 1260 insertions(+), 44 deletions(-)
 create mode 100644 docs/misc/arm/silicon-errata.txt
 create mode 100644 xen/arch/arm/alternative.c
 create mode 100644 xen/arch/arm/arm64/insn.c
 create mode 100644 xen/arch/arm/cpuerrata.c
 create mode 100644 xen/arch/arm/cpufeature.c
 create mode 100644 xen/include/asm-arm/alternative.h
 create mode 100644 xen/include/asm-arm/arm64/brk.h
 create mode 100644 xen/include/asm-arm/arm64/insn.h
 create mode 100644 xen/include/asm-arm/cpuerrata.h
 create mode 100644 xen/include/asm-arm/insn.h

-- 
1.9.1


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

[Xen-devel] [RFC 01/16] xen/arm: Makefile: Sort the entries alphabetically

[Julien Grall]

Signed-off-by: Julien Grall 
---
 xen/arch/arm/Makefile   | 38 --
 xen/arch/arm/arm32/Makefile |  9 -
 xen/arch/arm/arm64/Makefile | 12 +---
 xen/arch/arm/platforms/Makefile |  2 +-
 4 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index ead0cc0..8e0d2f6 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -4,42 +4,44 @@ subdir-y += platforms
 subdir-$(CONFIG_ARM_64) += efi
 subdir-$(CONFIG_ACPI) += acpi
 
-obj-$(EARLY_PRINTK) += early_printk.o
+obj-y += bootfdt.o
 obj-y += cpu.o
+obj-y += decode.o
+obj-y += device.o
 obj-y += domain.o
-obj-y += psci.o
-obj-y += vpsci.o
-obj-y += domctl.o
-obj-y += sysctl.o
 obj-y += domain_build.o
-obj-y += gic.o gic-v2.o
+obj-y += domctl.o
+obj-$(EARLY_PRINTK) += early_printk.o
+obj-y += gic.o
+obj-y += gic-v2.o
 obj-$(CONFIG_HAS_GICV3) += gic-v3.o
+obj-y += guestcopy.o
+obj-y += hvm.o
 obj-y += io.o
 obj-y += irq.o
 obj-y += kernel.o
 obj-y += mm.o
 obj-y += p2m.o
 obj-y += percpu.o
-obj-y += guestcopy.o
-obj-y += physdev.o
 obj-y += platform.o
 obj-y += platform_hypercall.o
+obj-y += physdev.o
+obj-y += processor.o
+obj-y += psci.o
 obj-y += setup.o
-obj-y += bootfdt.o
-obj-y += time.o
-obj-y += smpboot.o
-obj-y += smp.o
 obj-y += shutdown.o
+obj-y += smc.o
+obj-y += smp.o
+obj-y += smpboot.o
+obj-y += sysctl.o
+obj-y += time.o
 obj-y += traps.o
-obj-y += vgic.o vgic-v2.o
+obj-y += vgic.o
+obj-y += vgic-v2.o
 obj-$(CONFIG_ARM_64) += vgic-v3.o
 obj-y += vtimer.o
+obj-y += vpsci.o
 obj-y += vuart.o
-obj-y += hvm.o
-obj-y += device.o
-obj-y += decode.o
-obj-y += processor.o
-obj-y += smc.o
 obj-$(CONFIG_XSPLICE) += xsplice.o
 
 #obj-bin-y += o
diff --git a/xen/arch/arm/arm32/Makefile b/xen/arch/arm/arm32/Makefile
index df0e7de..b20db64 100644
--- a/xen/arch/arm/arm32/Makefile
+++ b/xen/arch/arm/arm32/Makefile
@@ -1,12 +1,11 @@
 subdir-y += lib
 
+obj-$(EARLY_PRINTK) += debug.o
+obj-y += domctl.o
+obj-y += domain.o
 obj-y += entry.o
 obj-y += proc-v7.o proc-caxx.o
-
+obj-y += smpboot.o
 obj-y += traps.o
-obj-y += domain.o
 obj-y += vfp.o
-obj-y += smpboot.o
-obj-y += domctl.o
 
-obj-$(EARLY_PRINTK) += debug.o
diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
index c7243f5..39c6ac6 100644
--- a/xen/arch/arm/arm64/Makefile
+++ b/xen/arch/arm/arm64/Makefile
@@ -1,12 +1,10 @@
 subdir-y += lib
 
+obj-y += cache.o
+obj-$(EARLY_PRINTK) += debug.o
+obj-y += domctl.o
+obj-y += domain.o
 obj-y += entry.o
-
+obj-y += smpboot.o
 obj-y += traps.o
-obj-y += domain.o
 obj-y += vfp.o
-obj-y += smpboot.o
-obj-y += domctl.o
-obj-y += cache.o
-
-obj-$(EARLY_PRINTK) += debug.o
diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index 3689eec..49fa683 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -3,8 +3,8 @@ obj-$(CONFIG_ARM_32) += brcm.o
 obj-$(CONFIG_ARM_32) += exynos5.o
 obj-$(CONFIG_ARM_32) += midway.o
 obj-$(CONFIG_ARM_32) += omap5.o
-obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
+obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
 obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
-- 
1.9.1


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

Re: [Xen-devel] [PATCH V7] vm_event: Allow subscribing to write events for specific MSR-s

[Jan Beulich]

>>> Razvan Cojocaru  05/05/16 12:51 PM >>>
>On 05/04/2016 05:45 PM, Jan Beulich wrote:
>>> +*msr &= 0x1fff;
>>> > +return >arch.monitor_msr_bitmap->high;
>>> > +
>>> > +default:
>>> > +return NULL;
>>> > +}
>>> > +}
>>> > +
>>> > +static int monitor_enable_msr(struct domain *d, u32 msr)
>>> > +{
>>> > +u32 *bitmap;
>> Together with the above - unsigned long * please (and the helper
>> function's return type should then also be unsigned long *).
>
>But returning unsigned long * from the helper function would require
>three aditional casts (when returning
>>arch.monitor_msr_bitmap->{low,hypervisor,high}), otherwise the
>compiler will complain about incompatible pointer types.

Well, I also suggested to make those arrays actual bitmaps. The way it is
now the fact that you use void * as return type means you hide a cast from
u8(*)[1024] to u32*. Using proper bitmaps and a proper return type will avoid
all that.

Jan


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

[Xen-devel] [linux-3.14 baseline-only test] 44388: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 44353
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 44353

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

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-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-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-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux48763742b1bceb119b04656b8dd06e0617dfa89a
baseline version:
 linux2ba480453d5acb3d9d5635358c6af84201d70939

Last test of basis44353  2016-04-21 22:08:41 Z   13 days
Testing same since44388  2016-05-05 04:53:57 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alexander Kochetkov 
  Alexandre Belloni 
  Andrew Morton 
  Andy Lutomirski 
  Aristeu Rozanski 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Ben Hutchings 
  Borislav Petkov 
  Chas Williams <3ch...@gmail.com>
  Daniel Lezcano 
  David Howells 
  David S. Miller 
  Davidlohr Bueso 
  Davidlohr Bueso 
  Dmitry Ivanov 
  Dmitry Ivanov 
  Dmitry Torokhov 
  Eryu Guan 
  Fabio Estevam 
  Geert Uytterhoeven 
  Geert Uytterhoeven 
  Greg Kroah-Hartman 
  Guo-Fu Tseng 
  Herbert Xu 
  Ignat Korchagin 
  Ingo Molnar 
  J. Bruce Fields 
  Jani Nikula 
  Javier Martinez Canillas 
  Jerome Marchand 
  Johannes Berg 
  John Keeping 
  K. Y. Srinivasan 
  Kamal Mostafa 
  Keerthy 
  Laszlo Ersek 
  Linus Torvalds 
  Linus Walleij 
  Lokesh Vutla 
  Lu Baolu 
  Mark Brown 
  Mathias Nyman 
  Matt Fleming 
  Mauro Carvalho Chehab 
  Michael Ellerman 
  Michael Hennerich 
  NeilBrown 
  Olof Johansson 
  Pali Rohár 
  Paul Gortmaker 
  Paul Walmsley 
  Robert Dobrowolski 
  Roman Pen 
  Rui Salvaterra 
  Shawn Guo 
  Sugar Zhang 
  Sushaanth Srirangapathi 
  Tejun Heo 
  Tero Kristo 
  Theodore Ts'o 
  Thomas Gleixner 
  Tom Lendacky 
  Tomi Valkeinen 
  Tony Lindgren 
  Tony Luck 

Re: [Xen-devel] [PATCH v3 6/9] tools/xen-access: add test-case for ARM SMC

[Jan Beulich]

i.A. Jan Beulich
Software Engineering Consultant
Attachmate Group
Nördlicher Zubringer 9-11
40470 Düsseldorf
jbeul...@suse.com
SUSE
 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)

>>> Tamas K Lengyel  05/04/16 7:18 PM >>>
>On May 4, 2016 09:35, "Jan Beulich"  wrote:
>>
>> >>> On 04.05.16 at 16:51,  wrote:
>> > --- a/tools/tests/xen-access/xen-access.c
>> > +++ b/tools/tests/xen-access/xen-access.c
>> > @@ -1,4 +1,3 @@
>> > -/*
>> >   * xen-access.c
>> >   *
>> >   * Exercises the basic per-page access mechanisms
>>
>> Are you saying this still builds with such a change?
>
>It builds fine, so not sure what you mean.

Perhaps the patch here isn't what you test? I can't see how a file with the
beginning of a comment removed can build.

Jan


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

Re: [Xen-devel] [HACKATHON 2016] Mini-OS on ARM

[Wei Liu]

On Thu, May 05, 2016 at 05:03:08PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> On 05/05/16 16:57, Wei Liu wrote:
> >On Thu, May 05, 2016 at 04:47:31PM +0100, Steve Capper wrote:
> >>[Apologies for the late send]
> >>
> >>Mini-OS on ARM
> >>==
> >>
> >>This session covered mini-os bringup on 64-bit ARM platforms.
> >>The following points arose during discussion:
> >>
> >>*) 32-bit Mini-OS may have bit-rotted
> >>   o) Some memory addresses may have been hard-coded for instance.
> >>   o) The memory map in Xen can change between releases.
> >>
> >
> >I think this might have been fixed by Juergen.
> 
> This session was about Mini-OS on ARM and this patch is x86 specific.
> 
> The problem is Mini-OS on ARM is using hardcoded addresses and interrupt
> number for some devices. This needs to be fix if you want mini-os to work on
> any Xen ARM release.
> 

OK so that's indeed different thing.

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

Re: [Xen-devel] [HACKATHON 2016] Mini-OS on ARM

[Julien Grall]

Hi Wei,

On 05/05/16 16:57, Wei Liu wrote:

On Thu, May 05, 2016 at 04:47:31PM +0100, Steve Capper wrote:

[Apologies for the late send]

Mini-OS on ARM
==

This session covered mini-os bringup on 64-bit ARM platforms.
The following points arose during discussion:

*) 32-bit Mini-OS may have bit-rotted
   o) Some memory addresses may have been hard-coded for instance.
   o) The memory map in Xen can change between releases.



I think this might have been fixed by Juergen.


This session was about Mini-OS on ARM and this patch is x86 specific.

The problem is Mini-OS on ARM is using hardcoded addresses and interrupt 
number for some devices. This needs to be fix if you want mini-os to 
work on any Xen ARM release.



Author: Juergen Gross 
AuthorDate: Fri Nov 20 19:32:42 2015 +0100
Commit: Ian Campbell 
CommitDate: Mon Nov 23 09:38:58 2015 +

 minios: don't rely on specific page table allocation scheme

 Today mini-os is making assumptions how the page tables it is started
 with are being allocated. Especially it is using the number of page
 table frames to calculate which is the first unmapped pfn.

 Instead of relying on page table number assumptions just look into the
 page tables to find the first pfn not already mapped.

 Signed-off-by: Juergen Gross 
 Acked-by: Samuel Thibault 


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [HACKATHON 2016] Mini-OS on ARM

[Wei Liu]

On Thu, May 05, 2016 at 04:47:31PM +0100, Steve Capper wrote:
> [Apologies for the late send]
> 
> Mini-OS on ARM
> ==
> 
> This session covered mini-os bringup on 64-bit ARM platforms.
> The following points arose during discussion:
> 
> *) 32-bit Mini-OS may have bit-rotted
>   o) Some memory addresses may have been hard-coded for instance.
>   o) The memory map in Xen can change between releases.
> 

I think this might have been fixed by Juergen.

Author: Juergen Gross 
AuthorDate: Fri Nov 20 19:32:42 2015 +0100
Commit: Ian Campbell 
CommitDate: Mon Nov 23 09:38:58 2015 +

minios: don't rely on specific page table allocation scheme

Today mini-os is making assumptions how the page tables it is started
with are being allocated. Especially it is using the number of page
table frames to calculate which is the first unmapped pfn.

Instead of relying on page table number assumptions just look into the
page tables to find the first pfn not already mapped.

Signed-off-by: Juergen Gross 
Acked-by: Samuel Thibault 

> *) To boot one would need page tables and a gic set-up
>   o) The FreeBSD interrupt controller code was deemed incompatible for
>  Mini-OS.
>   o) page table pages should be mapped as cacheable
>   o) Non-cacheable accesses will be re-routed to Xen? This is in the
>  Xen architecture document?
> 
> *) There is some ambiguity about which Mini-OS tree to use?
>   o) Contact Wei to clarify which tree is the right one to work on.
> 

This tree -- git://xenbits.xen.org/mini-os.git

And please send patches to minios-de...@lists.xenproject.org.

> *) There is a hypercall interface to help debug guests
>   o) Details in xen/arch/arm/traps.c
> 
> *) Other things discussed in this session
>   o) Some previous suspend/resume work can be found from Ian Campbell
>  in the xen-devel archive
>   o) Julien to send link?
>   o) A log-dirty pages implementation is missing and is needed for live
>  migration, an early implementation of this was not SMP compliant
>   o) big.LITTLE support is currently tricky as one has to track the
>  errata of all the cores
>   o) This is tricky as the guest OS kernel typically needs to know
>  a-priori about all the core types (to enable errata handling)
>   o) But this contradicts the Xen pool structure that currently does
>  not support straddling pools.
> 
> Cheers,
> -- 
> Steve
> 
> ___
> 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

[Xen-devel] [HACKATHON 2016] PCI Passthrough on ARM

[Steve Capper]

[Apologies for the late send]

PCI Passthrough on ARM
==

In this session Julien Grall talked through an older PCI design
document from xen-devel.
http://lists.xen.org/archives/html/xen-devel/2015-08/msg01306.html

The following points arose during discussion:

*) On ARM everything is initialised in Dom0 whilst on x86 the
   hypervisor initialises everything.
*) PCI passthrough on ARM should be interrupt controller agnostic
   (i.e. work under both GICv2m and GICv3+ITS).
*) Work is needed on SMMU, it may be necessary to unshare some mappings.
*) If possible, the SMMU driver should be sync-ed with the one in the
   Linux kernel.
*) Dom0 should not be in charge of the HW, it passes Xen some info
   unavailable from ACPI.
  o) For example, AML methods need to go via Dom0 whilst tables such as
 IORT can be parsed by hypervisor.
*) BDF->DeviceID mappings (used by GICv3 ITS) needs to match in both
   hypervisor and Dom0.
*) The PCI pass through document needs to be revised before patches can
   be authored.
*) Discussion on the PCI pass through document can continue on the
   xen-devel list.

Cheers,
-- 
Steve

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

[Xen-devel] [HACKATHON 2016] Mini-OS on ARM

[Steve Capper]

[Apologies for the late send]

Mini-OS on ARM
==

This session covered mini-os bringup on 64-bit ARM platforms.
The following points arose during discussion:

*) 32-bit Mini-OS may have bit-rotted
  o) Some memory addresses may have been hard-coded for instance.
  o) The memory map in Xen can change between releases.

*) To boot one would need page tables and a gic set-up
  o) The FreeBSD interrupt controller code was deemed incompatible for
 Mini-OS.
  o) page table pages should be mapped as cacheable
  o) Non-cacheable accesses will be re-routed to Xen? This is in the
 Xen architecture document?

*) There is some ambiguity about which Mini-OS tree to use?
  o) Contact Wei to clarify which tree is the right one to work on.

*) There is a hypercall interface to help debug guests
  o) Details in xen/arch/arm/traps.c

*) Other things discussed in this session
  o) Some previous suspend/resume work can be found from Ian Campbell
 in the xen-devel archive
  o) Julien to send link?
  o) A log-dirty pages implementation is missing and is needed for live
 migration, an early implementation of this was not SMP compliant
  o) big.LITTLE support is currently tricky as one has to track the
 errata of all the cores
  o) This is tricky as the guest OS kernel typically needs to know
 a-priori about all the core types (to enable errata handling)
  o) But this contradicts the Xen pool structure that currently does
 not support straddling pools.

Cheers,
-- 
Steve

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

[Xen-devel] [HACKATHON 2016] ARM Status

[Steve Capper]

[Apologies for the late send]

Xen - ARM Status

There was discussion on the following items:

*) Booting Xen on 64-bit ARM SoC
  o) Unfortunately Xen was executed in EL1.
  o) Advice was given that the firmware should boot the Xen in EL2.
  o) The ARMv7 secure mode switch to Hyp trick is not valid on AArch64.

*) ARMv7 Cubietruck bringup was also discussed
  o) One pain point mentioned was debugging the DomU guest
  o) There are no debug capabilities for a Xen guest, but
  o) There are a set of hyp calls that can be placed in the guest to
 aid with debugging.
  o) The documentation on these hyp calls needs refreshing in a wiki
 somewhere?
  o) Details of these can be found at: xen/arch/arm/traps.c

*) There is no list of names/ownership for HW platforms
  o) This is due to it being non-trivial to deduce a name from wiki
 activity.
  o) If people care about a board, they should make themselves known.

Cheers,
-- 
Steve

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

[Xen-devel] Debugging Xen early boot

[Zytaruk, Kelly]

I am having problems getting XEN boot messages over a serial console.

I have two systems.  On one system I can see the XEN boot message over a serial 
console whereas on the other system I cannot.

I physically move the same PCIe serial card and hard drive from one system to 
the other.  One system shows me the Xen boot messages and the other doesn't.

My config in /etc/grub.d/20_linux_xen is
xen_args="dom0_max_vcpus=4 dom0_mem=2048M,max:3072M iommu=1 conring_size=16384 
loglvl=all guest_loglvl=all com1=115200,8n1,pci console=com1"

I put a printk at the beginning of the Linux boot and I see the Dom0 Linux boot 
messages on both systems.  So I know that the serial port works on both systems 
but for some reason I don't see the Xen messages.

I would like to debug through __start_xen to see how the 16550 is being 
initialized.  Is there an easy way to debug __start_xen? 

Thanks,
Kelly


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

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  149 days
Failing since 65593  2015-12-08 23:44:51 Z  148 days  215 attempts
Testing same since93530  2016-05-05 09:42:35 Z0 days2 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  3 host-install(3)   broken REGR. vs. 44382

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 44382
 build-i386-rumpuserxen6 xen-buildfail   like 44382
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44382
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44382

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-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-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 14 guest-saverestorefail   never pass
 test-armhf-armhf-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-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-amd64-amd64-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-i386-libvirt  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-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-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
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail 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

version targeted for testing:
 xen  adf7d04317b4c4e60db42314ad874a45d80e65b9
baseline version:
 xen  356b5512b0dc9ce81a8007983a110de9798206dc

Last test of basis44382  2016-05-03 15:20:23 Z1 days
Testing same since44387  2016-05-05 03:50:08 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Dario Faggioli 
  David Vrabel 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Kyle J. Temkin 
  Kyle Temkin 
  Razvan Cojocaru 
  Roger Pau Monne 
  Roger Pau Monné 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

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

[Xen-devel] [xen-unstable-smoke test] 93533: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 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

version targeted for testing:
 xen  f8d4c1d5c59eb328480957ff6f1bccaf113b4921
baseline version:
 xen  adf7d04317b4c4e60db42314ad874a45d80e65b9

Last test of basis93482  2016-05-04 18:00:51 Z0 days
Testing same since93533  2016-05-05 11:04:57 Z0 days1 attempts


People who touched revisions under test:
  Paul Lai 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=f8d4c1d5c59eb328480957ff6f1bccaf113b4921
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
f8d4c1d5c59eb328480957ff6f1bccaf113b4921
+ branch=xen-unstable-smoke
+ revision=f8d4c1d5c59eb328480957ff6f1bccaf113b4921
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xf8d4c1d5c59eb328480957ff6f1bccaf113b4921 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ 

Re: [Xen-devel] [PATCH for 4.7 0/4] Assorted scheduling fixes

[Dario Faggioli]

On Thu, 2016-05-05 at 13:00 +0100, Julien Grall wrote:
> Hi Dario,
> On 04/05/16 10:06, Dario Faggioli wrote:
> > On what hardware/emulator? The same Julien was using?
> > > 
> > > (XEN) CPU1 never came online
> > > (XEN) Failed to bring up CPU 1 (error -5)
> > > (XEN) Bringing up CPU2
> > > (XEN) CPU2 never came online
> > > (XEN) Failed to bring up CPU 2 (error -5)
> > > (XEN) Bringing up CPU3
> > > (XEN) CPU3 never came online
> > > (XEN) Failed to bring up CPU 3 (error -5)
> > > (XEN) Brought up 1 CPUs
> > > 
> > > 
> > > Which is not very reassuring. I don't know if that is expected.
> > > 
> > I don't know... I've never said this on any x86 box before, and I
> > wouldn't think it to be related to this series... do you see this
> > only
> > with the series applied?
> Xen ARM doesn't wait indefinitely a secondary CPU to come online. 
> Instead, if it isn't online after a 1s, it will be skipped.
> 
Ok.

> This could happen on the Foundation Model if the number of cores
> given 
> on the model command line, handled by the firmware and described in
> the 
> device tree don't match each other.
> 
Right. Thanks for the explanation.

So, does this mean that the behavior reported above by Konrad, i.e.,
logging and not crashing, is indeed intentional (or at least expected)
and that therefore even this version of the patch cures the issue?

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 for 4.7 0/4] Assorted scheduling fixes

[Julien Grall]

Hi Dario,

On 04/05/16 10:06, Dario Faggioli wrote:

On Tue, 2016-05-03 at 21:26 -0400, Konrad Rzeszutek Wilk wrote:

On Tue, May 03, 2016 at 11:46:27PM +0200, Dario Faggioli wrote:


Julien, the patch is very very similar to the one attached to one
of my reply
in that thread, but I had to change some small bits... Can you
please re-test
it?

I tested it. It does not crash anymore. However I see this:


On what hardware/emulator? The same Julien was using?

(XEN) CPU1 never came online
(XEN) Failed to bring up CPU 1 (error -5)
(XEN) Bringing up CPU2
(XEN) CPU2 never came online
(XEN) Failed to bring up CPU 2 (error -5)
(XEN) Bringing up CPU3
(XEN) CPU3 never came online
(XEN) Failed to bring up CPU 3 (error -5)
(XEN) Brought up 1 CPUs


Which is not very reassuring. I don't know if that is expected.


I don't know... I've never said this on any x86 box before, and I
wouldn't think it to be related to this series... do you see this only
with the series applied?


Xen ARM doesn't wait indefinitely a secondary CPU to come online. 
Instead, if it isn't online after a 1s, it will be skipped.


This could happen on the Foundation Model if the number of cores given 
on the model command line, handled by the firmware and described in the 
device tree don't match each other.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] xen/arm: gicv2: Export GICv2m register frames to Dom0 by device tree

[Julien Grall]

On 05/05/16 12:06, Stefano Stabellini wrote:

On Thu, 5 May 2016, Julien Grall wrote:

Hi Wei,

On 27/04/16 08:05, Wei Chen wrote:

This patch adds v2m extension support in GIC-v2 driver. The GICv2 driver
detects the MSI frames from device tree and creates corresponding device
tree nodes in dom0's DTB. It also provides one hw_ops callback to map
v2m MMIO regions to dom0 and route v2m SPIs to dom0.

With this GICv2m extension support, the dom0 kernel can do GICv2m frame
setup and initialization.

This patch is based on the GICv2m patch of Suravee Suthikulpanit:
[PATCH 2/2] xen/arm: gicv2: Adding support for GICv2m in Dom0
http://lists.xen.org/archives/html/xen-devel/2015-04/msg02613.html

Signed-off-by: Wei Chen 


I have tested the patch and can get MSI working on Juno r2.

The tree is currently frozen in preparation for Xen 4.7. Nonetheless, with the
comment mentioned in [1], this patch looks good to me:

Reviewed-by: Julien Grall 

Stefano, do you plan to carry patch for Xen 4.8? If not, I can create a
separate branch and will resend the patch when the tree is re-opened.


I have always been in favor of creating a branch, in fact I already do
that for QEMU. So I create next-4.8 in


Thank you!


git://xenbits.xen.org/people/sstabellini/xen-unstable.git with this
patch. (If I misunderstood your comment about the readiness of it, let me
know. I'll force push the proper version.)


I am fine with the patch pushed.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] Odroid XU3 support

[Julien Grall]

(CC Stefano)

I forgot the CC stefano on this mail.

On 05/05/16 12:39, Julien Grall wrote:



On 28/04/16 14:26, Suriyan Ramasami wrote:

Hello Julien,


Hello Suriyan,


 Thank you for the advice. I do have a follow up question.

On Thu, Apr 28, 2016 at 2:50 AM, Julien Grall > wrote:

Hello,

On 27/04/16 23:53, Suriyan Ramasami wrote:

 How can I check which core is currently active?
 Judging by this link on big.LITTLE architecture:
http://forum.odroid.com/viewtopic.php?f=65=2580

 result of: cat /proc/cpuinfo | grep "CPU part" is
 CPU part: 0xc07

 which stands for A7.

If you do this in dom0, it will show all of them to be 0xc07.
They are
vCPUs after all.


Which is not a good idea. This means that Linux is not able to
detect potential errata for the underlying cores (in this case the
cortex-A15). Also some userspace may do some runtime optimization
based on the kind of CPUs available in the guest.

Xen is not ready for big.LITTLE, so I would highly recommend you to
disable either all the Cortex-A15 or Cortex-A7.

Ian did recommend that if they were in their own cpu pools it would
avoid mixing them in a guest. I was researching that angle. What is your
take on that?


I have the same idea in mind. The pools are created at boot time by Xen,
physical CPUs will be assigned to a pool depending on the CPU ID.

However this is not enough to get support of big.LITTLE. You will at
least need to modify the domain creation code to set the vMIDR based on
the based where the vCPU will run.
Furthermore Xen is expecting all the CPUs to have the same set of
features, hence the boot CPU data is often used to know what could be
run. This would need some work to get a system wide safe value (see
arch/arm64/kernel/cpufeature.c in Linux).



If Linux is not recognizing it, that is a dom0/domU issue, is it not?


This is a Xen issue. Xen is exposing the wrong CPU ID to the domain and
therefore the kernel may not apply properly errata or apply wrong
optimization.

Regards,



--
Julien Grall

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

Re: [Xen-devel] Odroid XU3 support

[Julien Grall]

On 28/04/16 14:26, Suriyan Ramasami wrote:

Hello Julien,


Hello Suriyan,


 Thank you for the advice. I do have a follow up question.

On Thu, Apr 28, 2016 at 2:50 AM, Julien Grall > wrote:

Hello,

On 27/04/16 23:53, Suriyan Ramasami wrote:

 How can I check which core is currently active?
 Judging by this link on big.LITTLE architecture:
http://forum.odroid.com/viewtopic.php?f=65=2580

 result of: cat /proc/cpuinfo | grep "CPU part" is
 CPU part: 0xc07

 which stands for A7.

If you do this in dom0, it will show all of them to be 0xc07.
They are
vCPUs after all.


Which is not a good idea. This means that Linux is not able to
detect potential errata for the underlying cores (in this case the
cortex-A15). Also some userspace may do some runtime optimization
based on the kind of CPUs available in the guest.

Xen is not ready for big.LITTLE, so I would highly recommend you to
disable either all the Cortex-A15 or Cortex-A7.

Ian did recommend that if they were in their own cpu pools it would
avoid mixing them in a guest. I was researching that angle. What is your
take on that?


I have the same idea in mind. The pools are created at boot time by Xen, 
physical CPUs will be assigned to a pool depending on the CPU ID.


However this is not enough to get support of big.LITTLE. You will at 
least need to modify the domain creation code to set the vMIDR based on 
the based where the vCPU will run.
Furthermore Xen is expecting all the CPUs to have the same set of 
features, hence the boot CPU data is often used to know what could be 
run. This would need some work to get a system wide safe value (see 
arch/arm64/kernel/cpufeature.c in Linux).




If Linux is not recognizing it, that is a dom0/domU issue, is it not?


This is a Xen issue. Xen is exposing the wrong CPU ID to the domain and 
therefore the kernel may not apply properly errata or apply wrong 
optimization.


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH net-next 0/4] xen-netback: support for control ring

[Paul Durrant]

My recent patch to import an up-to-date include/xen/interface/io/netif.h
from the Xen Project brought in the necessary definitions to support the
new control shared ring and protocol. This patch series updates xen-netback
to support the new ring.

Patch #1 adds the necessary boilerplate to map the control ring and handle
messages. No implementation of the new protocol is included in this patch
so that it can be kept to a reasonable size.

Patch #2 adds the protocol implementation.

Patch #3 adds support for passing has values calculated by xen-netback to
capable frontends.

Patch #4 adds support for accepting hash values calculated by capable
frontends and using them the set the socket buffer hash.

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

[Xen-devel] [PATCH net-next 2/4] xen-netback: add control protocol implementation

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.

A previous patch added the necessary boilerplate for mapping the control
ring from the frontend, should it be created. This patch adds
implementations for each of the defined protocol messages.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---
 drivers/net/xen-netback/Makefile|   2 +-
 drivers/net/xen-netback/common.h|  43 +
 drivers/net/xen-netback/hash.c  | 361 
 drivers/net/xen-netback/interface.c |  28 +++
 drivers/net/xen-netback/netback.c   |  49 -
 5 files changed, 480 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/xen-netback/hash.c

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..11e02be 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o hash.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 093a12a..4959716 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -220,6 +220,32 @@ struct xenvif_mcast_addr {
 
 #define XEN_NETBK_MCAST_MAX 64
 
+#define XEN_NETBK_MAX_HASH_KEY_SIZE 40
+#define XEN_NETBK_MAX_HASH_MAPPING_SIZE 128
+#define XEN_NETBK_HASH_TAG_SIZE 40
+
+struct xenvif_hash_cache_entry {
+   u8 tag[XEN_NETBK_HASH_TAG_SIZE];
+   unsigned int len;
+   u32 val;
+   int seq;
+};
+
+struct xenvif_hash_cache {
+   rwlock_t lock;
+   struct xenvif_hash_cache_entry *entry;
+   atomic_t seq;
+};
+
+struct xenvif_hash {
+   unsigned int alg;
+   u32 flags;
+   u8 key[XEN_NETBK_MAX_HASH_KEY_SIZE];
+   u32 mapping[XEN_NETBK_MAX_HASH_MAPPING_SIZE];
+   unsigned int size;
+   struct xenvif_hash_cache cache;
+};
+
 struct xenvif {
/* Unique identifier for this interface. */
domid_t  domid;
@@ -251,6 +277,8 @@ struct xenvif {
unsigned int num_queues; /* active queues, resource allocated */
unsigned int stalled_queues;
 
+   struct xenvif_hash hash;
+
struct xenbus_watch credit_watch;
struct xenbus_watch mcast_ctrl_watch;
 
@@ -353,6 +381,7 @@ extern bool separate_tx_rx_irq;
 extern unsigned int rx_drain_timeout_msecs;
 extern unsigned int rx_stall_timeout_msecs;
 extern unsigned int xenvif_max_queues;
+extern unsigned int xenvif_hash_cache_size;
 
 #ifdef CONFIG_DEBUG_FS
 extern struct dentry *xen_netback_dbg_root;
@@ -366,4 +395,18 @@ void xenvif_skb_zerocopy_complete(struct xenvif_queue 
*queue);
 bool xenvif_mcast_match(struct xenvif *vif, const u8 *addr);
 void xenvif_mcast_addr_list_free(struct xenvif *vif);
 
+/* Hash */
+int xenvif_init_hash(struct xenvif *vif);
+void xenvif_deinit_hash(struct xenvif *vif);
+
+u32 xenvif_set_hash_alg(struct xenvif *vif, u32 alg);
+u32 xenvif_get_hash_flags(struct xenvif *vif, u32 *flags);
+u32 xenvif_set_hash_flags(struct xenvif *vif, u32 flags);
+u32 xenvif_set_hash_key(struct xenvif *vif, u32 gref, u32 len);
+u32 xenvif_set_hash_mapping_size(struct xenvif *vif, u32 size);
+u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
+   u32 off);
+
+void xenvif_set_skb_hash(struct xenvif *vif, struct sk_buff *skb);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-netback/hash.c
new file mode 100644
index 000..054bfd9
--- /dev/null
+++ b/drivers/net/xen-netback/hash.c
@@ -0,0 +1,361 @@
+/*
+ * Copyright (c) 2016 Citrix Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Softare Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL 

[Xen-devel] [PATCH net-next 1/4] xen-netback: add control ring boilerplate

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.

This patch adds the necessary code to xen-netback to map this new shared
ring, should it be created by a frontend, but does not add implementations
for any of the defined protocol messages. These are added in a subsequent
patch for clarity.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---
 drivers/net/xen-netback/common.h|  28 +++---
 drivers/net/xen-netback/interface.c | 101 +---
 drivers/net/xen-netback/netback.c   |  99 +--
 drivers/net/xen-netback/xenbus.c|  75 ++
 4 files changed, 273 insertions(+), 30 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index f44b388..093a12a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -260,6 +260,11 @@ struct xenvif {
struct dentry *xenvif_dbg_root;
 #endif
 
+   struct xen_netif_ctrl_back_ring ctrl;
+   struct task_struct *ctrl_task;
+   wait_queue_head_t ctrl_wq;
+   unsigned int ctrl_irq;
+
/* Miscellaneous private stuff. */
struct net_device *dev;
 };
@@ -285,10 +290,15 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_init_queue(struct xenvif_queue *queue);
 void xenvif_deinit_queue(struct xenvif_queue *queue);
 
-int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
-  unsigned long rx_ring_ref, unsigned int tx_evtchn,
-  unsigned int rx_evtchn);
-void xenvif_disconnect(struct xenvif *vif);
+int xenvif_connect_data(struct xenvif_queue *queue,
+   unsigned long tx_ring_ref,
+   unsigned long rx_ring_ref,
+   unsigned int tx_evtchn,
+   unsigned int rx_evtchn);
+void xenvif_disconnect_data(struct xenvif *vif);
+int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t ring_ref,
+   unsigned int evtchn);
+void xenvif_disconnect_ctrl(struct xenvif *vif);
 void xenvif_free(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -300,10 +310,10 @@ int xenvif_queue_stopped(struct xenvif_queue *queue);
 void xenvif_wake_queue(struct xenvif_queue *queue);
 
 /* (Un)Map communication rings. */
-void xenvif_unmap_frontend_rings(struct xenvif_queue *queue);
-int xenvif_map_frontend_rings(struct xenvif_queue *queue,
- grant_ref_t tx_ring_ref,
- grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_data_rings(struct xenvif_queue *queue);
+int xenvif_map_frontend_data_rings(struct xenvif_queue *queue,
+  grant_ref_t tx_ring_ref,
+  grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_napi_schedule_or_enable_events(struct xenvif_queue *queue);
@@ -318,6 +328,8 @@ void xenvif_kick_thread(struct xenvif_queue *queue);
 
 int xenvif_dealloc_kthread(void *data);
 
+int xenvif_ctrl_kthread(void *data);
+
 void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
 
 void xenvif_carrier_on(struct xenvif *vif);
diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index f5231a2..78a10d2 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -128,6 +128,15 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+irqreturn_t xenvif_ctrl_interrupt(int irq, void *dev_id)
+{
+   struct xenvif *vif = dev_id;
+
+   wake_up(>ctrl_wq);
+
+   return IRQ_HANDLED;
+}
+
 int xenvif_queue_stopped(struct xenvif_queue *queue)
 {
struct net_device *dev = queue->vif->dev;
@@ -527,9 +536,66 @@ void xenvif_carrier_on(struct xenvif *vif)
rtnl_unlock();
 }
 
-int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
-  unsigned long rx_ring_ref, unsigned int tx_evtchn,
-  unsigned int rx_evtchn)
+int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t ring_ref,
+   unsigned int evtchn)
+{
+   struct net_device *dev = vif->dev;
+   void *addr;
+   struct xen_netif_ctrl_sring *shared;
+   struct task_struct *task;
+   int err = -ENOMEM;
+
+   err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
+_ref, 1, );
+   if (err)
+   goto err;
+
+   shared = (struct xen_netif_ctrl_sring *)addr;
+   BACK_RING_INIT(>ctrl, shared, XEN_PAGE_SIZE);
+
+   init_waitqueue_head(>ctrl_wq);
+
+   err = bind_interdomain_evtchn_to_irqhandler(vif->domid, evtchn,
+   

[Xen-devel] [PATCH net-next 3/4] xen-netback: pass hash value to the frontend

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.

This patch adds code to xen-netback to pass hash values calculated for
guest receive-side packets (i.e. netback transmit side) to the frontend.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---
 drivers/net/xen-netback/interface.c | 13 ++-
 drivers/net/xen-netback/netback.c   | 78 +++--
 2 files changed, 77 insertions(+), 14 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index e54b475..b2d945f 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -158,8 +158,17 @@ static u16 xenvif_select_queue(struct net_device *dev, 
struct sk_buff *skb,
struct xenvif *vif = netdev_priv(dev);
unsigned int size = vif->hash.size;
 
-   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
-   return fallback(dev, skb) % dev->real_num_tx_queues;
+   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE) {
+   u16 index = fallback(dev, skb) % dev->real_num_tx_queues;
+
+   /* Make sure there is no hash information in the socket
+* buffer otherwise it would be incorrectly forwarded
+* to the frontend.
+*/
+   skb_clear_hash(skb);
+
+   return index;
+   }
 
xenvif_set_skb_hash(vif, skb);
 
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 6509d11..7c72510 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -168,6 +168,8 @@ static bool xenvif_rx_ring_slots_available(struct 
xenvif_queue *queue)
needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
if (skb_is_gso(skb))
needed++;
+   if (skb->sw_hash)
+   needed++;
 
do {
prod = queue->rx.sring->req_prod;
@@ -285,6 +287,8 @@ struct gop_frag_copy {
struct xenvif_rx_meta *meta;
int head;
int gso_type;
+   int protocol;
+   int hash_present;
 
struct page *page;
 };
@@ -331,8 +335,15 @@ static void xenvif_setup_copy_gop(unsigned long gfn,
npo->copy_off += *len;
info->meta->size += *len;
 
+   if (!info->head)
+   return;
+
/* Leave a gap for the GSO descriptor. */
-   if (info->head && ((1 << info->gso_type) & queue->vif->gso_mask))
+   if ((1 << info->gso_type) & queue->vif->gso_mask)
+   queue->rx.req_cons++;
+
+   /* Leave a gap for the hash extra segment. */
+   if (info->hash_present)
queue->rx.req_cons++;
 
info->head = 0; /* There must be something in this buffer now */
@@ -367,6 +378,11 @@ static void xenvif_gop_frag_copy(struct xenvif_queue 
*queue, struct sk_buff *skb
.npo = npo,
.head = *head,
.gso_type = XEN_NETIF_GSO_TYPE_NONE,
+   /* xenvif_set_skb_hash() will have either set a s/w
+* hash or cleared the hash depending on
+* whether the the frontend wants a hash for this skb.
+*/
+   .hash_present = skb->sw_hash,
};
unsigned long bytes;
 
@@ -555,6 +571,7 @@ void xenvif_kick_thread(struct xenvif_queue *queue)
 
 static void xenvif_rx_action(struct xenvif_queue *queue)
 {
+   struct xenvif *vif = queue->vif;
s8 status;
u16 flags;
struct xen_netif_rx_response *resp;
@@ -590,9 +607,10 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
gnttab_batch_copy(queue->grant_copy_op, npo.copy_prod);
 
while ((skb = __skb_dequeue()) != NULL) {
+   struct xen_netif_extra_info *extra = NULL;
 
if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   queue->vif->gso_prefix_mask) {
+   vif->gso_prefix_mask) {
resp = RING_GET_RESPONSE(>rx,
 queue->rx.rsp_prod_pvt++);
 
@@ -610,7 +628,7 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
queue->stats.tx_bytes += skb->len;
queue->stats.tx_packets++;
 
-   status = xenvif_check_gop(queue->vif,
+   status = xenvif_check_gop(vif,
  XENVIF_RX_CB(skb)->meta_slots_used,
  );
 
@@ -632,21 +650,57 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
flags);
 
if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   queue->vif->gso_mask) {
-   struct xen_netif_extra_info *gso =
-   (struct xen_netif_extra_info *)
+   

[Xen-devel] [PATCH net-next 4/4] xen-netback: use hash value from the frontend

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.

This patch adds code to xen-netback to use the value in a hash extra
info fragment passed from the guest frontend in a transmit-side
(i.e. netback receive side) packet to set the skb hash accordingly.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---
 drivers/net/xen-netback/netback.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 7c72510..a5b5aad 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1509,6 +1509,33 @@ static void xenvif_tx_build_gops(struct xenvif_queue 
*queue,
}
}
 
+   if (extras[XEN_NETIF_EXTRA_TYPE_HASH - 1].type) {
+   struct xen_netif_extra_info *extra;
+   enum pkt_hash_types type = PKT_HASH_TYPE_NONE;
+
+   extra = [XEN_NETIF_EXTRA_TYPE_HASH - 1];
+
+   switch (extra->u.hash.type) {
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV4:
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV6:
+   type = PKT_HASH_TYPE_L3;
+   break;
+
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP:
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP:
+   type = PKT_HASH_TYPE_L4;
+   break;
+
+   default:
+   break;
+   }
+
+   if (type != PKT_HASH_TYPE_NONE)
+   skb_set_hash(skb,
+*(u32 *)extra->u.hash.value,
+type);
+   }
+
XENVIF_TX_CB(skb)->pending_idx = pending_idx;
 
__skb_put(skb, data_len);
-- 
2.1.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 93496
 build-amd64-rumpuserxen   6 xen-buildfail   like 93496
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93496
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93496
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93496
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93496
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 93496

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-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-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-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  adf7d04317b4c4e60db42314ad874a45d80e65b9
baseline version:
 xen  adf7d04317b4c4e60db42314ad874a45d80e65b9

Last test of basis93515  2016-05-05 03:30:10 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16926 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  

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  149 days
Failing since 65593  2015-12-08 23:44:51 Z  148 days  214 attempts
Testing same since93530  2016-05-05 09:42:35 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao 

Re: [Xen-devel] [PATCH v3] xen/arm: gicv2: Export GICv2m register frames to Dom0 by device tree

[Stefano Stabellini]

On Thu, 5 May 2016, Julien Grall wrote:
> Hi Wei,
> 
> On 27/04/16 08:05, Wei Chen wrote:
> > This patch adds v2m extension support in GIC-v2 driver. The GICv2 driver
> > detects the MSI frames from device tree and creates corresponding device
> > tree nodes in dom0's DTB. It also provides one hw_ops callback to map
> > v2m MMIO regions to dom0 and route v2m SPIs to dom0.
> > 
> > With this GICv2m extension support, the dom0 kernel can do GICv2m frame
> > setup and initialization.
> > 
> > This patch is based on the GICv2m patch of Suravee Suthikulpanit:
> > [PATCH 2/2] xen/arm: gicv2: Adding support for GICv2m in Dom0
> > http://lists.xen.org/archives/html/xen-devel/2015-04/msg02613.html
> > 
> > Signed-off-by: Wei Chen 
> 
> I have tested the patch and can get MSI working on Juno r2.
> 
> The tree is currently frozen in preparation for Xen 4.7. Nonetheless, with the
> comment mentioned in [1], this patch looks good to me:
> 
> Reviewed-by: Julien Grall 
> 
> Stefano, do you plan to carry patch for Xen 4.8? If not, I can create a
> separate branch and will resend the patch when the tree is re-opened.

I have always been in favor of creating a branch, in fact I already do
that for QEMU. So I create next-4.8 in
git://xenbits.xen.org/people/sstabellini/xen-unstable.git with this
patch. (If I misunderstood your comment about the readiness of it, let me
know. I'll force push the proper version.)

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

Re: [Xen-devel] [PATCH v3 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

[George Dunlap]

On 05/05/16 07:53, Xu, Quan wrote:
> On May 04, 2016 9:49 PM, George Dunlap  wrote:
>> On Fri, Apr 29, 2016 at 10:25 AM, Quan Xu  wrote:
>>> When IOMMU mapping is failed, we issue a best effort rollback,
>>> stopping IOMMU mapping, unmapping the previous IOMMU maps and
>> then
>>> reporting the error up to the call trees. When rollback is not
>>> feasible (in early initialization phase or trade-off of complexity)
>>> for the hardware domain, we do things on a best effort basis, only throwing
>> out an error message.
>>>
>>> IOMMU unmapping should perhaps continue despite an error, in an
>>> attempt to do best effort cleanup.
>>>
>>> Signed-off-by: Quan Xu 
>>>
>>> CC: Keir Fraser 
>>> CC: Jan Beulich 
>>> CC: Andrew Cooper 
>>> CC: Jun Nakajima 
>>> CC: Kevin Tian 
>>> CC: George Dunlap 
>>> ---
>>>  xen/arch/x86/mm.c   | 13 -
>>>  xen/arch/x86/mm/p2m-ept.c   | 27 +--
>>>  xen/arch/x86/mm/p2m-pt.c| 24 
>>>  xen/arch/x86/mm/p2m.c   | 11 +--
>>>  xen/drivers/passthrough/iommu.c | 14 +-
>>>  5 files changed, 75 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index
>>> a42097f..427097d 100644
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info
>> *page, unsigned long type,
>>> int preemptible)  {
>>>  unsigned long nx, x, y = page->u.inuse.type_info;
>>> -int rc = 0;
>>> +int rc = 0, ret = 0;
>>>
>>>  ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
>>>
>>> @@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info
>> *page, unsigned long type,
>>>  if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
>>>  {
>>>  if ( (x & PGT_type_mask) == PGT_writable_page )
>>> -iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
>>> +ret = iommu_unmap_page(d, mfn_to_gmfn(d,
>> page_to_mfn(page)));
>>>  else if ( type == PGT_writable_page )
>>> -iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
>>> -   page_to_mfn(page),
>>> -   IOMMUF_readable|IOMMUF_writable);
>>> +ret = iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
>>> + page_to_mfn(page),
>>> + IOMMUF_readable|IOMMUF_writable);
>>>  }
>>>  }
>>>
>>> @@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info
>> *page, unsigned long type,
>>>  if ( (x & PGT_partial) && !(nx & PGT_partial) )
>>>  put_page(page);
>>>
>>> +if ( !rc )
>>> +rc = ret;
>>> +
>>>  return rc;
>>>  }
>>>
>>> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
>>> index 1ed5b47..df87944 100644
>>> --- a/xen/arch/x86/mm/p2m-ept.c
>>> +++ b/xen/arch/x86/mm/p2m-ept.c
>>> @@ -821,6 +821,8 @@ out:
>>>  if ( needs_sync )
>>>  ept_sync_domain(p2m);
>>>
>>> +ret = 0;
>>> +
>>>  /* For host p2m, may need to change VT-d page table.*/
>>>  if ( rc == 0 && p2m_is_hostp2m(p2m) && need_iommu(d) &&
>>>   need_modify_vtd_table )
>>> @@ -831,11 +833,29 @@ out:
>>>  {
>>>  if ( iommu_flags )
>>>  for ( i = 0; i < (1 << order); i++ )
>>> -iommu_map_page(d, gfn + i, mfn_x(mfn) + i, 
>>> iommu_flags);
>>> +{
>>> +rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i, 
>>> iommu_flags);
>>> +
>>> +if ( !ret && unlikely(rc) )
>>> +{
>>> +while ( i-- )
>>> +iommu_unmap_page(d, gfn + i);
>>> +
>>> +ret = rc;
>>> +break;
>>> +}
>>> +}
>>>  else
>>>  for ( i = 0; i < (1 << order); i++ )
>>> -iommu_unmap_page(d, gfn + i);
>>> +{
>>> +rc = iommu_unmap_page(d, gfn + i);
>>> +
>>> +if ( !ret && unlikely(rc) )
>>> +ret = rc;
>>> +}
>>>  }
>>> +
>>> +rc = 0;
>>>  }
>>
>> So the reason for doing this thing with setting ret=0, then using rc,
>> then setting rc to zero, is to make sure that the change is propagated
>> to the altp2m if necessary?
>>
>> I'm not a fan of this sort of "implied signalling".  The check at the
>> altp2m conditional is meant to say, "everything went fine, go ahead
>> and propagate the change".  But with your changes, that's not what we
>> want anymore -- we want, "If the change 

Re: [Xen-devel] [PATCH v3] xen/arm: gicv2: Export GICv2m register frames to Dom0 by device tree

[Julien Grall]

Hi Wei,

On 27/04/16 08:05, Wei Chen wrote:

This patch adds v2m extension support in GIC-v2 driver. The GICv2 driver
detects the MSI frames from device tree and creates corresponding device
tree nodes in dom0's DTB. It also provides one hw_ops callback to map
v2m MMIO regions to dom0 and route v2m SPIs to dom0.

With this GICv2m extension support, the dom0 kernel can do GICv2m frame
setup and initialization.

This patch is based on the GICv2m patch of Suravee Suthikulpanit:
[PATCH 2/2] xen/arm: gicv2: Adding support for GICv2m in Dom0
http://lists.xen.org/archives/html/xen-devel/2015-04/msg02613.html

Signed-off-by: Wei Chen 


I have tested the patch and can get MSI working on Juno r2.

The tree is currently frozen in preparation for Xen 4.7. Nonetheless, 
with the comment mentioned in [1], this patch looks good to me:


Reviewed-by: Julien Grall 

Stefano, do you plan to carry patch for Xen 4.8? If not, I can create a 
separate branch and will resend the patch when the tree is re-opened.


Cheers,

[1] 
http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg03540.html


--
Julien Grall

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

Re: [Xen-devel] [PATCH V7] vm_event: Allow subscribing to write events for specific MSR-s

[Razvan Cojocaru]

On 05/04/2016 05:45 PM, Jan Beulich wrote:
>> +*msr &= 0x1fff;
>> > +return >arch.monitor_msr_bitmap->high;
>> > +
>> > +default:
>> > +return NULL;
>> > +}
>> > +}
>> > +
>> > +static int monitor_enable_msr(struct domain *d, u32 msr)
>> > +{
>> > +u32 *bitmap;
> Together with the above - unsigned long * please (and the helper
> function's return type should then also be unsigned long *).

But returning unsigned long * from the helper function would require
three aditional casts (when returning
>arch.monitor_msr_bitmap->{low,hypervisor,high}), otherwise the
compiler will complain about incompatible pointer types.

Leaving the helper to return void * avoids this extra clutter.


Thanks,
Razvan

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

Re: [Xen-devel] problem about using xl create to start a domU

[Stefano Stabellini]

It looks like something is wrong with xenstore. Is xenstored running?
Can you do xenstore-ls in dom0?

On Thu, 5 May 2016, Shannon Zhao wrote:
> Hi,
> 
> I'm going to create a domU for XEN on ARM64. I'm following [1] to cross
> compile the xen tools and [2] to create domU. One thing different is
> that I'm using Build_AEMv8A-AEMv8A fastmodel.
> 
> After executing "/etc/init.d/xencommons start", xl list shows:
> 
> Name   ID   Mem VCPUs  State   Time(s)
> Domain-0   0   256 2 r-  27.3
> 
> Then I execute "losetup /dev/loop0 domU.img" and xl create domU.cfg, it
> prints below logs:
> Parsing config from domU.cfg
> libxl: error: libxl_device.c:1033:device_backend_callback: unable to add
> device with path /local/domain/0/backend/vbd/1/51712
> libxl: error: libxl_create.c:1252:domcreate_launch_dm: unable to add
> disk devices
> libxl: error: libxl_device.c:1033:device_backend_callback: unable to
> remove device with path /local/domain/0/backend/vbd/1/51712
> libxl: error: libxl.c:1636:devices_destroy_cb: libxl__devices_destroy
> failed for 1
> libxl: error: libxl.c:1564:libxl__destroy_domid: non-existant domain 1
> libxl: error: libxl.c:1523:domain_destroy_callback: unable to destroy
> guest with domid 1
> libxl: error: libxl.c:1452:domain_destroy_cb: destruction of domain 1 failed
> 
> Is there anything I missed?
> 
> [1]http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling
> [2]https://wiki.linaro.org/LEG/Engineering/Virtualization/Xen_on_ARMv8_Foundation
> 
> Thanks,
> -- 
> Shannon
> 

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

Re: [Xen-devel] [PATCH] Honor '--enable-githttp' in toplevel Makefile generation

[Wei Liu]

On Thu, May 05, 2016 at 10:31:04AM +0100, Wei Liu wrote:
> On Wed, May 04, 2016 at 08:54:07AM -0700, Paul Lai wrote:
> > During the make world, git mini-os.git didn't honor the 'configure
> > --enable-githttp' option.  The 'enable-githttp' was only honored in
> > the tools subdirectory.
> > 
> > Signed-off-by: Paul Lai 
> 
> Acked-by: Wei Liu 
> 
> Thanks for your patch.
> 
> I will queue this up for pushing shortly. And FYI I will re-generate the
> changes to configure as I commit this.
> 

And it is now pushed to staging branch. I added "build: " prefix to the
subject line.

Wei.

> Wei.

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

Re: [Xen-devel] problem about using xl create to start a domU

[Stefano Stabellini]

CC'ing new Julien's email address.

On Thu, 5 May 2016, Stefano Stabellini wrote:
> It looks like something is wrong with xenstore. Is xenstored running?
> Can you do xenstore-ls in dom0?
> 
> On Thu, 5 May 2016, Shannon Zhao wrote:
> > Hi,
> > 
> > I'm going to create a domU for XEN on ARM64. I'm following [1] to cross
> > compile the xen tools and [2] to create domU. One thing different is
> > that I'm using Build_AEMv8A-AEMv8A fastmodel.
> > 
> > After executing "/etc/init.d/xencommons start", xl list shows:
> > 
> > Name   ID   Mem VCPUs  State   Time(s)
> > Domain-0   0   256 2 r-  27.3
> > 
> > Then I execute "losetup /dev/loop0 domU.img" and xl create domU.cfg, it
> > prints below logs:
> > Parsing config from domU.cfg
> > libxl: error: libxl_device.c:1033:device_backend_callback: unable to add
> > device with path /local/domain/0/backend/vbd/1/51712
> > libxl: error: libxl_create.c:1252:domcreate_launch_dm: unable to add
> > disk devices
> > libxl: error: libxl_device.c:1033:device_backend_callback: unable to
> > remove device with path /local/domain/0/backend/vbd/1/51712
> > libxl: error: libxl.c:1636:devices_destroy_cb: libxl__devices_destroy
> > failed for 1
> > libxl: error: libxl.c:1564:libxl__destroy_domid: non-existant domain 1
> > libxl: error: libxl.c:1523:domain_destroy_callback: unable to destroy
> > guest with domid 1
> > libxl: error: libxl.c:1452:domain_destroy_cb: destruction of domain 1 failed
> > 
> > Is there anything I missed?
> > 
> > [1]http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling
> > [2]https://wiki.linaro.org/LEG/Engineering/Virtualization/Xen_on_ARMv8_Foundation
> > 
> > Thanks,
> > -- 
> > Shannon
> > 
> 

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

Re: [Xen-devel] [PATCH v3 09/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending

[Xu, Quan]

On May 04, 2016 4:43 PM, Jan Beulich  wrote:
> >>> On 04.05.16 at 04:14,  wrote:
> > On May 04, 2016 10:00 AM, Tian, Kevin  wrote:
> >> > From: Xu, Quan
> >> > Sent: Friday, April 29, 2016 5:25 PM diff --git
> >> > a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c index
> >> > 2885e31..9097333 100644
> >> > --- a/xen/arch/x86/acpi/power.c
> >> > +++ b/xen/arch/x86/acpi/power.c
> >> > @@ -45,6 +45,8 @@ void do_suspend_lowlevel(void);
> >> >
> >> >  static int device_power_down(void)  {
> >> > +int err;
> >> > +
> >> >  console_suspend();
> >> >
> >> >  time_suspend();
> >> > @@ -53,11 +55,22 @@ static int device_power_down(void)
> >> >
> >> >  ioapic_suspend();
> >> >
> >> > -iommu_suspend();
> >> > +err = iommu_suspend();
> >> > +
> >> > +if ( err )
> >> > +goto iommu_suspend_error;
> >> >
> >> >  lapic_suspend();
> >> >
> >> >  return 0;
> >> > +
> >> > + iommu_suspend_error:
> >> > +ioapic_resume();
> >> > +i8259A_resume();
> >> > +time_resume();
> >> > +console_resume();
> >> > +
> >> > +return err;
> >> >  }
> >>
> >> Jan had comment to better reuse device_power_up... looks no change in
> >> this version.
> >
> > Yes,  __iiuc__, this may be an optimization, but not a must.
> > We can discuss this in detail In this version.
> 
> As an optimization it would indeed be quite pointless here. My request was
> more for maintainability: By re-using the function future changes don't need
> to go to two places, and hence there's no risk of one of them getting
> forgotten.
> 

Jan,
What about this one as below:


--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -43,6 +43,17 @@ struct acpi_sleep_info acpi_sinfo;

 void do_suspend_lowlevel(void);

+enum dev_power_type {
+TYPE_ALL,
+TYPE_CONSOLE,
+TYPE_TIME,
+TYPE_I8259A,
+TYPE_IOAPIC,
+TYPE_IOMMU,
+TYPE_LAPIC,
+TYPE_UNKNOWN
+};
+
 static int device_power_down(void)
 {
 console_suspend();
@@ -53,26 +64,35 @@ static int device_power_down(void)

 ioapic_suspend();

-iommu_suspend();
+if ( iommu_suspend() )
+return TYPE_IOMMU;

 lapic_suspend();

 return 0;
 }

-static void device_power_up(void)
+static void device_power_up(enum dev_power_type type)
 {
-lapic_resume();
-
-iommu_resume();
-
-ioapic_resume();
-
-i8259A_resume();
-
-time_resume();
-
-console_resume();
+switch ( type ) {
+case TYPE_ALL:
+case TYPE_LAPIC:
+lapic_resume();
+case TYPE_IOMMU:
+iommu_resume();
+case TYPE_IOAPIC:
+ioapic_resume();
+case TYPE_I8259A:
+i8259A_resume();
+case TYPE_TIME:
+time_resume();
+case TYPE_CONSOLE:
+console_resume();
+break;
+default:
+BUG();
+break;
+}
 }

 static void freeze_domains(void)
@@ -169,6 +189,7 @@ static int enter_state(u32 state)
 {
 printk(XENLOG_ERR "Some devices failed to power down.");
 system_state = SYS_STATE_resume;
+device_power_up(error);
 goto done;
 }

@@ -196,7 +217,7 @@ static int enter_state(u32 state)
 write_cr4(cr4 & ~X86_CR4_MCE);
 write_efer(read_efer());

-device_power_up();
+device_power_up(TYPE_ALL);

 mcheck_init(_cpu_data, 0);
 write_cr4(cr4);

--
Quan




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

[Xen-devel] [PATCH for-qemu-trad] Fix build with newer version of GNUTLS

[Wei Liu]

gnutls_kx_set_priority, gnutls_certificate_type_set_priority and
gnutls_protocol_set_priority were deprecated and eventually removed in
GNUTLS 3.4. Application should use gnutls_priority_set_direct instead
per [0].

gnutls_anon_server_credentials was deprecated at some point. Application
should use gnutls_anon_server_credentials_t instead.

Provide compatibility layer for QEMU traditional. This commit is in fact
backport of two upstream QEMU commits:
1. f40d55081667a716312b9a8b6e13835c4074f56b
2. 7d2a929feba319c18603e324b1750830d6c8b7a1

[0] 
https://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html

Signed-off-by: Sjoer van der Ploeg 
Signed-off-by: Wei Liu 
---
 vnc.c | 71 +--
 1 file changed, 48 insertions(+), 23 deletions(-)

diff --git a/vnc.c b/vnc.c
index 573af3b..61d1555 100644
--- a/vnc.c
+++ b/vnc.c
@@ -1925,9 +1925,9 @@ static int vnc_tls_initialize(void)
 return 1;
 }
 
-static gnutls_anon_server_credentials vnc_tls_initialize_anon_cred(void)
+static gnutls_anon_server_credentials_t vnc_tls_initialize_anon_cred(void)
 {
-gnutls_anon_server_credentials anon_cred;
+gnutls_anon_server_credentials_t anon_cred;
 int ret;
 
 if ((ret = gnutls_anon_allocate_server_credentials(_cred)) < 0) {
@@ -2151,13 +2151,52 @@ static void vnc_handshake_io(void *opaque) {
  (vs)->subauth == VNC_AUTH_VENCRYPT_X509VNC ||\
  (vs)->subauth == VNC_AUTH_VENCRYPT_X509PLAIN)
 
+#if defined(GNUTLS_VERSION_NUMBER) && \
+GNUTLS_VERSION_NUMBER >= 0x020200 /* 2.2.0 */
+static int vnc_set_gnutls_priority(gnutls_session_t s, int x509)
+{
+const char *priority = x509 ? "NORMAL" : "NORMAL:+ANON-DH";
+int rc;
 
-static int vnc_start_tls(struct VncState *vs) {
-static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
-static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, 
GNUTLS_SSL3, 0 };
-static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
-static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, 
GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
+rc = gnutls_priority_set_direct(s, priority, NULL);
+if (rc != GNUTLS_E_SUCCESS) {
+return -1;
+}
+return 0;
+}
+#else
+static int vnc_set_gnutls_priority(gnutls_session_t s, int x509)
+{
+static const int cert_types[] = { GNUTLS_CRT_X509, 0 };
+static const int protocols[] = {
+GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0
+};
+static const int kx_anon[] = { GNUTLS_KX_ANON_DH, 0 };
+static const int kx_x509[] = {
+GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA,
+GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0
+};
+int rc;
+
+rc = gnutls_kx_set_priority(s, x509 ? kx_x509 : kx_anon);
+if (rc != GNUTLS_E_SUCCESS) {
+return -1;
+}
+
+rc = gnutls_certificate_type_set_priority(s, cert_types);
+if (rc != GNUTLS_E_SUCCESS) {
+return -1;
+}
 
+rc = gnutls_protocol_set_priority(s, protocols);
+if (rc != GNUTLS_E_SUCCESS) {
+return -1;
+}
+return 0;
+}
+#endif
+
+static int vnc_start_tls(struct VncState *vs) {
 VNC_DEBUG("Do TLS setup\n");
 if (vnc_tls_initialize() < 0) {
VNC_DEBUG("Failed to init TLS\n");
@@ -2177,21 +2216,7 @@ static int vnc_start_tls(struct VncState *vs) {
return -1;
}
 
-   if (gnutls_kx_set_priority(vs->tls_session, NEED_X509_AUTH(vs) ? 
kx_x509 : kx_anon) < 0) {
-   gnutls_deinit(vs->tls_session);
-   vs->tls_session = NULL;
-   vnc_client_error(vs);
-   return -1;
-   }
-
-   if (gnutls_certificate_type_set_priority(vs->tls_session, 
cert_type_priority) < 0) {
-   gnutls_deinit(vs->tls_session);
-   vs->tls_session = NULL;
-   vnc_client_error(vs);
-   return -1;
-   }
-
-   if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 
0) {
+   if (vnc_set_gnutls_priority(vs->tls_session, !!NEED_X509_AUTH(vs)) < 0) 
{
gnutls_deinit(vs->tls_session);
vs->tls_session = NULL;
vnc_client_error(vs);
@@ -2219,7 +2244,7 @@ static int vnc_start_tls(struct VncState *vs) {
}
 
} else {
-   gnutls_anon_server_credentials anon_cred = 
vnc_tls_initialize_anon_cred();
+   gnutls_anon_server_credentials_t anon_cred = 
vnc_tls_initialize_anon_cred();
if (!anon_cred) {
gnutls_deinit(vs->tls_session);
vs->tls_session = NULL;
-- 
2.1.4


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

Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/2] xen: add pvUSB backend

[Anthony PERARD]

On Wed, May 04, 2016 at 10:25:03AM +0200, Juergen Gross wrote:
> On 03/05/16 17:06, Anthony PERARD wrote:
> > On Thu, Mar 10, 2016 at 04:19:30PM +0100, Juergen Gross wrote:
> >> +static void usbback_bh(void *opaque)
> >> +{
> >> +struct usbback_info *usbif;
> >> +struct usbif_urb_back_ring *urb_ring;
> >> +struct usbback_req *usbback_req;
> >> +RING_IDX rc, rp;
> >> +unsigned int more_to_do;
> >> +
> >> +usbif = opaque;
> >> +if (usbif->ring_error) {
> >> +return;
> >> +}
> >> +
> >> +urb_ring = >urb_ring;
> >> +rc = urb_ring->req_cons;
> >> +rp = urb_ring->sring->req_prod;
> > 
> > Maybe use atomic_read() here to avoid req_prod been read more than once.
> 
> Hmm. This isn't done in the other backends.
> 
> TBH: what would happen if req_prod would be read multiple times? In the
> worst case we would see a new request from the guest which we would have
> missed without the atomic_read().

If the guest is misbehaving, it maybe could provoke QEMU to handle more
request. I'm not sure.

For this use of atomic_read, I'm mostly refering to XSA-155[1] and a
conversation[2].

[1] http://xenbits.xen.org/xsa/advisory-155.html
[2] <570cfa45.7070...@citrix.com>
http://lists.xen.org/archives/html/xen-devel/2016-04/msg01696.html


> >> +xen_rmb(); /* Ensure we see queued requests up to 'rp'. */
> >> +

-- 
Anthony PERARD

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

[Xen-devel] [distros-debian-wheezy test] 44389: tolerable trouble: blocked/broken

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-armhf   3 host-install(3)  broken like 44369
 build-armhf-pvops 3 host-install(3)  broken like 44369
 build-amd64   3 host-install(3)  broken like 44369
 build-amd64-pvops 3 host-install(3)  broken like 44369
 build-i3863 host-install(3)  broken like 44369
 build-i386-pvops  3 host-install(3)  broken like 44369

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-wheezy-netboot-pvgrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a

baseline version:
 flight   44369

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked 
 test-amd64-i386-i386-wheezy-netboot-pvgrub   blocked 
 test-amd64-i386-amd64-wheezy-netboot-pygrub  blocked 
 test-amd64-amd64-i386-wheezy-netboot-pygrub  blocked 



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v3 8/9] x86/hvm: Add debug exception vm_events

[Razvan Cojocaru]

On 05/04/2016 05:51 PM, Tamas K Lengyel wrote:
> Since in-guest debug exceptions are now unconditionally trapped to Xen, adding
> a hook for vm_event subscribers to tap into this new always-on guest event. We
> rename along the way hvm_event_breakpoint_type to hvm_event_type to better
> match the various events that can be passed with it. We also introduce the
> necessary monitor_op domctl's to enable subscribing to the events.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Razvan Cojocaru 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> 
> v3: Increment vm_event interface version
> v2: Rename hvm_monitor_event to hvm_monitor_debug
> ---
>  tools/libxc/include/xenctrl.h   |  3 +-
>  tools/libxc/xc_monitor.c| 15 +
>  tools/tests/xen-access/xen-access.c | 61 
> -
>  xen/arch/x86/hvm/monitor.c  | 26 ++--
>  xen/arch/x86/hvm/vmx/vmx.c  | 26 +---
>  xen/arch/x86/monitor.c  | 16 ++
>  xen/include/asm-x86/domain.h|  2 ++
>  xen/include/asm-x86/hvm/monitor.h   |  7 +++--
>  xen/include/asm-x86/monitor.h   |  3 +-
>  xen/include/public/domctl.h |  6 
>  xen/include/public/vm_event.h   | 14 +++--
>  11 files changed, 157 insertions(+), 22 deletions(-)

Acked-by: Razvan Cojocaru 

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

Re: [Xen-devel] [PATCH v3 9/9] MAINTAINERS: Update monitor/vm_event covered code

[Razvan Cojocaru]

On 05/04/2016 05:51 PM, Tamas K Lengyel wrote:
> Add headers to the covered list.
> 
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Jan Beulich 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
>  MAINTAINERS | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Acked-by: Razvan Cojocaru 

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

Re: [Xen-devel] [PATCH v3 7/9] x86/hvm: Rename hvm/event to hvm/monitor

[Razvan Cojocaru]

On 05/04/2016 05:51 PM, Tamas K Lengyel wrote:
> Mechanical renaming to better describe that the code in hvm/event is part of
> the monitor subsystem.
> 
> Signed-off-by: Tamas K Lengyel 
> Acked-by: Kevin Tian 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Razvan Cojocaru 
> Cc: Jun Nakajima 
> ---
>  xen/arch/x86/hvm/Makefile  |  2 +-
>  xen/arch/x86/hvm/hvm.c | 12 +--
>  xen/arch/x86/hvm/{event.c => monitor.c}| 17 ---
>  xen/arch/x86/hvm/vmx/vmx.c | 13 +--
>  xen/include/asm-x86/hvm/{event.h => monitor.h} | 30 
> +-
>  5 files changed, 38 insertions(+), 36 deletions(-)
>  rename xen/arch/x86/hvm/{event.c => monitor.c} (88%)
>  rename xen/include/asm-x86/hvm/{event.h => monitor.h} (60%)

Acked-by: Razvan Cojocaru 

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

Re: [Xen-devel] [PATCH v3 6/9] tools/xen-access: add test-case for ARM SMC

[Razvan Cojocaru]

On 05/04/2016 05:51 PM, Tamas K Lengyel wrote:
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Razvan Cojocaru 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/tests/xen-access/xen-access.c | 32 ++--
>  1 file changed, 30 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/tests/xen-access/xen-access.c 
> b/tools/tests/xen-access/xen-access.c
> index f26e723..db65846 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -1,4 +1,3 @@
> -/*
>   * xen-access.c

With the above fixed as per Jan's comment:

Acked-by: Razvan Cojocaru 

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

Re: [Xen-devel] [PATCH v3 3/9] monitor: ARM SMC events

[Razvan Cojocaru]

On 05/04/2016 05:51 PM, Tamas K Lengyel wrote:
> Add support for monitoring ARM SMC events. This patch only adds the required
> bits to enable/disable monitoring and forwarding the event through vm_event.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Razvan Cojocaru 
> 
> v3: Split parts off as separate patches
> Union for arm32/64 register structs in vm_event
> Cosmetic fixes
> ---
>  xen/arch/arm/monitor.c| 49 
> +++
>  xen/arch/arm/traps.c  | 16 --
>  xen/include/asm-arm/domain.h  |  5 +
>  xen/include/asm-arm/monitor.h | 24 ++---
>  xen/include/public/domctl.h   |  1 +
>  xen/include/public/vm_event.h |  2 ++
>  6 files changed, 77 insertions(+), 20 deletions(-)

The interface part looks alright, but I can't comment on the
ARM-specific bits. With that:

Acked-by: Razvan Cojocaru 

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

Re: [Xen-devel] [PATCH v3 2/9] monitor: Don't call vm_event_fill_regs from common

[Razvan Cojocaru]

On 05/04/2016 05:51 PM, Tamas K Lengyel wrote:
> The prototype of vm_event_fill_regs will differ on x86 and ARM so in this 
> patch
> we move components from common to arch-specific that use this function. As
> part of this patch we rename and relocate vm_event_monitor_guest_request as
> monitor_guest_request from vm_event to monitor.
> 
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Razvan Cojocaru 
> ---
>  xen/arch/arm/Makefile  |  1 +
>  xen/arch/arm/hvm.c |  4 ++--
>  xen/arch/arm/monitor.c | 48 
> ++
>  xen/arch/x86/hvm/event.c   |  3 +++
>  xen/arch/x86/hvm/hvm.c |  3 ++-
>  xen/arch/x86/monitor.c | 18 +
>  xen/common/vm_event.c  | 17 
>  xen/include/xen/monitor.h  |  1 +
>  xen/include/xen/vm_event.h |  2 --
>  9 files changed, 75 insertions(+), 22 deletions(-)
>  create mode 100644 xen/arch/arm/monitor.c

Acked-by: Razvan Cojocaru 

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

Re: [Xen-devel] [PATCH] Honor '--enable-githttp' in toplevel Makefile generation

[Wei Liu]

On Wed, May 04, 2016 at 08:54:07AM -0700, Paul Lai wrote:
> During the make world, git mini-os.git didn't honor the 'configure
> --enable-githttp' option.  The 'enable-githttp' was only honored in
> the tools subdirectory.
> 
> Signed-off-by: Paul Lai 

Acked-by: Wei Liu 

Thanks for your patch.

I will queue this up for pushing shortly. And FYI I will re-generate the
changes to configure as I commit this.

Wei.

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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Razvan Cojocaru]

On 05/04/2016 04:42 PM, Jan Beulich wrote:
 On 04.05.16 at 13:32,  wrote:
>> But while implementing a stub that falls back to the actual LOCK CMPXCHG
>> and replacing hvm_copy_to_guest_virt() with it would indeed be an
>> improvement (with the added advantage of being able to treat
>> non-emulated LOCK CMPXCHG cases), I don't understand how that would
>> solve the read-modify-write atomicity problem.
>>
>> AFAICT, this would only solve the write problem. Assuming we have VCPU1
>> and VCPU2 emulating a LOCKed instruction expecting rmw atomicity, the
>> stub alone would not prevent this:
>>
>> VCPU1: read, modify
>> VCPU2: read, modify, write
>> VCPU1: write
> 
> I'm not sure I follow what you mean here: Does the above represent
> what the guest does, or what the hypervisor does as steps to emulate
> a _single_ guest instruction? In the former case, I don't see what
> you're after. And in the latter case I don't understand why you think
> using CMPXCHG instead of WRITE wouldn't help.

Briefly, this is the scenario: assuming a guest with two VCPUs and an
introspection application that has restricted access to a page, the
guest runs two LOCK instructions that touch the page, causing a page
fault for each instruction. This further translates to two EPT fault
vm_events being placed in the ring buffer.

By the time the introspection application polls the event channel, both
VCPUs are paused, waiting for replies to the vm_events.

If the monitoring application processes both events (puts both replies,
with the emulate option on, in the ring buffer), then signals the event
channel, it is possible that both VCPUs get woken up, ending up running
x86_emulate() simultaneously.

In this case, my understanding is that just using CMPXCHG will not work
(although it is clearly superior to the current implementation), because
the read part and the write part of x86_emulate() (when LOCKed
instructions are involved) should be executed atomically, but writing
the CMPXCHG stub would only make sure that two simultaneous writes won't
occur.

In other words, this would still be possible (atomicity would still not
be guaranteed for LOCKed instructions):

VCPU1: read
VCPU2: read, write
VCPU1: write

when what we want for LOCKed instructions is:

VCPU1: read, write
VCPU2: read, write

Am I misunderstanding how x86_emulate() works?


Thanks,
Razvan

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

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Gary Lin]

On Thu, May 05, 2016 at 08:03:05AM +, Ni, Ruiyu wrote:
> Gary,
> Can you kindly teach me how to run OVMF under Xen?
> 
> I worked out a draft fix and need to verify whether
> everything is fine.
> 
Hi Ray,

1. Install the Xen host. I use openSUSE Leap 42.1 as the host system
   and it's available in https://software.opensuse.org/421/
   Just download the iso file and burn the DVD or make a live USB as
   mentioned here: https://en.opensuse.org/Live_USB_stick
   BTW, I encountered some problem with my test machine (an old HP notebook)
   when booting the Xen kernel. Swithcing from UEFI to legacy mode works
   for me.

2. After installing the base system, add the Virtualization repo to get
   the latest xen packages.
   $ wget 
http://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_42.1/Virtualization.repo
   $ sudo cp Virtualization.repo /etc/zypp/repos.d/
   $ sudo zypper ref

3. Follow the steps to install Xen server with YaST:
   https://tr.opensuse.org/How_to_Install_a_Xen_VM_Server
   You don't need to create the grub2 entry since yast already takes
   care of it. Use 'rpm -qi xen-tools' to make sure xen-tools >= 4.7.0
   is installed.

4. Reboot the system to the Xen kernel. You will see a Xen entry on the
   grub2 menu. Choose the entry to boot Domain0.

5. Now you have a xen server, the next is the config for HVM guest. Here
   is my config:

builder = 'hvm'
name = 'xen-test'
vcpus = 2
memory = 1024
disk = ['/home/linux/VM/xen-test.qcow2,qcow2,xvda,w', 
'file:/home/linux/iso/opensuse-42.1.iso,hdc:cdrom,r']
on_poweroff="destroy"
on_reboot="destroy"
on_crash="destroy"
sdl=1
bios='ovmf'
bios_override='/home/linux/git/edk2/Build/OvmfX64/DEBUG_GCC48/FV/OVMF.fd'
device_model_args = ["-debugcon", "file:debug.log", "-global", 
"isa-debugcon.iobase=0x402"]

   Just create a config file such as xen-test.cfg and add the options.
   The qcow2 and iso are only necessary if you want to install a guest OS.
   Please modify the path of "bios_override" according to your setup.
   BTW, the parameters in "device_model_args" will direct the OVMF debug
   message to debug.log. It's useful for debugging.

6. Build your own OVMF. In case you need any package to build OVMF, try

   $ sudo zypper in 

   to install the package or search the package with

   $ sudo zypper se 

7. Start the HVM guest as root.

   # xl create xen-test.cfg

8. Destroy the HVM guest. The instance won't be destroyed automatically
   after closing the sdl window. You have to destroy the instance
   manually.

   # xl destroy 
   
   In my case, it's
   
   # xl destroy xen-test

Let me know if you need more information to setup xen server/guest :)

Thanks,

Gary Lin

> Regards,
> Ray
> 
> >-Original Message-
> >From: Laszlo Ersek [mailto:ler...@redhat.com]
> >Sent: Thursday, April 28, 2016 6:36 PM
> >To: Ni, Ruiyu ; Gary Lin 
> >Cc: edk2-de...@lists.01.org ; Xen Devel 
> >; Kinney, Michael D
> >
> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> >
> >On 04/28/16 07:08, Ni, Ruiyu wrote:
> >
> >
> > Do you know whether Xen passes the PCI device resource
> > information to firmware?
> >>>
> >>> I don't think so, no.
> >>>
> >>> But, given that the previous PciHostBridgeDxe driver was working on Xen,
> >>> can we perhaps emulate that behavior in
> >>> "OvmfPkg/Library/PciHostBridgeLib" somehow?
> >>
> >> Let me explain the reason why previous PciHostBridgeDxe driver was
> >> working on Xen:
> >> The PciRootBridgeIo.Configuration() in new driver only create resource
> >> descriptor when the resource status is allocated:
> >>
> >> if (ResAllocNode->Status != ResAllocated) {
> >>   continue;
> >> }
> >>
> >> The same function in old driver doesn't check the Status field so it
> >> unconditionally returns BUS descriptor with AddrRangeMin and
> >> AddrRangeMax both equal 0. So that PciEnumeratorLight()
> >> in PciBus driver can still search the devices from starting bus 0.
> >> It just happened to work.
> >>
> >> I think the new driver's Configuration() implementation is correct
> >> while the old driver's one is wrong. So I don't want to change to
> >> wrong implementation to fix this issue.
> >
> >Makes sense, thank you for the explanation.
> >
> >> The issue can be resolved if we have a way to tell PciBus
> >> PciEnumeratorLight() which bus number to start searching.
> >>
> >> It's almost true that starting bus number for root bridge #0
> >> is 0. But it might not be true for the rest root bridges.
> >>
> >> OVMF's PciHostBridgeLib currently returns multiple root bridges
> >> and for root bridge #1, the starting bus number is obviously
> >> not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is
> >> only one root bridge.
> >>
> >> My question is in OVMF over Xen, does "etc/extra-pci-roots" exist?
> >> If it exists, device behind root bridge #1, #2... can *not* be found
> >> 

Re: [Xen-devel] [PATCH for 4.7] pvusb: add missing definition to usbif.h

[Wei Liu]

On Thu, May 05, 2016 at 11:10:33AM +0200, Juergen Gross wrote:
> On 05/05/16 11:02, Wei Liu wrote:
> > On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote:
> >> The pvusb request structure contains the transfer_flags member which
> >> is missing definitions of it's semantics.
> >>
> >> Add the definition of the USBIF_SHORT_NOT_OK flag.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >> Please consider taking this patch for 4.7 release. I believe this is the
> >> last bit missing for support of qemu based pvusb backend. The risk of the
> >> patch should be zero, as no Xen component is using this header.
> >> ---
> >>  xen/include/public/io/usbif.h | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/xen/include/public/io/usbif.h b/xen/include/public/io/usbif.h
> >> index 9ef0cdc..4053c24 100644
> >> --- a/xen/include/public/io/usbif.h
> >> +++ b/xen/include/public/io/usbif.h
> >> @@ -187,6 +187,7 @@ struct usbif_urb_request {
> >>/* basic urb parameter */
> >>uint32_t pipe;
> >>uint16_t transfer_flags;
> >> +#define USBIF_SHORT_NOT_OK0x0001
> > 
> > Where does this come from? Should it be surrounded by define guard?
> 
> I just wasn't defined up to now (to be precise: transfer_flags was just
> copied from the related URB struct member in the frontend, so the
> interface was based on some Linux kernel internals, and the qemu backend
> used a literal "1" for testing the flag).
> 
> > #ifndef USBIF_SHORT_NOT_OK
> > #define USBIF_SHORT_NOT_OK 0x0001
> > #endif
> > 
> > Why does it need to be in our public header? If we end up taking this
> > I think it should at least start with XEN_ prefix.
> 
> This is just a part of the pvusb interface. So it should be defined in
> the appropriate header file.
> 

OK. I get it now.

> Regarding prefix: I can do this, but in this case I'd prefer to add the
> prefix to all definitions in the header. As there are currently no
> in-tree users of this header, the risk would still be zero. :-)
> 
> Thoughts?
> 

Actually not all public #define are prefixed by XEN_ (netif.h does,
blkif.h doesn't) so I won't insists on this. But I still using XEN_
prefix is better.

Wei.

> 
> Juergen
> 

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

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Wei Liu]

On Thu, May 05, 2016 at 08:03:05AM +, Ni, Ruiyu wrote:
> Gary,
> Can you kindly teach me how to run OVMF under Xen?
> 
> I worked out a draft fix and need to verify whether
> everything is fine.
> 

Currently you need to build Xen's hvmloader, which will embed a OVMF
binary inside it.

These are some rough steps:

1. git clone xen.git from xenbits.xen.org
2. cd xen.git, create a .config file, which contains lines:
   OVMF_UPSTREAM_URL = /path/to/your/ovmf/tree
   OVMF_UPSTREAM_REVISION = $OVMF_REVISION
3. run ./configure --enable-ovmf
4. make dist -- you will get everything built in dist directory

Depending whether you have a working xen system or not, you might want
to either

1. install the xen system you just built.

or

1. get the hvmloader binary from dist/install/usr/local/lib/xen/boot
2. copy that to your working xen system

Feel free to ask questions.

As a side note, your ovmf will be cloned into tools/firmware/ directory,
you can check if xen is really building the commit you want there.

It's a bit cumbersome at the moment. Hopefully this will change in the
next release -- Anthony has a series to let you provide a firmware
binary directly.

Wei.

> Regards,
> Ray
> 
> >-Original Message-
> >From: Laszlo Ersek [mailto:ler...@redhat.com]
> >Sent: Thursday, April 28, 2016 6:36 PM
> >To: Ni, Ruiyu ; Gary Lin 
> >Cc: edk2-de...@lists.01.org ; Xen Devel 
> >; Kinney, Michael D
> >
> >Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
> >
> >On 04/28/16 07:08, Ni, Ruiyu wrote:
> >
> >
> > Do you know whether Xen passes the PCI device resource
> > information to firmware?
> >>>
> >>> I don't think so, no.
> >>>
> >>> But, given that the previous PciHostBridgeDxe driver was working on Xen,
> >>> can we perhaps emulate that behavior in
> >>> "OvmfPkg/Library/PciHostBridgeLib" somehow?
> >>
> >> Let me explain the reason why previous PciHostBridgeDxe driver was
> >> working on Xen:
> >> The PciRootBridgeIo.Configuration() in new driver only create resource
> >> descriptor when the resource status is allocated:
> >>
> >> if (ResAllocNode->Status != ResAllocated) {
> >>   continue;
> >> }
> >>
> >> The same function in old driver doesn't check the Status field so it
> >> unconditionally returns BUS descriptor with AddrRangeMin and
> >> AddrRangeMax both equal 0. So that PciEnumeratorLight()
> >> in PciBus driver can still search the devices from starting bus 0.
> >> It just happened to work.
> >>
> >> I think the new driver's Configuration() implementation is correct
> >> while the old driver's one is wrong. So I don't want to change to
> >> wrong implementation to fix this issue.
> >
> >Makes sense, thank you for the explanation.
> >
> >> The issue can be resolved if we have a way to tell PciBus
> >> PciEnumeratorLight() which bus number to start searching.
> >>
> >> It's almost true that starting bus number for root bridge #0
> >> is 0. But it might not be true for the rest root bridges.
> >>
> >> OVMF's PciHostBridgeLib currently returns multiple root bridges
> >> and for root bridge #1, the starting bus number is obviously
> >> not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is
> >> only one root bridge.
> >>
> >> My question is in OVMF over Xen, does "etc/extra-pci-roots" exist?
> >> If it exists, device behind root bridge #1, #2... can *not* be found
> >> with the current implementation.
> >
> >"etc/extra-pci-roots" (more precisely, fw_cfg in general) is specific to
> >QEMU. QemuFwCfgLib runs alright in Xen guests, but whenever you look for
> >an fw_cfg file, it is not found -- which is good behavior.
> >
> >So, OVMF's PciHostBridgeLib produces exactly one PCI_ROOT_BRIDGE object
> >when it runs on Xen. ExtraRootBridges is set to zero, the loop runs zero
> >times, and the one InitRootBridge() call after the loop produces one
> >PCI_ROOT_BRIDGE object, with the following parameters:
> >- Bus.Base = 0
> >- Bus.Limit = PCI_MAX_BUS
> >
> >Thanks
> >Laszlo
> 
> ___
> 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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 3f250a944d691d2169fa3834c89eed7235b735ae
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  149 days
Failing since 65593  2015-12-08 23:44:51 Z  148 days  213 attempts
Testing same since93523  2016-05-05 07:14:33 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao 

Re: [Xen-devel] [PATCH for 4.7] pvusb: add missing definition to usbif.h

[Juergen Gross]

On 05/05/16 11:02, Wei Liu wrote:
> On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote:
>> The pvusb request structure contains the transfer_flags member which
>> is missing definitions of it's semantics.
>>
>> Add the definition of the USBIF_SHORT_NOT_OK flag.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>> Please consider taking this patch for 4.7 release. I believe this is the
>> last bit missing for support of qemu based pvusb backend. The risk of the
>> patch should be zero, as no Xen component is using this header.
>> ---
>>  xen/include/public/io/usbif.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/xen/include/public/io/usbif.h b/xen/include/public/io/usbif.h
>> index 9ef0cdc..4053c24 100644
>> --- a/xen/include/public/io/usbif.h
>> +++ b/xen/include/public/io/usbif.h
>> @@ -187,6 +187,7 @@ struct usbif_urb_request {
>>  /* basic urb parameter */
>>  uint32_t pipe;
>>  uint16_t transfer_flags;
>> +#define USBIF_SHORT_NOT_OK  0x0001
> 
> Where does this come from? Should it be surrounded by define guard?

I just wasn't defined up to now (to be precise: transfer_flags was just
copied from the related URB struct member in the frontend, so the
interface was based on some Linux kernel internals, and the qemu backend
used a literal "1" for testing the flag).

> #ifndef USBIF_SHORT_NOT_OK
> #define USBIF_SHORT_NOT_OK 0x0001
> #endif
> 
> Why does it need to be in our public header? If we end up taking this
> I think it should at least start with XEN_ prefix.

This is just a part of the pvusb interface. So it should be defined in
the appropriate header file.

Regarding prefix: I can do this, but in this case I'd prefer to add the
prefix to all definitions in the header. As there are currently no
in-tree users of this header, the risk would still be zero. :-)

Thoughts?


Juergen


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

Re: [Xen-devel] [PATCH V7] vm_event: Allow subscribing to write events for specific MSR-s

[Razvan Cojocaru]

On 05/04/2016 05:45 PM, Jan Beulich wrote:
 On 29.04.16 at 08:03,  wrote:
>> --- a/xen/arch/x86/monitor.c
>> +++ b/xen/arch/x86/monitor.c
>> @@ -22,6 +22,104 @@
>>  #include 
>>  #include 
>>  
>> +int arch_monitor_init_domain(struct domain *d)
>> +{
>> +if ( !d->arch.monitor_msr_bitmap )
>> +d->arch.monitor_msr_bitmap = xzalloc(struct monitor_msr_bitmap);
>> +
>> +if ( !d->arch.monitor_msr_bitmap )
>> +return -ENOMEM;
>> +
>> +memset(>arch.monitor, 0, sizeof(d->arch.monitor));
>> +memset(>monitor, 0, sizeof(d->monitor));
>> +
>> +return 0;
>> +}
>> +
>> +void arch_monitor_cleanup_domain(struct domain *d)
>> +{
>> +xfree(d->arch.monitor_msr_bitmap);
>> +d->arch.monitor_msr_bitmap = NULL;
>> +}
> 
> Considering that struct domain starts out zeroed, it would seem
> slightly more efficient to move the memset()-s into the cleanup
> function. After all that's how it has been before you moved the
> code here.

No problem.

>> +static void *monitor_bitmap_for_msr(struct domain *d, u32 *msr)
>> +{
>> +ASSERT(d->arch.monitor_msr_bitmap && msr);
>> +
>> +switch ( *msr )
>> +{
>> +case 0 ... 0x1fff:
>> +BUILD_BUG_ON(ARRAY_SIZE(d->arch.monitor_msr_bitmap->low) * 8 < 
>> 0x1fff);
>> +return >arch.monitor_msr_bitmap->low;
>> +
>> +case 0x4000 ... 0x40001fff:
>> +BUILD_BUG_ON(
>> +ARRAY_SIZE(d->arch.monitor_msr_bitmap->hypervisor) * 8 < 
>> 0x1fff);
>> +*msr &= 0x1fff;
>> +return >arch.monitor_msr_bitmap->hypervisor;
>> +
>> +case 0xc000 ... 0xc0001fff:
>> +BUILD_BUG_ON(ARRAY_SIZE(d->arch.monitor_msr_bitmap->high) * 8 < 
>> 0x1fff);
> 
> I really recommend using sizeof() instead of ARRAY_SIZE() in all of
> these, so the code isn't dependent on the base type of those arrays
> (which really ought to change to proper bitmaps anyway, due to
> the __set_bit() and __clear_bit() the callers of this function do). Also
> the comparison with 0x1fff is (in a benign way) off by one - I think
> you really mean either <= or 0x2000.

I'll change it to 0x2000, and switch to sizeof().

>> +*msr &= 0x1fff;
>> +return >arch.monitor_msr_bitmap->high;
>> +
>> +default:
>> +return NULL;
>> +}
>> +}
>> +
>> +static int monitor_enable_msr(struct domain *d, u32 msr)
>> +{
>> +u32 *bitmap;
> 
> Together with the above - unsigned long * please (and the helper
> function's return type should then also be unsigned long *).

Understood.

>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -401,12 +401,12 @@ struct arch_domain
>>  unsigned int write_ctrlreg_enabled   : 4;
>>  unsigned int write_ctrlreg_sync  : 4;
>>  unsigned int write_ctrlreg_onchangeonly  : 4;
>> -unsigned int mov_to_msr_enabled  : 1;
>> -unsigned int mov_to_msr_extended : 1;
>>  unsigned int singlestep_enabled  : 1;
>>  unsigned int software_breakpoint_enabled : 1;
>>  } monitor;
>>  
>> +struct monitor_msr_bitmap *monitor_msr_bitmap;
> 
> Why is this not being made part of the immediately preceding
> structure (omitting the monitor_ prefix)?

I'll move it.


Thanks,
Razvan


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

Re: [Xen-devel] [PATCH for 4.7] pvusb: add missing definition to usbif.h

[Wei Liu]

On Thu, May 05, 2016 at 08:36:45AM +0200, Juergen Gross wrote:
> The pvusb request structure contains the transfer_flags member which
> is missing definitions of it's semantics.
> 
> Add the definition of the USBIF_SHORT_NOT_OK flag.
> 
> Signed-off-by: Juergen Gross 
> ---
> Please consider taking this patch for 4.7 release. I believe this is the
> last bit missing for support of qemu based pvusb backend. The risk of the
> patch should be zero, as no Xen component is using this header.
> ---
>  xen/include/public/io/usbif.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/include/public/io/usbif.h b/xen/include/public/io/usbif.h
> index 9ef0cdc..4053c24 100644
> --- a/xen/include/public/io/usbif.h
> +++ b/xen/include/public/io/usbif.h
> @@ -187,6 +187,7 @@ struct usbif_urb_request {
>   /* basic urb parameter */
>   uint32_t pipe;
>   uint16_t transfer_flags;
> +#define USBIF_SHORT_NOT_OK   0x0001

Where does this come from? Should it be surrounded by define guard?

#ifndef USBIF_SHORT_NOT_OK
#define USBIF_SHORT_NOT_OK 0x0001
#endif

Why does it need to be in our public header? If we end up taking this
I think it should at least start with XEN_ prefix.

>   uint16_t buffer_length;
>   union {
>   uint8_t ctrl[8]; /* setup_packet (Ctrl) */
> -- 
> 2.6.6
> 
> 
> ___
> 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

[Xen-devel] [libvirt test] 93516: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
vs. 91479
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
91479
 test-amd64-i386-libvirt-xsm  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt 14 guest-saverestore fail REGR. vs. 91479
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 91479

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  a4ef805758867d33d20544f13a16de93da11
baseline version:
 libvirt  8b62c65d24bdb20121d3147b4f4dc98bac4f024b

Last test of basis91479  2016-04-15 05:33:51 Z   20 days
Failing since 91597  2016-04-16 04:20:46 Z   19 days   19 attempts
Testing same since93516  2016-05-05 04:22:37 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Ben Gray 
  Bjoern Walk 
  Boris Fiuczynski 
  Cole Robinson 
  Cédric Bosdonnat 
  Daniel P. Berrange 
  Daniel Veillard 
  Dmitry Andreev 
  Eric Blake 
  Erik Skultety 
  Jason J. Herne 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Nitesh Konkar 
  Nitesh Konkar 
  Olga Krishtal 
  Peter Krempa 
  Richard Laager 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Shivaprasad G Bhat 
  Shivaprasad G Bhat 
  Simon Arlott 
  Yuri Chornoivan 

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  fail
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   fail
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmfail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm blocked 
 

Re: [Xen-devel] [edk2] OVMF broken under Xen (in PCI initialisation)

[Ni, Ruiyu]

Gary,
Can you kindly teach me how to run OVMF under Xen?

I worked out a draft fix and need to verify whether
everything is fine.

Regards,
Ray

>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Thursday, April 28, 2016 6:36 PM
>To: Ni, Ruiyu ; Gary Lin 
>Cc: edk2-de...@lists.01.org ; Xen Devel 
>; Kinney, Michael D
>
>Subject: Re: [edk2] OVMF broken under Xen (in PCI initialisation)
>
>On 04/28/16 07:08, Ni, Ruiyu wrote:
>
>
> Do you know whether Xen passes the PCI device resource
> information to firmware?
>>>
>>> I don't think so, no.
>>>
>>> But, given that the previous PciHostBridgeDxe driver was working on Xen,
>>> can we perhaps emulate that behavior in
>>> "OvmfPkg/Library/PciHostBridgeLib" somehow?
>>
>> Let me explain the reason why previous PciHostBridgeDxe driver was
>> working on Xen:
>> The PciRootBridgeIo.Configuration() in new driver only create resource
>> descriptor when the resource status is allocated:
>>
>> if (ResAllocNode->Status != ResAllocated) {
>>   continue;
>> }
>>
>> The same function in old driver doesn't check the Status field so it
>> unconditionally returns BUS descriptor with AddrRangeMin and
>> AddrRangeMax both equal 0. So that PciEnumeratorLight()
>> in PciBus driver can still search the devices from starting bus 0.
>> It just happened to work.
>>
>> I think the new driver's Configuration() implementation is correct
>> while the old driver's one is wrong. So I don't want to change to
>> wrong implementation to fix this issue.
>
>Makes sense, thank you for the explanation.
>
>> The issue can be resolved if we have a way to tell PciBus
>> PciEnumeratorLight() which bus number to start searching.
>>
>> It's almost true that starting bus number for root bridge #0
>> is 0. But it might not be true for the rest root bridges.
>>
>> OVMF's PciHostBridgeLib currently returns multiple root bridges
>> and for root bridge #1, the starting bus number is obviously
>> not 0 unless "etc/extra-pci-roots" doesn't exist or is 0 so there is
>> only one root bridge.
>>
>> My question is in OVMF over Xen, does "etc/extra-pci-roots" exist?
>> If it exists, device behind root bridge #1, #2... can *not* be found
>> with the current implementation.
>
>"etc/extra-pci-roots" (more precisely, fw_cfg in general) is specific to
>QEMU. QemuFwCfgLib runs alright in Xen guests, but whenever you look for
>an fw_cfg file, it is not found -- which is good behavior.
>
>So, OVMF's PciHostBridgeLib produces exactly one PCI_ROOT_BRIDGE object
>when it runs on Xen. ExtraRootBridges is set to zero, the loop runs zero
>times, and the one InitRootBridge() call after the loop produces one
>PCI_ROOT_BRIDGE object, with the following parameters:
>- Bus.Base = 0
>- Bus.Limit = PCI_MAX_BUS
>
>Thanks
>Laszlo

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

Re: [Xen-devel] [PATCH v3 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

[Xu, Quan]

On May 04, 2016 9:49 PM, George Dunlap  wrote:
> On Fri, Apr 29, 2016 at 10:25 AM, Quan Xu  wrote:
> > When IOMMU mapping is failed, we issue a best effort rollback,
> > stopping IOMMU mapping, unmapping the previous IOMMU maps and
> then
> > reporting the error up to the call trees. When rollback is not
> > feasible (in early initialization phase or trade-off of complexity)
> > for the hardware domain, we do things on a best effort basis, only throwing
> out an error message.
> >
> > IOMMU unmapping should perhaps continue despite an error, in an
> > attempt to do best effort cleanup.
> >
> > Signed-off-by: Quan Xu 
> >
> > CC: Keir Fraser 
> > CC: Jan Beulich 
> > CC: Andrew Cooper 
> > CC: Jun Nakajima 
> > CC: Kevin Tian 
> > CC: George Dunlap 
> > ---
> >  xen/arch/x86/mm.c   | 13 -
> >  xen/arch/x86/mm/p2m-ept.c   | 27 +--
> >  xen/arch/x86/mm/p2m-pt.c| 24 
> >  xen/arch/x86/mm/p2m.c   | 11 +--
> >  xen/drivers/passthrough/iommu.c | 14 +-
> >  5 files changed, 75 insertions(+), 14 deletions(-)
> >
> > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index
> > a42097f..427097d 100644
> > --- a/xen/arch/x86/mm.c
> > +++ b/xen/arch/x86/mm.c
> > @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info
> *page, unsigned long type,
> > int preemptible)  {
> >  unsigned long nx, x, y = page->u.inuse.type_info;
> > -int rc = 0;
> > +int rc = 0, ret = 0;
> >
> >  ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
> >
> > @@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info
> *page, unsigned long type,
> >  if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
> >  {
> >  if ( (x & PGT_type_mask) == PGT_writable_page )
> > -iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
> > +ret = iommu_unmap_page(d, mfn_to_gmfn(d,
> page_to_mfn(page)));
> >  else if ( type == PGT_writable_page )
> > -iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
> > -   page_to_mfn(page),
> > -   IOMMUF_readable|IOMMUF_writable);
> > +ret = iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
> > + page_to_mfn(page),
> > + IOMMUF_readable|IOMMUF_writable);
> >  }
> >  }
> >
> > @@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info
> *page, unsigned long type,
> >  if ( (x & PGT_partial) && !(nx & PGT_partial) )
> >  put_page(page);
> >
> > +if ( !rc )
> > +rc = ret;
> > +
> >  return rc;
> >  }
> >
> > diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> > index 1ed5b47..df87944 100644
> > --- a/xen/arch/x86/mm/p2m-ept.c
> > +++ b/xen/arch/x86/mm/p2m-ept.c
> > @@ -821,6 +821,8 @@ out:
> >  if ( needs_sync )
> >  ept_sync_domain(p2m);
> >
> > +ret = 0;
> > +
> >  /* For host p2m, may need to change VT-d page table.*/
> >  if ( rc == 0 && p2m_is_hostp2m(p2m) && need_iommu(d) &&
> >   need_modify_vtd_table )
> > @@ -831,11 +833,29 @@ out:
> >  {
> >  if ( iommu_flags )
> >  for ( i = 0; i < (1 << order); i++ )
> > -iommu_map_page(d, gfn + i, mfn_x(mfn) + i, 
> > iommu_flags);
> > +{
> > +rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i, 
> > iommu_flags);
> > +
> > +if ( !ret && unlikely(rc) )
> > +{
> > +while ( i-- )
> > +iommu_unmap_page(d, gfn + i);
> > +
> > +ret = rc;
> > +break;
> > +}
> > +}
> >  else
> >  for ( i = 0; i < (1 << order); i++ )
> > -iommu_unmap_page(d, gfn + i);
> > +{
> > +rc = iommu_unmap_page(d, gfn + i);
> > +
> > +if ( !ret && unlikely(rc) )
> > +ret = rc;
> > +}
> >  }
> > +
> > +rc = 0;
> >  }
> 
> So the reason for doing this thing with setting ret=0, then using rc,
> then setting rc to zero, is to make sure that the change is propagated
> to the altp2m if necessary?
> 
> I'm not a fan of this sort of "implied signalling".  The check at the
> altp2m conditional is meant to say, "everything went fine, go ahead
> and propagate the change".  But with your changes, that's not what we
> want anymore -- we want, "If the change actually made it into the
> hostp2m, propagate it 

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  148 days
Failing since 65593  2015-12-08 23:44:51 Z  148 days  212 attempts
Testing same since93512  2016-05-05 02:23:11 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  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 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao 

[Xen-devel] [PATCH for 4.7] pvusb: add missing definition to usbif.h

[Juergen Gross]

The pvusb request structure contains the transfer_flags member which
is missing definitions of it's semantics.

Add the definition of the USBIF_SHORT_NOT_OK flag.

Signed-off-by: Juergen Gross 
---
Please consider taking this patch for 4.7 release. I believe this is the
last bit missing for support of qemu based pvusb backend. The risk of the
patch should be zero, as no Xen component is using this header.
---
 xen/include/public/io/usbif.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/public/io/usbif.h b/xen/include/public/io/usbif.h
index 9ef0cdc..4053c24 100644
--- a/xen/include/public/io/usbif.h
+++ b/xen/include/public/io/usbif.h
@@ -187,6 +187,7 @@ struct usbif_urb_request {
/* basic urb parameter */
uint32_t pipe;
uint16_t transfer_flags;
+#define USBIF_SHORT_NOT_OK 0x0001
uint16_t buffer_length;
union {
uint8_t ctrl[8]; /* setup_packet (Ctrl) */
-- 
2.6.6


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