[Xen-devel] [PATCH v4 2/3] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.

[Quan Xu]

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/qinval.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index 946e812..b227e4e 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -28,6 +28,11 @@
 #include "vtd.h"
 #include "extern.h"
 
+static int __read_mostly iommu_qi_timeout_ms = 1;
+integer_param("iommu_qi_timeout_ms", iommu_qi_timeout_ms);
+
+#define IOMMU_QI_TIMEOUT (iommu_qi_timeout_ms * MILLISECS(1))
+
 static void print_qi_regs(struct iommu *iommu)
 {
 u64 val;
@@ -167,10 +172,12 @@ static int queue_invalidate_wait(struct iommu *iommu,
 start_time = NOW();
 while ( poll_slot != QINVAL_STAT_DONE )
 {
-if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
+if ( NOW() > (start_time + IOMMU_QI_TIMEOUT) )
 {
 print_qi_regs(iommu);
-panic("queue invalidate wait descriptor was not executed");
+dprintk(XENLOG_WARNING VTDPREFIX,
+"Queue invalidate wait descriptor was timeout.\n");
+return -ETIMEDOUT;
 }
 cpu_relax();
 }
-- 
1.9.1


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

[Xen-devel] [PATCH v4 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue.

[Quan Xu]

Now if IOTLB/Context/IETC flush is timeout, panic hypervisor.
The coming patch set will fix it.

If Device-TLB flush is timeout, we'll hide the target ATS
device and crash the domain owning this ATS device.

If impacted domain is hardware domain, just throw out a warning.

The hided Device will be disallowed to be further assigned to
any domain.

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/pci.c |  2 +-
 xen/drivers/passthrough/vtd/extern.h  |  2 +
 xen/drivers/passthrough/vtd/qinval.c  | 80 ++-
 xen/drivers/passthrough/vtd/x86/ats.c | 13 ++
 4 files changed, 94 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 27b3ca7..2d7dc59 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -407,7 +407,7 @@ static void _pci_hide_device(struct pci_dev *pdev)
 list_add(&pdev->domain_list, &dom_xen->arch.pdev_list);
 }
 
-int __init pci_hide_device(int bus, int devfn)
+int pci_hide_device(int bus, int devfn)
 {
 struct pci_dev *pdev;
 int rc = -ENOMEM;
diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index ec9c513..a2123ce 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -58,6 +58,8 @@ int ats_device(const struct pci_dev *, const struct 
acpi_drhd_unit *);
 
 int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
  u64 addr, unsigned int size_order, u64 type);
+int dev_invalidate_iotlb_sync(struct iommu *iommu, u16 did,
+  u16 seg, u8 bus, u8 devfn);
 
 int qinval_device_iotlb(struct iommu *iommu,
 u32 max_invs_pend, u16 sid, u16 size, u64 addr);
diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index b227e4e..7330c5d 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -190,9 +190,19 @@ static int queue_invalidate_wait(struct iommu *iommu,
 static int invalidate_sync(struct iommu *iommu)
 {
 struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
+int rc;
 
 if ( qi_ctrl->qinval_maddr )
-return queue_invalidate_wait(iommu, 0, 1, 1);
+{
+rc = queue_invalidate_wait(iommu, 0, 1, 1);
+if ( rc )
+{
+if ( rc == -ETIMEDOUT )
+panic("Queue invalidate wait descriptor was timeout.\n");
+return rc;
+}
+}
+
 return 0;
 }
 
@@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
 return 0;
 }
 
+static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
+ u16 seg, u8 bus, u8 devfn)
+{
+struct domain *d;
+struct pci_dev *pdev;
+
+d = rcu_lock_domain_by_id(iommu->domid_map[did]);
+ASSERT(d);
+for_each_pdev(d, pdev)
+{
+if ( (pdev->seg == seg) &&
+ (pdev->bus == bus) &&
+ (pdev->devfn == devfn) )
+{
+if ( pdev->domain )
+{
+list_del(&pdev->domain_list);
+pdev->domain = NULL;
+}
+
+if ( pci_hide_device(bus, devfn) )
+{
+printk(XENLOG_ERR
+   "IOMMU hide device %04x:%02x:%02x error.",
+   seg, bus, devfn);
+break;
+}
+
+break;
+}
+}
+
+if ( !is_hardware_domain(d) )
+domain_crash(d);
+rcu_unlock_domain(d);
+}
+
+int dev_invalidate_iotlb_sync(struct iommu *iommu, u16 did,
+  u16 seg, u8 bus, u8 devfn)
+{
+struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
+int rc;
+
+if ( qi_ctrl->qinval_maddr )
+{
+rc = queue_invalidate_wait(iommu, 0, 1, 1);
+if ( rc )
+{
+if ( rc == -ETIMEDOUT )
+dev_invalidate_iotlb_timeout(iommu, did, seg, bus, devfn);
+return rc;
+}
+}
+
+return 0;
+}
+
 static void queue_invalidate_iec(struct iommu *iommu, u8 granu, u8 im, u16 
iidx)
 {
 unsigned long flags;
@@ -349,9 +416,18 @@ static int flush_iotlb_qi(
 queue_invalidate_iotlb(iommu,
type >> DMA_TLB_FLUSH_GRANU_OFFSET, dr,
dw, did, size_order, 0, addr);
+
+/*
+ * Synchronize with hardware for invalidation request descriptors
+ * submitted before Device-TLB invalidate descriptor.
+ */
+rc = invalidate_sync(iommu);
+if ( rc )
+ return rc;
+
 if ( flush_dev_iotlb )
 ret = dev_invalidate_iotlb(iommu, did, addr, size_order, type);
-rc = invalidate_sync(iommu);
+
 if ( !ret )
 ret = rc;
 }
diff --git a/xen/drivers/passthrough/vtd/x86/ats.c 
b/xen/drivers/passthrough/vtd/x86/ats.c
index 7c797f6..6299f52 100644
--- a/xen/drivers/passthrough

[Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

[Quan Xu]

This patches are based on Kevin Tian's previous discussion 'Revisit VT-d 
asynchronous flush issue'.
Fix current timeout concern and also allow limited ATS support in a light way:

1. Check VT-d Device-TLB flush error.
   This patch checks all kinds of error and all the way up the call trees of 
VT-d Device-TLB flush.

2. Reduce spin timeout to 1ms, which can be boot-time changed with 
'iommu_qi_timeout_ms'.
   For example:
   multiboot /boot/xen.gz ats=1 iommu_qi_timeout_ms=100

3. Fix vt-d Device-TLB flush timeout issue.
Now if IOTLB/Context/IETC flush is timeout, panic hypervisor. The coming 
patch
set will fix it.

If Device-TLB flush is timeout, we'll hide the target ATS
device and crash the domain owning this ATS device.

If impacted domain is hardware domain, just throw out a warning.

The hided Device will be disallowed to be further assigned to
any domain.

--

 * DMAR_OPERATION_TIMEOUT should be also chopped down to a low number of 
milliseconds.
   As Kevin Tian mentioned in 'Revisit VT-d asynchronous flush issue', We also 
confirmed with hardware team
   that 1ms is large enough for IOMMU internal flush. So I can change 
DMAR_OPERATION_TIMEOUT from 1000 ms to 1 ms.

   IOMMU_WAIT_OP() is only for VT-d registers read/write, and there is also a 
panic. We need a further discussion
   whether or how to remove this panic in next patch set.

 * if IOTLB/Context/IETC flush is timeout, panic hypervisor. The coming patch 
set will fix it.


Quan Xu (3):
  VT-d: Check VT-d Device-TLB flush error.
  VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.
  VT-d: Fix vt-d Device-TLB flush timeout issue.

 xen/arch/x86/acpi/power.c |   8 +-
 xen/arch/x86/crash.c  |   3 +-
 xen/arch/x86/domain_build.c   |   5 +-
 xen/arch/x86/mm.c |  15 ++-
 xen/arch/x86/mm/p2m-ept.c |  14 ++-
 xen/arch/x86/mm/p2m-pt.c  |  14 ++-
 xen/arch/x86/mm/p2m.c |  19 +++-
 xen/arch/x86/x86_64/mm.c  |   7 +-
 xen/common/domain.c   |   3 +-
 xen/common/grant_table.c  |   5 +-
 xen/common/memory.c   |  13 ++-
 xen/drivers/passthrough/amd/iommu_init.c  |   4 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |   4 +-
 xen/drivers/passthrough/arm/smmu.c|  13 ++-
 xen/drivers/passthrough/iommu.c   |  47 +---
 xen/drivers/passthrough/pci.c |   2 +-
 xen/drivers/passthrough/vtd/extern.h  |   6 +-
 xen/drivers/passthrough/vtd/iommu.c   | 157 --
 xen/drivers/passthrough/vtd/qinval.c  |  93 ++-
 xen/drivers/passthrough/vtd/quirks.c  |  26 +++--
 xen/drivers/passthrough/vtd/x86/ats.c |  13 +++
 xen/drivers/passthrough/vtd/x86/vtd.c |  13 ++-
 xen/drivers/passthrough/x86/iommu.c   |   6 +-
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |   4 +-
 xen/include/asm-x86/iommu.h   |   2 +-
 xen/include/xen/iommu.h   |  20 ++--
 26 files changed, 403 insertions(+), 113 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v4 1/3] VT-d: Check VT-d Device-TLB flush error.

[Quan Xu]

This patch checks all kinds of error and all the way up
the call trees of VT-d Device-TLB flush.

Signed-off-by: Quan Xu 
---
 xen/arch/x86/acpi/power.c |   8 +-
 xen/arch/x86/crash.c  |   3 +-
 xen/arch/x86/domain_build.c   |   5 +-
 xen/arch/x86/mm.c |  15 ++-
 xen/arch/x86/mm/p2m-ept.c |  14 ++-
 xen/arch/x86/mm/p2m-pt.c  |  14 ++-
 xen/arch/x86/mm/p2m.c |  19 +++-
 xen/arch/x86/x86_64/mm.c  |   7 +-
 xen/common/domain.c   |   3 +-
 xen/common/grant_table.c  |   5 +-
 xen/common/memory.c   |  13 ++-
 xen/drivers/passthrough/amd/iommu_init.c  |   4 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |   4 +-
 xen/drivers/passthrough/arm/smmu.c|  13 ++-
 xen/drivers/passthrough/iommu.c   |  47 +---
 xen/drivers/passthrough/vtd/extern.h  |   4 +-
 xen/drivers/passthrough/vtd/iommu.c   | 157 --
 xen/drivers/passthrough/vtd/qinval.c  |   2 +-
 xen/drivers/passthrough/vtd/quirks.c  |  26 +++--
 xen/drivers/passthrough/vtd/x86/vtd.c |  13 ++-
 xen/drivers/passthrough/x86/iommu.c   |   6 +-
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |   4 +-
 xen/include/asm-x86/iommu.h   |   2 +-
 xen/include/xen/iommu.h   |  20 ++--
 24 files changed, 300 insertions(+), 108 deletions(-)

diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index f41f0de..1974721 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -45,6 +45,8 @@ void do_suspend_lowlevel(void);
 
 static int device_power_down(void)
 {
+int rc;
+
 console_suspend();
 
 time_suspend();
@@ -53,7 +55,9 @@ static int device_power_down(void)
 
 ioapic_suspend();
 
-iommu_suspend();
+rc = iommu_suspend();
+if ( rc )
+return rc;
 
 lapic_suspend();
 
@@ -182,7 +186,7 @@ static int enter_state(u32 state)
 error = tboot_s3_resume();
 break;
 case ACPI_STATE_S5:
-acpi_enter_sleep_state(ACPI_STATE_S5);
+error = acpi_enter_sleep_state(ACPI_STATE_S5);
 break;
 default:
 error = -EINVAL;
diff --git a/xen/arch/x86/crash.c b/xen/arch/x86/crash.c
index 888a214..59e1af6 100644
--- a/xen/arch/x86/crash.c
+++ b/xen/arch/x86/crash.c
@@ -170,7 +170,8 @@ static void nmi_shootdown_cpus(void)
 
 /* Crash shutdown any IOMMU functionality as the crashdump kernel is not
  * happy when booting if interrupt/dma remapping is still enabled */
-iommu_crash_shutdown();
+if ( iommu_crash_shutdown() )
+printk("Failed to shut down IOMMU.\n");
 
 __stop_this_cpu();
 
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index bca6fe7..a11bc2a 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -1627,7 +1627,10 @@ int __init construct_dom0(
 }
 
 if ( d->domain_id == hardware_domid )
-iommu_hwdom_init(d);
+{
+if ( iommu_hwdom_init(d) )
+printk("Xen warning : IOMMU hardware domain init failed.\n");
+}
 
 return 0;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 202ff76..3c1db05 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2443,11 +2443,18 @@ static int __get_page_type(struct page_info *page, 
unsigned long type,
 if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
 {
 if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
+{
+rc = iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
+return rc;
+}
 else if ( type == PGT_writable_page )
-iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
-   page_to_mfn(page),
-   IOMMUF_readable|IOMMUF_writable);
+{
+rc = iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
+page_to_mfn(page),
+IOMMUF_readable|IOMMUF_writable);
+if ( rc )
+return rc;
+}
 }
 }
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 9860c6c..2ed43b0 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -829,15 +829,23 @@ out:
  need_modify_vtd_table )
 {
 if ( iommu_hap_pt_share )
-iommu_pte_flush(d, gfn, &ept_entry->epte, order, vtd_pte_present);
+rc = iommu_pte_flush(d, gfn, &ept_entry->epte, order, 
vtd_pte_present);
 else
 {
 if ( iommu_flags )
 for ( i = 0; i < (1 << order); i++ )
-iommu_map_page(d

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline 
untested
 test-amd64-i386-xl-raw6 xen-bootfail baseline untested
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail baseline untested
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail baseline untested
 test-amd64-amd64-libvirt-vhd  9 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 linux4ef7675344d687a0ef5b0d7c0cee12da005870c0
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  167 days
Failing since 59348  2015-07-10 04:24:05 Z  166 days  113 attempts
Testing same since66896  2015-12-22 00:42:29 Z1 days1 attempts


3412 people touched revisions under test,
not listing them all

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

[Xen-devel] [qemu-upstream-4.2-testing test] 66927: regressions - FAIL

[osstest service owner]

flight 66927 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66927/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 62044
 build-amd64   5 xen-build fail REGR. vs. 62044

Tests which did not succeed, but are not blocking:
 test-i386-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuu5081fc1c773d2a83ec7a867f030323b8b6956cd1
baseline version:
 qemuuc17e602ae64fb24405ebd256679ba9a6f5819086

Last test of basis62044  2015-09-15 15:06:42 Z   98 days
Testing same since66542  2015-12-18 16:37:10 Z4 days5 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-i386-xend-qemuu-winxpsp3  blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-i386-i386-xl-qemuu-winxpsp3 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

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

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


Not pushing.


commit 5081fc1c773d2a83ec7a867f030323b8b6956cd1
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:45:14 2015 +

xenfb: avoid reading twice the same fields from the shared page

Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading the type
field multiple times.

This is part of XSA-155.

Signed-off-by: Stefano Stabellini 

commit 74fab2ef4c0ba42af477e9e445c9883cc45cf9e6
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:44:58 2015 +

xen/blkif: Avoid double access to src->nr_segments

src is stored in shared memory and src->nr_segments is dereferenced
twice at the end of the function.  If a compiler decides to compile this
into two separate memory accesses then the size limitation could be
bypassed.

Fix it by removing the double access to src->nr_segments.

This is part of XSA-155.

Signed-off-by: Stefano Stabellini 

Re: [Xen-devel] xenbits GitHub mirror?

[Jon Ludlam]

On Mon, Dec 21, 2015 at 11:54:52AM +, George Dunlap wrote:
> On Sat, Dec 19, 2015 at 8:51 PM, Doug Goldstein  wrote:
> > All,
> >
> > Now I'll start off by saying that "no" is a perfectly acceptable answer
> > to this suggestion. Basically I remember at the Xen Developer Summit a
> > few people mentioned it being nice if people provided a git tree where
> > their branches were available for testing. I was just thinking it might
> > be easier for third parties to do that if there was an official Xen
> > Project mirror of the main repos on xenbits on GitHub and people could
> > fork that repo and make their branch available. Just a thought.
> 
> So I don't think there would be any objection at all to individual
> contributors sending links to git repos that happened to be hosted on
> github in the cover letter of a patch series posted to xen-devel.
> 
> I also don't think there would be any objection to someone
> *unofficially* maintaining a xenbits mirror on github, and advertising
> its availability on the wiki, as long as it was clear that it was
> unofficial.
>

There's an unofficial mirror maintained by the Mirage team on the
under the mirage organization: https://github.com/mirage/xen

Jon

> I'll let someone who feels more strongly than I do comment on the
> ideological perspective of having an official mirror; but from a
> practical perspective, my concern would be dealing with people who
> clone it and then send pull requests.  I'm pretty sure we will never
> accept pull requests made via github, and as a policy we will
> therefore never look at pull requests.  Having dozens of open,
> un-answered pull requests on github will look bad for the project; and
> manually going through and rejecting every pull request with an
> explanation of why seems like a pain that I'd rather avoid if we can
> help it.
> 
>  -George
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] EVTCHNOP failure while creating VM

[quizyjones]

This is the output when I tried to create a vm in a nested xen. I looked up 
into the source and found error -22 presents invalid arguments. What might be 
the cause?
(XEN) event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(XEN) 
event_channel.c:272:d0 EVTCHNOP failure: domain 1, error -22(d1) HVM Loader(d1) 
Detected Xen v4.4.1(d1) Xenbus rings @0xfeffc000, event channel 3(d1) System 
requested SeaBIOS(d1) CPU speed is 1600 MHz(d1) Relocating guest memory for 
lowmem MMIO space disabled(XEN) irq.c:270: Dom1 PCI link 0 changed 0 -> 5(d1) 
PCI-ISA link 0 routed to IRQ5(XEN) irq.c:270: Dom1 PCI link 1 changed 0 -> 
10(d1) PCI-ISA link 1 routed to IRQ10(XEN) irq.c:270: Dom1 PCI link 2 changed 0 
-> 11(d1) PCI-ISA link 2 routed to IRQ11(XEN) irq.c:270: Dom1 PCI link 3 
changed 0 -> 5(d1) PCI-ISA link 3 routed to IRQ5(d1) pci dev 01:3 
INTA->IRQ10(d1) pci dev 02:0 INTA->IRQ11(d1) pci dev 04:0 INTA->IRQ5(d1) No RAM 
in high memory; setting high_mem resource base to 1(d1) pci dev 03:0 
bar 10 size 00200: 0f008(d1) pci dev 02:0 bar 14 size 00100: 
0f208(d1) pci dev 04:0 bar 30 size 4: 0f300(d1) pci dev 03:0 
bar 30 size 1: 0f304(d1) pci dev 03:0 bar 14 size 01000: 
0f305(d1) pci dev 02:0 bar 10 size 00100: 0c001(d1) pci dev 04:0 
bar 10 size 00100: 0c101(d1) pci dev 04:0 bar 14 size 00100: 
0f3051000(d1) pci dev 01:1 bar 20 size 00010: 0c201(d1) Multiprocessor 
initialisation:(d1)  - CPU0 ... 46-bit phys ... fixed MTRRs ... var MTRRs [2/8] 
... done.(d1) Testing HVM environment:(d1)  - REP INSB across page boundaries 
... passed(d1)  - GS base MSRs and SWAPGS ... passed(d1) Passed 2 of 2 
tests(d1) Writing SMBIOS tables ...(d1) Loading SeaBIOS ...(d1) Creating MP 
tables ...(d1) Loading ACPI ...(d1) vm86 TSS at fc00a080(d1) BIOS map:(d1)  
1-100d3: Scratch space(d1)  e-f: Main BIOS(d1) E820 table:(d1)  
[00]: : - :000a: RAM(d1)  HOLE: :000a - 
:000e(d1)  [01]: :000e - :0010: 
RESERVED(d1)  [02]: :0010 - :1f80: RAM(d1)  HOLE: 
:1f80 - :fc00(d1)  [03]: :fc00 - 
0001:: RESERVED(d1) Invoking SeaBIOS ...(d1) SeaBIOS (version 
rel-1.7.3.1-0-g7d9cbe6-20151216_104417-ubuntu-hvm)(d1)(d1) Found Xen hypervisor 
signature at 4000(d1) xen: copy e820...(d1) Relocating init from 0x000e4161 
to 0x1f7e2950 (size 54768)(d1) CPU Mhz=1600(d1) Found 7 PCI devices (max PCI 
bus is 00)(d1) Allocated Xen hypercall page at 1f7ff000(d1) Detected Xen 
v4.4.1(d1) xen: copy BIOS tables...(d1) Copying SMBIOS entry point from 
0x00010010 to 0x000f1740(d1) Copying MPTABLE from 0xfc001130/fc001140 to 
0x000f1660(d1) Copying PIR from 0x00010030 to 0x000f15e0(d1) Copying ACPI RSDP 
from 0x000100b0 to 0x000f15b0(d1) Using pmtimer, ioport 0xb008, freq 3579 
kHz(d1) Scan for VGA option rom(d1) WARNING! Found unaligned PCI rom 
(vd=1013:00b8)(d1) Running option rom at c000:0003(XEN) stdvga.c:147:d1 
entering stdvga and caching modes(d1) Turning on vga text mode console(d1) 
SeaBIOS (version rel-1.7.3.1-0-g7d9cbe6-20151216_104417-ubuntu-hvm)(d1) Machine 
UUID 71c7de52-a5ed-484b-9ebc-805378916ea9(d1) Found 0 lpt ports(d1) Found 0 
serial ports(d1) ATA controller 1 at 1f0/3f4/c200 (irq 14 dev 9)(d1) ATA 
controller 2 at 170/374/c208 (irq 15 dev 9)(d1) ata0-0: QEMU HARDDISK ATA-7 
Hard-Disk (5120 MiBytes)(d1) Searching bootorder for: 
/pci@i0cf8/*@1,1/drive@0/disk@0(d1) DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 
DVD/CD](d1) Searching bootorder for: /pci@i0cf8/*@1,1/drive@1/disk@0(d1) PS2 
keyboard initialized(d1) All threads complete.(d1) Scan for option roms(d1) 
Running option rom at c900:0003(d1) pmm call arg1=1(d1) pmm ca

[Xen-devel] [qemu-upstream-4.4-testing test] 66918: regressions - FAIL

[osstest service owner]

flight 66918 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66918/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu2264b0c66075cc34c252a1386f019f8be6240890
baseline version:
 qemuu5fe74249f5ab528fe84a26fa60438a6de4c787f0

Last test of basis62702  2015-10-06 15:32:13 Z   77 days
Testing same since66539  2015-12-18 16:12:10 Z4 days4 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64-xend pass
 build-i386-xend  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  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 pass
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass



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

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

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

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


Not pushing.


commit 2264b0c66075cc34c252a1386f019f8be6240890
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:45:14 2015 +

xenfb: avoid reading twice the same fields

[Xen-devel] [qemu-upstream-4.3-testing test] 66933: regressions - FAIL

[osstest service owner]

flight 66933 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66933/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 62112
 build-amd64   5 xen-build fail REGR. vs. 62112

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

version targeted for testing:
 qemuu6e184363e64a0610c35ca231bfc73cea56eb02f3
baseline version:
 qemuub188780861662e8cf1847ec562799b32bb44f05e

Last test of basis62112  2015-09-18 04:07:28 Z   96 days
Testing same since66538  2015-12-18 16:12:07 Z4 days5 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 test-amd64-amd64-pairblocked 
 test-amd64-i386-pair blocked 
 test-amd64-amd64-pv  blocked 
 test-amd64-i386-pv   

Re: [Xen-devel] [PATCH RFC 01/31] xen/public: Export featureset information in the public API

[Andrew Cooper]

On 22/12/2015 16:59, Jan Beulich wrote:
 On 22.12.15 at 17:42,  wrote:
>> On 22/12/15 16:28, Jan Beulich wrote:
>> On 16.12.15 at 22:24,  wrote:
 +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC001, 
 FSMAX+2 */
 +#define X86_FEATURE_XSTORE((FSMAX+1)*32+ 2) /* on-CPU RNG present 
 (xstore insn) */
 +#define X86_FEATURE_XSTORE_EN ((FSMAX+1)*32+ 3) /* on-CPU RNG enabled 
 */
 +#define X86_FEATURE_XCRYPT((FSMAX+1)*32+ 6) /* on-CPU crypto 
 (xcrypt insn) */
 +#define X86_FEATURE_XCRYPT_EN ((FSMAX+1)*32+ 7) /* on-CPU crypto 
 enabled */
 +#define X86_FEATURE_ACE2  ((FSMAX+1)*32+ 8) /* Advanced Cryptography 
 Engine v2 */
 +#define X86_FEATURE_ACE2_EN   ((FSMAX+1)*32+ 9) /* ACE v2 enabled */
 +#define X86_FEATURE_PHE   ((FSMAX+1)*32+10) /* PadLock Hash 
 Engine */
 +#define X86_FEATURE_PHE_EN((FSMAX+1)*32+11) /* PHE enabled */
 +#define X86_FEATURE_PMM   ((FSMAX+1)*32+12) /* PadLock Montgomery 
 Multiplier */
 +#define X86_FEATURE_PMM_EN((FSMAX+1)*32+13) /* PMM enabled */
>>> None of these get consumed anywhere - if you already touch this
>>> code, just drop all of them.
>> X86_FEATURE_XSTORE gets used in xen/arch/x86/cpu/centaur.c to stash word
>> 0xC001, but nothing actually reads the stashed values.
>>
>> I could do a precursor patch which drops the stashing of this
>> information, which will result in NCAPINTS getting shorter by the end of
>> the series.
> Yes, that's what I meant to imply.
>
 +/*
 + * CPUID leaf shorthand:
 + * - optional 'e', Extended (0x8xxx)
 + * - leaf, uppercase hex
 + * - register, lowercase
 + * - optional subleaf, uppercase hex
 + */
 +#define XEN_FEATURESET_1d 0 /* 0x0001.edx  */
 +#define XEN_FEATURESET_1c 1 /* 0x0001.ecx  */
 +#define XEN_FEATURESET_e1d2 /* 0x8001.edx  */
 +#define XEN_FEATURESET_e1c3 /* 0x8001.ecx  */
 +#define XEN_FEATURESET_Da14 /* 0x000d:1.eax*/
 +#define XEN_FEATURESET_7b05 /* 0x0007:0.ebx*/
>>> This ends up being pretty cryptic.
>> Perhaps at a first glance, but there are so many uses that a shorthand
>> really is needed.  See especially the MSR masking patches towards the
>> end of the series.
> I understand that something short is needed. But as the main
> identifier in the ABI?

It really comes down to whom is intended to do what with a featureset.

These values are derivable as functions of the feature values
themselves, but that requires an assumption that the featureset bitmap
mirrors hardware precisely.  Providing this (names not withstanding) as
a part of the ABI is intended to provide that assurance.

I fully intend higher levels of the toolstack to deal with a featureset
as an arbitrary bitmap, but lower levels like libxc do need a greater
level of understanding of its layout.

>
 +#define XEN_NR_FEATURESET_ENTRIES (XEN_FEATURESET_7b0 + 1)
>>> This shouldn't be exposed, as it will necessarily change sooner or later.
>> Hmm yes - I think I can alter where this lives, although libxc does need
>> to be able to get this value.
> Perhaps keep it where it is, but put it inside #ifdef __XEN__?

I reckon it would be better in cpuid-private.h, strictly making it
accessible only to to the components sharing that library.

~Andrew

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

Re: [Xen-devel] Sub page Grant Table mappings

[David Vrabel]

On 22/12/15 20:59, Mike Belopuhov wrote:
> Hi,
> 
> I'm trying to get grant table sub page mappings working on Xen 4.5.
> I know there have been some changes in the trunk regarding moving src/
> dst checks closer together, but I can't test this easily atm.  Please
> bear with me for a moment.  Or tell me that it might have been broken
> previously.
> 
> What I'm trying to do is to map in a 2k cluster from the networking
> stack (we call it an mbuf cluster, you might call it skb something)
> onto the Netfront Rx ring.  2 clusters fit one page.  Therefore for
> one frame address which is a (PA >> 12) I might have 2 entries one
> after the other, both with sub_page.length = 2048 but one with a
> sub_page.page_off = 2048 and the other with a 0 offset.  Both come
> with (GTF_permit_access | GTF_sub_page) flags.

The netif protocol doesn't allow subpages for Rx requests -- the backend
requires a full page to be granted.  Note how struct netif_rx_req only
has id and gref fields.

David

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

Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

[Jan Beulich]

>>> "Wu, Feng"  12/23/15 5:58 AM >>>
>Kevin and Dario gave some comments about this patch. I would like to
>know whether you have any comments about this patch, it is highly
>appreciated if you can give your opinions, which is very important for
>it to get merged as soon as possible. Thank you!

Only after January 6th, and even then I can't predict when I'll get to it. Yes,
it has been pending for a long time, but no, this is not something that I can
just quickly slip between two other things: What you're doing is complicated
and not the prettiest of all things, so it needs careful looking at, and hence
enough time (in one piece).

Jan


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

[Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing

[Paul Durrant]

This patch documents a new shared (variable message length) ring between
frontend and backend that can be used to pass bulk out-of-band data, such
as that required to implement toeplitz hashing in the backend that is
configurable by the frontend.

The patch then goes on to document the messages passed over the control
ring that can be used to configure toeplitz hashing.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/include/public/io/netif.h | 320 ++
 1 file changed, 320 insertions(+)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index 1790ea0..612dbd0 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -151,6 +151,326 @@
  */
 
 /*
+ * Control ring:
+ *
+ * Some features, such as toeplitz hashing (detailed below), require a
+ * significant amount of out-of-band data to be passed from frontend to
+ * backend. Use of xenstore is not suitable for large quantities of data
+ * because of quota limitations and so a dedicated 'control ring' is used.
+ * The ability of the backend to use a control ring is advertised by
+ * setting:
+ *
+ * /local/domain/X/backend///feature-control-ring = "1"
+ *
+ * The frontend provides a control ring to the backend by setting:
+ *
+ * /local/domain//device/vif//ctrl-ring-ref = 
+ * /local/domain//device/vif//event-channel-ctrl = 
+ *
+ * where  is the grant reference of the shared page used to
+ * implement the control ring and  is an event channel to be used
+ * as a mailbox interrupt, before the frontend moves into the connected
+ * state.
+ *
+ * The layout of the shared page is as follows:
+ *
+ *0 1 2 3 4 5 6 7  octet
+ * +-+-+-+-+-+-+-+-+
+ * |req_cons   |req_prod   |
+ * +-+-+-+-+-+-+-+-+
+ * |rsp_cons   |rsp_prod   |
+ * +-+-+-+-+-+-+-+-+
+ * |   |
+ * +   +
+ * |  req[1024]|
+ * .
+ * .
+ * |   |
+ * +-+-+-+-+-+-+-+-+
+ * |   |
+ * +   +
+ * |  rsp[1024]|
+ * .
+ * .
+ * |   |
+ * +-+-+-+-+-+-+-+-+
+ *
+ * This provides a 1024 byte request buffer, a 1024 response buffer and
+ * producer/consumer counts for both. The frontend and backend
+ * communicate using message structures prefaced with the following
+ * header:
+ *
+ * netif_ctrl_msg_hdr_t:
+ *
+ *0 1 2 3 4 5 6 7  octet
+ * +-+-+-+-+-+-+-+-+
+ * | type  | size  |
+ * +-+-+-+-+-+-+-+-+
+ *
+ * The type is one of the NETIF_CTRL_MSG_* values defined below and the
+ * size field specifies how many octets of payload follow the header
+ * (hence size may be 0 for messages not requiring a payload).
+ *
+ * The frontend makes a request by writing a message into the req buffer
+ * (at req_cons modulo 1024, taking care to wrap correctly), incrementing
+ * req_prod by the number of octets written and then sending a mailbox
+ * event to the backend.
+ * The message length may exceed the available space in the buffer
+ * (which can be calculated as req_cons + NETIF_CTRL_RING_SIZE - req_prod)
+ * in which case, as much data should be written as is possible and
+ * req_prod should be incremented by the number of octets written. A
+ * mailbox interrupt should then be sent to the backend to start message
+ * processing and the frontend should not write any more message data
+ * into the req buffer until the backend sends a mailbox interrupt
+ * to the frontend.
+ *
+ * The backend receives a request (when triggered to do so by a mailbox
+ * event) by reading as many octets as it can (which can be calculated
+ * as req_prod - req_cons) from the req buffer (from offset req_cons
+ * modulo 1024, taking care to wrap correctly) into a private buffer and
+ * then incrementing req_cons with the number of octets read.
+ * If a complete header (8 octets) has been read then the backend can
+ * determine how many payload octets it should expect and whether they
+ * have all been read. If they have then the message can be processed.
+ * If they have not then a mailbox event should be sent to the frontend
+ * and backend processing should be suspended until the next mailbox
+ * event arrives).
+ *
+ * The backend sends responses to the frontend using the rsp buffer in
+ * much the same

[Xen-devel] [PATCH 3/3] public/io/netif.h: document new extra info for passing hash values

[Paul Durrant]

To properly support NDIS RSS, the Windows frontend PV driver needs the
toeplitz hash value calculated by the backend (otherwise it would have to
duplicate the calculation).

This patch adds documentation for "feature-hash" and a definition of a
new XEN_NETIF_EXTRA_TYPE_HASH extra info segment which both frontends
and backends can use to pass hash values to the other end.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/include/public/io/netif.h | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index 612dbd0..fd96d87 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -151,6 +151,12 @@
  */
 
 /*
+ * "feature-hash" advertises the capability to accept extra info slots of
+ * type XEN_NETIF_EXTRA_TYPE_HASH. They will not be sent by either end
+ * unless the other end advertises this feature.
+ */
+
+/*
  * Control ring:
  *
  * Some features, such as toeplitz hashing (detailed below), require a
@@ -630,6 +636,18 @@ struct xen_netif_ctrl_msg_hdr {
  * type: Must be XEN_NETIF_EXTRA_TYPE_MCAST_{ADD,DEL}
  * flags: XEN_NETIF_EXTRA_FLAG_*
  * addr: address to add/remove
+ *
+ * XEN_NETIF_EXTRA_TYPE_HASH:
+ *
+ *0 1 2 3 4 5 6 7  octet
+ * +-+-+-+-+-+-+-+-+
+ * |type |flags|htype| pad |LSB  value  MSB|
+ * +-+-+-+-+-+-+-+-+
+ *
+ * type: Must be XEN_NETIF_EXTRA_TYPE_HASH
+ * flags: XEN_NETIF_EXTRA_FLAG_*
+ * htype: XEN_NETIF_HASH_TYPE_*
+ * value: Hash value
  */
 
 /* Protocol checksum field is blank in the packet (hardware offload)? */
@@ -663,7 +681,8 @@ typedef struct netif_tx_request netif_tx_request_t;
 #define XEN_NETIF_EXTRA_TYPE_GSO   (1)  /* u.gso */
 #define XEN_NETIF_EXTRA_TYPE_MCAST_ADD (2)  /* u.mcast */
 #define XEN_NETIF_EXTRA_TYPE_MCAST_DEL (3)  /* u.mcast */
-#define XEN_NETIF_EXTRA_TYPE_MAX   (4)
+#define XEN_NETIF_EXTRA_TYPE_HASH  (4)  /* u.hash */
+#define XEN_NETIF_EXTRA_TYPE_MAX   (5)
 
 /* netif_extra_info_t flags. */
 #define _XEN_NETIF_EXTRA_FLAG_MORE (0)
@@ -675,6 +694,16 @@ typedef struct netif_tx_request netif_tx_request_t;
 #define XEN_NETIF_GSO_TYPE_TCPV6(2)
 
 /*
+ * Hash types. (See NETIF_CTRL_TOEPLITZ_FLAG_* definitions above
+ * for more information).
+ */
+#define XEN_NETIF_HASH_TYPE_NONE0
+#define XEN_NETIF_HASH_TYPE_IPV41
+#define XEN_NETIF_HASH_TYPE_IPV4_TCP2
+#define XEN_NETIF_HASH_TYPE_IPV63
+#define XEN_NETIF_HASH_TYPE_IPV6_TCP4
+
+/*
  * This structure needs to fit within both netif_tx_request_t and
  * netif_rx_response_t for compatibility.
  */
@@ -691,6 +720,11 @@ struct netif_extra_info {
 struct {
 uint8_t addr[6];
 } mcast;
+struct {
+uint8_t type;
+uint8_t pad;
+uint8_t value[4];
+} hash;
 uint16_t pad[3];
 } u;
 };
-- 
2.1.4


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

[Xen-devel] [PATCH 1/3] public/io/netif.h: document transmit and receive wire formats separately

[Paul Durrant]

Currently there is no documented wire format for guest receive-side
packets but the location of the 'wire format' comment block suggests
it is the same as transmit-side. This is almost true but there is a
subtle difference in the use of the 'size' field for the first fragment.

For clarity this patch creates separate comment blocks for receive
and transmit side packet wire formats, tries to be more clear about the
distinction between 'fragments' and 'extras', and documents the subtlety
concerning the size field of the first fragment.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
---
 xen/include/public/io/netif.h | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
index e103cf3..1790ea0 100644
--- a/xen/include/public/io/netif.h
+++ b/xen/include/public/io/netif.h
@@ -151,22 +151,22 @@
  */
 
 /*
- * This is the 'wire' format for packets:
- *  Request 1: netif_tx_request_t -- NETTXF_* (any flags)
- * [Request 2: netif_extra_info_t] (only if request 1 has
- *  NETTXF_extra_info)
- * [Request 3: netif_extra_info_t] (only if request 2 has
- *  XEN_NETIF_EXTRA_MORE)
- *  Request 4: netif_tx_request_t -- NETTXF_more_data
- *  Request 5: netif_tx_request_t -- NETTXF_more_data
- *  ...
- *  Request N: netif_tx_request_t -- 0
- */
-
-/*
  * Guest transmit
  * ==
  *
+ * This is the 'wire' format for packets:
+ *  Fragment 1: netif_tx_request_t  - flags = NETTXF_*
+ *size = total packet size
+ * [Extra 1: netif_extra_info_t]- (only if fragment 1 flags include
+ * NETTXF_extra_info)
+ * [Extra N: netif_extra_info_t]- (only if extra N-1 flags include
+ * XEN_NETIF_EXTRA_MORE)
+ *  ...
+ *  Fragment N: netif_tx_request_t  - (only if fragment N-1 flags include
+ * NETTXF_more_data)
+ *flags = 0
+ *size = fragment size
+ *
  * Ring slot size is 12 octets, however not all request/response
  * structs use the full size.
  *
@@ -202,6 +202,19 @@
  * Guest receive
  * =
  *
+ * This is the 'wire' format for packets:
+ *  Fragment 1: netif_rx_request_t  - flags = NETRXF_*
+ *size = fragment size
+ * [Extra 1: netif_extra_info_t]- (only if fragment 1 flags include
+ * NETRXF_extra_info)
+ * [Extra N: netif_extra_info_t]- (only if extra N-1 flags include
+ * XEN_NETIF_EXTRA_MORE)
+ *  ...
+ *  Fragment N: netif_rx_request_t  - (only if fragment N-1 flags include
+ * NETRXF_more_data)
+ *flags = 0
+ *size = fragment size
+ *
  * Ring slot size is 8 octets.
  *
  * rx request (netif_rx_request_t)
-- 
2.1.4


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

[Xen-devel] [PATCH 0/3] public/io/netif.h: support for toeplitz hashing

[Paul Durrant]

This series documents changes needed to support toeplitz hashing in a
backend, configurable by the frontend.

Patch #1 is a clean-up patch that clarifies the guest transmit and
receive side packet formats.

Patch #2 documents a new 'control ring' for passing bulk data between
frontend and backend. This is needed for passing the hash mapping table
and hash key. It also documents messages to allow a frontend to configure
toeplitz hashing.

Patch #3 documents a new extra info segment that can be used for passing
hash values along with packets on both the transmit and receive side.

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

[Xen-devel] [qemu-upstream-4.5-testing test] 66906: regressions - FAIL

[osstest service owner]

flight 66906 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66906/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 66752 pass in 
66906
 test-amd64-amd64-i386-pvgrub 21 leak-check/checkfail pass in 66752
 test-armhf-armhf-xl-rtds  9 debian-install  fail pass in 66752
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail pass 
in 66752

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 66752 
like 62075
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 66752 like 62414
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10  fail like 62321
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 62414
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 62414

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

version targeted for testing:
 qemuu32bba3499008c847e08858f310d65806e0bade36
baseline version:
 qemuue5a1bb22cfb307db909dbd3404c48e5bbeb9e66d

Last test of basis62414  2015-09-26 20:34:49 Z   87 days
Testing same since66534  2015-12-18 15:48:15 Z4 days4 attempts


People who touched revisions under test:
  Stefano Stabellini 

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
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd6

Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

[Xu, Quan]

> On 23.12.2015 at 4:26pm,  wrote:
> Subject: [PATCH v4 0/3] VT-d Device-TLB flush issue
> Quan Xu (3):
>   VT-d: Check VT-d Device-TLB flush error.
>   VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.
>   VT-d: Fix vt-d Device-TLB flush timeout issue.

Jan, 
If patch 1 is a huge, could you review the patch 2/3 first? 
Any comment, I can fix it ASAP. Then we can make patch 2/3 done before holiday. 

Thanks. Merry Christmas!!
-Quan


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

Re: [Xen-devel] [PATCH RFC 01/31] xen/public: Export featureset information in the public API

[Jan Beulich]

>>> Andrew Cooper  12/23/15 11:05 AM >>>
>On 22/12/2015 16:59, Jan Beulich wrote:
> On 22.12.15 at 17:42,  wrote:
>>> On 22/12/15 16:28, Jan Beulich wrote:
>>> On 16.12.15 at 22:24,  wrote:
> +#define XEN_FEATURESET_1d 0 /* 0x0001.edx  */
> +#define XEN_FEATURESET_1c 1 /* 0x0001.ecx  */
> +#define XEN_FEATURESET_e1d2 /* 0x8001.edx  */
> +#define XEN_FEATURESET_e1c3 /* 0x8001.ecx  */
> +#define XEN_FEATURESET_Da14 /* 0x000d:1.eax*/
> +#define XEN_FEATURESET_7b05 /* 0x0007:0.ebx*/
 This ends up being pretty cryptic.
>>> Perhaps at a first glance, but there are so many uses that a shorthand
>>> really is needed.  See especially the MSR masking patches towards the
>>> end of the series.
>> I understand that something short is needed. But as the main
>> identifier in the ABI?
>
>It really comes down to whom is intended to do what with a featureset.
>
>These values are derivable as functions of the feature values
>themselves, but that requires an assumption that the featureset bitmap
>mirrors hardware precisely.  Providing this (names not withstanding) as
>a part of the ABI is intended to provide that assurance.
>
>I fully intend higher levels of the toolstack to deal with a featureset
>as an arbitrary bitmap, but lower levels like libxc do need a greater
>level of understanding of its layout.

All understood. The question just is whether the main identifiers in the public
header should be this cryptic, or whether consumers should instead introduce
shortcuts of their liking (even more so that, just like noted elsewhere, these
identifiers also lack "CPU" and perhaps "x86" in their names - in the end
feature leveling isn't something that's needed on x86 only).

Jan


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

[Xen-devel] [xen-4.3-testing test] 66934: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-prev  5 xen-build fail REGR. vs. 65650
 build-i386-prev   5 xen-build fail REGR. vs. 65650
 build-i3865 xen-build fail REGR. vs. 65650
 build-armhf   5 xen-build fail REGR. vs. 65650
 build-amd64   5 xen-build fail REGR. vs. 65650

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
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-amd64-rumpuserxen   1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xend-qemut-winxpsp3  1 build-check(1)  blocked n/a

version targeted for testing:
 xen  0574a773238f0ecce3873dc525082f6e16ac655b
baseline ve

Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

[Jan Beulich]

>>> "Xu, Quan"  12/23/15 11:19 AM >>>
>> On 23.12.2015 at 4:26pm,  wrote:
>> Subject: [PATCH v4 0/3] VT-d Device-TLB flush issue
>> Quan Xu (3):
>>   VT-d: Check VT-d Device-TLB flush error.
>>   VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.
>>   VT-d: Fix vt-d Device-TLB flush timeout issue.
>
>If patch 1 is a huge, could you review the patch 2/3 first? 
>Any comment, I can fix it ASAP. Then we can make patch 2/3 done before 
>holiday. 

No, sorry, I'm already not in the office anymore, and won't do patch review
from home in my spare time. This will need to wait.

Jan


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

Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

[Jan Beulich]

>>> Quan Xu  12/23/15 9:26 AM >>>
>This patches are based on Kevin Tian's previous discussion 'Revisit VT-d 
>asynchronous flush issue'.
>Fix current timeout concern and also allow limited ATS support in a light way:
>
>1. Check VT-d Device-TLB flush error.
>This patch checks all kinds of error and all the way up the call trees of VT-d 
>Device-TLB flush.
>
>2. Reduce spin timeout to 1ms, which can be boot-time changed with 
>'iommu_qi_timeout_ms'.
>For example:
>multiboot /boot/xen.gz ats=1 iommu_qi_timeout_ms=100
>
>3. Fix vt-d Device-TLB flush timeout issue.
>Now if IOTLB/Context/IETC flush is timeout, panic hypervisor. The coming patch
>set will fix it.

There must have been a misunderstanding: Your earlier outline didn't indicate 
you
mean to introduce panics here, even if only temporarily. I'm afraid I'm not 
currently
willing to take any conceptually wrong patches anymore with just the promise of
fixing the issue(s) later (and I think we've mentioned this in some past 
discussion
on the list, albeit unlikely in the context of any of your work). This may mean 
that
the earlier described ordering of things you mean to do needs changing.

I'm sorry that you're hit first by this, the more that it was not you but 
colleagues of
yours causing this change to the acceptance model.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 66579

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

version targeted for testing:
 libvirt  d5a0cf10bcc2088420c6c29545a69fd613f1cc4f
baseline version:
 libvirt  5b74103b0bcb8b9c184c1583694d76976753265a

Last test of basis66579  2015-12-19 04:21:33 Z4 days
Testing same since66919  2015-12-22 04:20:28 Z1 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Erik Skultety 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

[Xu, Quan]

> On 23.12.2015 at 6:41pm,  wrote:
> >>> "Xu, Quan"  12/23/15 11:19 AM >>>
> >> On 23.12.2015 at 4:26pm,  wrote:
> >> Subject: [PATCH v4 0/3] VT-d Device-TLB flush issue Quan Xu (3):
> >>   VT-d: Check VT-d Device-TLB flush error.
> >>   VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.
> >>   VT-d: Fix vt-d Device-TLB flush timeout issue.
> >
> >If patch 1 is a huge, could you review the patch 2/3 first?
> >Any comment, I can fix it ASAP. Then we can make patch 2/3 done before
> holiday.
> 
> No, sorry, I'm already not in the office anymore, and won't do patch review
> from home in my spare time. This will need to wait.
> 
ok.


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

Re: [Xen-devel] [PATCH v4 0/3] VT-d Device-TLB flush issue

[Xu, Quan]

> On 23.12.2015 at 6:39pm, 'Jan Beulich' wrote:
> >>> Quan Xu  12/23/15 9:26 AM >>>
> >This patches are based on Kevin Tian's previous discussion 'Revisit VT-d
> asynchronous flush issue'.
> >Fix current timeout concern and also allow limited ATS support in a light 
> >way:
> >
> >1. Check VT-d Device-TLB flush error.
> >This patch checks all kinds of error and all the way up the call trees of 
> >VT-d
> Device-TLB flush.
> >
> >2. Reduce spin timeout to 1ms, which can be boot-time changed with
> 'iommu_qi_timeout_ms'.
> >For example:
> >multiboot /boot/xen.gz ats=1 iommu_qi_timeout_ms=100
> >
> >3. Fix vt-d Device-TLB flush timeout issue.
> >Now if IOTLB/Context/IETC flush is timeout, panic hypervisor. The
> >coming patch set will fix it.
> 
> There must have been a misunderstanding: Your earlier outline didn't indicate
> you mean to introduce panics here, 

It is a panic for iotlb/context/iec flush issue without my patch set.  I just 
move the panic from queue_invalidate_wait() to 
invalidate_sync()..
I did NOT introduce a new panic..


> even if only temporarily. I'm afraid I'm not
> currently willing to take any conceptually wrong patches anymore with just the
> promise of fixing the issue(s) later (and I think we've mentioned this in some
> past discussion on the list, albeit unlikely in the context of any of your 
> work).
> This may mean that the earlier described ordering of things you mean to do
> needs changing.
> 

:(:( .. 

> I'm sorry that you're hit first by this, the more that it was not you but 
> colleagues
> of yours causing this change to the acceptance model.
> 
> 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 RFC 01/31] xen/public: Export featureset information in the public API

[Andrew Cooper]

On 23/12/2015 10:24, Jan Beulich wrote:
 Andrew Cooper  12/23/15 11:05 AM >>>
>> On 22/12/2015 16:59, Jan Beulich wrote:
>> On 22.12.15 at 17:42,  wrote:
 On 22/12/15 16:28, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> +#define XEN_FEATURESET_1d 0 /* 0x0001.edx  */
>> +#define XEN_FEATURESET_1c 1 /* 0x0001.ecx  */
>> +#define XEN_FEATURESET_e1d2 /* 0x8001.edx  */
>> +#define XEN_FEATURESET_e1c3 /* 0x8001.ecx  */
>> +#define XEN_FEATURESET_Da14 /* 0x000d:1.eax*/
>> +#define XEN_FEATURESET_7b05 /* 0x0007:0.ebx*/
> This ends up being pretty cryptic.
 Perhaps at a first glance, but there are so many uses that a shorthand
 really is needed.  See especially the MSR masking patches towards the
 end of the series.
>>> I understand that something short is needed. But as the main
>>> identifier in the ABI?
>> It really comes down to whom is intended to do what with a featureset.
>>
>> These values are derivable as functions of the feature values
>> themselves, but that requires an assumption that the featureset bitmap
>> mirrors hardware precisely.  Providing this (names not withstanding) as
>> a part of the ABI is intended to provide that assurance.
>>
>> I fully intend higher levels of the toolstack to deal with a featureset
>> as an arbitrary bitmap, but lower levels like libxc do need a greater
>> level of understanding of its layout.
> All understood. The question just is whether the main identifiers in the 
> public
> header should be this cryptic, or whether consumers should instead introduce
> shortcuts of their liking (even more so that, just like noted elsewhere, these
> identifiers also lack "CPU" and perhaps "x86" in their names - in the end
> feature leveling isn't something that's needed on x86 only).

For now, I can move them along with XEN_NR_FEATURESET_ENTRIES, because
the only bits of libxc which need them are the bits which are already
using the shared library.


The slight conceptual issue I am concerned about is how this will fit in
with extended work to fix the rest of cpuid handling in Xen.

Other quantities, such as max_leaf and max_phys_addr need levelling
across hosts.  At the moment, all of this information is derived from
dom0's view and is not kept consistent across migrate.  (Surprisingly,
windows notices this, doesn't crash, and decides to install a new CPU
driver.)

Long term, the toolstack needs to level a complete idea of the cpuid
policy for the guest, and the featureset is just one part of this. 
However, I am expecting that the featureset on its own will still be a
useful entity, which is why I progressed down this route.

~Andrew

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

Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing

[Andrew Cooper]

On 23/12/2015 10:06, Paul Durrant wrote:
> +#define NETIF_CTRL_RING_SIZE 1024
> +
> +struct netif_ctrl_ring {
> + RING_IDX req_cons;
> + RING_IDX req_prod;
> + RING_IDX rsp_cons;
> + RING_IDX rsp_prod;
> + uint8_t req[NETIF_CTRL_RING_SIZE];
> + uint8_t rsp[NETIF_CTRL_RING_SIZE];

To avoid making the same mistake as the xenstore ring, this at the very
minimum needs a defined reset protocol.  It should also at least have a
version number (currently expected to be zero) which is used to
delineate the use of the remaining space in the page.

> +};
> +
> +struct xen_netif_ctrl_msg_hdr {
> + uint16_t type;
> + uint16_t len;

These don't match your documentation above.  uint32_t's ?

> +};
> +
> +#define NETIF_CTRL_MSG_ACK  1
> +#define NETIF_CTRL_MSG_GET_TOEPLITZ_FLAGS   2
> +#define NETIF_CTRL_MSG_SET_TOEPLITZ_FLAGS   3
> +#define NETIF_CTRL_MSG_SET_TOEPLITZ_KEY 4
> +#define NETIF_CTRL_MSG_SET_TOEPLITZ_MAPPING 5

What about 0?  Again learning from the xenstore case, can we define 0 as
explicitly an invalid value, so a page of zeroes doesn't appear to be a
valid sequence of messages.

> +
> +/* Control messages: */
> +
> +/*
> + * NETIF_CTRL_MSG_ACK:
> + *
> + * This is the only valid type of message sent by the backend to the
> + * frontend. It carries a payload of the following format:
> + *
> + *0 1 2 3 4 5 6 7  octet
> + * +-+-+-+-+-+-+-+-+

Can I recommend that all ack packets contain the control type they are
responding to.  In the normal case, it indeed shouldn't be needed, but
if the front and back ever get out of sync, it will make debugging far
easier.

~Andrew

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

Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of
> Andrew Cooper
> Sent: 23 December 2015 11:45
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Keir (Xen.org); Ian Campbell; Tim (Xen.org); Ian Jackson; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control
> ring and toeplitz hashing
> 
> On 23/12/2015 10:06, Paul Durrant wrote:
> > +#define NETIF_CTRL_RING_SIZE 1024
> > +
> > +struct netif_ctrl_ring {
> > +   RING_IDX req_cons;
> > +   RING_IDX req_prod;
> > +   RING_IDX rsp_cons;
> > +   RING_IDX rsp_prod;
> > +   uint8_t req[NETIF_CTRL_RING_SIZE];
> > +   uint8_t rsp[NETIF_CTRL_RING_SIZE];
> 
> To avoid making the same mistake as the xenstore ring, this at the very
> minimum needs a defined reset protocol.  It should also at least have a
> version number (currently expected to be zero) which is used to
> delineate the use of the remaining space in the page.

It doesn't need a reset protocol any more than the rx or tx rings do. xenstore 
is a special case, because you can't use xenstore to handle (re)connection (as 
you can in this case) ;-)
Given the boolean feature flag in xenstore then I agree a version number could 
be useful... or the xenstore flag could be changed into a version number.

> 
> > +};
> > +
> > +struct xen_netif_ctrl_msg_hdr {
> > +   uint16_t type;
> > +   uint16_t len;
> 
> These don't match your documentation above.  uint32_t's ?

Yikes, you're right. They should be uint32_ts.

> 
> > +};
> > +
> > +#define NETIF_CTRL_MSG_ACK  1
> > +#define NETIF_CTRL_MSG_GET_TOEPLITZ_FLAGS   2
> > +#define NETIF_CTRL_MSG_SET_TOEPLITZ_FLAGS   3
> > +#define NETIF_CTRL_MSG_SET_TOEPLITZ_KEY 4
> > +#define NETIF_CTRL_MSG_SET_TOEPLITZ_MAPPING 5
> 
> What about 0?  Again learning from the xenstore case, can we define 0 as
> explicitly an invalid value, so a page of zeroes doesn't appear to be a
> valid sequence of messages.

I thought 0 being invalid was kind of obvious from the fact I started at 1, but 
I'll make it explicit.

> 
> > +
> > +/* Control messages: */
> > +
> > +/*
> > + * NETIF_CTRL_MSG_ACK:
> > + *
> > + * This is the only valid type of message sent by the backend to the
> > + * frontend. It carries a payload of the following format:
> > + *
> > + *0 1 2 3 4 5 6 7  octet
> > + * +-+-+-+-+-+-+-+-+
> 
> Can I recommend that all ack packets contain the control type they are
> responding to.  In the normal case, it indeed shouldn't be needed, but
> if the front and back ever get out of sync, it will make debugging far
> easier.

Yep, that's a good idea.

  Paul

> 
> ~Andrew

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

Re: [Xen-devel] [PULL 0/4] xen-2015-12-22

[Peter Maydell]

On 22 December 2015 at 16:20, Stefano Stabellini
 wrote:
> The following changes since commit c3626ca7df027dabf0568284360a23faf18f0884:
>
>   Update version for v2.5.0-rc3 release (2015-12-07 17:47:40 +)
>
> are available in the git repository at:
>
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-12-22
>
> for you to fetch changes up to fc3e493bc8e96ef4bf7ae4f035f43cb39382c936:
>
>   xen_disk: treat "vhd" as "vpc" (2015-12-11 17:02:37 +)
>
> 
> Xen 2015/12/22
>
> 
> Jan Beulich (3):
>   xen/MSI-X: latch MSI-X table writes
>   xen/MSI-X: really enforce alignment
>   xen/pass-through: correctly deal with RW1C bits
>
> Stefano Stabellini (1):
>   xen_disk: treat "vhd" as "vpc"

Applied, thanks.

-- PMM

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

[Xen-devel] VGA Passthrough Tested Adatpers

[Chris Law]

Hey can someone add AMD Radeon R9 390 to the Tested Adapters list here 
http://wiki.xenproject.org/wiki/Xen_VGA_Passthrough_Tested_Adapters
 
I've requested edit access, but don't yet have it.
 
Thanks,
 
Chris. 
  ___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing

[David Vrabel]

On 23/12/15 10:06, Paul Durrant wrote:
> This patch documents a new shared (variable message length) ring between
> frontend and backend that can be used to pass bulk out-of-band data, such
> as that required to implement toeplitz hashing in the backend that is
> configurable by the frontend.
> 
> The patch then goes on to document the messages passed over the control
[...]
> ring that can be used to configure toeplitz hashing.
> --- a/xen/include/public/io/netif.h
> +++ b/xen/include/public/io/netif.h
> @@ -151,6 +151,326 @@
>   */
>  
>  /*
> + * Control ring:
[...]
> + *
> + * The layout of the shared page is as follows:
> + *
> + *0 1 2 3 4 5 6 7  octet
> + * +-+-+-+-+-+-+-+-+
> + * |req_cons   |req_prod   |
> + * +-+-+-+-+-+-+-+-+
> + * |rsp_cons   |rsp_prod   |
> + * +-+-+-+-+-+-+-+-+
> + * |   |
> + * +   +
> + * |  req[1024]|
> + * .
> + * .
> + * |   |
> + * +-+-+-+-+-+-+-+-+
> + * |   |
> + * +   +
> + * |  rsp[1024]|
> + * .
> + * .
> + * |   |
> + * +-+-+-+-+-+-+-+-+

You should use the standard ring format and infrastructure.

David

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

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

[osstest service owner]

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

Regressions :-(

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

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

[Xen-devel] [qemu-upstream-4.6-testing test] 66923: regressions - FAIL

[osstest service owner]

flight 66923 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66923/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2   6 xen-boot   fail in 66773 pass in 66923
 test-armhf-armhf-xl-arndale   5 xen-installfail in 66773 pass in 66923
 test-armhf-armhf-xl   6 xen-bootfail pass in 66773

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  9 debian-installfail REGR. vs. 63071
 test-armhf-armhf-xl-vhd   9 debian-di-install fail in 66773 like 63071
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 63071
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 63071

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

version targeted for testing:
 qemuu9e304f572ac98265f5e7433b6490077962acda97
baseline version:
 qemuu980dfcf5b8d8161871f81d1987b2f8ea5d7d4db9

Last test of basis63071  2015-10-19 15:10:58 Z   64 days
Testing same since66535  2015-12-18 15:50:42 Z4 days4 attempts


People who touched revisions under test:
  Stefano Stabellini 

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-amd6

[Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well

[Tamas K Lengyel]

Add altp2m information to HVM events as well when altp2m is active.

Cc: Razvan Cojocaru 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Signed-off-by: Tamas K Lengyel 
---
 xen/arch/x86/hvm/event.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index 73c8f14..a3d4892 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static void hvm_event_fill_regs(vm_event_request_t *req)
@@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync, vm_event_request_t 
*req)
 vm_event_vcpu_pause(curr);
 }
 
+if ( altp2m_active(currd) )
+{
+req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
+req->altp2m_idx = vcpu_altp2m(curr).p2midx;
+}
+
 hvm_event_fill_regs(req);
 vm_event_put_request(currd, &currd->vm_event->monitor, req);
 
-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Tamas K Lengyel]

Introduce new vm_event domctl option which allows an event subscriber
to request all vCPUs not currently pending a vm_event request to be paused,
thus allowing the subscriber to sync up on the state of the domain. This
is especially useful when the subscribed wants to disable certain events
from being delivered and wants to ensure no more requests are pending on the
ring before doing so.

Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Razvan Cojocaru 
Signed-off-by: Tamas K Lengyel 
---
 tools/libxc/include/xenctrl.h | 11 +++
 tools/libxc/xc_vm_event.c | 16 
 xen/common/vm_event.c | 23 +++
 xen/include/public/domctl.h   | 14 +-
 4 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 01a6dda..27bb907 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2433,6 +2433,17 @@ int xc_monitor_emulate_each_rep(xc_interface *xch, 
domid_t domain_id,
 bool enable);
 
 /***
+ * xc_vm_event_sync_on can be used by a vm_event subscriber to pause all vCPUs
+ * that do not currently have a pending vm_event request. This allows the
+ * subscriber to sync up on the domain's status and process all outstanding
+ * vm_event requests without any new ones being placed on the ring. A caller
+ * of xc_vm_event_sync_on can resume these vCPUs by calling
+ * xc_vm_event_sync_off.
+ */
+int xc_vm_event_sync_on(xc_interface *xch, domid_t domain_id);
+int xc_vm_event_sync_off(xc_interface *xch, domid_t domain_id);
+
+/***
  * Memory sharing operations.
  *
  * Unles otherwise noted, these calls return 0 on succes, -1 and errno on
diff --git a/tools/libxc/xc_vm_event.c b/tools/libxc/xc_vm_event.c
index 2fef96a..6b39908 100644
--- a/tools/libxc/xc_vm_event.c
+++ b/tools/libxc/xc_vm_event.c
@@ -156,3 +156,19 @@ void *xc_vm_event_enable(xc_interface *xch, domid_t 
domain_id, int param,
 
 return ring_page;
 }
+
+int xc_vm_event_sync_on(xc_interface *xch, domid_t domain_id)
+{
+return xc_vm_event_control(xch, domain_id,
+   XEN_VM_EVENT_ENABLE,
+   XEN_DOMCTL_VM_EVENT_OP_SYNC,
+   NULL);
+}
+
+int xc_vm_event_sync_off(xc_interface *xch, domid_t domain_id)
+{
+return xc_vm_event_control(xch, domain_id,
+   XEN_VM_EVENT_DISABLE,
+   XEN_DOMCTL_VM_EVENT_OP_SYNC,
+   NULL);
+}
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 28a7add..b8298bd 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -726,6 +726,29 @@ int vm_event_domctl(struct domain *d, 
xen_domctl_vm_event_op_t *vec,
 break;
 #endif
 
+case XEN_DOMCTL_VM_EVENT_OP_SYNC:
+{
+struct vcpu *v;
+rc = 0;
+
+switch( vec->op )
+{
+case XEN_VM_EVENT_ENABLE:
+for_each_vcpu( d, v )
+if ( !atomic_read(&v->vm_event_pause_count) )
+vcpu_pause(v);
+break;
+
+default:
+for_each_vcpu( d, v )
+if ( !atomic_read(&v->vm_event_pause_count) )
+vcpu_unpause(v);
+break;
+};
+}
+break;
+
+
 default:
 rc = -ENOSYS;
 }
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 7a56b3f..486c667 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -749,7 +749,8 @@ struct xen_domctl_gdbsx_domstatus {
  * sharing, monitor and paging. This hypercall allows one to
  * control these rings (enable/disable), as well as to signal
  * to the hypervisor to pull responses (resume) from the given
- * ring.
+ * ring. Sync will pause/unpause all vCPUs which don't have
+ * a pending vm_event.
  */
 #define XEN_VM_EVENT_ENABLE   0
 #define XEN_VM_EVENT_DISABLE  1
@@ -810,6 +811,17 @@ struct xen_domctl_gdbsx_domstatus {
  */
 #define XEN_DOMCTL_VM_EVENT_OP_SHARING   3
 
+/*
+ * SYNC is a special vm_event operation where all vCPUs get paused
+ * to allow the toolstack to sync up with the state of the domain,
+ * without any new vm_event requests being produced by the domain
+ * on any of the rings.
+ * When issued with ENABLE all the vCPUs get paused that aren't
+ * already paused for a vm_event request. When issued with DISABLE
+ * or RESUME the vCPUs without a pending vm_event request get unpaused.
+ */
+#define XEN_DOMCTL_VM_EVENT_OP_SYNC   4
+
 /* Use for teardown/setup of helper<->hypervisor interface for paging, 
  * access and sharing.*/
 struct xen_domctl_vm_event_op {
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] x86/VPMU: Check more carefully which bits are allowed to be written to MSRs

[Boris Ostrovsky]

On 12/23/2015 12:21 AM, Tian, Kevin wrote:

From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
Sent: Wednesday, December 23, 2015 12:25 AM

Current Intel VPMU emulation needs to perform more checks when writing
PMU MSRs on guest's behalf:
* MSR_CORE_PERF_GLOBAL_CTRL is not checked at all
* MSR_CORE_PERF_FIXED_CTR_CTRL has more reserved bits in PMU version 2
* MSR_CORE_PERF_GLOBAL_OVF_CTRL's bit 61 is allowed on versions greater
* than 2.

We can also use precomputed mask in core2_vpmu_do_interrupt().

Signed-off-by: Boris Ostrovsky 

Acked-by: Kevin Tian 



I think I missed one more register. Let me send another version.

-boris

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

Re: [Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Razvan Cojocaru]

On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
> Introduce new vm_event domctl option which allows an event subscriber
> to request all vCPUs not currently pending a vm_event request to be paused,
> thus allowing the subscriber to sync up on the state of the domain. This
> is especially useful when the subscribed wants to disable certain events
> from being delivered and wants to ensure no more requests are pending on the
> ring before doing so.
> 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> Cc: Razvan Cojocaru 
> Signed-off-by: Tamas K Lengyel 

This certainly looks very interesting. Would xc_domain_pause() not be
enough for your use case then?


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well

[Razvan Cojocaru]

On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
> Add altp2m information to HVM events as well when altp2m is active.
> 
> Cc: Razvan Cojocaru 
> Cc: Keir Fraser 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Signed-off-by: Tamas K Lengyel 
> ---
>  xen/arch/x86/hvm/event.c | 7 +++
>  1 file changed, 7 insertions(+)

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

[Xen-devel] [PATCH v2 0/2] Be more strict about writing to Intel VPMU registers

[Boris Ostrovsky]

* Add more checks when writing VPMU control registers
* Explicitly disable PEBS since calculating reserved bits in 
MSR_IA32_PEBS_ENABLE
  is somewhat non-trivial (and pointless since PEBS is not supported)


Boris Ostrovsky (2):
  x86/VPMU: Check more carefully which bits are allowed to be written
to MSRs
  x86/VPMU: Don't allow any non-zero writes to MSR_IA32_PEBS_ENABLE

 xen/arch/x86/cpu/vpmu_intel.c |   31 ++-
 1 files changed, 22 insertions(+), 9 deletions(-)


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

[Xen-devel] [PATCH v2 2/2] x86/VPMU: Don't allow any non-zero writes to MSR_IA32_PEBS_ENABLE

[Boris Ostrovsky]

Calculation reserved bits for MSR_IA32_PEBS_ENABLE is model-dependent
and since we don't support PEBS anyway we shouldn't allow any writes to
it (but let's still permit guests wishing to disable PEBS).

We should also report PEBS as unsupported to HVM, just like we do on PV.

Signed-off-by: Boris Ostrovsky 
---
 xen/arch/x86/cpu/vpmu_intel.c |   13 ++---
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 03cfe50..a179717 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -264,7 +264,6 @@ static void core2_vpmu_set_msr_bitmap(unsigned long 
*msr_bitmap)
  clear_bit(msraddr_to_bitpos(MSR_P6_EVNTSEL(i)), msr_bitmap);
 
 clear_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR_CTRL), msr_bitmap);
-clear_bit(msraddr_to_bitpos(MSR_IA32_PEBS_ENABLE), msr_bitmap);
 clear_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
 }
 
@@ -296,7 +295,6 @@ static void core2_vpmu_unset_msr_bitmap(unsigned long 
*msr_bitmap)
 set_bit(msraddr_to_bitpos(MSR_P6_EVNTSEL(i)), msr_bitmap);
 
 set_bit(msraddr_to_bitpos(MSR_CORE_PERF_FIXED_CTR_CTRL), msr_bitmap);
-set_bit(msraddr_to_bitpos(MSR_IA32_PEBS_ENABLE), msr_bitmap);
 set_bit(msraddr_to_bitpos(MSR_IA32_DS_AREA), msr_bitmap);
 }
 
@@ -368,7 +366,6 @@ static inline void __core2_vpmu_load(struct vcpu *v)
 wrmsrl(MSR_CORE_PERF_FIXED_CTR_CTRL, core2_vpmu_cxt->fixed_ctrl);
 if ( vpmu_is_set(vcpu_vpmu(v), VPMU_CPU_HAS_DS) )
 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) )
 {
@@ -394,6 +391,8 @@ static int core2_vpmu_verify(struct vcpu *v)
 return -EINVAL;
 if ( core2_vpmu_cxt->global_ctrl & global_ctrl_mask )
 return -EINVAL;
+if ( core2_vpmu_cxt->pebs_enable )
+return -EINVAL;
 
 fixed_ctrl = core2_vpmu_cxt->fixed_ctrl;
 if ( fixed_ctrl & fixed_ctrl_mask )
@@ -606,10 +605,9 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
  "MSR_PERF_GLOBAL_STATUS(0x38E)!\n");
 return -EINVAL;
 case MSR_IA32_PEBS_ENABLE:
-if ( msr_content & 1 )
-gdprintk(XENLOG_WARNING, "Guest is trying to enable PEBS, "
- "which is not supported.\n");
-core2_vpmu_cxt->pebs_enable = msr_content;
+if ( msr_content )
+/* PEBS is reported as unavailable in MSR_IA32_MISC_ENABLE */
+return -EINVAL;
 return 0;
 case MSR_IA32_DS_AREA:
 if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_DS) )
@@ -733,6 +731,7 @@ static int core2_vpmu_do_rdmsr(unsigned int msr, uint64_t 
*msr_content)
 /* Extension for BTS */
 if ( vpmu_is_set(vpmu, VPMU_CPU_HAS_BTS) )
 *msr_content &= ~MSR_IA32_MISC_ENABLE_BTS_UNAVAIL;
+*msr_content |= MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL;
 }
 
 return 0;
-- 
1.7.1


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

[Xen-devel] [PATCH v2 1/2] x86/VPMU: Check more carefully which bits are allowed to be written to MSRs

[Boris Ostrovsky]

Current Intel VPMU emulation needs to perform more checks when writing
PMU MSRs on guest's behalf:
* MSR_CORE_PERF_GLOBAL_CTRL is not checked at all
* MSR_CORE_PERF_FIXED_CTR_CTRL has more reserved bits in PMU version 2
* MSR_CORE_PERF_GLOBAL_OVF_CTRL's bit 61 is allowed on versions greater
* than 2.

We can also use precomputed mask in core2_vpmu_do_interrupt().

Signed-off-by: Boris Ostrovsky 
Acked-by: Kevin Tian 
---
 xen/arch/x86/cpu/vpmu_intel.c |   18 --
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 3eff1ae..03cfe50 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -87,7 +87,7 @@ 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;
+static uint64_t __read_mostly global_ovf_ctrl_mask, global_ctrl_mask;
 
 /* Total size of PMU registers block (copied to/from PV(H) guest) */
 static unsigned int __read_mostly regs_sz;
@@ -392,6 +392,8 @@ static int core2_vpmu_verify(struct vcpu *v)
 
 if ( core2_vpmu_cxt->global_ovf_ctrl & global_ovf_ctrl_mask )
 return -EINVAL;
+if ( core2_vpmu_cxt->global_ctrl & global_ctrl_mask )
+return -EINVAL;
 
 fixed_ctrl = core2_vpmu_cxt->fixed_ctrl;
 if ( fixed_ctrl & fixed_ctrl_mask )
@@ -627,6 +629,8 @@ 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:
+if ( msr_content & global_ctrl_mask )
+return -EINVAL;
 core2_vpmu_cxt->global_ctrl = msr_content;
 break;
 case MSR_CORE_PERF_FIXED_CTR_CTRL:
@@ -820,7 +824,7 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 if ( is_pmc_quirk )
 handle_pmc_quirk(msr_content);
 core2_vpmu_cxt->global_status |= msr_content;
-msr_content = 0xC007 | ((1 << arch_pmc_cnt) - 1);
+msr_content = ~global_ovf_ctrl_mask;
 wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
 }
 else
@@ -1001,10 +1005,20 @@ int __init core2_vpmu_init(void)
 full_width_write = (caps >> 13) & 1;
 
 fixed_ctrl_mask = ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1);
+if ( version == 2 )
+fixed_ctrl_mask |= 0x444;
 fixed_counters_mask = ~((1ull << core2_get_bitwidth_fix_count()) - 1);
+global_ctrl_mask = ~1ULL << fixed_pmc_cnt) - 1) << 32) |
+ ((1ULL << arch_pmc_cnt) - 1));
 global_ovf_ctrl_mask = ~(0xC000 |
  (((1ULL << fixed_pmc_cnt) - 1) << 32) |
  ((1ULL << arch_pmc_cnt) - 1));
+if ( version > 2 )
+/*
+ * Even though we don't support Uncore counters guests should be
+ * able to clear all available overflows.
+ */
+global_ovf_ctrl_mask &= ~(1ULL << 61);
 
 regs_sz = (sizeof(struct xen_pmu_intel_ctxt) - regs_off) +
   sizeof(uint64_t) * fixed_pmc_cnt +
-- 
1.7.1


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

Re: [Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Andrew Cooper]

On 23/12/2015 15:41, Razvan Cojocaru wrote:
> On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>> Introduce new vm_event domctl option which allows an event subscriber
>> to request all vCPUs not currently pending a vm_event request to be paused,
>> thus allowing the subscriber to sync up on the state of the domain. This
>> is especially useful when the subscribed wants to disable certain events
>> from being delivered and wants to ensure no more requests are pending on the
>> ring before doing so.
>>
>> Cc: Ian Jackson 
>> Cc: Stefano Stabellini 
>> Cc: Ian Campbell 
>> Cc: Wei Liu 
>> Cc: Razvan Cojocaru 
>> Signed-off-by: Tamas K Lengyel 
> This certainly looks very interesting. Would xc_domain_pause() not be
> enough for your use case then?

I second this query.  I would have thought xc_domain_pause() does
exactly what you want in this case.

The code provided is racy, as it is liable to alter which pause
references it takes/releases depending on what other pause/unpause
actions are being made.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] vm_event: Add altp2m info to HVM events as well

[Andrew Cooper]

On 23/12/2015 15:42, Razvan Cojocaru wrote:
> On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>> Add altp2m information to HVM events as well when altp2m is active.
>>
>> Cc: Razvan Cojocaru 
>> Cc: Keir Fraser 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> Signed-off-by: Tamas K Lengyel 
>> ---
>>  xen/arch/x86/hvm/event.c | 7 +++
>>  1 file changed, 7 insertions(+)
> Acked-by: Razvan Cojocaru 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [distros-debian-squeeze test] 38554: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed
baseline version:
 flight   38469

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubpass
 test-amd64-i386-amd64-squeeze-netboot-pygrub pass
 test-amd64-amd64-i386-squeeze-netboot-pygrub pass
 test-amd64-i386-i386-squeeze-netboot-pygrub  pass



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

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

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


Push not applicable.


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a

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

Last test of basis65543  2015-12-08 08:45:15 Z   15 days
Failing since 65593  2015-12-08 23:44:51 Z   14 days   12 attempts
Testing same since67012  2015-12-23 00:50:02 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Cecil Sheng 
  Chao Zhang 
  Dandan Bi 
  Daocheng Bu 
  Eric Dong 
  Eugene Cohen 
  Feng Tian 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Laszlo Ersek 
  Leekha Shaveta 
  Liming Gao 
  Mark Rutland 
  Michael Kinney 
  Paulo Alcantara 
  Qin Long 
  Qiu Shumin 
  Ruiyu Ni 
  Samer El-Haj-Mahmoud 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 

jobs:
 build-amd64-xsm  fail
 build-i386-xsm   fail
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Tamas K Lengyel]

On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper 
wrote:

> On 23/12/2015 15:41, Razvan Cojocaru wrote:
> > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
> >> Introduce new vm_event domctl option which allows an event subscriber
> >> to request all vCPUs not currently pending a vm_event request to be
> paused,
> >> thus allowing the subscriber to sync up on the state of the domain. This
> >> is especially useful when the subscribed wants to disable certain events
> >> from being delivered and wants to ensure no more requests are pending
> on the
> >> ring before doing so.
> >>
> >> Cc: Ian Jackson 
> >> Cc: Stefano Stabellini 
> >> Cc: Ian Campbell 
> >> Cc: Wei Liu 
> >> Cc: Razvan Cojocaru 
> >> Signed-off-by: Tamas K Lengyel 
> > This certainly looks very interesting. Would xc_domain_pause() not be
> > enough for your use case then?
>
> I second this query.  I would have thought xc_domain_pause() does
> exactly what you want in this case.
>

The problem is in what order the responses are processed. I may not be
correct about the logic but here is what my impression was:
xc_domain_unpause resumes all vCPUs even if there is still a vm_event
response that has not been processed. Now, if the subscriber set response
flags (altp2m switch, singlestep toggle, etc) those actions would not be
properly performed on the vCPU before it's resumed. If the subscriber
processes all requests and signals via the event channel that the responses
are on the ring, then calls xc_domain_unpause, we can still have a race
between processing the responses from the ring and unpausing the vCPU.


> The code provided is racy, as it is liable to alter which pause
> references it takes/releases depending on what other pause/unpause
> actions are being made.
>

It's understood that the user would not use xc_domain_pause/unpause while
using vm_event responses with response flags specified. Even then, it was
already racy IMHO if the user called xc_domain_unpause before processing
requests from the vm_event ring that originally paused the vCPU, so this
doesn't change that situation.

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

[Xen-devel] [xen-4.6-testing test] 66942: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 65639
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail like 65639

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

version targeted for testing:
 xen  eb32a519f5945dc7465f1f4f555e2dd9654250b7
baseline version:
 xen  850bcd0f42e4912b6605a2caa42d5c466ed58bd1

Last test of basis65639  2015-12-09 21:22:40 Z   13 days
Failing since 66394  2015-12-15 18:17:32 Z8 days7 attempts
Testing same since66942  2015-12-22 11:53:37 Z1 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Brendan Gregg 
  Daniel Kiper 
  Dario Faggioli 
  David Vrabel 
  Ed Swierk 
  Haozhong Zhang 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Malcolm Crossley 

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-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pa

Re: [Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Razvan Cojocaru]

On 12/23/2015 08:11 PM, Tamas K Lengyel wrote:
> 
> 
> On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper
> mailto:andrew.coop...@citrix.com>> wrote:
> 
> On 23/12/2015 15:41, Razvan Cojocaru wrote:
> > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
> >> Introduce new vm_event domctl option which allows an event subscriber
> >> to request all vCPUs not currently pending a vm_event request to be 
> paused,
> >> thus allowing the subscriber to sync up on the state of the domain. 
> This
> >> is especially useful when the subscribed wants to disable certain 
> events
> >> from being delivered and wants to ensure no more requests are pending 
> on the
> >> ring before doing so.
> >>
> >> Cc: Ian Jackson  >
> >> Cc: Stefano Stabellini  >
> >> Cc: Ian Campbell  >
> >> Cc: Wei Liu mailto:wei.l...@citrix.com>>
> >> Cc: Razvan Cojocaru  >
> >> Signed-off-by: Tamas K Lengyel  >
> > This certainly looks very interesting. Would xc_domain_pause() not be
> > enough for your use case then?
> 
> I second this query.  I would have thought xc_domain_pause() does
> exactly what you want in this case.
> 
> 
> The problem is in what order the responses are processed. I may not be
> correct about the logic but here is what my impression was:
> xc_domain_unpause resumes all vCPUs even if there is still a vm_event
> response that has not been processed. Now, if the subscriber set
> response flags (altp2m switch, singlestep toggle, etc) those actions
> would not be properly performed on the vCPU before it's resumed. If the
> subscriber processes all requests and signals via the event channel that
> the responses are on the ring, then calls xc_domain_unpause, we can
> still have a race between processing the responses from the ring and
> unpausing the vCPU.
>  
> 
> The code provided is racy, as it is liable to alter which pause
> references it takes/releases depending on what other pause/unpause
> actions are being made.
> 
> 
> It's understood that the user would not use xc_domain_pause/unpause
> while using vm_event responses with response flags specified. Even then,
> it was already racy IMHO if the user called xc_domain_unpause before
> processing requests from the vm_event ring that originally paused the
> vCPU, so this doesn't change that situation.

There are a bunch of checks in vcpu_wake() (xen/common/schedule.c) that
I've always assumed guard against the problem you're describing. I may
be wrong (I don't have any experience with the scheduling code), but
even if I am, I still think having xc_domain_pause() /
xc_domain_unpause() behave correctly is better than adding a new libxc
function. Is that an unreasonable goal?


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Andrew Cooper]

On 23/12/2015 18:11, Tamas K Lengyel wrote:
>
>
> On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper
> mailto:andrew.coop...@citrix.com>> wrote:
>
> On 23/12/2015 15:41, Razvan Cojocaru wrote:
> > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
> >> Introduce new vm_event domctl option which allows an event
> subscriber
> >> to request all vCPUs not currently pending a vm_event request
> to be paused,
> >> thus allowing the subscriber to sync up on the state of the
> domain. This
> >> is especially useful when the subscribed wants to disable
> certain events
> >> from being delivered and wants to ensure no more requests are
> pending on the
> >> ring before doing so.
> >>
> >> Cc: Ian Jackson  >
> >> Cc: Stefano Stabellini  >
> >> Cc: Ian Campbell  >
> >> Cc: Wei Liu mailto:wei.l...@citrix.com>>
> >> Cc: Razvan Cojocaru  >
> >> Signed-off-by: Tamas K Lengyel  >
> > This certainly looks very interesting. Would xc_domain_pause()
> not be
> > enough for your use case then?
>
> I second this query.  I would have thought xc_domain_pause() does
> exactly what you want in this case.
>
>
> The problem is in what order the responses are processed. I may not be
> correct about the logic but here is what my impression was:
> xc_domain_unpause resumes all vCPUs even if there is still a vm_event
> response that has not been processed. Now, if the subscriber set
> response flags (altp2m switch, singlestep toggle, etc) those actions
> would not be properly performed on the vCPU before it's resumed. If
> the subscriber processes all requests and signals via the event
> channel that the responses are on the ring, then calls
> xc_domain_unpause, we can still have a race between processing the
> responses from the ring and unpausing the vCPU.
>  
>
> The code provided is racy, as it is liable to alter which pause
> references it takes/releases depending on what other pause/unpause
> actions are being made.
>
>
> It's understood that the user would not use xc_domain_pause/unpause
> while using vm_event responses with response flags specified. Even
> then, it was already racy IMHO if the user called xc_domain_unpause
> before processing requests from the vm_event ring that originally
> paused the vCPU, so this doesn't change that situation.

Pausing is strictly reference counted. (or rather, it is since c/s
3eb1c70 "properly reference count DOMCTL_{,un}pausedomain hypercalls". 
Before then, it definitely was buggy.)

There is the domain pause count, and pause counts per vcpu.  All domain
pause operations take both a domain pause reference, and a vcpu pause
reference on each vcpu.  A vcpu is only eligible to be scheduled if its
pause reference count is zero.  If two independent tasks call
vcpu_pause() on the same vcpu, it will remain paused until both
independent tasks have called vcpu_unpause().

Having said this, I can well believe that there might be issues with the
current uses of pausing.

The vital factor is that the entity which pauses a vcpu is also
responsible for unpausing it, and it must be resistant to accidentally
leaking its reference.

In this case, I believe that what you want to do is:

1) Identify condition requiring a sync
2) xc_domain_pause()
3) Process all of the pending vm_events
4) Synchronise the state
5) xc_domain_unpause()

All vcpus of the domain should stay descheduled between points 2 and 5. 
If this doesn't have the intended effect, then I suspect there is a bug
in the pause reference handing of the vm_event subsystem.

Is this clearer, or have I misunderstood the problem?

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

[Xen-devel] [PATCH] xen: remove dups in x86 and x86_64 variables

[Doug Goldstein]

Currently the Xen build uses x86 and x86_64 variables as well as
CONFIG_X86 and CONFIG_X86_64. This just removes the duplication. The
CONFIG_ variables are now managed by Kconfig but existed previously so
this duplication existed prior to the Kconfig migration.

Signed-off-by: Doug Goldstein 
---
This patch should be purely mechanical. The build of this is identical on my
machine except for build date/time.
---
 xen/Rules.mk | 2 +-
 xen/arch/x86/Makefile| 4 ++--
 xen/arch/x86/Rules.mk| 4 
 xen/arch/x86/efi/Makefile| 2 +-
 xen/arch/x86/mm/Makefile | 6 +++---
 xen/arch/x86/mm/hap/Makefile | 2 +-
 xen/common/Makefile  | 2 +-
 xen/drivers/acpi/Makefile| 6 +++---
 xen/drivers/passthrough/Makefile | 8 
 xen/drivers/passthrough/vtd/Makefile | 2 +-
 10 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index 8839dca..f7ddc69 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -45,7 +45,7 @@ ALL_OBJS-y   += $(BASEDIR)/common/built_in.o
 ALL_OBJS-y   += $(BASEDIR)/drivers/built_in.o
 ALL_OBJS-y   += $(BASEDIR)/xsm/built_in.o
 ALL_OBJS-y   += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
-ALL_OBJS-$(x86)  += $(BASEDIR)/crypto/built_in.o
+ALL_OBJS-$(CONFIG_X86)   += $(BASEDIR)/crypto/built_in.o
 
 CFLAGS += -nostdinc -fno-builtin -fno-common
 CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d4e507a..6448a23 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -5,7 +5,7 @@ subdir-y += hvm
 subdir-y += mm
 subdir-y += oprofile
 
-subdir-$(x86_64) += x86_64
+subdir-$(CONFIG_X86_64) += x86_64
 
 obj-bin-y += alternative.init.o
 obj-y += apic.o
@@ -67,7 +67,7 @@ obj-$(crash_debug) += gdbstub.o
 
 x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
 
-efi-$(x86_64) := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
+efi-$(CONFIG_X86_64) := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
 -O $(BASEDIR)/include/xen/compile.h ]; then \
  echo '$(TARGET).efi'; fi)
 
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 4ca69a1..b76a754 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -22,10 +22,6 @@ $(call as-insn-check,CFLAGS,CC,".equ \"x\"$$(comma)1", \
  -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM \
  '-D__OBJECT_LABEL__=$(subst $(BASEDIR)/,,$(CURDIR))/$$@')
 
-x86 := y
-x86_32 := n
-x86_64 := y
-
 shadow-paging ?= y
 bigmem?= n
 
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 1daa7ac..c6c2fa6 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -4,7 +4,7 @@ obj-y += stub.o
 
 create = test -e $(1) || touch -t 19990101 $(1)
 
-efi := $(filter y,$(x86_64)$(shell rm -f disabled))
+efi := $(filter y,$(CONFIG_X86_64)$(shell rm -f disabled))
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
 efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
diff --git a/xen/arch/x86/mm/Makefile b/xen/arch/x86/mm/Makefile
index aeccdfc..61b7428 100644
--- a/xen/arch/x86/mm/Makefile
+++ b/xen/arch/x86/mm/Makefile
@@ -6,9 +6,9 @@ obj-y += p2m.o p2m-pt.o p2m-ept.o p2m-pod.o
 obj-y += altp2m.o
 obj-y += guest_walk_2.o
 obj-y += guest_walk_3.o
-obj-$(x86_64) += guest_walk_4.o
-obj-$(x86_64) += mem_paging.o
-obj-$(x86_64) += mem_sharing.o
+obj-$(CONFIG_X86_64) += guest_walk_4.o
+obj-$(CONFIG_X86_64) += mem_paging.o
+obj-$(CONFIG_X86_64) += mem_sharing.o
 
 guest_walk_%.o: guest_walk.c Makefile
$(CC) $(CFLAGS) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
diff --git a/xen/arch/x86/mm/hap/Makefile b/xen/arch/x86/mm/hap/Makefile
index 68f2bb5..14cb29d 100644
--- a/xen/arch/x86/mm/hap/Makefile
+++ b/xen/arch/x86/mm/hap/Makefile
@@ -1,7 +1,7 @@
 obj-y += hap.o
 obj-y += guest_walk_2level.o
 obj-y += guest_walk_3level.o
-obj-$(x86_64) += guest_walk_4level.o
+obj-$(CONFIG_X86_64) += guest_walk_4level.o
 obj-y += nested_hap.o
 obj-y += nested_ept.o
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 8ab15ba..a8132db 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -65,7 +65,7 @@ obj-$(xenoprof)+= xenoprof.o
 
 obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o kernel.o memory.o 
multicall.o tmem_xen.o xlat.o)
 
-subdir-$(x86_64) += hvm
+subdir-$(CONFIG_X86_64) += hvm
 
 subdir-$(coverage) += gcov
 
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index 3bb626e..d8a4299 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -1,11 +1,11 @@
 subdir-y += tables
 subdir-y += utilit

Re: [Xen-devel] [PATCH] xen: remove dups in x86 and x86_64 variables

[Andrew Cooper]

On 23/12/2015 19:15, Doug Goldstein wrote:
> Currently the Xen build uses x86 and x86_64 variables as well as
> CONFIG_X86 and CONFIG_X86_64. This just removes the duplication. The
> CONFIG_ variables are now managed by Kconfig but existed previously so
> this duplication existed prior to the Kconfig migration.
>
> Signed-off-by: Doug Goldstein 

Acked-by: Andrew Cooper 

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

[Xen-devel] [xen-unstable baseline-only test] 38553: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels 
fail REGR. vs. 38528
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 38528
 test-amd64-amd64-xl-credit2  19 guest-start/debian.repeatfail   like 38528
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 38528
 test-amd64-amd64-pygrub  10 guest-start  fail   like 38528
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 38528
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 38528
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 38528

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

version targeted for testing:
 xen  bf925a9f1254391749f569c1b8fc606036340488
baseline version:
 xen  18fcef8d62b28766e7b373a71d54bcf7578cea23

Last test of basis38528  2015-12-17 08:08:25 Z6 days
Testing same since38553  2015-12-23 06:28:47 Z0 days1 attempts


People who touched revisions under test:
  Alex Xu 
  Andrew Cooper 
  Boris Ostrovsky 
  Daniel De Graaf 
  David Vrabel 
  Doug Goldstein 
  Huaitong Han 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Malcolm Crossley 
  Razvan Cojocaru 
  Shuai Ruan 
  Stefano Stabellini 
  Yu Zhang 

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

[Xen-devel] [linux-3.16 test] 66976: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 64969

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd   5 xen-installfail in 66479 pass in 66976
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 66479

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 64969
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail in 66479 like 64969
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 66479 like 64969
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail in 66479 like 64969
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail in 66479 like 64969
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10   fail   like 64969
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 64969

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

version targeted for testing:
 linux70a95b3e395fa9f5a5cf531c56ae7e5b6ed37e32
baseline version:
 linuxa11efd7b42bf716f528b4f163cd86ba1e499354a

Last test of basis64969  2015-11-20 22:00:18 Z   32 days
Testing same since66400  2015-12-15 18:22:25 Z8 days7 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Al Viro 
  Alan Stern 
  Alex Deucher 
  Alexandra Yates 
  Alexandre Belloni 
  Amitkumar Karwar 
  Andrew Morton 
  Andrey Ryabinin 
  Andrzej Hajda 
  Andy Leiserson 
  Andy Shevchenko 
  Ani Sinha 
  Anna Schumaker 
  Arik Nemtsov 
  Arik Nemtsov 
  Arnaldo Carvalho de Melo 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Bjørn Mork 
  Boris Brezillon 
  Borislav Petkov 
  Brian

Re: [Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Tamas K Lengyel]

On Wed, Dec 23, 2015 at 8:14 PM, Andrew Cooper 
wrote:

> On 23/12/2015 18:11, Tamas K Lengyel wrote:
>
>
>
> On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper 
> wrote:
>
>> On 23/12/2015 15:41, Razvan Cojocaru wrote:
>> > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>> >> Introduce new vm_event domctl option which allows an event subscriber
>> >> to request all vCPUs not currently pending a vm_event request to be
>> paused,
>> >> thus allowing the subscriber to sync up on the state of the domain.
>> This
>> >> is especially useful when the subscribed wants to disable certain
>> events
>> >> from being delivered and wants to ensure no more requests are pending
>> on the
>> >> ring before doing so.
>> >>
>> >> Cc: Ian Jackson 
>> >> Cc: Stefano Stabellini < 
>> stefano.stabell...@eu.citrix.com>
>> >> Cc: Ian Campbell 
>> >> Cc: Wei Liu 
>> >> Cc: Razvan Cojocaru < 
>> rcojoc...@bitdefender.com>
>> >> Signed-off-by: Tamas K Lengyel < 
>> ta...@tklengyel.com>
>> > This certainly looks very interesting. Would xc_domain_pause() not be
>> > enough for your use case then?
>>
>> I second this query.  I would have thought xc_domain_pause() does
>> exactly what you want in this case.
>>
>
> The problem is in what order the responses are processed. I may not be
> correct about the logic but here is what my impression was:
> xc_domain_unpause resumes all vCPUs even if there is still a vm_event
> response that has not been processed. Now, if the subscriber set response
> flags (altp2m switch, singlestep toggle, etc) those actions would not be
> properly performed on the vCPU before it's resumed. If the subscriber
> processes all requests and signals via the event channel that the responses
> are on the ring, then calls xc_domain_unpause, we can still have a race
> between processing the responses from the ring and unpausing the vCPU.
>
>
>> The code provided is racy, as it is liable to alter which pause
>> references it takes/releases depending on what other pause/unpause
>> actions are being made.
>>
>
> It's understood that the user would not use xc_domain_pause/unpause while
> using vm_event responses with response flags specified. Even then, it was
> already racy IMHO if the user called xc_domain_unpause before processing
> requests from the vm_event ring that originally paused the vCPU, so this
> doesn't change that situation.
>
>
> Pausing is strictly reference counted. (or rather, it is since c/s 3eb1c70
> "properly reference count DOMCTL_{,un}pausedomain hypercalls".  Before
> then, it definitely was buggy.)
>
> There is the domain pause count, and pause counts per vcpu.  All domain
> pause operations take both a domain pause reference, and a vcpu pause
> reference on each vcpu.  A vcpu is only eligible to be scheduled if its
> pause reference count is zero.  If two independent tasks call vcpu_pause()
> on the same vcpu, it will remain paused until both independent tasks have
> called vcpu_unpause().
>
> Having said this, I can well believe that there might be issues with the
> current uses of pausing.
>
> The vital factor is that the entity which pauses a vcpu is also
> responsible for unpausing it, and it must be resistant to accidentally
> leaking its reference.
>
> In this case, I believe that what you want to do is:
>
> 1) Identify condition requiring a sync
> 2) xc_domain_pause()
> 3) Process all of the pending vm_events
> 4) Synchronise the state
> 5) xc_domain_unpause()
>
> All vcpus of the domain should stay descheduled between points 2 and 5.
> If this doesn't have the intended effect, then I suspect there is a bug in
> the pause reference handing of the vm_event subsystem.
>
> Is this clearer, or have I misunderstood the problem?
>

The problem is with step 4&5 IMHO. The event channel notification AFAIK is
asynchronous in that it just starts the processing of the pending vm_event
responses and returns, doesn't wait for the responses to be all processed.
Now if we progress to step 5, we might still have some responses on the
ring which have not gotten processed yet, so there is a race-condition.
There is currently no way to get a notification when all responses have
been processed, so the best thing we can do is to make sure we can
pause/unpause vCPUs without pending requests/responses as those are safe to
be resumed, while restricting the other vCPUs to be only unpaused through
the pending vm_event response. I hope this make sense.

That being said, I haven't yet encountered an instance where this
racecondition was lost, so this is just a pre-caution.

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

[Xen-devel] [PATCH v6 09/16] qapi: Change Netdev into a flat union

[Eric Blake]

From: Kővágó, Zoltán 

Except qapi-schema.json, this patch was generated by:

find . -name .git -prune -o -type f \! -name '*~' -print0 | \
  xargs -0 sed -i \
-e 's/NetClientOptionsKind/NetClientDriver/g' \
-e 's/NET_CLIENT_OPTIONS_KIND_/NET_CLIENT_DRIVER_/g' \
-e 's/netdev->opts/netdev/g'

Signed-off-by: Kővágó, Zoltán 
Message-Id: 
<01a527fbf1a5de880091f98cf011616a78ad.1441627176.git.dirty.ice...@gmail.com>

Additional changes:
Rebase the patch on top of an earlier change from netdev->kind to
netdev->type, so that tweak is no longer needed here.  Rebase to
latest master which enhanced multiqueue.

Rework so that NetdevLegacy doesn't pollute QMP command but is instead
copied piecewise into the new Netdev, which means that NetClientOptions
must still remain in qapi. Since legacy previously always rejected
'hubport', we can now make that explicit by having the two unions be
slightly different; but that means we must manually map between the
two structures.

Signed-off-by: Eric Blake 

---
v6: rebase to latest master
---
 hw/arm/musicpal.c|   2 +-
 hw/core/qdev-properties-system.c |   2 +-
 hw/net/allwinner_emac.c  |   2 +-
 hw/net/cadence_gem.c |   2 +-
 hw/net/dp8393x.c |   2 +-
 hw/net/e1000.c   |   2 +-
 hw/net/eepro100.c|   2 +-
 hw/net/etraxfs_eth.c |   2 +-
 hw/net/fsl_etsec/etsec.c |   2 +-
 hw/net/imx_fec.c |   2 +-
 hw/net/lan9118.c |   2 +-
 hw/net/lance.c   |   2 +-
 hw/net/mcf_fec.c |   2 +-
 hw/net/milkymist-minimac2.c  |   2 +-
 hw/net/mipsnet.c |   2 +-
 hw/net/ne2000-isa.c  |   2 +-
 hw/net/ne2000.c  |   2 +-
 hw/net/opencores_eth.c   |   2 +-
 hw/net/pcnet-pci.c   |   2 +-
 hw/net/rocker/rocker_fp.c|   2 +-
 hw/net/rtl8139.c |   2 +-
 hw/net/smc91c111.c   |   2 +-
 hw/net/spapr_llan.c  |   2 +-
 hw/net/stellaris_enet.c  |   2 +-
 hw/net/vhost_net.c   |  16 ++---
 hw/net/virtio-net.c  |  10 +--
 hw/net/vmxnet3.c |   2 +-
 hw/net/xen_nic.c |   2 +-
 hw/net/xgmac.c   |   2 +-
 hw/net/xilinx_axienet.c  |   2 +-
 hw/net/xilinx_ethlite.c  |   2 +-
 hw/usb/dev-network.c |   2 +-
 include/net/net.h|   4 +-
 monitor.c|  14 ++---
 net/dump.c   |   6 +-
 net/hub.c|  22 +++
 net/l2tpv3.c |   6 +-
 net/net.c| 133 +--
 net/netmap.c |   4 +-
 net/slirp.c  |   6 +-
 net/socket.c |   8 +--
 net/tap-win32.c  |   6 +-
 net/tap.c|  24 +++
 net/vde.c|   6 +-
 net/vhost-user.c |  18 +++---
 qapi-schema.json |  57 +
 46 files changed, 234 insertions(+), 166 deletions(-)

diff --git a/hw/arm/musicpal.c b/hw/arm/musicpal.c
index b534bb9..527b703 100644
--- a/hw/arm/musicpal.c
+++ b/hw/arm/musicpal.c
@@ -374,7 +374,7 @@ static void eth_cleanup(NetClientState *nc)
 }

 static NetClientInfo net_mv88w8618_info = {
-.type = NET_CLIENT_OPTIONS_KIND_NIC,
+.type = NET_CLIENT_DRIVER_NIC,
 .size = sizeof(NICState),
 .receive = eth_receive,
 .cleanup = eth_cleanup,
diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
index ad3c428ff..959fdea 100644
--- a/hw/core/qdev-properties-system.c
+++ b/hw/core/qdev-properties-system.c
@@ -229,7 +229,7 @@ static void set_netdev(Object *obj, Visitor *v, const char 
*name,
 }

 queues = qemu_find_net_clients_except(str, peers,
-  NET_CLIENT_OPTIONS_KIND_NIC,
+  NET_CLIENT_DRIVER_NIC,
   MAX_QUEUE_NUM);
 if (queues == 0) {
 err = -ENOENT;
diff --git a/hw/net/allwinner_emac.c b/hw/net/allwinner_emac.c
index 0407dee..4fdf824 100644
--- a/hw/net/allwinner_emac.c
+++ b/hw/net/allwinner_emac.c
@@ -422,7 +422,7 @@ static const MemoryRegionOps aw_emac_mem_ops = {
 };

 static NetClientInfo net_aw_emac_info = {
-.type = NET_CLIENT_OPTIONS_KIND_NIC,
+.type = NET_CLIENT_DRIVER_NIC,
 .size = sizeof(NICState),
 .can_receive = aw_emac_can_receive,
 .receive = aw_emac_receive,
diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
index 3639fc1..9fe7d19 100644
--- a/hw/net/cadence_gem.c
+++ b/hw/net/cadence_gem.c
@@ -1181,7 +1181,7 @@ static void gem_set_link(NetClientState *nc)
 }

 static NetClientInfo net_gem_info = {
-.type = NET_CLIENT_OPTIONS_KIND_NIC,
+.type = NET_CLIENT_DRIVER_NIC,
 .size = sizeof(NICState),
 .can_receive = gem_can_rec

Re: [Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Tamas K Lengyel]

On Wed, Dec 23, 2015 at 9:55 PM, Tamas K Lengyel 
wrote:

>
>
>
> On Wed, Dec 23, 2015 at 8:14 PM, Andrew Cooper 
> wrote:
>
>> On 23/12/2015 18:11, Tamas K Lengyel wrote:
>>
>>
>>
>> On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper > > wrote:
>>
>>> On 23/12/2015 15:41, Razvan Cojocaru wrote:
>>> > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>>> >> Introduce new vm_event domctl option which allows an event subscriber
>>> >> to request all vCPUs not currently pending a vm_event request to be
>>> paused,
>>> >> thus allowing the subscriber to sync up on the state of the domain.
>>> This
>>> >> is especially useful when the subscribed wants to disable certain
>>> events
>>> >> from being delivered and wants to ensure no more requests are pending
>>> on the
>>> >> ring before doing so.
>>> >>
>>> >> Cc: Ian Jackson 
>>> >> Cc: Stefano Stabellini 
>>> >> Cc: Ian Campbell 
>>> >> Cc: Wei Liu 
>>> >> Cc: Razvan Cojocaru 
>>> >> Signed-off-by: Tamas K Lengyel 
>>> > This certainly looks very interesting. Would xc_domain_pause() not be
>>> > enough for your use case then?
>>>
>>> I second this query.  I would have thought xc_domain_pause() does
>>> exactly what you want in this case.
>>>
>>
>> The problem is in what order the responses are processed. I may not be
>> correct about the logic but here is what my impression was:
>> xc_domain_unpause resumes all vCPUs even if there is still a vm_event
>> response that has not been processed. Now, if the subscriber set response
>> flags (altp2m switch, singlestep toggle, etc) those actions would not be
>> properly performed on the vCPU before it's resumed. If the subscriber
>> processes all requests and signals via the event channel that the responses
>> are on the ring, then calls xc_domain_unpause, we can still have a race
>> between processing the responses from the ring and unpausing the vCPU.
>>
>>
>>> The code provided is racy, as it is liable to alter which pause
>>> references it takes/releases depending on what other pause/unpause
>>> actions are being made.
>>>
>>
>> It's understood that the user would not use xc_domain_pause/unpause while
>> using vm_event responses with response flags specified. Even then, it was
>> already racy IMHO if the user called xc_domain_unpause before processing
>> requests from the vm_event ring that originally paused the vCPU, so this
>> doesn't change that situation.
>>
>>
>> Pausing is strictly reference counted. (or rather, it is since c/s
>> 3eb1c70 "properly reference count DOMCTL_{,un}pausedomain hypercalls".
>> Before then, it definitely was buggy.)
>>
>> There is the domain pause count, and pause counts per vcpu.  All domain
>> pause operations take both a domain pause reference, and a vcpu pause
>> reference on each vcpu.  A vcpu is only eligible to be scheduled if its
>> pause reference count is zero.  If two independent tasks call vcpu_pause()
>> on the same vcpu, it will remain paused until both independent tasks have
>> called vcpu_unpause().
>>
>
Actually, I've double-checked and v->pause_count and
v->vm_event_pause_count are both increased for a vm_event request. So you
are right, the reference counting will make sure that v->pause_count > 0
until we process the vm_event response and call xc_domain_unpause. I was
under the impression that wasn't the case. We can ignore this patch.

Thanks and sorry for the noise ;)
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] vm_event: sync domctl

[Andrew Cooper]

On 23/12/2015 21:06, Tamas K Lengyel wrote:
>
>
> On Wed, Dec 23, 2015 at 9:55 PM, Tamas K Lengyel  > wrote:
>
>
>
>
> On Wed, Dec 23, 2015 at 8:14 PM, Andrew Cooper
> mailto:andrew.coop...@citrix.com>> wrote:
>
> On 23/12/2015 18:11, Tamas K Lengyel wrote:
>>
>>
>> On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper
>> > > wrote:
>>
>> On 23/12/2015 15:41, Razvan Cojocaru wrote:
>> > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>> >> Introduce new vm_event domctl option which allows an
>> event subscriber
>> >> to request all vCPUs not currently pending a vm_event
>> request to be paused,
>> >> thus allowing the subscriber to sync up on the state
>> of the domain. This
>> >> is especially useful when the subscribed wants to
>> disable certain events
>> >> from being delivered and wants to ensure no more
>> requests are pending on the
>> >> ring before doing so.
>> >>
>> >> Cc: Ian Jackson > >
>> >> Cc: Stefano Stabellini
>> > >
>> >> Cc: Ian Campbell > >
>> >> Cc: Wei Liu > >
>> >> Cc: Razvan Cojocaru > >
>> >> Signed-off-by: Tamas K Lengyel > >
>> > This certainly looks very interesting. Would
>> xc_domain_pause() not be
>> > enough for your use case then?
>>
>> I second this query.  I would have thought
>> xc_domain_pause() does
>> exactly what you want in this case.
>>
>>
>> The problem is in what order the responses are processed. I
>> may not be correct about the logic but here is what my
>> impression was: xc_domain_unpause resumes all vCPUs even if
>> there is still a vm_event response that has not been
>> processed. Now, if the subscriber set response flags (altp2m
>> switch, singlestep toggle, etc) those actions would not be
>> properly performed on the vCPU before it's resumed. If the
>> subscriber processes all requests and signals via the event
>> channel that the responses are on the ring, then calls
>> xc_domain_unpause, we can still have a race between
>> processing the responses from the ring and unpausing the vCPU.
>>  
>>
>> The code provided is racy, as it is liable to alter which
>> pause
>> references it takes/releases depending on what other
>> pause/unpause
>> actions are being made.
>>
>>
>> It's understood that the user would not use
>> xc_domain_pause/unpause while using vm_event responses with
>> response flags specified. Even then, it was already racy IMHO
>> if the user called xc_domain_unpause before processing
>> requests from the vm_event ring that originally paused the
>> vCPU, so this doesn't change that situation.
>
> Pausing is strictly reference counted. (or rather, it is since
> c/s 3eb1c70 "properly reference count DOMCTL_{,un}pausedomain
> hypercalls".  Before then, it definitely was buggy.)
>
> There is the domain pause count, and pause counts per vcpu. 
> All domain pause operations take both a domain pause
> reference, and a vcpu pause reference on each vcpu.  A vcpu is
> only eligible to be scheduled if its pause reference count is
> zero.  If two independent tasks call vcpu_pause() on the same
> vcpu, it will remain paused until both independent tasks have
> called vcpu_unpause().
>
>
> Actually, I've double-checked and v->pause_count and
> v->vm_event_pause_count are both increased for a vm_event request. So
> you are right, the reference counting will make sure that
> v->pause_count > 0 until we process the vm_event response and call
> xc_domain_unpause. I was under the impression that wasn't the case. We
> can ignore this patch.
>
> Thanks and sorry for the noise ;)

Not a problem at all.  This is complicated stuff, and IMO it was equally
as likely that there was a real bug lurking.

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

[Xen-devel] [PATCH] cleancache: constify cleancache_ops structure

[Julia Lawall]

The cleancache_ops structure is never modified, so declare it as const.

This also removes the __read_mostly declaration on the cleancache_ops
variable declaration, since it seems redundant with const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---

Not sure that the __read_mostly change is correct.  Does it apply to the
variable, or to what the variable points to?

 drivers/xen/tmem.c |2 +-
 include/linux/cleancache.h |2 +-
 mm/cleancache.c|4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/cleancache.h b/include/linux/cleancache.h
index bda5ec0b4..cb3e142 100644
--- a/include/linux/cleancache.h
+++ b/include/linux/cleancache.h
@@ -37,7 +37,7 @@ struct cleancache_ops {
void (*invalidate_fs)(int);
 };
 
-extern int cleancache_register_ops(struct cleancache_ops *ops);
+extern int cleancache_register_ops(const struct cleancache_ops *ops);
 extern void __cleancache_init_fs(struct super_block *);
 extern void __cleancache_init_shared_fs(struct super_block *);
 extern int  __cleancache_get_page(struct page *);
diff --git a/drivers/xen/tmem.c b/drivers/xen/tmem.c
index 945fc43..4ac2ca8 100644
--- a/drivers/xen/tmem.c
+++ b/drivers/xen/tmem.c
@@ -242,7 +242,7 @@ static int tmem_cleancache_init_shared_fs(char *uuid, 
size_t pagesize)
return xen_tmem_new_pool(shared_uuid, TMEM_POOL_SHARED, pagesize);
 }
 
-static struct cleancache_ops tmem_cleancache_ops = {
+static const struct cleancache_ops tmem_cleancache_ops = {
.put_page = tmem_cleancache_put_page,
.get_page = tmem_cleancache_get_page,
.invalidate_page = tmem_cleancache_flush_page,
diff --git a/mm/cleancache.c b/mm/cleancache.c
index 8fc5081..c6356d6 100644
--- a/mm/cleancache.c
+++ b/mm/cleancache.c
@@ -22,7 +22,7 @@
  * cleancache_ops is set by cleancache_register_ops to contain the pointers
  * to the cleancache "backend" implementation functions.
  */
-static struct cleancache_ops *cleancache_ops __read_mostly;
+static const struct cleancache_ops *cleancache_ops;
 
 /*
  * Counters available via /sys/kernel/debug/cleancache (if debugfs is
@@ -49,7 +49,7 @@ static void cleancache_register_ops_sb(struct super_block 
*sb, void *unused)
 /*
  * Register operations for cleancache. Returns 0 on success.
  */
-int cleancache_register_ops(struct cleancache_ops *ops)
+int cleancache_register_ops(const struct cleancache_ops *ops)
 {
if (cmpxchg(&cleancache_ops, NULL, ops))
return -EBUSY;


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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 linux3a02f35dee2867eca8966d01848a3f523260f675
baseline version:
 linux

Re: [Xen-devel] [PATCH] xen: remove dups in x86 and x86_64 variables

[Wu, Feng]

> -Original Message-
> From: Doug Goldstein [mailto:car...@cardoe.com]
> Sent: Thursday, December 24, 2015 3:15 AM
> To: xen-devel@lists.xen.org
> Cc: Wu, Feng ; Tian, Kevin ;
> George Dunlap ; Andrew Cooper
> ; Jan Beulich ; Keir Fraser
> ; Doug Goldstein 
> Subject: [PATCH] xen: remove dups in x86 and x86_64 variables
> 
> Currently the Xen build uses x86 and x86_64 variables as well as
> CONFIG_X86 and CONFIG_X86_64. This just removes the duplication. The
> CONFIG_ variables are now managed by Kconfig but existed previously so
> this duplication existed prior to the Kconfig migration.
> 
> Signed-off-by: Doug Goldstein 
> ---
> This patch should be purely mechanical. The build of this is identical on my
> machine except for build date/time.
> ---
>  xen/Rules.mk | 2 +-
>  xen/arch/x86/Makefile| 4 ++--
>  xen/arch/x86/Rules.mk| 4 
>  xen/arch/x86/efi/Makefile| 2 +-
>  xen/arch/x86/mm/Makefile | 6 +++---
>  xen/arch/x86/mm/hap/Makefile | 2 +-
>  xen/common/Makefile  | 2 +-
>  xen/drivers/acpi/Makefile| 6 +++---
>  xen/drivers/passthrough/Makefile | 8 
>  xen/drivers/passthrough/vtd/Makefile | 2 +-

Acked-by: Feng Wu  for the VT-d part.

Thanks,
Feng

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt15 guest-saverestore.2 fail in 66856 pass in 66999
 test-armhf-armhf-xl-credit2   5 xen-installfail in 66856 pass in 66999
 test-armhf-armhf-xl-rtds  9 debian-install  fail pass in 66856
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
66856
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail pass 
in 66856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 66856 like 66426
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10  fail like 66395
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 66426
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66426
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66426

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

version targeted for testing:
 xen  172797ecdfd4e2cfece6a401b7b000799534c84e
baseline version:
 xen  4c11414775a28ccd29a33c62cd89e202feb631d7

Last test of basis66426  2015-12-16 11:30:16 Z7 days
Failing since 66473  2015-12-17 18:53:22 Z6 days5 attempts
Testing same since66553  2015-12-18 21:22:14 Z5 days4 attempts


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

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  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-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail 

[Xen-devel] question about migration

[Wen Congyang]

Hi Andrew Cooper:

I rebase the COLO codes to the newest upstream xen, and test it. I found
a problem in the test, and I can reproduce this problem via the migration.

How to reproduce:
1. xl cr -p hvm_nopv
2. xl migrate hvm_nopv 192.168.3.1

The migration successes, but the vm doesn't run in the target machine.
You can get the reason from 'xl dmesg':
(XEN) HVM2 restore: VMCE_VCPU 1
(XEN) HVM2 restore: TSC_ADJUST 0
(XEN) HVM2 restore: TSC_ADJUST 1
(d2) HVM Loader
(d2) Detected Xen v4.7-unstable
(d2) Get guest memory maps[128] failed. (-38)
(d2) *** HVMLoader bug at e820.c:39
(d2) *** HVMLoader crashed.

The reason is that:
We don't call xc_domain_set_memory_map() in the target machine.
When we create a hvm domain:
libxl__domain_build()
libxl__build_hvm()
libxl__arch_domain_construct_memmap()
xc_domain_set_memory_map()

Should we migrate the guest memory from source machine to target machine?

Thanks
Wen Congyang



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

Re: [Xen-devel] how to enable kdb for xen

[quizyjones]

Hi, Elena. I tried to patch xen-4.4.1 with the patches at 
http://lists.xen.org/archives/html/xen-devel/2014-04/msg3.html. However, 
after the patching, when I make with kdb=y, it would interrupt for error: 
'struct domain' has no member named 'is_paused_by_controller'. Does the patch 
really work with xen-4.4?

> Date: Fri, 18 Dec 2015 23:58:52 -0500
> Subject: Re: [Xen-devel] how to enable kdb for xen
> From: ufimts...@gmail.com
> To: quizy_jo...@outlook.com
> CC: konrad.w...@oracle.com; elena.ufimts...@oracle.com; t...@xen.org; 
> xen-devel@lists.xen.org
> 
> On Fri, Dec 18, 2015 at 11:24 PM, quizyjones  wrote:
> > Is there any progress?
> 
> Hey
> 
> I did look into this and I could not find the trace of what I have
> done before. So I decided to ytu and port it to current version from
> this Mukesh patch:
> http://lists.xen.org/archives/html/xen-devel/2014-04/msg3.html
> It looks like it applied without major issues, but I have not tested
> it yet, but its in my plan for next week.
> 
> Elena
> 
> >
> >> Date: Wed, 16 Dec 2015 09:42:47 -0500
> >> From: ufimts...@gmail.com
> >> To: konrad.w...@oracle.com
> >> CC: elena.ufimts...@oracle.com; quizy_jo...@outlook.com; t...@xen.org;
> >> xen-devel@lists.xen.org
> >> Subject: Re: [Xen-devel] how to enable kdb for xen
> >
> >>
> >> On Wed, Dec 16, 2015 at 9:30 AM, Konrad Rzeszutek Wilk
> >>  wrote:
> >> > On December 16, 2015 3:08:04 AM EST, quizyjones
> >> >  wrote:
> >> >>The version embedded with kdb only updates to 4.1.0. How can I use it
> >> >>with xen 4.6? Or is there any other debuggers which can step in Xen?
> >> >
> >> > CCing Elena who poked at it some point. Not sure if she got it ported
> >> > over though.
> >> >>
> >> >>From: quizy_jo...@outlook.com
> >> >>To: xen-devel@lists.xen.org
> >> >>Date: Wed, 16 Dec 2015 06:57:02 +
> >> >>Subject: [Xen-devel] how to enable kdb for xen
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>I tried to debug xen use kdb. After compiling xen with debug=y, is
> >> >>there any further steps I should take? I can get console outputs start
> >> >>with: Xen 4.4.1 (XEN) Xen version 4.4.1 (root@) (gcc
> >> >>(Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4) debug=y Wed Dec 16 11:01:14
> >> >>.But I can't step into the boot procedure. The kdb seems not built
> >> >>in and there is no kdb folder in /tools/debugger. How can I build
> >> >>xen-4.4.1/xen-4.4.6 with kdb?
> >>
> >> Hey!
> >> If I recall correctly, I did try to port kdb. Let me find out what
> >> happened there.
> >>
> >> Elena
> >>
> >> >>
> >> >>
> >> >>
> >> >>___
> >> >>Xen-devel mailing list
> >> >>Xen-devel@lists.xen.org
> >> >>http://lists.xen.org/xen-devel
> >> >>
> >> >>
> >> >>
> >> >>___
> >> >>Xen-devel mailing list
> >> >>Xen-devel@lists.xen.org
> >> >>http://lists.xen.org/xen-devel
> >> >
> >> >
> >> >
> >> > ___
> >> > Xen-devel mailing list
> >> > Xen-devel@lists.xen.org
> >> > http://lists.xen.org/xen-devel
> >>
> >>
> >>
> >> --
> >> Elena
> >>
> >> ___
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> http://lists.xen.org/xen-devel
> 
> 
> 
> -- 
> Elena
  ___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 66864 
pass in 67023
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
66864 pass in 67023
 test-armhf-armhf-xl-vhd   6 xen-boot   fail in 66864 pass in 67023
 test-amd64-amd64-libvirt-vhd  6 xen-bootfail pass in 66864
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 66864

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail  like 66458
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66458

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

version targeted for testing:
 xen  fd4db045339863c901e887fe35fe958ce766351e
baseline version:
 xen  d0b73c9bf21f9199401a36eeda7ba0a4412aad6d

Last test of basis66458  2015-12-17 09:42:47 Z6 days
Failing since 66520  2015-12-18 10:37:08 Z5 days5 attempts
Testing same since66583  2015-12-19 06:03:35 Z4 days4 attempts


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

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-prev fail
 build-i386-prev  fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops

Re: [Xen-devel] how to enable kdb for xen

[quizyjones]

Besides of that, even when I compile the debuggers.hg version of xen-4.1.0 at 
http://xenbits.xensource.com/ext/debuggers.hg, it will interrupt for:
gcc -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall 
-Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement  -DNDEBUG 
-nostdinc -fno-builtin -fno-common -Wredundant-decls -iwithprefix include 
-Werror -Wno-pointer-arith -pipe -I/home/john/debuggers.hg/xen/include  
-I/home/john/debuggers.hg/xen/include/asm-x86/mach-generic 
-I/home/john/debuggers.hg/xen/include/asm-x86/mach-default -msoft-float 
-fno-stack-protector -fno-exceptions -mno-red-zone -fpic 
-fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -g -D__XEN__ 
-DXEN_KDB_CONFIG -MMD -MF .cpupool.o.d -c cpupool.c -o cpupool.ocpupool.c: In 
function ‘cpupool_add_domain’:cpupool.c:331:9: error: variable ‘n_dom’ set but 
not used [-Werror=unused-but-set-variable] int n_dom; ^cpupool.c: 
In function ‘cpupool_rm_domain’:cpupool.c:356:9: error: variable ‘n_dom’ set 
but not used [-Werror=unused-but-set-variable] int n_dom; 
^cpupool.c:355:9: error: variable ‘cpupool_id’ set but not used 
[-Werror=unused-but-set-variable] int cpupool_id; ^cc1: all 
warnings being treated as errorsmake[4]: *** [cpupool.o] Error 1make[4]: 
Leaving directory `/home/john/debuggers.hg/xen/common'make[3]: *** 
[/home/john/debuggers.hg/xen/common/built_in.o] Error 2make[3]: Leaving 
directory `/home/john/debuggers.hg/xen/arch/x86'make[2]: *** 
[/home/john/debuggers.hg/xen/xen] Error 2make[2]: Leaving directory 
`/home/john/debuggers.hg/xen'make[1]: *** [install] Error 2make[1]: Leaving 
directory `/home/john/debuggers.hg/xen'make: *** [install-xen] Error 2
Actually, the variables are all used in the function, I don't know why this 
happens. After removing -Werror option in Makefile, it still happens.
From: quizy_jo...@outlook.com
To: ufimts...@gmail.com
Date: Thu, 24 Dec 2015 02:36:34 +
CC: elena.ufimts...@oracle.com; xen-devel@lists.xen.org; t...@xen.org
Subject: Re: [Xen-devel] how to enable kdb for xen




Hi, Elena. I tried to patch xen-4.4.1 with the patches at 
http://lists.xen.org/archives/html/xen-devel/2014-04/msg3.html. However, 
after the patching, when I make with kdb=y, it would interrupt for error: 
'struct domain' has no member named 'is_paused_by_controller'. Does the patch 
really work with xen-4.4?

> Date: Fri, 18 Dec 2015 23:58:52 -0500
> Subject: Re: [Xen-devel] how to enable kdb for xen
> From: ufimts...@gmail.com
> To: quizy_jo...@outlook.com
> CC: konrad.w...@oracle.com; elena.ufimts...@oracle.com; t...@xen.org; 
> xen-devel@lists.xen.org
> 
> On Fri, Dec 18, 2015 at 11:24 PM, quizyjones  wrote:
> > Is there any progress?
> 
> Hey
> 
> I did look into this and I could not find the trace of what I have
> done before. So I decided to ytu and port it to current version from
> this Mukesh patch:
> http://lists.xen.org/archives/html/xen-devel/2014-04/msg3.html
> It looks like it applied without major issues, but I have not tested
> it yet, but its in my plan for next week.
> 
> Elena
> 
> >
> >> Date: Wed, 16 Dec 2015 09:42:47 -0500
> >> From: ufimts...@gmail.com
> >> To: konrad.w...@oracle.com
> >> CC: elena.ufimts...@oracle.com; quizy_jo...@outlook.com; t...@xen.org;
> >> xen-devel@lists.xen.org
> >> Subject: Re: [Xen-devel] how to enable kdb for xen
> >
> >>
> >> On Wed, Dec 16, 2015 at 9:30 AM, Konrad Rzeszutek Wilk
> >>  wrote:
> >> > On December 16, 2015 3:08:04 AM EST, quizyjones
> >> >  wrote:
> >> >>The version embedded with kdb only updates to 4.1.0. How can I use it
> >> >>with xen 4.6? Or is there any other debuggers which can step in Xen?
> >> >
> >> > CCing Elena who poked at it some point. Not sure if she got it ported
> >> > over though.
> >> >>
> >> >>From: quizy_jo...@outlook.com
> >> >>To: xen-devel@lists.xen.org
> >> >>Date: Wed, 16 Dec 2015 06:57:02 +
> >> >>Subject: [Xen-devel] how to enable kdb for xen
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>I tried to debug xen use kdb. After compiling xen with debug=y, is
> >> >>there any further steps I should take? I can get console outputs start
> >> >>with: Xen 4.4.1 (XEN) Xen version 4.4.1 (root@) (gcc
> >> >>(Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4) debug=y Wed Dec 16 11:01:14
> >> >>.But I can't step into the boot procedure. The kdb seems not built
> >> >>in and there is no kdb folder in /tools/debugger. How can I build
> >> >>xen-4.4.1/xen-4.4.6 with kdb?
> >>
> >> Hey!
> >> If I recall correctly, I did try to port kdb. Let me find out what
> >> happened there.
> >>
> >> Elena
> >>
> >> >>
> >> >>
> >> >>
> >> >>___
> >> >>Xen-devel mailing list
> >> >>Xen-devel@lists.xen.org
> >> >>http://lists.xen.org/xen-devel
> >> >>
> >> >>
> >> >>
> >> >>___
> >> >>Xen-devel mailing list
> >> >>Xen-devel@lists.x

[Xen-devel] [qemu-upstream-4.2-testing test] 67068: regressions - FAIL

[osstest service owner]

flight 67068 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/67068/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 62044
 build-amd64   5 xen-build fail REGR. vs. 62044

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-i386-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xend-qemuu-winxpsp3  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a

version targeted for testing:
 qemuu5081fc1c773d2a83ec7a867f030323b8b6956cd1
baseline version:
 qemuuc17e602ae64fb24405ebd256679ba9a6f5819086

Last test of basis62044  2015-09-15 15:06:42 Z   99 days
Testing same since66542  2015-12-18 16:37:10 Z5 days6 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  fail
 build-i386   fail
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-i386-xend-qemuu-winxpsp3  blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-i386-i386-xl-qemuu-winxpsp3 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

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

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


Not pushing.


commit 5081fc1c773d2a83ec7a867f030323b8b6956cd1
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:45:14 2015 +

xenfb: avoid reading twice the same fields from the shared page

Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading the type
field multiple times.

This is part of XSA-155.

Signed-off-by: Stefano Stabellini 

commit 74fab2ef4c0ba42af477e9e445c9883cc45cf9e6
Author: Stefano Stabellini 
Date:   Fri Dec 18 15:44:58 2015 +

xen/blkif: Avoid double access to src->nr_segments

src is stored in shared memory and src->nr_segments is dereferenced
twice at the end of the function.  If a compiler decides to compile this
into two separate memory accesses then the size limitation could be
bypassed.

Fix it by removing the double access to src->nr_segments.

This is part of XSA-155.

Signed-off-by: Stefano Stabellini 

[Xen-devel] [linux-3.18 test] 67045: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 63732

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pvh-amd   9 debian-install fail in 66869 pass in 67045
 test-amd64-i386-xl-raw 18 guest-start/debian.repeat fail in 66869 pass in 67045
 test-armhf-armhf-xl-vhd   6 xen-bootfail pass in 66869

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 63732
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 66869 like 63732
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 63676
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 63732
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 63732
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 63732

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

version targeted for testing:
 linux60917545df1ffc7f918550512dc4a14758f74784
baseline version:
 linuxb12403044336e7d567f309eb443aa9acf76380af

Last test of basis63732  2015-11-06 18:01:35 Z   47 days
Testing same since66410  2015-12-16 01:55:28 Z8 days7 attempts


People who touched revisions under test:
  Aaro Koskinen 
  Aaron Conole 
  Alex Deucher 
  Alex Williamson 
  Alexander Couzens 
  Alexander Drozdov 
  Alexander Duyck 
  Alexandre Belloni 
  Andrew Morton 
  Andrey Vagin 
  Ani Sinha 
  Ben Hutchings 
  Ben Skeggs 
  Benjamin Tissoires 
  Bin Liu 
  Bjorn Helgaas 
  Bjørn Mork 
  Carol L Soto 
  Cathy Avery 
  Charles Keepax 
  Chris Mason 
  Cong Wang 
  Dan Carpenter 
  Daniel Borkmann 
  Dann Frazier 
  Dave Kleikamp 
  David Howells 
  David S. Miller 
  Dmitry Torokhov 
  Dmitry Vyukov 
  Doron Tsur 
  Doug Ledford 
  Dāvis Mosāns 
  Emmanuel Grumbach 
  Eric Dumazet 
  Eric Northup 
  Eric Whitney 
  Eryu Guan 
  Felipe Balbi 
  Felix Fietkau 
  Florian Fainelli 
  Francesco Ruggeri 
  Francesco Ruggeri 
  G. Richard Bellamy 
  George Hilios 
  Greg Kroah-Hartman 
  Gregory CLEMENT 
  Guillaume Naul