[Xen-devel] [xen-4.5-testing test] 94518: regressions - FAIL
flight 94518 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94518/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 93989 build-amd64-libvirt 5 libvirt-build fail REGR. vs. 93989 build-armhf-libvirt 5 libvirt-build fail REGR. vs. 93989 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 93989 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 93989 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 11 guest-start fail like 93928 test-amd64-amd64-xl-rtds 6 xen-boot fail like 93989 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 93989 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93989 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 93989 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-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-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-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 10 guest-start 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-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass version targeted for testing: xen 62e890246736d48030640198d3fd9d71fe392de3 baseline version: xen 2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3 Last test of basis93989 2016-05-10 14:43:18 Z7 days Failing since 94030 2016-05-11 13:08:55 Z6 days 11 attempts Testing same since94518 2016-05-17 13:41:54 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Julien Grall Kyle J. Temkin Kyle Temkin Shanker Donthineni Stefano Stabellini Vikram Sethi jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail 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 test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd
[Xen-devel] [PATCH net-next] xen-netback: correct length checks on hash copy_ops
The length checks on the grant table copy_ops for setting hash key and
hash mapping are checking the local 'len' value which is correct in
the case of the former but not the latter. This was picked up by
static analysis checks.
This patch replaces checks of 'len' with 'copy_op.len' in both cases
to correct the incorrect check, keep the two checks consistent, and to
make it clear what the checks are for.
Signed-off-by: Paul Durrant
Reported-by: Dan Carpenter
Cc: Wei Liu
---
drivers/net/xen-netback/hash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-netback/hash.c
index 392e392..fb87cb3 100644
--- a/drivers/net/xen-netback/hash.c
+++ b/drivers/net/xen-netback/hash.c
@@ -311,7 +311,7 @@ u32 xenvif_set_hash_key(struct xenvif *vif, u32 gref, u32
len)
if (len > XEN_NETBK_MAX_HASH_KEY_SIZE)
return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
- if (len != 0) {
+ if (copy_op.len != 0) {
gnttab_batch_copy(©_op, 1);
if (copy_op.status != GNTST_okay)
@@ -359,7 +359,7 @@ u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref,
u32 len,
if (mapping[off++] >= vif->num_queues)
return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
- if (len != 0) {
+ if (copy_op.len != 0) {
gnttab_batch_copy(©_op, 1);
if (copy_op.status != GNTST_okay)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 08/10] vt-d/ept: propagate IOMMU Device-TLB flush error up to EPT update.
Propagate the IOMMU Device-TLB flush error up to the ept_set_entry(),
when VT-d shares EPT page table.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
CC: Feng Wu
---
xen/arch/x86/mm/p2m-ept.c | 2 +-
xen/include/asm-x86/iommu.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 7d4809f..2b02f02 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -832,7 +832,7 @@ 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 )
diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 43f1620..3d2c354 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -27,7 +27,8 @@ int iommu_setup_hpet_msi(struct msi_desc *);
/* While VT-d specific, this must get declared in a generic header. */
int adjust_vtd_irq_affinities(void);
-int iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte, int order, bool_t
present);
+int __must_check iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
+ int order, bool_t present);
bool_t iommu_supports_eim(void);
int iommu_enable_x2apic_IR(void);
void iommu_disable_x2apic_IR(void);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping
Propagate the IOMMU Device-TLB flush error up to ME phantom function
mapping and unmapping.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/vtd/extern.h | 3 ++-
xen/drivers/passthrough/vtd/iommu.c | 8
xen/drivers/passthrough/vtd/quirks.c | 28 ++--
3 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/extern.h
b/xen/drivers/passthrough/vtd/extern.h
index cbe0286..6772839 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -91,7 +91,8 @@ int is_igd_vt_enabled_quirk(void);
void platform_quirks_init(void);
void vtd_ops_preamble_quirk(struct iommu* iommu);
void vtd_ops_postamble_quirk(struct iommu* iommu);
-void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map);
+int __must_check me_wifi_quirk(struct domain *domain,
+ u8 bus, u8 devfn, int map);
void pci_vtd_quirk(const struct pci_dev *);
bool_t platform_supports_intremap(void);
bool_t platform_supports_x2apic(void);
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 3d07139..9175ddf 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1441,8 +1441,8 @@ int domain_context_mapping_one(
unmap_vtd_domain_page(context_entries);
-if ( !seg )
-me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
+if ( !seg && !rc )
+rc = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
return rc;
}
@@ -1594,8 +1594,8 @@ int domain_context_unmap_one(
spin_unlock(&iommu->lock);
unmap_vtd_domain_page(context_entries);
-if ( !iommu->intel->drhd->segment )
-me_wifi_quirk(domain, bus, devfn, UNMAP_ME_PHANTOM_FUNC);
+if ( !iommu->intel->drhd->segment && !rc )
+rc = me_wifi_quirk(domain, bus, devfn, UNMAP_ME_PHANTOM_FUNC);
return rc;
}
diff --git a/xen/drivers/passthrough/vtd/quirks.c
b/xen/drivers/passthrough/vtd/quirks.c
index 473d1fc..3606b52 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -331,10 +331,12 @@ void __init platform_quirks_init(void)
* assigning Intel integrated wifi device to a guest.
*/
-static void map_me_phantom_function(struct domain *domain, u32 dev, int map)
+static int __must_check map_me_phantom_function(struct domain *domain,
+u32 dev, int map)
{
struct acpi_drhd_unit *drhd;
struct pci_dev *pdev;
+int rc;
/* find ME VT-d engine base on a real ME device */
pdev = pci_get_pdev(0, 0, PCI_DEVFN(dev, 0));
@@ -342,23 +344,27 @@ static void map_me_phantom_function(struct domain
*domain, u32 dev, int map)
/* map or unmap ME phantom function */
if ( map )
-domain_context_mapping_one(domain, drhd->iommu, 0,
- PCI_DEVFN(dev, 7), NULL);
+rc = domain_context_mapping_one(domain, drhd->iommu, 0,
+PCI_DEVFN(dev, 7), NULL);
else
-domain_context_unmap_one(domain, drhd->iommu, 0,
- PCI_DEVFN(dev, 7));
+rc = domain_context_unmap_one(domain, drhd->iommu, 0,
+ PCI_DEVFN(dev, 7));
+
+return rc;
}
-void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map)
+int me_wifi_quirk(struct domain *domain,
+ u8 bus, u8 devfn, int map)
{
u32 id;
+int rc = 0;
id = pci_conf_read32(0, 0, 0, 0, 0);
if ( IS_CTG(id) )
{
/* quit if ME does not exist */
if ( pci_conf_read32(0, 0, 3, 0, 0) == 0x )
-return;
+return 0;
/* if device is WLAN device, map ME phantom device 0:3.7 */
id = pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);
@@ -372,7 +378,7 @@ void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn,
int map)
case 0x423b8086:
case 0x423c8086:
case 0x423d8086:
-map_me_phantom_function(domain, 3, map);
+rc = map_me_phantom_function(domain, 3, map);
break;
default:
break;
@@ -382,7 +388,7 @@ void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn,
int map)
{
/* quit if ME does not exist */
if ( pci_conf_read32(0, 0, 22, 0, 0) == 0x )
-return;
+return 0;
/* if device is WLAN device, map ME phantom device 0:22.7 */
id = pci_conf_read32(0, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 0);
@@ -398,12 +404,14 @@ void me_wifi_quirk(struct domain *domain, u8 bus, u8
devfn, int map)
case 0x42388086:/* Puma Peak */
case 0x422b8086:
case 0x422c8086:
-map_me_phantom_function(domain, 22, map);
+
[Xen-devel] [PATCH v5 00/10] Check VT-d Device-TLB flush error
This patch set is a prereq patch set for Patch:'VT-d Device-TLB flush issue'.
While IOMMU Device-TLB flush timed out, xen calls panic() at present. However
the existing panic()
is going to be eliminated, so we must propagate the IOMMU Device-TLB flush
error up to the call trees.
This patch set is also based on the discussion of 'abstract model of IOMMU
unmaping/mapping failures'
--Changes in v5:
patch 1:
* add the missing blank line.
* add comments.
* if iommu_flush_context_device failed, continue to flush IOMMU IOTLB on a
best effort basis.
* __defer__ to:
- rename __intel_iommu_iotlb_flush to iommu_flush_iotlb
- rename intel_iommu_iotlb_flush to iommu_flush_iotlb_pages
- rename intel_iommu_iotlb_flush_all to iommu_flush_iotlb_all
- add __must_check annotation
in patch 7 / 8,
otherwise, this will disrupt the order due to __must_check annotation.
patch 2:
* enhance the logging.
* state why no spamming can occur in commit message.
patch 3:
* keep the "rc == 0" untouched.
* add __must_check annotation.
* restricting the scope of "ret" to the innermost block.
* in ept_set_entry(), in the case of iommu_map_page(), just use rc directly
and not
bother using ret at all.
patch 4:
* add __must_check annotation.
patch 5:
* add __must_check annotation.
patch 6:
* switch the two sides of the && for "if ( rc >= 0 && unlikely(ret) )".
* remove redundant __must_check.
patch 7:
* rename __intel_iommu_iotlb_flush to iommu_flush_iotlb.
* rename intel_iommu_iotlb_flush to iommu_flush_iotlb_pages.
* rename intel_iommu_iotlb_flush_all to iommu_flush_iotlb_all.
* add __must_check annotation.
patch 8:
* change ret to rc.
patch 9:
* change 'enum dev_power_type' to 'enum dev_power_saved'.
* change 'TYPE_*' to 'SAVED_*'
* drop '*_UNKNOWN' in enum.
* change 'should' to 'cannot' for comment.
* reorder in device_power_up().
* enhance logging message.
patch 10:
* if an earlier error occurred ( rc != 0 ), no use in calling me_wifi_quirk().
Quan Xu (10):
vt-d: fix the IOMMU flush issue
IOMMU: handle IOMMU mapping and unmapping failures
IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU unmapping.
IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping.
IOMMU/MMU: propagate IOMMU Device-TLB flush error up to
iommu_iotlb_flush{,_all} (top level ones).
IOMMU: propagate IOMMU Device-TLB flush error up to
iommu_iotlb_flush{,_all} (leaf ones).
vt-d/ept: propagate IOMMU Device-TLB flush error up to EPT update.
IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending
vt-d: propagate error up to ME phantom function mapping and unmapping
xen/arch/arm/p2m.c| 5 +-
xen/arch/x86/acpi/power.c | 72 +++---
xen/arch/x86/mm.c | 18 ++-
xen/arch/x86/mm/p2m-ept.c | 39 +++--
xen/arch/x86/mm/p2m-pt.c | 28 +++-
xen/arch/x86/mm/p2m.c | 34 -
xen/common/memory.c | 20 ++-
xen/drivers/passthrough/amd/iommu_init.c | 9 +-
xen/drivers/passthrough/amd/pci_amd_iommu.c | 19 ++-
xen/drivers/passthrough/arm/smmu.c| 19 +--
xen/drivers/passthrough/iommu.c | 66 +++--
xen/drivers/passthrough/vtd/extern.h | 3 +-
xen/drivers/passthrough/vtd/iommu.c | 199 ++
xen/drivers/passthrough/vtd/quirks.c | 28 ++--
xen/drivers/passthrough/x86/iommu.c | 5 +-
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 4 +-
xen/include/asm-x86/iommu.h | 3 +-
xen/include/asm-x86/p2m.h | 12 +-
xen/include/xen/iommu.h | 22 +--
19 files changed, 441 insertions(+), 164 deletions(-)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 01/10] vt-d: fix the IOMMU flush issue
The propagation value from IOMMU flush interfaces may be positive, which
indicates callers need to flush cache, not one of faliures.
when the propagation value is positive, this patch fixes this flush issue
as follows:
- call iommu_flush_write_buffer() to flush cache.
- return zero.
Signed-off-by: Quan Xu
CC: Kevin Tian
CC: Feng Wu
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
---
xen/drivers/passthrough/vtd/iommu.c | 101 ++--
xen/include/asm-x86/iommu.h | 2 +-
2 files changed, 75 insertions(+), 28 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index db83949..3ece815 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -557,14 +557,16 @@ static void iommu_flush_all(void)
}
}
-static void __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
-int dma_old_pte_present, unsigned int page_count)
+static int __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
+ bool_t dma_old_pte_present,
+ unsigned int page_count)
{
struct domain_iommu *hd = dom_iommu(d);
struct acpi_drhd_unit *drhd;
struct iommu *iommu;
int flush_dev_iotlb;
int iommu_domid;
+int rc = 0;
/*
* No need pcideves_lock here because we have flush
@@ -579,23 +581,28 @@ static void __intel_iommu_iotlb_flush(struct domain *d,
unsigned long gfn,
flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
iommu_domid= domain_iommu_domid(d, iommu);
+
if ( iommu_domid == -1 )
continue;
if ( page_count != 1 || gfn == INVALID_GFN )
-{
-if ( iommu_flush_iotlb_dsi(iommu, iommu_domid,
-0, flush_dev_iotlb) )
-iommu_flush_write_buffer(iommu);
-}
+rc = iommu_flush_iotlb_dsi(iommu, iommu_domid,
+ 0, flush_dev_iotlb);
else
+rc = iommu_flush_iotlb_psi(iommu, iommu_domid,
+ (paddr_t)gfn << PAGE_SHIFT_4K,
+ PAGE_ORDER_4K,
+ !dma_old_pte_present,
+ flush_dev_iotlb);
+
+if ( rc > 0 )
{
-if ( iommu_flush_iotlb_psi(iommu, iommu_domid,
-(paddr_t)gfn << PAGE_SHIFT_4K, PAGE_ORDER_4K,
-!dma_old_pte_present, flush_dev_iotlb) )
-iommu_flush_write_buffer(iommu);
+iommu_flush_write_buffer(iommu);
+rc = 0;
}
}
+
+return rc;
}
static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
unsigned int page_count)
@@ -1278,6 +1285,7 @@ int domain_context_mapping_one(
u64 maddr, pgd_maddr;
u16 seg = iommu->intel->drhd->segment;
int agaw;
+int rc;
ASSERT(pcidevs_locked());
spin_lock(&iommu->lock);
@@ -1391,13 +1399,26 @@ int domain_context_mapping_one(
spin_unlock(&iommu->lock);
/* Context entry was previously non-present (with domid 0). */
-if ( iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
-DMA_CCMD_MASK_NOBIT, 1) )
-iommu_flush_write_buffer(iommu);
-else
+rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
+DMA_CCMD_MASK_NOBIT, 1);
+
+/*
+ * The current logic for rc returns:
+ * - positive invoke iommu_flush_write_buffer to flush cache.
+ * - zero success.
+ * - negative failure. Continue to flush IOMMU IOTLB on a best
+ * effort basis.
+ */
+if ( rc <= 0 )
{
int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
-iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
+
+rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
+}
+else
+{
+iommu_flush_write_buffer(iommu);
+rc = 0;
}
set_bit(iommu->index, &hd->arch.iommu_bitmap);
@@ -1407,7 +1428,7 @@ int domain_context_mapping_one(
if ( !seg )
me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
-return 0;
+return rc;
}
static int domain_context_mapping(
@@ -1502,6 +1523,7 @@ int domain_context_unmap_one(
struct context_entry *context, *context_entries;
u64 maddr;
int iommu_domid;
+int rc;
ASSERT(pcidevs_locked());
spin_lock(&iommu->lock);
@@ -1522,6 +1544,7 @@ int domain_context_unmap_one(
iommu_flush_cache_entry(context, sizeof(struct context_entry));
iommu_domid= domain_iommu_domid(domain, iommu);
+
if ( iommu_domid == -1 )
{
spin_unlock(&iommu->lock);
@@ -1529,14 +1552,27 @@ int domain_context_unmap_one(
return -EINVAL;
}
-if ( iommu_flush_conte
[Xen-devel] [PATCH v5 06/10] IOMMU/MMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (top level ones).
Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
This patch fixes the top level ones (this patch doesn't fix the leaf ones but
the next patch does).
Signed-off-by: Quan Xu
Reviewed-by: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
CC: Kevin Tian
---
xen/arch/arm/p2m.c | 5 -
xen/common/memory.c | 20 +++-
xen/drivers/passthrough/iommu.c | 13 +
xen/drivers/passthrough/x86/iommu.c | 5 +++--
xen/include/xen/iommu.h | 7 ---
5 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index db21433..fe201d0 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1178,7 +1178,10 @@ out:
if ( flush )
{
flush_tlb_domain(d);
-iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+ret = iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+
+if ( !rc )
+rc = ret;
}
while ( (pg = page_list_remove_head(&free_pages)) )
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 644f81a..754c33c 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -633,9 +633,9 @@ static long
memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
return rc;
}
-static int xenmem_add_to_physmap(struct domain *d,
- struct xen_add_to_physmap *xatp,
- unsigned int start)
+static int __must_check xenmem_add_to_physmap(struct domain *d,
+ struct xen_add_to_physmap *xatp,
+ unsigned int start)
{
unsigned int done = 0;
long rc = 0;
@@ -677,9 +677,19 @@ static int xenmem_add_to_physmap(struct domain *d,
#ifdef CONFIG_HAS_PASSTHROUGH
if ( need_iommu(d) )
{
+int ret;
+
this_cpu(iommu_dont_flush_iotlb) = 0;
-iommu_iotlb_flush(d, xatp->idx - done, done);
-iommu_iotlb_flush(d, xatp->gpfn - done, done);
+
+ret = iommu_iotlb_flush(d, xatp->idx - done, done);
+
+if ( unlikely(ret) && rc >= 0 )
+rc = ret;
+
+ret = iommu_iotlb_flush(d, xatp->gpfn - done, done);
+
+if ( unlikely(ret) && rc >= 0 )
+rc = ret;
}
#endif
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index e04db16..54d307b 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -315,24 +315,29 @@ static void iommu_free_pagetables(unsigned long unused)
cpumask_cycle(smp_processor_id(),
&cpu_online_map));
}
-void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int
page_count)
+int iommu_iotlb_flush(struct domain *d, unsigned long gfn,
+ unsigned int page_count)
{
const struct domain_iommu *hd = dom_iommu(d);
if ( !iommu_enabled || !hd->platform_ops || !hd->platform_ops->iotlb_flush
)
-return;
+return 0;
hd->platform_ops->iotlb_flush(d, gfn, page_count);
+
+return 0;
}
-void iommu_iotlb_flush_all(struct domain *d)
+int iommu_iotlb_flush_all(struct domain *d)
{
const struct domain_iommu *hd = dom_iommu(d);
if ( !iommu_enabled || !hd->platform_ops ||
!hd->platform_ops->iotlb_flush_all )
-return;
+return 0;
hd->platform_ops->iotlb_flush_all(d);
+
+return 0;
}
int __init iommu_setup(void)
diff --git a/xen/drivers/passthrough/x86/iommu.c
b/xen/drivers/passthrough/x86/iommu.c
index b64b98f..a18a608 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -104,8 +104,9 @@ int arch_iommu_populate_page_table(struct domain *d)
this_cpu(iommu_dont_flush_iotlb) = 0;
if ( !rc )
-iommu_iotlb_flush_all(d);
-else if ( rc != -ERESTART )
+rc = iommu_iotlb_flush_all(d);
+
+if ( rc && rc != -ERESTART )
iommu_teardown(d);
return rc;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 14041a1..27e2d3e 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -61,7 +61,7 @@ int deassign_device(struct domain *d, u16 seg, u8 bus, u8
devfn);
void arch_iommu_domain_destroy(struct domain *d);
int arch_iommu_domain_init(struct domain *d);
-int arch_iommu_populate_page_table(struct domain *d);
+int __must_check arch_iommu_populate_page_table(struct domain *d);
void arch_iommu_check_autotranslated_hwdom(struct domain *d);
int iommu_construct(struct domain *d);
@@ -200,8 +200,9 @@ int iommu_do_pci_domctl(struct xen_domctl *, struct domain
*d,
int iommu_do_domctl(struct xen_domctl *, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t));
-void iommu_iotlb_flush(struct domain *d, unsigned long gfn, unsigned int
page_count);
-void iommu_iotlb_flush_all(struct domain *d);
+int __must_check iommu_iotlb_flush(struct domain *d,
[Xen-devel] [PATCH v5 09/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending
Propagate the IOMMU Device-TLB flush error up to IOMMU suspending.
Signed-off-by: Quan Xu
CC: Jan Beulich
CC: Liu Jinsong
CC: Keir Fraser
CC: Andrew Cooper
CC: Suravee Suthikulpanit
CC: Stefano Stabellini
CC: Julien Grall
CC: Kevin Tian
CC: Feng Wu
---
xen/arch/x86/acpi/power.c | 72 ---
xen/drivers/passthrough/amd/iommu_init.c | 9 +++-
xen/drivers/passthrough/amd/pci_amd_iommu.c | 2 +-
xen/drivers/passthrough/iommu.c | 6 ++-
xen/drivers/passthrough/vtd/iommu.c | 45 +
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +-
xen/include/xen/iommu.h | 4 +-
7 files changed, 105 insertions(+), 35 deletions(-)
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index 2885e31..8e60c75 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -43,36 +43,68 @@ struct acpi_sleep_info acpi_sinfo;
void do_suspend_lowlevel(void);
+enum dev_power_saved
+{
+SAVED_NONE,/* None of device power saved */
+SAVED_CONSOLE, /* Device power of console saved */
+SAVED_TIME,/* Device power of time saved */
+SAVED_I8259A, /* Device power of I8259A saved */
+SAVED_IOAPIC, /* Device power of IOAPIC saved */
+SAVED_IOMMU, /* Device power of IOMMU saved */
+SAVED_LAPIC, /* Device power of LAPIC saved */
+};
+
static int device_power_down(void)
{
-console_suspend();
+if ( console_suspend() )
+return SAVED_CONSOLE;
-time_suspend();
+if ( time_suspend() )
+return SAVED_TIME;
-i8259A_suspend();
+if ( i8259A_suspend() )
+return SAVED_I8259A;
+/* ioapic_suspend cannot fail */
ioapic_suspend();
-iommu_suspend();
+if ( iommu_suspend() )
+return SAVED_IOMMU;
-lapic_suspend();
+if ( lapic_suspend() )
+return SAVED_LAPIC;
return 0;
}
-static void device_power_up(void)
+static void device_power_up(enum dev_power_saved saved)
{
-lapic_resume();
-
-iommu_resume();
-
-ioapic_resume();
-
-i8259A_resume();
-
-time_resume();
-
-console_resume();
+switch ( saved )
+{
+case SAVED_NONE:
+lapic_resume();
+/* fall through */
+case SAVED_LAPIC:
+iommu_resume();
+/* fall through */
+case SAVED_IOMMU:
+ioapic_resume();
+/* fall through */
+case SAVED_IOAPIC:
+i8259A_resume();
+/* fall through */
+case SAVED_I8259A:
+time_resume();
+/* fall through */
+case SAVED_TIME:
+console_resume();
+/* fall through */
+case SAVED_CONSOLE:
+break;
+default:
+BUG();
+break;
+}
}
static void freeze_domains(void)
@@ -169,6 +201,10 @@ static int enter_state(u32 state)
{
printk(XENLOG_ERR "Some devices failed to power down.");
system_state = SYS_STATE_resume;
+
+if ( error > 0 )
+device_power_up(error);
+
goto done;
}
@@ -196,7 +232,7 @@ static int enter_state(u32 state)
write_cr4(cr4 & ~X86_CR4_MCE);
write_efer(read_efer());
-device_power_up();
+device_power_up(SAVED_NONE);
mcheck_init(&boot_cpu_data, 0);
write_cr4(cr4);
diff --git a/xen/drivers/passthrough/amd/iommu_init.c
b/xen/drivers/passthrough/amd/iommu_init.c
index 4536106..0b68596 100644
--- a/xen/drivers/passthrough/amd/iommu_init.c
+++ b/xen/drivers/passthrough/amd/iommu_init.c
@@ -1339,7 +1339,14 @@ static void invalidate_all_devices(void)
iterate_ivrs_mappings(_invalidate_all_devices);
}
-void amd_iommu_suspend(void)
+int amd_iommu_suspend(void)
+{
+amd_iommu_crash_shutdown();
+
+return 0;
+}
+
+void amd_iommu_crash_shutdown(void)
{
struct amd_iommu *iommu;
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 86d6fb3..f162703 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -639,6 +639,6 @@ const struct iommu_ops amd_iommu_ops = {
.suspend = amd_iommu_suspend,
.resume = amd_iommu_resume,
.share_p2m = amd_iommu_share_p2m,
-.crash_shutdown = amd_iommu_suspend,
+.crash_shutdown = amd_iommu_crash_shutdown,
.dump_p2m_table = amd_dump_p2m_table,
};
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 92d37c5..b610a1f 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -379,10 +379,12 @@ int __init iommu_setup(void)
return rc;
}
-void iommu_suspend()
+int iommu_suspend()
{
if ( iommu_enabled )
-iommu_get_ops()->suspend();
+return iommu_get_ops()->suspend();
+
+return 0;
}
void iommu_resume()
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index a6caf97..3d07139 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xe
[Xen-devel] [PATCH v5 05/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU mapping.
Propagate the IOMMU Device-TLB flush error up to IOMMU mapping.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Suravee Suthikulpanit
CC: Stefano Stabellini
CC: Julien Grall
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
---
xen/drivers/passthrough/amd/pci_amd_iommu.c | 17 +++--
xen/drivers/passthrough/arm/smmu.c | 4 ++--
xen/drivers/passthrough/vtd/iommu.c | 12 +++-
xen/include/xen/iommu.h | 4 ++--
4 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 70b7475..86d6fb3 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -285,6 +285,8 @@ static void __hwdom_init amd_iommu_hwdom_init(struct domain
*d)
if ( !iommu_passthrough && !need_iommu(d) )
{
+int rc = 0;
+
/* Set up 1:1 page table for dom0 */
for ( i = 0; i < max_pdx; i++ )
{
@@ -295,12 +297,23 @@ static void __hwdom_init amd_iommu_hwdom_init(struct
domain *d)
* a pfn_valid() check would seem desirable here.
*/
if ( mfn_valid(pfn) )
-amd_iommu_map_page(d, pfn, pfn,
- IOMMUF_readable|IOMMUF_writable);
+{
+int ret;
+
+ret = amd_iommu_map_page(d, pfn, pfn,
+ IOMMUF_readable|IOMMUF_writable);
+
+if ( unlikely(ret) )
+rc = ret;
+}
if ( !(i & 0xf) )
process_pending_softirqs();
}
+
+if ( rc )
+AMD_IOMMU_DEBUG("d%d: IOMMU mapping failed %d.",
+d->domain_id, rc);
}
for_each_amd_iommu ( iommu )
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 1ce4ddf..ee5c89d 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2745,8 +2745,8 @@ static void arm_smmu_iommu_domain_teardown(struct domain
*d)
xfree(xen_domain);
}
-static int arm_smmu_map_page(struct domain *d, unsigned long gfn,
-unsigned long mfn, unsigned int flags)
+static int __must_check arm_smmu_map_page(struct domain *d, unsigned long gfn,
+ unsigned long mfn, unsigned int
flags)
{
p2m_type_t t;
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 29fb7fd..461688c 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1724,13 +1724,15 @@ static void iommu_domain_teardown(struct domain *d)
spin_unlock(&hd->arch.mapping_lock);
}
-static int intel_iommu_map_page(
-struct domain *d, unsigned long gfn, unsigned long mfn,
-unsigned int flags)
+static int __must_check intel_iommu_map_page(struct domain *d,
+ unsigned long gfn,
+ unsigned long mfn,
+ unsigned int flags)
{
struct domain_iommu *hd = dom_iommu(d);
struct dma_pte *page = NULL, *pte = NULL, old, new = { 0 };
u64 pg_maddr;
+int rc = 0;
/* Do nothing if VT-d shares EPT page table */
if ( iommu_use_hap_pt(d) )
@@ -1773,9 +1775,9 @@ static int intel_iommu_map_page(
unmap_vtd_domain_page(page);
if ( !this_cpu(iommu_dont_flush_iotlb) )
-__intel_iommu_iotlb_flush(d, gfn, dma_pte_present(old), 1);
+rc = __intel_iommu_iotlb_flush(d, gfn, dma_pte_present(old), 1);
-return 0;
+return rc;
}
static int __must_check intel_iommu_unmap_page(struct domain *d,
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 73a7f1e..14041a1 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -166,8 +166,8 @@ struct iommu_ops {
#endif /* HAS_PCI */
void (*teardown)(struct domain *d);
-int (*map_page)(struct domain *d, unsigned long gfn, unsigned long mfn,
-unsigned int flags);
+int __must_check (*map_page)(struct domain *d, unsigned long gfn,
+ unsigned long mfn, unsigned int flags);
int __must_check (*unmap_page)(struct domain *d, unsigned long gfn);
void (*free_page_table)(struct page_info *);
#ifdef CONFIG_X86
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 04/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU unmapping.
Propagate the IOMMU Device-TLB flush error up to IOMMU unmapping.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
Reviewed-by: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
CC: Kevin Tian
CC: Feng Wu
CC: Jan Beulich
CC: Andrew Cooper
---
xen/drivers/passthrough/arm/smmu.c| 2 +-
xen/drivers/passthrough/vtd/iommu.c | 18 ++
xen/include/asm-x86/hvm/svm/amd-iommu-proto.h | 2 +-
xen/include/xen/iommu.h | 2 +-
4 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 54a03a6..1ce4ddf 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2774,7 +2774,7 @@ static int arm_smmu_map_page(struct domain *d, unsigned
long gfn,
return guest_physmap_add_entry(d, gfn, mfn, 0, t);
}
-static int arm_smmu_unmap_page(struct domain *d, unsigned long gfn)
+static int __must_check arm_smmu_unmap_page(struct domain *d, unsigned long
gfn)
{
/*
* This function should only be used by gnttab code when the domain
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 3ece815..29fb7fd 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -616,11 +616,12 @@ static void intel_iommu_iotlb_flush_all(struct domain *d)
}
/* clear one page's page table */
-static void dma_pte_clear_one(struct domain *domain, u64 addr)
+static int __must_check dma_pte_clear_one(struct domain *domain, u64 addr)
{
struct domain_iommu *hd = dom_iommu(domain);
struct dma_pte *page = NULL, *pte = NULL;
u64 pg_maddr;
+int rc = 0;
spin_lock(&hd->arch.mapping_lock);
/* get last level pte */
@@ -628,7 +629,7 @@ static void dma_pte_clear_one(struct domain *domain, u64
addr)
if ( pg_maddr == 0 )
{
spin_unlock(&hd->arch.mapping_lock);
-return;
+return 0;
}
page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
@@ -638,7 +639,7 @@ static void dma_pte_clear_one(struct domain *domain, u64
addr)
{
spin_unlock(&hd->arch.mapping_lock);
unmap_vtd_domain_page(page);
-return;
+return 0;
}
dma_clear_pte(*pte);
@@ -646,9 +647,11 @@ static void dma_pte_clear_one(struct domain *domain, u64
addr)
iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
if ( !this_cpu(iommu_dont_flush_iotlb) )
-__intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1);
+rc = __intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1);
unmap_vtd_domain_page(page);
+
+return rc;
}
static void iommu_free_pagetable(u64 pt_maddr, int level)
@@ -1775,15 +1778,14 @@ static int intel_iommu_map_page(
return 0;
}
-static int intel_iommu_unmap_page(struct domain *d, unsigned long gfn)
+static int __must_check intel_iommu_unmap_page(struct domain *d,
+ unsigned long gfn)
{
/* Do nothing if hardware domain and iommu supports pass thru. */
if ( iommu_passthrough && is_hardware_domain(d) )
return 0;
-dma_pte_clear_one(d, (paddr_t)gfn << PAGE_SHIFT_4K);
-
-return 0;
+return dma_pte_clear_one(d, (paddr_t)gfn << PAGE_SHIFT_4K);
}
int iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
diff --git a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
index 9c51172..57b6cc1 100644
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -53,7 +53,7 @@ int amd_iommu_update_ivrs_mapping_acpi(void);
/* mapping functions */
int amd_iommu_map_page(struct domain *d, unsigned long gfn, unsigned long mfn,
unsigned int flags);
-int amd_iommu_unmap_page(struct domain *d, unsigned long gfn);
+int __must_check amd_iommu_unmap_page(struct domain *d, unsigned long gfn);
u64 amd_iommu_get_next_table_from_pte(u32 *entry);
int amd_iommu_reserve_domain_unity_map(struct domain *domain,
u64 phys_addr, unsigned long size,
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 19ba976..73a7f1e 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -168,7 +168,7 @@ struct iommu_ops {
void (*teardown)(struct domain *d);
int (*map_page)(struct domain *d, unsigned long gfn, unsigned long mfn,
unsigned int flags);
-int (*unmap_page)(struct domain *d, unsigned long gfn);
+int __must_check (*unmap_page)(struct domain *d, unsigned long gfn);
void (*free_page_table)(struct page_info *);
#ifdef CONFIG_X86
void (*update_ire_from_apic)(unsigned int apic, unsigned int reg, unsigned
int value);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 02/10] IOMMU: handle IOMMU mapping and unmapping failures
Treat IOMMU mapping and unmapping failures as a fatal to the DomU
If IOMMU mapping and unmapping failed, crash the DomU and propagate
the error up to the call trees.
No spamming can occur. For DomU, we avoid logging any message
for already dying domains. For Dom0, that'll still be more verbose
than we'd really like, but it at least wouldn't outright flood the
console.
Signed-off-by: Quan Xu
Reviewed-by: Kevin Tian
CC: Jan Beulich
CC: Kevin Tian
---
xen/drivers/passthrough/iommu.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 9d104d2..7c70306 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -240,21 +240,49 @@ int iommu_map_page(struct domain *d, unsigned long gfn,
unsigned long mfn,
unsigned int flags)
{
const struct domain_iommu *hd = dom_iommu(d);
+int rc;
if ( !iommu_enabled || !hd->platform_ops )
return 0;
-return hd->platform_ops->map_page(d, gfn, mfn, flags);
+rc = hd->platform_ops->map_page(d, gfn, mfn, flags);
+
+if ( unlikely(rc) )
+{
+if ( !d->is_shutting_down && printk_ratelimit() )
+printk(XENLOG_ERR
+ "d%d: IOMMU mapping gfn %#lx mfn %#lx failed %d.",
+ d->domain_id, gfn, mfn, rc);
+
+if ( !is_hardware_domain(d) )
+domain_crash(d);
+}
+
+return rc;
}
int iommu_unmap_page(struct domain *d, unsigned long gfn)
{
const struct domain_iommu *hd = dom_iommu(d);
+int rc;
if ( !iommu_enabled || !hd->platform_ops )
return 0;
-return hd->platform_ops->unmap_page(d, gfn);
+rc = hd->platform_ops->unmap_page(d, gfn);
+
+if ( unlikely(rc) )
+{
+if ( !d->is_shutting_down && printk_ratelimit() )
+printk(XENLOG_ERR
+ "d%d: IOMMU unmapping gfn %#lx failed %d.",
+ d->domain_id, gfn, rc);
+
+if ( !is_hardware_domain(d) )
+domain_crash(d);
+}
+
+return rc;
}
static void iommu_free_pagetables(unsigned long unused)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping
When IOMMU mapping is failed, we issue a best effort rollback, stopping
IOMMU mapping, unmapping the previous IOMMU maps and then reporting the
error up to the call trees. When rollback is not feasible (in early
initialization phase or trade-off of complexity) for the hardware domain,
we do things on a best effort basis, only throwing out an error message.
IOMMU unmapping should perhaps continue despite an error, in an attempt
to do best effort cleanup.
Signed-off-by: Quan Xu
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
---
xen/arch/x86/mm.c | 18 +++---
xen/arch/x86/mm/p2m-ept.c | 37 +
xen/arch/x86/mm/p2m-pt.c| 28
xen/arch/x86/mm/p2m.c | 34 --
xen/drivers/passthrough/iommu.c | 15 ++-
xen/include/asm-x86/p2m.h | 12 +++-
6 files changed, 113 insertions(+), 31 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 03a4d5b..fee3b9d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2463,11 +2463,12 @@ static int __put_page_type(struct page_info *page,
}
-static int __get_page_type(struct page_info *page, unsigned long type,
- int preemptible)
+static int __must_check __get_page_type(struct page_info *page,
+unsigned long type,
+int preemptible)
{
unsigned long nx, x, y = page->u.inuse.type_info;
-int rc = 0;
+int rc = 0, ret = 0;
ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
@@ -2578,11 +2579,11 @@ static int __get_page_type(struct page_info *page,
unsigned long type,
if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
{
if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
+ret = iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
else if ( type == PGT_writable_page )
-iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
- page_to_mfn(page),
- IOMMUF_readable|IOMMUF_writable);
+ret = iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
+ page_to_mfn(page),
+ IOMMUF_readable|IOMMUF_writable);
}
}
@@ -2599,6 +2600,9 @@ static int __get_page_type(struct page_info *page,
unsigned long type,
if ( (x & PGT_partial) && !(nx & PGT_partial) )
put_page(page);
+if ( !rc )
+rc = ret;
+
return rc;
}
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 1ed5b47..7d4809f 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -658,7 +658,7 @@ bool_t ept_handle_misconfig(uint64_t gpa)
*
* Returns: 0 for success, -errno for failure
*/
-static int
+static int __must_check
ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, mfn_t mfn,
unsigned int order, p2m_type_t p2mt, p2m_access_t p2ma,
int sve)
@@ -667,6 +667,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn,
mfn_t mfn,
unsigned long gfn_remainder = gfn;
unsigned int i, target = order / EPT_TABLE_ORDER;
int ret, rc = 0;
+bool_t entry_written = 0;
bool_t direct_mmio = (p2mt == p2m_mmio_direct);
uint8_t ipat = 0;
bool_t need_modify_vtd_table = 1;
@@ -812,10 +813,15 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn,
mfn_t mfn,
rc = atomic_write_ept_entry(ept_entry, new_entry, target);
if ( unlikely(rc) )
old_entry.epte = 0;
-else if ( p2mt != p2m_invalid &&
- (gfn + (1UL << order) - 1 > p2m->max_mapped_pfn) )
-/* Track the highest gfn for which we have ever had a valid mapping */
-p2m->max_mapped_pfn = gfn + (1UL << order) - 1;
+else
+{
+entry_written = 1;
+
+if ( p2mt != p2m_invalid &&
+ (gfn + (1UL << order) - 1 > p2m->max_mapped_pfn) )
+/* Track the highest gfn for which we have ever had a valid
mapping */
+p2m->max_mapped_pfn = gfn + (1UL << order) - 1;
+}
out:
if ( needs_sync )
@@ -831,10 +837,25 @@ out:
{
if ( iommu_flags )
for ( i = 0; i < (1 << order); i++ )
-iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
+{
+rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i,
iommu_flags);
+
+if ( unlikely(rc) )
+{
+while ( i-- )
+iommu_unmap_page(p2m->domain, gfn + i);
+
+break;
+}
+}
else
for ( i = 0;
[Xen-devel] [PATCH v5 07/10] IOMMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (leaf ones).
Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
This patch fixes the leaf ones.
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Stefano Stabellini
CC: Julien Grall
CC: Jan Beulich
CC: Kevin Tian
CC: Feng Wu
---
xen/drivers/passthrough/arm/smmu.c | 13 -
xen/drivers/passthrough/iommu.c | 8 ++--
xen/drivers/passthrough/vtd/iommu.c | 25 ++---
xen/include/xen/iommu.h | 5 +++--
4 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index ee5c89d..1d21568 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2540,7 +2540,7 @@ static int force_stage = 2;
*/
static u32 platform_features = ARM_SMMU_FEAT_COHERENT_WALK;
-static void arm_smmu_iotlb_flush_all(struct domain *d)
+static int __must_check arm_smmu_iotlb_flush_all(struct domain *d)
{
struct arm_smmu_xen_domain *smmu_domain = dom_iommu(d)->arch.priv;
struct iommu_domain *cfg;
@@ -2557,13 +2557,16 @@ static void arm_smmu_iotlb_flush_all(struct domain *d)
arm_smmu_tlb_inv_context(cfg->priv);
}
spin_unlock(&smmu_domain->lock);
+
+ return 0;
}
-static void arm_smmu_iotlb_flush(struct domain *d, unsigned long gfn,
- unsigned int page_count)
+static int __must_check arm_smmu_iotlb_flush(struct domain *d,
+ unsigned long gfn,
+ unsigned int page_count)
{
-/* ARM SMMU v1 doesn't have flush by VMA and VMID */
-arm_smmu_iotlb_flush_all(d);
+ /* ARM SMMU v1 doesn't have flush by VMA and VMID */
+ return arm_smmu_iotlb_flush_all(d);
}
static struct iommu_domain *arm_smmu_get_domain(struct domain *d,
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 54d307b..92d37c5 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -323,9 +323,7 @@ int iommu_iotlb_flush(struct domain *d, unsigned long gfn,
if ( !iommu_enabled || !hd->platform_ops || !hd->platform_ops->iotlb_flush
)
return 0;
-hd->platform_ops->iotlb_flush(d, gfn, page_count);
-
-return 0;
+return hd->platform_ops->iotlb_flush(d, gfn, page_count);
}
int iommu_iotlb_flush_all(struct domain *d)
@@ -335,9 +333,7 @@ int iommu_iotlb_flush_all(struct domain *d)
if ( !iommu_enabled || !hd->platform_ops ||
!hd->platform_ops->iotlb_flush_all )
return 0;
-hd->platform_ops->iotlb_flush_all(d);
-
-return 0;
+return hd->platform_ops->iotlb_flush_all(d);
}
int __init iommu_setup(void)
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 461688c..a6caf97 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -557,9 +557,10 @@ static void iommu_flush_all(void)
}
}
-static int __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
- bool_t dma_old_pte_present,
- unsigned int page_count)
+static int __must_check iommu_flush_iotlb(struct domain *d,
+ unsigned long gfn,
+ bool_t dma_old_pte_present,
+ unsigned int page_count)
{
struct domain_iommu *hd = dom_iommu(d);
struct acpi_drhd_unit *drhd;
@@ -605,14 +606,16 @@ static int __intel_iommu_iotlb_flush(struct domain *d,
unsigned long gfn,
return rc;
}
-static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
unsigned int page_count)
+static int __must_check iommu_flush_iotlb_pages(struct domain *d,
+unsigned long gfn,
+unsigned int page_count)
{
-__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
+return iommu_flush_iotlb(d, gfn, 1, page_count);
}
-static void intel_iommu_iotlb_flush_all(struct domain *d)
+static int iommu_flush_iotlb_all(struct domain *d)
{
-__intel_iommu_iotlb_flush(d, INVALID_GFN, 0, 0);
+return iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
}
/* clear one page's page table */
@@ -647,7 +650,7 @@ static int __must_check dma_pte_clear_one(struct domain
*domain, u64 addr)
iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
if ( !this_cpu(iommu_dont_flush_iotlb) )
-rc = __intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1);
+rc = iommu_flush_iotlb_pages(domain, addr >> PAGE_SHIFT_4K, 1);
unmap_vtd_domain_page(page);
@@ -1775,7 +1778,7 @@ static int __must_check intel_iommu_map_page(struct
domain *d,
unmap_vtd_domain_page(page);
if ( !this_cpu(iommu_dont_flush_iotlb) )
-rc = __intel_iommu_iotlb_flush(d, gfn, dma_pte_
Re: [Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max
On 17/05/16 22:50, Ed Swierk wrote: > I added some more instrumentation and discovered that the result of > xen_count_remap_pages() (0x85dea) is one less than the actual number > of pages remapped by xen_set_identity_and_remap() (0x85deb). > > The two functions differ in their handling of a xen_e820_map entry > whose size is not a multiple of the page size. The entry starting at > 0x68000 has size 0x33400. xen_count_remap_pages() rounds up when > computing the end_pfn (to 0x9c), while xen_set_identity_and_remap() > rounds down (to 0x9b). Thus xen_count_remap_pages() counts the > remapped space following the entry as one page smaller than the other > function does. > > (Confusingly, the "BIOS-provided physical RAM map" shows both the > start and end addresses rounded down to page boundaries, rather than > the addresses actually provided by the BIOS.) > > [0.00] xen_count_remap_pages i=0 addr=0x0 size=0x6 start_pfn=0x0 > end_pfn=0x0 > [0.00] xen_count_remap_pages i=0 plus end_pfn=0x60 type=0x1 > [0.00] xen_count_remap_pages i=1 addr=0x6 size=0x8000 > start_pfn=0x60 end_pfn=0x60 > [0.00] xen_count_remap_pages i=1 plus end_pfn=0x68 type=0x2 > [0.00] xen_count_remap_pages i=2 addr=0x68000 size=0x33400 > start_pfn=0x68 end_pfn=0x68 > [0.00] xen_count_remap_pages i=2 plus end_pfn=0x9c type=0x1 > [0.00] xen_count_remap_pages i=3 addr=0x10 size=0x759fe000 > start_pfn=0x100 end_pfn=0x9c > [0.00] xen_count_remap_pages i=3 plus end_pfn=0x75afe type=0x1 > [0.00] xen_count_remap_pages i=4 addr=0x75bab000 size=0x464b000 > start_pfn=0x75bab end_pfn=0x75afe > [0.00] xen_count_remap_pages i=4 plus end_pfn=0x7a1f6 type=0x1 > [0.00] xen_count_remap_pages i=5 addr=0x7b7d7000 size=0x29000 > start_pfn=0x7b7d7 end_pfn=0x7a1f6 > [0.00] xen_count_remap_pages i=5 plus end_pfn=0x7b800 type=0x1 > [0.00] xen_count_remap_pages i=6 addr=0x7bf0 size=0x10 > start_pfn=0x7bf00 end_pfn=0x7b800 > [0.00] xen_count_remap_pages i=6 plus end_pfn=0x7c000 type=0x1 > [0.00] xen_count_remap_pages i=7 addr=0xc7ffc000 size=0x1000 > start_pfn=0xc7ffc end_pfn=0x7c000 > [0.00] xen_count_remap_pages i=7 plus end_pfn=0xc7ffd type=0x2 > [0.00] xen_count_remap_pages i=8 addr=0xfbffc000 size=0x1000 > start_pfn=0xfbffc end_pfn=0xc7ffd > [0.00] xen_count_remap_pages i=8 plus end_pfn=0xfbffd type=0x2 > [0.00] xen_count_remap_pages i=9 addr=0xfec0 size=0x2000 > start_pfn=0xfec00 end_pfn=0xfbffd > [0.00] xen_count_remap_pages i=9 plus end_pfn=0xfec02 type=0x2 > [0.00] xen_count_remap_pages i=10 addr=0xfec4 size=0x1000 > start_pfn=0xfec40 end_pfn=0xfec02 > [0.00] xen_count_remap_pages i=10 plus end_pfn=0xfec41 type=0x2 > [0.00] xen_count_remap_pages i=11 addr=0xfed2 size=0x1 > start_pfn=0xfed20 end_pfn=0xfec41 > [0.00] xen_count_remap_pages i=11 plus end_pfn=0xfed30 type=0x1 > [0.00] xen_count_remap_pages i=12 addr=0xfee0 size=0x10 > start_pfn=0xfee00 end_pfn=0xfed30 > [0.00] xen_count_remap_pages i=12 plus end_pfn=0xfef00 type=0x2 > [0.00] xen_count_remap_pages i=13 addr=0x1 size=0x1f8000 > start_pfn=0x10 end_pfn=0xfef00 > [0.00] xen_count_remap_pages i=13 plus end_pfn=0x48 type=0x1 > [0.00] xen_count_remap_pages(max_pfn=0x48) == 0x85dea > [0.00] max_pages 0x505dea > [0.00] xen_add_extra_mem(48, 85dea) > [0.00] memblock_reserve(0x48000, 0x85dea000) > [0.00] xen_set_identity_and_remap i=0 addr=0x0 size=0x6 type=0x1 > [0.00] xen_set_identity_and_remap i=1 addr=0x6 size=0x8000 > type=0x2 > [0.00] xen_set_identity_and_remap i=2 addr=0x68000 size=0x33400 > type=0x1 > [0.00] xen_set_identity_and_remap_chunk start_pfn=0x60 end_pfn=0x68 > nr_pages=0x48 remap_pfn=0x48 > [0.00] xen_set_identity_and_remap_chunk i=0x0 cur_pfn=0x60 left=0x8 > size=0x8 remap_range_size=0x1c0 > [0.00] xen_set_identity_and_remap i=3 addr=0x10 size=0x759fe000 > type=0x1 > [0.00] xen_set_identity_and_remap_chunk start_pfn=0x9b end_pfn=0x100 > nr_pages=0x48 remap_pfn=0x480008 > [0.00] xen_set_identity_and_remap_chunk i=0x0 cur_pfn=0x9b left=0x65 > size=0x65 remap_range_size=0x1b8 > [0.00] xen_set_identity_and_remap i=4 addr=0x75bab000 size=0x464b000 > type=0x1 > [0.00] xen_set_identity_and_remap_chunk start_pfn=0x75afe > end_pfn=0x75bab nr_pages=0x48 remap_pfn=0x48006d > [0.00] xen_set_identity_and_remap_chunk i=0x0 cur_pfn=0x75afe > left=0xad size=0xad remap_range_size=0x1bfff93 > [0.00] xen_set_identity_and_remap i=5 addr=0x7b7d7000 size=0x29000 > type=0x1 > [0.00] xen_set_identity_and_remap_chunk start_pfn=0x7a1f6 > end_pfn=0x7b7d7 nr_pages=0x48 remap_pfn=0x48011a > [0.00] xen_set_identity_an
Re: [Xen-devel] [PATCH v10 2/3] vt-d: synchronize for Device-TLB flush one by one
On May 17, 2016 8:37 PM, Jan Beulich wrote:
> >>> On 22.04.16 at 12:54, wrote:
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -33,6 +33,8 @@ integer_param("vtd_qi_timeout", vtd_qi_timeout);
> >
> > #define IOMMU_QI_TIMEOUT (vtd_qi_timeout * MILLISECS(1))
> >
> > +static int invalidate_sync(struct iommu *iommu);
>
> __must_check?
>
Yes, I will add it.
> > -static void queue_invalidate_iotlb(struct iommu *iommu,
> > -u8 granu, u8 dr, u8 dw, u16 did, u8 am, u8 ih, u64 addr)
> > +static int __must_check queue_invalidate_iotlb_sync(struct iommu
> *iommu,
> > +u8 granu, u8 dr, u8 dw,
> > +u16 did, u8 am, u8 ih,
> > +u64 addr)
> > {
> > unsigned long flags;
> > unsigned int index;
> > @@ -133,10 +141,12 @@ static void queue_invalidate_iotlb(struct iommu
> *iommu,
> > unmap_vtd_domain_page(qinval_entries);
> > qinval_update_qtail(iommu, index);
> > spin_unlock_irqrestore(&iommu->register_lock, flags);
> > +
> > +return invalidate_sync(iommu);
> > }
>
> With this, ...
>
> > @@ -346,9 +353,13 @@ static int flush_iotlb_qi(
> > if (cap_read_drain(iommu->cap))
> > dr = 1;
> > /* Need to conside the ih bit later */
> > -queue_invalidate_iotlb(iommu,
> > - type >> DMA_TLB_FLUSH_GRANU_OFFSET, dr,
> > - dw, did, size_order, 0, addr);
> > +ret = queue_invalidate_iotlb_sync(iommu,
> > + type >>
> > DMA_TLB_FLUSH_GRANU_OFFSET,
> > + dr, dw, did, size_order, 0,
> > addr);
> > +
> > +if ( ret )
> > +return ret;
> > +
> > if ( flush_dev_iotlb )
> > ret = dev_invalidate_iotlb(iommu, did, addr, size_order, type);
> > rc = invalidate_sync(iommu);
>
> ... why does this invalidate_sync() not go away?
>
Oh, it is your suggestion -- leaving the existing logic as is would be better -
best effort
invalidation even when an error has occurred.
http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00523.html
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Bug in x86 instruction emulator?
>>> On 06.04.16 at 01:38, wrote: > I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU > with vga="qxl", Xorg will segfault instantly if tried started. Multiple > Linux distros have been tested and Xorg segfaults in all. > > Attached are a full backtrace from domU generated by Xorg, and a > assembler dump of function 'sse2_blt'. Just FYI: Looks like I can repro this finally, and it also looks like at least for me it isn't an SSE2 instruction that the issue is with. Instead I'm getting an #UD in the middle of an instruction a few lines down from the last SSE2 one, which suggests we're having an issue with sizing instructions (however odd that may seem). Now that I can repro it, at least I have something to actually debug ... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] build: convert crash_debug to Kconfig
>>> On 18.05.16 at 04:15, wrote:
> On 5/12/16 4:03 AM, Jan Beulich wrote:
> On 11.05.16 at 19:35, wrote:
>>> On 5/11/16 4:47 AM, Jan Beulich wrote:
>>> On 10.05.16 at 23:05, wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -1,6 +1,13 @@
>
> menu "Debugging Options"
>
> +config CRASH_DEBUG
> + bool "Crash Debugging Support"
> + depends on X86
> + ---help---
> + If you want to be able to attach gdb to Xen to be able to debug
> + Xen if it crashes then say Y.
> +
> config DEBUG
> bool "Developer Checks"
> ---help---
Is this really meant to be independent of DEBUG (or EXPERT), as it's
being placed ahead of DEBUG?
>>>
>>> That's what we talked about with v2. You wanted it to be independent if
>>> EXPERT was set but when you have something defined as "menuconfig "
>>> you cannot then have a rule "if || EXPERT" as you asked for in v2.
>>> So I needed to make them independent always which is what I did.
>>>
>>> Let me restate more generically, if things are dependent on a menu for
>>> the sub-menu items to be displayed (as in v2) then the menu must be
>>> enabled and cannot be conditionally displayed on another option.
>>>
>>> Roughly think of it this way:
>>>
>>> menuconfig SOME_STATE
>>>
>>> if SOME_STATE || EXPERT
>>>
>>> config OTHER
>>>
>>> endif
>>>
>>>
>>> is the following code:
>>>
>>>
>>> if (SOME_STATE) {
>>> if (SOME_STATE or EXPERT) {
>>> printf("got here\n");
>>> }
>>> }
>>
>> But there's no menuconfig anymore, for precisely that reason (aiui).
>
> Right. That's what I was trying to get across. What I gathered from past
> reviews is that it should to be independent of DEBUG correct?
"It" being what? The CRASH_DEBUG above? That would be the
question I asked you in my initial reply (still visible above); I
don't think it should be, but instead should, like all the other
DEBUG controlled ones, be dependent on "DEBUG || EXPERT" as
said a number of times.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/6] build: convert verbose to Kconfig
>>> On 18.05.16 at 04:16, wrote: > On 5/12/16 4:04 AM, Jan Beulich wrote: > On 11.05.16 at 19:37, wrote: >>> On 5/11/16 4:45 AM, Jan Beulich wrote: >>> On 10.05.16 at 23:05, wrote: > --- a/xen/Kconfig.debug > +++ b/xen/Kconfig.debug > @@ -15,4 +15,11 @@ config DEBUG > option is intended for development purposes only, and not for > production use. > > +config VERBOSE_DEBUG > + bool "Verbose debug messages" > + default DEBUG > + ---help--- > + Guest output from HYPERVISOR_console_io and hypervisor parsing > + ELF images (dom0) is logged in the Xen ring buffer. The "depends on DEBUG || EXPERT" did get lost here (or, looking at the following patch, a respective "if" framing them all). >>> >>> This option is always visible to someone and is not dependent on DEBUG >>> due to the if not being possible in the form you asked. So I adjusted it >>> to "default DEBUG" as you had asked. I can make this option dependent on >>> DEBUG or EXPERT. >> >> Same here - with the menuconfig gone, I don't see why. > > So no change? From the first email I gather that it should be "depends > on DEBUG || EXPERT" but from the last one I gather no change. Oh, my mistake. I read the "can" in the last sentence of your previous reply as "can only", i.e. understanding you mean either DEBUG or EXPERT. So yes, what I meant to be asking for is "depends on DEBUG || EXPERT" uniformly for all the DEBUG sub-options. Which, it no longer being a menuconfig, should be possible to express by just an "if DEBUG || EXPERT" framing them all. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 2/3] vt-d: synchronize for Device-TLB flush one by one
>>> On 18.05.16 at 10:53, wrote:
> On May 17, 2016 8:37 PM, Jan Beulich wrote:
>> >>> On 22.04.16 at 12:54, wrote:
>> > -static void queue_invalidate_iotlb(struct iommu *iommu,
>> > -u8 granu, u8 dr, u8 dw, u16 did, u8 am, u8 ih, u64 addr)
>> > +static int __must_check queue_invalidate_iotlb_sync(struct iommu
>> *iommu,
>> > +u8 granu, u8 dr, u8
>> > dw,
>> > +u16 did, u8 am, u8 ih,
>> > +u64 addr)
>> > {
>> > unsigned long flags;
>> > unsigned int index;
>> > @@ -133,10 +141,12 @@ static void queue_invalidate_iotlb(struct iommu
>> *iommu,
>> > unmap_vtd_domain_page(qinval_entries);
>> > qinval_update_qtail(iommu, index);
>> > spin_unlock_irqrestore(&iommu->register_lock, flags);
>> > +
>> > +return invalidate_sync(iommu);
>> > }
>>
>> With this, ...
>>
>> > @@ -346,9 +353,13 @@ static int flush_iotlb_qi(
>> > if (cap_read_drain(iommu->cap))
>> > dr = 1;
>> > /* Need to conside the ih bit later */
>> > -queue_invalidate_iotlb(iommu,
>> > - type >> DMA_TLB_FLUSH_GRANU_OFFSET, dr,
>> > - dw, did, size_order, 0, addr);
>> > +ret = queue_invalidate_iotlb_sync(iommu,
>> > + type >>
>> > DMA_TLB_FLUSH_GRANU_OFFSET,
>> > + dr, dw, did, size_order, 0,
>> > addr);
>> > +
>> > +if ( ret )
>> > +return ret;
>> > +
>> > if ( flush_dev_iotlb )
>> > ret = dev_invalidate_iotlb(iommu, did, addr, size_order,
>> > type);
>> > rc = invalidate_sync(iommu);
>>
>> ... why does this invalidate_sync() not go away?
>>
>
> Oh, it is your suggestion -- leaving the existing logic as is would be better
> -
> best effort invalidation even when an error has occurred.
>
> http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00523.html
Look like this was a bad comment of mine (resulting from
dev_invalidate_iotlb(), other than the other respective functions,
not getting a _sync tag added), and I would have appreciated if
you had simply pointed out the redundancy. Please remember
that the review process is bi-directional, and hence doesn't mean
you need to blindly do everything a reviewer asks for: Things you
agree with should be changed in code. For things you don't agree
with you should reply verbally, explaining why a requested change
shouldn't be done.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH net-next] xen-netback: correct length checks on hash copy_ops
On Wed, May 18, 2016 at 08:53:01AM +0100, Paul Durrant wrote:
> The length checks on the grant table copy_ops for setting hash key and
> hash mapping are checking the local 'len' value which is correct in
> the case of the former but not the latter. This was picked up by
> static analysis checks.
>
> This patch replaces checks of 'len' with 'copy_op.len' in both cases
> to correct the incorrect check, keep the two checks consistent, and to
> make it clear what the checks are for.
>
> Signed-off-by: Paul Durrant
> Reported-by: Dan Carpenter
> Cc: Wei Liu
Acked-by: Wei Liu
> ---
> drivers/net/xen-netback/hash.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-netback/hash.c
> index 392e392..fb87cb3 100644
> --- a/drivers/net/xen-netback/hash.c
> +++ b/drivers/net/xen-netback/hash.c
> @@ -311,7 +311,7 @@ u32 xenvif_set_hash_key(struct xenvif *vif, u32 gref, u32
> len)
> if (len > XEN_NETBK_MAX_HASH_KEY_SIZE)
> return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
>
> - if (len != 0) {
> + if (copy_op.len != 0) {
> gnttab_batch_copy(©_op, 1);
>
> if (copy_op.status != GNTST_okay)
> @@ -359,7 +359,7 @@ u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref,
> u32 len,
> if (mapping[off++] >= vif->num_queues)
> return XEN_NETIF_CTRL_STATUS_INVALID_PARAMETER;
>
> - if (len != 0) {
> + if (copy_op.len != 0) {
> gnttab_batch_copy(©_op, 1);
>
> if (copy_op.status != GNTST_okay)
> --
> 2.1.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [seabios test] 94522: tolerable FAIL - PUSHED
flight 94522 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94522/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 92452
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92452
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
fail never pass
version targeted for testing:
seabios 1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
baseline version:
seabios c8e105a4d5e52e8e7539ab1f2cd07ebe0ae9033a
Last test of basis92452 2016-04-23 11:37:00 Z 24 days
Testing same since94496 2016-05-17 01:12:44 Z1 days3 attempts
People who touched revisions under test:
Kevin O'Connor
Paul Menzel
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-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-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
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=seabios
+ revision=1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
+ . ./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 seabios
1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
+ branch=seabios
+ revision=1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuub
Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
On Tue, May 17, 2016 at 08:05:23PM +0800, Big Strong wrote: > Is there a libxc function to translate the > virtual address of malloc() to physical address? Only to answer this question: no. There isn't one. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Xen: don't warn about 2-byte wchar_t in efi
On Monday 16 May 2016 12:08:17 Stefano Stabellini wrote:
> On Wed, 11 May 2016, Arnd Bergmann wrote:
> > The XEN UEFI code has become available on the ARM architecture
> > recently, but now causes a link-time warning:
> >
> > ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use
> > 4-byte wchar_t; use of wchar_t values across objects may fail
> >
> > This seems harmless, because the efi code only uses 2-byte
> > characters when interacting with EFI, so we don't pass on those
> > strings to elsewhere in the system, and we just need to
> > silence the warning.
> >
> > It is not clear to me whether we actually need to build the file
> > with the -fshort-wchar flag, but if we do, then we should also
> > pass --no-wchar-size-warning to the linker, to avoid the warning.
> >
> > Signed-off-by: Arnd Bergmann
> > Fixes: 37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific
> > UEFI runtime services")
>
> Given that drivers/xen/efi.c doesn't actually use any wchar_t, it is not
> clear to me whether we need to pass -fshort-wchar either. However this
> patch is correct any, so I committed it to xentip.
Right, I was wondering about that too, but it has been this way since the
code was first merged, so I couldn't figure out if removing the flag
had any side-effects.
Arnd
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [for-4.7 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings
On Tue, 17 May 2016, Julien Grall wrote: > Hi Stefano, > > On 17/05/16 13:27, Stefano Stabellini wrote: > > On Tue, 17 May 2016, Julien Grall wrote: > > > On 17/05/16 12:24, Stefano Stabellini wrote: > > > > I think you are right. Especially with backports in mind, it would be > > > > better to introduce an __apply_p2m_changes function which assumes that > > > > the p2m lock has already been taken by the caller. Then you can base the > > > > implementation of apply_p2m_changes on it. > > > > > > > On Tue, 17 May 2016, Wei Chen wrote: > > > > > Hi Julien, > > > > > > > > > > I have some concern about this patch. Because we released the spinlock > > > > > before remove the mapped memory. If somebody acquires the spinlock > > > > > before we remove the mapped memory, this mapped memory region can be > > > > > accessed by guest. > > > > > > > > > > The apply_p2m_changes is no longer atomic. Is it a security risk? > > > > > > Accesses to the page table have never been atomic, as soon as an entry is > > > written in the page tables, the guest vCPUs or a prefetcher could read it. > > > > > > The spinlock is only here to protect the page tables against concurrent > > > modifications. Releasing the lock is not an issue as Xen does not promise > > > any > > > ordering for the p2m changes. > > > > I understand that. However I am wondering whether it might be possible > > for the guest to run commands which cause concurrent p2m change requests > > on purpose, inserting something else between the first phase and the > > second phase of apply_p2m_changes, causing problems to the hypervisor. > > Removing and inserting entries are 2 distinct steps. > > > Or maybe not even on purpose, but causing problem to itself nonetheless. > > Each vCPU can only trigger one command at the time. So concurrent p2m changes > would involve 2 vCPUs. > > Even if vCPU A send the command before vCPU B, nothing prevents Xen to serve B > before A. > > The only way a guest could harm itself would be to have the 2 requests > modifying the same regions in the page tables. However, per-above this > behavior is undefined no matter the implementation of apply_p2m_changes. All right, so the use case that should haved worked before (but didn't because the implementation was broken) and wouldn't work anymore with this patch is the following: - vcpu1 asks region1 to be mapped at gpaddrA the mapping fails at least partially - vcpu2 asks region2 to be mapped at gpaddrA the mapping succeeds This doesn't work anymore because the second mapping could be done in between the two halves of the first mapping, resulting in a partially mapped region2. I realize that this is an unimportant case and not worth supporting. I, for one, would prefer not to have to think about implementation halves of apply_p2m_changes going forward so I would prefer a different patch. That said, I still retract my comment and leave it up to you. If you would like to change this patch, I'll be happy to review v2, otherwise, if you prefer to keep it as is, let me know and I'll commit this version. > > Honestly it is true that it doesn't look like Xen could run into > > troubles. But still this is a change in behaviour compared to the > > current code (which I know doesn't actually work) and I wanted to flag > > it. > > This code has always been buggy, and I suspect the goal was to call back > without the lock. > > There is no reason to keep the lock more than necessary. Releasing the lock > allow other p2m changes to be executed rather than spinning while the long > execution (INSERTION + REMOVAL) is done. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 00/10] Check VT-d Device-TLB flush error
>>> On 18.05.16 at 10:08, wrote: > --Changes in v5: > > patch 1: > * add the missing blank line. > * add comments. > * if iommu_flush_context_device failed, continue to flush IOMMU IOTLB on a > best effort basis. > * __defer__ to: > - rename __intel_iommu_iotlb_flush to iommu_flush_iotlb > - rename intel_iommu_iotlb_flush to iommu_flush_iotlb_pages > - rename intel_iommu_iotlb_flush_all to iommu_flush_iotlb_all > - add __must_check annotation > in patch 7 / 8, > otherwise, this will disrupt the order due to __must_check annotation. I've peeked into patch 1, and this information is still not there, despite you having been asked before to put this change information into the individual patches to aid reviewers. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [for-4.7 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings
Hi Stefano, On 18/05/2016 11:10, Stefano Stabellini wrote: All right, so the use case that should haved worked before (but didn't because the implementation was broken) and wouldn't work anymore with this patch is the following: - vcpu1 asks region1 to be mapped at gpaddrA the mapping fails at least partially - vcpu2 asks region2 to be mapped at gpaddrA the mapping succeeds This doesn't work anymore because the second mapping could be done in between the two halves of the first mapping, resulting in a partially mapped region2. If we leave aside the buggy code, this use case has never worked and will never work. Xen might handle the request from vcpu2 before vcpu1. It is not because of the implementation, but because the pCPU running vCPU1 may be slower or receive an interrupt... So the use case you described is already unpredictable. The guest has to use an internal lock if it wants the request from vCPU2 to be handled after the one from vCPU1. And in this case, it is not possible to have vCPU2 messing in the middle of the vCPU1 transaction. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6] Config.mk: update mini-os changeset
>>> On 17.05.16 at 17:57, wrote: > Patches pulled in: > lib/sys.c: enclose file_types in define guards > build: change MINI-OS_ROOT to MINIOS_ROOT > > Signed-off-by: Wei Liu Applied, but in the future please submit patches against staging-4.6: I had to fix up patch context to account for the qemu updates which didn't pass the push gate yet. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-coverity test] 94545: all pass - PUSHED
flight 94545 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94545/
Perfect :-)
All tests in this flight passed
version targeted for testing:
xen c32381352cce9744e640bf239d2704dae4af4fc7
baseline version:
xen 4f6aea066fe2cf3bf4929d6dac1e558071566f73
Last test of basis94390 2016-05-15 09:18:54 Z3 days
Testing same since94545 2016-05-18 09:19:19 Z0 days1 attempts
People who touched revisions under test:
Andrew Cooper
Edgar E. Iglesias
Jan Beulich
Jim Fehlig
Peng Fan
Stefano Stabellini
Wei Liu
jobs:
coverity-amd64 pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-coverity
+ revision=c32381352cce9744e640bf239d2704dae4af4fc7
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push
xen-unstable-coverity c32381352cce9744e640bf239d2704dae4af4fc7
+ branch=xen-unstable-coverity
+ revision=c32381352cce9744e640bf239d2704dae4af4fc7
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.6-testing
+ '[' xc32381352cce9744e640bf239d2704dae4af4fc7 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/o
Re: [Xen-devel] [for-4.7 0/2] xen/arm: Bug fixes in the P2M code
Wei Liu, can I go ahead and commit this to staging? Do you approve it for 4.7? On Mon, 16 May 2016, Julien Grall wrote: > Hello, > > This small series fixes potential deadlock and the removal of unrelated > mapping when the P2M code fails to insert/allocate mappings. > > This series contains bug fix for Xen 4.7 and candidate for backporting > up to Xen 4.5. > > Yours sincerely, > > Julien Grall (2): > xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary > xen/arm: p2m: Release the p2m lock before undoing the mappings > > xen/arch/arm/p2m.c | 25 +++-- > 1 file changed, 11 insertions(+), 14 deletions(-) > > -- > 1.9.1 > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6] Config.mk: update mini-os changeset
On Wed, May 18, 2016 at 04:31:22AM -0600, Jan Beulich wrote: > >>> On 17.05.16 at 17:57, wrote: > > Patches pulled in: > > lib/sys.c: enclose file_types in define guards > > build: change MINI-OS_ROOT to MINIOS_ROOT > > > > Signed-off-by: Wei Liu > > Applied, but in the future please submit patches against staging-4.6: > I had to fix up patch context to account for the qemu updates which > didn't pass the push gate yet. > Sorry for the trouble. I will patch staging in the future. Wei. > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [for-4.7 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings
On 18/05/2016 11:10, Stefano Stabellini wrote: I realize that this is an unimportant case and not worth supporting. I, for one, would prefer not to have to think about implementation halves of apply_p2m_changes going forward so I would prefer a different patch. That said, I still retract my comment and leave it up to you. If you would like to change this patch, I'll be happy to review v2, otherwise, if you prefer to keep it as is, let me know and I'll commit this version. I forgot to reply to this part. I agree that the resulting code might be confusing. However today, the lock is taken for a very long time (TLBs are flushed in the middle, memory management,...) which may result to starve other vCPUs on big platform. This time would be doubled in case of failure when inserting a new mapping. FWIW, I am planning to rework the page table code for the next release to get it simplified and handle break-before-make (recommended by the ARM ARM) more easily. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [GIT PULL] EFI ARM Xen support
* Stefano Stabellini wrote:
> On Tue, 17 May 2016, David Vrabel wrote:
> > On 17/05/16 11:12, Stefano Stabellini wrote:
> > > On Sat, 14 May 2016, Matt Fleming wrote:
> > >> Folks,
> > >>
> > >> Please pull the following branch which contains support for Xen on ARM
> > >> EFI platforms.
> > >>
> > >> This merge includes a merge of Stefano's xen/linux-next branch to pull
> > >> in the prerequisites required for Shannon's commit:
> > >>
> > >> 11ee5491e5ff ("Xen: EFI: Parse DT parameters for Xen specific UEFI")
> > >>
> > >> as it needs both the latest changes in the EFI 'next' branch (now
> > >> tip/efi/core) and xen/linux-next.
> > >>
> > >> I have intentionally not included the individual patches as I would
> > >> normally do in a pull request, so that commit history created by my
> > >> merging of Stefano's branch is preserved, and so that there's no way
> > >> to accidentally apply the patches individually.
> > >>
> > >> The following changes since commit
> > >> 6c5450ef66816216e574885cf8d3ddb31ef77428:
> > >>
> > >> efivarfs: Make efivarfs_file_ioctl() static (2016-05-07 07:06:13 +0200)
> > >>
> > >> are available in the git repository at:
> > >>
> > >> git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
> > >> efi/arm-xen
> > >>
> > >> for you to fetch changes up to 11ee5491e5ff519e0d3a7018eb21351cb6955a98:
> > >>
> > >> Xen: EFI: Parse DT parameters for Xen specific UEFI (2016-05-14
> > >> 19:31:01 +0100)
> > >
> > > Is this arrangement working for everybody, in particular the tip
> > > maintainers?
> >
> > Yes.
>
> I meant the x86 tip maintainers (Thomas, Peter and Ingo).
I have no particular objections, since this seems to be Xen-next merged to the
EFI
tree that is already upstream, plus this single commit on top of t:
11ee5491e5ff Xen: EFI: Parse DT parameters for Xen specific UEFI
Which, if Matt is fine with it, you could send to Linus too as part of this
cycle's Xen pull request.
Thanks,
Ingo
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [for-4.7 0/2] xen/arm: Bug fixes in the P2M code
On Wed, May 18, 2016 at 11:39:56AM +0100, Stefano Stabellini wrote: > Wei Liu, > > can I go ahead and commit this to staging? Do you approve it for 4.7? > Release-acked-by: Wei Liu > On Mon, 16 May 2016, Julien Grall wrote: > > Hello, > > > > This small series fixes potential deadlock and the removal of unrelated > > mapping when the P2M code fails to insert/allocate mappings. > > > > This series contains bug fix for Xen 4.7 and candidate for backporting > > up to Xen 4.5. > > > > Yours sincerely, > > > > Julien Grall (2): > > xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary > > xen/arm: p2m: Release the p2m lock before undoing the mappings > > > > xen/arch/arm/p2m.c | 25 +++-- > > 1 file changed, 11 insertions(+), 14 deletions(-) > > > > -- > > 1.9.1 > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [GIT PULL] EFI ARM Xen support
On Wed, 18 May, at 12:46:38PM, Ingo Molnar wrote: > > I have no particular objections, since this seems to be Xen-next merged to > the EFI > tree that is already upstream, plus this single commit on top of t: > > 11ee5491e5ff Xen: EFI: Parse DT parameters for Xen specific UEFI > > Which, if Matt is fine with it, you could send to Linus too as part of this > cycle's Xen pull request. Sure, I'm fine with that. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [for-4.7 0/2] xen/arm: Bug fixes in the P2M code
On 18/05/2016 11:39, Stefano Stabellini wrote: Wei Liu, can I go ahead and commit this to staging? Do you approve it for 4.7? I will resend a new version of patch #2 with a summary of the discussion we had. You can go ahead to apply #1, assuming Wei gives a release-acked. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 44427: all pass
This run is configured for baseline tests only. flight 44427 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44427/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf b41ef32518095f783d0c2343b496cc857c6f3dff baseline version: ovmf 05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5 Last test of basis44424 2016-05-17 14:50:00 Z0 days Testing same since44427 2016-05-18 06:20:27 Z0 days1 attempts People who touched revisions under test: Jiaxin Wu Laszlo Ersek Maurice Ma Zenith432 jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit b41ef32518095f783d0c2343b496cc857c6f3dff Author: Maurice Ma Date: Mon May 16 08:29:40 2016 -0700 CorebootModulePkg: Remove PciSioSerialDxe and SerialDxe driver CorebootPayloadPkg has been changed to use generic SerialDxe driver from MdeModulePkg. As part of the clean-up, the overridden SerialDxe and PciSioSerialDxe drivers in CorebootModulePkg need to be removed. Cc: Prince Agyeman Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Maurice Ma Reviewed-by: Lee Leahy commit 1fed57ab5d6961c43866b98c6ef56e1740373b1c Author: Jiaxin Wu Date: Mon May 16 11:44:45 2016 +0800 MdeModulePkg: Refine the code for DxeHttpLib Cc: Ye Ting Cc: Fu Siyuan Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu Reviewed-by: Liming Gao commit 1250f3706620141d92fec4428352270251c9ac4d Author: Zenith432 Date: Mon May 16 15:51:25 2016 + OvmfPkg/XenBusDxe: duplicate twice-iterated VA_LIST in XenStoreVSPrint() Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zenith432 Reviewed-by: Laszlo Ersek [ler...@redhat.com: add spaces before macro invocation parentheses; clean up subject line] Signed-off-by: Laszlo Ersek ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [distros-debian-squeeze test] 44428: trouble: broken/fail/pass
flight 44428 distros-debian-squeeze real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44428/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 4 capture-logs !broken [st=!broken!] build-armhf-pvops 4 capture-logs !broken [st=!broken!] Regressions which are regarded as allowable (not blocking): build-armhf 3 host-install(3) broken like 44404 build-armhf-pvops 3 host-install(3) broken like 44404 test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail blocked in 44404 test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail blocked in 44404 test-amd64-i386-i386-squeeze-netboot-pygrub 9 debian-di-install fail blocked in 44404 test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail blocked in 44404 baseline version: flight 44404 jobs: build-amd64 pass build-armhf broken build-i386 pass build-amd64-pvopspass build-armhf-pvopsbroken build-i386-pvops pass test-amd64-amd64-amd64-squeeze-netboot-pygrubfail test-amd64-i386-amd64-squeeze-netboot-pygrub fail test-amd64-amd64-i386-squeeze-netboot-pygrub fail test-amd64-i386-i386-squeeze-netboot-pygrub fail 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] [PATCH] Config.mk: update qemu-xen tag
Signed-off-by: Anthony PERARD --- Config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Config.mk b/Config.mk index 05bcadc..bdc8e45 100644 --- a/Config.mk +++ b/Config.mk @@ -271,7 +271,7 @@ SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git endif OVMF_UPSTREAM_REVISION ?= b41ef32518095f783d0c2343b496cc857c6f3dff -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc1 +QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc4 MINIOS_UPSTREAM_REVISION ?= 1a3ee6eeca136525aa2e6917ae500e7cf731c09d # Fri May 13 15:21:10 2016 +0100 # lib/sys.c: enclose file_types in define guards -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Config.mk: update qemu-xen tag
On Wed, May 18, 2016 at 12:35:22PM +0100, Anthony PERARD wrote: > Signed-off-by: Anthony PERARD Ack + queued. Thanks > --- > Config.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Config.mk b/Config.mk > index 05bcadc..bdc8e45 100644 > --- a/Config.mk > +++ b/Config.mk > @@ -271,7 +271,7 @@ SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git > MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git > endif > OVMF_UPSTREAM_REVISION ?= b41ef32518095f783d0c2343b496cc857c6f3dff > -QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc1 > +QEMU_UPSTREAM_REVISION ?= qemu-xen-4.7.0-rc4 > MINIOS_UPSTREAM_REVISION ?= 1a3ee6eeca136525aa2e6917ae500e7cf731c09d > # Fri May 13 15:21:10 2016 +0100 > # lib/sys.c: enclose file_types in define guards > -- > Anthony PERARD > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about MMU update on HVM guest
On Fri, May 13, 2016 at 12:11 AM, AnhNN wrote: > Hi, > > I have some questions about MMU update operation. > I add some logging in function do_mmu_update (in file /xen/arch/x86/mm.c), > and start Windows 7 32 bit HVM guest. > After guest started, I look at log and see that MMU update has been called > with every page of guest, with pt_ower = 0 and pg_owner = 1. And with every > page, MMU update called 2 times. The first time, page->count_info = > 0x8002 after MMU update, but after that it decrease to > 0x8001 in a different function. At the second time, > page->count_info = 0x8002 after MMU update, and keep that value > forever. > > So the question is, why domain 0 have a reference to every pages of HVM > guest ? > And why in the second time of MMU update, count_info doesn't decrease to > 0x8001 ? I think your best best for understanding where the references are coming from is to look at the get_page / put_page. One question: is your guest running in HVM mode, or in shadow mode? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 94527: regressions - FAIL
flight 94527 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94527/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs. 93932 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 93932 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 93932 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93932 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 93932 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93932 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 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-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-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 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-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-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 test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 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-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 version targeted for testing: xen fa168e3b9f9547556d5267f55f4c8fa675b4d371 baseline version: xen 39546d1360d954c2d0e2ff71dc74851e7081f61f Last test of basis93932 2016-05-09 21:11:10 Z8 days Failing since 94000 2016-05-10 18:10:33 Z7 days 12 attempts Testing same since94527 2016-05-17 16:13:21 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Ian Campbell Ian Jackson Jan Beulich Julien Grall Kyle J. Temkin Kyle Temkin Shanker Donthineni Stefano Stabellini Stefano Stabellini Vikram Sethi Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev
Re: [Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max
On 17/05/16 22:50, Ed Swierk wrote:
> I added some more instrumentation and discovered that the result of
> xen_count_remap_pages() (0x85dea) is one less than the actual number
> of pages remapped by xen_set_identity_and_remap() (0x85deb).
>
> The two functions differ in their handling of a xen_e820_map entry
> whose size is not a multiple of the page size. The entry starting at
> 0x68000 has size 0x33400. xen_count_remap_pages() rounds up when
> computing the end_pfn (to 0x9c), while xen_set_identity_and_remap()
> rounds down (to 0x9b). Thus xen_count_remap_pages() counts the
> remapped space following the entry as one page smaller than the other
> function does.
Could you please test the attached patch? It follows your idea of the
combined function, but is using a function pointer instead of a flag.
The patch is based on 4.6, but I believe it should just work on 4.4.
Juergen
>From 0d665e37ef79c35cc71830a46d3cf1746b5d01ee Mon Sep 17 00:00:00 2001
From: Juergen Gross
Date: Wed, 18 May 2016 12:54:42 +0200
Subject: [PATCH] xen: use same main loop for counting and remapping pages
Instead of having two functions for cycling through the E820 map in
order to count to be remapped pages and remap them later, just use one
function with a caller supplied sub-function called for each region to
be processed. This eliminates the possibility of a mismatch between
both loops which showed up in certain configurations.
Suggested-by: Ed Swierk
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 65 +---
1 file changed, 26 insertions(+), 39 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 7ab2951..42b8fda 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -393,6 +393,9 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
unsigned long i = 0;
unsigned long n = end_pfn - start_pfn;
+ if (remap_pfn == 0)
+ remap_pfn = nr_pages;
+
while (i < n) {
unsigned long cur_pfn = start_pfn + i;
unsigned long left = n - i;
@@ -438,17 +441,29 @@ static unsigned long __init xen_set_identity_and_remap_chunk(
return remap_pfn;
}
-static void __init xen_set_identity_and_remap(unsigned long nr_pages)
+static unsigned long __init xen_count_remap_pages(
+ unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages,
+ unsigned long remap_pages)
+{
+ if (start_pfn >= nr_pages)
+ return remap_pages;
+
+ return remap_pages + min(end_pfn, nr_pages) - start_pfn;
+}
+
+static unsigned long __init xen_foreach_remap_area(unsigned long nr_pages,
+ unsigned long (*func)(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned long nr_pages, unsigned long last_val))
{
phys_addr_t start = 0;
- unsigned long last_pfn = nr_pages;
+ unsigned long ret_val = 0;
const struct e820entry *entry = xen_e820_map;
int i;
/*
* Combine non-RAM regions and gaps until a RAM region (or the
- * end of the map) is reached, then set the 1:1 map and
- * remap the memory in those non-RAM regions.
+ * end of the map) is reached, then call the provided function
+ * to perform it's duty on the non-RAM region.
*
* The combined non-RAM regions are rounded to a whole number
* of pages so any partial pages are accessible via the 1:1
@@ -466,14 +481,13 @@ static void __init xen_set_identity_and_remap(unsigned long nr_pages)
end_pfn = PFN_UP(entry->addr);
if (start_pfn < end_pfn)
-last_pfn = xen_set_identity_and_remap_chunk(
- start_pfn, end_pfn, nr_pages,
- last_pfn);
+ret_val = func(start_pfn, end_pfn, nr_pages,
+ ret_val);
start = end;
}
}
- pr_info("Released %ld page(s)\n", xen_released_pages);
+ return ret_val;
}
/*
@@ -596,35 +610,6 @@ static void __init xen_ignore_unusable(void)
}
}
-static unsigned long __init xen_count_remap_pages(unsigned long max_pfn)
-{
- unsigned long extra = 0;
- unsigned long start_pfn, end_pfn;
- const struct e820entry *entry = xen_e820_map;
- int i;
-
- end_pfn = 0;
- for (i = 0; i < xen_e820_map_entries; i++, entry++) {
- start_pfn = PFN_DOWN(entry->addr);
- /* Adjacent regions on non-page boundaries handling! */
- end_pfn = min(end_pfn, start_pfn);
-
- if (start_pfn >= max_pfn)
- return extra + max_pfn - end_pfn;
-
- /* Add any holes in map to result. */
- extra += start_pfn - end_pfn;
-
- end_pfn = PFN_UP(entry->addr + entry->size);
- end_pfn = min(end_pfn, max_pfn);
-
- if (entry->type != E820_RAM)
- extra += end_pfn - start_pfn;
- }
-
- return extra;
-}
-
bool __init xen_is_e820_reserved(phys_addr_t start, phys_addr_t size)
{
struct e820entry *entry;
@@ -804,7 +789,7 @@ char * __init xen_memory_setup(void)
max_pages = xen_get_max_pages();
/* How many extra pages do we need due to remapping? */
- max_pages += xen_count_remap_pages(max_pfn);
+ max_pages += xen_foreach_remap_area(max_pfn, xen_count_remap_pages);
if (max_pages > max_pfn)
extra_pages += max_pages - max_pfn;
@@ -922,7 +
Re: [Xen-devel] [PATCH v10 2/3] vt-d: synchronize for Device-TLB flush one by one
On May 18, 2016 5:29 PM, Jan Beulich wrote:
> >>> On 18.05.16 at 10:53, wrote:
> > On May 17, 2016 8:37 PM, Jan Beulich wrote:
> >> >>> On 22.04.16 at 12:54, wrote:
> >> > -static void queue_invalidate_iotlb(struct iommu *iommu,
> >> > -u8 granu, u8 dr, u8 dw, u16 did, u8 am, u8 ih, u64 addr)
> >> > +static int __must_check queue_invalidate_iotlb_sync(struct iommu
> >> *iommu,
> >> > +u8 granu, u8 dr, u8
> >> > dw,
> >> > +u16 did, u8 am, u8
> >> > ih,
> >> > +u64 addr)
> >> > {
> >> > unsigned long flags;
> >> > unsigned int index;
> >> > @@ -133,10 +141,12 @@ static void queue_invalidate_iotlb(struct
> >> > iommu
> >> *iommu,
> >> > unmap_vtd_domain_page(qinval_entries);
> >> > qinval_update_qtail(iommu, index);
> >> > spin_unlock_irqrestore(&iommu->register_lock, flags);
> >> > +
> >> > +return invalidate_sync(iommu);
> >> > }
> >>
> >> With this, ...
> >>
> >> > @@ -346,9 +353,13 @@ static int flush_iotlb_qi(
> >> > if (cap_read_drain(iommu->cap))
> >> > dr = 1;
> >> > /* Need to conside the ih bit later */
> >> > -queue_invalidate_iotlb(iommu,
> >> > - type >> DMA_TLB_FLUSH_GRANU_OFFSET, dr,
> >> > - dw, did, size_order, 0, addr);
> >> > +ret = queue_invalidate_iotlb_sync(iommu,
> >> > + type >>
> >> > DMA_TLB_FLUSH_GRANU_OFFSET,
> >> > + dr, dw, did, size_order,
> >> > + 0, addr);
> >> > +
> >> > +if ( ret )
> >> > +return ret;
> >> > +
> >> > if ( flush_dev_iotlb )
> >> > ret = dev_invalidate_iotlb(iommu, did, addr, size_order,
> >> > type);
> >> > rc = invalidate_sync(iommu);
> >>
> >> ... why does this invalidate_sync() not go away?
> >>
> >
> > Oh, it is your suggestion -- leaving the existing logic as is would be
> > better - best effort invalidation even when an error has occurred.
> >
> > http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00523.h
> > tml
>
> Look like this was a bad comment of mine (resulting from
> dev_invalidate_iotlb(), other than the other respective functions, not
> getting a
> _sync tag added), and I would have appreciated if you had simply pointed out
> the redundancy.
I just issued an open for this point in v9 discussion. I felt a strange, but
really didn't have obvious reasons at that time.
--
I'll drop this invalidate_sync() in v11.
> Please remember that the review process is bi-directional,
> and hence doesn't mean you need to blindly do everything a reviewer asks for:
> Things you agree with should be changed in code. For things you don't agree
> with you should reply verbally, explaining why a requested change shouldn't
> be done.
>
Thanks. I will try to follow it.
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 00/10] Check VT-d Device-TLB flush error
On May 18, 2016 6:21 PM, Jan Beulich wrote: > >>> On 18.05.16 at 10:08, wrote: > > --Changes in v5: > > > > patch 1: > > * add the missing blank line. > > * add comments. > > * if iommu_flush_context_device failed, continue to flush IOMMU IOTLB on > a best effort basis. > > * __defer__ to: > > - rename __intel_iommu_iotlb_flush to iommu_flush_iotlb > > - rename intel_iommu_iotlb_flush to iommu_flush_iotlb_pages > > - rename intel_iommu_iotlb_flush_all to iommu_flush_iotlb_all > > - add __must_check annotation > > in patch 7 / 8, > > otherwise, this will disrupt the order due to __must_check annotation. > > I've peeked into patch 1, and this information is still not there, despite you > having been asked before to put this change information into the individual > patches to aid reviewers. > Sorry, I misunderstood the 'Somewhere' in previous discussion, furthermore, I don't like to add so much change information at the beginning of the patch. But if you like, I will follow it. Sorry again. Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: add steal_clock support on x86
With CONFIG_PARAVIRT_TIME_ACCOUNTING the kernel is capable to account
for time a thread wasn't able to run due to hypervisor scheduling.
Add support in Xen arch independent time handling for this feature by
moving it out of the arm arch into drivers/xen.
Signed-off-by: Juergen Gross
---
arch/arm/xen/enlighten.c | 17 ++---
arch/x86/xen/time.c | 2 ++
drivers/xen/time.c | 19 +++
include/xen/xen-ops.h| 1 +
4 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..9163b94 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -84,19 +84,6 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct *vma,
}
EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
-static unsigned long long xen_stolen_accounting(int cpu)
-{
- struct vcpu_runstate_info state;
-
- BUG_ON(cpu != smp_processor_id());
-
- xen_get_runstate_snapshot(&state);
-
- WARN_ON(state.state != RUNSTATE_running);
-
- return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
-}
-
static void xen_read_wallclock(struct timespec64 *ts)
{
u32 version;
@@ -355,8 +342,8 @@ static int __init xen_guest_init(void)
register_cpu_notifier(&xen_cpu_notifier);
- pv_time_ops.steal_clock = xen_stolen_accounting;
- static_key_slow_inc(¶virt_steal_enabled);
+ xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index a0a4e55..f478169 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -431,6 +431,8 @@ static void __init xen_time_init(void)
xen_setup_timer(cpu);
xen_setup_cpu_clockevents();
+ xen_time_setup_guest();
+
if (xen_initial_domain())
pvclock_gtod_register_notifier(&xen_pvclock_gtod_notifier);
}
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index 7107842..6648a78 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -75,6 +75,15 @@ bool xen_vcpu_stolen(int vcpu)
return per_cpu(xen_runstate, vcpu).state == RUNSTATE_runnable;
}
+static u64 xen_steal_clock(int cpu)
+{
+ struct vcpu_runstate_info state;
+
+ BUG_ON(cpu != smp_processor_id());
+ xen_get_runstate_snapshot(&state);
+ return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
+}
+
void xen_setup_runstate_info(int cpu)
{
struct vcpu_register_runstate_memory_area area;
@@ -86,3 +95,13 @@ void xen_setup_runstate_info(int cpu)
BUG();
}
+void __init xen_time_setup_guest(void)
+{
+ pv_time_ops.steal_clock = xen_steal_clock;
+
+ static_key_slow_inc(¶virt_steal_enabled);
+ /*
+* We can't set paravirt_steal_rq_enabled as this would require the
+* capability to read another cpu's runstate info.
+*/
+}
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..5ce51c2 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -21,6 +21,7 @@ void xen_resume_notifier_unregister(struct notifier_block
*nb);
bool xen_vcpu_stolen(int vcpu);
void xen_setup_runstate_info(int cpu);
+void __init xen_time_setup_guest(void);
void xen_get_runstate_snapshot(struct vcpu_runstate_info *res);
int xen_setup_shutdown_event(void);
--
2.6.6
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen
On 17/05/16 11:33, George Dunlap wrote: > On Mon, May 16, 2016 at 11:33 PM, Boris Ostrovsky > wrote: >> On 05/16/2016 05:38 PM, Tony S wrote: >>> The issue behind it is that the process execution calculation(e.g., >>> delta_exec) in virtualized environment should not be calculated as it >>> did in physical enviroment. >>> >>> Here are two solutions to fix it: >>> >>> 1) Based on the vcpu->runstate.time(running/runnable/block/offline) >>> changes, to determine how much time the process on this VCPU is >>> running, instead of just "delta_exec = now - exec_start"; >>> >>> 2) Build another clock inside the guest OS which records the exect >>> time that the VCPU runs. All vruntime calculation is based on this >>> clock, instead of hyperivosr clock/time(real clock). >> >> Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting process >> times. KVM uses it but Xen doesn't. > > Is someone on the Linux side going to put this on their to-do list then? :-) Patch sent. Support was already existing for arm. What is missing is support for paravirt_steal_rq_enabled which requires to be able to read the stolen time of another cpu. This can't work today as accessing another cpu's vcpu_runstate_info isn't possible without risking inconsistent data. I plan to add support for this, too, but this will require adding another hypercall to map a modified vcpu_runstate_info containing an indicator for an ongoing update of the data. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing baseline-only test] 44426: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 44426 xen-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44426/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 4 capture-logs !broken [st=!broken!] build-armhf 4 capture-logs !broken [st=!broken!] test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail REGR. vs. 44413 Regressions which are regarded as allowable (not blocking): build-armhf-pvops 3 host-install(3) broken like 44413 build-armhf 3 host-install(3) broken like 44413 test-amd64-amd64-xl 19 guest-start/debian.repeatfail like 44413 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 44413 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 44413 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 44413 test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail like 44413 Tests which did not succeed, but are not blocking: build-armhf-libvirt 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-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-midway1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a build-i386-rumpuserxen6 xen-buildfail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: xen 09f9f792b5af8023c95e445aeba94cb9bffcc45f baseline version: xen ab6f8993136a10fee4336e0cbb90f491ce505212 Last test of basis44413 2016-05-13 17:17:58 Z4 days Testing same since44426 2016-05-18 05:50:14 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-amd64-xend pass build-i386-xend pass build-amd64 pass build-armhf broken build-i386 pass build-amd64-libvirt pass build-armhf-libvirt blocked build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopsbroken build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl fail test-armhf-armhf-xl blocked test-amd64-i386-xl pass test-amd64-amd64-qemuu-nested-amdfail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64
Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation
On May 17, 2016 3:48 PM, Jan Beulich wrote: > >>> On 17.05.16 at 05:19, wrote: > >> From: Xu, Quan > >> Sent: Monday, May 16, 2016 11:26 PM > >> > >> On May 13, 2016 11:28 PM, Jan Beulich wrote: > >> > >>> On 22.04.16 at 12:54, wrote: > >> > > --- a/docs/misc/xen-command-line.markdown > >> > > +++ b/docs/misc/xen-command-line.markdown > >> > > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also > >> > specified vpmu will be turned off. > >> > > As the virtualisation is not 100% safe, don't use the vpmu flag > >> > > on production systems (see http://xenbits.xen.org/xsa/advisory- > 163.html)! > >> > > > >> > > +### vtd\_qi\_timeout (VT-d) > >> > > +> `= ` > >> > > + > >> > > +> Default: `1` > >> > > + > >> > > +Specify the timeout of the VT-d Queued Invalidation in milliseconds. > >> > > + > >> > > +By default, the timeout is 1ms. When you see error 'Queue > >> > > +invalidate wait descriptor timed out', try increasing this value. > >> > > >> > So when someone enables ATS, will the 1ms timeout apply to the dev > >> > iotlb invalidations too? > >> > >> Yes, > >> The timeout is the same for IOTLB, Context, IEC and Device-TLB > >> invalidation. > >> > >> > If so, that's surely too short, and would ideally be adjusted > >> > automatically, but the need for a higher timeout in that case > >> > should in any event be mentioned here. > >> > >> I can try to use 1ms for IOTLB, Context and IEC invalidation. As > >> mentioned, 1 ms is enough for IOTLB, Context and IEC invalidation. > >> What about 10 ms for Device-TLB (10 ms is just a higher timeout, no > specific meaning)? > > > > I remember in earlier discussion we agreed to use 1ms as the default > > for both IOMMU-side and device-side flushes. For device-side flushes, > > we checked internal HW team that 1ms is a reasonable threshold for > > integrated devices. It's likely insufficient for discrete devices. We > > may check any automatic adjustment method later when it becomes a real > > problem. For now, please elaborate above information in the text. > > Well, taking care of automation later is fine with me, > but tying everything to a > single timeout, when device iotlb invalidation may require a much larger > value, > isn't. > A little bit confused. Check it -- could I leave patch 1/3 as is? btw, I have tested it against the last commit, no conflict. Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 94547: tolerable all pass - PUSHED
flight 94547 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94547/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 1542efcea893df874b13b1ea78101e1ff6a55c41
baseline version:
xen c32381352cce9744e640bf239d2704dae4af4fc7
Last test of basis94529 2016-05-17 19:02:33 Z0 days
Testing same since94547 2016-05-18 11:02:48 Z0 days1 attempts
People who touched revisions under test:
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=1542efcea893df874b13b1ea78101e1ff6a55c41
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
1542efcea893df874b13b1ea78101e1ff6a55c41
+ branch=xen-unstable-smoke
+ revision=1542efcea893df874b13b1ea78101e1ff6a55c41
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x1542efcea893df874b13b1ea78101e1ff6a55c41 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/
Re: [Xen-devel] [PATCH v10 3/3] vt-d: fix vt-d Device-TLB flush timeout issue
On May 17, 2016 10:00 PM, Jan Beulich wrote:
> >>> On 22.04.16 at 12:54, wrote:
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -206,10 +206,71 @@ static int invalidate_sync(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 = NULL;
> > +struct pci_dev *pdev;
> > +
> > +if ( test_bit(did, iommu->domid_bitmap) )
> > +d = rcu_lock_domain_by_id(iommu->domid_map[did]);
> > +
> > +/*
> > + * In case the domain has been freed or the IOMMU domid bitmap is
> > + * not valid, the device no longer belongs to this domain.
> > + */
> > +if ( d == NULL )
> > +return;
> > +
> > +pcidevs_lock();
> > +
> > +for_each_pdev(d, pdev)
> > +{
> > +if ( (pdev->seg == seg) &&
> > + (pdev->bus == bus) &&
> > + (pdev->devfn == devfn) )
> > +{
> > +ASSERT(pdev->domain);
> > +list_del(&pdev->domain_list);
> > +pdev->domain = NULL;
> > +pci_hide_existing_device(pdev);
> > +break;
> > +}
> > +}
>
> A loop like this is of course not ideal (especially for Dom0, which may have
> many devices). And I wonder why you, ...
>
> > @@ -134,8 +133,9 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16
> did,
> > /* invalidate all translations: sbit=1,bit_63=0,bit[62:12]=1 */
> > sbit = 1;
> > addr = (~0UL << PAGE_SHIFT_4K) & 0x7FFF;
> > -rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth,
> > - sid, sbit, addr);
> > +rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth,
> > did,
> > + pdev->seg, pdev->bus,
> > pdev->devfn,
> > + sbit, addr);
> > break;
> > case DMA_TLB_PSI_FLUSH:
> > if ( !device_in_domain(iommu, pdev, did) ) @@ -154,8
> > +154,9 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
> > addr |= (((u64)1 << (size_order - 1)) - 1) <<
> > PAGE_SHIFT_4K;
> > }
> >
> > -rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth,
> > - sid, sbit, addr);
> > +rc = qinval_device_iotlb_sync(iommu, pdev->ats_queue_depth,
> > did,
> > + pdev->seg, pdev->bus,
> > pdev->devfn,
> > + sbit, addr);
> > break;
>
> ... holding pdev in your hands here, don't just pass it down (which at once
> would make the function signature less convoluted: you could even eliminate
> the currently 2nd parameter that way).
>
Good idea!!
Quan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
On Wed, May 18, 2016 at 3:48 AM, Wei Liu wrote: > On Tue, May 17, 2016 at 08:05:23PM +0800, Big Strong wrote: >> Is there a libxc function to translate the >> virtual address of malloc() to physical address? > > Only to answer this question: no. There isn't one. > > Wei. Technically there is! The function xc_translate_foreign_address can be used to translate in-guest virtual addresses to physical, works for both PV and HVM guests. AFAIK a tool on dom0 can run it on itself. Never tried it that way though. Cheers, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
On Wed, May 18, 2016 at 07:14:23AM -0600, Tamas K Lengyel wrote: > On Wed, May 18, 2016 at 3:48 AM, Wei Liu wrote: > > On Tue, May 17, 2016 at 08:05:23PM +0800, Big Strong wrote: > >> Is there a libxc function to translate the > >> virtual address of malloc() to physical address? > > > > Only to answer this question: no. There isn't one. > > > > Wei. > > Technically there is! The function xc_translate_foreign_address can be > used to translate in-guest virtual addresses to physical, works for > both PV and HVM guests. AFAIK a tool on dom0 can run it on itself. > Never tried it that way though. > Right. I missed that one. Thanks for correction. Wei. > Cheers, > Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.7] tools: bump library version numbers
The following libraries are checked: 1. libxc, version number bumped 2. libxl, version number bumped 3. libxlu, no development in 4.7 cycle, version number not bumped 4. libs/*, new in 4.7 cycle, version number not bumped 5. libxenstore, no development in 4.7 cycle, version number not bumped 6. libxenstat, no development in 4.7 cycle, version number not bumped 7. libvchan, depends on xengnttab library, API changed, version number bumped Signed-off-by: Wei Liu --- Cc: Ian Jackson --- tools/libvchan/Makefile | 2 +- tools/libxc/Makefile| 2 +- tools/libxl/Makefile| 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile index 0573d2f..6d1a724 100644 --- a/tools/libvchan/Makefile +++ b/tools/libvchan/Makefile @@ -14,7 +14,7 @@ LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxengnttab) $(LDLIBS_libxengnts $(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) $(CFLAGS_libxengnttab) $(CFLAGS_libxengntshr) $(CFLAGS_libxenevtchn) $(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxengnttab) $(CFLAGS_libxengntshr) $(CFLAGS_libxenevtchn) -MAJOR = 1.0 +MAJOR = 4.7 MINOR = 0 CFLAGS += -I../include -I. diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile index ef02c9d..05264c7 100644 --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -1,7 +1,7 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk -MAJOR= 4.6 +MAJOR= 4.7 MINOR= 0 ifeq ($(CONFIG_LIBXC_MINIOS),y) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 4fc264d..defeb40 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -5,10 +5,10 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk -MAJOR = 4.6 +MAJOR = 4.7 MINOR = 0 -XLUMAJOR = 4.6 +XLUMAJOR = 4.7 XLUMINOR = 0 CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.7] tools: bump library version numbers
On Wed, May 18, 2016 at 02:32:15PM +0100, Wei Liu wrote: > The following libraries are checked: > 1. libxc, version number bumped > 2. libxl, version number bumped > 3. libxlu, no development in 4.7 cycle, version number not bumped > 4. libs/*, new in 4.7 cycle, version number not bumped > 5. libxenstore, no development in 4.7 cycle, version number not bumped > 6. libxenstat, no development in 4.7 cycle, version number not bumped > 7. libvchan, depends on xengnttab library, API changed, version number >bumped > > Signed-off-by: Wei Liu Please ignore this version. The commit message is wrong. Hit "send" too fast, sorry. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] tools: bump library version numbers
The following libraries are checked: 1. libxc, version number bumped 2. libxl, version number bumped 3. libxlu, no development in 4.7 cycle, but depends on libxl, version number bumped 4. libs/*, new in 4.7 cycle, version numbers not bumped 5. libxenstore, no development in 4.7 cycle, version number not bumped 6. libxenstat, no development in 4.7 cycle, version number not bumped 7. libvchan, depends on xengnttab library, API changed, version number bumped Signed-off-by: Wei Liu --- Cc: Ian Jackson --- tools/libvchan/Makefile | 2 +- tools/libxc/Makefile| 2 +- tools/libxl/Makefile| 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile index 0573d2f..6d1a724 100644 --- a/tools/libvchan/Makefile +++ b/tools/libvchan/Makefile @@ -14,7 +14,7 @@ LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxengnttab) $(LDLIBS_libxengnts $(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore) $(CFLAGS_libxengnttab) $(CFLAGS_libxengntshr) $(CFLAGS_libxenevtchn) $(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxengnttab) $(CFLAGS_libxengntshr) $(CFLAGS_libxenevtchn) -MAJOR = 1.0 +MAJOR = 4.7 MINOR = 0 CFLAGS += -I../include -I. diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile index ef02c9d..05264c7 100644 --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -1,7 +1,7 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk -MAJOR= 4.6 +MAJOR= 4.7 MINOR= 0 ifeq ($(CONFIG_LIBXC_MINIOS),y) diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index 4fc264d..defeb40 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -5,10 +5,10 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk -MAJOR = 4.6 +MAJOR = 4.7 MINOR = 0 -XLUMAJOR = 4.6 +XLUMAJOR = 4.7 XLUMINOR = 0 CFLAGS += -Werror -Wno-format-zero-length -Wmissing-declarations \ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker
On Fri, May 13, 2016 at 6:25 PM, Andrew Cooper wrote: > hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a > general L1 p2m walk. It is fine for AMD as NPT share the same format as > normal pagetables. For Intel EPT however, it is wrong. > > The translation ends up correct (as the formats are sufficiently similar), but > the control bits in lower 12 bits differ in meaning. A plain PT walker sets > A/D bits (bits 5 and 6) as it walks, but in EPT tables, these are the IPAT and > top bit of EMT (caching type). This in turn causes problem when the EPT > tables are subsequently used. > > Replace hostmode->p2m_ga_to_gfn() with nestedhap_walk_L1_p2m() in > paging_gva_to_gfn(), which is the correct function for the task. This > involves making nestedhap_walk_L1_p2m() non-static, and adding > vmx_vmcs_enter/exit() pairs to nvmx_hap_walk_L1_p2m() as it is now reachable > from contexts other than v == current. > > Signed-off-by: Andrew Cooper Acked-by: George Dunlap ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.7] xen/nested_p2m: Don't walk EPT tables with a regular PT walker
On Fri, May 13, 2016 at 06:25:41PM +0100, Andrew Cooper wrote: > hostmode->p2m_ga_to_gfn() is a plain PT walker, and is not appropriate for a > general L1 p2m walk. It is fine for AMD as NPT share the same format as > normal pagetables. For Intel EPT however, it is wrong. > > The translation ends up correct (as the formats are sufficiently similar), but > the control bits in lower 12 bits differ in meaning. A plain PT walker sets > A/D bits (bits 5 and 6) as it walks, but in EPT tables, these are the IPAT and > top bit of EMT (caching type). This in turn causes problem when the EPT > tables are subsequently used. > > Replace hostmode->p2m_ga_to_gfn() with nestedhap_walk_L1_p2m() in > paging_gva_to_gfn(), which is the correct function for the task. This > involves making nestedhap_walk_L1_p2m() non-static, and adding > vmx_vmcs_enter/exit() pairs to nvmx_hap_walk_L1_p2m() as it is now reachable > from contexts other than v == current. > > Signed-off-by: Andrew Cooper Release-acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Saving a guest crashes dom0
Saving a guest (xl save) crashes dom0, log below. Paul, this seems to be happening in the code that you modified recently. If you don't have time I can look at this but it will probably have to wait until tomorrow. -boris [ 176.347760] BUG: unable to handle kernel NULL pointer dereference at 0008 [ 176.347780] IP: [] xenvif_flush_hash+0x6f/0xd0 [ 176.347791] PGD 563f067 PUD 54b1067 PMD 0 [ 176.347798] Oops: [#1] SMP [ 176.347803] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod ahci libahci libata scsi_mod i915 e1000e video backlight wmi tpm_tis xen_blkfront xen_netfront xenfs xen_privcmd [ 176.347840] CPU: 1 PID: 26 Comm: xenwatch Not tainted 4.6.0upstream-03623-g0b7962a-dirty #1 [ 176.347845] Hardware name: LENOVO ThinkServer TS130/, BIOS 9HKT47AUS 01/10/2012 [ 176.347850] task: 880037e22140 ti: 880037e4 task.ti: 880037e4 [ 176.347855] RIP: e030:[] [] xenvif_flush_hash+0x6f/0xd0 [ 176.347862] RSP: e02b:880037e43cb8 EFLAGS: 00010017 [ 176.347866] RAX: 880006190250 RBX: 88000619f840 RCX: [ 176.347870] RDX: 0001 RSI: 81215ce0 RDI: 88000619fad0 [ 176.347875] RBP: 880037e43d28 R08: 0040 R09: 0040 [ 176.347879] R10: 0040 R11: 0001 R12: 88000619fad0 [ 176.347883] R13: R14: 88000619fad8 R15: 880037e43cd8 [ 176.347892] FS: 7f3fa46cb710() GS:88003de8() knlGS: [ 176.347927] CS: e033 DS: ES: CR0: 80050033 [ 176.347930] CR2: 0008 CR3: 06cad000 CR4: 00042660 [ 176.347935] Stack: [ 176.347939] 003e 880006190250 0002 0006c560 [ 176.347946] 88000619f850 0002 81476f4e [ 176.347952] 880037e43d18 88000619f840 0006 0040 [ 176.347959] Call Trace: [ 176.347963] [] ? xenbus_unmap_ring_vfree+0xe/0x10 [ 176.347968] [] xenvif_deinit_hash+0x9/0x10 [ 176.347973] [] xenvif_disconnect_ctrl+0x3d/0xb0 [ 176.347977] [] set_backend_state+0x13c/0x200 [ 176.347982] [] frontend_changed+0x77/0xe0 [ 176.347987] [] xenbus_otherend_changed+0x9d/0xa0 [ 176.347993] [] frontend_changed+0xb/0x10 [ 176.347997] [] xenwatch_thread+0xc8/0x190 [ 176.348002] [] ? woken_wake_function+0x10/0x10 [ 176.348008] [] ? schedule+0x42/0xb0 [ 176.348013] [] ? _raw_spin_unlock_irqrestore+0x15/0x20 [ 176.348017] [] ? join+0x60/0x60 [ 176.348022] [] kthread+0xd2/0xf0 [ 176.348027] [] ? finish_task_switch+0x91/0x220 [ 176.348032] [] ? schedule_tail+0x19/0xd0 [ 176.348036] [] ret_from_fork+0x1f/0x40 [ 176.348041] [] ? kthread_freezable_should_stop+0x80/0x80 [ 176.348045] Code: 90 02 00 00 4c 8d b3 98 02 00 00 4c 89 e7 e8 59 03 22 00 4c 8b ab 98 02 00 00 48 89 45 98 4d 39 f5 4c 89 6d c0 74 48 4c 8d 7d b0 <49> 8b 55 08 49 8b 45 00 48 bf 00 02 00 00 00 00 ad de 48 c7 c6 [ 176.348095] RIP [] xenvif_flush_hash+0x6f/0xd0 [ 176.348101] RSP [ 176.348103] CR2: 0008 [ 176.348108] ---[ end trace b58563dcb1aec61c ]--- [ 176.348111] Kernel panic - not syncing: Fatal exception [ 176.348117] Kernel Offset: disabled (XEN) [2016-05-18 13:06:05] Hardware Dom0 crashed: rebooting machine in 5 seconds. (XEN) [2016-05-18 13:06:10] Resetting with ACPI MEMORY or I/O RESET_REG. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [seabios baseline-only test] 44429: tolerable FAIL
This run is configured for baseline tests only. flight 44429 seabios real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44429/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 44361 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 44361 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: seabios 1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98 baseline version: seabios c8e105a4d5e52e8e7539ab1f2cd07ebe0ae9033a Last test of basis44361 2016-04-24 01:21:29 Z 24 days Testing same since44429 2016-05-18 09:54:18 Z0 days1 attempts People who touched revisions under test: Kevin O'Connor Paul Menzel jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-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-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 1dc77745774ff7ba95a0c4dc8eb2299a6cde4d98 Author: Kevin O'Connor Date: Mon May 16 20:51:17 2016 -0400 tcgbios: Remove unused const variable Remove the unused array `PhysicalPresence_CMD_DISABLE` to fix GCC 6 warnings. Signed-off-by: Paul Menzel Signed-off-by: Kevin O'Connor commit 0024cd77f88a38036a228fb885217ff06e97464c Author: Kevin O'Connor Date: Mon May 16 20:50:28 2016 -0400 usb-xhci: Remove unused const variables Remove the unused arrays `eptype_to_xhci_in` and `eptype_to_xhci_out` to fix GCC 6 warnings. Signed-off-by: Paul Menzel Signed-off-by: Kevin O'Connor ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Saving a guest crashes dom0
> -Original Message- > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > Sent: 18 May 2016 14:54 > To: xen-devel; Paul Durrant > Subject: Saving a guest crashes dom0 > > Saving a guest (xl save) crashes dom0, log below. > > Paul, this seems to be happening in the code that you modified > recently. If you don't have time I can look at this but it will > probably have to wait until tomorrow. > No, this looks problematic, I'll look now... What was the guest? Paul > > -boris > > > [ 176.347760] BUG: unable to handle kernel NULL pointer dereference at > 0008 > [ 176.347780] IP: [] xenvif_flush_hash+0x6f/0xd0 > [ 176.347791] PGD 563f067 PUD 54b1067 PMD 0 > [ 176.347798] Oops: [#1] SMP > [ 176.347803] Modules linked in: dm_multipath dm_mod xen_evtchn > iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi > libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod ahci > libahci libata scsi_mod i915 e1000e video backlight wmi tpm_tis > xen_blkfront xen_netfront xenfs xen_privcmd > [ 176.347840] CPU: 1 PID: 26 Comm: xenwatch Not tainted > 4.6.0upstream-03623-g0b7962a-dirty #1 > [ 176.347845] Hardware name: LENOVO ThinkServer TS130/, BIOS > 9HKT47AUS 01/10/2012 > [ 176.347850] task: 880037e22140 ti: 880037e4 task.ti: > 880037e4 > [ 176.347855] RIP: e030:[] [] > xenvif_flush_hash+0x6f/0xd0 > [ 176.347862] RSP: e02b:880037e43cb8 EFLAGS: 00010017 > [ 176.347866] RAX: 880006190250 RBX: 88000619f840 RCX: > > [ 176.347870] RDX: 0001 RSI: 81215ce0 RDI: > 88000619fad0 > [ 176.347875] RBP: 880037e43d28 R08: 0040 R09: > 0040 > [ 176.347879] R10: 0040 R11: 0001 R12: > 88000619fad0 > [ 176.347883] R13: R14: 88000619fad8 R15: > 880037e43cd8 > [ 176.347892] FS: 7f3fa46cb710() GS:88003de8() > knlGS: > [ 176.347927] CS: e033 DS: ES: CR0: 80050033 > [ 176.347930] CR2: 0008 CR3: 06cad000 CR4: > 00042660 > [ 176.347935] Stack: > [ 176.347939] 003e 880006190250 0002 > 0006c560 > [ 176.347946] 88000619f850 0002 > 81476f4e > [ 176.347952] 880037e43d18 88000619f840 0006 > 0040 > [ 176.347959] Call Trace: > [ 176.347963] [] ? xenbus_unmap_ring_vfree+0xe/0x10 > [ 176.347968] [] xenvif_deinit_hash+0x9/0x10 > [ 176.347973] [] xenvif_disconnect_ctrl+0x3d/0xb0 > [ 176.347977] [] set_backend_state+0x13c/0x200 > [ 176.347982] [] frontend_changed+0x77/0xe0 > [ 176.347987] [] xenbus_otherend_changed+0x9d/0xa0 > [ 176.347993] [] frontend_changed+0xb/0x10 > [ 176.347997] [] xenwatch_thread+0xc8/0x190 > [ 176.348002] [] ? woken_wake_function+0x10/0x10 > [ 176.348008] [] ? schedule+0x42/0xb0 > [ 176.348013] [] ? > _raw_spin_unlock_irqrestore+0x15/0x20 > [ 176.348017] [] ? join+0x60/0x60 > [ 176.348022] [] kthread+0xd2/0xf0 > [ 176.348027] [] ? finish_task_switch+0x91/0x220 > [ 176.348032] [] ? schedule_tail+0x19/0xd0 > [ 176.348036] [] ret_from_fork+0x1f/0x40 > [ 176.348041] [] ? > kthread_freezable_should_stop+0x80/0x80 > [ 176.348045] Code: 90 02 00 00 4c 8d b3 98 02 00 00 4c 89 e7 e8 59 03 > 22 00 4c 8b ab 98 02 00 00 48 89 45 98 4d 39 f5 4c 89 6d c0 74 48 4c 8d > 7d b0 <49> 8b 55 08 49 8b 45 00 48 bf 00 02 00 00 00 00 ad de 48 c7 c6 > [ 176.348095] RIP [] xenvif_flush_hash+0x6f/0xd0 > [ 176.348101] RSP > [ 176.348103] CR2: 0008 > [ 176.348108] ---[ end trace b58563dcb1aec61c ]--- > [ 176.348111] Kernel panic - not syncing: Fatal exception > [ 176.348117] Kernel Offset: disabled > (XEN) [2016-05-18 13:06:05] Hardware Dom0 crashed: rebooting machine in > 5 seconds. > (XEN) [2016-05-18 13:06:10] Resetting with ACPI MEMORY or I/O RESET_REG. > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Saving a guest crashes dom0
> -Original Message- > From: Paul Durrant > Sent: 18 May 2016 15:18 > To: 'Boris Ostrovsky'; xen-devel > Subject: RE: Saving a guest crashes dom0 > > > -Original Message- > > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com] > > Sent: 18 May 2016 14:54 > > To: xen-devel; Paul Durrant > > Subject: Saving a guest crashes dom0 > > > > Saving a guest (xl save) crashes dom0, log below. > > > > Paul, this seems to be happening in the code that you modified > > recently. If you don't have time I can look at this but it will > > probably have to wait until tomorrow. > > > > No, this looks problematic, I'll look now... What was the guest? > Never mind. I see the problem. Disconnection of the control ring is done regardless of whether a control ring was connected and the hash deinit is not adequately protected. I'll come up with a patch. Paul > Paul > > > > > -boris > > > > > > [ 176.347760] BUG: unable to handle kernel NULL pointer dereference at > > 0008 > > [ 176.347780] IP: [] xenvif_flush_hash+0x6f/0xd0 > > [ 176.347791] PGD 563f067 PUD 54b1067 PMD 0 > > [ 176.347798] Oops: [#1] SMP > > [ 176.347803] Modules linked in: dm_multipath dm_mod xen_evtchn > > iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi > > libcrc32c crc32c_generic crc32c_intel sg sr_mod cdrom sd_mod ahci > > libahci libata scsi_mod i915 e1000e video backlight wmi tpm_tis > > xen_blkfront xen_netfront xenfs xen_privcmd > > [ 176.347840] CPU: 1 PID: 26 Comm: xenwatch Not tainted > > 4.6.0upstream-03623-g0b7962a-dirty #1 > > [ 176.347845] Hardware name: LENOVO ThinkServer TS130/, BIOS > > 9HKT47AUS 01/10/2012 > > [ 176.347850] task: 880037e22140 ti: 880037e4 task.ti: > > 880037e4 > > [ 176.347855] RIP: e030:[] [] > > xenvif_flush_hash+0x6f/0xd0 > > [ 176.347862] RSP: e02b:880037e43cb8 EFLAGS: 00010017 > > [ 176.347866] RAX: 880006190250 RBX: 88000619f840 RCX: > > > > [ 176.347870] RDX: 0001 RSI: 81215ce0 RDI: > > 88000619fad0 > > [ 176.347875] RBP: 880037e43d28 R08: 0040 R09: > > 0040 > > [ 176.347879] R10: 0040 R11: 0001 R12: > > 88000619fad0 > > [ 176.347883] R13: R14: 88000619fad8 R15: > > 880037e43cd8 > > [ 176.347892] FS: 7f3fa46cb710() GS:88003de8() > > knlGS: > > [ 176.347927] CS: e033 DS: ES: CR0: 80050033 > > [ 176.347930] CR2: 0008 CR3: 06cad000 CR4: > > 00042660 > > [ 176.347935] Stack: > > [ 176.347939] 003e 880006190250 0002 > > 0006c560 > > [ 176.347946] 88000619f850 0002 > > 81476f4e > > [ 176.347952] 880037e43d18 88000619f840 0006 > > 0040 > > [ 176.347959] Call Trace: > > [ 176.347963] [] ? xenbus_unmap_ring_vfree+0xe/0x10 > > [ 176.347968] [] xenvif_deinit_hash+0x9/0x10 > > [ 176.347973] [] xenvif_disconnect_ctrl+0x3d/0xb0 > > [ 176.347977] [] set_backend_state+0x13c/0x200 > > [ 176.347982] [] frontend_changed+0x77/0xe0 > > [ 176.347987] [] xenbus_otherend_changed+0x9d/0xa0 > > [ 176.347993] [] frontend_changed+0xb/0x10 > > [ 176.347997] [] xenwatch_thread+0xc8/0x190 > > [ 176.348002] [] ? woken_wake_function+0x10/0x10 > > [ 176.348008] [] ? schedule+0x42/0xb0 > > [ 176.348013] [] ? > > _raw_spin_unlock_irqrestore+0x15/0x20 > > [ 176.348017] [] ? join+0x60/0x60 > > [ 176.348022] [] kthread+0xd2/0xf0 > > [ 176.348027] [] ? finish_task_switch+0x91/0x220 > > [ 176.348032] [] ? schedule_tail+0x19/0xd0 > > [ 176.348036] [] ret_from_fork+0x1f/0x40 > > [ 176.348041] [] ? > > kthread_freezable_should_stop+0x80/0x80 > > [ 176.348045] Code: 90 02 00 00 4c 8d b3 98 02 00 00 4c 89 e7 e8 59 03 > > 22 00 4c 8b ab 98 02 00 00 48 89 45 98 4d 39 f5 4c 89 6d c0 74 48 4c 8d > > 7d b0 <49> 8b 55 08 49 8b 45 00 48 bf 00 02 00 00 00 00 ad de 48 c7 c6 > > [ 176.348095] RIP [] xenvif_flush_hash+0x6f/0xd0 > > [ 176.348101] RSP > > [ 176.348103] CR2: 0008 > > [ 176.348108] ---[ end trace b58563dcb1aec61c ]--- > > [ 176.348111] Kernel panic - not syncing: Fatal exception > > [ 176.348117] Kernel Offset: disabled > > (XEN) [2016-05-18 13:06:05] Hardware Dom0 crashed: rebooting machine in > > 5 seconds. > > (XEN) [2016-05-18 13:06:10] Resetting with ACPI MEMORY or I/O > RESET_REG. > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 94530: regressions - FAIL
flight 94530 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/94530/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-xsm 7 host-ping-check-xen fail REGR. vs. 94506 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 94506 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 94506 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94506 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-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl 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-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-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-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-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-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 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 version targeted for testing: qemuua257c741491ff1c3c192d13a89c136dd6401c54d baseline version: qemuuc98e7937119503d06dbb494b7e4806ec66a27df0 Last test of basis94506 2016-05-17 09:48:40 Z1 days Testing same since94530 2016-05-17 23:10:46 Z0 days1 attempts People who touched revisions under test: Alexander Yarygin Changlong Xie Christian Borntraeger Cornelia Huck Fan Zhang Hollis Blanchard Peter Maydell Stefan Hajnoczi xiaoqiang zhao Yi Min Zhao jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm
Re: [Xen-devel] Saving a guest crashes dom0
> > -Original Message-
> > From: Paul Durrant
> > Sent: 18 May 2016 15:18
> > To: 'Boris Ostrovsky'; xen-devel
> > Subject: RE: Saving a guest crashes dom0
> >
> > > -Original Message-
> > > From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> > > Sent: 18 May 2016 14:54
> > > To: xen-devel; Paul Durrant
> > > Subject: Saving a guest crashes dom0
> > >
> > > Saving a guest (xl save) crashes dom0, log below.
> > >
> > > Paul, this seems to be happening in the code that you modified
> > > recently. If you don't have time I can look at this but it will
> > > probably have to wait until tomorrow.
> > >
> >
> > No, this looks problematic, I'll look now... What was the guest?
> >
>
> Never mind. I see the problem. Disconnection of the control ring is done
> regardless of whether a control ring was connected and the hash deinit is not
> adequately protected. I'll come up with a patch.
>
This should fix the problem for you:
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 1c7f49b..83deeeb 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
vif->ctrl_task = NULL;
}
- xenvif_deinit_hash(vif);
-
if (vif->ctrl_irq) {
+ xenvif_deinit_hash(vif);
unbind_from_irqhandler(vif->ctrl_irq, vif);
vif->ctrl_irq = 0;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] Tmem cleanups for 4.7 (hopefully?).
On Tue, May 17, 2016 at 09:11:16PM -0500, Doug Goldstein wrote: > On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote: > > Hey, > > > > These four little cleanups move the bulk of tmem control ops > > from tmem.c to tmem_control.c. > > > > Last release I moved the control tmem ops from being part of tmem > > hypercall to be part of the syscall subops - and this is the next > > step in this cleanup. (See > > http://lists.xen.org/archives/html/xen-devel/2015-10/msg03313.html) > > which will allow me to follow up on the other steps: > > b) Fix the toolstack (cleanup) > > c) tmem tze, dedup, and zlib code drop > > > > Anyhow sorry for this being so tardy - xSplice had more attention :-) > > > > Regression tests show no problems. > > > > The patches themselves have no functionality changes thought I was itching > > to remove most of the counters. I will do that going forward, but need > > to figure out which ones make sense or if some of them can be coalesced. > > > > xen/common/Makefile| 2 +- > > xen/common/tmem.c | 618 > > + > > xen/common/tmem_control.c | 443 + > > xen/include/xen/tmem_control.h | 33 +++ > > xen/include/xen/tmem_xen.h | 128 + > > 5 files changed, 672 insertions(+), 552 deletions(-) > > > > Konrad Rzeszutek Wilk (4): > > tmem: Move global stats in a tmem_statistics structure > > tmem: Wrap atomic_t in struct tmem_statistics as well. > > tmem: Move global_ individual variables in a global structure. > > tmem: Move bulk of tmem control functions in its own file. > > > > > > ___ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > > > > So overall applying all 4 patches results in something that I think is > better. I think some improvement on the bisect-ability of the patches > and I'll toss my Reviewed-by: Doug Goldstein on the > series. The bisection-ability is there. Each individual patch compiles just fine (double-checking that right now). Thanks! ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-qemu-trad] Fix build with newer version of GNUTLS
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [PATCH for-qemu-trad] Fix build
with newer version of GNUTLS"):
> On Thu, May 05, 2016 at 11:14:44AM +0100, Wei Liu wrote:
> > Provide compatibility layer for QEMU traditional. This commit is in fact
> > backport of two upstream QEMU commits:
> > 1. f40d55081667a716312b9a8b6e13835c4074f56b
> > 2. 7d2a929feba319c18603e324b1750830d6c8b7a1
...
> > Signed-off-by: Sjoer van der Ploeg
> > Signed-off-by: Wei Liu
>
> Tested-by: Konrad Rzeszutek Wilk
>
> on
> gnutls-3.4.9-1.fc23.x86_64
>
> And it fixes the build problems.
Thanks to everyone. I have applied this to my local tree and queued
it for push. I have also queued it for backport.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] state of xenified SUSE kernel
On 17.05.2016 17:34, Jan Beulich wrote: We use xenified kernels based on kernel 3.4 for years and benchmarks showed that they are faster than the pvops (vanilla) kernels. But what is the current state in terms of performance and features? I'm not sure what you expect here. Up to openSUSE 42.1 and SLE 12 SP1 they are fully maintained, i.e. you can get quite a bit newer than 3.4 based kernels. There's not a lot of performance analysis that I would be aware of, so I can't answer that part anyway. And them being release branches rather than development ones, there's not going to be any new feature work. As far as I know the patches are based on the original work for kernel 2.6.18 and have not been adjusted to major changes in Xen architecture. So what I am thinking about is performance improvements that result from using newer Xen features. So the question was: from an architectural point of view should pvops in recent vanilla kernels be "better" then xenified kernels? Regards Andreas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max
Nice implementation. I tested it and it fixes the problem on the affected system. Just a minor typo in a comment: "it's duty" should be "its duty". --Ed On Wed, May 18, 2016 at 4:44 AM, Juergen Gross wrote: > On 17/05/16 22:50, Ed Swierk wrote: > > I added some more instrumentation and discovered that the result of > > xen_count_remap_pages() (0x85dea) is one less than the actual number > > of pages remapped by xen_set_identity_and_remap() (0x85deb). > > > > The two functions differ in their handling of a xen_e820_map entry > > whose size is not a multiple of the page size. The entry starting at > > 0x68000 has size 0x33400. xen_count_remap_pages() rounds up when > > computing the end_pfn (to 0x9c), while xen_set_identity_and_remap() > > rounds down (to 0x9b). Thus xen_count_remap_pages() counts the > > remapped space following the entry as one page smaller than the other > > function does. > > Could you please test the attached patch? It follows your idea of the > combined function, but is using a function pointer instead of a flag. > The patch is based on 4.6, but I believe it should just work on 4.4. > > > Juergen > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 2nd opinion on backportability of c35eefded2
On 13/05/16 10:32, Jan Beulich wrote:
> Hi George,
>
> after quite a bit of debugging on 4.6.1 I learned that said commit
> ("x86/P2M: consolidate handling of types not requiring a valid MFN")
> is more than just cleanup: Since p2m_set_entry() happily performs
> arithmetic on the passed in MFN, shadow mode guests (verified) as
> well as HAP ones when 1Gb / 2Mb mappings are unavailable (not
> verified), if any of the MFNs below 1Gb are invalid (reported with
> e.g. "crashkernel=512M@16M"), p2m_pt_set_entry() would (in
> the context of guest_physmap_mark_populate_on_demand())
> produce invalid instead of PoD entries, resulting in subsequent
> attempts by the guest to use (e.g. balloon out) these pages to
> fail (the balloon failure results in a crash during boot).
I'm sorry, I'm having some trouble parsing this paragraph. :-)
But this is what I gather:
Before c35eefded2, the 4k-entry path didn't check whether the p2m entry
was PoD, it only checked that the mfn was valid. The pod code would
always set this mfn to 0, which is (usually) valid; but p2m_set_entry()
might iterate over this, ending up in p2m_pt_set_entry() with non-zero
low values for mfn. In certain circumstances these low-value mfns might
actually be invalid (for example, if they overlap a crash kernel).
In such a case, the resulting p2m entries would be (erroneously) marked
as invalid rather than PoD, resulting in a crash when the guest tried to
access it or populate it.
You observed this happening in the shadow case, and believe it would
happen if p2m 2MiB or 1GiB pages were disabled but haven't checked those
cases.
c35eefded2 fixes this by implicitly checking for the PoD type on the 4k
entry path.
> Now, while the backport to 4.6 is straightforward, I'm having the
> vague feeling that this change might depend on some earlier one,
> but I can't pinpoint anything. Hence I would appreciate if you
> could take a look and provide your judgment.
We talked about the PoD type thing in the context of a discussion about
660fd65 ("x86/p2m-pt: tighten conditions of IOMMU mapping updates") --
discussion here [1]. But it doesn't look like that's a prerequisite,
and nothing else really comes to mind.
-George
[1] marc.info/?i=<560d261d0278000a7...@prv-mh.provo.novell.com>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: use same main loop for counting and remapping pages
Instead of having two functions for cycling through the E820 map in
order to count to be remapped pages and remap them later, just use one
function with a caller supplied sub-function called for each region to
be processed. This eliminates the possibility of a mismatch between
both loops which showed up in certain configurations.
Suggested-by: Ed Swierk
Signed-off-by: Juergen Gross
---
arch/x86/xen/setup.c | 65 +---
1 file changed, 26 insertions(+), 39 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 7ab2951..e345891 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -393,6 +393,9 @@ static unsigned long __init
xen_set_identity_and_remap_chunk(
unsigned long i = 0;
unsigned long n = end_pfn - start_pfn;
+ if (remap_pfn == 0)
+ remap_pfn = nr_pages;
+
while (i < n) {
unsigned long cur_pfn = start_pfn + i;
unsigned long left = n - i;
@@ -438,17 +441,29 @@ static unsigned long __init
xen_set_identity_and_remap_chunk(
return remap_pfn;
}
-static void __init xen_set_identity_and_remap(unsigned long nr_pages)
+static unsigned long __init xen_count_remap_pages(
+ unsigned long start_pfn, unsigned long end_pfn, unsigned long nr_pages,
+ unsigned long remap_pages)
+{
+ if (start_pfn >= nr_pages)
+ return remap_pages;
+
+ return remap_pages + min(end_pfn, nr_pages) - start_pfn;
+}
+
+static unsigned long __init xen_foreach_remap_area(unsigned long nr_pages,
+ unsigned long (*func)(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned long nr_pages, unsigned long last_val))
{
phys_addr_t start = 0;
- unsigned long last_pfn = nr_pages;
+ unsigned long ret_val = 0;
const struct e820entry *entry = xen_e820_map;
int i;
/*
* Combine non-RAM regions and gaps until a RAM region (or the
-* end of the map) is reached, then set the 1:1 map and
-* remap the memory in those non-RAM regions.
+* end of the map) is reached, then call the provided function
+* to perform its duty on the non-RAM region.
*
* The combined non-RAM regions are rounded to a whole number
* of pages so any partial pages are accessible via the 1:1
@@ -466,14 +481,13 @@ static void __init xen_set_identity_and_remap(unsigned
long nr_pages)
end_pfn = PFN_UP(entry->addr);
if (start_pfn < end_pfn)
- last_pfn = xen_set_identity_and_remap_chunk(
- start_pfn, end_pfn, nr_pages,
- last_pfn);
+ ret_val = func(start_pfn, end_pfn, nr_pages,
+ ret_val);
start = end;
}
}
- pr_info("Released %ld page(s)\n", xen_released_pages);
+ return ret_val;
}
/*
@@ -596,35 +610,6 @@ static void __init xen_ignore_unusable(void)
}
}
-static unsigned long __init xen_count_remap_pages(unsigned long max_pfn)
-{
- unsigned long extra = 0;
- unsigned long start_pfn, end_pfn;
- const struct e820entry *entry = xen_e820_map;
- int i;
-
- end_pfn = 0;
- for (i = 0; i < xen_e820_map_entries; i++, entry++) {
- start_pfn = PFN_DOWN(entry->addr);
- /* Adjacent regions on non-page boundaries handling! */
- end_pfn = min(end_pfn, start_pfn);
-
- if (start_pfn >= max_pfn)
- return extra + max_pfn - end_pfn;
-
- /* Add any holes in map to result. */
- extra += start_pfn - end_pfn;
-
- end_pfn = PFN_UP(entry->addr + entry->size);
- end_pfn = min(end_pfn, max_pfn);
-
- if (entry->type != E820_RAM)
- extra += end_pfn - start_pfn;
- }
-
- return extra;
-}
-
bool __init xen_is_e820_reserved(phys_addr_t start, phys_addr_t size)
{
struct e820entry *entry;
@@ -804,7 +789,7 @@ char * __init xen_memory_setup(void)
max_pages = xen_get_max_pages();
/* How many extra pages do we need due to remapping? */
- max_pages += xen_count_remap_pages(max_pfn);
+ max_pages += xen_foreach_remap_area(max_pfn, xen_count_remap_pages);
if (max_pages > max_pfn)
extra_pages += max_pages - max_pfn;
@@ -922,7 +907,9 @@ char * __init xen_memory_setup(void)
* Set identity map on non-RAM pages and prepare remapping the
* underlying RAM.
*/
- xen_set_identity_and_remap(max_pfn);
+ xen_foreach_remap_area(max_pfn, xen_set_identity_and_remap_chunk);
+
+ pr_info("Released %ld page(s)\n", xen_released_pages);
return
Re: [Xen-devel] [PATCH v2 for-4.7 12/14] libxl: fix passing the type argument to xc_psr_* [and 1 more messages]
Wei Liu writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the type
argument to xc_psr_*"):
> On Thu, Apr 28, 2016 at 06:29:03PM +0100, Ian Jackson wrote:
> > I'm very much against introducing casts which are not absolutely
> > necessary. Casts are a big hammer which can suppress important
> > warnings (such as conversions between integers and pointers).
> >
> > This anomaly with the same enum defined in two places with two names
> > is pretty poor. But if we are to perpetuate it, as perhaps we must,
> > then rather than casting at each conversion point, we should introduce
> > an inline function which contains the cast. That way each call site
> > remains more typesafe.
>
> The two enums aren't going away any time soon.
Sadly, I think you're right.
> Does the following diff meet your requirement?
Yes, that is exactly the kind of thing I was thinking of. It makes
the cast non-routine by putting it in a dedicated function whose
authors/readers know to check it's right.
Acked-by: Ian Jackson
(with a suitable commit message)
Roger Pau Monne writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the
type argument to xc_psr_*"):
> On Thu, Apr 28, 2016 at 09:49:11PM +0100, Wei Liu wrote:
> > +BUILD_BUG_ON(sizeof(libxl_psr_cbm_type) != sizeof(xc_psr_cat_type));
> > +return (xc_psr_cat_type)type;
>
> In order to prevent using a cast, we could use a union:
>
> union {
> libxl_psr_cbm_type libxl_psr;
> xc_psr_cat_type xc_psr;
> } u;
>
> u.libxl_psr = type;
> return u.xc_psr;
No, not really.
Firstly, although we compile with -fno-strict-aliasing, this is a bad
example in these days of hostile optimisers: without
-fno-strict-aliasing, the compiler is allowed to assume that the loads
and stores are to different variables, even though the contrary is
evident.
Secondly, it's clumsy.
Thirdly, this kind of union aliasing is normally used for
representation (structure) punning.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max
On 18/05/16 16:39, Ed Swierk wrote: > Nice implementation. I tested it and it fixes the problem on the > affected system. > > Just a minor typo in a comment: "it's duty" should be "its duty". Thanks. Corrected and sent to lkml. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 05/18/2016 08:15 AM, Juergen Gross wrote:
> }
>
> +void __init xen_time_setup_guest(void)
> +{
> + pv_time_ops.steal_clock = xen_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + /*
> + * We can't set paravirt_steal_rq_enabled as this would require the
> + * capability to read another cpu's runstate info.
> + */
> +}
Won't we be accounting for stolen cycles twice now --- once from
steal_account_process_tick()->steal_clock() and second time from
do_stolen_accounting()?
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-4.3-testing test] 94533: trouble: blocked/broken
flight 94533 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/94533/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 3 host-install(3) broken REGR. vs. 80927 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927 build-i3863 host-install(3) broken REGR. vs. 80927 build-amd64 3 host-install(3) broken REGR. vs. 80927 Tests which did not succeed, but are not blocking: 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-amd64-pair 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 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 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-multivcpu 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-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 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 test-amd64-i386-libvirt 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-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 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-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a version targeted for testing: qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1 baseline version: qemuu10c1b763c26feb645627a1639e722515f3e1e876 Last test of basis80927 2016-02-06 13:30:02 Z 102 days Testing same since93977 2016-05-10 11:09:16 Z8 days 21 attempts People who touched revisions under test: Gerd Hoffmann Stefano Stabellini jobs: build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopsbroken build-i386-pvops broken 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-pairblo
Re: [Xen-devel] [PATCH] MAINTAINERS: put docs/man/ under tool stack
George Dunlap writes ("Re: [Xen-devel] [PATCH] MAINTAINERS: put docs/man/ under
tool stack"):
> On Mon, May 9, 2016 at 10:57 AM, Jan Beulich wrote:
> > Right now there's only tool stack related documentation there.
> >
> > Signed-off-by: Jan Beulich
>
> Acked-by: George Dunlap
>
> But I guess it really wants a tools maintainer's Ack.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn emulation
This in particular prevents updating guest IP when handling the retry needed to forward the memory access to qemu. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -4178,6 +4178,8 @@ x86_emulate( if ( !rc && (b & 1) && (ea.type == OP_MEM) ) rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp, ea.bytes, ctxt); +if ( rc ) +goto done; dst.type = OP_NONE; break; } @@ -4430,6 +4432,8 @@ x86_emulate( if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) ) rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp, ea.bytes, ctxt); +if ( rc ) +goto done; dst.type = OP_NONE; break; } x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn emulation This in particular prevents updating guest IP when handling the retry needed to forward the memory access to qemu. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -4178,6 +4178,8 @@ x86_emulate( if ( !rc && (b & 1) && (ea.type == OP_MEM) ) rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp, ea.bytes, ctxt); +if ( rc ) +goto done; dst.type = OP_NONE; break; } @@ -4430,6 +4432,8 @@ x86_emulate( if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) ) rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp, ea.bytes, ctxt); +if ( rc ) +goto done; dst.type = OP_NONE; break; } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 1/4] tmem: Move global stats in a tmem_statistics structure
On Tue, May 17, 2016 at 09:01:00PM -0500, Doug Goldstein wrote:
> On 5/17/16 8:57 PM, Doug Goldstein wrote:
> > On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
> >> And adjust the macro: atomic_inc_and_max to update the structure.
> >>
> >> Sadly one entry: pool->pgp_count cannot use this macro anymore
> >> so unroll the macro for this instance.
> >>
> >> No functional change. The name has the 'tmem_stats' as it will
> >> be eventually non-local.
> >>
> >> Signed-off-by: Konrad Rzeszutek Wilk
> >> ---
> >> xen/common/tmem.c | 135
> >> +-
> >> 1 file changed, 73 insertions(+), 62 deletions(-)
> >>
> >> diff --git a/xen/common/tmem.c b/xen/common/tmem.c
> >> index 16e249a..d362eae 100644
> >> --- a/xen/common/tmem.c
> >> +++ b/xen/common/tmem.c
> >> @@ -28,25 +28,32 @@
> >> #define TMEM_SPEC_VERSION 1
> >>
> >> /* Global statistics (none need to be locked). */
> >> -static unsigned long total_tmem_ops = 0;
> >> -static unsigned long errored_tmem_ops = 0;
> >> -static unsigned long total_flush_pool = 0;
> >> -static unsigned long alloc_failed = 0, alloc_page_failed = 0;
> >> -static unsigned long evicted_pgs = 0, evict_attempts = 0;
> >> -static unsigned long relinq_pgs = 0, relinq_attempts = 0;
> >> -static unsigned long max_evicts_per_relinq = 0;
> >> -static unsigned long low_on_memory = 0;
> >> -static unsigned long deduped_puts = 0;
> >> -static unsigned long tot_good_eph_puts = 0;
> >> -static int global_obj_count_max = 0;
> >> -static int global_pgp_count_max = 0;
> >> -static int global_pcd_count_max = 0;
> >> -static int global_page_count_max = 0;
> >> -static int global_rtree_node_count_max = 0;
> >> -static long global_eph_count_max = 0;
> >> -static unsigned long failed_copies;
> >> -static unsigned long pcd_tot_tze_size = 0;
> >> -static unsigned long pcd_tot_csize = 0;
> >> +struct tmem_statistics {
> >> +unsigned long total_tmem_ops;
> >> +unsigned long errored_tmem_ops;
> >> +unsigned long total_flush_pool;
> >> +unsigned long alloc_failed;
> >> +unsigned long alloc_page_failed;
> >> +unsigned long evicted_pgs;
> >> +unsigned long evict_attempts;
> >> +unsigned long relinq_pgs;
> >> +unsigned long relinq_attempts;
> >> +unsigned long max_evicts_per_relinq;
> >> +unsigned long low_on_memory;
> >> +unsigned long deduped_puts;
> >> +unsigned long tot_good_eph_puts;
> >> +int global_obj_count_max;
> >> +int global_pgp_count_max;
> >> +int global_pcd_count_max;
> >> +int global_page_count_max;
> >> +int global_rtree_node_count_max;
> >> +long global_eph_count_max;
> >> +unsigned long failed_copies;
> >> +unsigned long pcd_tot_tze_size;
> >> +unsigned long pcd_tot_csize;
> >> +};
> >> +
> >> +static struct tmem_statistics tmem_stats;
> >>
> >> / CORE DATA STRUCTURES /
> >>
> >> @@ -225,8 +232,8 @@ static atomic_t global_rtree_node_count =
> >> ATOMIC_INIT(0);
> >>
> >> #define atomic_inc_and_max(_c) do { \
> >> atomic_inc(&_c); \
> >> -if ( _atomic_read(_c) > _c##_max ) \
> >> -_c##_max = _atomic_read(_c); \
> >> +if ( _atomic_read(_c) > tmem_stats._c##_max ) \
> >> +tmem_stats._c##_max = _atomic_read(_c); \
> >> } while (0)
> >>
> >> #define atomic_dec_and_assert(_c) do { \
> >> @@ -273,7 +280,7 @@ static void *tmem_malloc(size_t size, struct tmem_pool
> >> *pool)
> >> v = xmem_pool_alloc(size, tmem_mempool);
> >> }
> >> if ( v == NULL )
> >> -alloc_failed++;
> >> +tmem_stats.alloc_failed++;
> >> return v;
> >> }
> >>
> >> @@ -300,7 +307,7 @@ static struct page_info *tmem_alloc_page(struct
> >> tmem_pool *pool)
> >> else
> >> pfp = __tmem_alloc_page();
> >> if ( pfp == NULL )
> >> -alloc_page_failed++;
> >> +tmem_stats.alloc_page_failed++;
> >> else
> >> atomic_inc_and_max(global_page_count);
> >
> > So the code was previously like this but this change made me notice
> > this. How come tmem_stats.global_page_count needs to be atomically
> > incremented but not tmem_stats.alloc_page_failed? Its also a little
> > weird that global_page_count is in the struct now but not really visible
> > here while alloc_page_count is in the struct but has to be explicitly
> > called out.
> >
> >
>
> Actually I just realized "global_page_count" but this patch actually
> deals with "global_page_count_max". So ignore the original email.
>
> But does this patch compile (for bisect-ability) due to the change to
> atomic_inc_and_max() but not moving "global_page_count" into the structure?
Yup:
#define atomic_inc_and_max(_c) do { \
atomic_inc(&_c); \
-if ( _atomic_read(_c) > _c##_max ) \
-_c##_max = _atomic_read(_c); \
+if ( _atomic_read(_c) > tmem_stats._c##_max ) \
+tmem_stats._c##_max = _atomic_read(_c); \
} while (0)
As the global_page_count is still
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 18/05/16 16:46, Boris Ostrovsky wrote:
> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>> }
>>
>> +void __init xen_time_setup_guest(void)
>> +{
>> +pv_time_ops.steal_clock = xen_steal_clock;
>> +
>> +static_key_slow_inc(¶virt_steal_enabled);
>> +/*
>> + * We can't set paravirt_steal_rq_enabled as this would require the
>> + * capability to read another cpu's runstate info.
>> + */
>> +}
>
> Won't we be accounting for stolen cycles twice now --- once from
> steal_account_process_tick()->steal_clock() and second time from
> do_stolen_accounting()?
Uuh, yes.
I guess I should rip do_stolen_accounting() out, too? It is a
Xen-specific hack, so I guess nobody will cry. Maybe it would be a
good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen
On Wed, 2016-05-18 at 14:24 +0200, Juergen Gross wrote: > On 17/05/16 11:33, George Dunlap wrote: > > > Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting > > > process > > > times. KVM uses it but Xen doesn't. > > Is someone on the Linux side going to put this on their to-do list > > then? :-) > > Patch sent. > Yep, seen it, thanks. > Support was already existing for arm. > Yes!! I remember Stefano talking about introducing it, and that was also why I thought we had it already since long time on x86. Well, anyway... :-) > What is missing is support for > paravirt_steal_rq_enabled which requires to be able to read the > stolen > time of another cpu. This can't work today as accessing another cpu's > vcpu_runstate_info isn't possible without risking inconsistent data. > I plan to add support for this, too, but this will require adding > another hypercall to map a modified vcpu_runstate_info containing an > indicator for an ongoing update of the data. > Understood. So, Tony, up for trying again your workload with this patch applied to Linux? Most likely, it _won't_ fix all the problems you're seeing, but I'm curious to see if it helps. Thanks again and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Saving a guest crashes dom0
On 05/18/2016 10:27 AM, Paul Durrant wrote:
> This should fix the problem for you:
Yes, that does it. Thanks.
-boris
>
> diff --git a/drivers/net/xen-netback/interface.c
> b/drivers/net/xen-netback/interface.c
> index 1c7f49b..83deeeb 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
> vif->ctrl_task = NULL;
> }
>
> - xenvif_deinit_hash(vif);
> -
> if (vif->ctrl_irq) {
> + xenvif_deinit_hash(vif);
> unbind_from_irqhandler(vif->ctrl_irq, vif);
> vif->ctrl_irq = 0;
> }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 94551: tolerable all pass - PUSHED
flight 94551 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94551/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13 saverestore-support-checkfail never pass
version targeted for testing:
xen 667a7120d006007389435976071f0b89f94ec7cc
baseline version:
xen 1542efcea893df874b13b1ea78101e1ff6a55c41
Last test of basis94547 2016-05-18 11:02:48 Z0 days
Testing same since94551 2016-05-18 13:02:38 Z0 days1 attempts
People who touched revisions under test:
Anthony PERARD
Wei Liu
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=667a7120d006007389435976071f0b89f94ec7cc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke
667a7120d006007389435976071f0b89f94ec7cc
+ branch=xen-unstable-smoke
+ revision=667a7120d006007389435976071f0b89f94ec7cc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x667a7120d006007389435976071f0b89f94ec7cc = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/h
Re: [Xen-devel] [PATCH] x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn emulation
On 18/05/16 15:49, Jan Beulich wrote: > This in particular prevents updating guest IP when handling the retry > needed to forward the memory access to qemu. > > Signed-off-by: Jan Beulich Oops. Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Saving a guest crashes dom0
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 18 May 2016 15:57
> To: Paul Durrant; xen-devel
> Subject: Re: Saving a guest crashes dom0
>
> On 05/18/2016 10:27 AM, Paul Durrant wrote:
> > This should fix the problem for you:
>
>
> Yes, that does it. Thanks.
Brilliant :-) I'll post now.
Paul
>
> -boris
>
>
> >
> > diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-
> netback/interface.c
> > index 1c7f49b..83deeeb 100644
> > --- a/drivers/net/xen-netback/interface.c
> > +++ b/drivers/net/xen-netback/interface.c
> > @@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
> > vif->ctrl_task = NULL;
> > }
> >
> > - xenvif_deinit_hash(vif);
> > -
> > if (vif->ctrl_irq) {
> > + xenvif_deinit_hash(vif);
> > unbind_from_irqhandler(vif->ctrl_irq, vif);
> > vif->ctrl_irq = 0;
> > }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation
>>> On 18.05.16 at 14:53, wrote: > On May 17, 2016 3:48 PM, Jan Beulich wrote: >> >>> On 17.05.16 at 05:19, wrote: >> >> From: Xu, Quan >> >> Sent: Monday, May 16, 2016 11:26 PM >> >> >> >> On May 13, 2016 11:28 PM, Jan Beulich wrote: >> >> > >>> On 22.04.16 at 12:54, wrote: >> >> > > --- a/docs/misc/xen-command-line.markdown >> >> > > +++ b/docs/misc/xen-command-line.markdown >> >> > > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also >> >> > specified vpmu will be turned off. >> >> > > As the virtualisation is not 100% safe, don't use the vpmu flag >> >> > > on production systems (see http://xenbits.xen.org/xsa/advisory- >> 163.html)! >> >> > > >> >> > > +### vtd\_qi\_timeout (VT-d) >> >> > > +> `= ` >> >> > > + >> >> > > +> Default: `1` >> >> > > + >> >> > > +Specify the timeout of the VT-d Queued Invalidation in milliseconds. >> >> > > + >> >> > > +By default, the timeout is 1ms. When you see error 'Queue >> >> > > +invalidate wait descriptor timed out', try increasing this value. >> >> > >> >> > So when someone enables ATS, will the 1ms timeout apply to the dev >> >> > iotlb invalidations too? >> >> >> >> Yes, >> >> The timeout is the same for IOTLB, Context, IEC and Device-TLB >> >> invalidation. >> >> >> >> > If so, that's surely too short, and would ideally be adjusted >> >> > automatically, but the need for a higher timeout in that case >> >> > should in any event be mentioned here. >> >> >> >> I can try to use 1ms for IOTLB, Context and IEC invalidation. As >> >> mentioned, 1 ms is enough for IOTLB, Context and IEC invalidation. >> >> What about 10 ms for Device-TLB (10 ms is just a higher timeout, no >> specific meaning)? >> > >> > I remember in earlier discussion we agreed to use 1ms as the default >> > for both IOMMU-side and device-side flushes. For device-side flushes, >> > we checked internal HW team that 1ms is a reasonable threshold for >> > integrated devices. It's likely insufficient for discrete devices. We >> > may check any automatic adjustment method later when it becomes a real >> > problem. For now, please elaborate above information in the text. >> >> Well, taking care of automation later is fine with me, >> but tying everything to a >> single timeout, when device iotlb invalidation may require a much larger >> value, >> isn't. >> > > A little bit confused. Check it -- could I leave patch 1/3 as is? The patch can imo remain as is only if the new default timeout is large enough for all possible cases (including those users who are adventurous enough to turn on ATS). > btw, I have tested it against the last commit, no conflict. No idea what you mean to say with this. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for-4.7 12/14] libxl: fix passing the type argument to xc_psr_* [and 1 more messages]
On Wed, May 18, 2016 at 03:45:22PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2 for-4.7 12/14] libxl: fix passing the type
> argument to xc_psr_*"):
> > On Thu, Apr 28, 2016 at 06:29:03PM +0100, Ian Jackson wrote:
> > > I'm very much against introducing casts which are not absolutely
> > > necessary. Casts are a big hammer which can suppress important
> > > warnings (such as conversions between integers and pointers).
> > >
> > > This anomaly with the same enum defined in two places with two names
> > > is pretty poor. But if we are to perpetuate it, as perhaps we must,
> > > then rather than casting at each conversion point, we should introduce
> > > an inline function which contains the cast. That way each call site
> > > remains more typesafe.
> >
> > The two enums aren't going away any time soon.
>
> Sadly, I think you're right.
>
> > Does the following diff meet your requirement?
>
> Yes, that is exactly the kind of thing I was thinking of. It makes
> the cast non-routine by putting it in a dedicated function whose
> authors/readers know to check it's right.
>
> Acked-by: Ian Jackson
>
> (with a suitable commit message)
Thanks. I will submit a proper patch with your ack.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH net-next] xen-netback: only deinitialized hash if it was initialized
A domain with a frontend that does not implement a control ring has been
seen to cause a crash during domain save. This was apparently because
the call to xenvif_deinit_hash() in xenvif_disconnect_ctrl() is made
regardless of whether a control ring was connected, and hence
xenvif_hash_init() was called.
This patch brings the call to xenvif_deinit_hash() in
xenvif_disconnect_ctrl() inside the if clause that checks whether the
control ring event channel was connected. This is sufficient to ensure
it is only called if xenvif_init_hash() was called previously.
Signed-off-by: Paul Durrant
Reported-by: Boris Ostrovsky
Tested-by: Boris Ostrovsky
Cc: Wei Liu
---
drivers/net/xen-netback/interface.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 1c7f49b..83deeeb 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
vif->ctrl_task = NULL;
}
- xenvif_deinit_hash(vif);
-
if (vif->ctrl_irq) {
+ xenvif_deinit_hash(vif);
unbind_from_irqhandler(vif->ctrl_irq, vif);
vif->ctrl_irq = 0;
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86emul: suppress writeback upon unsuccessful MMX/SSE/AVX insn emulation
On Wed, May 18, 2016 at 08:49:01AM -0600, Jan Beulich wrote: > This in particular prevents updating guest IP when handling the retry > needed to forward the memory access to qemu. > > Signed-off-by: Jan Beulich Release-acked-by: Wei Liu > > --- a/xen/arch/x86/x86_emulate/x86_emulate.c > +++ b/xen/arch/x86/x86_emulate/x86_emulate.c > @@ -4178,6 +4178,8 @@ x86_emulate( > if ( !rc && (b & 1) && (ea.type == OP_MEM) ) > rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp, > ea.bytes, ctxt); > +if ( rc ) > +goto done; > dst.type = OP_NONE; > break; > } > @@ -4430,6 +4432,8 @@ x86_emulate( > if ( !rc && (b != 0x6f) && (ea.type == OP_MEM) ) > rc = ops->write(ea.mem.seg, ea.mem.off, mmvalp, > ea.bytes, ctxt); > +if ( rc ) > +goto done; > dst.type = OP_NONE; > break; > } > > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] state of xenified SUSE kernel
>>> On 18.05.16 at 16:39, wrote: > On 17.05.2016 17:34, Jan Beulich wrote: >>> We use xenified kernels based on kernel 3.4 for years and benchmarks >>> showed that they are faster than the pvops (vanilla) kernels. >>> But what is the current state in terms of performance and features? >> I'm not sure what you expect here. Up to openSUSE 42.1 and >> SLE 12 SP1 they are fully maintained, i.e. you can get quite a >> bit newer than 3.4 based kernels. There's not a lot of >> performance analysis that I would be aware of, so I can't >> answer that part anyway. And them being release branches >> rather than development ones, there's not going to be any >> new feature work. > > As far as I know the patches are based on the original work for kernel > 2.6.18 and have not been adjusted to major changes in Xen architecture. > So what I am thinking about is performance improvements that result from > using newer Xen features. We've added support for newer features where suitable, over the years. When reasonable I've also tried to put these into the 2.6.18 tree. But from all I can tell right now this isn't going to happen any further. > So the question was: from an architectural > point of view should pvops in recent vanilla kernels be "better" then > xenified kernels? Hence it's hard to answer this question, the more that I can't even prove (or disprove) what you've said regarding its performance having been better in the past. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 2nd opinion on backportability of c35eefded2
>>> On 18.05.16 at 16:41, wrote:
> On 13/05/16 10:32, Jan Beulich wrote:
>> Hi George,
>>
>> after quite a bit of debugging on 4.6.1 I learned that said commit
>> ("x86/P2M: consolidate handling of types not requiring a valid MFN")
>> is more than just cleanup: Since p2m_set_entry() happily performs
>> arithmetic on the passed in MFN, shadow mode guests (verified) as
>> well as HAP ones when 1Gb / 2Mb mappings are unavailable (not
>> verified), if any of the MFNs below 1Gb are invalid (reported with
>> e.g. "crashkernel=512M@16M"), p2m_pt_set_entry() would (in
>> the context of guest_physmap_mark_populate_on_demand())
>> produce invalid instead of PoD entries, resulting in subsequent
>> attempts by the guest to use (e.g. balloon out) these pages to
>> fail (the balloon failure results in a crash during boot).
>
> I'm sorry, I'm having some trouble parsing this paragraph. :-)
>
> But this is what I gather:
>
> Before c35eefded2, the 4k-entry path didn't check whether the p2m entry
> was PoD, it only checked that the mfn was valid. The pod code would
> always set this mfn to 0, which is (usually) valid; but p2m_set_entry()
> might iterate over this, ending up in p2m_pt_set_entry() with non-zero
> low values for mfn. In certain circumstances these low-value mfns might
> actually be invalid (for example, if they overlap a crash kernel).
>
> In such a case, the resulting p2m entries would be (erroneously) marked
> as invalid rather than PoD, resulting in a crash when the guest tried to
> access it or populate it.
>
> You observed this happening in the shadow case, and believe it would
> happen if p2m 2MiB or 1GiB pages were disabled but haven't checked those
> cases.
>
> c35eefded2 fixes this by implicitly checking for the PoD type on the 4k
> entry path.
Yes, that's a neater re-write of what I had tried to state.
>> Now, while the backport to 4.6 is straightforward, I'm having the
>> vague feeling that this change might depend on some earlier one,
>> but I can't pinpoint anything. Hence I would appreciate if you
>> could take a look and provide your judgment.
>
> We talked about the PoD type thing in the context of a discussion about
> 660fd65 ("x86/p2m-pt: tighten conditions of IOMMU mapping updates") --
> discussion here [1]. But it doesn't look like that's a prerequisite,
> and nothing else really comes to mind.
Right, the PoD thing was just an observation while putting together
that other patch, not something that would create a dependency.
Plus - that commit went in during 4.6-rc, and got backported to 4.5.x,
so even if it was a prereq this would not be a problem.
Thanks for double checking!
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>> }
>>>
>>> +void __init xen_time_setup_guest(void)
>>> +{
>>> + pv_time_ops.steal_clock = xen_steal_clock;
>>> +
>>> + static_key_slow_inc(¶virt_steal_enabled);
>>> + /*
>>> +* We can't set paravirt_steal_rq_enabled as this would require the
>>> +* capability to read another cpu's runstate info.
>>> +*/
>>> +}
>> Won't we be accounting for stolen cycles twice now --- once from
>> steal_account_process_tick()->steal_clock() and second time from
>> do_stolen_accounting()?
> Uuh, yes.
>
> I guess I should rip do_stolen_accounting() out, too?
I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
that's indeed the case then we should ifndef do_stolen_accounting(). Or
maybe check for paravirt_steal_enabled.
-boris
> It is a
> Xen-specific hack, so I guess nobody will cry. Maybe it would be a
> good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then?
>
>
> Juergen
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.7] libxl: consolidate casting to xc psr type to a function
In commit 31268fea (libxl: fix passing the type argument to xc_psr_*),
casting to xc psr type was done at each call site.
This patch consolidates casting into a function to avoid casting at each
conversion point. Each call site remains more type safe.
Signed-off-by: Wei Liu
Acked-by: Ian Jackson
---
Cc: Ian Jackson
Cc: Roger Pau Monne
I will commit this patch later this week if I receive no further
feedback.
---
tools/libxl/libxl_psr.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 40f2d5f..99733f6 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -293,12 +293,18 @@ out:
return rc;
}
+static inline xc_psr_cat_type libxl__psr_cbm_type_to_libxc_psr_cat_type(
+libxl_psr_cbm_type type)
+{
+BUILD_BUG_ON(sizeof(libxl_psr_cbm_type) != sizeof(xc_psr_cat_type));
+return (xc_psr_cat_type)type;
+}
+
int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
libxl_psr_cbm_type type, libxl_bitmap *target_map,
uint64_t cbm)
{
GC_INIT(ctx);
-BUILD_BUG_ON(sizeof(libxl_psr_cbm_type) != sizeof(xc_psr_cat_type));
int rc;
int socketid, nr_sockets;
@@ -309,9 +315,13 @@ int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
}
libxl_for_each_set_bit(socketid, *target_map) {
+xc_psr_cat_type xc_type;
+
if (socketid >= nr_sockets)
break;
-if (xc_psr_cat_set_domain_data(ctx->xch, domid, (xc_psr_cat_type)type,
+
+xc_type = libxl__psr_cbm_type_to_libxc_psr_cat_type(type);
+if (xc_psr_cat_set_domain_data(ctx->xch, domid, xc_type,
socketid, cbm)) {
libxl__psr_cat_log_err_msg(gc, errno);
rc = ERROR_FAIL;
@@ -329,8 +339,9 @@ int libxl_psr_cat_get_cbm(libxl_ctx *ctx, uint32_t domid,
{
GC_INIT(ctx);
int rc = 0;
+xc_psr_cat_type xc_type = libxl__psr_cbm_type_to_libxc_psr_cat_type(type);
-if (xc_psr_cat_get_domain_data(ctx->xch, domid, (xc_psr_cat_type)type,
+if (xc_psr_cat_get_domain_data(ctx->xch, domid, xc_type,
target, cbm_r)) {
libxl__psr_cat_log_err_msg(gc, errno);
rc = ERROR_FAIL;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH net-next] xen-netback: only deinitialized hash if it was initialized
On Wed, May 18, 2016 at 03:55:42PM +0100, Paul Durrant wrote:
> A domain with a frontend that does not implement a control ring has been
> seen to cause a crash during domain save. This was apparently because
> the call to xenvif_deinit_hash() in xenvif_disconnect_ctrl() is made
> regardless of whether a control ring was connected, and hence
> xenvif_hash_init() was called.
>
> This patch brings the call to xenvif_deinit_hash() in
> xenvif_disconnect_ctrl() inside the if clause that checks whether the
> control ring event channel was connected. This is sufficient to ensure
> it is only called if xenvif_init_hash() was called previously.
>
> Signed-off-by: Paul Durrant
> Reported-by: Boris Ostrovsky
> Tested-by: Boris Ostrovsky
> Cc: Wei Liu
Acked-by: Wei Liu
> ---
> drivers/net/xen-netback/interface.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netback/interface.c
> b/drivers/net/xen-netback/interface.c
> index 1c7f49b..83deeeb 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -780,9 +780,8 @@ void xenvif_disconnect_ctrl(struct xenvif *vif)
> vif->ctrl_task = NULL;
> }
>
> - xenvif_deinit_hash(vif);
> -
> if (vif->ctrl_irq) {
> + xenvif_deinit_hash(vif);
> unbind_from_irqhandler(vif->ctrl_irq, vif);
> vif->ctrl_irq = 0;
> }
> --
> 2.1.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 18/05/16 17:25, Boris Ostrovsky wrote:
> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>> On 18/05/16 16:46, Boris Ostrovsky wrote:
>>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
}
+void __init xen_time_setup_guest(void)
+{
+ pv_time_ops.steal_clock = xen_steal_clock;
+
+ static_key_slow_inc(¶virt_steal_enabled);
+ /*
+ * We can't set paravirt_steal_rq_enabled as this would require the
+ * capability to read another cpu's runstate info.
+ */
+}
>>> Won't we be accounting for stolen cycles twice now --- once from
>>> steal_account_process_tick()->steal_clock() and second time from
>>> do_stolen_accounting()?
>> Uuh, yes.
>>
>> I guess I should rip do_stolen_accounting() out, too?
>
> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
This is easy to accomplish. :-)
> that's indeed the case then we should ifndef do_stolen_accounting(). Or
> maybe check for paravirt_steal_enabled.
Is this really a sensible thing to do? There is a mechanism used by KVM
to do the stolen accounting. I think we should use it instead of having
a second implementation doing the same thing in case the generic one
isn't enabled.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 18/05/16 16:42, Juergen Gross wrote:
> On 18/05/16 17:25, Boris Ostrovsky wrote:
>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>>> On 18/05/16 16:46, Boris Ostrovsky wrote:
On 05/18/2016 08:15 AM, Juergen Gross wrote:
> }
>
> +void __init xen_time_setup_guest(void)
> +{
> + pv_time_ops.steal_clock = xen_steal_clock;
> +
> + static_key_slow_inc(¶virt_steal_enabled);
> + /*
> + * We can't set paravirt_steal_rq_enabled as this would require the
> + * capability to read another cpu's runstate info.
> + */
> +}
Won't we be accounting for stolen cycles twice now --- once from
steal_account_process_tick()->steal_clock() and second time from
do_stolen_accounting()?
>>> Uuh, yes.
>>>
>>> I guess I should rip do_stolen_accounting() out, too?
>>
>> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
>
> This is easy to accomplish. :-)
>
>> that's indeed the case then we should ifndef do_stolen_accounting(). Or
>> maybe check for paravirt_steal_enabled.
>
> Is this really a sensible thing to do? There is a mechanism used by KVM
> to do the stolen accounting. I think we should use it instead of having
> a second implementation doing the same thing in case the generic one
> isn't enabled.
I agree.
Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
don't think it's essential (or is it?).
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 18/05/16 17:45, David Vrabel wrote:
> On 18/05/16 16:42, Juergen Gross wrote:
>> On 18/05/16 17:25, Boris Ostrovsky wrote:
>>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
On 18/05/16 16:46, Boris Ostrovsky wrote:
> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>> }
>>
>> +void __init xen_time_setup_guest(void)
>> +{
>> +pv_time_ops.steal_clock = xen_steal_clock;
>> +
>> +static_key_slow_inc(¶virt_steal_enabled);
>> +/*
>> + * We can't set paravirt_steal_rq_enabled as this would require
>> the
>> + * capability to read another cpu's runstate info.
>> + */
>> +}
> Won't we be accounting for stolen cycles twice now --- once from
> steal_account_process_tick()->steal_clock() and second time from
> do_stolen_accounting()?
Uuh, yes.
I guess I should rip do_stolen_accounting() out, too?
>>>
>>> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
>>
>> This is easy to accomplish. :-)
>>
>>> that's indeed the case then we should ifndef do_stolen_accounting(). Or
>>> maybe check for paravirt_steal_enabled.
>>
>> Is this really a sensible thing to do? There is a mechanism used by KVM
>> to do the stolen accounting. I think we should use it instead of having
>> a second implementation doing the same thing in case the generic one
>> isn't enabled.
>
> I agree.
>
> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
> don't think it's essential (or is it?).
Not doing so will change behavior in case I rip out
do_stolen_accounting(). What about "default y if XEN" ?
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 05/18/2016 11:45 AM, David Vrabel wrote:
> On 18/05/16 16:42, Juergen Gross wrote:
>> On 18/05/16 17:25, Boris Ostrovsky wrote:
>>> On 05/18/2016 10:53 AM, Juergen Gross wrote:
On 18/05/16 16:46, Boris Ostrovsky wrote:
> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>> }
>>
>> +void __init xen_time_setup_guest(void)
>> +{
>> +pv_time_ops.steal_clock = xen_steal_clock;
>> +
>> +static_key_slow_inc(¶virt_steal_enabled);
>> +/*
>> + * We can't set paravirt_steal_rq_enabled as this would require
>> the
>> + * capability to read another cpu's runstate info.
>> + */
>> +}
> Won't we be accounting for stolen cycles twice now --- once from
> steal_account_process_tick()->steal_clock() and second time from
> do_stolen_accounting()?
Uuh, yes.
I guess I should rip do_stolen_accounting() out, too?
>>> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
>> This is easy to accomplish. :-)
I looked at KVM code (PARAVIRT_TIME_ACCOUNTING is not selected there
neither) and in their case that's presumably because stealing accounting
is a CPUID bit, i.e. it might not be supported. In Xen case we always
have this interface.
>>
>>> that's indeed the case then we should ifndef do_stolen_accounting(). Or
>>> maybe check for paravirt_steal_enabled.
>> Is this really a sensible thing to do? There is a mechanism used by KVM
>> to do the stolen accounting. I think we should use it instead of having
>> a second implementation doing the same thing in case the generic one
>> isn't enabled.
> I agree.
>
> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
> don't think it's essential (or is it?).
Looks like it's useful only if paravirt_steal_rq_enabled, which we don't
support yet.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 18/05/16 16:51, Juergen Gross wrote:
> On 18/05/16 17:45, David Vrabel wrote:
>> On 18/05/16 16:42, Juergen Gross wrote:
>>> On 18/05/16 17:25, Boris Ostrovsky wrote:
On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>> }
>>>
>>> +void __init xen_time_setup_guest(void)
>>> +{
>>> + pv_time_ops.steal_clock = xen_steal_clock;
>>> +
>>> + static_key_slow_inc(¶virt_steal_enabled);
>>> + /*
>>> +* We can't set paravirt_steal_rq_enabled as this would require
>>> the
>>> +* capability to read another cpu's runstate info.
>>> +*/
>>> +}
>> Won't we be accounting for stolen cycles twice now --- once from
>> steal_account_process_tick()->steal_clock() and second time from
>> do_stolen_accounting()?
> Uuh, yes.
>
> I guess I should rip do_stolen_accounting() out, too?
I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
>>>
>>> This is easy to accomplish. :-)
>>>
that's indeed the case then we should ifndef do_stolen_accounting(). Or
maybe check for paravirt_steal_enabled.
>>>
>>> Is this really a sensible thing to do? There is a mechanism used by KVM
>>> to do the stolen accounting. I think we should use it instead of having
>>> a second implementation doing the same thing in case the generic one
>>> isn't enabled.
>>
>> I agree.
>>
>> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
>> don't think it's essential (or is it?).
>
> Not doing so will change behavior in case I rip out
> do_stolen_accounting(). What about "default y if XEN" ?
Ok.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 18/05/16 17:53, Boris Ostrovsky wrote:
> On 05/18/2016 11:45 AM, David Vrabel wrote:
>> On 18/05/16 16:42, Juergen Gross wrote:
>>> On 18/05/16 17:25, Boris Ostrovsky wrote:
On 05/18/2016 10:53 AM, Juergen Gross wrote:
> On 18/05/16 16:46, Boris Ostrovsky wrote:
>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
>>> }
>>>
>>> +void __init xen_time_setup_guest(void)
>>> +{
>>> + pv_time_ops.steal_clock = xen_steal_clock;
>>> +
>>> + static_key_slow_inc(¶virt_steal_enabled);
>>> + /*
>>> +* We can't set paravirt_steal_rq_enabled as this would require
>>> the
>>> +* capability to read another cpu's runstate info.
>>> +*/
>>> +}
>> Won't we be accounting for stolen cycles twice now --- once from
>> steal_account_process_tick()->steal_clock() and second time from
>> do_stolen_accounting()?
> Uuh, yes.
>
> I guess I should rip do_stolen_accounting() out, too?
I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
>>> This is easy to accomplish. :-)
>
>
> I looked at KVM code (PARAVIRT_TIME_ACCOUNTING is not selected there
> neither) and in their case that's presumably because stealing accounting
> is a CPUID bit, i.e. it might not be supported. In Xen case we always
> have this interface.
So they added it later and the default is to keep the old behavior.
that's indeed the case then we should ifndef do_stolen_accounting(). Or
maybe check for paravirt_steal_enabled.
>>> Is this really a sensible thing to do? There is a mechanism used by KVM
>>> to do the stolen accounting. I think we should use it instead of having
>>> a second implementation doing the same thing in case the generic one
>>> isn't enabled.
>> I agree.
>>
>> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
>> don't think it's essential (or is it?).
>
> Looks like it's useful only if paravirt_steal_rq_enabled, which we don't
> support yet.
I think the patch is still useful. It is reducing code size and
it is removing arch-specific Xen-hack(s). With the patch Xen's
solution for arm and x86 is common and the same as for KVM. Adding
paravirt_steal_rq_enabled later will be much easier as only one
function needs substantial modification.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen
On Wed, May 18, 2016 at 8:57 AM, Dario Faggioli wrote: > On Wed, 2016-05-18 at 14:24 +0200, Juergen Gross wrote: >> On 17/05/16 11:33, George Dunlap wrote: >> > > Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting >> > > process >> > > times. KVM uses it but Xen doesn't. >> > Is someone on the Linux side going to put this on their to-do list >> > then? :-) >> >> Patch sent. >> > Yep, seen it, thanks. > >> Support was already existing for arm. >> > Yes!! I remember Stefano talking about introducing it, and that was > also why I thought we had it already since long time on x86. > > Well, anyway... :-) > >> What is missing is support for >> paravirt_steal_rq_enabled which requires to be able to read the >> stolen >> time of another cpu. This can't work today as accessing another cpu's >> vcpu_runstate_info isn't possible without risking inconsistent data. >> I plan to add support for this, too, but this will require adding >> another hypercall to map a modified vcpu_runstate_info containing an >> indicator for an ongoing update of the data. >> > Understood. > > So, Tony, up for trying again your workload with this patch applied to > Linux? > > Most likely, it _won't_ fix all the problems you're seeing, but I'm > curious to see if it helps. Hi Dario, I did not see the patch. Can you please send me the patch and I will try to test it later. Best Tony > > Thanks again and Regards, > Dario > -- > <> (Raistlin Majere) > - > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) > -- Tony. S Ph. D student of University of Colorado, Colorado Springs ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote: > On 18/05/16 16:46, Boris Ostrovsky wrote: > > > > Won't we be accounting for stolen cycles twice now --- once from > > steal_account_process_tick()->steal_clock() and second time from > > do_stolen_accounting()? > Uuh, yes. > > I guess I should rip do_stolen_accounting() out, too? It is a > Xen-specific hack, so I guess nobody will cry. Maybe it would be a > good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then? > So, config options aside, if I understand this correctly, it looks like we were actually already doing steal time accounting, although in a non-standard way. And yet, people seem to have issues relating to lack of (proper?) steal time accounting (Cc-ing Tony). I guess this means that, either: - the issue being reported is actually not caused by the lack of steal time accounting, - our current (Xen specific) steal time accounting solution is flawed, - the issue is caused by the lack of the bit of steal time accounting that we do not support yet, - other ideas? Tony? Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add steal_clock support on x86
On 05/18/2016 12:00 PM, Juergen Gross wrote:
> On 18/05/16 17:53, Boris Ostrovsky wrote:
>> On 05/18/2016 11:45 AM, David Vrabel wrote:
>>> On 18/05/16 16:42, Juergen Gross wrote:
On 18/05/16 17:25, Boris Ostrovsky wrote:
> On 05/18/2016 10:53 AM, Juergen Gross wrote:
>> On 18/05/16 16:46, Boris Ostrovsky wrote:
>>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
}
+void __init xen_time_setup_guest(void)
+{
+ pv_time_ops.steal_clock = xen_steal_clock;
+
+ static_key_slow_inc(¶virt_steal_enabled);
+ /*
+ * We can't set paravirt_steal_rq_enabled as this would require
the
+ * capability to read another cpu's runstate info.
+ */
+}
>>> Won't we be accounting for stolen cycles twice now --- once from
>>> steal_account_process_tick()->steal_clock() and second time from
>>> do_stolen_accounting()?
>> Uuh, yes.
>>
>> I guess I should rip do_stolen_accounting() out, too?
> I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If
This is easy to accomplish. :-)
>>
>> I looked at KVM code (PARAVIRT_TIME_ACCOUNTING is not selected there
>> neither) and in their case that's presumably because stealing accounting
>> is a CPUID bit, i.e. it might not be supported. In Xen case we always
>> have this interface.
> So they added it later and the default is to keep the old behavior.
>
> that's indeed the case then we should ifndef do_stolen_accounting(). Or
> maybe check for paravirt_steal_enabled.
Is this really a sensible thing to do? There is a mechanism used by KVM
to do the stolen accounting. I think we should use it instead of having
a second implementation doing the same thing in case the generic one
isn't enabled.
>>> I agree.
>>>
>>> Although I don't think selecting PARAVIRT_TIME_ACC' is necessary -- I
>>> don't think it's essential (or is it?).
>> Looks like it's useful only if paravirt_steal_rq_enabled, which we don't
>> support yet.
> I think the patch is still useful. It is reducing code size and
> it is removing arch-specific Xen-hack(s). With the patch Xen's
> solution for arm and x86 is common and the same as for KVM. Adding
> paravirt_steal_rq_enabled later will be much easier as only one
> function needs substantial modification.
I am not arguing against having a patch that will remove
do_stolen_accounting(). I was responding to David's statement about
whether we need to select CONFIG_PARAVIRT_TIME_ACCOUNTING, and I am not
sure this is necessary since steal_account_process_tick() (that will
take case of things that do_stolen_accounting() currently does) doesn't
need it.
(And if it is indeed needed --- can we have Xen's Kconfig select it
instead of "default y if XEN" ?)
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
