date:20150619

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 58663
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 58663

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 58618
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   like 58663
 test-amd64-i386-libvirt  11 guest-start  fail   like 58663
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail   like 58663
 test-amd64-amd64-libvirt 11 guest-start  fail   like 58663
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58663
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail   like 58663
 test-armhf-armhf-libvirt 11 guest-start  fail   like 58663

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  e76ff6c156906b515c2a4300a81c95886ece5d5f
baseline version:
 xen  fcbfaf9d260adbdb9352d6300b9f63c4ed443d49


People who touched revisions under test:
  David Scott 
  David Vrabel 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Juergen Gross 
  Malcolm Crossley 
  Roger Pau Monne 
  Roger Pau MonnÃ© 
  Ross Lagerwall 
  Wei Liu 
  Wei Wang 


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-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64

[Xen-devel] [rumpuserxen test] 58768: regressions - FAIL

flight 58768 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58768/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866
 build-amd64-rumpuserxen   5 rumpuserxen-build fail REGR. vs. 33866

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

version targeted for testing:
 rumpuserxen  3b91e44996ea6ae1276bce1cc44f38701c53ee6f
baseline version:
 rumpuserxen  30d72f3fc5e35cd53afd82c8179cc0e0b11146ad


People who touched revisions under test:
  Antti Kantee 
  Ian Jackson 
  Martin Lucina 
  Wei Liu 


jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-i386-rumpuserxen-i386 blocked 



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

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


Not pushing.

(No revision log; it would be 535 lines long.)

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

[Xen-devel] [PATCH 9/9] libxc/x86/pvh: Allow creation of 32b PVH guests

Signed-off-by: Boris Ostrovsky 
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Ian Campbell 
CC: Wei Liu 
---
 tools/libxc/xc_dom_x86.c |   32 +++-
 1 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 920fe42..43e79f4 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -301,7 +301,8 @@ static int setup_pgtables_x86_32_pae(struct xc_dom_image 
*dom)
 pgpfn = (addr - dom->parms.virt_base) >> PAGE_SHIFT_X86;
 l1tab[l1off] =
 pfn_to_paddr(xc_dom_p2m_guest(dom, pgpfn)) | L1_PROT;
-if ( (addr >= dom->pgtables_seg.vstart) &&
+if ( (!dom->pvh_enabled)&&
+ (addr >= dom->pgtables_seg.vstart) &&
  (addr < dom->pgtables_seg.vend) )
 l1tab[l1off] &= ~_PAGE_RW; /* page tables are r/o */
 
@@ -591,22 +592,9 @@ static int vcpu_x86_32(struct xc_dom_image *dom, void *ptr)
 
 DOMPRINTF_CALLED(dom->xch);
 
-if ( dom->pvh_enabled )
-{
-xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
- "%s: PVH not supported for 32bit guests.", __FUNCTION__);
-return -1;
-}
-
 /* clear everything */
 memset(ctxt, 0, sizeof(*ctxt));
 
-ctxt->user_regs.ds = FLAT_KERNEL_DS_X86_32;
-ctxt->user_regs.es = FLAT_KERNEL_DS_X86_32;
-ctxt->user_regs.fs = FLAT_KERNEL_DS_X86_32;
-ctxt->user_regs.gs = FLAT_KERNEL_DS_X86_32;
-ctxt->user_regs.ss = FLAT_KERNEL_SS_X86_32;
-ctxt->user_regs.cs = FLAT_KERNEL_CS_X86_32;
 ctxt->user_regs.eip = dom->parms.virt_entry;
 ctxt->user_regs.esp =
 dom->parms.virt_base + (dom->bootstack_pfn + 1) * PAGE_SIZE_X86;
@@ -614,9 +602,6 @@ static int vcpu_x86_32(struct xc_dom_image *dom, void *ptr)
 dom->parms.virt_base + (dom->start_info_pfn) * PAGE_SIZE_X86;
 ctxt->user_regs.eflags = 1 << 9; /* Interrupt Enable */
 
-ctxt->kernel_ss = ctxt->user_regs.ss;
-ctxt->kernel_sp = ctxt->user_regs.esp;
-
 ctxt->flags = VGCF_in_kernel_X86_32 | VGCF_online_X86_32;
 if ( dom->parms.pae == 2 /* extended_cr3 */ ||
  dom->parms.pae == 3 /* bimodal */ )
@@ -627,6 +612,19 @@ static int vcpu_x86_32(struct xc_dom_image *dom, void *ptr)
 DOMPRINTF("%s: cr3: pfn 0x%" PRIpfn " mfn 0x%" PRIpfn "",
   __FUNCTION__, dom->pgtables_seg.pfn, cr3_pfn);
 
+if ( dom->pvh_enabled )
+return 0;
+
+ctxt->user_regs.ds = FLAT_KERNEL_DS_X86_32;
+ctxt->user_regs.es = FLAT_KERNEL_DS_X86_32;
+ctxt->user_regs.fs = FLAT_KERNEL_DS_X86_32;
+ctxt->user_regs.gs = FLAT_KERNEL_DS_X86_32;
+ctxt->user_regs.ss = FLAT_KERNEL_SS_X86_32;
+ctxt->user_regs.cs = FLAT_KERNEL_CS_X86_32;
+
+ctxt->kernel_ss = ctxt->user_regs.ss;
+ctxt->kernel_sp = ctxt->user_regs.esp;
+
 return 0;
 }
 
-- 
1.7.1


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

[Xen-devel] [PATCH 6/9] x86/pvh: Properly set HYPERVISOR_COMPAT_VIRT_START for PVH guests

Signed-off-by: Boris Ostrovsky 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

---
 xen/arch/x86/domain.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index d049fa8..f87da64 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -584,7 +584,7 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 mapcache_domain_init(d);
 
 HYPERVISOR_COMPAT_VIRT_START(d) =
-is_pv_domain(d) ? __HYPERVISOR_COMPAT_VIRT_START : ~0u;
+is_hvm_domain(d) ? ~0u : __HYPERVISOR_COMPAT_VIRT_START;
 
 if ( !is_idle_domain(d) )
 {
-- 
1.7.1


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

[Xen-devel] [PATCH 8/9] x86/pvh: Don't try to get l4 table for PVH guests in vcpu_destroy_pagetables()

.. since it doesn't exist for PVH.

Signed-off-by: Boris Ostrovsky 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

---
 xen/arch/x86/mm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9e08c9b..eb369bd 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2652,7 +2652,7 @@ int vcpu_destroy_pagetables(struct vcpu *v)
 if ( rc )
 return rc;
 
-if ( is_pv_32on64_vcpu(v) )
+if ( is_pv_32on64_vcpu(v) && !is_pvh_vcpu(v) )
 {
 l4tab = map_domain_page(mfn);
 mfn = l4e_get_pfn(*l4tab);
-- 
1.7.1


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

[Xen-devel] [PATCH 4/9] x86/compat: Manage argument translation area separately from l4

Managing l4 page table and argument translation area are two unrelated
operations and should be handled separately

Signed-off-by: Boris Ostrovsky 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

---
 xen/arch/x86/domain.c |   36 ++--
 1 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ba28f38..2445b8b 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -321,19 +321,11 @@ static int setup_compat_l4(struct vcpu *v)
 {
 struct page_info *pg;
 l4_pgentry_t *l4tab;
-int rc;
 
 pg = alloc_domheap_page(v->domain, MEMF_no_owner);
 if ( pg == NULL )
 return -ENOMEM;
 
-rc = setup_compat_arg_xlat(v);
-if ( rc )
-{
-free_domheap_page(pg);
-return rc;
-}
-
 /* This page needs to look like a pagetable so that it can be shadowed */
 pg->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1;
 
@@ -350,7 +342,6 @@ static int setup_compat_l4(struct vcpu *v)
 
 static void release_compat_l4(struct vcpu *v)
 {
-free_compat_arg_xlat(v);
 free_domheap_page(pagetable_get_page(v->arch.guest_table));
 v->arch.guest_table = pagetable_null();
 v->arch.guest_table_user = pagetable_null();
@@ -373,7 +364,10 @@ int switch_native(struct domain *d)
 d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
 
 for_each_vcpu( d, v )
+{
+free_compat_arg_xlat(v);
 release_compat_l4(v);
+}
 
 return 0;
 }
@@ -398,8 +392,13 @@ int switch_compat(struct domain *d)
 d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 1;
 
 for_each_vcpu( d, v )
+{
+if ( (rc = setup_compat_arg_xlat(v)) )
+goto undo_and_fail;
+
 if ( (rc = setup_compat_l4(v)) )
 goto undo_and_fail;
+}
 
 domain_set_alloc_bitsize(d);
 
@@ -408,8 +407,12 @@ int switch_compat(struct domain *d)
  undo_and_fail:
 d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
 for_each_vcpu( d, v )
+{
+free_compat_arg_xlat(v);
+
 if ( !pagetable_is_null(v->arch.guest_table) )
 release_compat_l4(v);
+}
 
 return rc;
 }
@@ -481,7 +484,17 @@ int vcpu_initialise(struct vcpu *v)
 
 v->arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
 
-rc = is_pv_32on64_domain(d) ? setup_compat_l4(v) : 0;
+if ( is_pv_32on64_domain(d) )
+{
+if ( (rc = setup_compat_arg_xlat(v)) )
+goto done;
+
+if ( (rc = setup_compat_l4(v)) )
+{
+free_compat_arg_xlat(v);
+goto done;
+}
+}
  done:
 if ( rc )
 {
@@ -497,7 +510,10 @@ int vcpu_initialise(struct vcpu *v)
 void vcpu_destroy(struct vcpu *v)
 {
 if ( is_pv_32on64_vcpu(v) )
+{
+free_compat_arg_xlat(v);
 release_compat_l4(v);
+}
 
 vcpu_destroy_fpu(v);
 
-- 
1.7.1


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

[Xen-devel] [PATCH 2/9] x86/pvh: Don't copy to/from trap_ctxt for 32b PVH guests

.. as this field is not used by PVH guests

Signed-off-by: Boris Ostrovsky 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

---
 xen/arch/x86/domain.c |9 ++---
 xen/arch/x86/domctl.c |9 ++---
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index e396c6c..c7ef1e6 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -805,9 +805,12 @@ int arch_set_info_guest(
 else
 {
 XLAT_cpu_user_regs(&v->arch.user_regs, &c.cmp->user_regs);
-for ( i = 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); ++i )
-XLAT_trap_info(v->arch.pv_vcpu.trap_ctxt + i,
-   c.cmp->trap_ctxt + i);
+if ( is_pv_domain(d) )
+{
+for ( i = 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); ++i )
+XLAT_trap_info(v->arch.pv_vcpu.trap_ctxt + i,
+   c.cmp->trap_ctxt + i);
+}
 }
 
 if ( has_hvm_container_domain(d) )
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index d8ffe2b..82bd818 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1204,9 +1204,12 @@ void arch_get_info_guest(struct vcpu *v, 
vcpu_guest_context_u c)
 else
 {
 XLAT_cpu_user_regs(&c.cmp->user_regs, &v->arch.user_regs);
-for ( i = 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); ++i )
-XLAT_trap_info(c.cmp->trap_ctxt + i,
-   v->arch.pv_vcpu.trap_ctxt + i);
+if ( is_pv_domain(d) )
+{
+for ( i = 0; i < ARRAY_SIZE(c.cmp->trap_ctxt); ++i )
+XLAT_trap_info(c.cmp->trap_ctxt + i,
+   v->arch.pv_vcpu.trap_ctxt + i);
+}
 }
 
 for ( i = 0; i < ARRAY_SIZE(v->arch.debugreg); ++i )
-- 
1.7.1


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

[Xen-devel] [PATCH 3/9] x86/pvh: Properly initialize PVH guest's CR3

.. based on whether the guest is 32- or 64-bit

Signed-off-by: Boris Ostrovsky 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

---
 xen/arch/x86/domain.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index c7ef1e6..ba28f38 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -828,7 +828,7 @@ int arch_set_info_guest(
 cr3_page = get_page_from_gfn(d, cr3_gfn, NULL, P2M_ALLOC);
 
 v->arch.cr3 = page_to_maddr(cr3_page);
-v->arch.hvm_vcpu.guest_cr[3] = c.nat->ctrlreg[3];
+v->arch.hvm_vcpu.guest_cr[3] = c(ctrlreg[3]);
 v->arch.guest_table = pagetable_from_page(cr3_page);
 
 ASSERT(paging_mode_enabled(d));
-- 
1.7.1


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

[Xen-devel] [PATCH 5/9] x86/pvh: Set PVH guest's mode in XEN_DOMCTL_set_address_size

Instead of assuming that the PVH guest is 64-bit during VMCS constructions and
overriding 32/64 bit settings in VMCS later we can keep HVM's settings and
update them as needed when we know exactly what the guest is.

Signed-off-by: Boris Ostrovsky 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Jun Nakajima 
CC: Eddie Dong 
CC: Kevin Tian 
---
 xen/arch/x86/domain.c |   27 +--
 xen/arch/x86/domain_build.c   |7 +++
 xen/arch/x86/hvm/hvm.c|   19 ++-
 xen/arch/x86/hvm/vmx/vmcs.c   |9 +
 xen/arch/x86/hvm/vmx/vmx.c|   17 +
 xen/include/asm-x86/hvm/hvm.h |2 ++
 6 files changed, 58 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 2445b8b..d049fa8 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -358,6 +358,14 @@ int switch_native(struct domain *d)
 
 if ( !may_switch_mode(d) )
 return -EACCES;
+
+if ( is_pvh_domain(d) )
+{
+for_each_vcpu( d, v )
+if ( hvm_set_mode(v, 8) )
+return -EACCES;
+}
+
 if ( !is_pv_32on64_domain(d) )
 return 0;
 
@@ -377,13 +385,6 @@ int switch_compat(struct domain *d)
 struct vcpu *v;
 int rc;
 
-if ( is_pvh_domain(d) )
-{
-printk(XENLOG_G_INFO
-   "Xen currently does not support 32bit PVH guests\n");
-return -EINVAL;
-}
-
 if ( !may_switch_mode(d) )
 return -EACCES;
 if ( is_pv_32on64_domain(d) )
@@ -396,7 +397,12 @@ int switch_compat(struct domain *d)
 if ( (rc = setup_compat_arg_xlat(v)) )
 goto undo_and_fail;
 
-if ( (rc = setup_compat_l4(v)) )
+if ( !is_pvh_domain(d) )
+rc = setup_compat_l4(v);
+else
+rc = hvm_set_mode(v, 4);
+
+if ( rc )
 goto undo_and_fail;
 }
 
@@ -410,7 +416,7 @@ int switch_compat(struct domain *d)
 {
 free_compat_arg_xlat(v);
 
-if ( !pagetable_is_null(v->arch.guest_table) )
+if ( !is_pvh_domain(d) && !pagetable_is_null(v->arch.guest_table) )
 release_compat_l4(v);
 }
 
@@ -512,7 +518,8 @@ void vcpu_destroy(struct vcpu *v)
 if ( is_pv_32on64_vcpu(v) )
 {
 free_compat_arg_xlat(v);
-release_compat_l4(v);
+if ( !is_pvh_vcpu(v) )
+release_compat_l4(v);
 }
 
 vcpu_destroy_fpu(v);
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index d76707f..ca3f6d1 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -141,6 +141,13 @@ static struct vcpu *__init setup_dom0_vcpu(struct domain 
*d,
 if ( !d->is_pinned && !dom0_affinity_relaxed )
 cpumask_copy(v->cpu_hard_affinity, &dom0_cpus);
 cpumask_copy(v->cpu_soft_affinity, &dom0_cpus);
+
+if ( is_pvh_vcpu(v) )
+if ( hvm_set_mode(v, is_pv_32bit_domain(d) ? 4 : 8) )
+{
+vcpu_destroy(v);
+return NULL;
+}
 }
 
 return v;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d5e5242..c3c129d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2320,12 +2320,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
 v->arch.hvm_vcpu.inject_trap.vector = -1;
 
 if ( is_pvh_domain(d) )
-{
-v->arch.hvm_vcpu.hcall_64bit = 1;/* PVH 32bitfixme. */
-/* This is for hvm_long_mode_enabled(v). */
-v->arch.hvm_vcpu.guest_efer = EFER_LMA | EFER_LME;
 return 0;
-}
 
 rc = setup_compat_arg_xlat(v); /* teardown: free_compat_arg_xlat() */
 if ( rc != 0 )
@@ -6495,6 +6490,20 @@ enum hvm_intblk nhvm_interrupt_blocked(struct vcpu *v)
 return hvm_funcs.nhvm_intr_blocked(v);
 }
 
+int hvm_set_mode(struct vcpu *v, int mode)
+{
+if ( mode == 8 )
+{
+v->arch.hvm_vcpu.guest_efer |= EFER_LMA | EFER_LME;
+hvm_update_guest_efer(v);
+}
+
+if ( hvm_funcs.set_mode )
+return hvm_funcs.set_mode(v, mode);
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 4c5ceb5..08e2097 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -984,9 +984,6 @@ static int construct_vmcs(struct vcpu *v)
 v->arch.hvm_vmx.secondary_exec_control &=
 ~SECONDARY_EXEC_UNRESTRICTED_GUEST;
 
-/* Start in 64-bit mode. PVH 32bitfixme. */
-vmentry_ctl |= VM_ENTRY_IA32E_MODE;   /* GUEST_EFER.LME/LMA 
ignored */
-
 ASSERT(v->arch.hvm_vmx.exec_control & 
CPU_BASED_ACTIVATE_SECONDARY_CONTROLS);
 ASSERT(v->arch.hvm_vmx.exec_control & CPU_BASED_ACTIVATE_MSR_BITMAP);
 ASSERT(!(v->arch.hvm_vmx.exec_control & CPU_BASED_RDTSC_EXITING));
@@ -1124,11 +1121,7 @@ static int construct_vmcs(struct vcpu *v)
 __vmwrite(GUEST_DS_AR_BYTES, 0xc093);
 __vmwrite(GUEST_FS_AR_BYTES,

[Xen-devel] [PATCH 1/9] x86/pvh: Don't test 64b-only vcpu_guest_context's fields

vcpu_guest_context's fs_base, gs_base_kernel and gs_base_user are not defined
for 32-bit guests.

Drop PVH 32bitfixme ASSERT.

Signed-off-by: Boris Ostrovsky 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

---
 xen/arch/x86/domain.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0363650..e396c6c 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -769,16 +769,14 @@ int arch_set_info_guest(
 }
 else if ( is_pvh_domain(d) )
 {
-/* PVH 32bitfixme */
-ASSERT(!compat);
-
 if ( c(ctrlreg[0]) || c(ctrlreg[1]) || c(ctrlreg[2]) ||
  c(ctrlreg[4]) || c(ctrlreg[5]) || c(ctrlreg[6]) ||
  c(ctrlreg[7]) ||  c(ldt_base) || c(ldt_ents) ||
  c(user_regs.cs) || c(user_regs.ss) || c(user_regs.es) ||
  c(user_regs.ds) || c(user_regs.fs) || c(user_regs.gs) ||
- c(kernel_ss) || c(kernel_sp) || c.nat->gs_base_kernel ||
- c.nat->gdt_ents || c.nat->fs_base || c.nat->gs_base_user )
+ c(kernel_ss) || c(kernel_sp) || c(gdt_ents) ||
+ (!compat && (c.nat->gs_base_kernel ||
+  c.nat->fs_base || c.nat->gs_base_user)) )
 return -EINVAL;
 }
 
-- 
1.7.1


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

[Xen-devel] [PATCH 0/9] 32-bit domU PVH support

Initial 32-bit PVH support, dom0 will need more work.

Boris Ostrovsky (9):
  x86/pvh: Don't test 64b-only vcpu_guest_context's fields
  x86/pvh: Don't copy to/from trap_ctxt for 32b PVH guests
  x86/pvh: Properly initialize PVH guest's CR3
  x86/compat: Manage argument translation area separately from l4
  x86/pvh: Set PVH guest's mode in XEN_DOMCTL_set_address_size
  x86/pvh: Properly set HYPERVISOR_COMPAT_VIRT_START for PVH guests
  x86/pvh: Handle hypercalls for 32b PVH guests
  x86/pvh: Don't try to get l4 table for PVH guests in
vcpu_destroy_pagetables()
  libxc/x86/pvh: Allow creation of 32b PVH guests

 tools/libxc/xc_dom_x86.c  |   32 +++
 xen/arch/x86/domain.c |   84 ++--
 xen/arch/x86/domain_build.c   |7 +++
 xen/arch/x86/domctl.c |9 +++-
 xen/arch/x86/hvm/hvm.c|   54 +-
 xen/arch/x86/hvm/vmx/vmcs.c   |9 +
 xen/arch/x86/hvm/vmx/vmx.c|   17 
 xen/arch/x86/mm.c |2 +-
 xen/include/asm-x86/hvm/hvm.h |2 +
 9 files changed, 146 insertions(+), 70 deletions(-)


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

[Xen-devel] [PATCH 1/9] x86/pvh: Don't test 64b-only vcpu_guest_context's fields

vcpu_guest_context's fs_base, gs_base_kernel and gs_base_user are not defined
for 32-bit guests.

Drop PVH 32bitfixme ASSERT.

Signed-off-by: Boris Ostrovsky 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

---
 xen/arch/x86/domain.c |8 +++-
 1 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0363650..e396c6c 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -769,16 +769,14 @@ int arch_set_info_guest(
 }
 else if ( is_pvh_domain(d) )
 {
-/* PVH 32bitfixme */
-ASSERT(!compat);
-
 if ( c(ctrlreg[0]) || c(ctrlreg[1]) || c(ctrlreg[2]) ||
  c(ctrlreg[4]) || c(ctrlreg[5]) || c(ctrlreg[6]) ||
  c(ctrlreg[7]) ||  c(ldt_base) || c(ldt_ents) ||
  c(user_regs.cs) || c(user_regs.ss) || c(user_regs.es) ||
  c(user_regs.ds) || c(user_regs.fs) || c(user_regs.gs) ||
- c(kernel_ss) || c(kernel_sp) || c.nat->gs_base_kernel ||
- c.nat->gdt_ents || c.nat->fs_base || c.nat->gs_base_user )
+ c(kernel_ss) || c(kernel_sp) || c(gdt_ents) ||
+ (!compat && (c.nat->gs_base_kernel ||
+  c.nat->fs_base || c.nat->gs_base_user)) )
 return -EINVAL;
 }
 
-- 
1.7.1


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

[Xen-devel] [PATCH 7/9] x86/pvh: Handle hypercalls for 32b PVH guests

Signed-off-by: Boris Ostrovsky 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 

---
 xen/arch/x86/hvm/hvm.c |   35 +--
 1 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c3c129d..12f6839 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4910,7 +4910,6 @@ static hvm_hypercall_t *const 
hvm_hypercall32_table[NR_hypercalls] = {
 [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
 };
 
-/* PVH 32bitfixme. */
 static hvm_hypercall_t *const pvh_hypercall64_table[NR_hypercalls] = {
 HYPERCALL(platform_op),
 HYPERCALL(memory_op),
@@ -4929,6 +4928,27 @@ static hvm_hypercall_t *const 
pvh_hypercall64_table[NR_hypercalls] = {
 [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
 };
 
+extern void compat_mmuext_op(void); /* XXX: need proper declaration */
+static hvm_hypercall_t *const pvh_hypercall32_table[NR_hypercalls] = {
+HYPERCALL(platform_op),
+COMPAT_CALL(memory_op),
+HYPERCALL(xen_version),
+HYPERCALL(console_io),
+[ __HYPERVISOR_grant_table_op ]  =
+(hvm_hypercall_t *)hvm_grant_table_op_compat32,
+COMPAT_CALL(vcpu_op),
+COMPAT_CALL(mmuext_op),
+HYPERCALL(xsm_op),
+COMPAT_CALL(sched_op),
+HYPERCALL(event_channel_op),
+[ __HYPERVISOR_physdev_op ] = (hvm_hypercall_t *)hvm_physdev_op_compat32,
+HYPERCALL(hvm_op),
+HYPERCALL(sysctl),
+HYPERCALL(domctl),
+[ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
+};
+
+
 extern const uint8_t hypercall_args_table[], compat_hypercall_args_table[];
 
 int hvm_do_hypercall(struct cpu_user_regs *regs)
@@ -4959,8 +4979,10 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 return viridian_hypercall(regs);
 
 if ( (eax >= NR_hypercalls) ||
- (is_pvh_domain(currd) ? !pvh_hypercall64_table[eax]
-   : !hvm_hypercall32_table[eax]) )
+ (is_pvh_vcpu(curr) ? ((mode == 8) ?
+   !pvh_hypercall64_table[eax] :
+   !pvh_hypercall32_table[eax])
+: !hvm_hypercall32_table[eax]) )
 {
 regs->eax = -ENOSYS;
 return HVM_HCALL_completed;
@@ -5015,8 +5037,6 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 }
 #endif
 }
-else if ( unlikely(is_pvh_domain(currd)) )
-regs->_eax = -ENOSYS; /* PVH 32bitfixme. */
 else
 {
 unsigned int ebx = regs->_ebx;
@@ -5042,7 +5062,10 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 }
 #endif
 
-regs->_eax = hvm_hypercall32_table[eax](ebx, ecx, edx, esi, edi, ebp);
+regs->_eax = (is_pvh_vcpu(curr)
+  ? pvh_hypercall32_table
+  : hvm_hypercall32_table)[eax](ebx, ecx, edx,
+esi, edi, ebp);
 
 #ifndef NDEBUG
 if ( !curr->arch.hvm_vcpu.hcall_preempted )
-- 
1.7.1


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

[Xen-devel] [linux-next test] 58744: tolerable FAIL

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt  11 guest-start  fail   like 58620
 test-amd64-amd64-libvirt 11 guest-start  fail   like 58620
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   like 58620
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail   like 58620
 test-armhf-armhf-libvirt 11 guest-start  fail   like 58620
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58620
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 58620
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 58620

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 13 guest-saverestorefail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 20 leak-check/check fail 
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-cubietruck 12 migrate-support-checkfail never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 20 leak-check/check fail 
never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxc1ce6ea24e13fcdb61c75d7bb24377d11478b3c4
baseline version:
 linux0f57d86787d8b1076ea8f9cba2a46d534a27

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuser

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  14 guest-start.2 fail REGR. vs. 58620

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt  11 guest-start  fail   like 58620
 test-amd64-amd64-libvirt 11 guest-start  fail   like 58620
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 58620
 test-amd64-i386-freebsd10-amd64  9 freebsd-install fail like 58620
 test-amd64-i386-freebsd10-i386  9 freebsd-install  fail like 58620
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   like 58620
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail   like 58620
 test-armhf-armhf-libvirt 11 guest-start  fail   like 58620
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 58620
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58620

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 13 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 20 leak-check/check fail 
never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 20 leak-check/check fail 
never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxe640a280ccb9c448a3d9d522ea730ce00efa8cf0
baseline version:
 linux0f57d86787d8b1076ea8f9cba2a46d534a27


People who touched revisions under test:
  Andrew Morton 
  Hans Verkuil 
  Herbert Xu 
  Hugh Dickins 
  Laurent Pinchart 
  Linus Torvalds 
  Marcelo Tosatti 
  Mauro Carvalho Chehab 
  Radim KrÄmÃ¡Å 
  Steve Cornelius 
  Steven Rostedt 
  Victoria Milhoan 
  Vince Weaver 
  Wolfram Sang 
  Wolfram Sang 


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-am

Re: [Xen-devel] [PATCH 1/2 linux-next] Revert "ufs: fix deadlocks introduced by sb mutex merge"

2015-06-19 Thread Al Viro

On Wed, Jun 17, 2015 at 09:31:16PM +0100, Al Viro wrote:
> On Wed, Jun 17, 2015 at 10:57:15AM +0200, Jan Kara wrote:
> > > Joy...  Folks, is anybody actively maintaining fs/ufs these days?
> > 
> > Looking into the changelog there wasn't anyone seriously looking into UFS
> > for at least 5-6 years... Fabian did some cleanups recently but they were
> > mostly cosmetic. So I don't think it's really maintained. OTOH clearly
> > there are some users since occasionally someone comes with a bug report.
> > Welcome to the world where we have ~50 on disk / network filesystems :-|
> 
> FWIW, I've a partial rewrite of that area (completely untested, etc.)
> in vfs.git#ufs; it's still in progress, but hopefully it'll be done
> by tomorrow.  Basically, it switches the sucker to locking scheme
> similar to ext2 (modulo seqlock instead of rwlock for protection of
> block pointers, having to be more careful due to 64bit assignments not
> being atomic and being unable to fall back to ->truncate_mutex in
> case of race on the read side) and starts cleaning the hell out of
> the truncate (and eventually create side of get_block as well).
> 
> As far as I can see, the root of the problems with that sucker is the
> misplaced handling of tail-packing logics.  That had ballooned into
> a lot of convoluted codepaths ;-/  I'm not blaming Evgeniy - it *is*
> painful to massage into saner shape and the damn thing kept missing
> cleanups that were done to similar filesystems due to that...
> 
> One thing I'm somewhat unhappy about in what Evgeniy had done is dealing with
> UFS vs. UFS2 differences at such a low level.  Sure, the way we did endianness
> handling in there provoked exactly that, but it might have been better to
> go the other way round; see e.g. fs/minix/itree*.c for opposite approach.
> 
> All this stuff is currently completely untested; I'll be using generic
> parts of xfstests for beating it up, but any assistance would be welcome.
> Note: all testing I'll be realistically able to do will be for FreeBSD
> UFS variants - I don't have Solaris left on any boxen, to start with...

FWIW, I've got to one bloody unpleasant part of UFS we'd never managed to
get right and it seems that I have a potential solution.

Problem: UFS has larger-than-page allocation units.  And when we allocate
a block in a hole, we *must* zero the whole thing out.  The trouble being,
we notice that inside writepage(), where we are already holding a lock on
our page and where we can't lock other pages without risking a deadlock.

What's more, as soon as we'd inserted a reference to that block into inode,
we are open to readpage on another page backed by the same block coming
and seeing a normal mapped area.  So UFS block allocator ends up zeroing
them out via _buffer_ cache, waiting for writes to finish before returning
the block to caller.  It doesn't wait for metadata blocks (they are accessed
via buffer cache), but for data we end up with zeroes being written to disk,
no matter what.

That works, but it obviously hurts the performance.  Badly.  Writes into
a hole are relatively rare, but the same thing hurts normal sequential
writes to the end of file, which is not rare at all.

How about the following approach:
* Let allocation of data block at the EOF return the sucker without
writing zeroes out.
* Let ->write_iter() check if it's about to create a hole at the
(current) EOF.  In such case start with writing zeroes (in normal fashion,
via ->begin_write()/memset()/->end_write() through the page cache) from the
EOF to block boundary (or beginning of the area we were going to write to,
whichever's closer).  Then proceed in normal fashion.  Incidentally, it will
deal with tail unpacking for free.
* Do the same upon extending truncate.

Does anybody see holes in that?  readpage() crossing the EOF isn't a problem -
it will not even attempt to map past the current ->i_size and will zero the
page tail out just fine.  We get junk past the EOF on disk, but we zero it
out (or overwrite with our data) before increasing ->i_size.

Dealing with sparse files is also possible (taking allocations from
->writepage() to ->page_mkwrite(), where we are not holding a page lock
and thus can grab all affected pages), but it would be bigger, trickier
and benefit only a relatively rare case.

Comments?

PS: UFS tail unpacking is broken - in some cases it can be tricked into
trying to extend an indirect block, of all things, and that's not the
only fishy case in there.  I think I've fixed that crap in the local tree...

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

[Xen-devel] [PATCH v7 9/9] video: fbdev: vt8623fb: use arch_phys_wc_add() and pci_iomap_wc()

From: "Luis R. Rodriguez" 

This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Rob Clark 
Cc: Laurent Pinchart 
Cc: Jingoo Han 
Cc: "Lad, Prabhakar" 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Tomi Valkeinen 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/video/fbdev/vt8623fb.c | 31 ++-
 1 file changed, 6 insertions(+), 25 deletions(-)

diff --git a/drivers/video/fbdev/vt8623fb.c b/drivers/video/fbdev/vt8623fb.c
index ea7f056..60f24828 100644
--- a/drivers/video/fbdev/vt8623fb.c
+++ b/drivers/video/fbdev/vt8623fb.c
@@ -26,13 +26,9 @@
 #include  /* Why should fb driver call console functions? 
because console_lock() */
 #include 
 
-#ifdef CONFIG_MTRR
-#include 
-#endif
-
 struct vt8623fb_info {
char __iomem *mmio_base;
-   int mtrr_reg;
+   int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -99,10 +95,7 @@ static struct svga_timing_regs vt8623_timing_regs = {
 /* Module parameters */
 
 static char *mode_option = "640x480-8@60";
-
-#ifdef CONFIG_MTRR
 static int mtrr = 1;
-#endif
 
 MODULE_AUTHOR("(c) 2006 Ondrej Zajicek ");
 MODULE_LICENSE("GPL");
@@ -112,11 +105,8 @@ module_param(mode_option, charp, 0644);
 MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
 module_param_named(mode, mode_option, charp, 0);
 MODULE_PARM_DESC(mode, "Default video mode e.g. '648x480-8@60' (deprecated)");
-
-#ifdef CONFIG_MTRR
 module_param(mtrr, int, 0444);
 MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable, 
default=1)");
-#endif
 
 
 /* - */
@@ -710,7 +700,7 @@ static int vt8623_pci_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
info->fix.mmio_len = pci_resource_len(dev, 1);
 
/* Map physical IO memory address into kernel space */
-   info->screen_base = pci_iomap(dev, 0, 0);
+   info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -781,12 +771,9 @@ static int vt8623_pci_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
 
-#ifdef CONFIG_MTRR
-   if (mtrr) {
-   par->mtrr_reg = -1;
-   par->mtrr_reg = mtrr_add(info->fix.smem_start, 
info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
-   }
-#endif
+   if (mtrr)
+   par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.

[Xen-devel] [PATCH v7 8/9] video: fbdev: s3fb: use arch_phys_wc_add() and pci_iomap_wc()

From: "Luis R. Rodriguez" 

This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Jingoo Han 
Cc: Geert Uytterhoeven 
Cc: Daniel Vetter 
Cc: "Lad, Prabhakar" 
Cc: Rickard Strandqvist 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Tomi Valkeinen 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/video/fbdev/s3fb.c | 35 ++-
 1 file changed, 6 insertions(+), 29 deletions(-)

diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index f0ae61a..13b1090 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -28,13 +28,9 @@
 #include 
 #include 
 
-#ifdef CONFIG_MTRR
-#include 
-#endif
-
 struct s3fb_info {
int chip, rev, mclk_freq;
-   int mtrr_reg;
+   int wc_cookie;
struct vgastate state;
struct mutex open_lock;
unsigned int ref_count;
@@ -154,11 +150,7 @@ static const struct svga_timing_regs s3_timing_regs = {
 
 
 static char *mode_option;
-
-#ifdef CONFIG_MTRR
 static int mtrr = 1;
-#endif
-
 static int fasttext = 1;
 
 
@@ -170,11 +162,8 @@ module_param(mode_option, charp, 0444);
 MODULE_PARM_DESC(mode_option, "Default video mode ('640x480-8@60', etc)");
 module_param_named(mode, mode_option, charp, 0444);
 MODULE_PARM_DESC(mode, "Default video mode ('640x480-8@60', etc) 
(deprecated)");
-
-#ifdef CONFIG_MTRR
 module_param(mtrr, int, 0444);
 MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable, 
default=1)");
-#endif
 
 module_param(fasttext, int, 0644);
 MODULE_PARM_DESC(fasttext, "Enable S3 fast text mode (1=enable, 0=disable, 
default=1)");
@@ -1168,7 +1157,7 @@ static int s3_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
info->fix.smem_len = pci_resource_len(dev, 0);
 
/* Map physical IO memory address into kernel space */
-   info->screen_base = pci_iomap(dev, 0, 0);
+   info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -1365,12 +1354,9 @@ static int s3_pci_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
 
-#ifdef CONFIG_MTRR
-   if (mtrr) {
-   par->mtrr_reg = -1;
-   par->mtrr_reg = mtrr_add(info->fix.smem_start, 
info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
-   }
-#endif
+   if (mtrr)
+   par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.smem_len);
 
return 0;
 
@@ -1405,14 +1391,7 @@ static void s3_pci_remove(struct pci_dev *dev)

[Xen-devel] [PATCH v7 7/9] video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc()

From: "Luis R. Rodriguez" 

Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Laurent Pinchart 
Cc: Geert Uytterhoeven 
Cc: "Lad, Prabhakar" 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Tomi Valkeinen 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/video/fbdev/arkfb.c | 36 +---
 1 file changed, 5 insertions(+), 31 deletions(-)

diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index b305a1e..6a317de 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -26,13 +26,9 @@
 #include  /* Why should fb driver call console functions? 
because console_lock() */
 #include 
 
-#ifdef CONFIG_MTRR
-#include 
-#endif
-
 struct arkfb_info {
int mclk_freq;
-   int mtrr_reg;
+   int wc_cookie;
 
struct dac_info *dac;
struct vgastate state;
@@ -102,10 +98,6 @@ static const struct svga_timing_regs ark_timing_regs = {
 
 static char *mode_option = "640x480-8@60";
 
-#ifdef CONFIG_MTRR
-static int mtrr = 1;
-#endif
-
 MODULE_AUTHOR("(c) 2007 Ondrej Zajicek ");
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("fbdev driver for ARK 2000PV");
@@ -115,11 +107,6 @@ MODULE_PARM_DESC(mode_option, "Default video mode 
('640x480-8@60', etc)");
 module_param_named(mode, mode_option, charp, 0444);
 MODULE_PARM_DESC(mode, "Default video mode ('640x480-8@60', etc) 
(deprecated)");
 
-#ifdef CONFIG_MTRR
-module_param(mtrr, int, 0444);
-MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable, 
default=1)");
-#endif
-
 static int threshold = 4;
 
 module_param(threshold, int, 0644);
@@ -1002,7 +989,7 @@ static int ark_pci_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
info->fix.smem_len = pci_resource_len(dev, 0);
 
/* Map physical IO memory address into kernel space */
-   info->screen_base = pci_iomap(dev, 0, 0);
+   info->screen_base = pci_iomap_wc(dev, 0, 0);
if (! info->screen_base) {
rc = -ENOMEM;
dev_err(info->device, "iomap for framebuffer failed\n");
@@ -1057,14 +1044,8 @@ static int ark_pci_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
 
/* Record a reference to the driver data */
pci_set_drvdata(dev, info);
-
-#ifdef CONFIG_MTRR
-   if (mtrr) {
-   par->mtrr_reg = -1;
-   par->mtrr_reg = mtrr_add(info->fix.smem_start, 
info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
-   }
-#endif
-
+   par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.smem_len);
return 0;
 
/* Error handling */
@@ -1092,14 +1073,7 @@ static void ark_pci_remove(struct pci_dev *dev)
 
if (info) {
struct ar

[Xen-devel] [PATCH v7 6/9] lib: devres: add pcim_iomap_wc() variants

From: "Luis R. Rodriguez" 

Now that we have pci_iomap_wc() add the respective devres helpers.

Cc: Toshi Kani 
Cc: Andy Lutomirski 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Bjorn Helgaas 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Dave Hansen 
Cc: Arnd Bergmann 
Cc: Michael S. Tsirkin 
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader 
Cc: Ville Syrjälä 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Borislav Petkov 
Cc: Davidlohr Bueso 
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: Roger Pau Monné 
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez 
---
 include/linux/pci.h |  2 ++
 lib/devres.c| 78 +
 2 files changed, 80 insertions(+)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 1193975..5ff15c1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1609,9 +1609,11 @@ static inline void pci_dev_specific_enable_acs(struct 
pci_dev *dev) { }
 #endif
 
 void __iomem *pcim_iomap(struct pci_dev *pdev, int bar, unsigned long maxlen);
+void __iomem *pcim_iomap_wc(struct pci_dev *pdev, int bar, unsigned long 
maxlen);
 void pcim_iounmap(struct pci_dev *pdev, void __iomem *addr);
 void __iomem * const *pcim_iomap_table(struct pci_dev *pdev);
 int pcim_iomap_regions(struct pci_dev *pdev, int mask, const char *name);
+int pcim_iomap_wc_regions(struct pci_dev *pdev, int mask, const char *name);
 int pcim_iomap_regions_request_all(struct pci_dev *pdev, int mask,
   const char *name);
 void pcim_iounmap_regions(struct pci_dev *pdev, int mask);
diff --git a/lib/devres.c b/lib/devres.c
index fbe2aac..d59a2b9 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -304,6 +304,30 @@ void __iomem *pcim_iomap(struct pci_dev *pdev, int bar, 
unsigned long maxlen)
 EXPORT_SYMBOL(pcim_iomap);
 
 /**
+ * pcim_iomap_wc - Managed pcim_iomap_wc()
+ * @pdev: PCI device to iomap for
+ * @bar: BAR to iomap
+ * @maxlen: Maximum length of iomap
+ *
+ * Managed pci_iomap_wc().  Map is automatically unmapped on driver
+ * detach.
+ */
+void __iomem *pcim_iomap_wc(struct pci_dev *pdev, int bar, unsigned long 
maxlen)
+{
+   void __iomem **tbl;
+
+   BUG_ON(bar >= PCIM_IOMAP_MAX);
+
+   tbl = (void __iomem **)pcim_iomap_table(pdev);
+   if (!tbl || tbl[bar])   /* duplicate mappings not allowed */
+   return NULL;
+
+   tbl[bar] = pci_iomap_wc(pdev, bar, maxlen);
+   return tbl[bar];
+}
+EXPORT_SYMBOL_GPL(pcim_iomap_wc);
+
+/**
  * pcim_iounmap - Managed pci_iounmap()
  * @pdev: PCI device to iounmap for
  * @addr: Address to unmap
@@ -383,6 +407,60 @@ int pcim_iomap_regions(struct pci_dev *pdev, int mask, 
const char *name)
 EXPORT_SYMBOL(pcim_iomap_regions);
 
 /**
+ * pcim_iomap_wc_regions - Request and iomap PCI BARs with write-combining
+ * @pdev: PCI device to map IO resources for
+ * @mask: Mask of BARs to request and iomap
+ * @name: Name used when requesting regions
+ *
+ * Request and iomap regions specified by @mask with a preference for
+ * write-combining.
+ */
+int pcim_iomap_wc_regions(struct pci_dev *pdev, int mask, const char *name)
+{
+   void __iomem * const *iomap;
+   int i, rc;
+
+   iomap = pcim_iomap_table(pdev);
+   if (!iomap)
+   return -ENOMEM;
+
+   for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+   unsigned long len;
+
+   if (!(mask & (1 << i)))
+   continue;
+
+   rc = -EINVAL;
+   len = pci_resource_len(pdev, i);
+   if (!len)
+   goto err_inval;
+
+   rc = pci_request_region(pdev, i, name);
+   if (rc)
+   goto err_inval;
+
+   rc = -ENOMEM;
+   if (!pcim_iomap_wc(pdev, i, 0))
+   goto err_region;
+   }
+
+   return 0;
+
+ err_region:
+   pci_release_region(pdev, i);
+ err_inval:
+   while (--i >= 0) {
+   if (!(mask & (1 << i)))
+   continue;
+   pcim_iounmap(pdev, iomap[i]);
+   pci_release_region(pdev, i);
+   }
+
+   return rc;
+}
+EXPORT_SYMBOL_GPL(pcim_iomap_wc_regions);
+
+/**
  * pcim_iomap_regions_request_all - Request all BARs and iomap specified ones
  * @pdev: PCI device to map IO resources for
  * @mask: Mask of BARs to iomap
-- 
2.3.2.209.gd67f9d5.dirty


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

[Xen-devel] [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants

From: "Luis R. Rodriguez" 

PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC).  WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general to use it on a prefetchable
region.

Add pci_iomap_wc() and pci_iomap_wc_range() so drivers can take advantage
of write combining when they know it's safe.

On architectures that don't fully support WC, e.g., x86 without PAT,
drivers for legacy framebuffers may get some of the benefit by using
arch_phys_wc_add() in addition to pci_iomap_wc().  But arch_phys_wc_add()
is unreliable and should be avoided in general.  On x86, it uses MTRRs,
which are limited in number and size, so the results will vary based on
driver loading order.

The goals of adding pci_iomap_wc() are to:

- Give drivers an architecture-independent way to use WC so they can stop
  using interfaces like mtrr_add() (on x86, pci_iomap_wc() uses
  PAT when available)

- Move toward using _PAGE_CACHE_MODE_UC, not _PAGE_CACHE_MODE_UC_MINUS,
  on x86 on ioremap_nocache() (see de33c442ed2a ("x86 PAT: fix
  performance drop for glx, use UC minus for ioremap(), ioremap_nocache()
  and pci_mmap_page_range()")

Link: 
http://lkml.kernel.org/r/1426893517-2511-6-git-send-email-mcg...@do-not-panic.com
Original-posting: 
http://lkml.kernel.org/r/1432163293-20965-1-git-send-email-mcg...@do-not-panic.com
Cc: Toshi Kani 
Cc: Andy Lutomirski 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Dave Airlie 
Cc: Bjorn Helgaas 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Dave Hansen 
Cc: Arnd Bergmann 
Cc: Michael S. Tsirkin 
Cc: venkatesh.pallip...@intel.com
Cc: Stefan Bader 
Cc: Ville Syrjälä 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Borislav Petkov 
Cc: Davidlohr Bueso 
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: Roger Pau Monné 
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez 
---
 include/asm-generic/pci_iomap.h | 14 ++
 lib/pci_iomap.c | 61 +
 2 files changed, 75 insertions(+)

diff --git a/include/asm-generic/pci_iomap.h b/include/asm-generic/pci_iomap.h
index 7389c87..b1e17fc 100644
--- a/include/asm-generic/pci_iomap.h
+++ b/include/asm-generic/pci_iomap.h
@@ -15,9 +15,13 @@ struct pci_dev;
 #ifdef CONFIG_PCI
 /* Create a virtual mapping cookie for a PCI BAR (memory or IO) */
 extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long 
max);
+extern void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, unsigned long 
max);
 extern void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
 unsigned long offset,
 unsigned long maxlen);
+extern void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+   unsigned long offset,
+   unsigned long maxlen);
 /* Create a virtual mapping cookie for a port on a given PCI device.
  * Do not call this directly, it exists to make it easier for architectures
  * to override */
@@ -34,12 +38,22 @@ static inline void __iomem *pci_iomap(struct pci_dev *dev, 
int bar, unsigned lon
return NULL;
 }
 
+static inline void __iomem *pci_iomap_wc(struct pci_dev *dev, int bar, 
unsigned long max)
+{
+   return NULL;
+}
 static inline void __iomem *pci_iomap_range(struct pci_dev *dev, int bar,
unsigned long offset,
unsigned long maxlen)
 {
return NULL;
 }
+static inline void __iomem *pci_iomap_wc_range(struct pci_dev *dev, int bar,
+  unsigned long offset,
+  unsigned long maxlen)
+{
+   return NULL;
+}
 #endif
 
 #endif /* __ASM_GENERIC_IO_H */
diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
index bcce5f1..9604dcb 100644
--- a/lib/pci_iomap.c
+++ b/lib/pci_iomap.c
@@ -52,6 +52,46 @@ void __iomem *pci_iomap_range(struct pci_dev *dev,
 EXPORT_SYMBOL(pci_iomap_range);
 
 /**
+ * pci_iomap_wc_range - create a virtual WC mapping cookie for a PCI BAR
+ * @dev: PCI device that owns the BAR
+ * @bar: BAR number
+ * @offset: map memory at the given offset in BAR
+ * @maxlen: max length of the memory to map
+ *
+ * Using this function you will get a __iomem address to your device BAR.
+ * You can access it using ioread*() and iowrite*(). These functions hide
+ * the details if this is a MMIO or PIO address space and will just do what
+ * you expect from them in the correct way. When possible write combining
+ * is used.
+ *
+ * @maxlen specifies the maximum length to map. If you want to get access to
+ * the complete BAR from offset to the end, pass %0 here.
+ *

[Xen-devel] [PATCH v7 4/9] video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer

From: "Luis R. Rodriguez" 

The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.

In this case there are a few motivations for this:

a) Take advantage of PAT when available

b) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

Cc: Laurent Pinchart 
Cc: Rob Clark 
Cc: Geert Uytterhoeven 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Tomi Valkeinen 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/video/fbdev/gxt4500.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 135d78a..f19133a 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -662,7 +662,7 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
info->fix.smem_start = fb_phys;
info->fix.smem_len = pci_resource_len(pdev, 1);
-   info->screen_base = pci_ioremap_bar(pdev, 1);
+   info->screen_base = pci_ioremap_wc_bar(pdev, 1);
if (!info->screen_base) {
dev_err(&pdev->dev, "gxt4500: cannot map framebuffer\n");
goto err_unmap_regs;
-- 
2.3.2.209.gd67f9d5.dirty


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

[Xen-devel] [PATCH v7 3/9] video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar()

From: "Luis R. Rodriguez" 

Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Jingoo Han 
Cc: Geert Uytterhoeven 
Cc: Laurent Pinchart 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Tomi Valkeinen 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/video/fbdev/kyro/fbdev.c | 33 +++--
 include/video/kyro.h |  4 +---
 2 files changed, 12 insertions(+), 25 deletions(-)

diff --git a/drivers/video/fbdev/kyro/fbdev.c b/drivers/video/fbdev/kyro/fbdev.c
index 65041e1..5bb0153 100644
--- a/drivers/video/fbdev/kyro/fbdev.c
+++ b/drivers/video/fbdev/kyro/fbdev.c
@@ -22,9 +22,6 @@
 #include 
 #include 
 #include 
-#ifdef CONFIG_MTRR
-#include 
-#endif
 
 #include 
 
@@ -84,9 +81,7 @@ static device_info_t deviceInfo;
 static char *mode_option = NULL;
 static int nopan = 0;
 static int nowrap = 1;
-#ifdef CONFIG_MTRR
 static int nomtrr = 0;
-#endif
 
 /* PCI driver prototypes */
 static int kyrofb_probe(struct pci_dev *pdev, const struct pci_device_id *ent);
@@ -570,10 +565,8 @@ static int __init kyrofb_setup(char *options)
nopan = 1;
} else if (strcmp(this_opt, "nowrap") == 0) {
nowrap = 1;
-#ifdef CONFIG_MTRR
} else if (strcmp(this_opt, "nomtrr") == 0) {
nomtrr = 1;
-#endif
} else {
mode_option = this_opt;
}
@@ -691,17 +684,16 @@ static int kyrofb_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
currentpar->regbase = deviceInfo.pSTGReg =
ioremap_nocache(kyro_fix.mmio_start, kyro_fix.mmio_len);
+   if (!currentpar->regbase)
+   goto out_free_fb;
 
-   info->screen_base = ioremap_nocache(kyro_fix.smem_start,
-   kyro_fix.smem_len);
+   info->screen_base = pci_ioremap_wc_bar(pdev, 0);
+   if (!info->screen_base)
+   goto out_unmap_regs;
 
-#ifdef CONFIG_MTRR
if (!nomtrr)
-   currentpar->mtrr_handle =
-   mtrr_add(kyro_fix.smem_start,
-kyro_fix.smem_len,
-MTRR_TYPE_WRCOMB, 1);
-#endif
+   currentpar->wc_cookie = arch_phys_wc_add(kyro_fix.smem_start,
+kyro_fix.smem_len);
 
kyro_fix.ypanstep   = nopan ? 0 : 1;
kyro_fix.ywrapstep  = nowrap ? 0 : 1;
@@ -745,8 +737,10 @@ static int kyrofb_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
return 0;
 
 out_unmap:
-   iounmap(currentpar->regbase);
iounmap(info->screen_base);
+out_unmap_regs:
+   iounmap(currentpar->regbase);
+out_free_fb:

[Xen-devel] [PATCH v7 2/9] video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()

From: "Luis R. Rodriguez" 

Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining.

There are a few motivations for this:

a) Take advantage of PAT when available

b) Help bury MTRR code away, MTRR is architecture specific and on
   x86 its replaced by PAT

c) Help with the goal of eventually using _PAGE_CACHE_UC over
   _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
   de33c442e titled "x86 PAT: fix performance drop for glx,
   use UC minus for ioremap(), ioremap_nocache() and
   pci_mmap_page_range()")

The conversion done is expressed by the following Coccinelle
SmPL patch, it additionally required manual intervention to
address all the #ifdery and removal of redundant things which
arch_phys_wc_add() already addresses such as verbose message
about when MTRR fails and doing nothing when we didn't get
an MTRR.

@ mtrr_found @
expression index, base, size;
@@

-index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
+index = arch_phys_wc_add(base, size);

@ mtrr_rm depends on mtrr_found @
expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
@@

-mtrr_del(index, base, size);
+arch_phys_wc_del(index);

@ mtrr_rm_zero_arg depends on mtrr_found @
expression mtrr_found.index;
@@

-mtrr_del(index, 0, 0);
+arch_phys_wc_del(index);

@ mtrr_rm_fb_info depends on mtrr_found @
struct fb_info *info;
expression mtrr_found.index;
@@

-mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
+arch_phys_wc_del(index);

@ ioremap_replace_nocache depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap_nocache(base, size);
+info->screen_base = ioremap_wc(base, size);

@ ioremap_replace_default depends on mtrr_found @
struct fb_info *info;
expression base, size;
@@

-info->screen_base = ioremap(base, size);
+info->screen_base = ioremap_wc(base, size);

Generated-by: Coccinelle SmPL
Cc: Jingoo Han 
Cc: Bjorn Helgaas 
Cc: Geert Uytterhoeven 
Cc: Rob Clark 
Cc: Benoit Taine 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Tomi Valkeinen 
Signed-off-by: Luis R. Rodriguez 
---
 drivers/video/fbdev/i740fb.c | 35 ++-
 1 file changed, 6 insertions(+), 29 deletions(-)

diff --git a/drivers/video/fbdev/i740fb.c b/drivers/video/fbdev/i740fb.c
index a2b4204..452e116 100644
--- a/drivers/video/fbdev/i740fb.c
+++ b/drivers/video/fbdev/i740fb.c
@@ -27,24 +27,15 @@
 #include 
 #include 
 
-#ifdef CONFIG_MTRR
-#include 
-#endif
-
 #include "i740_reg.h"
 
 static char *mode_option;
-
-#ifdef CONFIG_MTRR
 static int mtrr = 1;
-#endif
 
 struct i740fb_par {
unsigned char __iomem *regs;
bool has_sgram;
-#ifdef CONFIG_MTRR
-   int mtrr_reg;
-#endif
+   int wc_cookie;
bool ddc_registered;
struct i2c_adapter ddc_adapter;
struct i2c_algo_bit_data ddc_algo;
@@ -1040,7 +1031,7 @@ static int i740fb_probe(struct pci_dev *dev, const struct 
pci_device_id *ent)
goto err_request_regions;
}
 
-   info->screen_base = pci_ioremap_bar(dev, 0);
+   info->screen_base = pci_ioremap_wc_bar(dev, 0);
if (!info->screen_base) {
dev_err(info->device, "error remapping base\n");
ret = -ENOMEM;
@@ -1144,13 +1135,9 @@ static int i740fb_probe(struct pci_dev *dev, const 
struct pci_device_id *ent)
 
fb_info(info, "%s frame buffer device\n", info->fix.id);
pci_set_drvdata(dev, info);
-#ifdef CONFIG_MTRR
-   if (mtrr) {
-   par->mtrr_reg = -1;
-   par->mtrr_reg = mtrr_add(info->fix.smem_start,
-   info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
-   }
-#endif
+   if (mtrr)
+   par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.smem_len);
return 0;
 
 err_reg_framebuffer:
@@ -1177,13 +1164,7 @@ static void i740fb_remove(struct pci_dev *dev)
 
if (info) {
struct i740fb_par *par = info->par;
-
-#ifdef CONFIG_MTRR
-   if (par->mtrr_reg >= 0) {
-   mtrr_del(par->mtrr_reg, 0, 0);
-   par->mtrr_reg = -1;
-   }
-#endif
+   arch_phys_wc_del(par->wc_cookie);
unregister_framebuffer(info);
fb_dealloc_cmap(&info->cmap);
if (par->ddc_registered)
@@ -1287,10 +1268,8 @@ static int  __init i740fb_setup(char *options)
while ((opt = strsep(&options, ",")) != NULL) {
if (!*opt)
continue;

[Xen-devel] [PATCH v7 1/9] pci: add pci_ioremap_wc_bar()

From: "Luis R. Rodriguez" 

This lets drivers take advantage of PAT when available. This
should help with the transition of converting video drivers over
to ioremap_wc() to help with the goal of eventually using
_PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
ioremap_nocache() (de33c442e titled "x86 PAT: fix performance
drop for glx, use UC minus for ioremap(), ioremap_nocache() and
pci_mmap_page_range()")

Cc: Toshi Kani 
Cc: Bjorn Helgaas 
Cc: Suresh Siddha 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Juergen Gross 
Cc: Daniel Vetter 
Cc: Andy Lutomirski 
Cc: Dave Airlie 
Cc: Antonino Daplas 
Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: Ville Syrjälä 
Cc: Mel Gorman 
Cc: Vlastimil Babka 
Cc: Borislav Petkov 
Cc: Davidlohr Bueso 
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez 
---
 drivers/pci/pci.c   | 14 ++
 include/linux/pci.h |  1 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 0008c95..fdae37b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -138,6 +138,20 @@ void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int 
bar)
return ioremap_nocache(res->start, resource_size(res));
 }
 EXPORT_SYMBOL_GPL(pci_ioremap_bar);
+
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar)
+{
+   /*
+* Make sure the BAR is actually a memory resource, not an IO resource
+*/
+   if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) {
+   WARN_ON(1);
+   return NULL;
+   }
+   return ioremap_wc(pci_resource_start(pdev, bar),
+ pci_resource_len(pdev, bar));
+}
+EXPORT_SYMBOL_GPL(pci_ioremap_wc_bar);
 #endif
 
 #define PCI_FIND_CAP_TTL   48
diff --git a/include/linux/pci.h b/include/linux/pci.h
index c0dd4ab..1193975 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1657,6 +1657,7 @@ static inline void pci_mmcfg_late_init(void) { }
 int pci_ext_cfg_avail(void);
 
 void __iomem *pci_ioremap_bar(struct pci_dev *pdev, int bar);
+void __iomem *pci_ioremap_wc_bar(struct pci_dev *pdev, int bar);
 
 #ifdef CONFIG_PCI_IOV
 int pci_iov_virtfn_bus(struct pci_dev *dev, int id);
-- 
2.3.2.209.gd67f9d5.dirty


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

[Xen-devel] [PATCH v7 0/9] pci: add pci_iomap_wc() and pci_ioremap_wc_bar()

From: "Luis R. Rodriguez" 

Arnd,

After a long-winded conversation with Bjorn over use of
EXPORT_SYMBOL_GPL() instead of EXPORT_SYMBOL() he's noted he'd
be OK if this goes through you as an alternative. This series
goes unmodified from the last posted v6 series, I am just
reposting and addressing this to you now in hopes you might
be comfortable with my use of EXPORT_SYMBOL_GPL() on new
PAT interfaces. I use EXPORT_SYMBOL_GPL() for new PAT symbols,
this parallels Ingo's stated preference as "we don't want
proprietary modules mucking around with new code PAT interfaces,
we only want modules we can analyze and fix in detail" [1].
Other than this Bjorn seemed comfortable with the series and
even had provided an Ack to the series, the EXPORT_SYMBOL_GPL()
thing was the ony thing he was not comfortable with, and also
that of the devres change going in with no users yet.

Tomi has already Ack'd the framebuffer driver specific changes
and is comfortable with the driver changes to go through the
tree that the depending symbols depend on.

I typically had submitted two series for these patches but since
the patches are all related and now already Acked I've bundled
them together and rebased them on top of today's linux-next tree.
This series is part of a larger effort to help avoid direct use
of MTRR code and instead replace it with more generic PAT
interfaces, I posted a full description of the entire series
recently [2].

Please let me know if there are any issues.

[0] 
http://lkml.kernel.org/r/caerspo7cnh1wpgqjceu8etxifnp_piq3cbwnkiwqpuad-fd...@mail.gmail.com
[1] http://article.gmane.org/gmane.linux.kernel.mm/129104
[2] 
http://lkml.kernel.org/r/CAB=NE6UgtdSoBsA=8+ueyrazhdnwusmqaohhaaefqudbrsy...@mail.gmail.com

Luis R. Rodriguez (9):
  pci: add pci_ioremap_wc_bar()
  video: fbdev: i740fb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
  video: fbdev: kyrofb: use arch_phys_wc_add() and pci_ioremap_wc_bar()
  video: fbdev: gxt4500: use pci_ioremap_wc_bar() for framebuffer
  PCI: Add pci_iomap_wc() variants
  lib: devres: add pcim_iomap_wc() variants
  video: fbdev: arkfb: use arch_phys_wc_add() and pci_iomap_wc()
  video: fbdev: s3fb: use arch_phys_wc_add() and pci_iomap_wc()
  video: fbdev: vt8623fb: use arch_phys_wc_add() and pci_iomap_wc()

 drivers/pci/pci.c| 14 
 drivers/video/fbdev/arkfb.c  | 36 +++
 drivers/video/fbdev/gxt4500.c|  2 +-
 drivers/video/fbdev/i740fb.c | 35 --
 drivers/video/fbdev/kyro/fbdev.c | 33 ++---
 drivers/video/fbdev/s3fb.c   | 35 --
 drivers/video/fbdev/vt8623fb.c   | 31 
 include/asm-generic/pci_iomap.h  | 14 
 include/linux/pci.h  |  3 ++
 include/video/kyro.h |  4 +--
 lib/devres.c | 78 
 lib/pci_iomap.c  | 61 +++
 12 files changed, 206 insertions(+), 140 deletions(-)

-- 
2.3.2.209.gd67f9d5.dirty


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

[Xen-devel] [xen-4.2-testing test] 58736: FAIL

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt  3 host-install(3) broken in 58584 REGR. vs. 58411

Tests which are failing intermittently (not blocking):
 test-i386-i386-libvirt3 host-install(3)  broken in 58584 pass in 58736
 test-amd64-i386-pair  4 host-install/dst_host(4) broken in 58584 pass in 58736
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 58584 pass in 58736
 test-amd64-i386-qemuu-freebsd10-amd64 3 host-install(3) broken in 58584 pass 
in 58736
 test-amd64-i386-xl-win7-amd64  3 host-install(3) broken in 58584 pass in 58736
 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 58584 pass in 
58736
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 58584 pass in 
58736
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot   fail in 58584 pass in 58736
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 58584 
pass in 58736
 test-amd64-amd64-xl-win7-amd64 16 guest-stopfail pass in 58584
 test-i386-i386-pv11 guest-start fail pass in 58722
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-localmigrate.2 fail pass in 
58722

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt  1 build-check(1)blocked in 58584 n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 build-amd64-rumpuserxen   5 rumpuserxen-buildfail   never pass
 build-i386-rumpuserxen5 rumpuserxen-buildfail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-i386-i386-libvirt   12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xend-winxpsp3 20 leak-check/check fail  never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass

version targeted for testing:
 xen  97134c441d6d81ba0d7cdcfdc4d8315115b99dce
baseline version:
 xen  21a8344ca38a2797a13b4bf57031b6f49ae12ccb


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Stefano Stabellini 


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-i386-i386-xlpass
 test-amd64-i386-rhel6hvm-amd pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-qemuu-freebsd10-amd64pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64

Re: [Xen-devel] [PATCH v6 1/4] pci: add pci_iomap_wc() variants

2015-06-19 Thread Bjorn Helgaas

On Fri, Jun 19, 2015 at 4:06 PM, Luis R. Rodriguez
 wrote:

> I hope to have provided a bit of new information to help you
> reconsider this series to go through you but since you seem to be fine
> for this to go through another tree and since I failed to notice that
> I should also get Arnd's Ack I am in hopes this might be able to go
> through Arnd's tree if not through you. Please let me know, in case I
> have to resubmit to Arnd.

If you want to have Arnd merge it, that's fine with me.

Bjorn

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

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

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   like 58713
 test-amd64-i386-libvirt  11 guest-start  fail   like 58713
 test-armhf-armhf-libvirt 11 guest-start  fail   like 58713
 test-amd64-amd64-libvirt 11 guest-start  fail   like 58713

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  5c9fc1c11fb54236576c2bff40e6e3df1e710983
baseline version:
 libvirt  307081796ee07d5f47e1fef66766de82d5fce642


People who touched revisions under test:
  James Cowgill 
  Jiri Denemark 
  John Ferlan 
  JÃ¡n Tomko 
  Luyao Huang 
  Michal Privoznik 
  Mikhail Feoktistov 
  Pavel Boldin 
  Peter Krempa 


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-libvirt fail
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  fail



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

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

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


Pushing revision :

+ branch=libvirt
+ revision=5c9fc1c11fb54236576c2bff40e6e3df1e710983
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ 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 libvirt 
5c9fc1c11fb54236576c2bff40e6e3df1e710983
+ branch=libvirt
+ revision=5c9fc1c11fb54236576c2bff40e6e3df1e710983
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
++ 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=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : 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/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.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

Re: [Xen-devel] [PATCH v6 1/4] pci: add pci_iomap_wc() variants

On Tue, Jun 16, 2015 at 3:20 PM, Bjorn Helgaas  wrote:
> On Tue, Jun 16, 2015 at 2:16 PM, Luis R. Rodriguez
>  wrote:
>> On Thu, May 28, 2015 at 5:36 PM, Luis R. Rodriguez
>>  wrote:
>>> On Wed, May 27, 2015 at 1:04 PM, Luis R. Rodriguez  wrote:
 On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote:
> On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote:
> > On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote:
> > >
> > > I tentatively put this (and the rest of the series) on a pci/resource
> > > branch.  I'm hoping you'll propose some clarification about
> > > EXPORT_SYMBOL_GPL().
> >
> > EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can
> > only run that code. So for instance although we have "Dual BSD/GPL"
> > tags for modules pure "BSD" tags do not exist for module tags and
> > cannot run EXPORT_SYMBOL_GPL() code [0]. Also there is some folks
> > who do believe tha at run time all kernel modules are GPL [1] [2].
> > And to be precise even though the FSF may claim a list of licenses
> > are GPL-compatible we cannot rely on this list alone for our own
> > goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must
> > discuss this on lkml [2].
>
> By "propose some clarification," I meant that I hoped you would propose a
> patch to Documentation/ that would give maintainers some guidance.

 I *really really* would hate to do so but only because you insist, I'll 
 look
 into this...
>>>
>>> OK done.
>>
>> Bjorn,
>>
>> This is now on Jonathan Corbet's tree and visible on linux-next:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=582ed8d51e2b6cb8a168c94852bca482685c2509
>
> Sorry, I'm just not comfortable with using EXPORT_SYMBOL_GPL() this
> way.  I'm happy to use it when it has a technical justification, e.g.,
> for internal interfaces where users of the interface are clearly
> derived works.

I believe it is completely fair for some maintainers to take the
position of what the documentation used to say prior to the new
documentation patch on queue for v4.2, but note that that is an old
position and I seriously caution against it. A few reasons I caution
against it:

1)  It used to be believed that EXPORT_SYMBOL_GPL() was pretty
pointless by many maintainers and developers -- in particular for all
those who have always written even EXPORT_SYMBOL() code with the same
intent as EXPORT_SYMBOL_GPL(). Experience and comments with attorneys
even on Linus' part reflects that there is a huge legal value to
EXPORT_SYMBOL_GPL() [0].

The skinny: Intent matters a lot and "circumventing a GPL-only export
requires an explicit action, making it clear that the resulting
copyright infringement was a deliberate act".

Naturally lax positions on the matter over use of EXPORT_SYMBOL_GPL()
have evolved over time then, not only about its value but also then as
a consequence about where its used in practice today by maintainers
and developers in different trees.

[0] https://lwn.net/Articles/154602/

2) The old position of use of EXPORT_SYMBOL_GPL() about the
derivatives work punts onto the maintainer the onus over the question
of derivatives work -- such question really should not be taken
lightly and this responsibility should really not fall onto the
developer, it requires attorney involvement and should not be taken
lightly by any means.

3) Most drivers are upstream these days, we want to avoid bug reports
from crappy proprietary drivers, specially as we add new features. We
don't have to be begging vendors to work upstream these days, that's
rather the norm. The landscape has changed dramatically. Even Linus
has told Nvidia to go fuck themselves lately, bravo.

> But pci_iomap_wc() is not in that category, and I
> think it should be symmetric with similar interfaces like pci_iomap()
> and ioremap_wc().

Those are two old APIs, and quite the contrary, as I noted we have a
series of new PAT APIs that old modules did not use that are now being
added and spread into the kernel onto which upstream maintainers have
been insisting on using EXPORT_SYMBOL_GPL() even though older similar
APIs only used EXPORT_SYMBOL(). As a recent example the family of APIs
set_pages_array_xx() are all EXPORT_SYMBOL() but Toshi's new
set_pages_array_wt() was asked to be changed to EXPORT_SYMBOL_GPL()
because as noted by Ingo:

--
By default we make new APIs EXPORT_SYMBOL_GPL():
we don't want proprietary modules mucking around with new code
PAT interfaces, we only want modules we can analyze and fix
in detail.
--

http://article.gmane.org/gmane.linux.kernel.mm/129104

> I don't want to use EXPORT_SYMBOL_GPL() for a random collection of
> things depending on the whim of the author.

Its not just me as I note above, and the new APIs I'm introducing are
also to help with PAT usage.

> That makes for a messy environment to work in, and it's messy enou

Re: [Xen-devel] [PATCH 3/3] xen/block: add multi-page ring support

2015-06-19 Thread Konrad Rzeszutek Wilk

On Tue, Jun 09, 2015 at 10:21:27AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 09, 2015 at 04:07:33PM +0200, Roger Pau Monn? wrote:
> > El 09/06/15 a les 15.39, Konrad Rzeszutek Wilk ha escrit:
> > > On Tue, Jun 09, 2015 at 08:52:53AM +, Paul Durrant wrote:
> > >>> -Original Message-
> > >>> From: Bob Liu [mailto:bob@oracle.com]
> > >>> Sent: 09 June 2015 09:50
> > >>> To: Bob Liu
> > >>> Cc: xen-devel@lists.xen.org; David Vrabel; just...@spectralogic.com;
> > >>> konrad.w...@oracle.com; Roger Pau Monne; Paul Durrant; Julien Grall; 
> > >>> linux-
> > >>> ker...@vger.kernel.org
> > >>> Subject: Re: [PATCH 3/3] xen/block: add multi-page ring support
> > >>>
> > >>>
> > >>> On 06/03/2015 01:40 PM, Bob Liu wrote:
> >  Extend xen/block to support multi-page ring, so that more requests can 
> >  be
> >  issued by using more than one pages as the request ring between 
> >  blkfront
> >  and backend.
> >  As a result, the performance can get improved significantly.
> > 
> >  We got some impressive improvements on our highend iscsi storage 
> >  cluster
> >  backend. If using 64 pages as the ring, the IOPS increased about 15 
> >  times
> >  for the throughput testing and above doubled for the latency testing.
> > 
> >  The reason was the limit on outstanding requests is 32 if use only 
> >  one-page
> >  ring, but in our case the iscsi lun was spread across about 100 
> >  physical
> >  drives, 32 was really not enough to keep them busy.
> > 
> >  Changes in v2:
> >   - Rebased to 4.0-rc6.
> >   - Document on how multi-page ring feature working to linux io/blkif.h.
> > 
> >  Changes in v3:
> >   - Remove changes to linux io/blkif.h and follow the protocol defined
> > in io/blkif.h of XEN tree.
> >   - Rebased to 4.1-rc3
> > 
> >  Changes in v4:
> >   - Turn to use 'ring-page-order' and 'max-ring-page-order'.
> >   - A few comments from Roger.
> > 
> >  Changes in v5:
> >   - Clarify with 4k granularity to comment
> >   - Address more comments from Roger
> > 
> >  Signed-off-by: Bob Liu 
> > >>>
> > >>> Also tested the windows PV driver which also works fine when multi-page
> > >>> ring feature
> > >>> was enabled in Linux backend.
> > >>> http://www.xenproject.org/downloads/windows-pv-drivers.html
> > >>>
> > >>
> > >> Great! Thanks for verifying that :-)
> > > 
> > > Woot! Bob, could you repost the blkif.h patch for the Xen tree
> > > pleas e and also mention the testing part in it please? I think this
> > > was the only big 'what if?!' question holding this up.
> > > 
> > > 
> > > Roger, I put them (patches) on devel/for-jens-4.2 on
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
> > > 
> > > I think these two patches:
> > > drivers: xen-blkback: delay pending_req allocation to connect_ring
> > > xen/block: add multi-page ring support
> > > 
> > > are the only ones that haven't been Acked by you (or maybe they
> > > have and I missed the Ack?)
> > 
> > Hello,
> > 
> > I was waiting to Ack those because the XenServer storage performance
> > folks found out that these patches cause a performance regression on
> > some of their tests. I'm adding them to the conversation so they can
> 
> This is with multi-page enabled or with the patches but multi-page
> disabled (baseline)?
> 
> > provide more details about the issues they found, and whether we should
> > hold pushing this patches or not.
> 
> Or surely fix whatever is causing this.


ping?


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

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

Re: [Xen-devel] [libvirt] [PATCH libvirt] libxl: avoid freeing an uninitialised bitmap

2015-06-19 Thread Jim Fehlig



On 06/19/2015 10:54 AM, Eric Blake wrote:

On 06/19/2015 10:33 AM, Ian Campbell wrote:

If vm->def->cputune.nvcpupin is 0 in libxlDomainSetVcpuAffinities (as
seems to be the case on arm) then the VIR_FREE after cleanup: would be
operating on an uninitialised pointer in map.map.

Fix this by using libxl_bitmap_init and libxl_bitmap_dispose in the
appropriate places (like VIR_FREE libxl_bitmap_dispose is also

s/VIR_FREE/VIR_FREE,/


idempotent, so there is no double free on exit from the loop).

libxl_bitmap_dispose is slightly preferable since it also sets
map.size back to 0, avoiding a potential source of confusion.

This fixes the crashes we've been seeing in the Xen automated tests on
ARM.

I had a glance at the handful of other users of libxl_bitmap and none
of them looked to have a similar issue.

Signed-off-by: Ian Campbell 
---
  src/libxl/libxl_domain.c |6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

ACK.


Modified the commit message as suggested and pushed.  Thanks!

Regards,
Jim


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

[Xen-devel] [PATCH v25 02/15] x86/VPMU: Add public xenpmu.h

Add pmu.h header files, move various macros and structures that will be
shared between hypervisor and PV guests to it.

Move MSR banks out of architectural PMU structures to allow for larger sizes
in the future. The banks are allocated immediately after the context and
PMU structures store offsets to them.

While making these updates, also:
* Remove unused vpmu_domain() macro from vpmu.h
* Convert msraddr_to_bitpos() into an inline and make it a little faster by
  realizing that all Intel's PMU-related MSRs are in the lower MSR range.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
Acked-by: Jan Beulich 
---
 xen/arch/x86/hvm/svm/vpmu.c  |  83 +++--
 xen/arch/x86/hvm/vmx/vpmu_core2.c| 123 +--
 xen/arch/x86/hvm/vpmu.c  |   8 ++
 xen/arch/x86/oprofile/op_model_ppro.c|   6 +-
 xen/include/Makefile |   3 +-
 xen/include/asm-x86/hvm/vmx/vpmu_core2.h |  32 
 xen/include/asm-x86/hvm/vpmu.h   |  16 ++--
 xen/include/public/arch-arm.h|   5 ++
 xen/include/public/arch-x86/pmu.h| 116 +
 xen/include/public/pmu.h |  58 +++
 xen/include/xlat.lst |   6 ++
 11 files changed, 322 insertions(+), 134 deletions(-)
 delete mode 100644 xen/include/asm-x86/hvm/vmx/vpmu_core2.h
 create mode 100644 xen/include/public/arch-x86/pmu.h
 create mode 100644 xen/include/public/pmu.h

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 6764070..a8b79df 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -30,10 +30,7 @@
 #include 
 #include 
 #include 
-
-#define F10H_NUM_COUNTERS 4
-#define F15H_NUM_COUNTERS 6
-#define MAX_NUM_COUNTERS F15H_NUM_COUNTERS
+#include 
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
 #define MSR_F10H_EVNTSEL_EN_SHIFT   22
@@ -49,6 +46,9 @@ static const u32 __read_mostly *counters;
 static const u32 __read_mostly *ctrls;
 static bool_t __read_mostly k7_counters_mirrored;
 
+#define F10H_NUM_COUNTERS   4
+#define F15H_NUM_COUNTERS   6
+
 /* PMU Counter MSRs. */
 static const u32 AMD_F10H_COUNTERS[] = {
 MSR_K7_PERFCTR0,
@@ -83,12 +83,14 @@ static const u32 AMD_F15H_CTRLS[] = {
 MSR_AMD_FAM15H_EVNTSEL5
 };
 
-/* storage for context switching */
-struct amd_vpmu_context {
-u64 counters[MAX_NUM_COUNTERS];
-u64 ctrls[MAX_NUM_COUNTERS];
-bool_t msr_bitmap_set;
-};
+/* Use private context as a flag for MSR bitmap */
+#define msr_bitmap_on(vpmu)do {\
+   (vpmu)->priv_context = (void *)-1L; \
+   } while (0)
+#define msr_bitmap_off(vpmu)   do {\
+   (vpmu)->priv_context = NULL;\
+   } while (0)
+#define is_msr_bitmap_on(vpmu) ((vpmu)->priv_context != NULL)
 
 static inline int get_pmu_reg_type(u32 addr)
 {
@@ -142,7 +144,6 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
 {
 unsigned int i;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
 
 for ( i = 0; i < num_counters; i++ )
 {
@@ -150,14 +151,13 @@ static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
 svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_WRITE);
 }
 
-ctxt->msr_bitmap_set = 1;
+msr_bitmap_on(vpmu);
 }
 
 static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
 {
 unsigned int i;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
 
 for ( i = 0; i < num_counters; i++ )
 {
@@ -165,7 +165,7 @@ static void amd_vpmu_unset_msr_bitmap(struct vcpu *v)
 svm_intercept_msr(v, ctrls[i], MSR_INTERCEPT_RW);
 }
 
-ctxt->msr_bitmap_set = 0;
+msr_bitmap_off(vpmu);
 }
 
 static int amd_vpmu_do_interrupt(struct cpu_user_regs *regs)
@@ -177,19 +177,22 @@ static inline void context_load(struct vcpu *v)
 {
 unsigned int i;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
+struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+uint64_t *counter_regs = vpmu_reg_pointer(ctxt, counters);
+uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
 for ( i = 0; i < num_counters; i++ )
 {
-wrmsrl(counters[i], ctxt->counters[i]);
-wrmsrl(ctrls[i], ctxt->ctrls[i]);
+wrmsrl(counters[i], counter_regs[i]);
+wrmsrl(ctrls[i], ctrl_regs[i]);
 }
 }
 
 static void amd_vpmu_load(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct amd_vpmu_context *ctxt = vpmu->context;
+struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
+uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
 vpmu_reset(vpmu, VPMU_FROZEN);
 
@@ -198,7 +201,7 @@ static void amd_vpmu_load(struct vcpu *v)
 unsigned int i;
 
 for ( i = 0; i < num_

[Xen-devel] [PATCH v25 14/15] x86/VPMU: Add privileged PMU mode

Add support for privileged PMU mode (XENPMU_MODE_ALL) which allows privileged
domain (dom0) profile both itself (and the hypervisor) and the guests. While
this mode is on profiling in guests is disabled.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 xen/arch/x86/hvm/vpmu.c  | 40 +---
 xen/arch/x86/traps.c | 13 +
 xen/include/public/pmu.h |  3 +++
 3 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index 9d6ca93..3ad0b94 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -108,8 +108,10 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
 const struct arch_vpmu_ops *ops;
 int ret = 0;
 
-if ( likely(vpmu_mode == XENPMU_MODE_OFF) )
-goto nop;
+if ( likely(vpmu_mode == XENPMU_MODE_OFF) ||
+ ((vpmu_mode & XENPMU_MODE_ALL) &&
+  !is_hardware_domain(current->domain)) )
+ goto nop;
 
 vpmu = vcpu_vpmu(curr);
 ops = vpmu->arch_vpmu_ops;
@@ -164,8 +166,12 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 struct vlapic *vlapic;
 u32 vlapic_lvtpc;
 
-/* dom0 will handle interrupt for special domains (e.g. idle domain) */
-if ( sampled->domain->domain_id >= DOMID_FIRST_RESERVED )
+/*
+ * dom0 will handle interrupt for special domains (e.g. idle domain) or,
+ * in XENPMU_MODE_ALL, for everyone.
+ */
+if ( (vpmu_mode & XENPMU_MODE_ALL) ||
+ (sampled->domain->domain_id >= DOMID_FIRST_RESERVED) )
 {
 sampling = choose_hwdom_vcpu();
 if ( !sampling )
@@ -179,16 +185,17 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 return;
 
 /* PV(H) guest */
-if ( !is_hvm_vcpu(sampling) )
+if ( !is_hvm_vcpu(sampling) || (vpmu_mode & XENPMU_MODE_ALL) )
 {
 const struct cpu_user_regs *cur_regs;
 uint64_t *flags = &vpmu->xenpmu_data->pmu.pmu_flags;
-domid_t domid = DOMID_SELF;
+domid_t domid;
 
 if ( !vpmu->xenpmu_data )
 return;
 
 if ( is_pvh_vcpu(sampling) &&
+ !(vpmu_mode & XENPMU_MODE_ALL) &&
  !vpmu->arch_vpmu_ops->do_interrupt(regs) )
 return;
 
@@ -205,6 +212,11 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 else
 *flags = PMU_SAMPLE_PV;
 
+if ( sampled == sampling )
+domid = DOMID_SELF;
+else
+domid = sampled->domain->domain_id;
+
 /* Store appropriate registers in xenpmu_data */
 /* FIXME: 32-bit PVH should go here as well */
 if ( is_pv_32bit_vcpu(sampling) )
@@ -233,7 +245,8 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
 
 if ( (vpmu_mode & XENPMU_MODE_SELF) )
 cur_regs = guest_cpu_user_regs();
-else if ( !guest_mode(regs) && 
is_hardware_domain(sampling->domain) )
+else if ( !guest_mode(regs) &&
+  is_hardware_domain(sampling->domain) )
 {
 cur_regs = regs;
 domid = DOMID_XEN;
@@ -472,7 +485,9 @@ void vpmu_initialise(struct vcpu *v)
 printk(XENLOG_G_WARNING "VPMU: Initialization failed for %pv\n", v);
 
 /* Intel needs to initialize VPMU ops even if VPMU is not in use */
-if ( !is_priv_vpmu && (ret || (vpmu_mode == XENPMU_MODE_OFF)) )
+if ( !is_priv_vpmu &&
+ (ret || (vpmu_mode == XENPMU_MODE_OFF) ||
+  (vpmu_mode == XENPMU_MODE_ALL)) )
 {
 spin_lock(&vpmu_lock);
 vpmu_count--;
@@ -525,7 +540,8 @@ static int pvpmu_init(struct domain *d, xen_pmu_params_t 
*params)
 struct page_info *page;
 uint64_t gfn = params->val;
 
-if ( vpmu_mode == XENPMU_MODE_OFF )
+if ( (vpmu_mode == XENPMU_MODE_OFF) ||
+ ((vpmu_mode & XENPMU_MODE_ALL) && !is_hardware_domain(d)) )
 return -EINVAL;
 
 if ( (params->vcpu >= d->max_vcpus) || (d->vcpu[params->vcpu] == NULL) )
@@ -645,12 +661,14 @@ long do_xenpmu_op(unsigned int op, 
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
 {
 case XENPMU_mode_set:
 {
-if ( (pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV)) ||
+if ( (pmu_params.val &
+  ~(XENPMU_MODE_SELF | XENPMU_MODE_HV | XENPMU_MODE_ALL)) ||
  (hweight64(pmu_params.val) > 1) )
 return -EINVAL;
 
 /* 32-bit dom0 can only sample itself. */
-if ( is_pv_32bit_vcpu(current) && (pmu_params.val & XENPMU_MODE_HV) )
+if ( is_pv_32bit_vcpu(current) &&
+ (pmu_params.val & (XENPMU_MODE_HV | XENPMU_MODE_ALL)) )
 return -EINVAL;
 
 spin_lock(&vpmu_lock);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index d2ff1a9..ac5622f 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2654,6 +2654,10 @@ static int emulate_privileged_op(struct cpu_user_regs 
*regs)
 case MSR_AMD_FAM15H_EVNTSEL0...MSR_AMD_FAM15H_PERFCTR

[Xen-devel] [PATCH v25 13/15] x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr

The two routines share most of their logic.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Dietmar Hahn 
---
 xen/arch/x86/hvm/vpmu.c| 75 --
 xen/include/asm-x86/hvm/vpmu.h | 14 ++--
 2 files changed, 41 insertions(+), 48 deletions(-)

diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c
index c0a22fb..9d6ca93 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -100,63 +100,46 @@ void vpmu_lvtpc_update(uint32_t val)
 apic_write(APIC_LVTPC, vpmu->hw_lapic_lvtpc);
 }
 
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+uint64_t supported, bool_t is_write)
 {
 struct vcpu *curr = current;
 struct vpmu_struct *vpmu;
+const struct arch_vpmu_ops *ops;
+int ret = 0;
 
-if ( vpmu_mode == XENPMU_MODE_OFF )
-return 0;
+if ( likely(vpmu_mode == XENPMU_MODE_OFF) )
+goto nop;
 
 vpmu = vcpu_vpmu(curr);
-if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_wrmsr )
-{
-int ret = vpmu->arch_vpmu_ops->do_wrmsr(msr, msr_content, supported);
-
-/*
- * We may have received a PMU interrupt during WRMSR handling
- * and since do_wrmsr may load VPMU context we should save
- * (and unload) it again.
- */
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
- vpmu_is_set(vpmu, VPMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu->arch_vpmu_ops->arch_vpmu_save(curr, 0);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-
-return 0;
-}
-
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-struct vcpu *curr = current;
-struct vpmu_struct *vpmu;
+ops = vpmu->arch_vpmu_ops;
+if ( !ops )
+goto nop;
+
+if ( is_write && ops->do_wrmsr )
+ret = ops->do_wrmsr(msr, *msr_content, supported);
+else if ( !is_write && ops->do_rdmsr )
+ret = ops->do_rdmsr(msr, msr_content);
+else
+goto nop;
 
-if ( vpmu_mode == XENPMU_MODE_OFF )
+/*
+ * We may have received a PMU interrupt while handling MSR access
+ * and since do_wr/rdmsr may load VPMU context we should save
+ * (and unload) it again.
+ */
+if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
+vpmu_is_set(vpmu, VPMU_CACHED) )
 {
-*msr_content = 0;
-return 0;
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+ops->arch_vpmu_save(curr, 0);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
 }
 
-vpmu = vcpu_vpmu(curr);
-if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->do_rdmsr )
-{
-int ret = vpmu->arch_vpmu_ops->do_rdmsr(msr, msr_content);
+return ret;
 
-if ( !is_hvm_vcpu(curr) && vpmu->xenpmu_data &&
- vpmu_is_set(vpmu, VPMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu->arch_vpmu_ops->arch_vpmu_save(curr, 0);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-else
+ nop:
+if ( !is_write )
 *msr_content = 0;
 
 return 0;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index f486d2f..212e496 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -101,8 +101,8 @@ static inline bool_t vpmu_are_all_set(const struct 
vpmu_struct *vpmu,
 }
 
 void vpmu_lvtpc_update(uint32_t val);
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported);
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content);
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+uint64_t supported, bool_t is_write);
 void vpmu_do_interrupt(struct cpu_user_regs *regs);
 void vpmu_do_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx);
@@ -112,6 +112,16 @@ void vpmu_save(struct vcpu *v);
 int vpmu_load(struct vcpu *v, bool_t from_guest);
 void vpmu_dump(struct vcpu *v);
 
+static inline int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
+uint64_t supported)
+{
+return vpmu_do_msr(msr, &msr_content, supported, 1);
+}
+static inline int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
+{
+return vpmu_do_msr(msr, msr_content, 0, 0);
+}
+
 extern int acquire_pmu_ownership(int pmu_ownership);
 extern void release_pmu_ownership(int pmu_ownership);
 
-- 
1.8.1.4


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

[Xen-devel] [PATCH v25 11/15] VPMU/AMD: Check MSR values before writing to hardware

A number of fields of PMU control MSRs are defined as Reserved. AMD
documentation requires that such fields are preserved when the register
is written by software.

Add checks to amd_vpmu_do_wrmsr() to make sure that guests don't attempt
to modify those bits.

Signed-off-by: Boris Ostrovsky 
---
 xen/arch/x86/hvm/svm/vpmu.c | 49 +++--
 1 file changed, 43 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 74d03a5..934f1b7 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -48,6 +48,7 @@ static bool_t __read_mostly k7_counters_mirrored;
 
 #define F10H_NUM_COUNTERS   4
 #define F15H_NUM_COUNTERS   6
+#define MAX_NUM_COUNTERSF15H_NUM_COUNTERS
 
 /* PMU Counter MSRs. */
 static const u32 AMD_F10H_COUNTERS[] = {
@@ -83,6 +84,11 @@ static const u32 AMD_F15H_CTRLS[] = {
 MSR_AMD_FAM15H_EVNTSEL5
 };
 
+/* Bits [63:42], [39:36], 21 and 19 are reserved */
+#define CTRL_RSVD_MASK ((-1ULL & (~((1ULL << 42) - 1))) | \
+(0xfULL << 36) | (1ULL << 21) | (1ULL << 19))
+static uint64_t __read_mostly ctrl_rsvd[MAX_NUM_COUNTERS];
+
 /* Use private context as a flag for MSR bitmap */
 #define msr_bitmap_on(vpmu)do {\
(vpmu)->priv_context = (void *)-1L; \
@@ -92,17 +98,24 @@ static const u32 AMD_F15H_CTRLS[] = {
} while (0)
 #define is_msr_bitmap_on(vpmu) ((vpmu)->priv_context != NULL)
 
-static inline int get_pmu_reg_type(u32 addr)
+static inline int get_pmu_reg_type(u32 addr, unsigned int *idx)
 {
 if ( (addr >= MSR_K7_EVNTSEL0) && (addr <= MSR_K7_EVNTSEL3) )
+{
+*idx = addr - MSR_K7_EVNTSEL0;
 return MSR_TYPE_CTRL;
+}
 
 if ( (addr >= MSR_K7_PERFCTR0) && (addr <= MSR_K7_PERFCTR3) )
+{
+*idx = addr - MSR_K7_PERFCTR0;
 return MSR_TYPE_COUNTER;
+}
 
 if ( (addr >= MSR_AMD_FAM15H_EVNTSEL0) &&
  (addr <= MSR_AMD_FAM15H_PERFCTR5 ) )
 {
+*idx = (addr - MSR_AMD_FAM15H_EVNTSEL0) >> 1;
 if (addr & 1)
 return MSR_TYPE_COUNTER;
 else
@@ -140,6 +153,16 @@ static inline u32 get_fam15h_addr(u32 addr)
 return addr;
 }
 
+static void amd_vpmu_init_regs(struct xen_pmu_amd_ctxt *ctxt)
+{
+unsigned i;
+uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
+
+memset(&ctxt->regs[0], 0, 2 * sizeof(uint64_t) * num_counters);
+for ( i = 0; i < num_counters; i++ )
+ctrl_regs[i] = ctrl_rsvd[i];
+}
+
 static void amd_vpmu_set_msr_bitmap(struct vcpu *v)
 {
 unsigned int i;
@@ -289,19 +312,24 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 {
 struct vcpu *v = current;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
+unsigned int idx = 0;
+int type = get_pmu_reg_type(msr, &idx);
 
 ASSERT(!supported);
 
+if ( (type == MSR_TYPE_CTRL ) &&
+ ((msr_content & CTRL_RSVD_MASK) != ctrl_rsvd[idx]) )
+return -EINVAL;
+
 /* For all counters, enable guest only mode for HVM guest */
-if ( has_hvm_container_vcpu(v) &&
- (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
+if ( has_hvm_container_vcpu(v) && (type == MSR_TYPE_CTRL) &&
  !is_guest_mode(msr_content) )
 {
 set_guest_mode(msr_content);
 }
 
 /* check if the first counter is enabled */
-if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
+if ( (type == MSR_TYPE_CTRL) &&
 is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) )
 {
 if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
@@ -313,7 +341,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 }
 
 /* stop saving & restore if guest stops first counter */
-if ( (get_pmu_reg_type(msr) == MSR_TYPE_CTRL) &&
+if ( (type == MSR_TYPE_CTRL) &&
 (is_pmu_enabled(msr_content) == 0) && vpmu_is_set(vpmu, VPMU_RUNNING) )
 {
 vpmu_reset(vpmu, VPMU_RUNNING);
@@ -433,7 +461,7 @@ int svm_vpmu_initialise(struct vcpu *v)
 if ( !counters )
 return -EINVAL;
 
-ctxt = xzalloc_bytes(sizeof(*ctxt) +
+ctxt = xmalloc_bytes(sizeof(*ctxt) +
  2 * sizeof(uint64_t) * num_counters);
 if ( !ctxt )
 {
@@ -445,6 +473,7 @@ int svm_vpmu_initialise(struct vcpu *v)
 
 ctxt->counters = sizeof(*ctxt);
 ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
+amd_vpmu_init_regs(ctxt);
 
 vpmu->context = ctxt;
 vpmu->priv_context = NULL;
@@ -457,6 +486,8 @@ int svm_vpmu_initialise(struct vcpu *v)
 
 int __init amd_vpmu_init(void)
 {
+unsigned int i;
+
 switch ( current_cpu_data.x86 )
 {
 case 0x15:
@@ -490,6 +521,12 @@ int __init amd_vpmu_init(void)
 return -ENOSPC;
 }
 
+for ( i = 0; i < num_counters; i++ )
+{
+rdmsrl(ctrls[i], ctrl_rsvd[i]);
+ctrl_rsvd[i] &= CTRL_RSVD_MASK;
+}
+

[Xen-devel] [PATCH v25 06/15] x86/VPMU: Initialize PMU for PV(H) guests

Code for initializing/tearing down PMU for PV guests

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
Acked-by: Jan Beulich 
Acked-by: Kevin Tian 
---
 tools/flask/policy/policy/modules/xen/xen.te |   4 +
 xen/arch/x86/domain.c|   2 +
 xen/arch/x86/hvm/hvm.c   |   1 +
 xen/arch/x86/hvm/svm/svm.c   |   4 +-
 xen/arch/x86/hvm/svm/vpmu.c  |  16 +++-
 xen/arch/x86/hvm/vmx/vmx.c   |   4 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c|  30 --
 xen/arch/x86/hvm/vpmu.c  | 131 ---
 xen/common/event_channel.c   |   1 +
 xen/include/asm-x86/hvm/vpmu.h   |   2 +
 xen/include/public/pmu.h |   2 +
 xen/include/public/xen.h |   1 +
 xen/include/xsm/dummy.h  |   3 +
 xen/xsm/flask/hooks.c|   4 +
 xen/xsm/flask/policy/access_vectors  |   2 +
 15 files changed, 181 insertions(+), 26 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index 45b5cb2..f553eb5 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -130,6 +130,10 @@ if (guest_writeconsole) {
dontaudit domain_type xen_t : xen writeconsole;
 }
 
+# Allow all domains to use PMU (but not to change its settings --- that's what
+# pmu_ctrl is for)
+allow domain_type xen_t:xen2 pmu_use;
+
 ###
 #
 # Domain creation
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index dc18565..b699f68 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -438,6 +438,8 @@ int vcpu_initialise(struct vcpu *v)
 vmce_init_vcpu(v);
 }
 
+spin_lock_init(&v->arch.vpmu.vpmu_lock);
+
 if ( has_hvm_container_domain(d) )
 {
 rc = hvm_vcpu_initialise(v);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index d5e5242..83a81f5 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4931,6 +4931,7 @@ static hvm_hypercall_t *const 
pvh_hypercall64_table[NR_hypercalls] = {
 HYPERCALL(hvm_op),
 HYPERCALL(sysctl),
 HYPERCALL(domctl),
+HYPERCALL(xenpmu_op),
 [ __HYPERVISOR_arch_1 ] = (hvm_hypercall_t *)paging_domctl_continuation
 };
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index a02f983..680eebe 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1165,7 +1165,9 @@ static int svm_vcpu_initialise(struct vcpu *v)
 return rc;
 }
 
-vpmu_initialise(v);
+/* PVH's VPMU is initialized via hypercall */
+if ( is_hvm_vcpu(v) )
+vpmu_initialise(v);
 
 svm_guest_osvw_init(v);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index b60ca40..a8572a6 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -364,13 +364,11 @@ static void amd_vpmu_destroy(struct vcpu *v)
 amd_vpmu_unset_msr_bitmap(v);
 
 xfree(vpmu->context);
-vpmu_reset(vpmu, VPMU_CONTEXT_ALLOCATED);
 
 if ( vpmu_is_set(vpmu, VPMU_RUNNING) )
-{
-vpmu_reset(vpmu, VPMU_RUNNING);
 release_pmu_ownship(PMU_OWNER_HVM);
-}
+
+vpmu_clear(vpmu);
 }
 
 /* VPMU part of the 'q' keyhandler */
@@ -482,6 +480,16 @@ int __init amd_vpmu_init(void)
 return -EINVAL;
 }
 
+if ( sizeof(struct xen_pmu_data) +
+ 2 * sizeof(uint64_t) * num_counters > PAGE_SIZE )
+{
+printk(XENLOG_WARNING
+   "VPMU: Register bank does not fit into VPMU shared page\n");
+counters = ctrls = NULL;
+num_counters = 0;
+return -ENOSPC;
+}
+
 return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 0837627..50e11dd 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -140,7 +140,9 @@ static int vmx_vcpu_initialise(struct vcpu *v)
 }
 }
 
-vpmu_initialise(v);
+/* PVH's VPMU is initialized via hypercall */
+if ( is_hvm_vcpu(v) )
+vpmu_initialise(v);
 
 vmx_install_vlapic_mapping(v);
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 025c970..e7642e5 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -365,13 +365,16 @@ static int core2_vpmu_alloc_resource(struct vcpu *v)
 if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
 return 0;
 
-wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
-if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
-goto out_err;
+if ( has_hvm_container_vcpu(v) )
+{
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+if ( vmx_add_host_load_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
+goto out_err;
 
-if ( vmx_add_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL) )
-

[Xen-devel] [PATCH v25 08/15] x86/VPMU: When handling MSR accesses, leave fault injection to callers

Hypervisor cannot easily inject faults into PV guests from arch-specific VPMU
read/write MSR handlers (unlike it is in the case of HVM guests).

With this patch vpmu_do_msr() will return an error code to indicate whether an
error was encountered during MSR processing (instead of stating that the access
was to a VPMU register). The caller will then decide how to deal with the error.

As part of this patch we also check for validity of certain MSR accesses right
when we determine which register is being written, as opposed to postponing this
until later.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
---
Changes in v25:
* Updated commit message to mention reason for changing vpmu_do_msr return 
values

 xen/arch/x86/hvm/svm/svm.c|  6 ++-
 xen/arch/x86/hvm/svm/vpmu.c   |  6 +--
 xen/arch/x86/hvm/vmx/vmx.c| 24 ---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 86 +++
 4 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 680eebe..3b5d15d 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1708,7 +1708,8 @@ static int svm_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 case MSR_AMD_FAM15H_EVNTSEL3:
 case MSR_AMD_FAM15H_EVNTSEL4:
 case MSR_AMD_FAM15H_EVNTSEL5:
-vpmu_do_rdmsr(msr, msr_content);
+if ( vpmu_do_rdmsr(msr, msr_content) )
+goto gpf;
 break;
 
 case MSR_AMD64_DR0_ADDRESS_MASK:
@@ -1859,7 +1860,8 @@ static int svm_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 case MSR_AMD_FAM15H_EVNTSEL3:
 case MSR_AMD_FAM15H_EVNTSEL4:
 case MSR_AMD_FAM15H_EVNTSEL5:
-vpmu_do_wrmsr(msr, msr_content, 0);
+if ( vpmu_do_wrmsr(msr, msr_content, 0) )
+goto gpf;
 break;
 
 case MSR_IA32_MCx_MISC(4): /* Threshold register */
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index a8572a6..74d03a5 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -305,7 +305,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 is_pmu_enabled(msr_content) && !vpmu_is_set(vpmu, VPMU_RUNNING) )
 {
 if ( !acquire_pmu_ownership(PMU_OWNER_HVM) )
-return 1;
+return 0;
 vpmu_set(vpmu, VPMU_RUNNING);
 
 if ( has_hvm_container_vcpu(v) && is_msr_bitmap_on(vpmu) )
@@ -335,7 +335,7 @@ static int amd_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 
 /* Write to hw counters */
 wrmsrl(msr, msr_content);
-return 1;
+return 0;
 }
 
 static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
@@ -353,7 +353,7 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 
 rdmsrl(msr, *msr_content);
 
-return 1;
+return 0;
 }
 
 static void amd_vpmu_destroy(struct vcpu *v)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 50e11dd..db1fa82 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2166,12 +2166,17 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 *msr_content |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
 /* Perhaps vpmu will change some bits. */
+/* FALLTHROUGH */
+case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(3):
+case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+case MSR_IA32_PEBS_ENABLE:
+case MSR_IA32_DS_AREA:
 if ( vpmu_do_rdmsr(msr, msr_content) )
-goto done;
+goto gp_fault;
 break;
 default:
-if ( vpmu_do_rdmsr(msr, msr_content) )
-break;
 if ( passive_domain_do_rdmsr(msr, msr_content) )
 goto done;
 switch ( long_mode_do_msr_read(msr, msr_content) )
@@ -2347,7 +2352,7 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 if ( msr_content & ~supported )
 {
 /* Perhaps some other bits are supported in vpmu. */
-if ( !vpmu_do_wrmsr(msr, msr_content, supported) )
+if ( vpmu_do_wrmsr(msr, msr_content, supported) )
 break;
 }
 if ( msr_content & IA32_DEBUGCTLMSR_LBR )
@@ -2375,9 +2380,16 @@ static int vmx_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 if ( !nvmx_msr_write_intercept(msr, msr_content) )
 goto gp_fault;
 break;
+case MSR_P6_PERFCTR(0)...MSR_P6_PERFCTR(7):
+case MSR_P6_EVNTSEL(0)...MSR_P6_EVNTSEL(7):
+case MSR_CORE_PERF_FIXED_CTR0...MSR_CORE_PERF_FIXED_CTR2:
+case MSR_CORE_PERF_FIXED_CTR_CTRL...MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+case MSR_IA32_PEBS_ENABLE:
+case MSR_IA32_DS_AREA:
+ if ( vpmu_do_wrmsr(msr, m

[Xen-devel] [PATCH v25 05/15] x86/VPMU: Initialize VPMUs with __initcall

Move some VPMU initilization operations into __initcalls to avoid performing
same tests and calculations for each vcpu.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 xen/arch/x86/hvm/svm/vpmu.c   | 106 --
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 151 +++---
 xen/arch/x86/hvm/vpmu.c   |  32 
 xen/include/asm-x86/hvm/vpmu.h|   2 +
 4 files changed, 156 insertions(+), 135 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 481ea7b..b60ca40 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -356,54 +356,6 @@ static int amd_vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 return 1;
 }
 
-static int amd_vpmu_initialise(struct vcpu *v)
-{
-struct xen_pmu_amd_ctxt *ctxt;
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
-uint8_t family = current_cpu_data.x86;
-
-if ( counters == NULL )
-{
- switch ( family )
-{
-case 0x15:
-num_counters = F15H_NUM_COUNTERS;
-counters = AMD_F15H_COUNTERS;
-ctrls = AMD_F15H_CTRLS;
-k7_counters_mirrored = 1;
-break;
-case 0x10:
-case 0x12:
-case 0x14:
-case 0x16:
-default:
-num_counters = F10H_NUM_COUNTERS;
-counters = AMD_F10H_COUNTERS;
-ctrls = AMD_F10H_CTRLS;
-k7_counters_mirrored = 0;
-break;
-}
-}
-
-ctxt = xzalloc_bytes(sizeof(*ctxt) +
- 2 * sizeof(uint64_t) * num_counters);
-if ( !ctxt )
-{
-gdprintk(XENLOG_WARNING, "Insufficient memory for PMU, "
-" PMU feature is unavailable on domain %d vcpu %d.\n",
-v->vcpu_id, v->domain->domain_id);
-return -ENOMEM;
-}
-
-ctxt->counters = sizeof(*ctxt);
-ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
-
-vpmu->context = ctxt;
-vpmu->priv_context = NULL;
-vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
-return 0;
-}
-
 static void amd_vpmu_destroy(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
@@ -474,30 +426,62 @@ struct arch_vpmu_ops amd_vpmu_ops = {
 
 int svm_vpmu_initialise(struct vcpu *v)
 {
+struct xen_pmu_amd_ctxt *ctxt;
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-uint8_t family = current_cpu_data.x86;
-int ret = 0;
 
-/* vpmu enabled? */
 if ( vpmu_mode == XENPMU_MODE_OFF )
 return 0;
 
-switch ( family )
+if ( !counters )
+return -EINVAL;
+
+ctxt = xzalloc_bytes(sizeof(*ctxt) +
+ 2 * sizeof(uint64_t) * num_counters);
+if ( !ctxt )
 {
+printk(XENLOG_G_WARNING "Insufficient memory for PMU, "
+   " PMU feature is unavailable on domain %d vcpu %d.\n",
+   v->vcpu_id, v->domain->domain_id);
+return -ENOMEM;
+}
+
+ctxt->counters = sizeof(*ctxt);
+ctxt->ctrls = ctxt->counters + sizeof(uint64_t) * num_counters;
+
+vpmu->context = ctxt;
+vpmu->priv_context = NULL;
+
+vpmu->arch_vpmu_ops = &amd_vpmu_ops;
+
+vpmu_set(vpmu, VPMU_CONTEXT_ALLOCATED);
+return 0;
+}
+
+int __init amd_vpmu_init(void)
+{
+switch ( current_cpu_data.x86 )
+{
+case 0x15:
+num_counters = F15H_NUM_COUNTERS;
+counters = AMD_F15H_COUNTERS;
+ctrls = AMD_F15H_CTRLS;
+k7_counters_mirrored = 1;
+break;
 case 0x10:
 case 0x12:
 case 0x14:
-case 0x15:
 case 0x16:
-ret = amd_vpmu_initialise(v);
-if ( !ret )
-vpmu->arch_vpmu_ops = &amd_vpmu_ops;
-return ret;
+num_counters = F10H_NUM_COUNTERS;
+counters = AMD_F10H_COUNTERS;
+ctrls = AMD_F10H_CTRLS;
+k7_counters_mirrored = 0;
+break;
+default:
+printk(XENLOG_WARNING "VPMU: Unsupported CPU family %#x\n",
+   current_cpu_data.x86);
+return -EINVAL;
 }
 
-printk("VPMU: Initialization failed. "
-   "AMD processor family %d has not "
-   "been supported\n", family);
-return -EINVAL;
+return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index cfcdf42..025c970 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,62 +708,6 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 return 1;
 }
 
-static int core2_vpmu_initialise(struct vcpu *v)
-{
-struct vpmu_struct *vpmu = vcpu_vpmu(v);
-u64 msr_content;
-static bool_t ds_warned;
-
-if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
-goto func_out;
-/* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
-while ( boot_cpu_has(X86_FEATURE_DS) )
-{
-if ( !boot_cpu_has(X86_FEATURE_DTES64) )
-{
-if ( !ds_warned )
-printk(XENLOG_G_WARNING "CPU does

[Xen-devel] [PATCH v25 15/15] x86/VPMU: Move VPMU files up from hvm/ directory

Since PMU is now not HVM specific we can move VPMU-related files up from
arch/x86/hvm/ directory.

Specifically:
arch/x86/hvm/vpmu.c -> arch/x86/cpu/vpmu.c
arch/x86/hvm/svm/vpmu.c -> arch/x86/cpu/vpmu_amd.c
arch/x86/hvm/vmx/vpmu_core2.c -> arch/x86/cpu/vpmu_intel.c
include/asm-x86/hvm/vpmu.h -> include/asm-x86/vpmu.h

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
Acked-by: Kevin Tian 
---
 xen/arch/x86/cpu/Makefile   | 1 +
 xen/arch/x86/{hvm => cpu}/vpmu.c| 2 +-
 xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} | 2 +-
 xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} | 2 +-
 xen/arch/x86/hvm/Makefile   | 1 -
 xen/arch/x86/hvm/svm/Makefile   | 1 -
 xen/arch/x86/hvm/vlapic.c   | 2 +-
 xen/arch/x86/hvm/vmx/Makefile   | 1 -
 xen/arch/x86/oprofile/op_model_ppro.c   | 2 +-
 xen/arch/x86/traps.c| 2 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h  | 2 +-
 xen/include/asm-x86/{hvm => }/vpmu.h| 0
 12 files changed, 8 insertions(+), 10 deletions(-)
 rename xen/arch/x86/{hvm => cpu}/vpmu.c (99%)
 rename xen/arch/x86/{hvm/svm/vpmu.c => cpu/vpmu_amd.c} (99%)
 rename xen/arch/x86/{hvm/vmx/vpmu_core2.c => cpu/vpmu_intel.c} (99%)
 rename xen/include/asm-x86/{hvm => }/vpmu.h (100%)

diff --git a/xen/arch/x86/cpu/Makefile b/xen/arch/x86/cpu/Makefile
index d73d93a..74f23ae 100644
--- a/xen/arch/x86/cpu/Makefile
+++ b/xen/arch/x86/cpu/Makefile
@@ -7,3 +7,4 @@ obj-y += common.o
 obj-y += intel.o
 obj-y += intel_cacheinfo.o
 obj-y += mwait-idle.o
+obj-y += vpmu.o vpmu_amd.o vpmu_intel.o
diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/cpu/vpmu.c
similarity index 99%
rename from xen/arch/x86/hvm/vpmu.c
rename to xen/arch/x86/cpu/vpmu.c
index 3ad0b94..802e6a3 100644
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -28,10 +28,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/cpu/vpmu_amd.c
similarity index 99%
rename from xen/arch/x86/hvm/svm/vpmu.c
rename to xen/arch/x86/cpu/vpmu_amd.c
index 17272cb..e5195cf 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu_amd.c
@@ -28,8 +28,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
 
 #define MSR_F10H_EVNTSEL_GO_SHIFT   40
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c b/xen/arch/x86/cpu/vpmu_intel.c
similarity index 99%
rename from xen/arch/x86/hvm/vmx/vpmu_core2.c
rename to xen/arch/x86/cpu/vpmu_intel.c
index 1206e90..423ca82 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include  
 #include 
 #include 
 #include 
@@ -37,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 
 /*
  * See Intel SDM Vol 2a Instruction Set Reference chapter 3 for CPUID
diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 69af47f..794e793 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -23,4 +23,3 @@ obj-y += vlapic.o
 obj-y += vmsi.o
 obj-y += vpic.o
 obj-y += vpt.o
-obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/svm/Makefile b/xen/arch/x86/hvm/svm/Makefile
index a10a55e..760d295 100644
--- a/xen/arch/x86/hvm/svm/Makefile
+++ b/xen/arch/x86/hvm/svm/Makefile
@@ -6,4 +6,3 @@ obj-y += nestedsvm.o
 obj-y += svm.o
 obj-y += svmdebug.o
 obj-y += vmcb.o
-obj-y += vpmu.o
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 92b0fa8..e03d670 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -33,12 +33,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/xen/arch/x86/hvm/vmx/Makefile b/xen/arch/x86/hvm/vmx/Makefile
index 373b3d9..04a29ce 100644
--- a/xen/arch/x86/hvm/vmx/Makefile
+++ b/xen/arch/x86/hvm/vmx/Makefile
@@ -3,5 +3,4 @@ obj-y += intr.o
 obj-y += realmode.o
 obj-y += vmcs.o
 obj-y += vmx.o
-obj-y += vpmu_core2.o
 obj-y += vvmx.o
diff --git a/xen/arch/x86/oprofile/op_model_ppro.c 
b/xen/arch/x86/oprofile/op_model_ppro.c
index ca429a1..89649d0 100644
--- a/xen/arch/x86/oprofile/op_model_ppro.c
+++ b/xen/arch/x86/oprofile/op_model_ppro.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "op_x86_model.h"
 #include "op_counter.h"
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index ac5622f..bfa6002 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -72,7 +72,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h

[Xen-devel] [PATCH v25 12/15] x86/VPMU: Handle PMU interrupts for PV(H) guests

Add support for handling PMU interrupts for PV(H) guests.

VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush
hypercall. This allows the guest to access PMU MSR values that are stored in
VPMU context which is shared between hypervisor and domain, thus avoiding
traps to hypervisor.

Since the interrupt handler may now force VPMU context save (i.e. set
VPMU_CONTEXT_SAVE flag) we need to make changes to amd_vpmu_save() which
until now expected this flag to be set only when the counters were stopped.

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
Acked-by: Kevin Tian 
---
Changes in v25:
* Replaced 'int num_enabled' with 'bool_t is_running' in amd_vpmu_load()
* Partially restored comment in amd_vpmu_save()
* Replaced sizeof(*ctxt) with offsetof() svm_vpmu_initialise()'s memcpy
* Replaced a couple of returns with 'ret=-E...' in do_xenpmu_op()


 xen/arch/x86/hvm/svm/vpmu.c   |  92 ++---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 108 ++-
 xen/arch/x86/hvm/vpmu.c   | 269 ++
 xen/include/asm-x86/hvm/vpmu.h|  10 +-
 xen/include/public/arch-x86/pmu.h |  41 +-
 xen/include/public/pmu.h  |   2 +
 xen/include/xsm/dummy.h   |   4 +-
 xen/xsm/flask/hooks.c |   2 +
 8 files changed, 467 insertions(+), 61 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index 934f1b7..17272cb 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -46,6 +46,9 @@ static const u32 __read_mostly *counters;
 static const u32 __read_mostly *ctrls;
 static bool_t __read_mostly k7_counters_mirrored;
 
+/* Total size of PMU registers block (copied to/from PV(H) guest) */
+static unsigned int __read_mostly regs_sz;
+
 #define F10H_NUM_COUNTERS   4
 #define F15H_NUM_COUNTERS   6
 #define MAX_NUM_COUNTERSF15H_NUM_COUNTERS
@@ -158,7 +161,7 @@ static void amd_vpmu_init_regs(struct xen_pmu_amd_ctxt 
*ctxt)
 unsigned i;
 uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
-memset(&ctxt->regs[0], 0, 2 * sizeof(uint64_t) * num_counters);
+memset(&ctxt->regs[0], 0, regs_sz);
 for ( i = 0; i < num_counters; i++ )
 ctrl_regs[i] = ctrl_rsvd[i];
 }
@@ -211,27 +214,65 @@ static inline void context_load(struct vcpu *v)
 }
 }
 
-static void amd_vpmu_load(struct vcpu *v)
+static int amd_vpmu_load(struct vcpu *v, bool_t from_guest)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct xen_pmu_amd_ctxt *ctxt = vpmu->context;
-uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
+struct xen_pmu_amd_ctxt *ctxt;
+uint64_t *ctrl_regs;
+unsigned int i;
 
 vpmu_reset(vpmu, VPMU_FROZEN);
 
-if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
+if ( !from_guest && vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
 {
-unsigned int i;
+ctxt = vpmu->context;
+ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
 
 for ( i = 0; i < num_counters; i++ )
 wrmsrl(ctrls[i], ctrl_regs[i]);
 
-return;
+return 0;
+}
+
+if ( from_guest )
+{
+bool_t is_running = 0;
+struct xen_pmu_amd_ctxt *guest_ctxt = &vpmu->xenpmu_data->pmu.c.amd;
+
+ASSERT(!is_hvm_vcpu(v));
+
+ctxt = vpmu->context;
+ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
+
+memcpy(&ctxt->regs[0], &guest_ctxt->regs[0], regs_sz);
+
+for ( i = 0; i < num_counters; i++ )
+{
+if ( (ctrl_regs[i] & CTRL_RSVD_MASK) != ctrl_rsvd[i] )
+{
+/*
+ * Not necessary to re-init context since we should never load
+ * it until guest provides valid values. But just to be safe.
+ */
+amd_vpmu_init_regs(ctxt);
+return -EINVAL;
+}
+
+if ( is_pmu_enabled(ctrl_regs[i]) )
+is_running = 1;
+}
+
+if ( is_running )
+vpmu_set(vpmu, VPMU_RUNNING);
+else
+vpmu_reset(vpmu, VPMU_RUNNING);
 }
 
 vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
 
 context_load(v);
+
+return 0;
 }
 
 static inline void context_save(struct vcpu *v)
@@ -246,22 +287,18 @@ static inline void context_save(struct vcpu *v)
 rdmsrl(counters[i], counter_regs[i]);
 }
 
-static int amd_vpmu_save(struct vcpu *v)
+static int amd_vpmu_save(struct vcpu *v,  bool_t to_guest)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 unsigned int i;
 
-/*
- * Stop the counters. If we came here via vpmu_save_force (i.e.
- * when VPMU_CONTEXT_SAVE is set) counters are already stopped.
- */
+/* Stop the counters. */
+for ( i = 0; i < num_counters; i++ )
+wrmsrl(ctrls[i], 0);
+
 if ( !vpmu_is_set(vpmu, VPMU_CONTEXT_SAVE) )
 {
 vpmu_set(vpmu, VPMU_FROZEN);
-
-for ( i = 0; i < num_counters; i++ )
-wrmsrl(ctrls[i], 0);
-
 return 0;
 }
 
@@ -2

[Xen-devel] [PATCH v25 10/15] x86/VPMU: Use pre-computed masks when checking validity of MSRs

No need to compute those masks on every MSR access.

Also, when checking MSR_P6_EVNTSELx registers make sure that bit 21
(which is a reserved bit) is not set.

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
---
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 089154e..166277a 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -80,9 +80,16 @@ static bool_t __read_mostly full_width_write;
 #define FIXED_CTR_CTRL_BITS 4
 #define FIXED_CTR_CTRL_MASK ((1 << FIXED_CTR_CTRL_BITS) - 1)
 
+#define ARCH_CNTR_ENABLED   (1ULL << 22)
+
 /* Number of general-purpose and fixed performance counters */
 static unsigned int __read_mostly arch_pmc_cnt, fixed_pmc_cnt;
 
+/* Masks used for testing whether and MSR is valid */
+#define ARCH_CTRL_MASK  (~((1ull << 32) - 1) | (1ull << 21))
+static uint64_t __read_mostly fixed_ctrl_mask, fixed_counters_mask;
+static uint64_t __read_mostly global_ovf_ctrl_mask;
+
 /*
  * QUIRK to workaround an issue on various family 6 cpus.
  * The issue leads to endless PMC interrupt loops on the processor.
@@ -479,9 +486,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 
 ASSERT(!supported);
 
-if ( type == MSR_TYPE_COUNTER &&
- (msr_content &
-  ~((1ull << core2_get_bitwidth_fix_count()) - 1)) )
+if ( (type == MSR_TYPE_COUNTER) && (msr_content & fixed_counters_mask) )
 /* Writing unsupported bits to a fixed counter */
 return -EINVAL;
 
@@ -490,9 +495,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 switch ( msr )
 {
 case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
-if ( msr_content & ~(0xC000 |
- (((1ULL << fixed_pmc_cnt) - 1) << 32) |
- ((1ULL << arch_pmc_cnt) - 1)) )
+if ( msr_content & global_ovf_ctrl_mask )
 return -EINVAL;
 core2_vpmu_cxt->global_status &= ~msr_content;
 wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
@@ -526,8 +529,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 core2_vpmu_cxt->global_ctrl = msr_content;
 break;
 case MSR_CORE_PERF_FIXED_CTR_CTRL:
-if ( msr_content &
- ( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
+if ( msr_content & fixed_ctrl_mask )
 return -EINVAL;
 
 if ( has_hvm_container_vcpu(v) )
@@ -556,7 +558,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 struct xen_pmu_cntr_pair *xen_pmu_cntr_pair =
 vpmu_reg_pointer(core2_vpmu_cxt, arch_counters);
 
-if ( msr_content & (~((1ull << 32) - 1)) )
+if ( msr_content & ARCH_CTRL_MASK )
 return -EINVAL;
 
 if ( has_hvm_container_vcpu(v) )
@@ -565,7 +567,7 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 else
 rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 
-if ( msr_content & (1ULL << 22) )
+if ( msr_content & ARCH_CNTR_ENABLED )
 *enabled_cntrs |= 1ULL << tmp;
 else
 *enabled_cntrs &= ~(1ULL << tmp);
@@ -915,6 +917,12 @@ int __init core2_vpmu_init(void)
 rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
 full_width_write = (caps >> 13) & 1;
 
+fixed_ctrl_mask = ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1);
+fixed_counters_mask = ~((1ull << core2_get_bitwidth_fix_count()) - 1);
+global_ovf_ctrl_mask = ~(0xC000 |
+ (((1ULL << fixed_pmc_cnt) - 1) << 32) |
+ ((1ULL << arch_pmc_cnt) - 1));
+
 check_pmc_quirk();
 
 if ( sizeof(struct xen_pmu_data) + sizeof(uint64_t) * fixed_pmc_cnt +
-- 
1.8.1.4


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

[Xen-devel] [PATCH v25 09/15] x86/VPMU: Add support for PMU register handling on PV guests

Intercept accesses to PMU MSRs and process them in VPMU module. If vpmu ops
for VCPU are not initialized (which is the case, for example, for PV guests that
are not "VPMU-enlightened") access to MSRs will return failure.

Dump VPMU state for all domains (HVM and PV) when requested.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Acked-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/domain.c |  3 +--
 xen/arch/x86/hvm/vmx/vpmu_core2.c | 49 +++--
 xen/arch/x86/hvm/vpmu.c   |  3 +++
 xen/arch/x86/traps.c  | 51 +--
 4 files changed, 95 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 11197e4..be4963f 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -2075,8 +2075,7 @@ void arch_dump_vcpu_info(struct vcpu *v)
 {
 paging_dump_vcpu_info(v);
 
-if ( is_hvm_vcpu(v) )
-vpmu_dump(v);
+vpmu_dump(v);
 }
 
 void domain_cpuid(
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 9710149..089154e 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -299,12 +300,18 @@ static inline void __core2_vpmu_save(struct vcpu *v)
 rdmsrl(MSR_CORE_PERF_FIXED_CTR0 + i, fixed_counters[i]);
 for ( i = 0; i < arch_pmc_cnt; i++ )
 rdmsrl(MSR_IA32_PERFCTR0 + i, xen_pmu_cntr_pair[i].counter);
+
+if ( !has_hvm_container_vcpu(v) )
+rdmsrl(MSR_CORE_PERF_GLOBAL_STATUS, core2_vpmu_cxt->global_status);
 }
 
 static int core2_vpmu_save(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 
+if ( !has_hvm_container_vcpu(v) )
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, 0);
+
 if ( !vpmu_are_all_set(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED) )
 return 0;
 
@@ -342,6 +349,13 @@ static inline void __core2_vpmu_load(struct vcpu *v)
 wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
 wrmsrl(MSR_IA32_DS_AREA, core2_vpmu_cxt->ds_area);
 wrmsrl(MSR_IA32_PEBS_ENABLE, core2_vpmu_cxt->pebs_enable);
+
+if ( !has_hvm_container_vcpu(v) )
+{
+wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, core2_vpmu_cxt->global_ovf_ctrl);
+core2_vpmu_cxt->global_ovf_ctrl = 0;
+wrmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
+}
 }
 
 static void core2_vpmu_load(struct vcpu *v)
@@ -433,7 +447,6 @@ static int core2_vpmu_msr_common_check(u32 msr_index, int 
*type, int *index)
 static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content,
uint64_t supported)
 {
-u64 global_ctrl;
 int i, tmp;
 int type = -1, index = -1;
 struct vcpu *v = current;
@@ -477,7 +490,12 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 switch ( msr )
 {
 case MSR_CORE_PERF_GLOBAL_OVF_CTRL:
+if ( msr_content & ~(0xC000 |
+ (((1ULL << fixed_pmc_cnt) - 1) << 32) |
+ ((1ULL << arch_pmc_cnt) - 1)) )
+return -EINVAL;
 core2_vpmu_cxt->global_status &= ~msr_content;
+wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
 return 0;
 case MSR_CORE_PERF_GLOBAL_STATUS:
 gdprintk(XENLOG_INFO, "Can not write readonly MSR: "
@@ -505,14 +523,18 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
 return 0;
 case MSR_CORE_PERF_GLOBAL_CTRL:
-global_ctrl = msr_content;
+core2_vpmu_cxt->global_ctrl = msr_content;
 break;
 case MSR_CORE_PERF_FIXED_CTR_CTRL:
 if ( msr_content &
  ( ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1)) )
 return -EINVAL;
 
-vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+if ( has_hvm_container_vcpu(v) )
+vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+   &core2_vpmu_cxt->global_ctrl);
+else
+rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 *enabled_cntrs &= ~(((1ULL << fixed_pmc_cnt) - 1) << 32);
 if ( msr_content != 0 )
 {
@@ -537,7 +559,11 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 if ( msr_content & (~((1ull << 32) - 1)) )
 return -EINVAL;
 
-vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL, &global_ctrl);
+if ( has_hvm_container_vcpu(v) )
+vmx_read_guest_msr(MSR_CORE_PERF_GLOBAL_CTRL,
+   &core2_vpmu_cxt->global_ctrl);
+else
+rdmsrl(MSR_CORE_PERF_GLOBAL_CTRL, core2_vpmu_cxt->global_ctrl);
 
 if ( msr

[Xen-devel] [PATCH v25 04/15] x86/VPMU: Interface for setting PMU mode and flags

Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF:  PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
  can profile itself and the hypervisor.

Note that PMU modes are different from what can be provided at Xen's boot line
with 'vpmu' argument. An 'off' (or '0') value is equivalent to XENPMU_MODE_OFF.
Any other value, on the other hand, will cause VPMU mode to be set to
XENPMU_MODE_SELF during boot.

For feature flags only Intel's BTS is currently supported.

Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 

---
Changes in v25:
* Added (vpmu_features == pmu_params.val) check in do_xenpmu_op:XENPMU_mode_get
  case (for consistency)
* Replaced 'return -EFAULT' with 'ret=-EFAULT' in XENPMU_feature_get


 tools/flask/policy/policy/modules/xen/xen.te |   3 +
 xen/arch/x86/domain.c|   4 +-
 xen/arch/x86/hvm/svm/vpmu.c  |   4 +-
 xen/arch/x86/hvm/vmx/vpmu_core2.c|  10 +-
 xen/arch/x86/hvm/vpmu.c  | 159 +--
 xen/arch/x86/x86_64/compat/entry.S   |   4 +
 xen/arch/x86/x86_64/entry.S  |   4 +
 xen/include/asm-x86/hvm/vpmu.h   |  27 +++--
 xen/include/public/pmu.h |  46 
 xen/include/public/xen.h |   1 +
 xen/include/xen/hypercall.h  |   4 +
 xen/include/xlat.lst |   1 +
 xen/include/xsm/dummy.h  |  15 +++
 xen/include/xsm/xsm.h|   6 +
 xen/xsm/dummy.c  |   1 +
 xen/xsm/flask/hooks.c|  18 +++
 xen/xsm/flask/policy/access_vectors  |   2 +
 17 files changed, 284 insertions(+), 25 deletions(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index 51f59c5..45b5cb2 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -68,6 +68,9 @@ allow dom0_t xen_t:xen2 {
 resource_op
 psr_cmt_op
 };
+allow dom0_t xen_t:xen2 {
+pmu_ctrl
+};
 allow dom0_t xen_t:mmu memorymap;
 
 # Allow dom0 to use these domctls on itself. For domctls acting on other
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 0363650..dc18565 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1546,7 +1546,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 if ( is_hvm_domain(prevd) )
 {
 if (prev != next)
-vpmu_save(prev);
+vpmu_switch_from(prev);
 
 if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
 pt_save_timer(prev);
@@ -1591,7 +1591,7 @@ void context_switch(struct vcpu *prev, struct vcpu *next)
 
 if (is_hvm_domain(nextd) && (prev != next) )
 /* Must be done with interrupts enabled */
-vpmu_load(next);
+vpmu_switch_to(next);
 
 context_saved(prev);
 
diff --git a/xen/arch/x86/hvm/svm/vpmu.c b/xen/arch/x86/hvm/svm/vpmu.c
index a8b79df..481ea7b 100644
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -472,14 +472,14 @@ struct arch_vpmu_ops amd_vpmu_ops = {
 .arch_vpmu_dump = amd_vpmu_dump
 };
 
-int svm_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int svm_vpmu_initialise(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 uint8_t family = current_cpu_data.x86;
 int ret = 0;
 
 /* vpmu enabled? */
-if ( !vpmu_flags )
+if ( vpmu_mode == XENPMU_MODE_OFF )
 return 0;
 
 switch ( family )
diff --git a/xen/arch/x86/hvm/vmx/vpmu_core2.c 
b/xen/arch/x86/hvm/vmx/vpmu_core2.c
index 6fc634c..cfcdf42 100644
--- a/xen/arch/x86/hvm/vmx/vpmu_core2.c
+++ b/xen/arch/x86/hvm/vmx/vpmu_core2.c
@@ -708,13 +708,13 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 return 1;
 }
 
-static int core2_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+static int core2_vpmu_initialise(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 u64 msr_content;
 static bool_t ds_warned;
 
-if ( !(vpmu_flags & VPMU_BOOT_BTS) )
+if ( !(vpmu_features & XENPMU_FEATURE_INTEL_BTS) )
 goto func_out;
 /* Check the 'Debug Store' feature in the CPUID.EAX[1]:EDX[21] */
 while ( boot_cpu_has(X86_FEATURE_DS) )
@@ -826,7 +826,7 @@ struct arch_vpmu_ops core2_no_vpmu_ops = {
 .do_cpuid = core2_no_vpmu_do_cpuid,
 };
 
-int vmx_vpmu_initialise(struct vcpu *v, unsigned int vpmu_flags)
+int vmx_vpmu_initialise(struct vcpu *v)
 {
 struct vpmu_struct *vpmu = vcpu_vpmu(v);
 uint8_t family = current_cpu_data.x86;
@@ -834,7 +834,7 @@ int vmx_vpmu_initialise(struct vcpu *v, unsigned int 
vpmu_flags)
 int ret = 0;
 
 vpmu->arch_vpm

[Xen-devel] [PATCH v25 01/15] common/symbols: Export hypervisor symbols to privileged guest

Export Xen's symbols as {} triplet via new XENPF_get_symbol
hypercall

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel De Graaf 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/arch/x86/platform_hypercall.c   | 28 +++
 xen/common/symbols.c| 54 +
 xen/include/public/platform.h   | 19 +
 xen/include/xen/symbols.h   |  3 +++
 xen/include/xlat.lst|  1 +
 xen/xsm/flask/hooks.c   |  4 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 7 files changed, 111 insertions(+)

diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index 334d474..7626261 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -798,6 +799,33 @@ ret_t 
do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
 }
 break;
 
+case XENPF_get_symbol:
+{
+static char name[KSYM_NAME_LEN + 1]; /* protected by xenpf_lock */
+XEN_GUEST_HANDLE(char) nameh;
+uint32_t namelen, copylen;
+
+guest_from_compat_handle(nameh, op->u.symdata.name);
+
+ret = xensyms_read(&op->u.symdata.symnum, &op->u.symdata.type,
+   &op->u.symdata.address, name);
+
+namelen = strlen(name) + 1;
+
+if ( namelen > op->u.symdata.namelen )
+copylen = op->u.symdata.namelen;
+else
+copylen = namelen;
+
+op->u.symdata.namelen = namelen;
+
+if ( !ret && copy_to_guest(nameh, name, copylen) )
+ret = -EFAULT;
+if ( !ret && __copy_field_to_guest(u_xenpf_op, op, u.symdata) )
+ret = -EFAULT;
+}
+break;
+
 default:
 ret = -ENOSYS;
 break;
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index fc7c9e7..a59c59d 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #ifdef SYMBOLS_ORIGIN
 extern const unsigned int symbols_offsets[];
@@ -148,3 +150,55 @@ const char *symbols_lookup(unsigned long addr,
 *offset = addr - symbols_address(low);
 return namebuf;
 }
+
+/*
+ * Get symbol type information. This is encoded as a single char at the
+ * beginning of the symbol name.
+ */
+static char symbols_get_symbol_type(unsigned int off)
+{
+/*
+ * Get just the first code, look it up in the token table,
+ * and return the first char from this token.
+ */
+return symbols_token_table[symbols_token_index[symbols_names[off + 1]]];
+}
+
+int xensyms_read(uint32_t *symnum, char *type,
+ uint64_t *address, char *name)
+{
+/*
+ * Symbols are most likely accessed sequentially so we remember position
+ * from previous read. This can help us avoid the extra call to
+ * get_symbol_offset().
+ */
+static uint64_t next_symbol, next_offset;
+static DEFINE_SPINLOCK(symbols_mutex);
+
+if ( *symnum > symbols_num_syms )
+return -ERANGE;
+if ( *symnum == symbols_num_syms )
+{
+/* No more symbols */
+name[0] = '\0';
+return 0;
+}
+
+spin_lock(&symbols_mutex);
+
+if ( *symnum == 0 )
+next_offset = next_symbol = 0;
+if ( next_symbol != *symnum )
+/* Non-sequential access */
+next_offset = get_symbol_offset(*symnum);
+
+*type = symbols_get_symbol_type(next_offset);
+next_offset = symbols_expand_symbol(next_offset, name);
+*address = symbols_address(*symnum);
+
+next_symbol = ++*symnum;
+
+spin_unlock(&symbols_mutex);
+
+return 0;
+}
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 82ec84e..1e6a6ce 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -590,6 +590,24 @@ struct xenpf_resource_op {
 typedef struct xenpf_resource_op xenpf_resource_op_t;
 DEFINE_XEN_GUEST_HANDLE(xenpf_resource_op_t);
 
+#define XENPF_get_symbol   63
+struct xenpf_symdata {
+/* IN/OUT variables */
+uint32_t namelen; /* IN:  size of name buffer   */
+  /* OUT: strlen(name) of hypervisor symbol (may be */
+  /*  larger than what's been copied to guest)  */
+uint32_t symnum;  /* IN:  Symbol to read*/
+  /* OUT: Next available symbol. If same as IN then */
+  /*  we reached the end*/
+
+/* OUT variables */
+XEN_GUEST_HANDLE(char) name;
+uint64_t address;
+char type;
+};
+typedef struct xenpf_symdata xenpf_symdata_t;
+DEFINE_XEN_GUEST_HANDLE(xenpf_symdata_t);
+
 /*
  * ` enum neg_errnoval
  * ` HYPERVISOR_platform_op(const struct xen_platform_op*);
@@ -619,6 +637,7 @@ struct xen_platform_op {
 struct xenpf_m

[Xen-devel] [PATCH v25 00/15] x86/PMU: Xen PMU PV(H) support

Changes in v25:
* Add extra check for consistency in patch 4
* Replace few returns with 'ret = -E...' (patches 4 and 12)
* Clarified commit message in patch 8
* A couple of cosmetic changes in patch 12
(I left AMD multi-counter problem unfixed since what I thought would
 be sufficient to fix it did not quite work and I don't want to do
 a partial fix)

Changes in v24:
* Make sure we follow read-once rule in hypervisor by copying data from
guest first (patch 12)
* Move MSR area pointers to the top on Intel structure (patch 2)
* Provde zero-sized arrays in public headers (patch 2)
* Return error code on PMU MSR access faults (patch 8)
* Initialize AMD counters to reserved values as opposed to zeroes
  (patch 11) (I also noticed that Intel counters similarly start with
  zeroes, which technically is not correct. I might fix it but not
  in this series)
* Make sure MSR pointers inside shared structure are not modified by
  guest (patch 12).

Changes in v23:
* In patch 2, replaced LVTPC and xen_pmu__ctxt unions in struct
  xen_pmu_arch with pad placeholders. They become actual memobers (as
  before) in patch 12, when they are first used.
* Added dummy struct member to ARM's struct xen_pmu_data definition
  (patch 2)
* Clarified changes in patch 10 commit message
* Added patch 11 to verify MSR value before writing it to HW in
  amd_vpmu_do_wrmsr()
* Verify MSRs before copying them into context on AMD (patch 12)


Changes in v22:
* Clarified access permissions on shared fileds (patch 2)
* Added ARCH_CNTR_ENABLED macro (patch 10)
* Use hypervisor-private VPMU_CACHED instead of shared PMU_CACHED
  (patch 11)
* A few cleanups (patch 11)

Changes in v21:

* Keep running VPMU's context private to hypervisor and expose
  it only during interrupt handling. Verify content of guest-updated
  context before loading into HW. Affected patches are 6 and (mostly) 11.
* Pre-compute some of the masks used for verification (new patch 10)
* Document shared data in public header files
* A couple of ARM-related fixes (patches 1 and 2)

Changes in v20:

* Made xen_pmu_data's domain_id a domid_t type, resulting in
  layout/padding changes (patches 2 and 10)
* Added compat checks for xen_pmu_data (patch 2)
* Clarified how vpmu_count is used in a comment (patch 6)
* Moved page management from under vpmu_lock (patch 6)
* Other (mostly style-related) changes in per-patch notes


Changes in v19:

* Do not allow changing mode to/from OFF/ALL while guests are
  running. This significantly simplifies code due
  to large number of corner cases that I had to deal with. Most of the
  changes are in patch#5. This also makes patch 4 from last version
  unnecessary
* Defer NMI support (drop patch#14 from last version)
* Make patch#15 from last series be patch#1 (vpmu init cleanup)
* Other changes are listed per patch


Changes in v18:

* Return 1 (i.e. "handled") in vpmu_do_interrupt() if PMU_CACHED is
  set. This is needed since we can get an interrupt while this flag is
  set on AMD processors when multiple counters are in use (**) (AMD
  processor don't mask LVTPC when PMC interrupt happens and so there
  is a window in vpmu_do_interrupt() until it sets the mask
  bit). Patch #14
* Unload both current and last_vcpu (if different) vpmu and clear
  this_cpu(last_vcpu) in vpmu_unload_all. Patch #5
* Make major version check for certain xenpmu_ops. Patch #5
* Make xenpmu_op()'s first argument unsigned. Patch #5
* Don't use format specifier for __stringify(). Patch #6
* Don't print generic error in vpmu_init(). Patch #6
* Don't test for VPMU existance in vpmu_initialise(). New patch #15
* Added vpmu_disabled flag to make sure VPMU doesn't get reenabled from
  dom0 (for example when watchdog is active). Patch #5
* Updated tags on some patches to better reflect latest reviewed status)

(**) While testing this I discovered that AMD VPMU is quite broken for
HVM: when multiple counters are in use linux dom0 often gets
unexpected NMIs. This may have something to do with what I mentioned
in the first bullet. However, this doesn't appear to be related to
this patch series (or earlier VPMU patches) --- I can reproduce this
all the way back to 4.1

Changes in v17:
* Disable VPMU when unknown CPU vendor is detected (patch #2)
* Remove unnecessary vendor tests in vendor-specific init routines (patch #14)
* Remember first CPU that starts mode change and use it to stop the cycle 
(patch #13)
* If vpmu ops is not present, return 0 as value for VPMU MSR read (as opposed 
to 
  returning an error as was the case in previous patch.) (patch #18)
  * Change slightly vpmu_do_msr() logic as result of this chage (patch #20)
* stringify VPMU version (patch #14)
* Use 'CS > 1' to mark sample as PMU_SAMPLE_USER (patch #19)

Changes in v16:

* Many changes in VPMU mode patch (#13):
  * Replaced arguments to some vpmu routines (vcpu -> vpmu). New patch (#12)
  * Added vpmu_unload vpmu op to completely unload vpmu data (e.g clear
MSR bitmaps). This routine may be called in c

[Xen-devel] [PATCH v25 07/15] x86/VPMU: Save VPMU state for PV guests during context switch

Save VPMU state during context switch for both HVM and PV(H) guests.

A subsequent patch ("x86/VPMU: NMI-based VPMU support") will make it possible
for vpmu_switch_to() to call vmx_vmcs_try_enter()->vcpu_pause() which needs
is_running to be correctly set/cleared. To prepare for that, call 
context_saved()
before vpmu_switch_to() is executed. (Note that while this change could have
been dalayed until that later patch, the changes are harmless to existing code
and so we do it here)

Signed-off-by: Boris Ostrovsky 

---
Changes in v25:
* Replaced is_hvm_vcpu with is_hvm_domain to be consistent with recent changes
 to context_switch()

 xen/arch/x86/domain.c | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index b699f68..11197e4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1543,17 +1543,14 @@ void context_switch(struct vcpu *prev, struct vcpu 
*next)
 }
 
 if ( prev != next )
-_update_runstate_area(prev);
-
-if ( is_hvm_domain(prevd) )
 {
-if (prev != next)
-vpmu_switch_from(prev);
-
-if ( !list_empty(&prev->arch.hvm_vcpu.tm_list) )
-pt_save_timer(prev);
+_update_runstate_area(prev);
+vpmu_switch_from(prev);
 }
 
+if ( is_hvm_domain(prevd) && !list_empty(&prev->arch.hvm_vcpu.tm_list) )
+pt_save_timer(prev);
+
 local_irq_disable();
 
 set_current(next);
@@ -1591,15 +1588,16 @@ void context_switch(struct vcpu *prev, struct vcpu 
*next)
!is_hardware_domain(nextd));
 }
 
-if (is_hvm_domain(nextd) && (prev != next) )
-/* Must be done with interrupts enabled */
-vpmu_switch_to(next);
-
 context_saved(prev);
 
 if ( prev != next )
+{
 _update_runstate_area(next);
 
+/* Must be done with interrupts enabled */
+vpmu_switch_to(next);
+}
+
 /* Ensure that the vcpu has an up-to-date time base. */
 update_vcpu_system_time(next);
 
-- 
1.8.1.4


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

[Xen-devel] [PATCH v25 03/15] x86/VPMU: Make vpmu not HVM-specific

vpmu structure will be used for both HVM and PV guests. Move it from
hvm_vcpu to arch_vcpu.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
Reviewed-by: Kevin Tian 
Reviewed-by: Dietmar Hahn 
Tested-by: Dietmar Hahn 
---
 xen/include/asm-x86/domain.h   | 2 ++
 xen/include/asm-x86/hvm/vcpu.h | 3 ---
 xen/include/asm-x86/hvm/vpmu.h | 5 ++---
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 5eb6832..908d63f 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -451,6 +451,8 @@ struct arch_vcpu
 void (*ctxt_switch_from) (struct vcpu *);
 void (*ctxt_switch_to) (struct vcpu *);
 
+struct vpmu_struct vpmu;
+
 /* Virtual Machine Extensions */
 union {
 struct pv_vcpu pv_vcpu;
diff --git a/xen/include/asm-x86/hvm/vcpu.h b/xen/include/asm-x86/hvm/vcpu.h
index 3d8f4dc..0faf60d 100644
--- a/xen/include/asm-x86/hvm/vcpu.h
+++ b/xen/include/asm-x86/hvm/vcpu.h
@@ -151,9 +151,6 @@ struct hvm_vcpu {
 u32 msr_tsc_aux;
 u64 msr_tsc_adjust;
 
-/* VPMU */
-struct vpmu_struct  vpmu;
-
 union {
 struct arch_vmx_struct vmx;
 struct arch_svm_struct svm;
diff --git a/xen/include/asm-x86/hvm/vpmu.h b/xen/include/asm-x86/hvm/vpmu.h
index 83eea7e..82bfa0e 100644
--- a/xen/include/asm-x86/hvm/vpmu.h
+++ b/xen/include/asm-x86/hvm/vpmu.h
@@ -31,9 +31,8 @@
 #define VPMU_BOOT_ENABLED 0x1/* vpmu generally enabled. */
 #define VPMU_BOOT_BTS 0x2/* Intel BTS feature wanted. */
 
-#define vcpu_vpmu(vcpu)   (&((vcpu)->arch.hvm_vcpu.vpmu))
-#define vpmu_vcpu(vpmu)   (container_of((vpmu), struct vcpu, \
-  arch.hvm_vcpu.vpmu))
+#define vcpu_vpmu(vcpu)   (&(vcpu)->arch.vpmu)
+#define vpmu_vcpu(vpmu)   container_of((vpmu), struct vcpu, arch.vpmu)
 
 #define MSR_TYPE_COUNTER0
 #define MSR_TYPE_CTRL   1
-- 
1.8.1.4


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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 58723

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

version targeted for testing:
 ovmf 9d6d8582ad2c88e611046e4391df607431571cf6
baseline version:
 ovmf 6ef586442e03f183fb0e93177f32ad541119adb6


People who touched revisions under test:
  Hess Chen 
  Star Zeng 


jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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

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


Not pushing.


commit 9d6d8582ad2c88e611046e4391df607431571cf6
Author: Star Zeng 
Date:   Fri Jun 19 00:42:16 2015 +

Remove Include/ directory.

It was committed into root directory by mistake at R17657.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17663 
6f19259b-4bc3-4df7-8a09-765794883524

commit 510f154ea26776aab01f6cfe295b21bb6b2a2aa8
Author: Hess Chen 
Date:   Fri Jun 19 00:05:25 2015 +

BaseTools/Upt: Update help message

Update help message of UPT to remove Intel(R) from the string.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen 
Reviewed-by: lhauch 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17662 
6f19259b-4bc3-4df7-8a09-765794883524

commit af0c61aefcc6fa2f86183aa165e96398899a6610
Author: Hess Chen 
Date:   Fri Jun 19 00:02:34 2015 +

BaseTools/Upt: Update error message

Update error message of installation failure to avoid confusion.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen 
Reviewed-by: lhauch 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17661 
6f19259b-4bc3-4df7-8a09-765794883524

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

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

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 11 guest-start  fail blocked in 58721
 test-amd64-i386-libvirt  11 guest-start  fail   like 58721
 test-amd64-i386-libvirt-xsm  11 guest-start  fail   like 58721
 test-amd64-amd64-libvirt 11 guest-start  fail   like 58721
 test-armhf-armhf-libvirt 11 guest-start  fail   like 58721

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 11 guest-start  fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 qemuu8ffe756da0481233e1bd518b2b16489f51856292
baseline version:
 qemuue20752775197d3606c50703422d2c5d53ecf54bb


People who touched revisions under test:
  Mark Cave-Ayland 
  Markus Armbruster 
  Peter Maydell 


jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale  pass
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck   fail
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-xl-pvh-intelfail
 test-amd64-i386-qemuu-rhel6hvm-intel

Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

2015-06-19 Thread David Vrabel

On 19/06/15 14:04, Jan Beulich wrote:
 On 19.06.15 at 14:23,  wrote:
>> On 19/06/15 11:55, Jan Beulich wrote:
>> On 19.06.15 at 11:52,  wrote:
 On 19/06/15 10:29, Jan Beulich wrote:
 On 18.06.15 at 12:40,  wrote:
>> On 18/06/15 11:36, Jan Beulich wrote:
>> On 17.06.15 at 14:02,  wrote:
 --- a/xen/common/event_channel.c
 +++ b/xen/common/event_channel.c
 @@ -1175,22 +1175,6 @@ int alloc_unbound_xen_event_channel(
  
  void free_xen_event_channel(struct domain *d, int port)
  {
 -struct evtchn *chn;
 -
 -spin_lock(&d->event_lock);
 -
 -if ( unlikely(d->is_dying) )
 -{
 -spin_unlock(&d->event_lock);
 -return;
 -}
 -
 -BUG_ON(!port_is_valid(d, port));
>>
>> I can keep this one.
>>
 -chn = evtchn_from_port(d, port);
 -BUG_ON(!consumer_is_xen(chn));
>>>
>>> At least in debug builds I think these would better be retained.
>>
>> But this one has to go because it will always trip when
>> free_xen_event_channel() is called after evtchn_destroy() (which will
>> have cleared xen_consumer).
>
> Then why not
>
> BUG_ON(!consumer_is_xen(chn) && !d->is_dying);
>
> or keep the d->is_dying check in place? I can see why accelerating
> notify_via_xen_event_channel() is useful, but
> free_xen_event_channel()?

 This BUG_ON() is a pretty weak check and I don't really see the point of
 it.  I'm not respinning v4 just for this.
>>>
>>> I'm not sure what makes this more weak than the other BUG_ON()
>>> you agreed to retain - both try to validate that the callers don't do
>>> bad things. Admitted, both would better be ASSERT()s...
>>>
>>> As to spinning v4 - I see no need, as I can easily adjust this while
>>> committing, as long as you don't disagree to have your name under
>>> the result.
>>
>> I disagree.
>>
>> For this assert to be safe it needs to take suitable locks such as:
>>
>> #ifdef DEBUG
>> struct evtchn *chn;
>>
>> chn = evtchn_from_port(d, port);
>> spin_lock(&chn->lock);
>> BUG_ON(chn->state != ECS_FREE && !consumer_is_xen(chn));
>> spin_unlock(&chn->lock);
>> #endif
>>
>> or if you want the is_dying check, you need the event lock instead.
>>
>> I wrote the first one, saw it was lots of noise for almost no gain and
>> threw it away.
> 
> Which is why as an alternative I suggested not to touch
> free_xen_event_channel() at all in this patch.

I found the this is_dying check confusing and since it is now
unnecessary and not very useful it is better to remove it to make the
code easier for others to understand.

David


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

Re: [Xen-devel] [libvirt] [PATCH libvirt] libxl: avoid freeing an uninitialised bitmap

2015-06-19 Thread Eric Blake

On 06/19/2015 10:33 AM, Ian Campbell wrote:
> If vm->def->cputune.nvcpupin is 0 in libxlDomainSetVcpuAffinities (as
> seems to be the case on arm) then the VIR_FREE after cleanup: would be
> operating on an uninitialised pointer in map.map.
> 
> Fix this by using libxl_bitmap_init and libxl_bitmap_dispose in the
> appropriate places (like VIR_FREE libxl_bitmap_dispose is also

s/VIR_FREE/VIR_FREE,/

> idempotent, so there is no double free on exit from the loop).
> 
> libxl_bitmap_dispose is slightly preferable since it also sets
> map.size back to 0, avoiding a potential source of confusion.
> 
> This fixes the crashes we've been seeing in the Xen automated tests on
> ARM.
> 
> I had a glance at the handful of other users of libxl_bitmap and none
> of them looked to have a similar issue.
> 
> Signed-off-by: Ian Campbell 
> ---
>  src/libxl/libxl_domain.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

ACK.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH libvirt] libxl: avoid freeing an uninitialised bitmap

If vm->def->cputune.nvcpupin is 0 in libxlDomainSetVcpuAffinities (as
seems to be the case on arm) then the VIR_FREE after cleanup: would be
operating on an uninitialised pointer in map.map.

Fix this by using libxl_bitmap_init and libxl_bitmap_dispose in the
appropriate places (like VIR_FREE libxl_bitmap_dispose is also
idempotent, so there is no double free on exit from the loop).

libxl_bitmap_dispose is slightly preferable since it also sets
map.size back to 0, avoiding a potential source of confusion.

This fixes the crashes we've been seeing in the Xen automated tests on
ARM.

I had a glance at the handful of other users of libxl_bitmap and none
of them looked to have a similar issue.

Signed-off-by: Ian Campbell 
---
 src/libxl/libxl_domain.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 0652270..0904b78 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -789,6 +789,8 @@ libxlDomainSetVcpuAffinities(libxlDriverPrivatePtr driver, 
virDomainObjPtr vm)
 size_t i;
 int ret = -1;
 
+libxl_bitmap_init(&map);
+
 for (i = 0; i < vm->def->cputune.nvcpupin; ++i) {
 pin = vm->def->cputune.vcpupin[i];
 cpumask = pin->cpumask;
@@ -802,13 +804,13 @@ libxlDomainSetVcpuAffinities(libxlDriverPrivatePtr 
driver, virDomainObjPtr vm)
 goto cleanup;
 }
 
-VIR_FREE(map.map);
+libxl_bitmap_dispose(&map); /* Also returns to freshly-init'd state */
 }
 
 ret = 0;
 
  cleanup:
-VIR_FREE(map.map);
+libxl_bitmap_dispose(&map);
 virObjectUnref(cfg);
 return ret;
 }
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH OSSTEST v3 12/11] toolstack/libvirt: install libnl-3-200 on Jessie

On Fri, Jun 19, 2015 at 01:05:55PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH OSSTEST v3 12/11] toolstack/libvirt: install 
> libnl-3-200 on Jessie"):
> > Signed-off-by: Wei Liu 
> ...
> > diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
> > index e7f4860..c71f88a 100644
> > --- a/Osstest/Toolstack/libvirt.pm
> > +++ b/Osstest/Toolstack/libvirt.pm
> > @@ -24,11 +24,15 @@ use Osstest::TestSupport;
> >  
> >  sub new {
> >  my ($class, $ho, $methname,$asset) = @_;
> > +my @extra_packages = qw(libavahi-client3);
> > +my $nl_lib = "libnl-3-200";
> > +$nl_lib = "libnl1" if ($ho->{Suite} =~ m/wheezy/);
> > +push(@extra_packages, $nl_lib);
> >  return bless { Name => "libvirt",
> >Host => $ho,
> >NewDaemons => [qw(libvirtd)],
> >Dom0MemFixed => 1,
> > -  ExtraPackages => [qw(libnl1 libavahi-client3)],
> > +  ExtraPackages => [@extra_packages],
> 
> It would be more normal to write
> \@extra_packages
> rather than
> [@extra_packages]
> unless you actually need to make a copy of the array.
> 
> (I don't care about this for efficiency, but rather for readability:
> writing [@extra_packages] carries an implication that something might
> edit either @extra_packages or ExtraPackages afterwards.
> 

For the record, Ian acked the following updated patch on IRC.

---8<---
>From b422cb2c6c1ecdc62a5a46212f2cf648c2141509 Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Thu, 18 Jun 2015 15:46:07 +0100
Subject: [PATCH OSSTEST] toolstack/libvirt: install libnl-3-200 on Jessie
Cc: ian.campb...@citrix.com, ian.jack...@eu.citrix.com

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 Osstest/Toolstack/libvirt.pm | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index e7f4860..51a10de 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -24,11 +24,15 @@ use Osstest::TestSupport;
 
 sub new {
 my ($class, $ho, $methname,$asset) = @_;
+my @extra_packages = qw(libavahi-client3);
+my $nl_lib = "libnl-3-200";
+$nl_lib = "libnl1" if ($ho->{Suite} =~ m/wheezy/);
+push(@extra_packages, $nl_lib);
 return bless { Name => "libvirt",
   Host => $ho,
   NewDaemons => [qw(libvirtd)],
   Dom0MemFixed => 1,
-  ExtraPackages => [qw(libnl1 libavahi-client3)],
+  ExtraPackages => \@extra_packages,
 }, $class;
 }
 
-- 
1.9.1


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

[Xen-devel] [linux-3.4 test] 58731: regressions - FAIL

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   9 debian-install fail REGR. vs. 52209-bisect
 test-amd64-amd64-pair   15 debian-install/dst_host fail REGR. vs. 52715-bisect
 test-amd64-i386-pair15 debian-install/dst_host fail REGR. vs. 56366-bisect

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt   9 debian-installfail blocked in 56366-bisect
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail blocked in 56366-bisect
 test-amd64-amd64-libvirt  9 debian-installfail blocked in 56366-bisect
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail blocked in 56366-bisect
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail blocked in 56366-bisect
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail blocked in 56366-bisect
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail blocked in 56366-bisect
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail blocked in 56366-bisect
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail blocked in 56366-bisect
 test-amd64-i386-freebsd10-i386  6 xen-bootfail blocked in 56366-bisect
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail blocked in 56366-bisect
 test-amd64-i386-xl9 debian-installfail blocked in 56366-bisect
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail blocked in 56366-bisect
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail blocked in 56366-bisect
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail blocked in 56366-bisect
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-xl-sedf  9 debian-installfail blocked in 56366-bisect
 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-xl-sedf-pin  9 debian-installfail blocked in 56366-bisect
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail blocked in 56366-bisect
 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 56366-bisect
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail blocked in 
56366-bisect
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-bootfail like 53709-bisect

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-xsm   9 debian-install   fail   never pass
 test-amd64-i386-xl-xsm9 debian-install   fail   never pass
 test-amd64-amd64-xl-pvh-amd   9 debian-install   fail   never pass
 test-amd64-amd64-xl-credit2   9 debian-install   fail   never pass
 test-amd64-amd64-xl-pvh-intel  9 debian-install   fail  never pass
 test-amd64-amd64-libvirt-xsm  9 debian-install   fail   never pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 20 leak-check/check fail 
never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 20 leak-check/check fail 
never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux56b48fcda5076d4070ab00df32ff5ff834e0be86
baseline version:
 linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70


370 people touched revisions under test,
not listing them all


jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl

Re: [Xen-devel] [PATCH OSSTEST] ts-libvirt-build: Enable debug symbols in binaries

Ian Campbell writes ("[PATCH OSSTEST] ts-libvirt-build: Enable debug symbols in 
binaries"):
> ... by passing -g as appropriate.
> 
> Also ensure debug logging is enabled with --enable-debug (which
> doesn't imply -g during build!).
> 
> Signed-off-by: Ian Campbell 

Acked-by: Ian Jackson 

And bundled into my misc queue.

Ian.

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

Re: [Xen-devel] [PATCH] xen/events/fifo: Consume unprocessed events when a CPU dies

2015-06-19 Thread David Vrabel

On 19/06/15 17:02, Boris Ostrovsky wrote:
> On 06/19/2015 11:15 AM, Ross Lagerwall wrote:
>> When a CPU is offlined, there may be unprocessed events on a port for
>> that CPU.  If the port is subsequently reused on a different CPU, it
>> could be in an unexpected state with the link bit set, resulting in
>> interrupts being missed. Fix this by consuming any unprocessed events
>> for a particular CPU when that CPU dies.
>>
>> Signed-off-by: Ross Lagerwall 
>> ---
>>   drivers/xen/events/events_fifo.c | 23 ++-
>>   1 file changed, 18 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/xen/events/events_fifo.c
>> b/drivers/xen/events/events_fifo.c
>> index 417415d..1dd0ba12 100644
>> --- a/drivers/xen/events/events_fifo.c
>> +++ b/drivers/xen/events/events_fifo.c
>> @@ -281,7 +281,8 @@ static void handle_irq_for_port(unsigned port)
>> static void consume_one_event(unsigned cpu,
>> struct evtchn_fifo_control_block *control_block,
>> -  unsigned priority, unsigned long *ready)
>> +  unsigned priority, unsigned long *ready,
>> +  bool drop)
>>   {
>>   struct evtchn_fifo_queue *q = &per_cpu(cpu_queue, cpu);
>>   uint32_t head;
>> @@ -313,13 +314,17 @@ static void consume_one_event(unsigned cpu,
>>   if (head == 0)
>>   clear_bit(priority, ready);
>>   -if (evtchn_fifo_is_pending(port) && !evtchn_fifo_is_masked(port))
>> -handle_irq_for_port(port);
>> +if (evtchn_fifo_is_pending(port) && !evtchn_fifo_is_masked(port)) {
>> +if (unlikely(drop))
>> +pr_warn("Dropping pending event for port %u\n", port);
> 
> Maybe pr_info (or pr_notice)?

We want a warning here because we think this shouldn't happen -- if it
does we actually need to retrigger the event on its new CPU.

> Also, why not do this (testing for unprocessed events) in
> xen_evtchn_close()?

We can't do anything about them when closing because they may be in the
middle of a queue.

David

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

Re: [Xen-devel] [PATCH] xen/events/fifo: Consume unprocessed events when a CPU dies


On 06/19/2015 11:15 AM, Ross Lagerwall wrote:

When a CPU is offlined, there may be unprocessed events on a port for
that CPU.  If the port is subsequently reused on a different CPU, it
could be in an unexpected state with the link bit set, resulting in
interrupts being missed. Fix this by consuming any unprocessed events
for a particular CPU when that CPU dies.

Signed-off-by: Ross Lagerwall 
---
  drivers/xen/events/events_fifo.c | 23 ++-
  1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index 417415d..1dd0ba12 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -281,7 +281,8 @@ static void handle_irq_for_port(unsigned port)
  
  static void consume_one_event(unsigned cpu,

  struct evtchn_fifo_control_block *control_block,
- unsigned priority, unsigned long *ready)
+ unsigned priority, unsigned long *ready,
+ bool drop)
  {
struct evtchn_fifo_queue *q = &per_cpu(cpu_queue, cpu);
uint32_t head;
@@ -313,13 +314,17 @@ static void consume_one_event(unsigned cpu,
if (head == 0)
clear_bit(priority, ready);
  
-	if (evtchn_fifo_is_pending(port) && !evtchn_fifo_is_masked(port))

-   handle_irq_for_port(port);
+   if (evtchn_fifo_is_pending(port) && !evtchn_fifo_is_masked(port)) {
+   if (unlikely(drop))
+   pr_warn("Dropping pending event for port %u\n", port);


Maybe pr_info (or pr_notice)?

Also, why not do this (testing for unprocessed events) in 
xen_evtchn_close()?


-boris


+   else
+   handle_irq_for_port(port);
+   }
  
  	q->head[priority] = head;

  }
  
-static void evtchn_fifo_handle_events(unsigned cpu)

+static void __evtchn_fifo_handle_events(unsigned cpu, bool drop)
  {
struct evtchn_fifo_control_block *control_block;
unsigned long ready;
@@ -331,11 +336,16 @@ static void evtchn_fifo_handle_events(unsigned cpu)
  
  	while (ready) {

q = find_first_bit(&ready, EVTCHN_FIFO_MAX_QUEUES);
-   consume_one_event(cpu, control_block, q, &ready);
+   consume_one_event(cpu, control_block, q, &ready, drop);
ready |= xchg(&control_block->ready, 0);
}
  }
  
+static void evtchn_fifo_handle_events(unsigned cpu)

+{
+   __evtchn_fifo_handle_events(cpu, false);
+}
+
  static void evtchn_fifo_resume(void)
  {
unsigned cpu;
@@ -420,6 +430,9 @@ static int evtchn_fifo_cpu_notification(struct 
notifier_block *self,
if (!per_cpu(cpu_control_block, cpu))
ret = evtchn_fifo_alloc_control_block(cpu);
break;
+   case CPU_DEAD:
+   __evtchn_fifo_handle_events(cpu, true);
+   break;
default:
break;
}



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

Re: [Xen-devel] [PATCH] xen-netback: fix a BUG() during initialization

On Fri, Jun 19, 2015 at 02:21:51PM +0200, Imre Palik wrote:
> From: "Palik, Imre" 
> 
> Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime 
> settable")
> introduced the capability to change the bandwidth rate limit at runtime.
> But it also introduced a possible crashing bug.
> 
> If netback receives two XenbusStateConnected without getting the
> hotplug-status watch firing in between, then it will try to register the
> watches for the rate limiter again.  But this triggers a BUG() in the watch
> registration code.
> 
> The fix modifies connect() to remove the possibly existing packet-rate
> watches before trying to install those watches.  This behaviour is in line
> with how connect() deals with the hotplug-status watch.
> 
> Signed-off-by: Imre Palik 
> Cc: Matt Wilson 

Acked-by: Wei Liu 

> ---
>  drivers/net/xen-netback/xenbus.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/xen-netback/xenbus.c 
> b/drivers/net/xen-netback/xenbus.c
> index 968787a..ec383b0 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -681,6 +681,9 @@ static int xen_register_watchers(struct xenbus_device 
> *dev, struct xenvif *vif)
>   char *node;
>   unsigned maxlen = strlen(dev->nodename) + sizeof("/rate");
>  
> + if (vif->credit_watch.node)
> + return -EADDRINUSE;
> +
>   node = kmalloc(maxlen, GFP_KERNEL);
>   if (!node)
>   return -ENOMEM;
> @@ -770,6 +773,7 @@ static void connect(struct backend_info *be)
>   }
>  
>   xen_net_read_rate(dev, &credit_bytes, &credit_usec);
> + xen_unregister_watchers(be->vif);
>   xen_register_watchers(dev, be->vif);
>   read_xenbus_vif_flags(be);
>  
> -- 
> 1.7.9.5

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

[Xen-devel] [PATCH OSSTEST] ts-libvirt-build: Enable debug symbols in binaries

... by passing -g as appropriate.

Also ensure debug logging is enabled with --enable-debug (which
doesn't imply -g during build!).

Signed-off-by: Ian Campbell 
---
 ts-libvirt-build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ts-libvirt-build b/ts-libvirt-build
index 38f2cfd..f764b53 100755
--- a/ts-libvirt-build
+++ b/ts-libvirt-build
@@ -56,8 +56,8 @@ sub config() {
 my $gnulib = submodule_find($submodules, "gnulib");
 target_cmd_build($ho, 3600, $builddir, <{Path} \\
 ./autogen.sh --no-git \\
  --with-libxl --without-xen --without-xenapi 
--without-selinux \\
-- 
2.1.4


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

[Xen-devel] [PATCH] xen/events/fifo: Consume unprocessed events when a CPU dies

2015-06-19 Thread Ross Lagerwall

When a CPU is offlined, there may be unprocessed events on a port for
that CPU.  If the port is subsequently reused on a different CPU, it
could be in an unexpected state with the link bit set, resulting in
interrupts being missed. Fix this by consuming any unprocessed events
for a particular CPU when that CPU dies.

Signed-off-by: Ross Lagerwall 
---
 drivers/xen/events/events_fifo.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index 417415d..1dd0ba12 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -281,7 +281,8 @@ static void handle_irq_for_port(unsigned port)
 
 static void consume_one_event(unsigned cpu,
  struct evtchn_fifo_control_block *control_block,
- unsigned priority, unsigned long *ready)
+ unsigned priority, unsigned long *ready,
+ bool drop)
 {
struct evtchn_fifo_queue *q = &per_cpu(cpu_queue, cpu);
uint32_t head;
@@ -313,13 +314,17 @@ static void consume_one_event(unsigned cpu,
if (head == 0)
clear_bit(priority, ready);
 
-   if (evtchn_fifo_is_pending(port) && !evtchn_fifo_is_masked(port))
-   handle_irq_for_port(port);
+   if (evtchn_fifo_is_pending(port) && !evtchn_fifo_is_masked(port)) {
+   if (unlikely(drop))
+   pr_warn("Dropping pending event for port %u\n", port);
+   else
+   handle_irq_for_port(port);
+   }
 
q->head[priority] = head;
 }
 
-static void evtchn_fifo_handle_events(unsigned cpu)
+static void __evtchn_fifo_handle_events(unsigned cpu, bool drop)
 {
struct evtchn_fifo_control_block *control_block;
unsigned long ready;
@@ -331,11 +336,16 @@ static void evtchn_fifo_handle_events(unsigned cpu)
 
while (ready) {
q = find_first_bit(&ready, EVTCHN_FIFO_MAX_QUEUES);
-   consume_one_event(cpu, control_block, q, &ready);
+   consume_one_event(cpu, control_block, q, &ready, drop);
ready |= xchg(&control_block->ready, 0);
}
 }
 
+static void evtchn_fifo_handle_events(unsigned cpu)
+{
+   __evtchn_fifo_handle_events(cpu, false);
+}
+
 static void evtchn_fifo_resume(void)
 {
unsigned cpu;
@@ -420,6 +430,9 @@ static int evtchn_fifo_cpu_notification(struct 
notifier_block *self,
if (!per_cpu(cpu_control_block, cpu))
ret = evtchn_fifo_alloc_control_block(cpu);
break;
+   case CPU_DEAD:
+   __evtchn_fifo_handle_events(cpu, true);
+   break;
default:
break;
}
-- 
2.1.0


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

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

>>> On 19.06.15 at 16:07,  wrote:
> I don't mind adding a PHYSDEVOP_pci_mmcfg_reserved call to FreeBSD, but
> for it to have any effect we need to stop unconditionally mapping
> everything as MMIO regions on PVH Dom0.

Right, I didn't mean to imply PVH would have any chance of working
right now.

But what you didn't respond to is the (kind of implicit I admit) question
of whether FreeBSD is using MMCFG accesses for the low 256 bytes
of the config space. (I note that there's one special case in Linux -
NumaChip - whether this is the case.)

Jan

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

Re: [Xen-devel] [PATCH OSSTEST v3 02/11] mg-debian-installer-update: updates to better handle Jessie onwards.

On Fri, Jun 19, 2015 at 02:50:34PM +0100, Ian Campbell wrote:
> On Wed, 2015-06-17 at 14:06 +0100, Wei Liu wrote:
> > +case $suite_$arch in
> 
> Sorry, this is buggy, it looks for a variable named "suite_" which
> doesn't exist and so nothing matches. It needs this:
> 
> diff --git a/mg-debian-installer-update b/mg-debian-installer-update
> index b9b1146..6a26675 100755
> --- a/mg-debian-installer-update
> +++ b/mg-debian-installer-update
> @@ -102,7 +102,7 @@ done
>  # Some platforms require a newer kernel than is in Debian. Construct
>  # something suitable from the latest kernel ($bpok=flavour) in
>  # backports.
> -case $suite_$arch in
> +case ${suite}_${arch} in
>  wheezy_armhf) bpok=armmp; need_initramfs=y;;
>  esac
>  if [ x$bpok != x ]; then
> 

I folded this in.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

>>> On 19.06.15 at 15:05,  wrote:
>>And now that I started looking into what it takes to make this
>>work, I'm having a deja vu: In order for us to reliably intercept
>>all CFG accesses, we need to whitelist the MMCFG pages of
>>devices we know we don't care about being written. I.e. we
>>need to start out with all of them being read-only. And the
>>affected MFNs have to be known before Dom0 maps these
>>pages (or else we would have to hunt down all the mappings in
>>the page tables, which is nothing I consider even remotely
>>reasonable). Yet, and here comes the deja vu, upstream Linux
>>_still_ doesn't make use of PHYSDEVOP_pci_mmcfg_reserved.
> 
> Yes it does: 
> http://lists.xenproject.org/archives/html/xen-devel/2013-11/msg00807.html 

Oh, sorry - I expected it to live somewhere under arch/x86/.

Jan


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

Re: [Xen-devel] performace issue when turn on apicv

2015-06-19 Thread Konrad Rzeszutek Wilk

On Thu, Jun 18, 2015 at 10:35:37AM +0100, Jan Beulich wrote:
> >>> On 18.06.15 at 11:18,  wrote:
> > Jan Beulich wrote on 2015-06-18:
> > On 18.06.15 at 10:53,  wrote:
> >>> Jan Beulich wrote on 2015-06-18:
> >>> On 18.06.15 at 10:20,  wrote:
> > Apart from that I notice that the EXIT_REASON_EOI_INDUCED handling
> > also adds about the same number of ticks...
>  
>  Are there any other devices in the guest causing meaningful amounts
>  of interrupts (I suppose the SSD itself is using just one)? I ask
>  since I wonder whether e.g. there may be lock contention in
> >> vioapic_update_EOI().
> >>> 
> >>> The EXIT_REASON_EOI_INDUCED is for local apic time.
> >> 
> >> ??? (I.e. I don't see the connection between the context and your reply.
> >> Perhaps I'm missing something obvious...)
> > 
> > I mean the lots of EXIT_REASON_EOI_INDUCEDis for local apic time which is 
> > edge-trigger. So it will not call vioapic_update_EOI.
> 
> Okay, this then suggests the problem being hvm_dpci_msi_eoi(),
> albeit looking at it I can't immediately see why it would take long.

We do take two spin-locks (d->event_lock) and (desc->lock) and also
can IPI set_eoi_ready across different CPUs.

Perhaps it might be worth adding some TRACE with the time taken
to get the locks and also doing the IPIs?

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

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

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

2015-06-19 Thread Roger Pau Monné

El 19/06/15 a les 15.00, Jan Beulich ha escrit:
 On 11.06.15 at 11:51,  wrote:
>> On 11/06/15 09:35, Jan Beulich wrote:
>>> While I continue to be of the opinion that all direct writes to
>>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
>>> MSI per entry mask) outside of the hypervisor are wrong and
>>> should be eliminated, the scope of the problem now clearly
>>> going beyond qemu made me reconsider whether we shouldn't,
>>> as advocated by Stefano, follow the trap-and-emulate route
>>> instead. This would not only mean adding code to x86's existing
>>> port CF8/CFC intercepts, but also write-protecting the MMCFG
>>> pages for all PCI devices being MSI or MSI-X capable, emulating
>>> writes with inspection / modification of writes to any of the mask
>>> bits located in PCI config space. (A subsequent optimization to
>>> this may then be a hypercall to do config space writes,
>>> eliminating the emulation overhead, accompanied by a bitmap
>>> indicating which devices' CFG space can be written directly.)
>>>
>>> For a (from now on) timely resolution of the original problem I'd
>>> really appreciate opinions (or alternative suggestions).
>>
>> A very definite +1 from me.  I have previously suggested as much.
> 
> And now that I started looking into what it takes to make this
> work, I'm having a deja vu: In order for us to reliably intercept
> all CFG accesses, we need to whitelist the MMCFG pages of
> devices we know we don't care about being written. I.e. we
> need to start out with all of them being read-only. And the
> affected MFNs have to be known before Dom0 maps these
> pages (or else we would have to hunt down all the mappings in
> the page tables, which is nothing I consider even remotely
> reasonable). Yet, and here comes the deja vu, upstream Linux
> _still_ doesn't make use of PHYSDEVOP_pci_mmcfg_reserved.
> No idea whether FreeBSD or whatever else can be used as Dom0
> do. So no matter how we turn it, we have a dependency on the
> Dom0 kernel also being adjusted. In which case we might as well
> go the original route of requiring hypercalls to be used for certain
> operations to deal with the problem here.

FreeBSD doesn't implement PHYSDEVOP_pci_mmcfg_reserved ATM. I had a
patch to implement it, but it's completely useless with the way we map
MMIO regions on PVH right now.

Every hole in the e820 is basically mapped as a MMIO region _before_
starting Dom0, making the white/black listing done in
PHYSDEVOP_pci_mmcfg_reserved completely moot.

> Otoh the write interception has the potential of dealing with other
> problems (like that of XSAs 120 and 126), but making the security
> of Xen (in presence of the fix/workaround to the original problem
> here) dependent on a Dom0 side change not even on its way into
> the master Linux branch yet makes me really hesitant to try going
> that route. (And no, I'm not up to fighting for another pv-ops hook
> considering that I've never been really convinced of the pv-ops
> model in the first place.)
> 
> But then again the one thing we might consider saving us on the
> Linux side is that as of 2.6.25 base config space accesses don't
> get done via MMCFG anymore, and we don't have an immediate
> need to intercept extended ones (i.e. initially we might even get
> away without snooping MMCFG writes at all). Roger - how do
> things look like on the FreeBSD side?

I don't mind adding a PHYSDEVOP_pci_mmcfg_reserved call to FreeBSD, but
for it to have any effect we need to stop unconditionally mapping
everything as MMIO regions on PVH Dom0.

Then we need to expand XENMEM_add_to_physmap_batch so it can be used to
map MMIO regions on demand from Dom0 or modify
PHYSDEVOP_pci_mmcfg_reserved so it sets up the right mappings (1:1) for
auto-translated guests.

Roger.

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

[Xen-devel] Raisin moving to git://xenbits.xen.org/raisin.git

2015-06-19 Thread Stefano Stabellini

Hi all,

The Raisin git repository has just moved out of my personal git space on
xenbits to a more official location. The new git Raisin URL is:

git://xenbits.xen.org/raisin.git
http://xenbits.xen.org/gitweb/?p=raisin.git

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH OSSTEST v3 02/11] mg-debian-installer-update: updates to better handle Jessie onwards.

On Wed, 2015-06-17 at 14:06 +0100, Wei Liu wrote:
> +case $suite_$arch in

Sorry, this is buggy, it looks for a variable named "suite_" which
doesn't exist and so nothing matches. It needs this:

diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index b9b1146..6a26675 100755
--- a/mg-debian-installer-update
+++ b/mg-debian-installer-update
@@ -102,7 +102,7 @@ done
 # Some platforms require a newer kernel than is in Debian. Construct
 # something suitable from the latest kernel ($bpok=flavour) in
 # backports.
-case $suite_$arch in
+case ${suite}_${arch} in
 wheezy_armhf) bpok=armmp; need_initramfs=y;;
 esac
 if [ x$bpok != x ]; then

Ian.


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

Re: [Xen-devel] [OSSTEST PATCH 2/2] config: Computed defaults for Logs and Results

Ian Campbell writes ("Re: [OSSTEST PATCH 2/2] config: Computed defaults for 
Logs and Results"):
> On Fri, 2015-06-19 at 13:38 +0100, Ian Jackson wrote:
> > Signed-off-by: Ian Jackson 
> 
> No functional change AFAICT.

Indeed.

I have collected these and your --reuse patch into a branch of
miscellany.

Ian.

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

Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc

2015-06-19 Thread Peng Fan



Hi,

On 6/18/2015 10:54 PM, Ian Campbell wrote:

On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote:

Hi,

I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
no clear idea about why Dom0 kernel panic.

Have you confirmed that this same kernel runs reliably natively on this
platform?
Yeah. With XEN related configuration, the kernel can run natively on the 
platform.



[...]

/ # Unable to handle kernel NULL pointer dereference at virtual address

pgd = 84f1c000
[] *pgd=8cf15831, *pte=, *ppte=
Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 89 Comm: sh Not tainted 3.14.28-01780-g281e5c1-dirty #269
task: 84c07a80 ti: 84f02000 task.ti: 84f02000
PC is at 0x0
LR is at call_timer_fn.isra.33+0x24/0x88
pc : [<>]lr : [<80038b38>]psr: 2113

Your kernel has jumped to address 0x0 for some reason. You should use
gdb or something to examine you vmlinux file and try and figure out what
LR is doing, which may give you a hint as to why it is apparently
jumping to address zero.
I add such piece of code the linux kernel version 3.14.38. The panic 
disappears.


diff --git a/kernel/timer.c b/kernel/timer.c
index 38f0d40..4a025cc 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base 
*base)


base->running_timer = timer;
detach_expired_timer(timer, base);
+   if (!fn) {
+   printk("fn is null why\n"); > 
This log only shows once. Not sure why fn is null and only once.

+   continue;
+   }

if (irqsafe) {
spin_unlock(&base->lock);



(XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty

What changes have you made to your version of Xen? c01e139 is not an
upstream commit.
I only add an uart driver and a platform file. The platform part is very 
simple:

PLATFORM_START(imx7d, "i.MX 7Dual")
.compatible = imx7d_dt_compat,
.smp_init = imx7d_smp_init,  --> Actually I disabled this, since in 
dts, only one cpu node enabled.

.cpu_up = cpu_up_send_sgi,
/* Use IRAM base, not sure */
#if 0
.dom0_gnttab_start = 0x0090,
.dom0_gnttab_size = 0x2,
#endif
PLATFORM_END

I am not sure whether this realted to timer, the timer dts:

I think it looks like a software timer thing in the kernel rather than a
h/w timer thing.


The Dom0 kernel is also configured with " CONFIG_ARM_ARCH_TIMER=y", will
this incur errors? Or should Dom0 kernel not use arm arch timer?

Guests on Xen (including dom0) _should_ be using the arch timer.

Ian.

Not sure whether it relates to the uart driver that Julien suspected. 
But after apply the above kernel patch, Dom0 Linux can handle shell input.

Just have another question, How can Dom0 handle DMA for arm.

Thanks,
Peng.

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

Re: [Xen-devel] [PATCH 2/2] configure: check for argp

On Fri, Jun 19, 2015 at 10:58:25AM +0200, Roger Pau Monne wrote:
> argp is only present in the GNU C library, so add a specific check for it in
> configure. Also check if -largp is needed for linking against it.
> 
> Please run autoconf after applying.
> 
> Signed-off-by: Roger Pau Monné 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> Cc: Olaf Hering 

Acked-by: Wei Liu 

> ---
>  config/Tools.mk.in  | 1 +
>  tools/configure.ac  | 4 
>  tools/xentrace/Makefile | 2 +-
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/config/Tools.mk.in b/config/Tools.mk.in
> index aef9ed6..9bd5f6c 100644
> --- a/config/Tools.mk.in
> +++ b/config/Tools.mk.in
> @@ -78,5 +78,6 @@ CONFIG_GCRYPT   := @libgcrypt@
>  EXTFS_LIBS  := @EXTFS_LIBS@
>  CURSES_LIBS := @CURSES_LIBS@
>  TINFO_LIBS  := @TINFO_LIBS@
> +ARGP_LDFLAGS:= @argp_ldflags@
>  
>  FILE_OFFSET_BITS:= @FILE_OFFSET_BITS@
> diff --git a/tools/configure.ac b/tools/configure.ac
> index 1a06ddf..5eb4799 100644
> --- a/tools/configure.ac
> +++ b/tools/configure.ac
> @@ -356,6 +356,10 @@ AC_CHECK_LIB([yajl], [yajl_alloc], [],
>  AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])])
>  AC_CHECK_LIB([iconv], [libiconv_open], [libiconv="y"], [libiconv="n"])
>  AC_SUBST(libiconv)
> +AC_CHECK_HEADER([argp.h], [
> +AC_CHECK_LIB([argp], [argp_usage], [argp_ldflags="-largp"])
> +], [AC_MSG_ERROR([Could not find argp])])
> +AC_SUBST(argp_ldflags)
>  
>  # FDT is needed only on ARM
>  case "$host_cpu" in
> diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile
> index 7d874a3..2f57bda 100644
> --- a/tools/xentrace/Makefile
> +++ b/tools/xentrace/Makefile
> @@ -4,7 +4,7 @@ include $(XEN_ROOT)/tools/Rules.mk
>  CFLAGS += -Werror
>  
>  CFLAGS += $(CFLAGS_libxenctrl)
> -LDLIBS += $(LDLIBS_libxenctrl)
> +LDLIBS += $(LDLIBS_libxenctrl) $(ARGP_LDFLAGS)
>  
>  BIN-$(CONFIG_X86) = xenalyze
>  BIN  = $(BIN-y)
> -- 
> 1.9.5 (Apple Git-50.3)

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

Re: [Xen-devel] [PATCH 1/2] xen{trace/analyze}: don't use 64bit versions of libc functions

On Fri, Jun 19, 2015 at 10:58:24AM +0200, Roger Pau Monne wrote:
> This is not needed, neither encouraged. Configure already checks
> _FILE_OFFSET_BITS and appends it when needed, so that the right functions
> are used. Also remove the usage of loff_t and O_LARGEFILE for the same
> reason.
> 
> Signed-off-by: Roger Pau Monné 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> Cc: Olaf Hering 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

2015-06-19 Thread Konrad Rzeszutek Wilk

On June 19, 2015 9:00:39 AM EDT, Jan Beulich  wrote:
 On 11.06.15 at 11:51,  wrote:
>> On 11/06/15 09:35, Jan Beulich wrote:
>>> While I continue to be of the opinion that all direct writes to
>>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
>>> MSI per entry mask) outside of the hypervisor are wrong and
>>> should be eliminated, the scope of the problem now clearly
>>> going beyond qemu made me reconsider whether we shouldn't,
>>> as advocated by Stefano, follow the trap-and-emulate route
>>> instead. This would not only mean adding code to x86's existing
>>> port CF8/CFC intercepts, but also write-protecting the MMCFG
>>> pages for all PCI devices being MSI or MSI-X capable, emulating
>>> writes with inspection / modification of writes to any of the mask
>>> bits located in PCI config space. (A subsequent optimization to
>>> this may then be a hypercall to do config space writes,
>>> eliminating the emulation overhead, accompanied by a bitmap
>>> indicating which devices' CFG space can be written directly.)
>>>
>>> For a (from now on) timely resolution of the original problem I'd
>>> really appreciate opinions (or alternative suggestions).
>> 
>> A very definite +1 from me.  I have previously suggested as much.
>
>And now that I started looking into what it takes to make this
>work, I'm having a deja vu: In order for us to reliably intercept
>all CFG accesses, we need to whitelist the MMCFG pages of
>devices we know we don't care about being written. I.e. we
>need to start out with all of them being read-only. And the
>affected MFNs have to be known before Dom0 maps these
>pages (or else we would have to hunt down all the mappings in
>the page tables, which is nothing I consider even remotely
>reasonable). Yet, and here comes the deja vu, upstream Linux
>_still_ doesn't make use of PHYSDEVOP_pci_mmcfg_reserved.

Yes it does: 
http://lists.xenproject.org/archives/html/xen-devel/2013-11/msg00807.html

Is in the kernel.

>No idea whether FreeBSD or whatever else can be used as Dom0
>do. So no matter how we turn it, we have a dependency on the
>Dom0 kernel also being adjusted. In which case we might as well
>go the original route of requiring hypercalls to be used for certain
>operations to deal with the problem here.
>
>Otoh the write interception has the potential of dealing with other
>problems (like that of XSAs 120 and 126), but making the security
>of Xen (in presence of the fix/workaround to the original problem
>here) dependent on a Dom0 side change not even on its way into
>the master Linux branch yet makes me really hesitant to try going
>that route. (And no, I'm not up to fighting for another pv-ops hook
>considering that I've never been really convinced of the pv-ops
>model in the first place.)
>
>But then again the one thing we might consider saving us on the
>Linux side is that as of 2.6.25 base config space accesses don't
>get done via MMCFG anymore, and we don't have an immediate
>need to intercept extended ones (i.e. initially we might even get
>away without snooping MMCFG writes at all). Roger - how do
>things look like on the FreeBSD side?
>
>Jan



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

Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

>>> On 19.06.15 at 14:23,  wrote:
> On 19/06/15 11:55, Jan Beulich wrote:
> On 19.06.15 at 11:52,  wrote:
>>> On 19/06/15 10:29, Jan Beulich wrote:
>>> On 18.06.15 at 12:40,  wrote:
> On 18/06/15 11:36, Jan Beulich wrote:
> On 17.06.15 at 14:02,  wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -1175,22 +1175,6 @@ int alloc_unbound_xen_event_channel(
>>>  
>>>  void free_xen_event_channel(struct domain *d, int port)
>>>  {
>>> -struct evtchn *chn;
>>> -
>>> -spin_lock(&d->event_lock);
>>> -
>>> -if ( unlikely(d->is_dying) )
>>> -{
>>> -spin_unlock(&d->event_lock);
>>> -return;
>>> -}
>>> -
>>> -BUG_ON(!port_is_valid(d, port));
>
> I can keep this one.
>
>>> -chn = evtchn_from_port(d, port);
>>> -BUG_ON(!consumer_is_xen(chn));
>>
>> At least in debug builds I think these would better be retained.
>
> But this one has to go because it will always trip when
> free_xen_event_channel() is called after evtchn_destroy() (which will
> have cleared xen_consumer).

 Then why not

 BUG_ON(!consumer_is_xen(chn) && !d->is_dying);

 or keep the d->is_dying check in place? I can see why accelerating
 notify_via_xen_event_channel() is useful, but
 free_xen_event_channel()?
>>>
>>> This BUG_ON() is a pretty weak check and I don't really see the point of
>>> it.  I'm not respinning v4 just for this.
>> 
>> I'm not sure what makes this more weak than the other BUG_ON()
>> you agreed to retain - both try to validate that the callers don't do
>> bad things. Admitted, both would better be ASSERT()s...
>> 
>> As to spinning v4 - I see no need, as I can easily adjust this while
>> committing, as long as you don't disagree to have your name under
>> the result.
> 
> I disagree.
> 
> For this assert to be safe it needs to take suitable locks such as:
> 
> #ifdef DEBUG
> struct evtchn *chn;
> 
> chn = evtchn_from_port(d, port);
> spin_lock(&chn->lock);
> BUG_ON(chn->state != ECS_FREE && !consumer_is_xen(chn));
> spin_unlock(&chn->lock);
> #endif
> 
> or if you want the is_dying check, you need the event lock instead.
> 
> I wrote the first one, saw it was lots of noise for almost no gain and
> threw it away.

Which is why as an alternative I suggested not to touch
free_xen_event_channel() at all in this patch.

Jan


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

Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control

>>> On 11.06.15 at 11:51,  wrote:
> On 11/06/15 09:35, Jan Beulich wrote:
>> While I continue to be of the opinion that all direct writes to
>> interrupt masking bits (MSI-X mask-all, MSI-X per-entry mask,
>> MSI per entry mask) outside of the hypervisor are wrong and
>> should be eliminated, the scope of the problem now clearly
>> going beyond qemu made me reconsider whether we shouldn't,
>> as advocated by Stefano, follow the trap-and-emulate route
>> instead. This would not only mean adding code to x86's existing
>> port CF8/CFC intercepts, but also write-protecting the MMCFG
>> pages for all PCI devices being MSI or MSI-X capable, emulating
>> writes with inspection / modification of writes to any of the mask
>> bits located in PCI config space. (A subsequent optimization to
>> this may then be a hypercall to do config space writes,
>> eliminating the emulation overhead, accompanied by a bitmap
>> indicating which devices' CFG space can be written directly.)
>>
>> For a (from now on) timely resolution of the original problem I'd
>> really appreciate opinions (or alternative suggestions).
> 
> A very definite +1 from me.  I have previously suggested as much.

And now that I started looking into what it takes to make this
work, I'm having a deja vu: In order for us to reliably intercept
all CFG accesses, we need to whitelist the MMCFG pages of
devices we know we don't care about being written. I.e. we
need to start out with all of them being read-only. And the
affected MFNs have to be known before Dom0 maps these
pages (or else we would have to hunt down all the mappings in
the page tables, which is nothing I consider even remotely
reasonable). Yet, and here comes the deja vu, upstream Linux
_still_ doesn't make use of PHYSDEVOP_pci_mmcfg_reserved.
No idea whether FreeBSD or whatever else can be used as Dom0
do. So no matter how we turn it, we have a dependency on the
Dom0 kernel also being adjusted. In which case we might as well
go the original route of requiring hypercalls to be used for certain
operations to deal with the problem here.

Otoh the write interception has the potential of dealing with other
problems (like that of XSAs 120 and 126), but making the security
of Xen (in presence of the fix/workaround to the original problem
here) dependent on a Dom0 side change not even on its way into
the master Linux branch yet makes me really hesitant to try going
that route. (And no, I'm not up to fighting for another pv-ops hook
considering that I've never been really convinced of the pv-ops
model in the first place.)

But then again the one thing we might consider saving us on the
Linux side is that as of 2.6.25 base config space accesses don't
get done via MMCFG anymore, and we don't have an immediate
need to intercept extended ones (i.e. initially we might even get
away without snooping MMCFG writes at all). Roger - how do
things look like on the FreeBSD side?

Jan

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

Re: [Xen-devel] [OSSTEST PATCH 2/2] config: Computed defaults for Logs and Results

On Fri, 2015-06-19 at 13:38 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 

No functional change AFAICT.

Acked-by: Ian Campbell 



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

Re: [Xen-devel] [OSSTEST PATCH 1/2] config: Default Stash to $c{Logs}, not "logs"

On Fri, 2015-06-19 at 13:38 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 



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

[Xen-devel] [PATCH v2] xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node

2015-06-19 Thread Julien Grall

When the property "clock-frequency" is present in the DT timer node, it
means that the bootloader/firmware didn't correctly configure the
CNTFRQ/CNTFRQ_EL0 on each processor.

The best solution would be to fix the offending firmware/bootloader,
although it may not always be possible to modify and re-flash it.

As it's not possible to trap the register CNTFRQ/CNTFRQ_EL0, we have
to extend xen_arch_domainconfig to provide the timer frequency to the
toolstack when the property "clock-frequency" is present to the host DT
timer node. Then, a property "clock-frequency" will be created in the guest
DT timer node if the value is not 0.

We could have set the property in the guest DT no matter if the property
is present in the host DT. Although, we still want to let the guest
using CNTFRQ in normal case. After all, the property "clock-frequency"
is just a workaround for buggy firmware.

Also add a stub for fdt_property_u32 which is not present in libfdt <
1.4.0 used by distribution such as Debian Wheezy.

Signed-off-by: Julien Grall 
Tested-by: Chris Brand 

---
This patch requires to regenerate tools/configure.

Changes in v2:
- Typo in commit message
- Make the patch compiling on wheezy where fdt_property_u32 is
not present
---
 tools/configure.ac|  4 
 tools/libxl/libxl_arm.c   |  9 +++--
 tools/libxl/libxl_libfdt_compat.h |  9 +
 xen/arch/arm/domain.c |  2 +-
 xen/arch/arm/time.c   |  5 +
 xen/arch/arm/vtimer.c |  4 +++-
 xen/arch/arm/vtimer.h |  3 ++-
 xen/include/asm-arm/time.h|  6 ++
 xen/include/public/arch-arm.h | 14 ++
 9 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index 1a06ddf..2886cb5 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -379,6 +379,10 @@ AS_IF([test "x$partial_dt" = "xy" ],
 #   * The prototype exists but the functions are not exposed. Don't ask why...
 AC_CHECK_FUNCS([fdt_first_subnode fdt_next_subnode])
 AC_CHECK_DECLS([fdt_first_subnode, fdt_next_subnode],,,[#include ])
+
+# The helper fdt_property_u32 is only present in libfdt >= 1.4.0
+# It's an inline function, so only check if the declaration is present
+AC_CHECK_DECLS([fdt_property_u32],,,[#include ])
 esac
 
 # Checks for header files.
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 4fb5e26..f09c860 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -444,7 +444,9 @@ static int make_gicv3_node(libxl__gc *gc, void *fdt)
 return 0;
 }
 
-static int make_timer_node(libxl__gc *gc, void *fdt, const struct arch_info 
*ainfo)
+static int make_timer_node(libxl__gc *gc, void *fdt,
+   const struct arch_info *ainfo,
+   uint32_t frequency)
 {
 int res;
 gic_interrupt ints[3];
@@ -462,6 +464,9 @@ static int make_timer_node(libxl__gc *gc, void *fdt, const 
struct arch_info *ain
 res = fdt_property_interrupts(gc, fdt, ints, 3);
 if (res) return res;
 
+if ( frequency )
+fdt_property_u32(fdt, "clock-frequency", frequency);
+
 res = fdt_end_node(fdt);
 if (res) return res;
 
@@ -805,7 +810,7 @@ next_resize:
 goto out;
 }
 
-FDT( make_timer_node(gc, fdt, ainfo) );
+FDT( make_timer_node(gc, fdt, ainfo, xc_config->clock_frequency) );
 FDT( make_hypervisor_node(gc, fdt, vers) );
 
 if (pfdt)
diff --git a/tools/libxl/libxl_libfdt_compat.h 
b/tools/libxl/libxl_libfdt_compat.h
index 53a5076..23230b5 100644
--- a/tools/libxl/libxl_libfdt_compat.h
+++ b/tools/libxl/libxl_libfdt_compat.h
@@ -61,6 +61,7 @@
 #define LIBXL_LIBFDT_COMPAT_H
 
 #include "libxl_internal.h"
+#include 
 
 #if !HAVE_DECL_FDT_FIRST_SUBNODE
 _hidden int fdt_first_subnode(const void *fdt, int offset);
@@ -70,6 +71,14 @@ _hidden int fdt_first_subnode(const void *fdt, int offset);
 _hidden int fdt_next_subnode(const void *fdt, int offset);
 #endif
 
+#if !HAVE_DECL_FDT_PROPERTY_U32
+static inline int fdt_property_u32(void *fdt, const char *name, uint32_t val)
+{
+   uint32_t tmp = cpu_to_fdt32(val);
+   return fdt_property(fdt, name, &tmp, sizeof(tmp));
+}
+#endif
+
 #endif
 
 /*
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 24b8938..8b1bf5a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -593,7 +593,7 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( (rc = domain_vgic_init(d, config->nr_spis)) != 0 )
 goto fail;
 
-if ( (rc = domain_vtimer_init(d)) != 0 )
+if ( (rc = domain_vtimer_init(d, config)) != 0 )
 goto fail;
 
 /*
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index ce6d3fd..5ded30c 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -42,6 +42,8 @@ uint64_t __read_mostly boot_count;
  * register-mapped time source in the SoC. */
 unsigned long __read_mostly cpu_khz;

[Xen-devel] [OSSTEST PATCH 1/2] config: Default Stash to $c{Logs}, not "logs"

Signed-off-by: Ian Jackson 
---
 Osstest.pm  |3 ++-
 production-config   |1 -
 production-config-cambridge |1 -
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/Osstest.pm b/Osstest.pm
index 8948666..fc46487 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -60,7 +60,6 @@ our %c = qw(
 JobDB Standalone
 HostDB Static
 
-Stash logs
 Images images
 Logs logs
 Results results
@@ -214,6 +213,8 @@ sub readglobalconfig () {
 $c{DefaultBranch} ||= 'xen-unstable';
 
 $c{DebianMirrorHost} ||= 'ftp.debian.org' if $c{DebianMirrorProxy};
+
+$c{Stash} //= $c{Logs};
 }
 
 sub augmentconfigdefaults {
diff --git a/production-config b/production-config
index 47c0c4c..b17bd66 100644
--- a/production-config
+++ b/production-config
@@ -34,7 +34,6 @@ QueueDaemonHost osstest
 
 ExecutiveDbnamePat dbname=osstestdb;host=db
 
-Stash /home/logs/logs
 Images /home/logs/images
 Logs /home/logs/logs
 
diff --git a/production-config-cambridge b/production-config-cambridge
index 8f6fbe4..693690b 100644
--- a/production-config-cambridge
+++ b/production-config-cambridge
@@ -32,7 +32,6 @@ NetNameservers 10.80.248.2 10.80.16.28 10.80.16.67
 
 Timezone Europe/London
 
-Stash /home/xc_osstest/logs
 Images /home/xc_osstest/images
 Logs /home/xc_osstest/logs
 
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 2/2] config: Computed defaults for Logs and Results

Signed-off-by: Ian Jackson 
---
 Osstest.pm  |9 +++--
 production-config   |2 --
 production-config-cambridge |2 --
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Osstest.pm b/Osstest.pm
index fc46487..c89c941 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -61,8 +61,6 @@ our %c = qw(
 HostDB Static
 
 Images images
-Logs logs
-Results results
 
 DebianSuite wheezy
 DebianMirrorSubpath debian
@@ -214,6 +212,13 @@ sub readglobalconfig () {
 
 $c{DebianMirrorHost} ||= 'ftp.debian.org' if $c{DebianMirrorProxy};
 
+my $pubbaseprefix = $c{PubBaseDir} ? "$c{PubBaseDir}/" : "";
+foreach my $l (qw(logs results)) {
+   my $u = ucfirst $l;
+   next if defined $c{$u};
+   $c{"${u}"} = "$pubbaseprefix$l";
+}
+
 $c{Stash} //= $c{Logs};
 }
 
diff --git a/production-config b/production-config
index b17bd66..bcb351e 100644
--- a/production-config
+++ b/production-config
@@ -35,9 +35,7 @@ QueueDaemonHost osstest
 ExecutiveDbnamePat dbname=osstestdb;host=db
 
 Images /home/logs/images
-Logs /home/logs/logs
 
-Results /home/logs/results
 PubBaseDir /home/logs
 
 OverlayLocal /home/osstest/overlay-local
diff --git a/production-config-cambridge b/production-config-cambridge
index 693690b..7b54a98 100644
--- a/production-config-cambridge
+++ b/production-config-cambridge
@@ -33,9 +33,7 @@ NetNameservers 10.80.248.2 10.80.16.28 10.80.16.67
 Timezone Europe/London
 
 Images /home/xc_osstest/images
-Logs /home/xc_osstest/logs
 
-Results /home/xc_osstest/results
 PubBaseDir /home/xc_osstest
 
 OverlayLocal /export/home/osstest/overlay-local
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH OSSTEST v3 02/11] mg-debian-installer-update: updates to better handle Jessie onwards.

Wei Liu writes ("[PATCH OSSTEST v3 02/11] mg-debian-installer-update: updates 
to better handle Jessie onwards."):
> From: Ian Campbell 
> 
> In mg-debian-installer-update:
> 
>   - Expand the list of (suite,arch) combinations which don't exist and
> move it to the top.
...
> -# Newer kernel often needs a newer initramfs-tools. Make that available
> -echo >&2 "collecting backports initramfs-tools"
> -pkgfile=`zcat Packages.gz | grep-dctrl -PX initramfs-tools -nsFilename | 
> sort -n -r | head -n1`
> -rc=$?
> -set -e
> -if [ $rc != 0 ]; then fail "initramfs-tools package not found"; fi
> -fetch "$site/$pkgfile" >initramfs-tools.deb
> +if [ x$need_initramfs = xy ]; then
> +# Newer kernel often needs a newer initramfs-tools. Make that
> +# available
> +echo >&2 "collecting backports initramfs-tools"
> +pkgfile=`zcat Packages.gz \
> + | grep-dctrl -PX initramfs-tools -nsFilename \
> + | sort -n -r | head -n1`

That looks much like this:

> -pkgfile=`zcat Packages.gz | grep-dctrl -S linux | grep-dctrl -Pe 
> ^linux-image-.*-armmp$ -nsFilename | sort -n -r | head -n1`
> +pkgfile=`zcat Packages.gz | grep-dctrl -S linux \
> + | grep-dctrl -Pe ^linux-image-.*-${bpok}$ -nsFilename \
> + | sort -n -r | head -n1`

But since it was duplicated before I won't ask you to break it out.

Acked-by: Ian Jackson 

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 58451
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 58718 
REGR. vs. 58530

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail pass 
in 58718
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail pass in 58718
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail pass in 58718
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-localmigrate.2  fail pass in 58718

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 58718 REGR. vs. 
58530
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 58718 
like 58530
 test-amd64-amd64-libvirt 11 guest-start  fail   like 58530

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass

version targeted for testing:
 xen  de53397e342682dfe37d569a137007067a86b768
baseline version:
 xen  05ab7714ff84003b9b4542d7816b4651efb67679


People who touched revisions under test:
  Alan Robinson 
  Andrew Cooper 
  Dario Faggioli 
  Dietmar Hahn 
  Don Dugger 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Roger Pau MonnÃ© 
  Ross Lagerwall 


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

Re: [Xen-devel] [PATCHv3 2/6] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()

2015-06-19 Thread David Vrabel

On 19/06/15 11:55, Jan Beulich wrote:
 On 19.06.15 at 11:52,  wrote:
>> On 19/06/15 10:29, Jan Beulich wrote:
>> On 18.06.15 at 12:40,  wrote:
 On 18/06/15 11:36, Jan Beulich wrote:
 On 17.06.15 at 14:02,  wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -1175,22 +1175,6 @@ int alloc_unbound_xen_event_channel(
>>  
>>  void free_xen_event_channel(struct domain *d, int port)
>>  {
>> -struct evtchn *chn;
>> -
>> -spin_lock(&d->event_lock);
>> -
>> -if ( unlikely(d->is_dying) )
>> -{
>> -spin_unlock(&d->event_lock);
>> -return;
>> -}
>> -
>> -BUG_ON(!port_is_valid(d, port));

 I can keep this one.

>> -chn = evtchn_from_port(d, port);
>> -BUG_ON(!consumer_is_xen(chn));
>
> At least in debug builds I think these would better be retained.

 But this one has to go because it will always trip when
 free_xen_event_channel() is called after evtchn_destroy() (which will
 have cleared xen_consumer).
>>>
>>> Then why not
>>>
>>> BUG_ON(!consumer_is_xen(chn) && !d->is_dying);
>>>
>>> or keep the d->is_dying check in place? I can see why accelerating
>>> notify_via_xen_event_channel() is useful, but
>>> free_xen_event_channel()?
>>
>> This BUG_ON() is a pretty weak check and I don't really see the point of
>> it.  I'm not respinning v4 just for this.
> 
> I'm not sure what makes this more weak than the other BUG_ON()
> you agreed to retain - both try to validate that the callers don't do
> bad things. Admitted, both would better be ASSERT()s...
> 
> As to spinning v4 - I see no need, as I can easily adjust this while
> committing, as long as you don't disagree to have your name under
> the result.

I disagree.

For this assert to be safe it needs to take suitable locks such as:

#ifdef DEBUG
struct evtchn *chn;

chn = evtchn_from_port(d, port);
spin_lock(&chn->lock);
BUG_ON(chn->state != ECS_FREE && !consumer_is_xen(chn));
spin_unlock(&chn->lock);
#endif

or if you want the is_dying check, you need the event lock instead.

I wrote the first one, saw it was lots of noise for almost no gain and
threw it away.

David

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

Re: [Xen-devel] [PATCH OSSTEST v3 09/11] ts-xen-build-prep: reverse the test for installing libc6-dev-i386

Wei Liu writes ("[PATCH OSSTEST v3 09/11] ts-xen-build-prep: reverse the test 
for installing libc6-dev-i386"):
> Starting from wheezy, Debian introduced multiarch support, so we need to
> install libc6-dev-i386 to build tools.
> 
> Since multiarch will be permanent, we reverse the test to not install
> libc6-dev-i386 on releases older than wheezy  i.e. wheezy and jessie will have
> that package).

Acked-by: Ian Jackson 

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

[Xen-devel] [PATCH] xen-netback: fix a BUG() during initialization

2015-06-19 Thread Imre Palik

From: "Palik, Imre" 

Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime 
settable")
introduced the capability to change the bandwidth rate limit at runtime.
But it also introduced a possible crashing bug.

If netback receives two XenbusStateConnected without getting the
hotplug-status watch firing in between, then it will try to register the
watches for the rate limiter again.  But this triggers a BUG() in the watch
registration code.

The fix modifies connect() to remove the possibly existing packet-rate
watches before trying to install those watches.  This behaviour is in line
with how connect() deals with the hotplug-status watch.

Signed-off-by: Imre Palik 
Cc: Matt Wilson 
---
 drivers/net/xen-netback/xenbus.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 968787a..ec383b0 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -681,6 +681,9 @@ static int xen_register_watchers(struct xenbus_device *dev, 
struct xenvif *vif)
char *node;
unsigned maxlen = strlen(dev->nodename) + sizeof("/rate");
 
+   if (vif->credit_watch.node)
+   return -EADDRINUSE;
+
node = kmalloc(maxlen, GFP_KERNEL);
if (!node)
return -ENOMEM;
@@ -770,6 +773,7 @@ static void connect(struct backend_info *be)
}
 
xen_net_read_rate(dev, &credit_bytes, &credit_usec);
+   xen_unregister_watchers(be->vif);
xen_register_watchers(dev, be->vif);
read_xenbus_vif_flags(be);
 
-- 
1.7.9.5


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

Re: [Xen-devel] [PATCH OSSTEST v3 06/11] Cope with Jessie's d-i vg name

Wei Liu writes ("[PATCH OSSTEST v3 06/11] Cope with Jessie's d-i vg name"):
> In Jessie the default vg name is changed to "$hostname-vg". Make that
> default case and check for wheezy, squeeze and lenny for backward
> compatibility.
> 
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] libxc: delete sent_last_iter

Wei Liu writes ("[PATCH] libxc: delete sent_last_iter"):
> It's set in code but never used.  Detected by -Wunused-but-set-variable.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job

Ian Jackson writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe 
of nested test job"):
...
> But it isn't as simple as you suggest, unfortunately.  Because:
> 
> > proc need-hosts/test-nested {} {return host}
> > proc run-job/test-nested {} {
> > run-ts . = ts-debian-hvm-install + host l1
> > run-ts . = ts-nested-setup + host l1
> > run-ts . = ts-xen-install l1
> > run-ts . = ts-host-reboot l1
> > run-ts . = ts-leak-check basis l1
> > run-ts . = ts-debian-hvm-install l1 l2
> > run-ts . = ts-guest-stop l1 l2
> > run-ts . = ts-leak-check check l1
> > run-ts . = ts-logs-capture l1
> > run-ts . = ts-guest-destroy + host l1
> 
> This will not run ts-logs-capture on l1, unless all the previous tests
> passed.  That's obviously not what we want.

I think it would be best if I proposed some code to you.  I will get
back to you with a suggestion.

Ian.

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

Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job

Pang, LongtaoX writes ("RE: [OSSTEST Nested PATCH v11 6/7] Compose the main 
recipe of nested test job"):
> So, may I implement these action via below recipe in sg-run-job? Since, this 
> would be less code to 
> be changed and we want to avoid to involve tcl plumbing in sg-run-job. Also, 
> I think there is no harmful.

I don't object to that approach.

But it isn't as simple as you suggest, unfortunately.  Because:

> proc need-hosts/test-nested {} {return host}
> proc run-job/test-nested {} {
> run-ts . = ts-debian-hvm-install + host l1
> run-ts . = ts-nested-setup + host l1
> run-ts . = ts-xen-install l1
> run-ts . = ts-host-reboot l1
> run-ts . = ts-leak-check basis l1
> run-ts . = ts-debian-hvm-install l1 l2
> run-ts . = ts-guest-stop l1 l2
> run-ts . = ts-leak-check check l1
> run-ts . = ts-logs-capture l1
> run-ts . = ts-guest-destroy + host l1

This will not run ts-logs-capture on l1, unless all the previous tests
passed.  That's obviously not what we want.

Ian.

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

[Xen-devel] Developer Summit BoF's (Aug 17 & 18) and Developer Meeting Aug 19 in Seattle

2015-06-19 Thread Lars Kurth

Hi all,

I created two pages to help assignment of BoF's and topics that we should cover 
in the Developer Meeting the day after Developer Summit. You can sign up for 
BoF's and the Developer Meeting by replying to this mail or by editing the 
following two wiki pages
* http://wiki.xenproject.org/wiki/Developer_Meeting/Aug2015 

* http://wiki.xenproject.org/wiki/Developer_Meeting/Aug2015-BoFs#Topics 


For BoF's I need a time-slot (see above), a title and a short description. I 
will periodically check this page and update the main summit agenda which you 
can find at 
http://events.linuxfoundation.org/events/xen-project-developer-summit/program/schedule
 


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

Re: [Xen-devel] [PATCH] don't put dom0 console info directly after start_info data

2015-06-19 Thread Juergen Gross


On 06/19/2015 02:04 PM, Jan Beulich wrote:

On 19.06.15 at 13:06, <"jgr...@suse.com".non-mime.internet> wrote:

The console information of dom0 is living in the same memory page as the
start_info data. Don't put the console data directly after the start_info
to leave some room for future structure enlargements. Otherwise a dom0
with a newer start_info layout than the hypervisor could interprete
console data as part of the start_info data.

Before commit 50bd1f0825339dfacde471df7664729216fc46e3 there used to be a
padding at the end of start_info, but this was removed as it was regarded
to be not necessary.


Said commit removed padding from shared_info, not start_info.


Aargh, not enough coffee, I guess.

Sorry for the noise.


Juergen


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

Re: [Xen-devel] [PATCH OSSTEST v3 12/11] toolstack/libvirt: install libnl-3-200 on Jessie

Wei Liu writes ("[PATCH OSSTEST v3 12/11] toolstack/libvirt: install 
libnl-3-200 on Jessie"):
> Signed-off-by: Wei Liu 
...
> diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
> index e7f4860..c71f88a 100644
> --- a/Osstest/Toolstack/libvirt.pm
> +++ b/Osstest/Toolstack/libvirt.pm
> @@ -24,11 +24,15 @@ use Osstest::TestSupport;
>  
>  sub new {
>  my ($class, $ho, $methname,$asset) = @_;
> +my @extra_packages = qw(libavahi-client3);
> +my $nl_lib = "libnl-3-200";
> +$nl_lib = "libnl1" if ($ho->{Suite} =~ m/wheezy/);
> +push(@extra_packages, $nl_lib);
>  return bless { Name => "libvirt",
>  Host => $ho,
>  NewDaemons => [qw(libvirtd)],
>  Dom0MemFixed => 1,
> -ExtraPackages => [qw(libnl1 libavahi-client3)],
> +ExtraPackages => [@extra_packages],

It would be more normal to write
\@extra_packages
rather than
[@extra_packages]
unless you actually need to make a copy of the array.

(I don't care about this for efficiency, but rather for readability:
writing [@extra_packages] carries an implication that something might
edit either @extra_packages or ExtraPackages afterwards.

Ian.

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

Re: [Xen-devel] [PATCH] don't put dom0 console info directly after start_info data

>>> On 19.06.15 at 13:06, <"jgr...@suse.com".non-mime.internet> wrote:
> The console information of dom0 is living in the same memory page as the
> start_info data. Don't put the console data directly after the start_info
> to leave some room for future structure enlargements. Otherwise a dom0
> with a newer start_info layout than the hypervisor could interprete
> console data as part of the start_info data.
> 
> Before commit 50bd1f0825339dfacde471df7664729216fc46e3 there used to be a
> padding at the end of start_info, but this was removed as it was regarded
> to be not necessary.

Said commit removed padding from shared_info, not start_info. Nor
would the suggested change be the correct one for a problem like
this. Instead the kernel should check how much of the shared info
structure it knows about is valid (which Dom0 can easily do using
console.dom0.info_off - that is, after all, why this is being placed at
a variable offset; DomU currently has no problem, as the rest of the
page is zero for it). If a future extension makes it so that this can't
be determined implicitly, a suitable SIF_* flag would need to be added.

Jan

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

[Xen-devel] [xen-4.5-testing test] 58728: regressions - FAIL

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 58717 
REGR. vs. 58528

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  3 host-install(3)  broken in 58717 pass in 58728
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 58717 
pass in 58728
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 58717 
pass in 58728
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat   fail pass in 58717
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate   fail pass in 58717

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-sedf 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  a24672752214b07661db594921ba70c0ee3066c5
baseline version:
 xen  d963f64ba322731bc73d71adb589f361c1f8123c


People who touched revisions under test:
  Alan Robinson 
  Andrew Cooper 
  Dario Faggioli 
  Dietmar Hahn 
  Don Dugger 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Roger Pau MonnÃ© 
  Ross Lagerwall 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale  fail
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-rumpuserxen-i386 pass
 test-amd64-amd64

Re: [Xen-devel] [PATCH v2][RFC] libxl: Add AHCI support for upstream qemu

2015-06-19 Thread Fabio Fantoni

Il 11/06/2015 12:28, Fabio Fantoni ha scritto:

Il 11/06/2015 12:06, Zir Blazer ha scritto:
Since I'm not a developer I may be peeking my nose a bit too far, but
based on what I know, I think that enabling AHCI by default would be
a compatibility suicide. I'm not sure about Linux and Windows
Vista/7/8+, but at least for Windows XP based VMs, it would be a
terrible idea.

Also use windows xp without security updates (support ended one year
ago) is a "suicide".

I already did this patch considering windows domU problems (I'm using
mainly them for now), ahci used with option (ahci=0|1) instead replace
and default is disabled.

I tried it with different windows (excluding xp...abandoned)
I also tried with new winpv drivers
(http://www.xenproject.org/developers/teams/windows-pv-drivers.html)

With this patch applied ahci will be not used and will be used only
setting ahci=1, is it a good idea or is there problem also in this case?

I did many other tests in different linux hvm domUs (fedora and ubuntu)
and windows (7, 8.1, 10) without found problems.

Is this patch acceptable for xen 4.6?

Thanks for any reply and sorry for my bad english.

Back during WXP years, the vanilla install ISO didn't had any AHCI
Drivers integrated at all. If you set the SATA Controller to AHCI,
the WXP installation wouldn't detect any Hard Disk at all. If you
really wanted to use AHCI during its early days, you would need a
Floppy Disk with the AHCI Drivers of your SATA Controller
(Chipset/South Bridge or third party controller), that you could use
by pressing the F6 key right after booting the install CD:

http://www.pc-tips-and-tricks.com/images/Install-windows-xp-02.jpg

If you didn't had a Floppy Disk Driver or were lazy, the typical
choice was to set the SATA Controller to IDE and install WXP,
skipping anything AHCI related.

At some point an application called nLite appeared, which allowed you
to make your custom Windows XP ISO. You could easily modify a lot of
default options, integrate hotfixes, and even Drivers, and after you
were happy with your changes, you could then make your custom ISO and
burn it to a CD (Or from a USB Flash Drive with other tools to make
it booteable). So, with nLite, it was rather easy to integrated the
AHCI Drivers of your SATA Controller to the install ISO. This way, if
you were doing a fresh install, reinstall or repair, there was no
excuse to not use AHCI.
However, since for VM usage AHCI was not available at all until QEMU
implemented it recently, by default you will be always using IDE, so
there was no actual need to make a customized WXP install ISO with
AHCI Drivers that you were never going to use. Besides, Windows XP
doesn't even install nor have ready any AHCI Drivers if you're in IDE
mode, so if you're going to switch to use AHCI by default, every
existing WXP VM would greet you with a BSOD after upgrading Xen.

So, with this proposal you would have two issues: First, doing a new
install of Windows XP on a VM , since by default it shouldn't detect
any HD at all in AHCI. Second, that existing WXP VMs will BSOD on
boot. For as long as you can switch to IDE mode everything should
still be working as always, but it would mean that at the very least
you would have to modify the DomU config file to replace default AHCI
with old IDE.

Regarding using Windows XP with AHCI:
First, as stated before, if you want to install it on a new VM, you
need the AHCI Drivers. Since it seems that at some point support for
Floppy Disk got removed from Xen (I tried recently to use a Floppy
Disk image with fda= as stated somewhere on the wiki, but it did
nothing. Nor I found any recent documentation claiming that you can
mount a Floppy Disk image at all), the only choice is to make a
custom ISO with nLite with the AHCI Drivers integrated in it. Since
the emulated Southbridge is an Intel ICH9, I believe that the Drivers
that should be needed are these:
http://www.win-raid.com/t22f23-Guide-Integration-of-Intels-AHCI-RAID-drivers-into-a-Windows-XP-W-k-W-k-CD.html

Check for the a) and c) options for WXP/2003 in 32 and 64 Bits variants.

Also, it is important to note that the plain ICH9 Southbridge
according to Intel DOES NOT OFFICIALLY HAVE AHCI SUPPORT, ICH9R does.

http://en.wikipedia.org/wiki/I/O_Controller_Hub#ICH9

The previous Drivers are claimed to have been modified to force
support for ICH9 since AHCI is there, just that the original Drivers
doesn't want to use it. Typical artificial market segmentation
strategies. Still, if QEMU is emulating the plain ICH9 and you can't
get Windows to see drives in AHCI mode after integrating the AHCI
Drivers, that may be why.

Second, it is possible to switch from IDE to AHCI on WXP without
reinstalling, but doing it is rather hacky and instructions are very
Chipset and vendor dependant, which may (Or not) include editing
Windows registry. Here are instructions that claim to work for Intel
Southbri

Re: [Xen-devel] [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install

On Fri, 2015-06-19 at 12:02 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot 
> order during install"):
> > On Thu, 2015-06-18 at 18:57 +0100, Ian Jackson wrote:
> > > This seems a pretty serious bug.  Is there a way to avoid it ?
> > 
> > Unfortunately not as far as I can tell, it seems to be a major
> > shortcoming of the way UEFI boot order is managed both from the UEFI UI
> > and via the Linux command line tools. FWIW I was inspired by the way
> > XenRT has to do this too (so it is a problem for x86 too).
> > 
> > grub-installer happens pretty late in the install, so the gap until the
> > late command which repairs things is short, but not ideal I agree.
> 
> The real risk is, I think, that a marginal timeout results in the
> machine being powered off at the wrong moment.

Hrm, yes.

> We could reduce the risk of this by having the installer report back
> to the controller saying "I'm about to enter the critical region" and
> "I have now exited the critical region and am about to reboot", thus
> applying a separate timeout to the critical region.

Exiting the critical region is easy, it's the same script as I added
here.

Entering the critical region I'm not sure how to hook into,
grub-installer doesn't seem to provide any hooks of that sort.
early_hook seems like a rather too early lower bound.

Ian.


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

Re: [Xen-devel] [PATCH OSSTEST v2 13/19] standalone: Prefer ./standalone.config to $HOME/.xen-osstest/config

On Fri, 2015-06-19 at 12:04 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v2 13/19] standalone: Prefer 
> ./standalone.config to $HOME/.xen-osstest/config"):
> > On Fri, 2015-06-19 at 11:22 +0100, Ian Campbell wrote:
> > > On Thu, 2015-06-18 at 18:59 +0100, Ian Jackson wrote:
> > > > This results in us having
> > > >standalone-config-example
> > > >production-config
> > > >production-config-cambridge
> > > > but
> > > >standalone.config
> > > > is actually read by default.
> > > > 
> > > > Perhaps the latter should be
> > > >local-config
> > > > ?
> > > 
> > > That's ok by me.
> > 
> > But standalone.config can from standalone-reset in the first
> > place.standalone, I'm happy to change both but just wanted to mention
> > since that's been around for a while (so I'm not just changing something
> > new).
> 
> Your sentence seems mangled,

It is rather.

>  but AFAICT you are saying `we already
> have standalone.config'.  But AFAICT standalone.config is something
> entirely different.  standalone.config is a shell script sourced by
> standalone-reset.

Yes, you are right, they are entirely separate, so using
standalone.config is extra wrong here then!

Ian.


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

Re: [Xen-devel] stable trees (was: [xen-4.2-testing test] 58584: regressions)