[Xen-devel] [PATCH v12 3/6] vt-d: convert conditionals of qi_ctrl->qinval_maddr into ASSERT()s

[Xu, Quan]

From: Quan Xu 

QI ought to have got disabled if any of the IOMMU table setup
failed. A QI function (other than enable_qinval) is unreachable
when qi_ctrl->qinval_maddr is zero.

Signed-off-by: Quan Xu 

CC: Jan Beulich 
CC: Kevin Tian 
CC: Feng Wu 
---
 xen/drivers/passthrough/vtd/qinval.c | 52 
 1 file changed, 23 insertions(+), 29 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index 46c4c8f..4492b29 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -204,10 +204,9 @@ static int __must_check invalidate_sync(struct iommu 
*iommu,
 {
 struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
 
-if ( qi_ctrl->qinval_maddr )
-return queue_invalidate_wait(iommu, 0, 1, 1, flush_dev_iotlb);
+ASSERT(qi_ctrl->qinval_maddr);
 
-return 0;
+return queue_invalidate_wait(iommu, 0, 1, 1, flush_dev_iotlb);
 }
 
 int qinval_device_iotlb_sync(struct iommu *iommu,
@@ -297,10 +296,11 @@ static int __must_check flush_context_qi(void *_iommu, 
u16 did,
  u16 sid, u8 fm, u64 type,
  bool_t flush_non_present_entry)
 {
-int ret = 0;
 struct iommu *iommu = (struct iommu *)_iommu;
 struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
 
+ASSERT(qi_ctrl->qinval_maddr);
+
 /*
  * In the non-present entry flush case, if hardware doesn't cache
  * non-present entry we do nothing and if hardware cache non-present
@@ -315,11 +315,8 @@ static int __must_check flush_context_qi(void *_iommu, u16 
did,
 did = 0;
 }
 
-if ( qi_ctrl->qinval_maddr != 0 )
-ret = queue_invalidate_context_sync(iommu, did, sid, fm,
-type >> 
DMA_CCMD_INVL_GRANU_OFFSET);
-
-return ret;
+return queue_invalidate_context_sync(iommu, did, sid, fm,
+ type >> DMA_CCMD_INVL_GRANU_OFFSET);
 }
 
 static int __must_check flush_iotlb_qi(void *_iommu, u16 did, u64 addr,
@@ -328,10 +325,12 @@ static int __must_check flush_iotlb_qi(void *_iommu, u16 
did, u64 addr,
bool_t flush_dev_iotlb)
 {
 u8 dr = 0, dw = 0;
-int ret = 0;
+int ret = 0, rc;
 struct iommu *iommu = (struct iommu *)_iommu;
 struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
 
+ASSERT(qi_ctrl->qinval_maddr);
+
 /*
  * In the non-present entry flush case, if hardware doesn't cache
  * non-present entry we do nothing and if hardware cache non-present
@@ -346,28 +345,23 @@ static int __must_check flush_iotlb_qi(void *_iommu, u16 
did, u64 addr,
 did = 0;
 }
 
-if ( qi_ctrl->qinval_maddr != 0 )
+/* use queued invalidation */
+if (cap_write_drain(iommu->cap))
+dw = 1;
+if (cap_read_drain(iommu->cap))
+dr = 1;
+/* Need to conside the ih bit later */
+rc = queue_invalidate_iotlb_sync(iommu,
+ type >> DMA_TLB_FLUSH_GRANU_OFFSET,
+ dr, dw, did, size_order, 0, addr);
+if ( !ret )
+ret = rc;
+
+if ( flush_dev_iotlb )
 {
-int rc;
-
-/* use queued invalidation */
-if (cap_write_drain(iommu->cap))
-dw = 1;
-if (cap_read_drain(iommu->cap))
-dr = 1;
-/* Need to conside the ih bit later */
-rc = queue_invalidate_iotlb_sync(iommu,
- type >> DMA_TLB_FLUSH_GRANU_OFFSET,
- dr, dw, did, size_order, 0, addr);
+rc = dev_invalidate_iotlb(iommu, did, addr, size_order, type);
 if ( !ret )
 ret = rc;
-
-if ( flush_dev_iotlb )
-{
-rc = dev_invalidate_iotlb(iommu, did, addr, size_order, type);
-if ( !ret )
-ret = rc;
-}
 }
 return ret;
 }
-- 
1.9.1


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

[Xen-devel] [PATCH v12 6/6] vt-d: fix vt-d Device-TLB flush timeout issue

[Xu, Quan]

From: Quan Xu 

If Device-TLB flush timed out, we hide the target ATS device
immediately and crash the domain owning this ATS device. If
impacted domain is hardware domain, just throw out a warning.

By hiding the device, we make sure it can't be assigned to any
domain any longer (see device_assigned).

Signed-off-by: Quan Xu 

CC: Jan Beulich 
CC: Kevin Tian 
CC: Feng Wu 

---
v12:
   1. a forward declaration struct pci_ats_dev*, instead of
  including ats.h.
   2. eliminate the loop.
   3. use the same logic for logging and crashing as I did in
  other series (despite I have moved the domain crash logic
  up to the generic IOMMU layer, I think I am better still
  leave it as is).
   4. enhance dev_invalidate_sync() with ASSERT().
---
 xen/drivers/passthrough/pci.c |  6 +--
 xen/drivers/passthrough/vtd/extern.h  |  5 ++-
 xen/drivers/passthrough/vtd/qinval.c  | 75 +--
 xen/drivers/passthrough/vtd/x86/ats.c |  9 +
 xen/include/xen/pci.h |  1 +
 5 files changed, 71 insertions(+), 25 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 98936f55c..843dc88 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -419,7 +419,7 @@ static void free_pdev(struct pci_seg *pseg, struct pci_dev 
*pdev)
 xfree(pdev);
 }
 
-static void _pci_hide_device(struct pci_dev *pdev)
+void pci_hide_existing_device(struct pci_dev *pdev)
 {
 if ( pdev->domain )
 return;
@@ -436,7 +436,7 @@ int __init pci_hide_device(int bus, int devfn)
 pdev = alloc_pdev(get_pseg(0), bus, devfn);
 if ( pdev )
 {
-_pci_hide_device(pdev);
+pci_hide_existing_device(pdev);
 rc = 0;
 }
 pcidevs_unlock();
@@ -466,7 +466,7 @@ int __init pci_ro_device(int seg, int bus, int devfn)
 }
 
 __set_bit(PCI_BDF2(bus, devfn), pseg->ro_map);
-_pci_hide_device(pdev);
+pci_hide_existing_device(pdev);
 
 return 0;
 }
diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index 45357f2..efaff28 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -25,6 +25,7 @@
 
 #define VTDPREFIX "[VT-D]"
 
+struct pci_ats_dev;
 extern bool_t rwbf_quirk;
 
 void print_iommu_regs(struct acpi_drhd_unit *drhd);
@@ -60,8 +61,8 @@ int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
  u64 addr, unsigned int size_order, u64 type);
 
 int __must_check qinval_device_iotlb_sync(struct iommu *iommu,
-  u32 max_invs_pend,
-  u16 sid, u16 size, u64 addr);
+  struct pci_ats_dev *ats_dev,
+  u16 did, u16 size, u64 addr);
 
 unsigned int get_cache_line_size(void);
 void cacheline_flush(char *);
diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index 4492b29..e4e2771 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -27,11 +27,11 @@
 #include "dmar.h"
 #include "vtd.h"
 #include "extern.h"
+#include "../ats.h"
 
 #define VTD_QI_TIMEOUT 1
 
-static int __must_check invalidate_sync(struct iommu *iommu,
-bool_t flush_dev_iotlb);
+static int __must_check invalidate_sync(struct iommu *iommu);
 
 static void print_qi_regs(struct iommu *iommu)
 {
@@ -103,7 +103,7 @@ static int __must_check 
queue_invalidate_context_sync(struct iommu *iommu,
 
 unmap_vtd_domain_page(qinval_entries);
 
-return invalidate_sync(iommu, 0);
+return invalidate_sync(iommu);
 }
 
 static int __must_check queue_invalidate_iotlb_sync(struct iommu *iommu,
@@ -140,7 +140,7 @@ static int __must_check queue_invalidate_iotlb_sync(struct 
iommu *iommu,
 qinval_update_qtail(iommu, index);
 spin_unlock_irqrestore(>register_lock, flags);
 
-return invalidate_sync(iommu, 0);
+return invalidate_sync(iommu);
 }
 
 static int __must_check queue_invalidate_wait(struct iommu *iommu,
@@ -199,24 +199,73 @@ static int __must_check queue_invalidate_wait(struct 
iommu *iommu,
 return -EOPNOTSUPP;
 }
 
-static int __must_check invalidate_sync(struct iommu *iommu,
-bool_t flush_dev_iotlb)
+static int __must_check invalidate_sync(struct iommu *iommu)
 {
 struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
 
 ASSERT(qi_ctrl->qinval_maddr);
 
-return queue_invalidate_wait(iommu, 0, 1, 1, flush_dev_iotlb);
+return queue_invalidate_wait(iommu, 0, 1, 1, 0);
+}
+
+static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
+ struct pci_dev *pdev)
+{
+struct domain *d = NULL;
+
+if ( test_bit(did, iommu->domid_bitmap) )
+ 

[Xen-devel] [PATCH v12 2/6] vt-d: synchronize for Device-TLB flush one by one

[Xu, Quan]

From: Quan Xu 

Today we do Device-TLB flush synchronization after issuing flush
requests for all ATS devices belonging to a VM. Doing so however
imposes a limitation, i.e. that we can not figure out which flush
request is blocked in the flush queue list, based on VT-d spec.

To prepare correct Device-TLB flush timeout handling in next patch,
we change the behavior to synchronize for every Device-TLB flush
request. So the Device-TLB flush interface is changed a little bit,
by checking timeout within the function instead of outside of function.

Accordingly we also do a similar change for flush interfaces of
IOTLB/IEC/Context, i.e. moving synchronization into the function.
Since there is no user of a non-synced interface, we just rename
existing ones with _sync suffix.

Signed-off-by: Quan Xu 
Reviewed-by: Jan Beulich 

CC: Jan Beulich 
CC: Kevin Tian 
CC: Feng Wu 
---
 xen/drivers/passthrough/vtd/extern.h  |  5 +--
 xen/drivers/passthrough/vtd/qinval.c  | 65 ---
 xen/drivers/passthrough/vtd/x86/ats.c |  8 ++---
 3 files changed, 45 insertions(+), 33 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index 6772839..45357f2 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -59,8 +59,9 @@ int ats_device(const struct pci_dev *, const struct 
acpi_drhd_unit *);
 int dev_invalidate_iotlb(struct iommu *iommu, u16 did,
  u64 addr, unsigned int size_order, u64 type);
 
-int qinval_device_iotlb(struct iommu *iommu,
-u32 max_invs_pend, u16 sid, u16 size, u64 addr);
+int __must_check qinval_device_iotlb_sync(struct iommu *iommu,
+  u32 max_invs_pend,
+  u16 sid, u16 size, u64 addr);
 
 unsigned int get_cache_line_size(void);
 void cacheline_flush(char *);
diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index 4788d5f..46c4c8f 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -30,6 +30,9 @@
 
 #define VTD_QI_TIMEOUT 1
 
+static int __must_check invalidate_sync(struct iommu *iommu,
+bool_t flush_dev_iotlb);
+
 static void print_qi_regs(struct iommu *iommu)
 {
 u64 val;
@@ -69,8 +72,10 @@ static void qinval_update_qtail(struct iommu *iommu, 
unsigned int index)
 dmar_writeq(iommu->reg, DMAR_IQT_REG, (val << QINVAL_INDEX_SHIFT));
 }
 
-static void queue_invalidate_context(struct iommu *iommu,
-u16 did, u16 source_id, u8 function_mask, u8 granu)
+static int __must_check queue_invalidate_context_sync(struct iommu *iommu,
+  u16 did, u16 source_id,
+  u8 function_mask,
+  u8 granu)
 {
 unsigned long flags;
 unsigned int index;
@@ -97,10 +102,14 @@ static void queue_invalidate_context(struct iommu *iommu,
 spin_unlock_irqrestore(>register_lock, flags);
 
 unmap_vtd_domain_page(qinval_entries);
+
+return invalidate_sync(iommu, 0);
 }
 
-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;
@@ -130,6 +139,8 @@ static void queue_invalidate_iotlb(struct iommu *iommu,
 unmap_vtd_domain_page(qinval_entries);
 qinval_update_qtail(iommu, index);
 spin_unlock_irqrestore(>register_lock, flags);
+
+return invalidate_sync(iommu, 0);
 }
 
 static int __must_check queue_invalidate_wait(struct iommu *iommu,
@@ -199,8 +210,9 @@ static int __must_check invalidate_sync(struct iommu *iommu,
 return 0;
 }
 
-int qinval_device_iotlb(struct iommu *iommu,
-u32 max_invs_pend, u16 sid, u16 size, u64 addr)
+int qinval_device_iotlb_sync(struct iommu *iommu,
+ u32 max_invs_pend,
+ u16 sid, u16 size, u64 addr)
 {
 unsigned long flags;
 unsigned int index;
@@ -229,15 +241,17 @@ int qinval_device_iotlb(struct iommu *iommu,
 qinval_update_qtail(iommu, index);
 spin_unlock_irqrestore(>register_lock, flags);
 
-return 0;
+return invalidate_sync(iommu, 1);
 }
 
-static void queue_invalidate_iec(struct iommu *iommu, u8 granu, u8 im, u16 
iidx)
+static int __must_check queue_invalidate_iec_sync(struct iommu *iommu,
+  u8 granu, u8 im, 

[Xen-devel] [PATCH v12 0/6] VT-d Device-TLB flush issue

[Xu, Quan]

From: Quan Xu 

This patches fix current timeout concern and also allow limited ATS support:

1. add a timeout parameter for device IOTLB invalidation

The parameter 'iommu_dev_iotlb_timeout' specifies the timeout
of device IOTLB invalidation in milliseconds. By default, the
timeout is 1000 milliseconds, which can be boot-time changed.

We also confirmed with VT-d hardware team that 1 milliseconds
is large enough for VT-d IOMMU internal invalidation.

the existing panic() is eliminated and we bubble up the timeout
of device IOTLB invalidation for further processing, as the
PCI-e Address Translation Services (ATS) mandates a timeout of
60 seconds for device IOTLB invalidation. Obviously we can't
spin for 60 seconds or otherwise Xen hypervisor hangs.

2. today we do Device-TLB flush synchronization after issuing flush
requests for all ATS devices belonging to a VM. Doing so however
imposes a limitation, i.e. that we can not figure out which flush
request is blocked in the flush queue list, based on VT-d spec.

To prepare correct Device-TLB flush timeout handling in next patch,
we change the behavior to synchronize for every Device-TLB flush
request. So the Device-TLB flush interface is changed a little bit,
by checking timeout within the function instead of outside of function.

Accordingly we also do a similar change for flush interfaces of
IOTLB/IEC/Context, i.e. moving synchronization into the function.
Since there is no user of a non-synced interface, we just rename
existing ones with _sync suffix.

3. move the domain crash logic up to the generic IOMMU layer

4. If Device-TLB flush timed out, we hide the target ATS device
immediately and crash the domain owning this ATS device. If
impacted domain is hardware domain, just throw out a warning.

By hiding the device, we make sure it can't be assigned to any
domain any longer (see device_assigned).

---
Not covered in this series:

a) Eliminate the panic() in IOMMU_WAIT_OP, used only in VT-d register 
read/write.
   Further discussion is required on whether and how to improve it.
b) Handle IOTLB/Context/IEC flush timeout (after v12 review, I try to send 
out
   brain storming).
---
Quan Xu (6):
  IOMMU: add a timeout parameter for device IOTLB invalidation
  vt-d: synchronize for Device-TLB flush one by one
  vt-d: convert conditionals of qi_ctrl->qinval_maddr into ASSERT()s
  IOMMU/x86: using a struct pci_dev* instead of SBDF
  IOMMU: move the domain crash logic up to the generic IOMMU layer
  vt-d: fix vt-d Device-TLB flush timeout issue

 docs/misc/xen-command-line.markdown |   9 ++
 xen/drivers/passthrough/amd/iommu_cmd.c |  11 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |   2 +-
 xen/drivers/passthrough/ats.h   |   6 +-
 xen/drivers/passthrough/iommu.c |  33 +-
 xen/drivers/passthrough/pci.c   |   6 +-
 xen/drivers/passthrough/vtd/extern.h|   6 +-
 xen/drivers/passthrough/vtd/iommu.c |  19 +++-
 xen/drivers/passthrough/vtd/qinval.c| 168 +++-
 xen/drivers/passthrough/vtd/x86/ats.c   |  23 ++--
 xen/drivers/passthrough/x86/ats.c   |  52 ++---
 xen/include/xen/iommu.h |   2 +
 xen/include/xen/pci.h   |   1 +
 13 files changed, 238 insertions(+), 100 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v12 1/6] IOMMU: add a timeout parameter for device IOTLB invalidation

[Xu, Quan]

From: Quan Xu 

The parameter 'iommu_dev_iotlb_timeout' specifies the timeout
of device IOTLB invalidation in milliseconds. By default, the
timeout is 1000 milliseconds, which can be boot-time changed.

We also confirmed with VT-d hardware team that 1 milliseconds
is large enough for VT-d IOMMU internal invalidation.

the existing panic() is eliminated and we bubble up the timeout
of device IOTLB invalidation for further processing, as the
PCI-e Address Translation Services (ATS) mandates a timeout of
60 seconds for device IOTLB invalidation. Obviously we can't
spin for 60 seconds or otherwise Xen hypervisor hangs.

Add a __must_check annotation. The followup patch titled
'VT-d IOTLB/Context/IEC flush issue' addresses the __mustcheck.
That is the other callers of this routine (two or three levels up)
ignore the return code. This patch does not address this but the
other does.

Signed-off-by: Quan Xu 

CC: Julien Grall 
CC: Jan Beulich 
CC: Kevin Tian 
CC: Feng Wu 
CC: Suravee Suthikulpanit 
---
v12:
   1. enhance commit message.
   2. change timeout from 1ms to 1000ms.
   3. change IOMMU_QI_TIMEOUT to VTD_QI_TIMEOUT, with VTD_QI_TIMEOUT
  having its MILLISECS() dropped.
   4. enhance the whole expression of 'timeout = ...'
   5. drop a blank line that doesn't belong here.
---
 docs/misc/xen-command-line.markdown  |  9 +
 xen/drivers/passthrough/iommu.c  |  3 +++
 xen/drivers/passthrough/vtd/qinval.c | 32 +---
 xen/include/xen/iommu.h  |  2 ++
 4 files changed, 35 insertions(+), 11 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 7a271c0..0046f0d 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1015,6 +1015,15 @@ debug hypervisor only).
 
 >> Enable IOMMU debugging code (implies `verbose`).
 
+### iommu\_dev\_iotlb\_timeout
+> `= `
+
+> Default: `1000`
+
+Specify the timeout of the device IOTLB invalidation in milliseconds.
+By default, the timeout is 1000 ms. When you see error 'Queue invalidate
+wait descriptor timed out', try increasing this value.
+
 ### iommu\_inclusive\_mapping (VT-d)
 > `= `
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index ef80b3c..7656aeb 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -24,6 +24,9 @@
 static void parse_iommu_param(char *s);
 static void iommu_dump_p2m_table(unsigned char key);
 
+unsigned int __read_mostly iommu_dev_iotlb_timeout = 1000;
+integer_param("iommu_dev_iotlb_timeout", iommu_dev_iotlb_timeout);
+
 /*
  * The 'iommu' parameter enables the IOMMU.  Optional comma separated
  * value may contain:
diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index aa7841a..4788d5f 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -28,6 +28,8 @@
 #include "vtd.h"
 #include "extern.h"
 
+#define VTD_QI_TIMEOUT 1
+
 static void print_qi_regs(struct iommu *iommu)
 {
 u64 val;
@@ -130,10 +132,10 @@ static void queue_invalidate_iotlb(struct iommu *iommu,
 spin_unlock_irqrestore(>register_lock, flags);
 }
 
-static int queue_invalidate_wait(struct iommu *iommu,
-u8 iflag, u8 sw, u8 fn)
+static int __must_check queue_invalidate_wait(struct iommu *iommu,
+  u8 iflag, u8 sw, u8 fn,
+  bool_t flush_dev_iotlb)
 {
-s_time_t start_time;
 volatile u32 poll_slot = QINVAL_STAT_INIT;
 unsigned int index;
 unsigned long flags;
@@ -163,14 +165,20 @@ static int queue_invalidate_wait(struct iommu *iommu,
 /* Now we don't support interrupt method */
 if ( sw )
 {
+s_time_t timeout;
+
 /* In case all wait descriptor writes to same addr with same data */
-start_time = NOW();
+timeout = NOW() + MILLISECS(flush_dev_iotlb ?
+iommu_dev_iotlb_timeout : VTD_QI_TIMEOUT);
+
 while ( poll_slot != QINVAL_STAT_DONE )
 {
-if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
+if ( NOW() > timeout )
 {
 print_qi_regs(iommu);
-panic("queue invalidate wait descriptor was not executed");
+printk(XENLOG_WARNING VTDPREFIX
+   " Queue invalidate wait descriptor timed out\n");
+return -ETIMEDOUT;
 }
 cpu_relax();
 }
@@ -180,12 +188,14 @@ static int queue_invalidate_wait(struct iommu *iommu,
 return -EOPNOTSUPP;
 }
 
-static int invalidate_sync(struct iommu *iommu)
+static int __must_check invalidate_sync(struct iommu *iommu,
+bool_t flush_dev_iotlb)
 {

[Xen-devel] [PATCH v12 4/6] IOMMU/x86: using a struct pci_dev* instead of SBDF

[Xu, Quan]

From: Quan Xu 

a struct pci_dev* instead of SBDF is stored inside struct
pci_ats_dev and parameter to enable_ats_device().

Signed-off-by: Quan Xu 

CC: Jan Beulich 
CC: Kevin Tian 
CC: Feng Wu 
CC: Suravee Suthikulpanit 
---
 xen/drivers/passthrough/amd/iommu_cmd.c | 11 +++---
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  2 +-
 xen/drivers/passthrough/ats.h   |  6 ++--
 xen/drivers/passthrough/vtd/iommu.c |  8 ++---
 xen/drivers/passthrough/vtd/x86/ats.c   | 20 ---
 xen/drivers/passthrough/x86/ats.c   | 52 +++--
 6 files changed, 62 insertions(+), 37 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c 
b/xen/drivers/passthrough/amd/iommu_cmd.c
index 7c9d9be..b3094f3 100644
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -298,24 +298,23 @@ void amd_iommu_flush_iotlb(u8 devfn, const struct pci_dev 
*pdev,
 if ( ats_pdev == NULL )
 return;
 
-if ( !pci_ats_enabled(ats_pdev->seg, ats_pdev->bus, ats_pdev->devfn) )
+if ( !pci_ats_enabled(pdev->seg, pdev->bus, pdev->devfn) )
 return;
 
-iommu = find_iommu_for_device(ats_pdev->seg,
-  PCI_BDF2(ats_pdev->bus, ats_pdev->devfn));
+iommu = find_iommu_for_device(pdev->seg, PCI_BDF2(pdev->bus, pdev->devfn));
 
 if ( !iommu )
 {
 AMD_IOMMU_DEBUG("%s: Can't find iommu for %04x:%02x:%02x.%u\n",
-__func__, ats_pdev->seg, ats_pdev->bus,
-PCI_SLOT(ats_pdev->devfn), PCI_FUNC(ats_pdev->devfn));
+__func__, pdev->seg, pdev->bus,
+PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
 return;
 }
 
 if ( !iommu_has_cap(iommu, PCI_CAP_IOTLB_SHIFT) )
 return;
 
-req_id = get_dma_requestor_id(iommu->seg, PCI_BDF2(ats_pdev->bus, devfn));
+req_id = get_dma_requestor_id(iommu->seg, PCI_BDF2(pdev->bus, devfn));
 queueid = req_id;
 maxpend = ats_pdev->ats_queue_depth & 0xff;
 
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 7761241..64ca78e 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -162,7 +162,7 @@ static void amd_iommu_setup_domain_device(
  !pci_ats_enabled(iommu->seg, bus, pdev->devfn) )
 {
 if ( devfn == pdev->devfn )
-enable_ats_device(iommu->seg, bus, devfn, iommu);
+enable_ats_device(iommu, pdev);
 
 amd_iommu_flush_iotlb(devfn, pdev, INV_IOMMU_ALL_PAGES_ADDRESS, 0);
 }
diff --git a/xen/drivers/passthrough/ats.h b/xen/drivers/passthrough/ats.h
index 5c91572..1359841 100644
--- a/xen/drivers/passthrough/ats.h
+++ b/xen/drivers/passthrough/ats.h
@@ -19,9 +19,7 @@
 
 struct pci_ats_dev {
 struct list_head list;
-u16 seg;
-u8 bus;
-u8 devfn;
+struct pci_dev *pci_dev;
 u16 ats_queue_depth;/* ATS device invalidation queue depth */
 const void *iommu;  /* No common IOMMU struct so use void pointer */
 };
@@ -34,7 +32,7 @@ struct pci_ats_dev {
 extern struct list_head ats_devices;
 extern bool_t ats_enabled;
 
-int enable_ats_device(int seg, int bus, int devfn, const void *iommu);
+int enable_ats_device(const void *iommu, struct pci_dev *pci_dev);
 void disable_ats_device(int seg, int bus, int devfn);
 struct pci_ats_dev *get_ats_device(int seg, int bus, int devfn);
 
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index f010612..1b0a0f0 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1461,8 +1461,8 @@ int domain_context_mapping_one(
 return rc;
 }
 
-static int domain_context_mapping(
-struct domain *domain, u8 devfn, const struct pci_dev *pdev)
+static int domain_context_mapping(struct domain *domain, u8 devfn,
+  struct pci_dev *pdev)
 {
 struct acpi_drhd_unit *drhd;
 int ret = 0;
@@ -1498,7 +1498,7 @@ static int domain_context_mapping(
 ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn,
  pdev);
 if ( !ret && devfn == pdev->devfn && ats_device(pdev, drhd) > 0 )
-enable_ats_device(seg, bus, devfn, drhd->iommu);
+enable_ats_device(drhd->iommu, pdev);
 
 break;
 
@@ -1994,7 +1994,7 @@ static int intel_iommu_enable_device(struct pci_dev *pdev)
 if ( ret <= 0 )
 return ret;
 
-ret = enable_ats_device(pdev->seg, pdev->bus, pdev->devfn, drhd->iommu);
+ret = enable_ats_device(drhd->iommu, pdev);
 
 return ret >= 0 ? 0 : ret;
 }
diff --git a/xen/drivers/passthrough/vtd/x86/ats.c 
b/xen/drivers/passthrough/vtd/x86/ats.c
index dfa4d30..a6c53ea 100644
--- 

[Xen-devel] [PATCH v12 5/6] IOMMU: move the domain crash logic up to the generic IOMMU layer

[Xu, Quan]

From: Quan Xu 

Signed-off-by: Quan Xu 

CC: Julien Grall 
CC: Kevin Tian 
CC: Feng Wu 
CC: Jan Beulich 
CC: Suravee Suthikulpanit 
---
 xen/drivers/passthrough/iommu.c | 30 --
 xen/drivers/passthrough/vtd/iommu.c | 11 +++
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 7656aeb..d793f5d 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -318,21 +318,47 @@ int iommu_iotlb_flush(struct domain *d, unsigned long gfn,
   unsigned int page_count)
 {
 const struct domain_iommu *hd = dom_iommu(d);
+int rc;
 
 if ( !iommu_enabled || !hd->platform_ops || !hd->platform_ops->iotlb_flush 
)
 return 0;
 
-return hd->platform_ops->iotlb_flush(d, gfn, page_count);
+rc = hd->platform_ops->iotlb_flush(d, gfn, page_count);
+if ( unlikely(rc) )
+{
+if ( !d->is_shutting_down && printk_ratelimit() )
+printk(XENLOG_ERR
+   "d%d: IOMMU IOTLB flush failed: %d, gfn %#lx, page count 
%u\n",
+   d->domain_id, rc, gfn, page_count);
+
+if ( !is_hardware_domain(d) )
+domain_crash(d);
+}
+
+return rc;
 }
 
 int iommu_iotlb_flush_all(struct domain *d)
 {
 const struct domain_iommu *hd = dom_iommu(d);
+int rc;
 
 if ( !iommu_enabled || !hd->platform_ops || 
!hd->platform_ops->iotlb_flush_all )
 return 0;
 
-return hd->platform_ops->iotlb_flush_all(d);
+rc = hd->platform_ops->iotlb_flush_all(d);
+if ( unlikely(rc) )
+{
+if ( !d->is_shutting_down && printk_ratelimit() )
+printk(XENLOG_ERR
+   "d%d: IOMMU IOTLB flush all failed: %d\n",
+   d->domain_id, rc);
+
+if ( !is_hardware_domain(d) )
+domain_crash(d);
+}
+
+return rc;
 }
 
 int __init iommu_setup(void)
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 1b0a0f0..82332c8 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1847,6 +1847,17 @@ int iommu_pte_flush(struct domain *d, u64 gfn, u64 *pte,
 }
 }
 
+if ( unlikely(rc) )
+{
+if ( !d->is_shutting_down && printk_ratelimit() )
+printk(XENLOG_ERR VTDPREFIX
+   " d%d: IOMMU pages flush failed: %d\n",
+   d->domain_id, rc);
+
+if ( !is_hardware_domain(d) )
+domain_crash(d);
+}
+
 return rc;
 }
 
-- 
1.9.1


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

Re: [Xen-devel] Change of max-ram-below-4g initial value breaks Xen

[Gerd Hoffmann]

On Do, 2016-06-23 at 17:18 +0100, Anthony PERARD wrote:
> On Thu, Jun 23, 2016 at 04:57:54PM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > How could xen_ram_init() find out if the value of max-ram-below-4g is
> > > the default or if a user have set it? Is there another way we could fix
> > > this?
> > 
> > Attached patch should fix it.  Patch survived a quick smoke test on kvm
> > so far, need to do some more testing tomorrow.  Can you give it a spin
> > on xen?
> 
> Thanks. Unfortunately, it does not work :(.
> 
> In this patch, max_ram_below_4g is set before the call to xen_ram_init()
> and xen_ram_init read it back (via object_property_get_int()).  So, in
> xen_ram_init, user_lowmem is not 0.

Ah, I see.  We do the split calculation twice on xen.  That is pretty
pointless.  New patch attached.

cheers,
  Gerd

From a1bb0d4f7a94e97102e7ea72d0a65de2a17b1160 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann 
Date: Thu, 23 Jun 2016 16:49:03 +0200
Subject: [PATCH] xen: fix ram init regression

Commit "8156d48 pc: allow raising low memory via max-ram-below-4g
option" causes a regression on xen, because it uses a different
memory split.

This patch initializes max-ram-below-4g to zero and leaves the
initialization to the memory initialization functions.  That way
they can pick different default values (max-ram-below-4g is zero
still) or use the user supplied value (max-ram-below-4g is non-zero).

Also skip the whole ram split calculation on Xen.  xen_ram_init()
does its own split calculation anyway so it is superfluous, also
this way xen_ram_init can actually see whenever max-ram-below-4g
is zero or not.

Signed-off-by: Gerd Hoffmann 
---
 hw/i386/pc.c  |  2 +-
 hw/i386/pc_piix.c | 52 +---
 hw/i386/pc_q35.c  |  3 +++
 xen-hvm.c |  3 +++
 4 files changed, 36 insertions(+), 24 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 7198ed5..66e1dae 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1886,7 +1886,7 @@ static void pc_machine_initfn(Object *obj)
 pc_machine_get_hotplug_memory_region_size,
 NULL, NULL, NULL, _abort);
 
-pcms->max_ram_below_4g = 0xe000; /* 3.5G */
+pcms->max_ram_below_4g = 0; /* use default */
 object_property_add(obj, PC_MACHINE_MAX_RAM_BELOW_4G, "size",
 pc_machine_get_max_ram_below_4g,
 pc_machine_set_max_ram_below_4g,
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 53bc968..f51fa77 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -108,37 +108,43 @@ static void pc_init1(MachineState *machine,
  *so legacy non-PAE guests can get as much memory as possible in
  *the 32bit address space below 4G.
  *
+ *  - Note that Xen has its own ram setp code in xen_ram_init(),
+ *called via xen_hvm_init().
+ *
  * Examples:
  *qemu -M pc-1.7 -m 4G(old default)-> 3584M low,  512M high
  *qemu -M pc -m 4G(new default)-> 3072M low, 1024M high
  *qemu -M pc,max-ram-below-4g=2G -m 4G -> 2048M low, 2048M high
  *qemu -M pc,max-ram-below-4g=4G -m 3968M  -> 3968M low (=4G-128M)
  */
-lowmem = pcms->max_ram_below_4g;
-if (machine->ram_size >= pcms->max_ram_below_4g) {
-if (pcmc->gigabyte_align) {
-if (lowmem > 0xc000) {
-lowmem = 0xc000;
-}
-if (lowmem & ((1ULL << 30) - 1)) {
-error_report("Warning: Large machine and max_ram_below_4g "
- "(%" PRIu64 ") not a multiple of 1G; "
- "possible bad performance.",
- pcms->max_ram_below_4g);
-}
-}
-}
-
-if (machine->ram_size >= lowmem) {
-pcms->above_4g_mem_size = machine->ram_size - lowmem;
-pcms->below_4g_mem_size = lowmem;
-} else {
-pcms->above_4g_mem_size = 0;
-pcms->below_4g_mem_size = machine->ram_size;
-}
-
 if (xen_enabled()) {
 xen_hvm_init(pcms, _memory);
+} else {
+if (!pcms->max_ram_below_4g) {
+pcms->max_ram_below_4g = 0xe000; /* default: 3.5G */
+}
+lowmem = pcms->max_ram_below_4g;
+if (machine->ram_size >= pcms->max_ram_below_4g) {
+if (pcmc->gigabyte_align) {
+if (lowmem > 0xc000) {
+lowmem = 0xc000;
+}
+if (lowmem & ((1ULL << 30) - 1)) {
+error_report("Warning: Large machine and max_ram_below_4g "
+ "(%" PRIu64 ") not a multiple of 1G; "
+ "possible bad performance.",
+ pcms->max_ram_below_4g);
+}
+}
+}
+
+if (machine->ram_size >= lowmem) {
+pcms->above_4g_mem_size 

[Xen-devel] [PATCH] MAINTAINERS: Add ARM scif serial driver

[Dirk Behme]

The scif-uart.c is an ARM specific UART driver for the Renesas RCar
SoC family.

Signed-off-by: Dirk Behme 
---

Note: This has been discussed in

https://lists.xen.org/archives/html/xen-devel/2016-06/msg03051.html

https://lists.xen.org/archives/html/xen-devel/2016-06/msg03062.html

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9a224d4..a8e0043 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -171,6 +171,7 @@ F:  xen/drivers/char/arm-uart.c
 F: xen/drivers/char/exynos4210-uart.c
 F: xen/drivers/char/omap-uart.c
 F: xen/drivers/char/pl011.c
+F: xen/drivers/char/scif-uart.c
 F: xen/drivers/passthrough/arm/
 
 CPU POOLS
-- 
2.9.0


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

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[Yu Zhang]

On 6/23/2016 6:33 PM, George Dunlap wrote:

On 23/06/16 08:37, Yu Zhang wrote:

On 6/22/2016 7:33 PM, George Dunlap wrote:

On 22/06/16 11:07, Yu Zhang wrote:

On 6/22/2016 5:47 PM, George Dunlap wrote:

On 22/06/16 10:29, Jan Beulich wrote:

On 22.06.16 at 11:16,  wrote:

On 22/06/16 07:39, Jan Beulich wrote:

On 21.06.16 at 16:38,  wrote:

On 21/06/16 10:47, Jan Beulich wrote:

And then - didn't we mean to disable that part of XenGT during
migration, i.e. temporarily accept the higher performance
overhead without the p2m_ioreq_server entries? In which case
flipping everything back to p2m_ram_rw after (completed or
canceled) migration would be exactly what we want. The (new
or previous) ioreq server should attach only afterwards, and
can then freely re-establish any p2m_ioreq_server entries it
deems necessary.


Well, I agree this part of XenGT should be disabled during
migration.
But in such
case I think it's device model's job to trigger the p2m type
flipping(i.e. by calling
HVMOP_set_mem_type).

I agree - this would seem to be the simpler model here, despite
(as
George validly says) the more consistent model would be for the
hypervisor to do the cleanup. Such cleanup would imo be
reasonable
only if there was an easy way for the hypervisor to enumerate
all
p2m_ioreq_server pages.

Well, for me, the "easy way" means we should avoid traversing
the whole ept
paging structure all at once, right?

Yes.

Does calling p2m_change_entry_type_global() not satisfy this
requirement?

Not really - that addresses the "low overhead" aspect, but not the
"enumerate all such entries" one.

I'm sorry, I think I'm missing something here.  What do we need the
enumeration for?

We'd need that if we were to do the cleanup in the hypervisor (as
we can't rely on all p2m entry re-calculation to have happened by
the time a new ioreq server registers for the type).

So you're afraid of this sequence of events?
1) Server A de-registered, triggering a ioreq_server -> ram_rw type
change
2) gfn N is marked as misconfigured
3) Server B registers and marks gfn N as ioreq_server
4) When N is accessed, the misconfiguration is resolved incorrectly to
ram_rw

But that can't happen, because misconfigured entries are resolved
before
setting a p2m entry; so at step 3, gfn N will be first set to
(non-misconfigured) ram_rw, then changed to (non-misconfigured)
ioreq_server.

Or is there another sequence of events that I'm missing?

Thanks for your reply, George. :)
If no log dirty is triggered during this process, your sequence is
correct.
However, if log dirty is triggered, we'll met problems. I have described
this
in previous mails :

http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02426.html

on Jun 20

and

http://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02575.html

on Jun 21

Right -- sorry, now I see the issue:

1. Server A marks gfn X as ioreq_server
2. Server A deregisters, gfn X misconfigured
3. Server B registers, marks gfn Y as ioreq_server
4. Logdirty mode enabled; gfn Y misconfigured
5. When X or Y are accessed, resolve_misconfigure() has no way of
telling whether the entry is from server A (which should be set to
logdirty) or from server B (which should be left as ioreq_server).

Exactly.  :)
Another simpler scenario would be
1. Server A marks gfn X as p2m_ioreq_server;
2. Logdirty mode enabled; gfn X misconfigured;
3. When X is written, it will not cause ept vioalation, but ept
misconfig, and the
resolve_misconfig() would set gfn X back to p2m_ram_rw, thereafter we
can not
track access to X;

Right, so this is a reason that simply making misconfigurations always
resolve ioreq_server into ram_rw isn't compatible with logdirty.


Note: Not resetting the p2m type for p2m_ioreq_server when
p2m->ioreq_server is
not NULL is suitable for this simpler scenario, but is not correct if
take your scenario
into account.

The core reason is I could not find a simple solution in
resolve_misconfig() to handle
handle both the outdated p2m_ioreq_server entries, the in-use ones and
to support
the logdirty feature at the same time.

Indeed; and as I said, the real problem is that
p2m_change_entry_type_global() isn't really properly abstracted; in
order to use it you need to know how it works and be careful not to use
it at the wrong time.

Short-term, thinking through a handful of the scenarios we want to
support should be good enough.  Long-term, making it more robust so that
we don't have to think so hard about is probably better.


In a sense this is a deficiency in the change_entry_type_global()
interface.  A common OS principle is "make the common case fast, and the
uncommon case correct".  The scenario described above seems to me to be
an uncommon case which is handled quickly but incorrectly; ideally we
should handle it correctly, even if it's not very quick.

Synchronously resolving a previous misconfig is probably the most
straightforward thing to do.  It 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 87893
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 87893
 build-armhf   5 xen-build fail REGR. vs. 87893
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-installfail REGR. vs. 87893

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 96150 
pass in 96176
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
96150

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  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-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-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
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  0a8c94fae993dd8f2b27fd4cc694f61c21de84bf
baseline version:
 xen  8fa31952e2d08ef63897c43b5e8b33475ebf5d93

Last test of basis87893  2016-03-29 13:49:52 Z   86 days
Failing since 92180  2016-04-20 17:49:21 Z   64 days   27 attempts
Testing same since96017  2016-06-20 17:22:27 Z3 days6 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Jan Beulich 
  Jim Paris 
  Stefan Hajnoczi 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  fail
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  blocked 
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-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 

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

[osstest service owner]

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

Regressions :-(

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

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

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

version targeted for testing:
 qemuu59a79f65ba1eb197609532b52df7d48617c75b33
baseline version:
 qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe

Last test of basis94856  2016-05-27 20:14:49 Z   27 days
Failing since 94983  2016-05-31 09:40:12 Z   23 days   32 attempts
Testing same since96175  2016-06-23 10:51:16 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alex Bligh 
  Alex Williamson 
  Alexander Graf 
  Alexey Kardashevskiy 
  Alistair Francis 
  Amit Shah 
  Andrea Arcangeli 
  Andrew Jeffery 
  Andrew Jones 
  Anthony PERARD 
  Anton Blanchard 
  Ard Biesheuvel 
  Artyom Tarasenko 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Cao jin 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 733c0c88c358ef76fc9182c654a4a55d36f44704
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   29 days
Failing since 94750  2016-05-25 03:43:08 Z   29 days   53 attempts
Testing same since96169  2016-06-23 08:14:42 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Chao Zhang 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Li 
  Gary Lin 
  Giri P Mudusuru 
  Hao Wu 
  Hegde Nagaraj P 
  hegdenag 
  Heyi Guo 
  Jan D?bro? 
  Jan Dabros 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Lu, ShifeiX A 
  lushifex 
  Marcin Wojtas 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Qiu Shumin 
  Ruiyu Ni 
  Ryan Harkin 
  Sami Mujawar 
  Satya Yarlagadda 
  Sriram Subramanian 
  Star Zeng 
  Tapan Shah 
  Thomas Palmer 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

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



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

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

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  a6288d5bb8b970646368afe167a24eeba95e9e03
baseline version:
 xen  6a35f1e1fb03bbb957828f9f2cf8bfc47df95ee6

Last test of basis96177  2016-06-23 13:02:08 Z0 days
Failing since 96182  2016-06-23 16:07:29 Z0 days2 attempts
Testing same since96189  2016-06-23 18:02:47 Z0 days1 attempts


People who touched revisions under test:
  Dirk Behme 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Stefano Stabellini 
  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=a6288d5bb8b970646368afe167a24eeba95e9e03
+ . ./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 
a6288d5bb8b970646368afe167a24eeba95e9e03
+ branch=xen-unstable-smoke
+ revision=a6288d5bb8b970646368afe167a24eeba95e9e03
+ . ./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.7-testing
+ '[' xa6288d5bb8b970646368afe167a24eeba95e9e03 = 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]'

Re: [Xen-devel] [PATCH v2 17/17] libxl/arm: Initialize domain param HVM_PARAM_CALLBACK_IRQ

[Julien Grall]

Hi Shannon,

On 23/06/2016 04:17, Shannon Zhao wrote:

From: Shannon Zhao 

If Xen guest boots with ACPI, the guest kernel will get the event
channel interrupt information via domain param HVM_PARAM_CALLBACK_IRQ.
Initialize that domain param.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arm_acpi.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 263b5de..8a42125 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -348,6 +348,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 {
 const libxl_version_info *vers;
 int rc;
+uint64_t val;

 /* convenience aliases */
 xc_domain_configuration_t *xc_config = >config;
@@ -373,7 +374,12 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
 make_acpi_dsdt(gc, dom);
 link_acpi_tables(gc, dom);

-return 0;
+/* Set the value of domain param HVM_PARAM_CALLBACK_IRQ. */
+val = (uint64_t)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
+val |= (2 << 8); /* Active-low level-sensitive  */
+val |= GUEST_EVTCHN_PPI & 0xff;
+return xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CALLBACK_IRQ,
+val);


This is not ACPI specific. It could be done even if ACPI is not inuse. 
Actually it what we are doing for DOM0. So we need to keep consistent.



 }

 /*



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi Shannon,

On 23/06/2016 04:17, Shannon Zhao wrote:

From: Shannon Zhao 

Copy all the ACPI tables to guest space so that UEFI or guest could
access them.

Signed-off-by: Shannon Zhao 
---
 tools/libxc/xc_dom_arm.c | 51 
 1 file changed, 51 insertions(+)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 64a8b67..6a0a5b7 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -63,6 +63,47 @@ static int setup_pgtables_arm(struct xc_dom_image *dom)

 /*  */

+static int xc_dom_copy_acpi(struct xc_dom_image *dom)
+{
+int rc, i;
+uint32_t pages_num = ROUNDUP(dom->acpitable_size, XC_PAGE_SHIFT) >>
+ XC_PAGE_SHIFT;
+const xen_pfn_t base = GUEST_ACPI_BASE >> XC_PAGE_SHIFT;
+xen_pfn_t *p2m;
+void *acpi_pages;
+
+p2m = malloc(pages_num * sizeof(*p2m));
+for (i = 0; i < pages_num; i++)
+p2m[i] = base + i;
+
+rc = xc_domain_populate_physmap_exact(dom->xch, dom->guest_domid,
+  pages_num, 0, 0, p2m);


H... it looks like this is working because libxl is setting the 
maximum size of the domain with some slack (1MB). However, I guess the 
slack was for something else. Wei, Stefano, Ian, can you confirm?



+if ( rc )
+{
+DOMPRINTF("%s: xc_domain_populate_physmap_exact failed with %d",
+  __FUNCTION__, rc);
+goto out;
+}
+
+acpi_pages = xc_map_foreign_range(dom->xch, dom->guest_domid,
+  PAGE_SIZE * pages_num,
+  PROT_READ | PROT_WRITE, base);
+if ( !acpi_pages )
+{
+DOMPRINTF("%s Can't map acpi_pages", __FUNCTION__);
+rc = -1;
+goto out;
+}
+
+memcpy(acpi_pages, dom->acpitable_blob, dom->acpitable_size);
+
+out:
+munmap(acpi_pages, pages_num * PAGE_SIZE);
+free(p2m);
+
+return rc;
+}
+
 static int alloc_magic_pages(struct xc_dom_image *dom)
 {

>  int rc, i;

@@ -100,6 +141,16 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
 dom->xenstore_evtchn);

+if ( dom->acpitable_blob && dom->acpitable_size > 0 )
+{
+rc = xc_dom_copy_acpi(dom);
+if ( rc != 0 )
+{
+DOMPRINTF("Unable to copy ACPI tables");
+return rc;
+}
+}


alloc_magic_pages looks the wrong place with this function. Any reason 
to not have a generic ACPI blob loading in xc_dom_core.c as we do for 
devicetree?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 15/17] libxl/arm: Add ACPI module

[Julien Grall]

Hi Shannon,

On 23/06/2016 04:17, Shannon Zhao wrote:

From: Shannon Zhao 

Add the ARM Multiboot module for ACPI, so UEFI or DomU can get the base
address of ACPI tables from it.

Signed-off-by: Shannon Zhao 
---
 docs/misc/arm/device-tree/acpi.txt | 23 +++
 tools/libxl/libxl_arm.c| 24 
 2 files changed, 47 insertions(+)
 create mode 100644 docs/misc/arm/device-tree/acpi.txt

diff --git a/docs/misc/arm/device-tree/acpi.txt 
b/docs/misc/arm/device-tree/acpi.txt
new file mode 100644
index 000..c39c4d0
--- /dev/null
+++ b/docs/misc/arm/device-tree/acpi.txt
@@ -0,0 +1,23 @@
+DomU ACPI module
+
+
+Xen toolstack passes the domU ACPI tables via a reference in the /chosen node 
of
+the device tree.
+
+Each node contains the following properties:
+
+- compatible
+
+   "xen,guest-acpi", "multiboot,module"
+
+- reg
+
+   Specifies the physical address and the length of the module.


We need to clarify how the firmware can find the RSDP. I.e will it 
always be at the beginning of the region?


Also, do we really need the size of the region? Would not be simpler to 
give the base address of RSDP?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 Altp2m cleanup 1/3] altp2m cleanup work

[Lai, Paul C]

I'm opposed to moving HVMOP_cmd_min and HVMOP_cmd_max somewhere else.  That 
would make reading/understanding of the macros more difficult.  This practice 
is common.  Also, If min & max are defined elsewhere, it will be more likely to 
lead to mistakes/bugs. 

The use of "_min" and "_max" should be quite clear and is common use in linux 
code; Yes, I know this is xen code and I see it here too.  If there's a better 
way, please propose the better.  Maybe you're suggesting the macro names should 
be all caps: 
  HVMOP_CMD_MIN, HVMOP_CMD_MAX
?  I was following the coding style within the file itself.

I'm open to suggestions,
-Paul

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com] 
Sent: Thursday, June 23, 2016 8:45 AM
To: Lai, Paul C 
Cc: Sahita, Ravi ; xen-devel 

Subject: Re: [PATCH v1 Altp2m cleanup 1/3] altp2m cleanup work

>>> On 21.06.16 at 18:04,  wrote:
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -479,6 +479,8 @@ struct xen_hvm_altp2m_op {
>  #define HVMOP_altp2m_set_mem_access   7
>  /* Change a p2m entry to have a different gfn->mfn mapping */
>  #define HVMOP_altp2m_change_gfn   8
> +#define HVMOP_cmd_min HVMOP_altp2m_get_domain_state
> +#define HVMOP_cmd_max HVMOP_altp2m_change_gfn

I don't see why these would need to be in the public interface. Nor were their 
names chosen to properly describe their purpose.

Jan


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

[Xen-devel] [xen-unstable-smoke test] 96182: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  9808c130f04ff331aca23beee262f3d83eb46e55
baseline version:
 xen  6a35f1e1fb03bbb957828f9f2cf8bfc47df95ee6

Last test of basis96177  2016-06-23 13:02:08 Z0 days
Testing same since96182  2016-06-23 16:07:29 Z0 days1 attempts


People who touched revisions under test:
  Dirk Behme 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  fail
 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


Not pushing.


commit 9808c130f04ff331aca23beee262f3d83eb46e55
Author: Dirk Behme 
Date:   Wed Jun 22 13:49:07 2016 +0200

xen/arm: drivers: scif: Don't overwrite firmware settings

Besides the 14MHz external clock, the SCIF might be clocked by an
internal 66MHz clock. If this is the case, the current clock source
selection breaks this configuration. Same for the settings done by
the firmware for data bits, stop bits and parity.

Completely drop this and rely on the settings done by the firmware.

Signed-off-by: Dirk Behme 
Reviewed-by: Julien Grall 
Signed-off-by: Stefano Stabellini 

commit 892a43cd9996a45875de14c06828dea859039430
Author: Dirk Behme 
Date:   Wed Jun 22 13:49:06 2016 +0200

xen/arm: drivers: scif: Remove dead code

The two struct members baud and clock_hz are in the end read only
variables nowhere used for anything useful. Removing them makes
the code much simpler without changing any functionality.

Signed-off-by: Dirk Behme 
Reviewed-by: Julien Grall 
Signed-off-by: Stefano Stabellini 

commit 3d5cb5a81f8c68e74be4074db141f3059409
Author: Julien Grall 
Date:   Thu Jun 23 17:50:19 2016 +0200

arm: rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe

The correct acronym for a guest physical frame is gfn. Also use
the recently introduced typesafe gfn/mfn to avoid mixing the two
different kind of frame.

Signed-off-by: Julien Grall 
Acked-by: Jan Beulich 
Acked-by: Stefano Stabellini 

commit b45a4f1ed6c865fc1222d71fc82e4b61771b261b
Author: Jan Beulich 
Date:   Thu Jun 23 17:48:45 2016 +0200

x86emul: support MOVBE and CRC32

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

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

commit d86ad7cb287b5ea05cfee20cdd277005d771886f
Author: Jan Beulich 
Date:   Thu Jun 23 17:47:44 2016 +0200

VMX: ensure MSR index enum and array remain in sync

... by using dedicated initializers. Also add an ASSERT() to make sure
unintentional addition of holes to the array gets noticed. Ditch
MSR_INDEX_SIZE as redundant with VMX_MSR_COUNT.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Acked-by: Kevin Tian 

commit 3528b5b4c3b1695ecc7af5622b32042aafbdf6f4
Author: Jan Beulich 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 95844
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
95844
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail REGR. vs. 95844

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

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

version targeted for testing:
 linuxd420f00c7bfb405884dd71fb7f87974f0d1be455
baseline version:
 linuxb5076139991c6b12c62346d9880eec1d4227d99f

Last test of basis95844  2016-06-17 01:16:12 Z6 days
Testing same since96161  2016-06-23 05:18:02 Z0 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  AceLan Kao 
  Al Viro 
  Andre Przywara 
  Arnd Bergmann 
  Ben Dooks 
  Ben Skeggs 
  Bob Copeland 
  Chris Wilson 
  Christoffer Dall 
  Daniel Vetter 
  Dibyajyoti Ghosh 
  Eric W. Biederman 
  Ewan D. Milne 
  Fred Veldini 
  Gavin Shan 
  H. Peter Anvin 
  Helge Deller 
  Herbert Xu 
  Ingo Molnar 
  Jack Wang 
  James Bottomley 

Re: [Xen-devel] [PATCH v2 13/17] libxl/arm: Link all ACPI tables into one buffer

[Julien Grall]

Hi Shannon,

On 23/06/16 04:17, Shannon Zhao wrote:

From: Shannon Zhao 

Link all ACPI tables into one buffer, fill in the addresses of
tables and update checksum of each table.


Is there any reason to not allocate the acpitable_blob buffer before 
hand (and even reallocate if not enough space) and write the table 
directly in it?


Regards,



Reserve a memory map space for ACPI tables.

Signed-off-by: Shannon Zhao 
---
  tools/libxl/libxl_arm_acpi.c  | 58 +++
  xen/include/public/arch-arm.h |  4 +++
  2 files changed, 62 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index d8779af..263b5de 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -285,6 +285,63 @@ static void calculate_checksum(void *table, uint32_t 
checksum_offset,
  p[checksum_offset] = -sum;
  }

+static void link_acpi_tables(libxl__gc *gc, struct xc_dom_image *dom)
+{
+uint64_t offset = 0;
+struct acpi_table_xsdt *xsdt;
+struct acpi_table_rsdp *rsdp;
+struct acpi_table_fadt *fadt;
+
+assert(dom->acpitable_size <= GUEST_ACPI_SIZE);
+dom->acpitable_blob = libxl__zalloc(gc, dom->acpitable_size);
+
+rsdp = (struct acpi_table_rsdp *)(dom->acpitable_blob + offset);
+memcpy(dom->acpitable_blob + offset, acpitables[RSDP].table,
+   acpitables[RSDP].size);
+offset += ROUNDUP(acpitables[RSDP].size, 3);
+
+xsdt = (struct acpi_table_xsdt *)(dom->acpitable_blob + offset);
+memcpy(dom->acpitable_blob + offset, acpitables[XSDT].table,
+   acpitables[XSDT].size);
+rsdp->xsdt_physical_address = GUEST_ACPI_BASE + offset;
+calculate_checksum(rsdp, offsetof(struct acpi_table_header, checksum),
+   acpitables[RSDP].size);
+offset += ROUNDUP(acpitables[XSDT].size, 3);
+
+memcpy(dom->acpitable_blob + offset, acpitables[MADT].table,
+   acpitables[MADT].size);
+calculate_checksum(dom->acpitable_blob + offset,
+   offsetof(struct acpi_table_header, checksum),
+   acpitables[MADT].size);
+xsdt->table_offset_entry[0] = GUEST_ACPI_BASE + offset;
+offset += ROUNDUP(acpitables[MADT].size, 3);
+
+memcpy(dom->acpitable_blob + offset, acpitables[GTDT].table,
+   acpitables[GTDT].size);
+calculate_checksum(dom->acpitable_blob + offset,
+   offsetof(struct acpi_table_header, checksum),
+   acpitables[GTDT].size);
+xsdt->table_offset_entry[1] = GUEST_ACPI_BASE + offset;
+offset += ROUNDUP(acpitables[GTDT].size, 3);
+
+fadt = (struct acpi_table_fadt *)(dom->acpitable_blob + offset);
+memcpy(dom->acpitable_blob + offset, acpitables[FADT].table,
+   acpitables[FADT].size);
+xsdt->table_offset_entry[2] = GUEST_ACPI_BASE + offset;
+calculate_checksum(xsdt, offsetof(struct acpi_table_header, checksum),
+   acpitables[XSDT].size);
+offset += ROUNDUP(acpitables[FADT].size, 3);
+
+memcpy(dom->acpitable_blob + offset, acpitables[DSDT].table,
+   acpitables[DSDT].size);
+calculate_checksum(dom->acpitable_blob + offset,
+   offsetof(struct acpi_table_header, checksum),
+   acpitables[DSDT].size);
+fadt->dsdt = GUEST_ACPI_BASE + offset;
+calculate_checksum(fadt, offsetof(struct acpi_table_header, checksum),
+   acpitables[FADT].size);
+}
+
  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
  libxl__domain_build_state *state,
  struct xc_dom_image *dom)
@@ -314,6 +371,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,

  make_acpi_fadt(gc, dom);
  make_acpi_dsdt(gc, dom);
+link_acpi_tables(gc, dom);

  return 0;
  }
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 05e4a58..0911d16 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -407,6 +407,10 @@ typedef uint64_t xen_callback_t;
  #define GUEST_GICV3_GICR0_BASE 0x0302ULL/* vCPU0 - vCPU127 */
  #define GUEST_GICV3_GICR0_SIZE 0x0100ULL

+/* ACPI tables physical address */
+#define GUEST_ACPI_BASE 0x2000ULL
+#define GUEST_ACPI_SIZE 0x0020ULL
+
  /*
   * 16MB == 4096 pages reserved for guest to use as a region to map its
   * grant table in.



--
Julien Grall

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

[Xen-devel] [PATCH v6 5/5] x86/vm_event: Add HVM debug exception vm_events

[Tamas K Lengyel]

Since in-guest debug exceptions are now unconditionally trapped to Xen, adding
a hook for vm_event subscribers to tap into this new always-on guest event. We
rename along the way hvm_event_breakpoint_type to hvm_event_type to better
match the various events that can be passed with it. We also introduce the
necessary monitor_op domctl's to enable subscribing to the events.

This patch also provides monitor subscribers to int3 events proper access
to the instruction length necessary for accurate event-reinjection. Without
this subscribers manually have to evaluate if the int3 instruction has any
prefix attached which would change the instruction length.

Signed-off-by: Tamas K Lengyel 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Razvan Cojocaru 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 

v6: Add comment describing rc condition values for the monitor call
v5: Transmit the proper insn_length for int3 events as well to fix
 the current bug with prefixed int3 instructions.
---
 tools/libxc/include/xenctrl.h   |  3 +-
 tools/libxc/xc_monitor.c| 25 +++
 tools/tests/xen-access/xen-access.c | 63 -
 xen/arch/x86/hvm/monitor.c  | 21 +++--
 xen/arch/x86/hvm/vmx/vmx.c  | 55 +---
 xen/arch/x86/monitor.c  | 16 ++
 xen/include/asm-x86/domain.h|  2 ++
 xen/include/asm-x86/hvm/monitor.h   |  7 +++--
 xen/include/asm-x86/monitor.h   |  3 +-
 xen/include/public/domctl.h |  6 
 xen/include/public/vm_event.h   | 14 +++--
 11 files changed, 186 insertions(+), 29 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 4f5d954..4a85b4a 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2165,7 +2165,8 @@ int xc_monitor_software_breakpoint(xc_interface *xch, 
domid_t domain_id,
bool enable);
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
  bool enable, bool sync);
-
+int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
+bool enable, bool sync);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 78131b2..264992c 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -156,3 +156,28 @@ int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t 
domain_id,
 
 return do_domctl(xch, );
 }
+
+int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
+bool enable, bool sync)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION;
+domctl.u.monitor_op.u.debug_exception.sync = sync;
+
+return do_domctl(xch, );
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index f26e723..e615476 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -53,6 +53,10 @@
 #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
 #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
 
+/* From xen/include/asm-x86/processor.h */
+#define X86_TRAP_DEBUG  1
+#define X86_TRAP_INT3   3
+
 typedef struct vm_event {
 domid_t domain_id;
 xenevtchn_handle *xce_handle;
@@ -333,7 +337,7 @@ void usage(char* progname)
 {
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
-fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec");
+fprintf(stderr, "|breakpoint|altp2m_write|altp2m_exec|debug");
 #endif
 fprintf(stderr,
 "\n"
@@ -354,10 +358,12 @@ int main(int argc, char *argv[])
 xc_interface *xch;
 xenmem_access_t default_access = XENMEM_access_rwx;
 xenmem_access_t after_first_access = XENMEM_access_rwx;
+int memaccess = 0;
 int required = 0;
 int breakpoint = 0;
 int shutting_down = 0;
 int altp2m = 0;
+int debug = 0;
 uint16_t altp2m_view_id = 0;
 
 char* progname = argv[0];
@@ -391,11 +397,13 @@ int main(int argc, char *argv[])
 {
 default_access = XENMEM_access_rx;
 after_first_access = XENMEM_access_rwx;
+memaccess = 1;
 }
 else 

[Xen-devel] [PATCH v6 1/5] monitor: Rename vm_event_monitor_get_capabilities

[Tamas K Lengyel]

The monitor_get_capabilities check actually belongs to the monitor subsystem so
relocating and renaming it to sanitize the code's name and location. Mechanical
patch, no code changes introduced.

Signed-off-by: Tamas K Lengyel 
Acked-by: Andrew Cooper 
Acked-by: Razvan Cojocaru 
Acked-by: Julien Grall 
---
Cc: Jan Beulich 
Cc: Stefano Stabellini 
---
 xen/arch/x86/monitor.c |  2 +-
 xen/common/monitor.c   |  5 ++---
 xen/include/asm-arm/monitor.h  | 11 ++-
 xen/include/asm-arm/vm_event.h |  9 -
 xen/include/asm-x86/monitor.h  | 23 +++
 xen/include/asm-x86/vm_event.h | 23 ---
 6 files changed, 36 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index afc8537..a271161 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -226,7 +226,7 @@ int arch_monitor_domctl_event(struct domain *d,
 
 default:
 /*
- * Should not be reached unless vm_event_monitor_get_capabilities() is
+ * Should not be reached unless arch_monitor_get_capabilities() is
  * not properly implemented.
  */
 ASSERT_UNREACHABLE();
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index d950a7c..7c3d1c8 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -24,7 +24,6 @@
 #include 
 #include 
 #include 
-#include 
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *mop)
 {
@@ -48,12 +47,12 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 if ( unlikely(mop->event > 31) )
 return -EINVAL;
 /* Check if event type is available. */
-if ( unlikely(!(vm_event_monitor_get_capabilities(d) & (1U << 
mop->event))) )
+if ( unlikely(!(arch_monitor_get_capabilities(d) & (1U << 
mop->event))) )
 return -EOPNOTSUPP;
 break;
 
 case XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES:
-mop->event = vm_event_monitor_get_capabilities(d);
+mop->event = arch_monitor_get_capabilities(d);
 return 0;
 
 default:
diff --git a/xen/include/asm-arm/monitor.h b/xen/include/asm-arm/monitor.h
index 478f5e9..4af707a 100644
--- a/xen/include/asm-arm/monitor.h
+++ b/xen/include/asm-arm/monitor.h
@@ -39,7 +39,7 @@ int arch_monitor_domctl_event(struct domain *d,
 /*
  * No arch-specific monitor vm-events on ARM.
  *
- * Should not be reached unless vm_event_monitor_get_capabilities() is not
+ * Should not be reached unless arch_monitor_get_capabilities() is not
  * properly implemented.
  */
 ASSERT_UNREACHABLE();
@@ -59,4 +59,13 @@ void arch_monitor_cleanup_domain(struct domain *d)
 /* No arch-specific domain cleanup on ARM. */
 }
 
+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
+{
+uint32_t capabilities = 0;
+
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+
+return capabilities;
+}
+
 #endif /* __ASM_ARM_MONITOR_H__ */
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 014d9ba..a3fc4ce 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -59,13 +59,4 @@ static inline void vm_event_fill_regs(vm_event_request_t 
*req)
 /* Not supported on ARM. */
 }
 
-static inline uint32_t vm_event_monitor_get_capabilities(struct domain *d)
-{
-uint32_t capabilities = 0;
-
-capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
-
-return capabilities;
-}
-
 #endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 84e3a3a..94b6768 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -63,6 +63,29 @@ int arch_monitor_domctl_op(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 return rc;
 }
 
+static inline uint32_t arch_monitor_get_capabilities(struct domain *d)
+{
+uint32_t capabilities = 0;
+
+/*
+ * At the moment only Intel HVM domains are supported. However, event
+ * delivery could be extended to AMD and PV domains.
+ */
+if ( !is_hvm_domain(d) || !cpu_has_vmx )
+return capabilities;
+
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+
+/* Since we know this is on VMX, we can just call the hvm func */
+if ( hvm_is_singlestep_supported() )
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+
+return capabilities;
+}
+
 int arch_monitor_domctl_event(struct domain *d,
   struct xen_domctl_monitor_op *mop);
 
diff --git a/xen/include/asm-x86/vm_event.h 

[Xen-devel] [PATCH v6 3/5] monitor: Rename hvm/event to hvm/monitor

[Tamas K Lengyel]

Mechanical renaming to better describe that the code in hvm/event is part of
the monitor subsystem.

Signed-off-by: Tamas K Lengyel 
Acked-by: Kevin Tian 
Acked-by: Razvan Cojocaru 
Acked-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: Jun Nakajima 
---
 xen/arch/x86/hvm/Makefile  |  2 +-
 xen/arch/x86/hvm/hvm.c | 12 +--
 xen/arch/x86/hvm/{event.c => monitor.c}| 17 ---
 xen/arch/x86/hvm/vmx/vmx.c | 13 +--
 xen/include/asm-x86/hvm/{event.h => monitor.h} | 30 +-
 5 files changed, 38 insertions(+), 36 deletions(-)
 rename xen/arch/x86/hvm/{event.c => monitor.c} (88%)
 rename xen/include/asm-x86/hvm/{event.h => monitor.h} (59%)

diff --git a/xen/arch/x86/hvm/Makefile b/xen/arch/x86/hvm/Makefile
index 8bc55a9..f750d13 100644
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -3,7 +3,6 @@ subdir-y += vmx
 
 obj-y += asid.o
 obj-y += emulate.o
-obj-y += event.o
 obj-y += hpet.o
 obj-y += hvm.o
 obj-y += i8254.o
@@ -11,6 +10,7 @@ obj-y += intercept.o
 obj-y += io.o
 obj-y += ioreq.o
 obj-y += irq.o
+obj-y += monitor.o
 obj-y += mtrr.o
 obj-y += nestedhvm.o
 obj-y += pmtimer.o
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 337a119..ef18949 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -60,7 +60,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -1961,7 +1961,7 @@ int hvm_handle_xsetbv(u32 index, u64 new_bv)
 {
 int rc;
 
-hvm_event_crX(XCR0, new_bv, current->arch.xcr0);
+hvm_monitor_crX(XCR0, new_bv, current->arch.xcr0);
 
 rc = handle_xsetbv(index, new_bv);
 if ( rc )
@@ -2197,7 +2197,7 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
 {
 ASSERT(v->arch.vm_event);
 
-if ( hvm_event_crX(CR0, value, old_value) )
+if ( hvm_monitor_crX(CR0, value, old_value) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
 v->arch.vm_event->write_data.do_write.cr0 = 1;
@@ -2299,7 +2299,7 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 {
 ASSERT(v->arch.vm_event);
 
-if ( hvm_event_crX(CR3, value, old) )
+if ( hvm_monitor_crX(CR3, value, old) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
 v->arch.vm_event->write_data.do_write.cr3 = 1;
@@ -2379,7 +2379,7 @@ int hvm_set_cr4(unsigned long value, bool_t may_defer)
 {
 ASSERT(v->arch.vm_event);
 
-if ( hvm_event_crX(CR4, value, old_cr) )
+if ( hvm_monitor_crX(CR4, value, old_cr) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
 v->arch.vm_event->write_data.do_write.cr4 = 1;
@@ -3765,7 +3765,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 v->arch.vm_event->write_data.msr = msr;
 v->arch.vm_event->write_data.value = msr_content;
 
-hvm_event_msr(msr, msr_content);
+hvm_monitor_msr(msr, msr_content);
 return X86EMUL_OKAY;
 }
 
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/monitor.c
similarity index 88%
rename from xen/arch/x86/hvm/event.c
rename to xen/arch/x86/hvm/monitor.c
index 8fdb6f5..f0ab33a 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -1,5 +1,5 @@
 /*
- * arch/x86/hvm/event.c
+ * arch/x86/hvm/monitor.c
  *
  * Arch-specific hardware virtual machine event abstractions.
  *
@@ -7,6 +7,7 @@
  * Copyright (c) 2005, International Business Machines Corporation.
  * Copyright (c) 2008, Citrix Systems, Inc.
  * Copyright (c) 2016, Bitdefender S.R.L.
+ * Copyright (c) 2016, Tamas K Lengyel (ta...@tklengyel.com)
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -22,12 +23,12 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
 
-bool_t hvm_event_cr(unsigned int index, unsigned long value, unsigned long old)
+bool_t hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long 
old)
 {
 struct vcpu *curr = current;
 struct arch_domain *ad = >domain->arch;
@@ -54,7 +55,7 @@ bool_t hvm_event_cr(unsigned int index, unsigned long value, 
unsigned long old)
 return 0;
 }
 
-void hvm_event_msr(unsigned int msr, uint64_t value)
+void hvm_monitor_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
 
@@ -86,8 +87,8 @@ static inline unsigned long gfn_of_rip(unsigned long rip)
 return paging_gva_to_gfn(curr, sreg.base + rip, );
 }
 
-int hvm_event_breakpoint(unsigned long rip,
- enum hvm_event_breakpoint_type type)
+int hvm_monitor_breakpoint(unsigned 

[Xen-devel] [PATCH v6 4/5] vm_event: clear up return value of vm_event_monitor_traps

[Tamas K Lengyel]

The return value has not been clearly defined, with the function
never returning 0 which seemingly indicated a condition where the
guest should crash.

In this patch we define -rc as error condition where a subscriber is
present but an error prevented the notification from being sent;
0 where there is no subscriber or the notification was sent and the vCPU
is not paused (i.e. safe to continue execution as normal); and 1 where the
notification was sent with the vCPU paused and we are waiting for a
response.

Signed-off-by: Tamas K Lengyel 
Reviewed-by: Jan Beulich 
Acked-by: Razvan Cojocaru 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Andrew Cooper 

v6: Remove unnecessary else clause in vmx
---
 xen/arch/x86/hvm/monitor.c | 4 ++--
 xen/arch/x86/hvm/vmx/vmx.c | 6 +++---
 xen/common/vm_event.c  | 5 +++--
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index f0ab33a..472926c 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -48,8 +48,8 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 .u.write_ctrlreg.old_value = old
 };
 
-vm_event_monitor_traps(curr, sync, );
-return 1;
+if ( vm_event_monitor_traps(curr, sync, ) >= 0 )
+return 1;
 }
 
 return 0;
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index a56926c..03fcba7 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3388,11 +3388,11 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 break;
 }
 else {
-int handled =
+int rc =
   hvm_monitor_breakpoint(regs->eip,
  HVM_MONITOR_SOFTWARE_BREAKPOINT);
 
-if ( handled < 0 ) 
+if ( !rc )
 {
 struct hvm_trap trap = {
 .vector = TRAP_int3,
@@ -3406,7 +3406,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 hvm_inject_trap();
 break;
 }
-else if ( handled )
+if ( rc > 0 )
 break;
 }
 
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index ca1eced..b303180 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -806,7 +806,7 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
  * If there was no ring to handle the event, then
  * simply continue executing normally.
  */
-return 1;
+return 0;
 default:
 return rc;
 };
@@ -815,6 +815,7 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
 {
 req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
 vm_event_vcpu_pause(v);
+rc = 1;
 }
 
 if ( altp2m_active(d) )
@@ -826,7 +827,7 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
 vm_event_fill_regs(req);
 vm_event_put_request(d, >vm_event->monitor, req);
 
-return 1;
+return rc;
 }
 
 /*
-- 
2.8.1


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

[Xen-devel] [PATCH v6 2/5] monitor: Rename vm_event_monitor_guest_request

[Tamas K Lengyel]

Mechanical renaming and relocation to the monitor subsystem.

Signed-off-by: Tamas K Lengyel 
Acked-by: Razvan Cojocaru 
Acked-by: Jan Beulich 
Acked-by: Julien Grall 
---
Cc: Stefano Stabellini 
Cc: Andrew Cooper 
---
 xen/arch/arm/hvm.c |  4 ++--
 xen/arch/x86/hvm/hvm.c |  3 ++-
 xen/common/monitor.c   | 17 +
 xen/common/vm_event.c  | 16 
 xen/include/xen/monitor.h  |  1 +
 xen/include/xen/vm_event.h |  2 --
 6 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index c01123a..d999bde 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
@@ -75,7 +75,7 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 
 case HVMOP_guest_request_vm_event:
 if ( guest_handle_is_null(arg) )
-vm_event_monitor_guest_request();
+monitor_guest_request();
 else
 rc = -EINVAL;
 break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index ffc3395..337a119 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -5753,7 +5754,7 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 case HVMOP_guest_request_vm_event:
 if ( guest_handle_is_null(arg) )
-vm_event_monitor_guest_request();
+monitor_guest_request();
 else
 rc = -EINVAL;
 break;
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 7c3d1c8..436214a 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -84,6 +85,22 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 return 0;
 }
 
+void monitor_guest_request(void)
+{
+struct vcpu *curr = current;
+struct domain *d = curr->domain;
+
+if ( d->monitor.guest_request_enabled )
+{
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_GUEST_REQUEST,
+.vcpu_id = curr->vcpu_id,
+};
+
+vm_event_monitor_traps(curr, d->monitor.guest_request_sync, );
+}
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 1ba12cb..ca1eced 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -829,22 +829,6 @@ int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
 return 1;
 }
 
-void vm_event_monitor_guest_request(void)
-{
-struct vcpu *curr = current;
-struct domain *d = curr->domain;
-
-if ( d->monitor.guest_request_enabled )
-{
-vm_event_request_t req = {
-.reason = VM_EVENT_REASON_GUEST_REQUEST,
-.vcpu_id = curr->vcpu_id,
-};
-
-vm_event_monitor_traps(curr, d->monitor.guest_request_sync, );
-}
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/monitor.h b/xen/include/xen/monitor.h
index 7015e6d..204d5cc 100644
--- a/xen/include/xen/monitor.h
+++ b/xen/include/xen/monitor.h
@@ -26,5 +26,6 @@ struct domain;
 struct xen_domctl_monitor_op;
 
 int monitor_domctl(struct domain *d, struct xen_domctl_monitor_op *op);
+void monitor_guest_request(void);
 
 #endif /* __XEN_MONITOR_H__ */
diff --git a/xen/include/xen/vm_event.h b/xen/include/xen/vm_event.h
index beda9fe..89e6243 100644
--- a/xen/include/xen/vm_event.h
+++ b/xen/include/xen/vm_event.h
@@ -81,8 +81,6 @@ void vm_event_vcpu_unpause(struct vcpu *v);
 int vm_event_monitor_traps(struct vcpu *v, uint8_t sync,
vm_event_request_t *req);
 
-void vm_event_monitor_guest_request(void);
-
 #endif /* __VM_EVENT_H__ */
 
 
-- 
2.8.1


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

Re: [Xen-devel] [PATCH v2 12/17] libxl/arm: Add a helper to calculate the ACPI table checksum

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:

From: Shannon Zhao 

Signed-off-by: Shannon Zhao 
---
  tools/libxl/libxl_arm_acpi.c | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 45fc354..d8779af 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -270,6 +270,21 @@ static void make_acpi_dsdt(libxl__gc *gc, struct 
xc_dom_image *dom)
  dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
  }

+static void calculate_checksum(void *table, uint32_t checksum_offset,
+   uint32_t length)


This will break compilation and therefore bisection as nobody is using 
this function. Please make sure that all the patch can build one by one.



+{
+uint8_t *p, sum = 0;
+
+p = table;
+p[checksum_offset] = 0;
+
+while ( length-- )
+sum = sum + *p++;
+
+p = table;
+p[checksum_offset] = -sum;
+}
+
  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
  libxl__domain_build_state *state,
  struct xc_dom_image *dom)



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:

[...]


diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 264b6ef..5347480 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -77,7 +77,29 @@ endif

  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
  LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
-LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
+LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
+
+vpath iasl $(PATH)
+libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
+   $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
+
+libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
+   awk 'NR > 1 {print s} {s=$$0}' $< > $@
+   ./libxl_mk_dsdt_arm >> $@
+
+libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
+   iasl -vs -p $* -tc $*.asl
+   sed -e 's/AmlCode/$*/g' $*.hex >$@
+   echo "int $*_len=sizeof($*);" >>$@
+   rm -f $*.aml $*.hex
+


I don't like the idea to add iasl as a dependency for all ARM platforms. 
For instance ARMv7 platform will not use ACPI, but we still ask users to 
install iasl. So I think we should allow the user to opt-in/opt-out for 
ACPI.


Any opinions?


+iasl:
+   @echo
+   @echo "ACPI ASL compiler (iasl) is needed"
+   @echo "Download and install Intel ACPI CA from"
+   @echo "http://acpica.org/downloads/;
+   @echo
+   @exit 1


It is really a pain to discover the dependency in the middle of a build. 
The presence of iasl should be done by the configure.




  libxl_arm_acpi.o: libxl_arm_acpi.c
$(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index 353d774..45fc354 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -54,6 +54,9 @@ enum {
  NUMS,
  };

+extern unsigned char libxl_dsdt_anycpu_arm[];
+extern int libxl_dsdt_anycpu_arm_len;


Not sure this is the right place to mention it, but I don't find the 
actual declaration.


Both variables should be const and _hidden. Also, the *_len should be at 
least const int.



+
  struct acpitable {
  void *table;
  size_t size;
@@ -256,6 +259,17 @@ static void make_acpi_fadt(libxl__gc *gc, struct 
xc_dom_image *dom)
  dom->acpitable_size += ROUNDUP(acpitables[FADT].size, 3);
  }

+static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+acpitables[DSDT].table = libxl__zalloc(gc, libxl_dsdt_anycpu_arm_len);
+memcpy(acpitables[DSDT].table, libxl_dsdt_anycpu_arm,
+   libxl_dsdt_anycpu_arm_len);
+
+acpitables[DSDT].size = libxl_dsdt_anycpu_arm_len;
+/* Align to 64bit. */
+dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
+}
+
  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
  libxl__domain_build_state *state,
  struct xc_dom_image *dom)
@@ -284,6 +298,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
return rc;

  make_acpi_fadt(gc, dom);
+make_acpi_dsdt(gc, dom);

  return 0;
  }
diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
index 9b58de6..b0fd9ce 100644
--- a/tools/libxl/libxl_arm_acpi.h
+++ b/tools/libxl/libxl_arm_acpi.h
@@ -19,6 +19,8 @@

  #include 

+#define DOMU_MAX_VCPUS 128
+


I would rather define the maximum number of VCPUS in public/arch_arm.h 
to avoid defining the current number of vCPUs supported in multiple places.



  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
  libxl__domain_build_state *state,
  struct xc_dom_image *dom);
diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl 
b/tools/libxl/libxl_empty_dsdt_arm.asl
new file mode 100644
index 000..005fa6a
--- /dev/null
+++ b/tools/libxl/libxl_empty_dsdt_arm.asl
@@ -0,0 +1,22 @@
+/**
+ * DSDT for Xen ARM DomU
+ *
+ * Copyright (c) 2004, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ */
+
+DefinitionBlock ("DSDT.aml", "DSDT", 3, "XenARM", "Xen DSDT", 1)
+{
+
+}
diff --git a/tools/libxl/libxl_mk_dsdt_arm.c b/tools/libxl/libxl_mk_dsdt_arm.c
new file mode 100644
index 000..96fadbd
--- /dev/null
+++ b/tools/libxl/libxl_mk_dsdt_arm.c


Can we share the code from tools/firmware/acpi/mk_dsdt.c?


@@ 

Re: [Xen-devel] [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Julien Grall]

On 23/06/16 17:26, Julien Grall wrote:

  enum {
  RSDP,
  XSDT,
@@ -110,6 +113,30 @@ static void make_acpi_xsdt(libxl__gc *gc, struct
xc_dom_image *dom)
  dom->acpitable_size += ROUNDUP(acpitables[XSDT].size, 3);
  }

+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_table_gtdt *gtdt;
+size_t size = sizeof(*gtdt);
+
+gtdt = libxl__zalloc(gc, size);
+
+gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
+gtdt->non_secure_el1_flags =
+ (ACPI_LEVEL_SENSITIVE <<
ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW <<
ACPI_GTDT_INTERRUPT_POLARITY);
+gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
+gtdt->virtual_timer_flags =
+ (ACPI_LEVEL_SENSITIVE <<
ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW <<
ACPI_GTDT_INTERRUPT_POLARITY);
+
+make_acpi_header(>header, "GTDT", size, 2);
+
+acpitables[GTDT].table = gtdt;
+acpitables[GTDT].size = size;
+/* Align to 64bit. */
+dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);


I am not sure how ROUNDUP(..., 3) will align to 64-bit.


Hmmm I found why. The ROUNDUP macro in libxl is taking an order which is 
odd.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] RFC: XenSock brainstorming

[Stefano Stabellini]

Although discussing the goals is fun, feedback on the design of the
protocol is particularly welcome.

On Thu, 23 Jun 2016, Stefano Stabellini wrote:
> Now that Xen 4.7 is out of the door, any more feedback on this?
> 
> On Mon, 6 Jun 2016, Stefano Stabellini wrote:
> > Hi all,
> > 
> > a couple of months ago I started working on a new PV protocol for
> > virtualizing syscalls. I named it XenSock, as its main purpose is to
> > allow the implementation of the POSIX socket API in a domain other than
> > the one of the caller. It allows connect, accept, recvmsg, sendmsg, etc
> > to be implemented directly in Dom0. In a way this is conceptually
> > similar to virtio-9pfs, but for sockets rather than filesystem APIs.
> > See this diagram as reference:
> > 
> > https://docs.google.com/presentation/d/1z4AICTY2ejAjZ-Ul15GTL3i_wcmhKQJA7tcXwhI3dys/edit?usp=sharing
> > 
> > The frontends and backends could live either in userspace or kernel
> > space, with different trade-offs. My current prototype is based on Linux
> > kernel drivers but it would be nice to have userspace drivers too.
> > Discussing where the drivers could be implemented it's beyond the scope
> > of this email.
> > 
> > 
> > # Goals
> > 
> > The goal of the protocol is to provide networking capabilities to any
> > guests, with the following added benefits:
> > 
> > * guest networking should work out of the box with VPNs, wireless
> >   networks and any other complex network configurations in Dom0
> > 
> > * guest services should listen on ports bound directly to Dom0 IP
> >   addresses, fitting naturally in a Docker based workflow, where guests
> >   are Docker containers
> > 
> > * Dom0 should have full visibility on the guest behavior and should be
> >   able to perform inexpensive filtering and manipulation of guest calls
> > 
> > * XenSock should provide excellent performance. Unoptimized early code
> >   reaches 22 Gbit/sec TCP single stream and scales to 60 Gbit/sec with 3
> >   streams.
> > 
> > 
> > # Status
> > 
> > I would like to get feedback on the high level architecture, the data
> > path and the ring formats.
> > 
> > Beware that protocol and drivers are in their very early days. I don't
> > have all the information to write a design document yet. The ABI is
> > neither complete nor stable.
> > 
> > The code is not ready for xen-devel yet, but I would be happy to push a
> > git branch if somebody is interested in contributing to the project.
> > 
> > 
> > # Design and limitations
> > 
> > The frontend connects to the backend following the traditional xenstore
> > based exchange of information.
> > 
> > Frontend and backend setup an event channel and shared ring. The ring is
> > used by the frontend to forward socket API calls to the backend. I am
> > referring to this ring as command ring. This is an example of the ring
> > format:
> > 
> > #define XENSOCK_CONNECT0
> > #define XENSOCK_RELEASE3
> > #define XENSOCK_BIND   4
> > #define XENSOCK_LISTEN 5
> > #define XENSOCK_ACCEPT 6
> > #define XENSOCK_POLL   7
> > 
> > struct xen_xensock_request {
> > uint32_t id; /* private to guest, echoed in response */
> > uint32_t cmd;/* command to execute */
> > uint64_t sockid; /* id of the socket */
> > union {
> > struct xen_xensock_connect {
> > uint8_t addr[28];
> > uint32_t len;
> > uint32_t flags;
> > grant_ref_t ref[XENSOCK_DATARING_PAGES];
> > uint32_t evtchn;
> > } connect;
> > struct xen_xensock_bind {
> > uint8_t addr[28]; /* ipv6 ready */
> > uint32_t len;
> > } bind;
> > struct xen_xensock_accept {
> > grant_ref_t ref[XENSOCK_DATARING_PAGES];
> > uint32_t evtchn;
> > uint64_t sockid;
> > } accept;
> > } u;
> > };
> > 
> > struct xen_xensock_response {
> > uint32_t id;
> > uint32_t cmd;
> > uint64_t sockid;
> > int32_t ret;
> > };
> > 
> > DEFINE_RING_TYPES(xen_xensock, struct xen_xensock_request,
> >   struct xen_xensock_response);
> > 
> > 
> > Connect and accept lead to the creation of new active sockets. Today
> > each active socket has its own event channel and ring for sending and
> > receiving data. Data rings have the following format:
> > 
> > #define XENSOCK_DATARING_ORDER 2
> > #define XENSOCK_DATARING_PAGES (1 << XENSOCK_DATARING_ORDER)
> > #define XENSOCK_DATARING_SIZE (XENSOCK_DATARING_PAGES << PAGE_SHIFT)
> > 
> > typedef uint32_t XENSOCK_RING_IDX;
> > 
> > struct xensock_ring_intf {
> > char in[XENSOCK_DATARING_SIZE/4];
> > char out[XENSOCK_DATARING_SIZE/2];
> > XENSOCK_RING_IDX in_cons, in_prod;
> > XENSOCK_RING_IDX out_cons, out_prod;
> > int32_t in_error, out_error;
> > };
> > 
> > The ring works like the Xen console ring (see

Re: [Xen-devel] [PATCH v5 02/14] libxc: Prepare a start info structure for hvmloader

[Anthony PERARD]

On Thu, Jun 23, 2016 at 10:44:26AM -0400, Boris Ostrovsky wrote:
> On 06/22/2016 01:15 PM, Anthony PERARD wrote:
> > +/*
> > + * The memory layout of the start_info page and the modules, and where the
> > + * addresses are stored:
> > + *
> > + * /--\
> > + * | struct hvm_start_info|
> > + * +--+ <- start_info->modlist_paddr
> > + * | struct hvm_modlist_entry[0]  |
> > + * +--+
> > + * | struct hvm_modlist_entry[1]  |
> > + * +--+ <- modlist[0].cmdline_paddr
> > + * | cmdline of module 0  |
> > + * | char[HVMLOADER_MODULE_NAME_SIZE] |
> > + * +--+ <- modlist[1].cmdline_paddr
> > + * | cmdline of module 1  |
> > + * +--+
> > + */
> 
> Should this go to public/xen.h?

No, it should not. This is to describe how the memory is allocated
and used by this function. The different calculation may be a bit
complicated to follow.

> > +static void add_module_to_list(struct xc_dom_image *dom,
> > +   struct xc_hvm_firmware_module *module,
> > +   const char *name,
> > +   struct hvm_modlist_entry *modlist,
> > +   struct hvm_start_info *start_info)
> > +{
> > +uint32_t index = start_info->nr_modules;
> > +void *modules_cmdline_start = modlist + HVMLOADER_MODULE_MAX_COUNT;
> > +uint64_t modlist_paddr = (dom->start_info_seg.pfn << PAGE_SHIFT) +
> > +((uintptr_t)modlist - (uintptr_t)start_info);
> > +uint64_t modules_cmdline_paddr = modlist_paddr +
> > +sizeof(struct hvm_modlist_entry) * HVMLOADER_MODULE_MAX_COUNT;
> > +
> > +if ( module->length == 0 )
> > +return;
> > +
> > +assert(start_info->nr_modules < HVMLOADER_MODULE_MAX_COUNT);
> > +assert(strnlen(name, HVMLOADER_MODULE_NAME_SIZE)
> > +   < HVMLOADER_MODULE_NAME_SIZE);
> > +
> > +modlist[index].paddr = module->guest_addr_out;
> > +modlist[index].size = module->length;
> > +
> > +strncpy(modules_cmdline_start + HVMLOADER_MODULE_NAME_SIZE * index,
> > +name, HVMLOADER_MODULE_NAME_SIZE);
> > +modlist[index].cmdline_paddr =
> > +modules_cmdline_paddr + HVMLOADER_MODULE_NAME_SIZE * index;
> > +
> > +start_info->nr_modules++;
> > +}
> > +
> >  static int bootlate_hvm(struct xc_dom_image *dom)
> >  {
> >  uint32_t domid = dom->guest_domid;
> >  xc_interface *xch = dom->xch;
> > +struct hvm_start_info *start_info;
> > +size_t start_info_size;
> > +struct hvm_modlist_entry *modlist;
> >  
> > -if ( !dom->device_model )
> > -{
> > -struct hvm_start_info *start_info;
> > -size_t start_info_size;
> > -void *start_page;
> > -
> > -start_info_size = sizeof(*start_info) + dom->cmdline_size;
> > -if ( dom->ramdisk_blob )
> > -start_info_size += sizeof(struct hvm_modlist_entry);
> > +start_info_size = sizeof(*start_info) + dom->cmdline_size;
> > +if ( dom->ramdisk_blob )
> > +start_info_size += sizeof(struct hvm_modlist_entry);
> >  
> > -if ( start_info_size >
> > - dom->start_info_seg.pages << XC_DOM_PAGE_SHIFT(dom) )
> > -{
> > -DOMPRINTF("Trying to map beyond start_info_seg");
> > -return -1;
> > -}
> > +if ( start_info_size >
> > + dom->start_info_seg.pages << XC_DOM_PAGE_SHIFT(dom) )
> > +{
> > +DOMPRINTF("Trying to map beyond start_info_seg");
> > +return -1;
> > +}
> >  
> > -start_page = xc_map_foreign_range(xch, domid, start_info_size,
> > -  PROT_READ | PROT_WRITE,
> > -  dom->start_info_seg.pfn);
> > -if ( start_page == NULL )
> > -{
> > -DOMPRINTF("Unable to map HVM start info page");
> > -return -1;
> > -}
> > +start_info = xc_map_foreign_range(xch, domid, start_info_size,
> > +  PROT_READ | PROT_WRITE,
> > +  dom->start_info_seg.pfn);
> > +if ( start_info == NULL )
> > +{
> > +DOMPRINTF("Unable to map HVM start info page");
> > +return -1;
> > +}
> >  
> > -start_info = start_page;
> > +modlist = (void*)(start_info + 1) + dom->cmdline_size;
> >  
> > +if ( !dom->device_model )
> > +{
> >  if ( dom->cmdline )
> >  {
> > -char *cmdline = start_page + sizeof(*start_info);
> > +char *cmdline = (void*)(start_info + 1);
> >  
> >  strncpy(cmdline, dom->cmdline, dom->cmdline_size);
> >  start_info->cmdline_paddr = (dom->start_info_seg.pfn << 
> > PAGE_SHIFT) +
> > @@ -1733,22 +1791,30 @@ static int bootlate_hvm(struct 

Re: [Xen-devel] RFC: XenSock brainstorming

[Stefano Stabellini]

On Thu, 23 Jun 2016, David Vrabel wrote:
> On 06/06/16 10:33, Stefano Stabellini wrote:
> > # Goals
> > 
> > The goal of the protocol is to provide networking capabilities to any
> > guests, with the following added benefits:
> > 
> > * guest networking should work out of the box with VPNs, wireless
> >   networks and any other complex network configurations in Dom0
> > 
> > * guest services should listen on ports bound directly to Dom0 IP
> >   addresses, fitting naturally in a Docker based workflow, where guests
> >   are Docker containers
> > 
> > * Dom0 should have full visibility on the guest behavior and should be
> >   able to perform inexpensive filtering and manipulation of guest calls
> > 
> > * XenSock should provide excellent performance. Unoptimized early code
> >   reaches 22 Gbit/sec TCP single stream and scales to 60 Gbit/sec with 3
> >   streams.
> 
> I think it looks a bit odd to isolate the workload into a VM and then
> blow a hole in the isolation by providing a "fat" RPC interface directly
> to the privileged dom0 kernel.

It might look odd but this is exactly the goal of the project. The vast
majority of the syscalls will be run entirely within the VM. The ones
that are allowed to reach dom0 are only very few, less then 10 today in
fact. It is a big win from a security perspective compared to
containers. And it is a big win compared to VMs in terms of performance.
In my last test I reached 84 gbit/sec with 4 tcp streams.

Monitoring the behavior of the guest becomes extremely cheap and easy as
one can just keep track of the syscalls forwarded to dom0. It would be
trivial to figure out if your NGINX container unexpectedly tried to open
port 22 for example. One would have to employ complex firewall rules or
VM introspection to do this otherwise. In addition one can still use all
the traditional filtering techniques for these syscalls in dom0, such as
seccomp.

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

Re: [Xen-devel] [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Julien Grall]

Hi,

On 23/06/16 15:50, Stefano Stabellini wrote:

On Thu, 23 Jun 2016, Shannon Zhao wrote:

diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl 
b/tools/libxl/libxl_empty_dsdt_arm.asl
new file mode 100644
index 000..005fa6a
--- /dev/null
+++ b/tools/libxl/libxl_empty_dsdt_arm.asl
@@ -0,0 +1,22 @@
+/**
+ * DSDT for Xen ARM DomU
+ *
+ * Copyright (c) 2004, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ */
+
+DefinitionBlock ("DSDT.aml", "DSDT", 3, "XenARM", "Xen DSDT", 1)
+{
+
+}


Why do we need C code to generate the "static" asl? Can't we just
manually writing the asl code here and get rid of libxl_mk_dsdt_arm.c?


Whilst I agree that manually writing the asl code sounds more appealing, 
we need to write one node per processor. So currently this would be 128 
nodes and this will likely increase in the future.


Generating the asl has the advantage to be able to add new property in 
the processor node easily without having to modify one by one all the nodes.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 09/17] libxl/arm: Construct ACPI MADT table

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:

From: Shannon Zhao 

According to the GIC version, construct the MADT table.

Signed-off-by: Shannon Zhao 
---
  tools/libxl/libxl_arm_acpi.c | 100 +++
  1 file changed, 100 insertions(+)

diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
index de863f4..659dbfa 100644
--- a/tools/libxl/libxl_arm_acpi.c
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -42,6 +42,8 @@ typedef uint64_t u64;
  #define ACPI_LEVEL_SENSITIVE(u8) 0x00
  #define ACPI_ACTIVE_LOW (u8) 0x01

+#define ACPI_GICC_ENABLED 1


Is there any reason to not use ACPI_MADT_ENABLED?


+
  enum {
  RSDP,
  XSDT,
@@ -137,6 +139,101 @@ static void make_acpi_gtdt(libxl__gc *gc, struct 
xc_dom_image *dom)
  dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
  }

+static void make_acpi_madt_gicc(void *table, int nr_cpus, uint64_t gicc_base)
+{
+uint32_t i;
+struct acpi_madt_generic_interrupt *gicc = table;
+
+for (i = 0; i < nr_cpus; i++) {
+gicc->header.type = ACPI_MADT_TYPE_GENERIC_INTERRUPT;
+gicc->header.length = sizeof(*gicc);
+gicc->base_address = gicc_base;
+gicc->cpu_interface_number = i;
+gicc->arm_mpidr = libxl__compute_mpdir(i);
+gicc->uid = i;
+gicc->flags = ACPI_GICC_ENABLED;
+gicc++;
+}
+}
+
+static void make_acpi_madt_gicd(void *table, uint64_t gicd_base,
+uint8_t gic_version)
+{
+struct acpi_madt_generic_distributor *gicd = table;
+
+gicd->header.type = ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR;
+gicd->header.length = sizeof(*gicd);
+gicd->base_address = gicd_base;
+/* This version filed has no meaning before ACPI 5.1 errata. */


s/filed/field/


+gicd->version = gic_version;
+}
+
+static void make_acpi_madt_gicr(void *table, uint64_t gicr_base,
+uint64_t gicr_size)
+{
+struct acpi_madt_generic_redistributor *gicr = table;
+
+gicr->header.type = ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR;
+gicr->header.length = sizeof(*gicr);
+gicr->base_address = gicr_base;
+gicr->length = gicr_size;
+}
+
+static int make_acpi_madt(libxl__gc *gc, struct xc_dom_image *dom, int nr_cpus,
+  xc_domain_configuration_t *xc_config)
+{



[...]


+
+make_acpi_header(>header, "APIC", size, 3);
+
+acpitables[MADT].table = madt;
+acpitables[MADT].size = size;
+/* Align to 64bit. */
+dom->acpitable_size += ROUNDUP(acpitables[MADT].size, 3);


I am not sure how ROUNDUP(..., 3) will align to 64-bit.


+
+return 0;
+}
+
  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
  libxl__domain_build_state *state,
  struct xc_dom_image *dom)
@@ -160,6 +257,9 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
  make_acpi_rsdp(gc, dom);
  make_acpi_xsdt(gc, dom);
  make_acpi_gtdt(gc, dom);
+rc = make_acpi_madt(gc, dom, info->max_vcpus, xc_config);
+if (rc)
+   return rc;

  return 0;
  }



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 08/17] libxl/arm: Factor MPIDR computing codes out as a helper

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:

From: Shannon Zhao 

Factor MPIDR computing codes out as a helper, so it could be shared
between DT and ACPI.

Signed-off-by: Shannon Zhao 
---
  tools/libxl/libxl_arm.c  |  8 +---
  tools/libxl/libxl_arm_acpi.h | 12 
  2 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index f5db74b..a766732 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -312,13 +312,7 @@ static int make_cpus_node(libxl__gc *gc, void *fdt, int 
nr_cpus,
  for (i = 0; i < nr_cpus; i++) {
  const char *name;

-/*
- * According to ARM CPUs bindings, the reg field should match
- * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
- * constructing the reg value of the guest at the moment, for it
- * is enough for the current max vcpu number.
- */
-mpidr_aff = (i & 0x0f) | (((i >> 4) & 0xff) << 8);
+mpidr_aff = libxl__compute_mpdir(i);
  name = GCSPRINTF("cpu@%"PRIx64, mpidr_aff);

  res = fdt_begin_node(fdt, name);
diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
index 5899210..9b58de6 100644
--- a/tools/libxl/libxl_arm_acpi.h
+++ b/tools/libxl/libxl_arm_acpi.h


I do not think libxl_arm_acpi.h is the right place to add 
libxl__compute_mpidr. This function is clearly not ACPI specific. You 
may want to rename this file libxl_arm.h instead.



@@ -23,6 +23,18 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,
  libxl__domain_build_state *state,
  struct xc_dom_image *dom);

+static inline uint64_t libxl__compute_mpdir(int index)


'index' should be unsigned int. It would also make sense to name this 
variable 'cpuid'.



+{
+/*
+ * According to ARM CPUs bindings, the reg field should match
+ * the MPIDR's affinity bits. We will use AFF0 and AFF1 when
+ * constructing the reg value of the guest at the moment, for it
+ * is enough for the current max vcpu number.
+ */
+assert(index >= 0);


This will avoid this assert here.


+return (index & 0x0f) | (((index >> 4) & 0xff) << 8);
+}
+
  /*
   * Local variables:
   * mode: C



Regards,

--
Julien Grall

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

Re: [Xen-devel] RFC: XenSock brainstorming

[David Vrabel]

On 06/06/16 10:33, Stefano Stabellini wrote:
> # Goals
> 
> The goal of the protocol is to provide networking capabilities to any
> guests, with the following added benefits:
> 
> * guest networking should work out of the box with VPNs, wireless
>   networks and any other complex network configurations in Dom0
> 
> * guest services should listen on ports bound directly to Dom0 IP
>   addresses, fitting naturally in a Docker based workflow, where guests
>   are Docker containers
> 
> * Dom0 should have full visibility on the guest behavior and should be
>   able to perform inexpensive filtering and manipulation of guest calls
> 
> * XenSock should provide excellent performance. Unoptimized early code
>   reaches 22 Gbit/sec TCP single stream and scales to 60 Gbit/sec with 3
>   streams.

I think it looks a bit odd to isolate the workload into a VM and then
blow a hole in the isolation by providing a "fat" RPC interface directly
to the privileged dom0 kernel.

I think you could probably present a regular VIF to the guest and use
SDN (e.g., openvswitch) to get your docker-like semantics.

David


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

Re: [Xen-devel] [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:

[...]


diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index cc5a717..f5db74b 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1,6 +1,7 @@
  #include "libxl_internal.h"
  #include "libxl_arch.h"
  #include "libxl_libfdt_compat.h"
+#include "libxl_arm_acpi.h"

  #include 
  #include 
@@ -888,8 +889,24 @@ int libxl__arch_domain_init_hw_description(libxl__gc *gc,
 libxl__domain_build_state *state,
 struct xc_dom_image *dom)
  {
+int rc;
+
  assert(info->type == LIBXL_DOMAIN_TYPE_PV);
-return libxl__prepare_dtb(gc, info, state, dom);
+rc = libxl__prepare_dtb(gc, info, state, dom);
+if (rc)
+return rc;
+
+if (!state->config.acpi) {
+LOG(DEBUG, "Generating ACPI tables is disabled by user.");
+return 0;
+}
+
+if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
+LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
+state->config.acpi = false;


Silently ignores the user configuration is usually not a good thing. So 
should not we return an error here?



+}
+
+return libxl__prepare_acpi(gc, info, state, dom);
  }

  static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
new file mode 100644
index 000..60c31f9
--- /dev/null
+++ b/tools/libxl/libxl_arm_acpi.c
@@ -0,0 +1,85 @@
+/*
+ * ARM DmoU ACPI generation


s/DmoU/DomU/

[...]


+#include "libxl_arm_acpi.h"
+
+#include 


Please add a newline here for clarity.


+typedef uint8_t u8;
+typedef uint16_t u16;
+typedef uint32_t u32;
+typedef uint64_t u64;


Ditto.


+#include 
+#include 
+
+enum {
+RSDP,
+XSDT,
+GTDT,
+MADT,
+FADT,
+DSDT,
+NUMS,
+};
+
+struct acpitable {
+void *table;
+size_t size;
+};
+
+static struct acpitable acpitables[NUMS];


libxl is a library which can be used to implement daemon. So anything 
domain specific should not be static nor global.



+
+int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
+libxl__domain_build_state *state,
+struct xc_dom_image *dom)
+{
+const libxl_version_info *vers;
+int rc;
+
+/* convenience aliases */
+xc_domain_configuration_t *xc_config = >config;
+
+vers = libxl_get_version_info(CTX);
+if (vers == NULL)
+return ERROR_FAIL;
+
+LOG(DEBUG, "constructing ACPI tables for Xen version %d.%d guest",
+vers->xen_version_major, vers->xen_version_minor);
+
+dom->acpitable_blob = NULL;
+dom->acpitable_size = 0;
+
+return 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
new file mode 100644
index 000..5899210
--- /dev/null
+++ b/tools/libxl/libxl_arm_acpi.h
@@ -0,0 +1,32 @@


[...]


+#include "libxl_internal.h"
+#include "libxl_arch.h"
+
+#include 
+
+int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,


The function should be prefixed with _hidden.


+libxl__domain_build_state *state,
+struct xc_dom_image *dom);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */



Regards,

--
Julien Grall

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

Re: [Xen-devel] Change of max-ram-below-4g initial value breaks Xen

[Anthony PERARD]

On Thu, Jun 23, 2016 at 04:57:54PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > How could xen_ram_init() find out if the value of max-ram-below-4g is
> > the default or if a user have set it? Is there another way we could fix
> > this?
> 
> Attached patch should fix it.  Patch survived a quick smoke test on kvm
> so far, need to do some more testing tomorrow.  Can you give it a spin
> on xen?

Thanks. Unfortunately, it does not work :(.

In this patch, max_ram_below_4g is set before the call to xen_ram_init()
and xen_ram_init read it back (via object_property_get_int()).  So, in
xen_ram_init, user_lowmem is not 0.

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Julien Grall]

Hi,

On 23/06/16 16:00, Stefano Stabellini wrote:

On Thu, 23 Jun 2016, Shannon Zhao wrote:


[...]


+static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
+{
+struct acpi_table_gtdt *gtdt;
+size_t size = sizeof(*gtdt);
+
+gtdt = libxl__zalloc(gc, size);
+
+gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
+gtdt->non_secure_el1_flags =
+ (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW << 
ACPI_GTDT_INTERRUPT_POLARITY);
+gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
+gtdt->virtual_timer_flags =
+ (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE)
+ |(ACPI_ACTIVE_LOW << 
ACPI_GTDT_INTERRUPT_POLARITY);
+
+make_acpi_header(>header, "GTDT", size, 2);
+
+acpitables[GTDT].table = gtdt;
+acpitables[GTDT].size = size;
+/* Align to 64bit. */
+dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
+}


Many of this tables look pretty much static. Any reason why we can't
define them and initialize them on an header somewhere like:

 struct acpi_gtdt xen_acpi_gtdt {
 .non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
 .non_secure_el1_flags = (ACPI_LEVEL_SENSITIVE << ACPI_GTDT_INTERRUPT_MODE) | 
(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
 .virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
 .virtual_timer_flags = (ACPI_LEVEL_SENSITIVE << 
ACPI_GTDT_INTERRUPT_MODE)|(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
 };

it would make the code shorter and easier to read.


I agree with Stefano on this point.


  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
  libxl__domain_build_state *state,
  struct xc_dom_image *dom)
@@ -132,6 +159,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
libxl_domain_build_info *info,

  make_acpi_rsdp(gc, dom);
  make_acpi_xsdt(gc, dom);
+make_acpi_gtdt(gc, dom);

  return 0;
  }
--
2.0.4






Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 0/3] Make hvm_fep available to non-debug build

[Andrew Cooper]

On 23/06/16 16:10, Wei Liu wrote:
> Wei Liu (3):
>   xen: add warning infrastructure
>   console: use warning infrastructure for sync console warning
>   xen: make available hvm_fep to non-debug build as well

Committed, including the small adjustments.

~Andrew

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

Re: [Xen-devel] [PATCH v2 1/4] xen/init: Annotate all command line parameter infrastructure as const

[Andrew Cooper]

On 23/06/16 17:00, Jan Beulich wrote:
 On 21.06.16 at 18:59,  wrote:
>> --- a/xen/include/xen/init.h
>> +++ b/xen/include/xen/init.h
>> @@ -86,10 +86,11 @@ struct kernel_param {
>>  void *var;
>>  };
>>  
>> -extern struct kernel_param __setup_start, __setup_end;
>> +extern const struct kernel_param __setup_start[], __setup_end[];
>>  
>> -#define __setup_str static __initdata __attribute__((__aligned__(1))) char
>> -#define __kparam static __initsetup \
>> +#define __setup_str static const  __initconstrel \
>> +__attribute__((__aligned__(1))) char
> This slipped my attention during review, but causes build failure
> with some gcc versions now: Why __initconstrel rather than
> __initconst?

Because this was previously __initconst and you reverted it for breaking
on older GCC.  Message ID <56cb470e0278000d4...@prv-mh.provo.novell.com>

I can't replicate any build failures with any GCC or clang combination
to hand.  Are you able to find some solution which GCC is happy with?

~Andrew

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

Re: [Xen-devel] RFC: XenSock brainstorming

[Stefano Stabellini]

Now that Xen 4.7 is out of the door, any more feedback on this?

On Mon, 6 Jun 2016, Stefano Stabellini wrote:
> Hi all,
> 
> a couple of months ago I started working on a new PV protocol for
> virtualizing syscalls. I named it XenSock, as its main purpose is to
> allow the implementation of the POSIX socket API in a domain other than
> the one of the caller. It allows connect, accept, recvmsg, sendmsg, etc
> to be implemented directly in Dom0. In a way this is conceptually
> similar to virtio-9pfs, but for sockets rather than filesystem APIs.
> See this diagram as reference:
> 
> https://docs.google.com/presentation/d/1z4AICTY2ejAjZ-Ul15GTL3i_wcmhKQJA7tcXwhI3dys/edit?usp=sharing
> 
> The frontends and backends could live either in userspace or kernel
> space, with different trade-offs. My current prototype is based on Linux
> kernel drivers but it would be nice to have userspace drivers too.
> Discussing where the drivers could be implemented it's beyond the scope
> of this email.
> 
> 
> # Goals
> 
> The goal of the protocol is to provide networking capabilities to any
> guests, with the following added benefits:
> 
> * guest networking should work out of the box with VPNs, wireless
>   networks and any other complex network configurations in Dom0
> 
> * guest services should listen on ports bound directly to Dom0 IP
>   addresses, fitting naturally in a Docker based workflow, where guests
>   are Docker containers
> 
> * Dom0 should have full visibility on the guest behavior and should be
>   able to perform inexpensive filtering and manipulation of guest calls
> 
> * XenSock should provide excellent performance. Unoptimized early code
>   reaches 22 Gbit/sec TCP single stream and scales to 60 Gbit/sec with 3
>   streams.
> 
> 
> # Status
> 
> I would like to get feedback on the high level architecture, the data
> path and the ring formats.
> 
> Beware that protocol and drivers are in their very early days. I don't
> have all the information to write a design document yet. The ABI is
> neither complete nor stable.
> 
> The code is not ready for xen-devel yet, but I would be happy to push a
> git branch if somebody is interested in contributing to the project.
> 
> 
> # Design and limitations
> 
> The frontend connects to the backend following the traditional xenstore
> based exchange of information.
> 
> Frontend and backend setup an event channel and shared ring. The ring is
> used by the frontend to forward socket API calls to the backend. I am
> referring to this ring as command ring. This is an example of the ring
> format:
> 
> #define XENSOCK_CONNECT0
> #define XENSOCK_RELEASE3
> #define XENSOCK_BIND   4
> #define XENSOCK_LISTEN 5
> #define XENSOCK_ACCEPT 6
> #define XENSOCK_POLL   7
> 
> struct xen_xensock_request {
>   uint32_t id; /* private to guest, echoed in response */
>   uint32_t cmd;/* command to execute */
>   uint64_t sockid; /* id of the socket */
>   union {
>   struct xen_xensock_connect {
>   uint8_t addr[28];
>   uint32_t len;
>   uint32_t flags;
>   grant_ref_t ref[XENSOCK_DATARING_PAGES];
>   uint32_t evtchn;
>   } connect;
>   struct xen_xensock_bind {
>   uint8_t addr[28]; /* ipv6 ready */
>   uint32_t len;
>   } bind;
>   struct xen_xensock_accept {
>   grant_ref_t ref[XENSOCK_DATARING_PAGES];
>   uint32_t evtchn;
>   uint64_t sockid;
>   } accept;
>   } u;
> };
> 
> struct xen_xensock_response {
>   uint32_t id;
>   uint32_t cmd;
>   uint64_t sockid;
>   int32_t ret;
> };
> 
> DEFINE_RING_TYPES(xen_xensock, struct xen_xensock_request,
> struct xen_xensock_response);
> 
> 
> Connect and accept lead to the creation of new active sockets. Today
> each active socket has its own event channel and ring for sending and
> receiving data. Data rings have the following format:
> 
> #define XENSOCK_DATARING_ORDER 2
> #define XENSOCK_DATARING_PAGES (1 << XENSOCK_DATARING_ORDER)
> #define XENSOCK_DATARING_SIZE (XENSOCK_DATARING_PAGES << PAGE_SHIFT)
> 
> typedef uint32_t XENSOCK_RING_IDX;
> 
> struct xensock_ring_intf {
>   char in[XENSOCK_DATARING_SIZE/4];
>   char out[XENSOCK_DATARING_SIZE/2];
>   XENSOCK_RING_IDX in_cons, in_prod;
>   XENSOCK_RING_IDX out_cons, out_prod;
>   int32_t in_error, out_error;
> };
> 
> The ring works like the Xen console ring (see
> xen/include/public/io/console.h). Data is copied to/from the ring by
> both frontend and backend. in_error, out_error are used to report
> errors. This simple design works well, but it requires at least 1 page
> per active socket. To get good performance (~20 Gbit/sec single stream),
> we need buffers of at least 64K, so actually we are 

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Jan Beulich]

>>> On 23.06.16 at 17:45,  wrote:
> In your patch (changing XSM_XS_PRIV semantic), you implicitly considered
> all domctls allowed for xenstore domain to be always a subset of those
> allowed for device model domain. For now this is true, but if this set
> is going to be extended in the future, your approach most likely will
> lead to an error.

I don't think so (and intentionally accepted that resulting behavior),
but in the end only the future can prove this either way.

Jan


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

Re: [Xen-devel] [PATCH] xen/arm: domain_build: DT: add clocks node to the hypervisor node

[Julien Grall]

Hi Dirk,

On 23/06/16 16:59, Dirk Behme wrote:

On 23.06.2016 17:02, Julien Grall wrote:

On 22/06/16 16:58, Julien Grall wrote:

On 21/06/16 11:15, Dirk Behme wrote:

+printk("Failed to remember the clock node of %s\n",
path);
+printk("Use the Linux kernel command
'clk_ignore_unused'\n");
+return 0;


I don't think this is tolerable. We need to fix it  once and for all.

I understand that xen does not provide a realloc function. Is there
another way we can get a rid of this limit?


Note that I would wait that we agree on the device tree bindings
before reworking this patch.



You mean the 'clocks' binding for the hypervisor node? I.e. as proposed in

https://lists.xen.org/archives/html/xen-devel/2016-06/msg02885.html

create a patch for

- linux/Documentation/devicetree/bindings/arm/xen.txt
- xen/docs/misc/arm/device-tree/guest.txt

and proceed only with the code changes when this is accepted?


The second patch (xen/docs/misc/*) will be a verbatim copy of the first 
one. So writing only the first one is good for now.


I will defer the implementation in Xen but keep the Linux one to give an 
overview to the maintainers (ARM and clocks)


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/4] xen/init: Annotate all command line parameter infrastructure as const

[Jan Beulich]

>>> On 21.06.16 at 18:59,  wrote:
> --- a/xen/include/xen/init.h
> +++ b/xen/include/xen/init.h
> @@ -86,10 +86,11 @@ struct kernel_param {
>  void *var;
>  };
>  
> -extern struct kernel_param __setup_start, __setup_end;
> +extern const struct kernel_param __setup_start[], __setup_end[];
>  
> -#define __setup_str static __initdata __attribute__((__aligned__(1))) char
> -#define __kparam static __initsetup \
> +#define __setup_str static const  __initconstrel \
> +__attribute__((__aligned__(1))) char

This slipped my attention during review, but causes build failure
with some gcc versions now: Why __initconstrel rather than
__initconst?

Jan


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

Re: [Xen-devel] [PATCH] xen/arm: domain_build: DT: add clocks node to the hypervisor node

[Dirk Behme]

On 23.06.2016 17:02, Julien Grall wrote:

On 22/06/16 16:58, Julien Grall wrote:

On 21/06/16 11:15, Dirk Behme wrote:

+printk("Failed to remember the clock node of %s\n",
path);
+printk("Use the Linux kernel command
'clk_ignore_unused'\n");
+return 0;


I don't think this is tolerable. We need to fix it  once and for all.

I understand that xen does not provide a realloc function. Is there
another way we can get a rid of this limit?


Note that I would wait that we agree on the device tree bindings
before reworking this patch.



You mean the 'clocks' binding for the hypervisor node? I.e. as proposed in

https://lists.xen.org/archives/html/xen-devel/2016-06/msg02885.html

create a patch for

- linux/Documentation/devicetree/bindings/arm/xen.txt
- xen/docs/misc/arm/device-tree/guest.txt

and proceed only with the code changes when this is accepted?

Best regards

Dirk




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

Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Julien Grall]

Hi Shannon,

On 23/06/16 04:16, Shannon Zhao wrote:

From: Shannon Zhao 

Add a configuration option for ARM DomU so that user can deicde to use
ACPI or not. This option is defaultly false.

Signed-off-by: Shannon Zhao 
---
  tools/libxl/libxl_arm.c   | 3 +++
  tools/libxl/libxl_types.idl   | 1 +
  tools/libxl/xl_cmdimpl.c  | 4 
  xen/include/public/arch-arm.h | 1 +
  4 files changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 8f15d9b..cc5a717 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
  return ERROR_FAIL;
  }

+xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
+  ? true : false;
+
  return 0;
  }

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ef614be..426b868 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[


  ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
+   ("acpi", libxl_defbool),


If we are going towards a new field, you will need add a new define for 
advertising external toolstack of the presence of arch_arm.acpi in 
libxl.h (see LIBXL_HAVE_BUILDINFO_ARM_GIC_VERSION for instance).



])),

  ], dir=DIR_IN
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 6459eec..0634ffa 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2506,6 +2506,10 @@ skip_usbdev:
  }
   }

+if (xlu_cfg_get_defbool(config, "acpi", _info->arch_arm.acpi, 0)) {
+libxl_defbool_set(_info->arch_arm.acpi, 0);
+}
+
  xlu_cfg_destroy(config);
  }

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 870bc3b..05e4a58 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -306,6 +306,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_context_t);
  struct xen_arch_domainconfig {
  /* IN/OUT */
  uint8_t gic_version;
+uint8_t acpi;


This structure is used to pass information to the hypervisor. I do not 
think the hypervisor has to know the domain is using ACPI.



  /* IN */
  uint32_t nr_spis;
  /*



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 3/3] xen: make available hvm_fep to non-debug build as well

[Doug Goldstein]

On 6/23/16 10:10 AM, Wei Liu wrote:
> Originally hvm_fep was guarded by NDEBUG, which means it was only
> available to debug builds.
> 
> However there is value to have it for non-debug builds as well. User can
> use that to run tests in setup that replicates production setup.

"Users can use it to run tests in a setup that replicates a production
setup" is what I think was meant?

> 
> Make it clear with a sync_console style warning that this option can't
> be used in production setup. Update command line documentation
> accordingly. Finally mark Xen as tainted when this feature is used.
> 
> Add a kconfig option under x86 to configure hvm_fep.
> 
> Signed-off-by: Wei Liu 

Otherwise the change looks good.

Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



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

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 95848
 test-armhf-armhf-xl-credit2  11 guest-start  fail   like 95591
 build-amd64-rumpuserxen   6 xen-buildfail   like 95848
 build-i386-rumpuserxen6 xen-buildfail   like 95848
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail  like 95848
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeatfail like 95848
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95848
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 95848
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 95848
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 95848
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 95848

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

version targeted for testing:
 linux95123c0b81d9478b8155fe15093b88f57ef7d0bd
baseline version:
 linux888172862fa78505c4e4674c205a06586443d83f

Last test of basis95848  2016-06-17 05:58:53 Z6 days
Testing same since96160  2016-06-23 05:07:18 Z0 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  AceLan Kao 
  Al Viro 
  Andy Lutomirski 
  Arnd Bergmann 
  Ben Dooks 
  Ben Skeggs 
  Bob Copeland 
  Borislav Petkov 
  Chris Wilson 
  Dibyajyoti Ghosh 
  Eduardo Valentin 
  Eric W. Biederman 
  Ewan D. Milne 
  Fred Veldini 
  Gavin Shan 
  H. Peter Anvin 
  Helge Deller 
  Herbert Xu 
  Hongkun Cao 
  hongkun.cao 
  Ilia Mirkin 
  Ingo Molnar 
  Jack Wang 
  James Bottomley 
  James E.J. Bottomley 
  Jan Stancek 
  Jann Horn 
  Javi Merino 

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Marek Marczykowski-Górecki]

On Thu, Jun 23, 2016 at 05:45:22PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 23, 2016 at 09:37:09AM -0600, Jan Beulich wrote:
> > >>> On 23.06.16 at 17:22,  wrote:
> > > xen: allow XEN_DOMCTL_getdomaininfo for device model domains
> > > 
> > > Allow device model domain to get info about its target domain.
> > > It is used during PCI passthrough setup (xc_domain_memory_mapping
> > > checks for guest being auto-translated). While it happens in stubdomain,
> > > it failed, breaking PCI passthrough in such setup.
> > 
> > If that's the route to go (which I'm not convinced of, as I'm not sure
> > we won't need other xenstore domain special casing later on) I'd
> > really like to ask you to mention the other broken case too, as
> > described in my original patch (unless you found I was wrong with
> > that).
> 
> So, maybe something like this:
>   case XEN_DOMCTL_getdomaininfo:
>   if ( current-domain->is_xenstore )
>   return xsm_default_action(XSM_XS_PRIV, current->domain, d);;
>   return xsm_default_action(XSM_DM_PRIV, current->domain, d);
> 
> 
> In your patch (changing XSM_XS_PRIV semantic), you implicitly considered
> all domctls allowed for xenstore domain to be always a subset of those
> allowed for device model domain. For now this is true, but if this set
> is going to be extended in the future, your approach most likely will
> lead to an error.

Hmm, but if xenstore domain will never be also device model domain, this
probably change nothing...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Marek Marczykowski-Górecki]

On Thu, Jun 23, 2016 at 09:37:09AM -0600, Jan Beulich wrote:
> >>> On 23.06.16 at 17:22,  wrote:
> > xen: allow XEN_DOMCTL_getdomaininfo for device model domains
> > 
> > Allow device model domain to get info about its target domain.
> > It is used during PCI passthrough setup (xc_domain_memory_mapping
> > checks for guest being auto-translated). While it happens in stubdomain,
> > it failed, breaking PCI passthrough in such setup.
> 
> If that's the route to go (which I'm not convinced of, as I'm not sure
> we won't need other xenstore domain special casing later on) I'd
> really like to ask you to mention the other broken case too, as
> described in my original patch (unless you found I was wrong with
> that).

So, maybe something like this:
  case XEN_DOMCTL_getdomaininfo:
  if ( current-domain->is_xenstore )
  return xsm_default_action(XSM_XS_PRIV, current->domain, d);;
  return xsm_default_action(XSM_DM_PRIV, current->domain, d);


In your patch (changing XSM_XS_PRIV semantic), you implicitly considered
all domctls allowed for xenstore domain to be always a subset of those
allowed for device model domain. For now this is true, but if this set
is going to be extended in the future, your approach most likely will
lead to an error.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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

Re: [Xen-devel] [PATCH v1 Altp2m cleanup 1/3] altp2m cleanup work

[Jan Beulich]

>>> On 21.06.16 at 18:04,  wrote:
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -479,6 +479,8 @@ struct xen_hvm_altp2m_op {
>  #define HVMOP_altp2m_set_mem_access   7
>  /* Change a p2m entry to have a different gfn->mfn mapping */
>  #define HVMOP_altp2m_change_gfn   8
> +#define HVMOP_cmd_min HVMOP_altp2m_get_domain_state
> +#define HVMOP_cmd_max HVMOP_altp2m_change_gfn

I don't see why these would need to be in the public interface. Nor
were their names chosen to properly describe their purpose.

Jan


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

Re: [Xen-devel] [PATCH v5 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Tamas K Lengyel]

On Wed, Jun 22, 2016 at 9:38 AM, George Dunlap  wrote:
> On Sun, Jun 12, 2016 at 12:24 AM, Tamas K Lengyel  wrote:
>> Currently mem-sharing can be performed on a page-by-page base from the 
>> control
>> domain. However, when completely deduplicating (cloning) a VM, this requires
>> at least 3 hypercalls per page. As the user has to loop through all pages up
>> to max_gpfn, this process is very slow and wasteful.
>>
>> This patch introduces a new mem_sharing memop for bulk deduplication where
>> the user doesn't have to separately nominate each page in both the source and
>> destination domain, and the looping over all pages happen in the hypervisor.
>> This significantly reduces the overhead of completely deduplicating entire
>> domains.
>>
>> Signed-off-by: Tamas K Lengyel 
>> Acked-by: Wei Liu 
>> ---
>> Ian Jackson 
>> George Dunlap 
>> Jan Beulich 
>> Andrew Cooper 
>
> I'm sorry I'm a bit late to this party -- I'm not sure how I managed
> to miss the earlier posts of this.  A couple of questions...
>
>
>> @@ -1468,6 +1516,79 @@ int 
>> mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>>  }
>>  break;
>>
>> +case XENMEM_sharing_op_bulk_share:
>> +{
>> +unsigned long max_sgfn, max_cgfn;
>> +struct domain *cd;
>> +
>> +rc = -EINVAL;
>> +if( mso.u.bulk._pad[0] || mso.u.bulk._pad[1] || 
>> mso.u.bulk._pad[2] )
>> +goto out;
>> +
>> +if ( !mem_sharing_enabled(d) )
>> +goto out;
>> +
>> +rc = rcu_lock_live_remote_domain_by_id(mso.u.bulk.client_domain,
>> +   );
>> +if ( rc )
>> +goto out;
>> +
>> +/*
>> + * We reuse XENMEM_sharing_op_share XSM check here as this is 
>> essentially
>> + * the same concept repeated over multiple pages.
>> + */
>> +rc = xsm_mem_sharing_op(XSM_DM_PRIV, d, cd, 
>> XENMEM_sharing_op_share);
>> +if ( rc )
>> +{
>> +rcu_unlock_domain(cd);
>> +goto out;
>> +}
>> +
>> +if ( !mem_sharing_enabled(cd) )
>> +{
>> +rcu_unlock_domain(cd);
>> +rc = -EINVAL;
>> +goto out;
>> +}
>> +
>> +if ( !atomic_read(>pause_count) ||
>> + !atomic_read(>pause_count) )
>> +{
>> +rcu_unlock_domain(cd);
>> +rc = -EINVAL;
>> +goto out;
>> +}
>
> I realize that Jan asked for this, but I'm really not sure what good
> this is supposed to do, since the guest can be un-paused at any point
> halfway through the transaction.
>
> Wouldn't it make more sense to have this function pause and unpause
> the domains itself?

The domains are paused by the user when this op is called, so this is
just a sanity check ensuring you are not issuing the op on some other
domain. So if this function would pause the domain as well all it
would do is increase the pause count. This is the only intended
use-case for this function at this time. It would make no sense to try
to issue this op on domains that are running, as that pretty much
guarantee that some of their memory has already diverged, and thus
bulk-sharing their memory would have some unintended side-effects.

>
>> +
>> +max_sgfn = domain_get_maximum_gpfn(d);
>> +max_cgfn = domain_get_maximum_gpfn(cd);
>> +
>> +if ( max_sgfn != max_cgfn || max_sgfn < mso.u.bulk.start )
>> +{
>> +rcu_unlock_domain(cd);
>> +rc = -EINVAL;
>> +goto out;
>> +}
>> +
>> +rc = bulk_share(d, cd, max_sgfn + 1, );
>> +if ( rc > 0 )
>> +{
>> +if ( __copy_to_guest(arg, , 1) )
>> +rc = -EFAULT;
>> +else
>> +rc = 
>> hypercall_create_continuation(__HYPERVISOR_memory_op,
>> +   "lh", 
>> XENMEM_sharing_op,
>> +   arg);
>> +}
>> +else
>> +{
>> +mso.u.bulk.start = 0;
>> +mso.u.bulk.shared = atomic_read(>shr_pages);
>> +}
>> +
>> +rcu_unlock_domain(cd);
>> +}
>> +break;
>> +
>>  case XENMEM_sharing_op_debug_gfn:
>>  {
>>  unsigned long gfn = mso.u.debug.u.gfn;
>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> index 29ec571..084f06e 100644
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -465,6 

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Jan Beulich]

>>> On 23.06.16 at 17:22,  wrote:
> xen: allow XEN_DOMCTL_getdomaininfo for device model domains
> 
> Allow device model domain to get info about its target domain.
> It is used during PCI passthrough setup (xc_domain_memory_mapping
> checks for guest being auto-translated). While it happens in stubdomain,
> it failed, breaking PCI passthrough in such setup.

If that's the route to go (which I'm not convinced of, as I'm not sure
we won't need other xenstore domain special casing later on) I'd
really like to ask you to mention the other broken case too, as
described in my original patch (unless you found I was wrong with
that).

Jan


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

Re: [Xen-devel] [PATCH 01/11] public / x86: introduce hvmctl hypercall

[Andrew Cooper]

On 23/06/16 16:10, Jan Beulich wrote:
 On 23.06.16 at 16:55,  wrote:
>> On 20/06/16 13:52, Jan Beulich wrote:
>>> +/*
>>> + * Note that this value is effectively part of the ABI, even if we don't 
>> need
>>> + * to make it a formal part of it.  Hence this value may only be changed if
>>> + * accompanied by a suitable interface version increase.
>>> + */
>>> +#define HVMCTL_iter_shift 8
>>> +#define HVMCTL_iter_mask  ((1U << HVMCTL_iter_shift) - 1)
>>> +#define HVMCTL_iter_max   (1U << (16 + HVMCTL_iter_shift))
>> This (mis)use of the cmd parameter is surely no longer necessary, given
>> that there is space in xen_hvmctl_t to encode continuation information?
> There's no misuse of cmd anymore. This is just use to make the 16-bit
> continuation value (the opaque structure member) cover a more useful
> range, and at once avoid doing the preemption check on every
> iteration.

Ah ok, but it does leave the minimum iteration at 256, which could
easily be too large, depending on the underlying operation.

In this case, I think it would be far better to bump the cmd field to 32
bits, and opaque to 64bits, which affords us far more flexibility.

~Andrew

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

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Daniel De Graaf]

On 06/23/2016 11:22 AM, Marek Marczykowski-Górecki wrote:

On Thu, Jun 23, 2016 at 11:00:42AM -0400, Daniel De Graaf wrote:

On 06/23/2016 09:25 AM, Marek Marczykowski-Górecki wrote:
[...]

Ok, after drawing a flowchart of the control in this function after your
change, on a piece of paper, this case looks fine. But depending on how
the domain was found (explicit loop or rcu_lock_domain_by_id), different
locks are held, which makes it harder to follow what is going on.

Crazy idea: how about making the code easy/easier to read instead of
obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
convolved enough. How about this version (2 patches):

[...]

xen: allow XEN_DOMCTL_getdomaininfo for device model

Allow device model domain to get info about its target domain.
It is used during PCI passthrough setup (xc_domain_memory_mapping
checks for guest being auto-translated). While it happens in stubdomain,
it failed, breaking PCI passthrough in such setup.

While it is possible to workaround this at toolstack side, it seems
logical to allow device model to get information about its target
domain.

The problem was exposed by c428c9f "tools/libxl: handle the iomem
parameter with the memory_mapping hcall".

Signed-off-by: Marek Marczykowski-Górecki 
---
 xen/include/xsm/dummy.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 406cd18..70a1633 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -128,7 +128,10 @@ static XSM_INLINE int xsm_domctl(XSM_DEFAULT_ARG struct 
domain *d, int cmd)
 case XEN_DOMCTL_unbind_pt_irq:
 return xsm_default_action(XSM_DM_PRIV, current->domain, d);
 case XEN_DOMCTL_getdomaininfo:
-return xsm_default_action(XSM_XS_PRIV, current->domain, d);
+if (current->domain->target)
+return xsm_default_action(XSM_DM_PRIV, current->domain, d);
+else
+return xsm_default_action(XSM_XS_PRIV, current->domain, d);
 default:
 return xsm_default_action(XSM_PRIV, current->domain, d);
 }


I would prefer testing for the xenstore flag instead of testing for the
target field.  It ends up being the same thing in reality, since nobody
sane would make the xenstore also a device model (and not also dom0).

  case XEN_DOMCTL_getdomaininfo:
  if ( src->is_xenstore )
  return 0;
  return xsm_default_action(XSM_DM_PRIV, current->domain, d);

This makes it clear that xenstore is the special case, and removes the
need for the one-off XSM_XS_PRIV constant.


This was my initial idea, but I don't really understand the comment
about link-time verification if the behaviour is the same for xsm not
compiled vs disabled. But if skipping xsm_default_action here doesn't
break this magic, I'm for it.


That magic is just for the parameter to the XSM hook: in this case, it's
the XSM_OTHER in xsm_domctl that is being verified.  There is no magic
in xsm_default_action.


Updated patch (with removal of XSM_XS_PRIV):

xen: allow XEN_DOMCTL_getdomaininfo for device model domains

Allow device model domain to get info about its target domain.
It is used during PCI passthrough setup (xc_domain_memory_mapping
checks for guest being auto-translated). While it happens in stubdomain,
it failed, breaking PCI passthrough in such setup.

While it is possible to workaround this at toolstack side, it seems
logical to allow device model to get information about its target
domain.

Also, since this was the only usage of XSM_XS_PRIV, which now gets
handled inline, drop it.

The problem was exposed by c428c9f "tools/libxl: handle the iomem
parameter with the memory_mapping hcall".

Signed-off-by: Marek Marczykowski-Górecki 


This would be a good patch to include the corresponding change to the
XSM policy (tweaked from Jan's email):


--- a/tools/flask/policy/modules/xen/xen.if
+++ b/tools/flask/policy/modules/xen/xen.if
@@ -148,7 +148,7 @@ define(`device_model', `
create_channel($2, $1, $2_channel)
allow $1 $2_channel:event create;

-   allow $1 $2_target:domain shutdown;
+   allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
irqlevel pciroute pcilevel cacheattr send_irq };
 ')


With that included, or elsewhere in the series:

Acked-by: Daniel De Graaf 


---
 xen/include/xsm/dummy.h | 8 +++-
 xen/include/xsm/xsm.h   | 1 -
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 406cd18..2768861 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -71,10 +71,6 @@ static always_inline int xsm_default_action(
 if ( src->is_privileged )
 return 0;
 return 

Re: [Xen-devel] [PATCH v4 3/3] xen: make available hvm_fep to non-debug build as well

[Andrew Cooper]

On 23/06/16 16:10, Wei Liu wrote:
> Originally hvm_fep was guarded by NDEBUG, which means it was only
> available to debug builds.
>
> However there is value to have it for non-debug builds as well. User can
> use that to run tests in setup that replicates production setup.

That is odd phrasing.  Perhaps "Users can use it to..." ?

>
> Make it clear with a sync_console style warning that this option can't
> be used in production setup. Update command line documentation
> accordingly. Finally mark Xen as tainted when this feature is used.
>
> Add a kconfig option under x86 to configure hvm_fep.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Marek Marczykowski-Górecki]

On Thu, Jun 23, 2016 at 11:00:42AM -0400, Daniel De Graaf wrote:
> On 06/23/2016 09:25 AM, Marek Marczykowski-Górecki wrote:
> [...]
> > Ok, after drawing a flowchart of the control in this function after your
> > change, on a piece of paper, this case looks fine. But depending on how
> > the domain was found (explicit loop or rcu_lock_domain_by_id), different
> > locks are held, which makes it harder to follow what is going on.
> > 
> > Crazy idea: how about making the code easy/easier to read instead of
> > obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
> > convolved enough. How about this version (2 patches):
> [...]
> > xen: allow XEN_DOMCTL_getdomaininfo for device model
> > 
> > Allow device model domain to get info about its target domain.
> > It is used during PCI passthrough setup (xc_domain_memory_mapping
> > checks for guest being auto-translated). While it happens in stubdomain,
> > it failed, breaking PCI passthrough in such setup.
> > 
> > While it is possible to workaround this at toolstack side, it seems
> > logical to allow device model to get information about its target
> > domain.
> > 
> > The problem was exposed by c428c9f "tools/libxl: handle the iomem
> > parameter with the memory_mapping hcall".
> > 
> > Signed-off-by: Marek Marczykowski-Górecki 
> > ---
> >  xen/include/xsm/dummy.h | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> > index 406cd18..70a1633 100644
> > --- a/xen/include/xsm/dummy.h
> > +++ b/xen/include/xsm/dummy.h
> > @@ -128,7 +128,10 @@ static XSM_INLINE int xsm_domctl(XSM_DEFAULT_ARG 
> > struct domain *d, int cmd)
> >  case XEN_DOMCTL_unbind_pt_irq:
> >  return xsm_default_action(XSM_DM_PRIV, current->domain, d);
> >  case XEN_DOMCTL_getdomaininfo:
> > -return xsm_default_action(XSM_XS_PRIV, current->domain, d);
> > +if (current->domain->target)
> > +return xsm_default_action(XSM_DM_PRIV, current->domain, d);
> > +else
> > +return xsm_default_action(XSM_XS_PRIV, current->domain, d);
> >  default:
> >  return xsm_default_action(XSM_PRIV, current->domain, d);
> >  }
> 
> I would prefer testing for the xenstore flag instead of testing for the
> target field.  It ends up being the same thing in reality, since nobody
> sane would make the xenstore also a device model (and not also dom0).
> 
>   case XEN_DOMCTL_getdomaininfo:
>   if ( src->is_xenstore )
>   return 0;
>   return xsm_default_action(XSM_DM_PRIV, current->domain, d);
> 
> This makes it clear that xenstore is the special case, and removes the
> need for the one-off XSM_XS_PRIV constant.

This was my initial idea, but I don't really understand the comment
about link-time verification if the behaviour is the same for xsm not
compiled vs disabled. But if skipping xsm_default_action here doesn't
break this magic, I'm for it.

Updated patch (with removal of XSM_XS_PRIV):

xen: allow XEN_DOMCTL_getdomaininfo for device model domains

Allow device model domain to get info about its target domain.
It is used during PCI passthrough setup (xc_domain_memory_mapping
checks for guest being auto-translated). While it happens in stubdomain,
it failed, breaking PCI passthrough in such setup.

While it is possible to workaround this at toolstack side, it seems
logical to allow device model to get information about its target
domain.

Also, since this was the only usage of XSM_XS_PRIV, which now gets
handled inline, drop it.

The problem was exposed by c428c9f "tools/libxl: handle the iomem
parameter with the memory_mapping hcall".

Signed-off-by: Marek Marczykowski-Górecki 
---
 xen/include/xsm/dummy.h | 8 +++-
 xen/include/xsm/xsm.h   | 1 -
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 406cd18..2768861 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -71,10 +71,6 @@ static always_inline int xsm_default_action(
 if ( src->is_privileged )
 return 0;
 return -EPERM;
-case XSM_XS_PRIV:
-if ( src->is_xenstore || src->is_privileged )
-return 0;
-return -EPERM;
 default:
 LINKER_BUG_ON(1);
 return -EPERM;
@@ -128,7 +124,9 @@ static XSM_INLINE int xsm_domctl(XSM_DEFAULT_ARG struct 
domain *d, int cmd)
 case XEN_DOMCTL_unbind_pt_irq:
 return xsm_default_action(XSM_DM_PRIV, current->domain, d);
 case XEN_DOMCTL_getdomaininfo:
-return xsm_default_action(XSM_XS_PRIV, current->domain, d);
+if ( current->domain->is_xenstore )
+return 0;
+return xsm_default_action(XSM_DM_PRIV, current->domain, d);
 default:
 return xsm_default_action(XSM_PRIV, current->domain, d);
 }
diff --git a/xen/include/xsm/xsm.h 

Re: [Xen-devel] [PATCH v4 2/3] console: use warning infrastructure for sync console warning

[Andrew Cooper]

On 23/06/16 16:10, Wei Liu wrote:
> Move the warning text to a static variable and marked that as initconst
> data. Call warning_add in console_init_preirq. Finally remove all
> unused bits.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v4 3/3] xen: make available hvm_fep to non-debug build as well

[Jan Beulich]

>>> On 23.06.16 at 17:10,  wrote:
> Originally hvm_fep was guarded by NDEBUG, which means it was only
> available to debug builds.
> 
> However there is value to have it for non-debug builds as well. User can
> use that to run tests in setup that replicates production setup.
> 
> Make it clear with a sync_console style warning that this option can't
> be used in production setup. Update command line documentation
> accordingly. Finally mark Xen as tainted when this feature is used.
> 
> Add a kconfig option under x86 to configure hvm_fep.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v4 1/3] xen: add warning infrastructure

[Andrew Cooper]

On 23/06/16 16:10, Wei Liu wrote:
> Use an array to keep track of warning text, provide a function to add
> warning text to track.  Print warnings (if any) in console_endboot.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 2/3] console: use warning infrastructure for sync console warning

[Jan Beulich]

>>> On 23.06.16 at 17:10,  wrote:
> Move the warning text to a static variable and marked that as initconst
> data. Call warning_add in console_init_preirq. Finally remove all
> unused bits.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v3 1/2] xen/arm: drivers: scif: Remove dead code

[Julien Grall]

(CC "THE REST" maintainers)

Hi Dirk,

On 22/06/16 12:49, Dirk Behme wrote:

The two struct members baud and clock_hz are in the end read only
variables nowhere used for anything useful. Removing them makes
the code much simpler without changing any functionality.

Signed-off-by: Dirk Behme 


Note that technically this driver is supported by "THE REST" 
maintainers. It might be worth to add it under "ARM (W/ VIRTUALISATION 
EXTENSIONS) ARCHITECTURE" as it is already the case for the other ARM 
specific UART drivers.


FWIW: Reviewed-by: Julien Grall 

Regards,


---
  xen/drivers/char/scif-uart.c| 24 +---
  xen/include/asm-arm/scif-uart.h |  1 -
  2 files changed, 1 insertion(+), 24 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 51a2233..bc157fe 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -41,7 +41,7 @@
  #define scif_writew(uart, off, val)writew((val), (uart)->regs + (off))

  static struct scif_uart {
-unsigned int baud, clock_hz, data_bits, parity, stop_bits;
+unsigned int data_bits, parity, stop_bits;
  unsigned int irq;
  char __iomem *regs;
  struct irqaction irqaction;
@@ -87,7 +87,6 @@ static void scif_uart_interrupt(int irq, void *data, struct 
cpu_user_regs *regs)
  static void __init scif_uart_init_preirq(struct serial_port *port)
  {
  struct scif_uart *uart = port->uart;
-unsigned int divisor;
  uint16_t val;

  /*
@@ -142,25 +141,6 @@ static void __init scif_uart_init_preirq(struct 
serial_port *port)
  }
  scif_writew(uart, SCIF_SCSMR, val);

-ASSERT( uart->clock_hz > 0 );
-if ( uart->baud != BAUD_AUTO )
-{
-/* Setup desired Baud rate */
-divisor = uart->clock_hz / (uart->baud << 4);
-ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
-scif_writew(uart, SCIF_DL, (uint16_t)divisor);
-/* Selects the frequency divided clock (SC_CLK external input) */
-scif_writew(uart, SCIF_CKS, 0);
-udelay(100 / uart->baud + 1);
-}
-else
-{
-/* Read current Baud rate */
-divisor = scif_readw(uart, SCIF_DL);
-ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
-uart->baud = uart->clock_hz / (divisor << 4);
-}
-
  /* Setup trigger level for TX/RX FIFOs */
  scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);

@@ -303,8 +283,6 @@ static int __init scif_uart_init(struct dt_device_node *dev,

  uart = _com;

-uart->clock_hz  = SCIF_CLK_FREQ;
-uart->baud  = BAUD_AUTO;
  uart->data_bits = 8;
  uart->parity= PARITY_NONE;
  uart->stop_bits = 1;
diff --git a/xen/include/asm-arm/scif-uart.h b/xen/include/asm-arm/scif-uart.h
index 7a9f639..d030b26 100644
--- a/xen/include/asm-arm/scif-uart.h
+++ b/xen/include/asm-arm/scif-uart.h
@@ -22,7 +22,6 @@
  #define __ASM_ARM_SCIF_UART_H

  #define SCIF_FIFO_MAX_SIZE16
-#define SCIF_CLK_FREQ 14745600

  /* Register offsets */
  #define SCIF_SCSMR (0x00)/* Serial mode register   */



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 1/3] xen: add warning infrastructure

[Jan Beulich]

>>> On 23.06.16 at 17:10,  wrote:
> Use an array to keep track of warning text, provide a function to add
> warning text to track.  Print warnings (if any) in console_endboot.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

[Xen-devel] [PATCH v4 3/3] xen: make available hvm_fep to non-debug build as well

[Wei Liu]

Originally hvm_fep was guarded by NDEBUG, which means it was only
available to debug builds.

However there is value to have it for non-debug builds as well. User can
use that to run tests in setup that replicates production setup.

Make it clear with a sync_console style warning that this option can't
be used in production setup. Update command line documentation
accordingly. Finally mark Xen as tainted when this feature is used.

Add a kconfig option under x86 to configure hvm_fep.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Doug Goldstein 

v4:
1. Fix declaration of warning_hvm_fep.
2. Remove stars in warning text.

v3:
1. Make config HVM_FEP an expert option and default to DEBUG.
2. Change some ifdefs
3. Update docs
4. Use the new warning infrastructure

v2:
1. unsigned -> unsigned int
2. %d -> %u
3. Add spaces around "-"
4. Update warning message
5. Only taint hv when fep is used
6. Add kconfig option
---
 docs/misc/xen-command-line.markdown |  8 ++--
 xen/arch/x86/Kconfig| 17 +
 xen/arch/x86/hvm/hvm.c  | 12 +++-
 xen/common/kernel.c |  6 --
 xen/include/asm-x86/hvm/hvm.h   |  2 +-
 xen/include/xen/lib.h   |  1 +
 6 files changed, 40 insertions(+), 6 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 7a271c0..045478f 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -886,8 +886,12 @@ Recognized in debug builds of the hypervisor only.
 Allow use of the Forced Emulation Prefix in HVM guests, to allow emulation of
 arbitrary instructions.
 
-This option is intended for development purposes, and is only available in
-debug builds of the hypervisor.
+This option is intended for development and testing purposes.
+
+*Warning*
+As this feature opens up the instruction emulator to arbitrary
+instruction from an HVM guest, don't use this in production system. No
+security support is provided when this flag is set.
 
 ### hvm\_port80
 > `= `
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 73f79cc..c1e9279 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -59,6 +59,23 @@ config BIGMEM
 
  If unsure, say N.
 
+config HVM_FEP
+   bool "HVM Forced Emulation Prefix support" if EXPERT = "y"
+   default DEBUG
+   ---help---
+
+ Compiles in a feature that allows HVM guest to arbitrarily
+ exercise the instruction emulator.
+
+ This feature can only be enabled during boot time with
+ appropriate hypervisor command line option. Please read
+ hypervisor command line documentation before trying to use
+ this feature.
+
+ This is strictly for testing purposes, and not appropriate
+ for use in production.
+
+ If unsure, say N.
 endmenu
 
 source "common/Kconfig"
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 5d6b921..c0f44e2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -97,9 +98,14 @@ boolean_param("hap", opt_hap_enabled);
 
 #ifndef opt_hvm_fep
 /* Permit use of the Forced Emulation Prefix in HVM guests */
-bool_t opt_hvm_fep;
+bool_t __read_mostly opt_hvm_fep;
 boolean_param("hvm_fep", opt_hvm_fep);
 #endif
+static const char __initconst warning_hvm_fep[] =
+"WARNING: HVM FORCED EMULATION PREFIX IS AVAILABLE\n"
+"This option is *ONLY* intended to aid testing of Xen.\n"
+"It has implications on the security of the system.\n"
+"Please *DO NOT* use this in production.\n";
 
 /* Xen command-line option to enable altp2m */
 static bool_t __initdata opt_altp2m_enabled = 0;
@@ -182,6 +188,9 @@ static int __init hvm_enable(void)
 if ( !opt_altp2m_enabled )
 hvm_funcs.altp2m_supported = 0;
 
+if ( opt_hvm_fep )
+warning_add(warning_hvm_fep);
+
 /*
  * Allow direct access to the PC debug ports 0x80 and 0xed (they are
  * often used for I/O delays, but the vmexits simply slow things down).
@@ -3910,6 +3919,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
 {
 regs->eip += sizeof(sig);
 regs->eflags &= ~X86_EFLAGS_RF;
+add_taint(TAINT_HVM_FEP);
 }
 }
 
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index dae7e35..5bf77aa 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -175,6 +175,7 @@ int __init parse_bool(const char *s)
  *  'M' - Machine had a machine check experience.
  *  'B' - System has hit bad_page.
  *  'C' - Console output is synchronous.
+ *  'H' - HVM forced emulation prefix is permitted.
  *
  *  The string is overwritten by the next call to print_taint().
  */
@@ -182,11 +183,12 @@ char *print_tainted(char *str)
 {
 if ( tainted 

Re: [Xen-devel] [PATCH v3 1/2] xen/arm: drivers: scif: Remove dead code

[Wei Liu]

On Thu, Jun 23, 2016 at 04:09:39PM +0100, Julien Grall wrote:
> (CC "THE REST" maintainers)
> 
> Hi Dirk,
> 
> On 22/06/16 12:49, Dirk Behme wrote:
> >The two struct members baud and clock_hz are in the end read only
> >variables nowhere used for anything useful. Removing them makes
> >the code much simpler without changing any functionality.
> >
> >Signed-off-by: Dirk Behme 
> 
> Note that technically this driver is supported by "THE REST" maintainers. It
> might be worth to add it under "ARM (W/ VIRTUALISATION EXTENSIONS)
> ARCHITECTURE" as it is already the case for the other ARM specific UART
> drivers.
> 

FWIW this sounds reasonable to me.

Wei.

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

Re: [Xen-devel] [PATCH v3] xen: arm: Update arm64 image header

[Julien Grall]

Hi Dirk,

On 23/06/16 07:38, Dirk Behme wrote:

With the Linux kernel commits

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=4370eec05a887b0cd4392cd5dc5b2713174745c0

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/Documentation/arm64/booting.txt?id=a2c1d73b94ed49f5fac12e95052d7b140783f800

the arm64 image header changed. While the size of the header isn't changed,
some members have changed their usage.

Update Xen to this updated image header.

The main changes are that the first magic is gone and that there is an
image size, now.

In case we read a size != 0, let's use this image size, now. This does
allow us to check if the kernel Image is larger than the size given in
the device tree, too.

Additionally, add an error message if the magic is not found. This might
be the case with kernel's < 3.12 prior to

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4370eec05a887b0cd4392cd5dc5b2713174745c0

which introduced the second magic.

This is acceptable as the support of Xen for ARM64 in Linux has been added
in Linux 3.11 and the number of boards supported by Linux 3.11 on ARM64 is
very limited: ARM models and X-gene. And for the latter it was an early
support with only the serial and timer upstreamed.

Signed-off-by: Dirk Behme 
---

Changes in v3: Just update of the commit message regarding the support
for kernels < 3.12. No change to the patch itself.


  xen/arch/arm/kernel.c | 43 ++-
  1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 9871bd9..9b9a793 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -28,8 +28,7 @@

  #define ZIMAGE32_MAGIC 0x016f2818

-#define ZIMAGE64_MAGIC_V0 0x1408
-#define ZIMAGE64_MAGIC_V1 0x644d5241 /* "ARM\x64" */
+#define ZIMAGE64_MAGIC 0x644d5241 /* "ARM\x64" */

  struct minimal_dtb_header {
  uint32_t magic;
@@ -335,17 +334,17 @@ static int kernel_zimage64_probe(struct kernel_info *info,
  {
  /* linux/Documentation/arm64/booting.txt */
  struct {
-uint32_t magic0;
-uint32_t res0;
-uint64_t text_offset;  /* Image load offset */
-uint64_t res1;
-uint64_t res2;
+uint32_t code0;
+uint32_t code1;
+uint64_t text_offset;  /* Image load offset, little endian */
+uint64_t image_size;   /* Effective Image size, little endian */
+uint64_t flags;
  /* zImage V1 only from here */


I think this comment is irrelevant now.


+uint64_t res2;
  uint64_t res3;
  uint64_t res4;
-uint64_t res5;
-uint32_t magic1;
-uint32_t res6;
+uint32_t magic;/* Magic number, little endian, "ARM\x64" */
+uint32_t res5;
  } zimage;
  uint64_t start, end;

@@ -354,20 +353,30 @@ static int kernel_zimage64_probe(struct kernel_info *info,

  copy_from_paddr(, addr, sizeof(zimage));

-if ( zimage.magic0 != ZIMAGE64_MAGIC_V0 &&
- zimage.magic1 != ZIMAGE64_MAGIC_V1 )
+if ( zimage.magic != ZIMAGE64_MAGIC ) {
+printk(XENLOG_ERR "No valid magic found in header! Kernel too old?\n");


I have found why there were no error messages here before. The function 
kernel_probe will try the different formats supported one by one.


So this message will be printed if the kernel is an ARM32 image, which 
will confuse the user. So I would print this message only when 
zimage.magic0 is equal to ZIMAGE64_MAGIC_V0.



  return -EINVAL;
+}

-/* Currently there is no length in the header, so just use the size */
  start = 0;
-end = size;

  /*
- * Given the above this check is a bit pointless, but leave it
- * here in case someone adds a length field in the future.
+ * Where image_size is non-zero image_size is little-endian
+ * and must be respected.
   */
-if ( (end - start) > size )
+if ( zimage.image_size )
+end = zimage.image_size;
+else
+end = size;
+
+if ( (end - start) > size ) {
+if ( zimage.image_size ) {


This check is not necessary. "(end - start) > size" will only succeed 
when zimage.image_size is different than 0.



+printk(XENLOG_ERR "Error: Kernel Image size: %lu bytes > bootmodule 
size: %lu bytes\n",
+   zimage.image_size, (uint64_t)size);
+printk(XENLOG_ERR "The field 'size' does not match the size of 
blob!\n");
+}
  return -EINVAL;
+}

  info->zimage.kernel_addr = addr;
  info->zimage.len = end - start;



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 00/11] hvmctl hypercall

[Andrew Cooper]

On 20/06/16 13:39, Jan Beulich wrote:
> A long while back separating out all control kind operations (intended
> for use by only the control domain or device model) from the currect
> hvmop hypercall has been discussed. This series aims at finally making
> this reality (at once allowing to streamline the associated XSM checking).
>
> 01: public / x86: introduce hvmctl hypercall
> 02: convert HVMOP_set_pci_intx_level
> 03: convert HVMOP_set_isa_irq_level
> 04: convert HVMOP_set_pci_link_route
> 05: convert HVMOP_track_dirty_vram
> 06: convert HVMOP_modified_memory
> 07: convert HVMOP_set_mem_type
> 08: convert HVMOP_inject_trap
> 09: convert HVMOP_inject_msi
> 10: convert HVMOP_*ioreq_server*
> 11: x86/HVM: serialize trap injecting producer and consumer
>
> Signed-off-by: Jan Beulich 
>

Patches 2 through 10 are all mechanical and look fine.  All Reviewed-by:
Andrew Cooper 

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

Re: [Xen-devel] [PATCH 11/11] x86/HVM: serialize trap injecting producer and consumer

[Andrew Cooper]

On 20/06/16 13:58, Jan Beulich wrote:
> Since injection works on a remote vCPU, and since there's no
> enforcement of the subject vCPU being paused, there's a potential race
> between the prodcing and consuming sides. Fix this by leveraging the

producing.

> vector field as synchronization variable.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 0/3] VMX: Properly handle pi descriptor and per-cpu blocking list

[Dario Faggioli]

On Thu, 2016-06-23 at 12:33 +, Wu, Feng wrote:
> > -Original Message-
> > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > 
> > It goes through all the vcpus of all domains, and does not check or
> > care whether they are running, runnable or blocked.
> > 
> > Let's look at this in some more details. So, let's assume that
> > processor 5 is going away, and that you have the following vcpus
> > around:
> > 
> >  d0v0 : v->processor = 5, running on cpu 5
> >  d0v1 : v->processor = 4, running on cpu 4
> >  d1v0 : v->processor = 5, runnable but not running
> >  d2v3 : v->processor = 5, blocked
> > 
> > for d0v0, we do:
> >   cpu_disable_scheduler(5)
> >     set_bit(_VPF_migrating, d0v0->pause_flags);
> >     vcpu_sleep_nosync(d0v0);
> >       SCHED_OP(sleep, d0v0);
> >         csched_vcpu_sleep(d0v0)
> >           cpu_raise_softirq(5, SCHEDULE_SOFTIRQ);
> >     vcpu_migrate(d0v0);
> >       if ( v->is_running || ...) // assume v->is_running is true
> >         return
> Hi Dario, after read this mail again, I get another question,
> could you please help me out?
> 
> In the above code flow, we return in vcpu_migrate(d0v0) because
> v->is_running == 1, after vcpu_migrate() return, we check:
> 
> if ( v->processor == cpu )
> ret = -EAGAIN; 
> 
> In my understand in the above case, 'v->processor' is likely equal to
> 'cpu', hence return -EAGAIN. However, in __cpu_disable(), there is
> some check as below:
> 
> if ( cpu_disable_scheduler(cpu) )
> BUG();
> 
Right. But, as the comment inside cpu_disable_scheduler() itself says,
we only return -EAGAIN in case we are calling cpu_disable_scheduler for
removing a pCPU from a cpupool.

In that case, we do not use __cpu_disable(), and hence we can safely
return an error value. In that case, in fact, the caller of
cpu_disable_scheduler() is cpupool_unassign_cpu_helprer(), which does
what's necessary to deal with such error.

> Might we hit the BUG() in the above case? 
>
No, because we call cpu_disable_scheduler() from __cpu_disable(), only
when system state is SYS_STATE_suspend already, and hence we take the
then branch of the 'if', which does never return an error.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

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  6a35f1e1fb03bbb957828f9f2cf8bfc47df95ee6
baseline version:
 xen  91b26a35914176db4d19dc145bc6e2db62ee7a2c

Last test of basis96116  2016-06-22 11:02:34 Z1 days
Testing same since96177  2016-06-23 13:02:08 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Julien Grall 

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=6a35f1e1fb03bbb957828f9f2cf8bfc47df95ee6
+ . ./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 
6a35f1e1fb03bbb957828f9f2cf8bfc47df95ee6
+ branch=xen-unstable-smoke
+ revision=6a35f1e1fb03bbb957828f9f2cf8bfc47df95ee6
+ . ./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.7-testing
+ '[' x6a35f1e1fb03bbb957828f9f2cf8bfc47df95ee6 = 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/
+++ '[' 

[Xen-devel] [PATCH v4 0/3] Make hvm_fep available to non-debug build

[Wei Liu]

Wei Liu (3):
  xen: add warning infrastructure
  console: use warning infrastructure for sync console warning
  xen: make available hvm_fep to non-debug build as well

 docs/misc/xen-command-line.markdown |  8 --
 xen/arch/x86/Kconfig| 17 
 xen/arch/x86/hvm/hvm.c  | 12 +++-
 xen/common/Makefile |  1 +
 xen/common/kernel.c |  6 ++--
 xen/common/warning.c| 55 +
 xen/drivers/char/console.c  | 37 +++--
 xen/include/asm-x86/hvm/hvm.h   |  2 +-
 xen/include/xen/lib.h   |  1 +
 xen/include/xen/warning.h   |  7 +
 10 files changed, 113 insertions(+), 33 deletions(-)
 create mode 100644 xen/common/warning.c
 create mode 100644 xen/include/xen/warning.h

-- 
2.1.4


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

Re: [Xen-devel] [PATCH 01/11] public / x86: introduce hvmctl hypercall

[Jan Beulich]

>>> On 23.06.16 at 16:55,  wrote:
> On 20/06/16 13:52, Jan Beulich wrote:
>> +/*
>> + * Note that this value is effectively part of the ABI, even if we don't 
> need
>> + * to make it a formal part of it.  Hence this value may only be changed if
>> + * accompanied by a suitable interface version increase.
>> + */
>> +#define HVMCTL_iter_shift 8
>> +#define HVMCTL_iter_mask  ((1U << HVMCTL_iter_shift) - 1)
>> +#define HVMCTL_iter_max   (1U << (16 + HVMCTL_iter_shift))
> 
> This (mis)use of the cmd parameter is surely no longer necessary, given
> that there is space in xen_hvmctl_t to encode continuation information?

There's no misuse of cmd anymore. This is just use to make the 16-bit
continuation value (the opaque structure member) cover a more useful
range, and at once avoid doing the preemption check on every
iteration.

Jan


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

[Xen-devel] [PATCH v4 2/3] console: use warning infrastructure for sync console warning

[Wei Liu]

Move the warning text to a static variable and marked that as initconst
data. Call warning_add in console_init_preirq. Finally remove all
unused bits.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v4:
1. Fix declaration of warning_sync_console.
2. Remove all asterisks in warning text.

v3: new
---
 xen/drivers/char/console.c | 36 
 1 file changed, 8 insertions(+), 28 deletions(-)

diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index ac21caf..650035d 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -30,6 +29,7 @@
 #include 
 #include  /* for do_console_io */
 #include 
+#include 
 
 /* console: comma-separated list of console outputs. */
 static char __initdata opt_console[30] = OPT_CONSOLE_STR;
@@ -45,6 +45,12 @@ string_param("conswitch", opt_conswitch);
 /* sync_console: force synchronous console output (useful for debugging). */
 static bool_t __initdata opt_sync_console;
 boolean_param("sync_console", opt_sync_console);
+static const char __initconst warning_sync_console[] =
+"WARNING: CONSOLE OUTPUT IS SYNCHRONOUS\n"
+"This option is intended to aid debugging of Xen by ensuring\n"
+"that all output is synchronously delivered on the serial line.\n"
+"However it can introduce SIGNIFICANT latencies and affect\n"
+"timekeeping. It is NOT recommended for production use!\n";
 
 /* console_to_ring: send guest (incl. dom 0) console data to console ring. */
 static bool_t __read_mostly opt_console_to_ring;
@@ -740,6 +746,7 @@ void __init console_init_preirq(void)
 serial_start_sync(sercon_handle);
 add_taint(TAINT_SYNC_CONSOLE);
 printk("Console output is synchronous.\n");
+warning_add(warning_sync_console);
 }
 }
 
@@ -787,8 +794,6 @@ void __init console_init_postirq(void)
 
 void __init console_endboot(void)
 {
-int i, j;
-
 printk("Std. Loglevel: %s", loglvl_str(xenlog_lower_thresh));
 if ( xenlog_upper_thresh != xenlog_lower_thresh )
 printk(" (Rate-limited: %s)", loglvl_str(xenlog_upper_thresh));
@@ -799,31 +804,6 @@ void __init console_endboot(void)
 
 warning_print();
 
-if ( opt_sync_console )
-{
-printk("**\n");
-printk("*** WARNING: CONSOLE OUTPUT IS SYNCHRONOUS\n");
-printk("*** This option is intended to aid debugging "
-   "of Xen by ensuring\n");
-printk("*** that all output is synchronously delivered "
-   "on the serial line.\n");
-printk("*** However it can introduce SIGNIFICANT latencies "
-   "and affect\n");
-printk("*** timekeeping. It is NOT recommended for "
-   "production use!\n");
-printk("**\n");
-for ( i = 0; i < 3; i++ )
-{
-printk("%d... ", 3-i);
-for ( j = 0; j < 100; j++ )
-{
-process_pending_softirqs();
-mdelay(10);
-}
-}
-printk("\n");
-}
-
 video_endboot();
 
 /*
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v3 2/2] xen/arm: drivers: scif: Don't overwrite firmware settings

[Julien Grall]

Hi Dirk,

On 22/06/16 12:49, Dirk Behme wrote:

Besides the 14MHz external clock, the SCIF might be clocked by an
internal 66MHz clock. If this is the case, the current clock source
selection breaks this configuration. Same for the settings done by
the firmware for data bits, stop bits and parity.

Completely drop this and rely on the settings done by the firmware.

Signed-off-by: Dirk Behme 


Reviewed-by: Julien Grall 

Regards,


---
  xen/drivers/char/scif-uart.c | 40 
  1 file changed, 40 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index bc157fe..f9ae257 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -41,7 +41,6 @@
  #define scif_writew(uart, off, val)writew((val), (uart)->regs + (off))

  static struct scif_uart {
-unsigned int data_bits, parity, stop_bits;
  unsigned int irq;
  char __iomem *regs;
  struct irqaction irqaction;
@@ -87,7 +86,6 @@ static void scif_uart_interrupt(int irq, void *data, struct 
cpu_user_regs *regs)
  static void __init scif_uart_init_preirq(struct serial_port *port)
  {
  struct scif_uart *uart = port->uart;
-uint16_t val;

  /*
   * Wait until last bit has been transmitted. This is needed for a smooth
@@ -107,40 +105,6 @@ static void __init scif_uart_init_preirq(struct 
serial_port *port)
  scif_readw(uart, SCIF_SCLSR);
  scif_writew(uart, SCIF_SCLSR, 0);

-/* Select Baud rate generator output as a clock source */
-scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10);
-
-/* Setup protocol format and Baud rate, select Asynchronous mode */
-val = 0;
-ASSERT( uart->data_bits >= 7 && uart->data_bits <= 8 );
-if ( uart->data_bits == 7 )
-val |= SCSMR_CHR;
-else
-val &= ~SCSMR_CHR;
-
-ASSERT( uart->stop_bits >= 1 && uart->stop_bits <= 2 );
-if ( uart->stop_bits == 2 )
-val |= SCSMR_STOP;
-else
-val &= ~SCSMR_STOP;
-
-ASSERT( uart->parity >= PARITY_NONE && uart->parity <= PARITY_ODD );
-switch ( uart->parity )
-{
-case PARITY_NONE:
-val &= ~SCSMR_PE;
-break;
-
-case PARITY_EVEN:
-val |= SCSMR_PE;
-break;
-
-case PARITY_ODD:
-val |= SCSMR_PE | SCSMR_ODD;
-break;
-}
-scif_writew(uart, SCIF_SCSMR, val);
-
  /* Setup trigger level for TX/RX FIFOs */
  scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);

@@ -283,10 +247,6 @@ static int __init scif_uart_init(struct dt_device_node 
*dev,

  uart = _com;

-uart->data_bits = 8;
-uart->parity= PARITY_NONE;
-uart->stop_bits = 1;
-
  res = dt_device_get_address(dev, 0, , );
  if ( res )
  {



--
Julien Grall

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

[Xen-devel] [PATCH v4 1/3] xen: add warning infrastructure

[Wei Liu]

Use an array to keep track of warning text, provide a function to add
warning text to track.  Print warnings (if any) in console_endboot.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v4:
1. Fix __initdata annotation.
2. Move warning_print to console_endboot.
3. Use obj-bin-y in Makefile.
4. Print asterisks in warning_print.

v3: new
---
 xen/common/Makefile|  1 +
 xen/common/warning.c   | 55 ++
 xen/drivers/char/console.c |  3 +++
 xen/include/xen/warning.h  |  7 ++
 4 files changed, 66 insertions(+)
 create mode 100644 xen/common/warning.c
 create mode 100644 xen/include/xen/warning.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index e9893e2..dbf00c6 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,6 +59,7 @@ obj-y += vm_event.o
 obj-y += vmap.o
 obj-y += vsprintf.o
 obj-y += wait.o
+obj-bin-y += warning.init.o
 obj-$(CONFIG_XENOPROF) += xenoprof.o
 obj-y += xmalloc_tlsf.o
 
diff --git a/xen/common/warning.c b/xen/common/warning.c
new file mode 100644
index 000..8bdd299
--- /dev/null
+++ b/xen/common/warning.c
@@ -0,0 +1,55 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define WARNING_ARRAY_SIZE 20
+static unsigned int __initdata nr_warnings;
+static const char *__initdata warnings[WARNING_ARRAY_SIZE];
+
+void __init warning_add(const char *warning)
+{
+if ( nr_warnings >= WARNING_ARRAY_SIZE )
+panic("Too many pieces of warning text.");
+
+warnings[nr_warnings] = warning;
+nr_warnings++;
+}
+
+void __init warning_print(void)
+{
+unsigned int i, j;
+
+if ( !nr_warnings )
+return;
+
+printk("***\n");
+
+for ( i = 0; i < nr_warnings; i++ )
+{
+printk("%s", warnings[i]);
+printk("***\n");
+}
+
+for ( i = 0; i < 3; i++ )
+{
+printk("%u... ", 3 - i);
+for ( j = 0; j < 100; j++ )
+{
+process_pending_softirqs();
+mdelay(10);
+}
+}
+printk("\n");
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index f4f6141..ac21caf 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include  /* for do_console_io */
@@ -796,6 +797,8 @@ void __init console_endboot(void)
 printk(" (Rate-limited: %s)", loglvl_str(xenlog_guest_upper_thresh));
 printk("\n");
 
+warning_print();
+
 if ( opt_sync_console )
 {
 printk("**\n");
diff --git a/xen/include/xen/warning.h b/xen/include/xen/warning.h
new file mode 100644
index 000..c0661d5
--- /dev/null
+++ b/xen/include/xen/warning.h
@@ -0,0 +1,7 @@
+#ifndef _WARNING_H_
+#define _WARNING_H_
+
+void warning_add(const char *warning);
+void warning_print(void);
+
+#endif
-- 
2.1.4


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

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Andrew Cooper]

On 23/06/16 15:59, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 23, 2016 at 03:12:04PM +0100, Andrew Cooper wrote:
>> On 23/06/16 14:25, Marek Marczykowski-Górecki wrote:
>>> On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
>>> On 23.06.16 at 11:23,  wrote:
> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki 
> wrote:
>> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>> On 23.06.16 at 10:57,  wrote:
 On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
> I wonder what good the duplication of the returned domain ID does: I'm
> tempted to remove the one in the command-specific structure. Does
> anyone have insight into why it was done that way?
 Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
 existing domain with ID >= passed one? Reading various comments in code
 it looks to be used to domain enumeration. This patch changes this
 behaviour.
>>> No, it doesn't. It adjusts the behavior only for the DM case (which
>>> isn't supposed to get information on other than the target domain,
>>> i.e. in this one specific case the very domain ID needs to be passed
>>> in).
>> int xc_domain_getinfo(xc_interface *xch,
>>   uint32_t first_domid,
>>   unsigned int max_doms,
>>   xc_dominfo_t *info)
>> {
>> unsigned int nr_doms;
>> uint32_t next_domid = first_domid;
>> DECLARE_DOMCTL;
>> int rc = 0;
>>
>> memset(info, 0, max_doms*sizeof(xc_dominfo_t));
>>
>> for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
>> {   
>> domctl.cmd = XEN_DOMCTL_getdomaininfo;
>> domctl.domain = (domid_t)next_domid;
>> if ( (rc = do_domctl(xch, )) < 0 )
>> break;
>> info->domid  = (uint16_t)domctl.domain;
>> (...)
>> next_domid = (uint16_t)domctl.domain + 1;
>>
>>
>> Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next 
> valid
>> domain.
> Hmm, looks like I've misread you patch. Reading again...
>
> But now I see rcu_read_lock(_read_lock) is gets called only when
> looping over domains, but rcu_read_unlock is called in any case. Is it
> correct?
 How that? There is this third hunk:
>>> Ok, after drawing a flowchart of the control in this function after your
>>> change, on a piece of paper, this case looks fine. But depending on how
>>> the domain was found (explicit loop or rcu_lock_domain_by_id), different
>>> locks are held, which makes it harder to follow what is going on.
>>>
>>> Crazy idea: how about making the code easy/easier to read instead of
>>> obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
>>> convolved enough. How about this version (2 patches):
>>>
>>> xen: move domain lookup for getdomaininfo to the same
>>>
>>> XEN_DOMCTL_getdomaininfo have different semantics than most of others
>>> domctls - it returns information about first valid domain with ID >=
>>> argument. But that's no excuse for having the lookup done in a different
>>> place, which made handling different corner cases unnecessary complex.
>>> Move the lookup to the first switch clause. And adjust locking to be the
>>> same as for other cases.
>>>
>>> Signed-off-by: Marek Marczykowski-Górecki 
>> FWIW, I prefer this solution to the issue.
>>
>> Reviewed-by: Andrew Cooper , with a few style
>> nits.
> Fixed patch according to your comments:
>
> xen: move domain lookup for getdomaininfo to the same
>
> XEN_DOMCTL_getdomaininfo have different semantics than most of others
> domctls - it returns information about first valid domain with ID >=
> argument. But that's no excuse for having the lookup code in a different
> place, which made handling different corner cases unnecessary complex.
> Move the lookup to the first switch clause. And adjust locking to be the
> same as for other cases.
>
> Signed-off-by: Marek Marczykowski-Górecki 

Reviewed-by: Andrew Cooper 

> ---
>  xen/common/domctl.c | 44 +++-
>  1 file changed, 23 insertions(+), 21 deletions(-)
>
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index e43904e..41de3e8 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -442,11 +442,32 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  switch ( op->cmd )
>  {
>  case XEN_DOMCTL_createdomain:
> -case XEN_DOMCTL_getdomaininfo:
>  case XEN_DOMCTL_test_assign_device:
>  case XEN_DOMCTL_gdbsx_guestmemio:
>  d = NULL;
>  break;
> +
> +case XEN_DOMCTL_getdomaininfo:
> +d = 

Re: [Xen-devel] [PATCH] xen/arm: domain_build: DT: add clocks node to the hypervisor node

[Julien Grall]

On 22/06/16 16:58, Julien Grall wrote:

On 21/06/16 11:15, Dirk Behme wrote:

+printk("Failed to remember the clock node of %s\n", path);
+printk("Use the Linux kernel command
'clk_ignore_unused'\n");
+return 0;


I don't think this is tolerable. We need to fix it  once and for all.

I understand that xen does not provide a realloc function. Is there
another way we can get a rid of this limit?


Note that I would wait that we agree on the device tree bindings before 
reworking this patch. It will avoid you to waste time if we decide to 
move towards a different solution.



I am wondering if we can use the member domain_list of dt_device_node to
link the device having a clock property. And then latter one, allocate
the memory + copying the data.


+}
+memcpy(>clk.dtclocks[kinfo->clk.cnt], clocks, len);
+kinfo->clk.cnt += len;
  return 0;
  }



Regards,

--
Julien Grall

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

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Daniel De Graaf]

On 06/23/2016 09:25 AM, Marek Marczykowski-Górecki wrote:
[...]

Ok, after drawing a flowchart of the control in this function after your
change, on a piece of paper, this case looks fine. But depending on how
the domain was found (explicit loop or rcu_lock_domain_by_id), different
locks are held, which makes it harder to follow what is going on.

Crazy idea: how about making the code easy/easier to read instead of
obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
convolved enough. How about this version (2 patches):

[...]

xen: allow XEN_DOMCTL_getdomaininfo for device model

Allow device model domain to get info about its target domain.
It is used during PCI passthrough setup (xc_domain_memory_mapping
checks for guest being auto-translated). While it happens in stubdomain,
it failed, breaking PCI passthrough in such setup.

While it is possible to workaround this at toolstack side, it seems
logical to allow device model to get information about its target
domain.

The problem was exposed by c428c9f "tools/libxl: handle the iomem
parameter with the memory_mapping hcall".

Signed-off-by: Marek Marczykowski-Górecki 
---
 xen/include/xsm/dummy.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 406cd18..70a1633 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -128,7 +128,10 @@ static XSM_INLINE int xsm_domctl(XSM_DEFAULT_ARG struct 
domain *d, int cmd)
 case XEN_DOMCTL_unbind_pt_irq:
 return xsm_default_action(XSM_DM_PRIV, current->domain, d);
 case XEN_DOMCTL_getdomaininfo:
-return xsm_default_action(XSM_XS_PRIV, current->domain, d);
+if (current->domain->target)
+return xsm_default_action(XSM_DM_PRIV, current->domain, d);
+else
+return xsm_default_action(XSM_XS_PRIV, current->domain, d);
 default:
 return xsm_default_action(XSM_PRIV, current->domain, d);
 }


I would prefer testing for the xenstore flag instead of testing for the
target field.  It ends up being the same thing in reality, since nobody
sane would make the xenstore also a device model (and not also dom0).

  case XEN_DOMCTL_getdomaininfo:
  if ( src->is_xenstore )
  return 0;
  return xsm_default_action(XSM_DM_PRIV, current->domain, d);

This makes it clear that xenstore is the special case, and removes the
need for the one-off XSM_XS_PRIV constant.  


--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH v2 07/17] libxl/arm: Construct ACPI GTDT table

[Stefano Stabellini]

On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Construct GTDT table with the interrupt information of timers.
> 
> Signed-off-by: Shannon Zhao 
> ---
>  tools/libxl/libxl_arm_acpi.c | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index d5ffedf..de863f4 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -39,6 +39,9 @@ typedef uint64_t u64;
>  #define ACPI_BUILD_APPNAME6 "XenARM"
>  #define ACPI_BUILD_APPNAME4 "Xen "
>  
> +#define ACPI_LEVEL_SENSITIVE(u8) 0x00
> +#define ACPI_ACTIVE_LOW (u8) 0x01
> +
>  enum {
>  RSDP,
>  XSDT,
> @@ -110,6 +113,30 @@ static void make_acpi_xsdt(libxl__gc *gc, struct 
> xc_dom_image *dom)
>  dom->acpitable_size += ROUNDUP(acpitables[XSDT].size, 3);
>  }
>  
> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +struct acpi_table_gtdt *gtdt;
> +size_t size = sizeof(*gtdt);
> +
> +gtdt = libxl__zalloc(gc, size);
> +
> +gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
> +gtdt->non_secure_el1_flags =
> + (ACPI_LEVEL_SENSITIVE << 
> ACPI_GTDT_INTERRUPT_MODE)
> + |(ACPI_ACTIVE_LOW << 
> ACPI_GTDT_INTERRUPT_POLARITY);
> +gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
> +gtdt->virtual_timer_flags =
> + (ACPI_LEVEL_SENSITIVE << 
> ACPI_GTDT_INTERRUPT_MODE)
> + |(ACPI_ACTIVE_LOW << 
> ACPI_GTDT_INTERRUPT_POLARITY);
> +
> +make_acpi_header(>header, "GTDT", size, 2);
> +
> +acpitables[GTDT].table = gtdt;
> +acpitables[GTDT].size = size;
> +/* Align to 64bit. */
> +dom->acpitable_size += ROUNDUP(acpitables[GTDT].size, 3);
> +}

Many of this tables look pretty much static. Any reason why we can't
define them and initialize them on an header somewhere like:

struct acpi_gtdt xen_acpi_gtdt {
.non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
.non_secure_el1_flags = (ACPI_LEVEL_SENSITIVE << 
ACPI_GTDT_INTERRUPT_MODE) | (ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
.virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
.virtual_timer_flags = (ACPI_LEVEL_SENSITIVE << 
ACPI_GTDT_INTERRUPT_MODE)|(ACPI_ACTIVE_LOW << ACPI_GTDT_INTERRUPT_POLARITY);
};

it would make the code shorter and easier to read.


>  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>  libxl__domain_build_state *state,
>  struct xc_dom_image *dom)
> @@ -132,6 +159,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
> libxl_domain_build_info *info,
>  
>  make_acpi_rsdp(gc, dom);
>  make_acpi_xsdt(gc, dom);
> +make_acpi_gtdt(gc, dom);
>  
>  return 0;
>  }
> -- 
> 2.0.4
> 
> 

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

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Marek Marczykowski-Górecki]

On Thu, Jun 23, 2016 at 03:12:04PM +0100, Andrew Cooper wrote:
> On 23/06/16 14:25, Marek Marczykowski-Górecki wrote:
> > On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
> > On 23.06.16 at 11:23,  wrote:
> >>> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki 
> >>> wrote:
>  On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>  On 23.06.16 at 10:57,  wrote:
> >> On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
> >>> I wonder what good the duplication of the returned domain ID does: I'm
> >>> tempted to remove the one in the command-specific structure. Does
> >>> anyone have insight into why it was done that way?
> >> Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
> >> existing domain with ID >= passed one? Reading various comments in code
> >> it looks to be used to domain enumeration. This patch changes this
> >> behaviour.
> > No, it doesn't. It adjusts the behavior only for the DM case (which
> > isn't supposed to get information on other than the target domain,
> > i.e. in this one specific case the very domain ID needs to be passed
> > in).
>  int xc_domain_getinfo(xc_interface *xch,
>    uint32_t first_domid,
>    unsigned int max_doms,
>    xc_dominfo_t *info)
>  {
>  unsigned int nr_doms;
>  uint32_t next_domid = first_domid;
>  DECLARE_DOMCTL;
>  int rc = 0;
> 
>  memset(info, 0, max_doms*sizeof(xc_dominfo_t));
> 
>  for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
>  {   
>  domctl.cmd = XEN_DOMCTL_getdomaininfo;
>  domctl.domain = (domid_t)next_domid;
>  if ( (rc = do_domctl(xch, )) < 0 )
>  break;
>  info->domid  = (uint16_t)domctl.domain;
>  (...)
>  next_domid = (uint16_t)domctl.domain + 1;
> 
> 
>  Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next 
> >>> valid
>  domain.
> >>> Hmm, looks like I've misread you patch. Reading again...
> >>>
> >>> But now I see rcu_read_lock(_read_lock) is gets called only when
> >>> looping over domains, but rcu_read_unlock is called in any case. Is it
> >>> correct?
> >> How that? There is this third hunk:
> > Ok, after drawing a flowchart of the control in this function after your
> > change, on a piece of paper, this case looks fine. But depending on how
> > the domain was found (explicit loop or rcu_lock_domain_by_id), different
> > locks are held, which makes it harder to follow what is going on.
> >
> > Crazy idea: how about making the code easy/easier to read instead of
> > obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
> > convolved enough. How about this version (2 patches):
> >
> > xen: move domain lookup for getdomaininfo to the same
> >
> > XEN_DOMCTL_getdomaininfo have different semantics than most of others
> > domctls - it returns information about first valid domain with ID >=
> > argument. But that's no excuse for having the lookup done in a different
> > place, which made handling different corner cases unnecessary complex.
> > Move the lookup to the first switch clause. And adjust locking to be the
> > same as for other cases.
> >
> > Signed-off-by: Marek Marczykowski-Górecki 
> 
> FWIW, I prefer this solution to the issue.
> 
> Reviewed-by: Andrew Cooper , with a few style
> nits.

Fixed patch according to your comments:

xen: move domain lookup for getdomaininfo to the same

XEN_DOMCTL_getdomaininfo have different semantics than most of others
domctls - it returns information about first valid domain with ID >=
argument. But that's no excuse for having the lookup code in a different
place, which made handling different corner cases unnecessary complex.
Move the lookup to the first switch clause. And adjust locking to be the
same as for other cases.

Signed-off-by: Marek Marczykowski-Górecki 
---
 xen/common/domctl.c | 44 +++-
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index e43904e..41de3e8 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -442,11 +442,32 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 switch ( op->cmd )
 {
 case XEN_DOMCTL_createdomain:
-case XEN_DOMCTL_getdomaininfo:
 case XEN_DOMCTL_test_assign_device:
 case XEN_DOMCTL_gdbsx_guestmemio:
 d = NULL;
 break;
+
+case XEN_DOMCTL_getdomaininfo:
+d = rcu_lock_domain_by_id(op->domain);
+
+if ( d == NULL )
+{
+/* Search for the next available domain. */
+rcu_read_lock(_read_lock);
+
+ 

Re: [Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...

[Julien Grall]

On 23/06/16 15:15, Stefano Stabellini wrote:

On Thu, 23 Jun 2016, Julien Grall wrote:

On 23/06/16 15:05, Stefano Stabellini wrote:

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index aa4e774..47cb383 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
   }

   int map_mmio_regions(struct domain *d,
- unsigned long start_gfn,
+ gfn_t start_gfn,
unsigned long nr,
- unsigned long mfn)
+ mfn_t mfn)
   {
   return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
MATTR_DEV, 0, p2m_mmio_direct,
d->arch.p2m.default_access);


Any reason why you didn't push these changes down to apply_p2m_changes too?


To keep this series simple. I have another series coming up to push the change
down to apply_p2m_changes and clean up the P2M code.

I can move the patch to push down the change in this series if you prefer.


Yeah, it makes sense to keep them together.


Well, I still plan to have a different patch to push down the change. 
Switching from unsigned long to gfn/mfn is a long work which need to be 
split to ease the review.


I will see what I can do.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 01/11] public / x86: introduce hvmctl hypercall

[Andrew Cooper]

On 20/06/16 13:52, Jan Beulich wrote:
> +/*
> + * Note that this value is effectively part of the ABI, even if we don't need
> + * to make it a formal part of it.  Hence this value may only be changed if
> + * accompanied by a suitable interface version increase.
> + */
> +#define HVMCTL_iter_shift 8
> +#define HVMCTL_iter_mask  ((1U << HVMCTL_iter_shift) - 1)
> +#define HVMCTL_iter_max   (1U << (16 + HVMCTL_iter_shift))

This (mis)use of the cmd parameter is surely no longer necessary, given
that there is space in xen_hvmctl_t to encode continuation information?

~Andrew


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

Re: [Xen-devel] [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

[Stefano Stabellini]

On Thu, 23 Jun 2016, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> It uses static DSDT table like the way x86 uses. Currently the DSDT
> table only contains processor device objects and it generates the
> maximal objects which so far is 128.
> 
> Signed-off-by: Shannon Zhao 
> ---
>  tools/libxl/Makefile | 24 -
>  tools/libxl/libxl_arm_acpi.c | 15 ++
>  tools/libxl/libxl_arm_acpi.h |  2 +
>  tools/libxl/libxl_empty_dsdt_arm.asl | 22 +
>  tools/libxl/libxl_mk_dsdt_arm.c  | 94 
> 
>  5 files changed, 156 insertions(+), 1 deletion(-)
>  create mode 100644 tools/libxl/libxl_empty_dsdt_arm.asl
>  create mode 100644 tools/libxl/libxl_mk_dsdt_arm.c
> 
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 264b6ef..5347480 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -77,7 +77,29 @@ endif
>  
>  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
>  LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
> -LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o
> +LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_acpi.o libxl_dsdt_anycpu_arm.o
> +
> +vpath iasl $(PATH)
> +libxl_mk_dsdt_arm: libxl_mk_dsdt_arm.c
> + $(CC) $(CFLAGS) -o $@ libxl_mk_dsdt_arm.c
> +
> +libxl_dsdt_anycpu_arm.asl: libxl_empty_dsdt_arm.asl libxl_mk_dsdt_arm
> + awk 'NR > 1 {print s} {s=$$0}' $< > $@
> + ./libxl_mk_dsdt_arm >> $@
> +
> +libxl_dsdt_anycpu_arm.c: %.c: iasl %.asl
> + iasl -vs -p $* -tc $*.asl
> + sed -e 's/AmlCode/$*/g' $*.hex >$@
> + echo "int $*_len=sizeof($*);" >>$@
> + rm -f $*.aml $*.hex
> +
> +iasl:
> + @echo
> + @echo "ACPI ASL compiler (iasl) is needed"
> + @echo "Download and install Intel ACPI CA from"
> + @echo "http://acpica.org/downloads/;
> + @echo
> + @exit 1
>  
>  libxl_arm_acpi.o: libxl_arm_acpi.c
>   $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 353d774..45fc354 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -54,6 +54,9 @@ enum {
>  NUMS,
>  };
>  
> +extern unsigned char libxl_dsdt_anycpu_arm[];
> +extern int libxl_dsdt_anycpu_arm_len;
> +
>  struct acpitable {
>  void *table;
>  size_t size;
> @@ -256,6 +259,17 @@ static void make_acpi_fadt(libxl__gc *gc, struct 
> xc_dom_image *dom)
>  dom->acpitable_size += ROUNDUP(acpitables[FADT].size, 3);
>  }
>  
> +static void make_acpi_dsdt(libxl__gc *gc, struct xc_dom_image *dom)
> +{
> +acpitables[DSDT].table = libxl__zalloc(gc, libxl_dsdt_anycpu_arm_len);
> +memcpy(acpitables[DSDT].table, libxl_dsdt_anycpu_arm,
> +   libxl_dsdt_anycpu_arm_len);
> +
> +acpitables[DSDT].size = libxl_dsdt_anycpu_arm_len;
> +/* Align to 64bit. */
> +dom->acpitable_size += ROUNDUP(acpitables[DSDT].size, 3);
> +}
> +
>  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>  libxl__domain_build_state *state,
>  struct xc_dom_image *dom)
> @@ -284,6 +298,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
> libxl_domain_build_info *info,
>   return rc;
>  
>  make_acpi_fadt(gc, dom);
> +make_acpi_dsdt(gc, dom);
>  
>  return 0;
>  }
> diff --git a/tools/libxl/libxl_arm_acpi.h b/tools/libxl/libxl_arm_acpi.h
> index 9b58de6..b0fd9ce 100644
> --- a/tools/libxl/libxl_arm_acpi.h
> +++ b/tools/libxl/libxl_arm_acpi.h
> @@ -19,6 +19,8 @@
>  
>  #include 
>  
> +#define DOMU_MAX_VCPUS 128
> +
>  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>  libxl__domain_build_state *state,
>  struct xc_dom_image *dom);
> diff --git a/tools/libxl/libxl_empty_dsdt_arm.asl 
> b/tools/libxl/libxl_empty_dsdt_arm.asl
> new file mode 100644
> index 000..005fa6a
> --- /dev/null
> +++ b/tools/libxl/libxl_empty_dsdt_arm.asl
> @@ -0,0 +1,22 @@
> +/**
> + * DSDT for Xen ARM DomU
> + *
> + * Copyright (c) 2004, Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program; If not, see .
> + */
> +
> +DefinitionBlock ("DSDT.aml", "DSDT", 3, "XenARM", "Xen DSDT", 1)
> +{
> +
> +}

Why do we need C code to 

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Jan Beulich]

>>> On 23.06.16 at 15:25,  wrote:
> On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
>> >>> On 23.06.16 at 11:23,  wrote:
>> > On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
>> >> On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
>> >> > >>> On 23.06.16 at 10:57,  wrote:
>> >> > > On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
>> >> > >> I wonder what good the duplication of the returned domain ID does: 
>> >> > >> I'm
>> >> > >> tempted to remove the one in the command-specific structure. Does
>> >> > >> anyone have insight into why it was done that way?
>> >> > > 
>> >> > > Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
>> >> > > existing domain with ID >= passed one? Reading various comments in 
>> >> > > code
>> >> > > it looks to be used to domain enumeration. This patch changes this
>> >> > > behaviour.
>> >> > 
>> >> > No, it doesn't. It adjusts the behavior only for the DM case (which
>> >> > isn't supposed to get information on other than the target domain,
>> >> > i.e. in this one specific case the very domain ID needs to be passed
>> >> > in).
>> >> 
>> >> int xc_domain_getinfo(xc_interface *xch,
>> >>   uint32_t first_domid,
>> >>   unsigned int max_doms,
>> >>   xc_dominfo_t *info)
>> >> {
>> >> unsigned int nr_doms;
>> >> uint32_t next_domid = first_domid;
>> >> DECLARE_DOMCTL;
>> >> int rc = 0;
>> >> 
>> >> memset(info, 0, max_doms*sizeof(xc_dominfo_t));
>> >> 
>> >> for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
>> >> {   
>> >> domctl.cmd = XEN_DOMCTL_getdomaininfo;
>> >> domctl.domain = (domid_t)next_domid;
>> >> if ( (rc = do_domctl(xch, )) < 0 )
>> >> break;
>> >> info->domid  = (uint16_t)domctl.domain;
>> >> (...)
>> >> next_domid = (uint16_t)domctl.domain + 1;
>> >> 
>> >> 
>> >> Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next 
>> > valid
>> >> domain.
>> > 
>> > Hmm, looks like I've misread you patch. Reading again...
>> > 
>> > But now I see rcu_read_lock(_read_lock) is gets called only when
>> > looping over domains, but rcu_read_unlock is called in any case. Is it
>> > correct?
>> 
>> How that? There is this third hunk:
> 
> Ok, after drawing a flowchart of the control in this function after your
> change, on a piece of paper, this case looks fine. But depending on how
> the domain was found (explicit loop or rcu_lock_domain_by_id), different
> locks are held, which makes it harder to follow what is going on.
> 
> Crazy idea: how about making the code easy/easier to read instead of
> obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
> convolved enough. How about this version (2 patches):
> 
> xen: move domain lookup for getdomaininfo to the same

I don't mind this one.

> xen: allow XEN_DOMCTL_getdomaininfo for device model

But I don't really like this, and would prefer my solution here; it's
Daniel's call though.

Jan

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

Re: [Xen-devel] [PATCH v5 02/14] libxc: Prepare a start info structure for hvmloader

[Boris Ostrovsky]

On 06/22/2016 01:15 PM, Anthony PERARD wrote:
> ... and load BIOS/UEFI firmware into guest memory.
>
> This adds a new firmware module, system_firmware_module. It is loaded in
> the guest memory and final location is provided to hvmloader via the
> hvm_start_info struct.
>
> This patch create the hvm_start_info struct for HVM guest that have a
> device model, so this is now common code with HVM guest without device
> model.
>
> Signed-off-by: Anthony PERARD 
> ---
> CC: boris.ostrov...@oracle.com
> CC: roger@citrix.com
>
> Changes in V5:
> - in alloc_magic_pages_hvm, check dom->device_model only once instead of
>   twice (fold second if into previous else)
> - rework add_module_to_list to make it easier to read
> - also comment about the intended memory layout of start_info and the
>   modules
> - in bootlate_hvm(), drop start_page and use start_info as they point to
>   the same address
> - rename xc_dom_image.bios_module to xc_dom_image.system_firmware_module
> - rename module name to "firmware" (was "bios")
>
> Changes in V4:
> - change title to suggest the change of beavior
> - remove code to load acpi tables (dsdt)
> - Update public/xen.h about hvm_start_info available on other HVM guest
>   in %ebx.
>
> Changes in V3:
> - rename acpi_table_module to full_acpi_module.
> - factorise module loading, using new function to load existing optinal
>   module, this should not change anything
> - should now use the same code to loads modules as for HVMlite VMs.
>   this avoid duplication of code.
> - no more generic cmdline with a list of modules, each module have its name
>   in the module specific cmdline.
> - scope change for common code between hvmlite and hvmloader
> ---
>  tools/libxc/include/xc_dom.h   |   3 +
>  tools/libxc/xc_dom_hvmloader.c |   3 +
>  tools/libxc/xc_dom_x86.c   | 152 
> +
>  xen/include/public/xen.h   |   2 +-
>  4 files changed, 116 insertions(+), 44 deletions(-)
>
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 6cb10c4..0629971 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -209,6 +209,9 @@ struct xc_dom_image {
>  /* If unset disables the setup of the IOREQ pages. */
>  bool device_model;
>  
> +/* BIOS/Firmware passed to HVMLOADER */
> +struct xc_hvm_firmware_module system_firmware_module;
> +
>  /* Extra ACPI tables passed to HVMLOADER */
>  struct xc_hvm_firmware_module acpi_module;
>  
> diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
> index da8b995..cf2d57c 100644
> --- a/tools/libxc/xc_dom_hvmloader.c
> +++ b/tools/libxc/xc_dom_hvmloader.c
> @@ -167,6 +167,9 @@ static int modules_init(struct xc_dom_image *dom)
>  {
>  int rc;
>  
> +rc = module_init_one(dom, >system_firmware_module,
> + "System Firmware module");
> +if ( rc ) goto err;
>  rc = module_init_one(dom, >acpi_module, "ACPI module");
>  if ( rc ) goto err;
>  rc = module_init_one(dom, >smbios_module, "SMBIOS module");
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index 021f8a8..f017fbd 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -69,6 +69,9 @@
>  #define round_up(addr, mask) ((addr) | (mask))
>  #define round_pg_up(addr)  (((addr) + PAGE_SIZE_X86 - 1) & ~(PAGE_SIZE_X86 - 
> 1))
>  
> +#define HVMLOADER_MODULE_MAX_COUNT 1
> +#define HVMLOADER_MODULE_NAME_SIZE 10
> +
>  struct xc_dom_params {
>  unsigned levels;
>  xen_vaddr_t vaddr_mask;
> @@ -590,6 +593,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
>  xen_pfn_t special_array[X86_HVM_NR_SPECIAL_PAGES];
>  xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
>  xc_interface *xch = dom->xch;
> +size_t start_info_size = sizeof(struct hvm_start_info);
>  
>  /* Allocate and clear special pages. */
>  for ( i = 0; i < X86_HVM_NR_SPECIAL_PAGES; i++ )
> @@ -624,8 +628,6 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
>  
>  if ( !dom->device_model )
>  {
> -size_t start_info_size = sizeof(struct hvm_start_info);
> -
>  if ( dom->cmdline )
>  {
>  dom->cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
> @@ -635,17 +637,18 @@ static int alloc_magic_pages_hvm(struct xc_dom_image 
> *dom)
>  /* Limited to one module. */
>  if ( dom->ramdisk_blob )
>  start_info_size += sizeof(struct hvm_modlist_entry);
> -
> -rc = xc_dom_alloc_segment(dom, >start_info_seg,
> -  "HVMlite start info", 0, start_info_size);
> -if ( rc != 0 )
> -{
> -DOMPRINTF("Unable to reserve memory for the start info");
> -goto out;
> -}
>  }
>  else
>  {
> +start_info_size +=
> +sizeof(struct hvm_modlist_entry) * HVMLOADER_MODULE_MAX_COUNT;
> +  

Re: [Xen-devel] [PATCH v2 03/17] libxl/arm: Add a configuration option for ARM DomU ACPI

[Shannon Zhao]

On 2016年06月23日 21:39, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>> > From: Shannon Zhao 
>> > 
>> > Add a configuration option for ARM DomU so that user can deicde to use
>> > ACPI or not. This option is defaultly false.
>> > 
>> > Signed-off-by: Shannon Zhao 
>> > ---
>> >  tools/libxl/libxl_arm.c   | 3 +++
>> >  tools/libxl/libxl_types.idl   | 1 +
>> >  tools/libxl/xl_cmdimpl.c  | 4 
>> >  xen/include/public/arch-arm.h | 1 +
>> >  4 files changed, 9 insertions(+)
>> > 
>> > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> > index 8f15d9b..cc5a717 100644
>> > --- a/tools/libxl/libxl_arm.c
>> > +++ b/tools/libxl/libxl_arm.c
>> > @@ -77,6 +77,9 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>> >  return ERROR_FAIL;
>> >  }
>> >  
>> > +xc_config->acpi = libxl_defbool_val(d_config->b_info.arch_arm.acpi)
>> > +  ? true : false;
>> > +
>> >  return 0;
>> >  }
>> >  
>> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> > index ef614be..426b868 100644
>> > --- a/tools/libxl/libxl_types.idl
>> > +++ b/tools/libxl/libxl_types.idl
>> > @@ -560,6 +560,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>> >  
>> >  
>> >  ("arch_arm", Struct(None, [("gic_version", libxl_gic_version),
>> > +   ("acpi", libxl_defbool),
>> >])),
>> >  
>> >  ], dir=DIR_IN
>> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
>> > index 6459eec..0634ffa 100644
>> > --- a/tools/libxl/xl_cmdimpl.c
>> > +++ b/tools/libxl/xl_cmdimpl.c
>> > @@ -2506,6 +2506,10 @@ skip_usbdev:
>> >  }
>> >   }
>> >  
>> > +if (xlu_cfg_get_defbool(config, "acpi", _info->arch_arm.acpi, 0)) {
>> > +libxl_defbool_set(_info->arch_arm.acpi, 0);
>> > +}
> We cannot share the existing code to parse the acpi paramter because
> that is saved in b_info->u.hvm.acpi, right? 
Yes.
> It's a pity. I wonder if we
> could refactor the existing code so that we can actually share the acpi
> parameter between x86 and arm.
> 
I have no idea about this since I'm not familiar with this. But is there
any downsides of current way? Because for x86, it will use
b_info->u.hvm.acpi and for ARM it will use b_info->arch_arm.acpi. I
think they don't conflict even though we store it at two places.

Or could we add some codes to check the arch and decide where to store it?

Thanks,
-- 
Shannon

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

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Daniel De Graaf]

On 06/23/2016 04:39 AM, Jan Beulich wrote:

On 23.06.16 at 10:32,  wrote:

On 22.06.16 at 20:24,  wrote:

Either method works, and I agree allowing DM to invoke this domctl is both
useful and not going to introduce problems.  The getdomaininfo permission
will also need to be added to the device_model macro in xen.if.


What exactly this last sentence means I need to add I'm not sure
about.


Perhaps this?

--- unstable.orig/tools/flask/policy/policy/modules/xen/xen.if
+++ unstable/tools/flask/policy/policy/modules/xen/xen.if
@@ -148,7 +148,7 @@ define(`device_model', `
create_channel($2, $1, $2_channel)
allow $1 $2_channel:event create;

-   allow $1 $2_target:domain shutdown;
+   allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
irqlevel pciroute pcilevel cacheattr send_irq };
 ')

Jan


Yes, that is what I meant.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH v2] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM

[Shannon Zhao]

On 2016年06月23日 21:42, Ard Biesheuvel wrote:
> On 23 June 2016 at 13:31, Shannon Zhao  wrote:
>> From: Shannon Zhao 
>>
>> Add ACPI support for Virt Xen ARM and only for aarch64. It gets the
>> ACPI tables through Xen ARM multiboot protocol.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Shannon Zhao 
>> ---
>> Changes since v1:
>> * move the codes into ArmVirtPkg
>> * use FdtClient
>> * don't rely on OvmfPkg/AcpiPlatformDxe/EntryPoint.c while implement own
>>   entry point since it's minor
>> * use compatible string to find the DT node instead of node path
>>
>> If you want to test, the corresponding Xen patches can be fetched from:
>> https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v2
>> ---
>>  ArmVirtPkg/ArmVirtXen.dsc  |   8 +
>>  ArmVirtPkg/ArmVirtXen.fdf  |   8 +
>>  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 241 
>> +
>>  .../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf  |  49 +
>>  4 files changed, 306 insertions(+)
>>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>>  create mode 100644 ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>>
>> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
>> index 594ca64..a869986 100644
>> --- a/ArmVirtPkg/ArmVirtXen.dsc
>> +++ b/ArmVirtPkg/ArmVirtXen.dsc
>> @@ -216,3 +216,11 @@
>>
>>OvmfPkg/XenBusDxe/XenBusDxe.inf
>>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>> +
>> +  #
>> +  # ACPI support
>> +  #
>> +!if $(ARCH) == AARCH64
>> +  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>> +  ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>> +!endif
>> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
>> index 13412f9..b1e00e5 100644
>> --- a/ArmVirtPkg/ArmVirtXen.fdf
>> +++ b/ArmVirtPkg/ArmVirtXen.fdf
>> @@ -179,6 +179,14 @@ READ_LOCK_STATUS   = TRUE
>>INF OvmfPkg/XenBusDxe/XenBusDxe.inf
>>INF OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
>>
>> +  #
>> +  # ACPI support
>> +  #
>> +!if $(ARCH) == AARCH64
>> +  INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>> +  INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>> +!endif
>> +
>>  [FV.FVMAIN_COMPACT]
>>  FvAlignment= 16
>>  ERASE_POLARITY = 1
>> diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c 
>> b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>> new file mode 100644
>> index 000..9258be8
>> --- /dev/null
>> +++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
>> @@ -0,0 +1,241 @@
>> +/** @file
>> +  Xen ARM ACPI Platform Driver using Xen ARM multiboot protocol
>> +
>> +  Copyright (C) 2016, Linaro Ltd. All rights reserved.
>> +
>> +  This program and the accompanying materials
>> +  are licensed and made available under the terms and conditions of the BSD 
>> License
>> +  which accompanies this distribution.  The full text of the license may be 
>> found at
>> +  http://opensource.org/licenses/bsd-license.php
>> +
>> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
>> +  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
>> IMPLIED.
>> +
>> +**/
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *XenAcpiRsdpStructurePtr = 
>> NULL;
>> +
> 
> Does this need to be a global? If yes, please add STATIC, and prefix
> the name with 'm'. Otherwise, move it into InstallXenArmTables ().
> 
Ok, I'll move it to InstallXenArmTables().

>> +/**
>> +  Get the address of Xen ACPI Root System Description Pointer (RSDP)
>> +  structure.
>> +
>> +  @param  RsdpStructurePtr   Return pointer to RSDP structure
>> +
>> +  @return EFI_SUCCESSFind Xen RSDP structure successfully.
>> +  @return EFI_NOT_FOUND  Don't find Xen RSDP structure.
>> +  @return EFI_ABORTEDFind Xen RSDP structure, but it's not 
>> integrated.
>> +
>> +**/
>> +EFI_STATUS
>> +EFIAPI
>> +GetXenArmAcpiRsdp (
> 
> ... and here
> 
Ok.

>> +  OUT   EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   **RsdpPtr
>> +  )
>> +{
>> +  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   *RsdpStructurePtr;
>> +  EFI_STATUS Status;
>> +  FDT_CLIENT_PROTOCOL*FdtClient;
>> +  CONST UINT64   *Reg;
>> +  UINT32 RegElemSize, RegSize;
>> +  UINT64 RegBase;
>> +  UINT8  Sum;
>> +
>> +  RsdpStructurePtr = NULL;
> 
> Please initialize FdtClient to NULL here.
> 
Sure.

>> +  //
>> +  // Get the RSDP structure address from DeviceTree
>> +  //
>> +  Status = gBS->LocateProtocol (, NULL,
> 
> Please add gFdtClientProtocolGuid to the [Depex] section of this module
> 
Ok.

>> +  

Re: [Xen-devel] [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables

[Stefano Stabellini]

On Thu, 23 Jun 2016, Shannon Zhao wrote:
> On 2016年06月23日 21:37, Stefano Stabellini wrote:
> > On Thu, 23 Jun 2016, Shannon Zhao wrote:
> >> +
> >> +if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
> >> +LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
> >> +state->config.acpi = false;
> > 
> > Shouldn't we return here?
> > 
> Ah, right, thanks!
> > 
> >> +}
> >> +
> >> +return libxl__prepare_acpi(gc, info, state, dom);
> >>  }
> >>  
> >>  static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
> >> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> >> new file mode 100644
> >> index 000..60c31f9
> >> --- /dev/null
> >> +++ b/tools/libxl/libxl_arm_acpi.c
> >> @@ -0,0 +1,85 @@
> >> +/*
> >> + * ARM DmoU ACPI generation
> >> + *
> >> + * Copyright (C) 2008-2010  Kevin O'Connor 
> >> + * Copyright (C) 2006 Fabrice Bellard
> >> + * Copyright (C) 2013 Red Hat Inc
> >> + *
> >> + * Author: Michael S. Tsirkin 
> >> + *
> >> + * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO.,LTD.
> >> + *
> >> + * Author: Shannon Zhao 
> >> + *
> >> + * Copyright (C) 2016  Linaro Ltd.
> >> + *
> >> + * Author: Shannon Zhao 
> > 
> > Uhm... If in doubt just remove all the Author lines: git log provides
> > more than enough information about who wrote this code.
> > 
> Ahm... Julien suggested I should import the copyright from QEMU since I
> refer to that. While what I didn't say before is that even if I didn't
> refer to QEMU codes, the implementation will be like this because for
> the tables except DSDT we just fill in the contents of the tables. But
> for DSDT generation, it's totally different compared with QEMU.
> 
> I think I'll remove this. :)

I see. It's important to keep all the right signed-off-by, acked-by and
reviewed-by in the commit message. But the author list on source files
doesn't make much sense these days.___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 04/17] libxl/arm: prepare for constructing ACPI tables

[Shannon Zhao]

On 2016年06月23日 21:37, Stefano Stabellini wrote:
> On Thu, 23 Jun 2016, Shannon Zhao wrote:
>> +
>> +if (strcmp(dom->guest_type, "xen-3.0-aarch64")) {
>> +LOG(DEBUG, "Do not generate ACPI tables for %s", dom->guest_type);
>> +state->config.acpi = false;
> 
> Shouldn't we return here?
> 
Ah, right, thanks!
> 
>> +}
>> +
>> +return libxl__prepare_acpi(gc, info, state, dom);
>>  }
>>  
>>  static void finalise_one_memory_node(libxl__gc *gc, void *fdt,
>> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
>> new file mode 100644
>> index 000..60c31f9
>> --- /dev/null
>> +++ b/tools/libxl/libxl_arm_acpi.c
>> @@ -0,0 +1,85 @@
>> +/*
>> + * ARM DmoU ACPI generation
>> + *
>> + * Copyright (C) 2008-2010  Kevin O'Connor 
>> + * Copyright (C) 2006 Fabrice Bellard
>> + * Copyright (C) 2013 Red Hat Inc
>> + *
>> + * Author: Michael S. Tsirkin 
>> + *
>> + * Copyright (c) 2015 HUAWEI TECHNOLOGIES CO.,LTD.
>> + *
>> + * Author: Shannon Zhao 
>> + *
>> + * Copyright (C) 2016  Linaro Ltd.
>> + *
>> + * Author: Shannon Zhao 
> 
> Uhm... If in doubt just remove all the Author lines: git log provides
> more than enough information about who wrote this code.
> 
Ahm... Julien suggested I should import the copyright from QEMU since I
refer to that. While what I didn't say before is that even if I didn't
refer to QEMU codes, the implementation will be like this because for
the tables except DSDT we just fill in the contents of the tables. But
for DSDT generation, it's totally different compared with QEMU.

I think I'll remove this. :)

Thanks,
-- 
Shannon

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

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

[osstest service owner]

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

Regressions :-(

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

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-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-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass

version targeted for testing:
 qemuu12e8fccf5b5460be7aecddc71d27eceaba6e1f15
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  138 days
Failing since 93977  2016-05-10 11:09:16 Z   44 days  142 attempts
Testing same since95534  2016-06-11 00:59:46 Z   12 days   22 attempts


People who touched revisions under test:
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   pass



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

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

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

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


Not pushing.


commit 12e8fccf5b5460be7aecddc71d27eceaba6e1f15
Author: Ian Jackson 
Date:   Thu May 26 16:21:56 2016 +0100

main loop: Big hammer to fix logfile disk DoS in Xen setups

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Andrew Cooper]

On 23/06/16 10:50, Jan Beulich wrote:
 On 23.06.16 at 11:44,  wrote:
>> On 23/06/16 09:32, Jan Beulich wrote:
>>> I wonder what good the duplication of the returned domain ID does: I'm
>>> tempted to remove the one in the command-specific structure. Does
>>> anyone have insight into why it was done that way?
>> This hypercall, and its sibling XEN_SYSCTL_getdomaininfolist have crazy
>> semantics, which go out of their way to make it easy to get wrong.
>>
>> It is important that you always check the returned domid, as it may not
>> be the domain you asked for.  In particular, if a domain you are looking
>> after dies, the adjacent domain's information will be returnned.
> Same question as to Marek: How is this related to my remark?

Oh right.  I misread.  Altering the domctl domid value is pointless, as
libxc abstracts the call behind do_domctl() anyway.

~Andrew

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

Re: [Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...

[Stefano Stabellini]

On Thu, 23 Jun 2016, Julien Grall wrote:
> On 23/06/16 15:05, Stefano Stabellini wrote:
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index aa4e774..47cb383 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
> > >   }
> > > 
> > >   int map_mmio_regions(struct domain *d,
> > > - unsigned long start_gfn,
> > > + gfn_t start_gfn,
> > >unsigned long nr,
> > > - unsigned long mfn)
> > > + mfn_t mfn)
> > >   {
> > >   return apply_p2m_changes(d, INSERT,
> > > - pfn_to_paddr(start_gfn),
> > > - pfn_to_paddr(start_gfn + nr),
> > > - pfn_to_paddr(mfn),
> > > + pfn_to_paddr(gfn_x(start_gfn)),
> > > + pfn_to_paddr(gfn_x(start_gfn) + nr),
> > > + pfn_to_paddr(mfn_x(mfn)),
> > >MATTR_DEV, 0, p2m_mmio_direct,
> > >d->arch.p2m.default_access);
> > 
> > Any reason why you didn't push these changes down to apply_p2m_changes too?
> 
> To keep this series simple. I have another series coming up to push the change
> down to apply_p2m_changes and clean up the P2M code.
> 
> I can move the patch to push down the change in this series if you prefer.

Yeah, it makes sense to keep them together.

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

Re: [Xen-devel] [PATCH v3 7/8] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn

[Stefano Stabellini]

On Tue, 21 Jun 2016, Julien Grall wrote:
> The prototype and the declaration of p2m_lookup disagree on how the
> function should be used. One expect a frame number whilst the other
> an address.
> 
> Thankfully, everyone is using with an address today. However, most of
> the callers have to convert a guest frame to an address. Modify
> the interface to take a guest physical frame in parameter and return
> a machine frame.
> 
> Whilst modifying the interface, use typesafe gfn and mfn for clarity
> and catching possible misusage.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/p2m.c| 37 -
>  xen/arch/arm/traps.c  | 21 +++--
>  xen/include/asm-arm/p2m.h |  7 +++
>  3 files changed, 34 insertions(+), 31 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 47cb383..f3330dd 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -140,14 +140,15 @@ void flush_tlb_domain(struct domain *d)
>  }
>  
>  /*
> - * Lookup the MFN corresponding to a domain's PFN.
> + * Lookup the MFN corresponding to a domain's GFN.
>   *
>   * There are no processor functions to do a stage 2 only lookup therefore we
>   * do a a software walk.
>   */
> -static paddr_t __p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
> +static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
>  {
>  struct p2m_domain *p2m = >arch.p2m;
> +const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
>  const unsigned int offsets[4] = {
>  zeroeth_table_offset(paddr),
>  first_table_offset(paddr),
> @@ -158,7 +159,7 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
> paddr, p2m_type_t *t)
>  ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
>  };
>  lpae_t pte, *map;
> -paddr_t maddr = INVALID_PADDR;
> +mfn_t mfn = _mfn(INVALID_MFN);

It might be worth defining INVALID_MFN_T and just assign that to mfn.


>  paddr_t mask = 0;
>  p2m_type_t _t;
>  unsigned int level, root_table;
> @@ -216,21 +217,22 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
> paddr, p2m_type_t *t)
>  {
>  ASSERT(mask);
>  ASSERT(pte.p2m.type != p2m_invalid);
> -maddr = (pte.bits & PADDR_MASK & mask) | (paddr & ~mask);
> +mfn = _mfn(paddr_to_pfn((pte.bits & PADDR_MASK & mask) |
> +(paddr & ~mask)));
>  *t = pte.p2m.type;
>  }
>  
>  err:
> -return maddr;
> +return mfn;
>  }
>  
> -paddr_t p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
> +mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
>  {
> -paddr_t ret;
> +mfn_t ret;
>  struct p2m_domain *p2m = >arch.p2m;
>  
>  spin_lock(>lock);
> -ret = __p2m_lookup(d, paddr, t);
> +ret = __p2m_lookup(d, gfn, t);
>  spin_unlock(>lock);
>  
>  return ret;
> @@ -493,8 +495,9 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t 
> gfn,
>   * No setting was found in the Radix tree. Check if the
>   * entry exists in the page-tables.
>   */
> -paddr_t maddr = __p2m_lookup(d, gfn_x(gfn) << PAGE_SHIFT, NULL);
> -if ( INVALID_PADDR == maddr )
> +mfn_t mfn = __p2m_lookup(d, gfn, NULL);
> +
> +if ( mfn_x(mfn) == INVALID_MFN )
>  return -ESRCH;
>  
>  /* If entry exists then its rwx. */
> @@ -1483,8 +1486,7 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t 
> start_mfn, xen_pfn_t end_mfn)
>  
>  mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
>  {
> -paddr_t p = p2m_lookup(d, pfn_to_paddr(gfn_x(gfn)), NULL);
> -return _mfn(p >> PAGE_SHIFT);
> +return p2m_lookup(d, gfn, NULL);
>  }
>  
>  /*
> @@ -1498,7 +1500,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag)
>  {
>  long rc;
>  paddr_t ipa;
> -unsigned long maddr;
> +gfn_t gfn;
>  unsigned long mfn;
>  xenmem_access_t xma;
>  p2m_type_t t;
> @@ -1508,11 +1510,13 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, 
> unsigned long flag)
>  if ( rc < 0 )
>  goto err;
>  
> +gfn = _gfn(paddr_to_pfn(ipa));
> +
>  /*
>   * We do this first as this is faster in the default case when no
>   * permission is set on the page.
>   */
> -rc = __p2m_get_mem_access(current->domain, _gfn(paddr_to_pfn(ipa)), 
> );
> +rc = __p2m_get_mem_access(current->domain, gfn, );
>  if ( rc < 0 )
>  goto err;
>  
> @@ -1561,11 +1565,10 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, 
> unsigned long flag)
>   * We had a mem_access permission limiting the access, but the page type
>   * could also be limiting, so we need to check that as well.
>   */
> -maddr = __p2m_lookup(current->domain, ipa, );
> -if ( maddr == INVALID_PADDR )
> +mfn = mfn_x(__p2m_lookup(current->domain, gfn, ));
> +if ( mfn == INVALID_MFN )

The conversion would go away if we 

Re: [Xen-devel] PCI passthrough for HVM with stubdomain broken by "tools/libxl: handle the iomem parameter with the memory_mapping hcall"

[Andrew Cooper]

On 23/06/16 14:25, Marek Marczykowski-Górecki wrote:
> On Thu, Jun 23, 2016 at 03:46:46AM -0600, Jan Beulich wrote:
> On 23.06.16 at 11:23,  wrote:
>>> On Thu, Jun 23, 2016 at 11:18:24AM +0200, Marek Marczykowski-Górecki wrote:
 On Thu, Jun 23, 2016 at 03:12:47AM -0600, Jan Beulich wrote:
 On 23.06.16 at 10:57,  wrote:
>> On Thu, Jun 23, 2016 at 02:32:29AM -0600, Jan Beulich wrote:
>>> I wonder what good the duplication of the returned domain ID does: I'm
>>> tempted to remove the one in the command-specific structure. Does
>>> anyone have insight into why it was done that way?
>> Isn't XEN_DOMCTL_getdomaininfo supposed to return info about first
>> existing domain with ID >= passed one? Reading various comments in code
>> it looks to be used to domain enumeration. This patch changes this
>> behaviour.
> No, it doesn't. It adjusts the behavior only for the DM case (which
> isn't supposed to get information on other than the target domain,
> i.e. in this one specific case the very domain ID needs to be passed
> in).
 int xc_domain_getinfo(xc_interface *xch,
   uint32_t first_domid,
   unsigned int max_doms,
   xc_dominfo_t *info)
 {
 unsigned int nr_doms;
 uint32_t next_domid = first_domid;
 DECLARE_DOMCTL;
 int rc = 0;

 memset(info, 0, max_doms*sizeof(xc_dominfo_t));

 for ( nr_doms = 0; nr_doms < max_doms; nr_doms++ )
 {   
 domctl.cmd = XEN_DOMCTL_getdomaininfo;
 domctl.domain = (domid_t)next_domid;
 if ( (rc = do_domctl(xch, )) < 0 )
 break;
 info->domid  = (uint16_t)domctl.domain;
 (...)
 next_domid = (uint16_t)domctl.domain + 1;


 Looks like heavily dependent on XEN_DOMCTL_getdomaininfo returning next 
>>> valid
 domain.
>>> Hmm, looks like I've misread you patch. Reading again...
>>>
>>> But now I see rcu_read_lock(_read_lock) is gets called only when
>>> looping over domains, but rcu_read_unlock is called in any case. Is it
>>> correct?
>> How that? There is this third hunk:
> Ok, after drawing a flowchart of the control in this function after your
> change, on a piece of paper, this case looks fine. But depending on how
> the domain was found (explicit loop or rcu_lock_domain_by_id), different
> locks are held, which makes it harder to follow what is going on.
>
> Crazy idea: how about making the code easy/easier to read instead of
> obfuscating it even more? XEN_DOMCTL_getdomaininfo semantic is
> convolved enough. How about this version (2 patches):
>
> xen: move domain lookup for getdomaininfo to the same
>
> XEN_DOMCTL_getdomaininfo have different semantics than most of others
> domctls - it returns information about first valid domain with ID >=
> argument. But that's no excuse for having the lookup done in a different
> place, which made handling different corner cases unnecessary complex.
> Move the lookup to the first switch clause. And adjust locking to be the
> same as for other cases.
>
> Signed-off-by: Marek Marczykowski-Górecki 

FWIW, I prefer this solution to the issue.

Reviewed-by: Andrew Cooper , with a few style
nits.

> ---
>  xen/common/domctl.c | 41 -
>  1 file changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index e43904e..6ae1fe0 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -442,11 +442,29 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  switch ( op->cmd )
>  {
>  case XEN_DOMCTL_createdomain:
> -case XEN_DOMCTL_getdomaininfo:
>  case XEN_DOMCTL_test_assign_device:
>  case XEN_DOMCTL_gdbsx_guestmemio:
>  d = NULL;
>  break;

Newline here please.

> +case XEN_DOMCTL_getdomaininfo:
> +d = rcu_lock_domain_by_id(op->domain);

And here.

> +if ( d == NULL )
> +{
> +/* search for the next valid domain */

/* Search for the next available domain. */

> +rcu_read_lock(_read_lock);
> +
> +for_each_domain ( d )
> +if ( d->domain_id >= op->domain )
> +{
> +rcu_lock_domain(d);
> +break;
> +}
> +
> +rcu_read_unlock(_read_lock);
> +if ( d == NULL )
> +return -ESRCH;
> +}
> +break;

Another newline here please.

>  default:
>  d = rcu_lock_domain_by_id(op->domain);
>  if ( d == NULL )
> @@ -862,33 +880,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  break;
>  
>  case XEN_DOMCTL_getdomaininfo:
> -{
> -domid_t dom 

Re: [Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...

[Julien Grall]

On 23/06/16 15:05, Stefano Stabellini wrote:

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index aa4e774..47cb383 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
  }

  int map_mmio_regions(struct domain *d,
- unsigned long start_gfn,
+ gfn_t start_gfn,
   unsigned long nr,
- unsigned long mfn)
+ mfn_t mfn)
  {
  return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
   MATTR_DEV, 0, p2m_mmio_direct,
   d->arch.p2m.default_access);


Any reason why you didn't push these changes down to apply_p2m_changes too?


To keep this series simple. I have another series coming up to push the 
change down to apply_p2m_changes and clean up the P2M code.


I can move the patch to push down the change in this series if you prefer.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...

[Stefano Stabellini]

On Tue, 21 Jun 2016, Julien Grall wrote:
> to avoid mixing machine frame with guest frame.
> 
> Signed-off-by: Julien Grall 
> Acked-by: Jan Beulich 
> 
> ---
> Cc: Stefano Stabellini 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> 
> Changes in v3:
> - Use mfn_add when it is possible
> - Add Jan's acked-by
> ---
>  xen/arch/arm/domain_build.c  |  4 ++--
>  xen/arch/arm/gic-v2.c|  4 ++--
>  xen/arch/arm/p2m.c   | 22 +++---
>  xen/arch/arm/platforms/exynos5.c |  8 
>  xen/arch/arm/platforms/omap5.c   | 16 
>  xen/arch/arm/vgic-v2.c   |  4 ++--
>  xen/arch/x86/mm/p2m.c| 18 ++
>  xen/common/domctl.c  |  4 ++--
>  xen/include/xen/p2m-common.h |  8 
>  9 files changed, 45 insertions(+), 43 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 9035486..49185f0 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1036,9 +1036,9 @@ static int map_range_to_domain(const struct 
> dt_device_node *dev,
>  if ( need_mapping )
>  {
>  res = map_mmio_regions(d,
> -   paddr_to_pfn(addr),
> +   _gfn(paddr_to_pfn(addr)),
> DIV_ROUND_UP(len, PAGE_SIZE),
> -   paddr_to_pfn(addr));
> +   _mfn(paddr_to_pfn(addr)));
>  if ( res < 0 )
>  {
>  printk(XENLOG_ERR "Unable to map 0x%"PRIx64
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 4e2f4c7..3893ece 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -601,9 +601,9 @@ static int gicv2_map_hwdown_extra_mappings(struct domain 
> *d)
> d->domain_id, v2m_data->addr, v2m_data->size,
> v2m_data->spi_start, v2m_data->nr_spis);
>  
> -ret = map_mmio_regions(d, paddr_to_pfn(v2m_data->addr),
> +ret = map_mmio_regions(d, _gfn(paddr_to_pfn(v2m_data->addr)),
>  DIV_ROUND_UP(v2m_data->size, PAGE_SIZE),
> -paddr_to_pfn(v2m_data->addr));
> +_mfn(paddr_to_pfn(v2m_data->addr)));
>  if ( ret )
>  {
>  printk(XENLOG_ERR "GICv2: Map v2m frame to d%d failed.\n",
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index aa4e774..47cb383 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
>  }
>  
>  int map_mmio_regions(struct domain *d,
> - unsigned long start_gfn,
> + gfn_t start_gfn,
>   unsigned long nr,
> - unsigned long mfn)
> + mfn_t mfn)
>  {
>  return apply_p2m_changes(d, INSERT,
> - pfn_to_paddr(start_gfn),
> - pfn_to_paddr(start_gfn + nr),
> - pfn_to_paddr(mfn),
> + pfn_to_paddr(gfn_x(start_gfn)),
> + pfn_to_paddr(gfn_x(start_gfn) + nr),
> + pfn_to_paddr(mfn_x(mfn)),
>   MATTR_DEV, 0, p2m_mmio_direct,
>   d->arch.p2m.default_access);

Any reason why you didn't push these changes down to apply_p2m_changes too?


>  }
>  
>  int unmap_mmio_regions(struct domain *d,
> -   unsigned long start_gfn,
> +   gfn_t start_gfn,
> unsigned long nr,
> -   unsigned long mfn)
> +   mfn_t mfn)
>  {
>  return apply_p2m_changes(d, REMOVE,
> - pfn_to_paddr(start_gfn),
> - pfn_to_paddr(start_gfn + nr),
> - pfn_to_paddr(mfn),
> + pfn_to_paddr(gfn_x(start_gfn)),
> + pfn_to_paddr(gfn_x(start_gfn) + nr),
> + pfn_to_paddr(mfn_x(mfn)),
>   MATTR_DEV, 0, p2m_invalid,
>   d->arch.p2m.default_access);
>  }
> @@ -1280,7 +1280,7 @@ int map_dev_mmio_region(struct domain *d,
>  if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
>  return 0;
>  
> -res = map_mmio_regions(d, start_gfn, nr, mfn);
> +res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
>  if ( res < 0 )
>  {
>  printk(XENLOG_G_ERR "Unable to map [%#lx 

Re: [Xen-devel] [PATCH v3 5/8] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn

[Stefano Stabellini]

On Tue, 21 Jun 2016, Julien Grall wrote:
> The correct acronym for a guest physical frame is gfn. Also use
> the typesafe gfn to ensure that a guest frame is effectively used.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> ---
> Changes in v2:
> - Remove extra pair of brackets.
> ---
>  xen/arch/arm/domain.c | 4 ++--
>  xen/arch/arm/mm.c | 2 +-
>  xen/include/asm-arm/domain.h  | 2 +-
>  xen/include/asm-arm/grant_table.h | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index d8a804c..6ce4645 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -464,13 +464,13 @@ struct domain *alloc_domain_struct(void)
>  return NULL;
>  
>  clear_page(d);
> -d->arch.grant_table_gpfn = xzalloc_array(xen_pfn_t, max_grant_frames);
> +d->arch.grant_table_gfn = xzalloc_array(gfn_t, max_grant_frames);
>  return d;
>  }
>  
>  void free_domain_struct(struct domain *d)
>  {
> -xfree(d->arch.grant_table_gpfn);
> +xfree(d->arch.grant_table_gfn);
>  free_xenheap_page(d);
>  }
>  
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 6882d54..0e408f8 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1082,7 +1082,7 @@ int xenmem_add_to_physmap_one(
>  return -EINVAL;
>  }
>  
> -d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
> +d->arch.grant_table_gfn[idx] = gfn;
>  
>  t = p2m_ram_rw;
>  
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index 370cdeb..979f7de 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -51,7 +51,7 @@ struct arch_domain
>  uint64_t vttbr;
>  
>  struct hvm_domain hvm_domain;
> -xen_pfn_t *grant_table_gpfn;
> +gfn_t *grant_table_gfn;
>  
>  struct vmmio vmmio;
>  
> diff --git a/xen/include/asm-arm/grant_table.h 
> b/xen/include/asm-arm/grant_table.h
> index 5e076cc..eb02423 100644
> --- a/xen/include/asm-arm/grant_table.h
> +++ b/xen/include/asm-arm/grant_table.h
> @@ -30,7 +30,7 @@ static inline int replace_grant_supported(void)
>  
>  #define gnttab_shared_gmfn(d, t, i)  \
>  ( ((i >= nr_grant_frames(d->grant_table)) && \
> - (i < max_grant_frames)) ? 0 : (d->arch.grant_table_gpfn[i]))
> + (i < max_grant_frames)) ? 0 : gfn_x(d->arch.grant_table_gfn[i]))
>  
>  #define gnttab_need_iommu_mapping(d)\
>  (is_domain_direct_mapped(d) && need_iommu(d))
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one

[Stefano Stabellini]

On Tue, 21 Jun 2016, Julien Grall wrote:
> The x86 version of the function xenmem_add_to_physmap_one contains
> variable name gpfn and gfn which make the code very confusing.
> I have left unchanged for now.
> 
> Also, rename gpfn to gfn in the ARM version as the latter is the correct
> acronym for a guest physical frame.
> 
> Finally, remove the trailing whitespace around the changes.
> 
> Signed-off-by: Julien Grall 
> Acked-by: Jan Beulich 

Acked-by: Stefano Stabellini 


> ---
> Cc: Stefano Stabellini 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> 
> Changes in v3:
> - Add Jan's acked-by for non-ARM bits
> ---
>  xen/arch/arm/mm.c| 10 +-
>  xen/arch/x86/mm.c| 15 +++
>  xen/common/memory.c  |  6 +++---
>  xen/include/xen/mm.h |  2 +-
>  4 files changed, 16 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 5ab9b75..6882d54 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1046,7 +1046,7 @@ int xenmem_add_to_physmap_one(
>  unsigned int space,
>  union xen_add_to_physmap_batch_extra extra,
>  unsigned long idx,
> -xen_pfn_t gpfn)
> +gfn_t gfn)
>  {
>  unsigned long mfn = 0;
>  int rc;
> @@ -1081,8 +1081,8 @@ int xenmem_add_to_physmap_one(
>  else
>  return -EINVAL;
>  }
> -
> -d->arch.grant_table_gpfn[idx] = gpfn;
> +
> +d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
>  
>  t = p2m_ram_rw;
>  
> @@ -1145,7 +1145,7 @@ int xenmem_add_to_physmap_one(
>  if ( extra.res0 )
>  return -EOPNOTSUPP;
>  
> -rc = map_dev_mmio_region(d, gpfn, 1, idx);
> +rc = map_dev_mmio_region(d, gfn_x(gfn), 1, idx);
>  return rc;
>  
>  default:
> @@ -1153,7 +1153,7 @@ int xenmem_add_to_physmap_one(
>  }
>  
>  /* Map at new location. */
> -rc = guest_physmap_add_entry(d, _gfn(gpfn), _mfn(mfn), 0, t);
> +rc = guest_physmap_add_entry(d, gfn, _mfn(mfn), 0, t);
>  
>  /* If we fail to add the mapping, we need to drop the reference we
>   * took earlier on foreign pages */
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 7fbc94e..dbcf6cb 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4775,7 +4775,7 @@ int xenmem_add_to_physmap_one(
>  unsigned int space,
>  union xen_add_to_physmap_batch_extra extra,
>  unsigned long idx,
> -xen_pfn_t gpfn)
> +gfn_t gpfn)
>  {
>  struct page_info *page = NULL;
>  unsigned long gfn = 0; /* gcc ... */
> @@ -4834,7 +4834,7 @@ int xenmem_add_to_physmap_one(
>  break;
>  }
>  case XENMAPSPACE_gmfn_foreign:
> -return p2m_add_foreign(d, idx, gpfn, extra.foreign_domid);
> +return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
>  default:
>  break;
>  }
> @@ -4849,19 +4849,18 @@ int xenmem_add_to_physmap_one(
>  }
>  
>  /* Remove previously mapped page if it was present. */
> -prev_mfn = mfn_x(get_gfn(d, gpfn, ));
> +prev_mfn = mfn_x(get_gfn(d, gfn_x(gpfn), ));
>  if ( mfn_valid(prev_mfn) )
>  {
>  if ( is_xen_heap_mfn(prev_mfn) )
>  /* Xen heap frames are simply unhooked from this phys slot. */
> -guest_physmap_remove_page(d, _gfn(gpfn), _mfn(prev_mfn),
> -  PAGE_ORDER_4K);
> +guest_physmap_remove_page(d, gpfn, _mfn(prev_mfn), 
> PAGE_ORDER_4K);
>  else
>  /* Normal domain memory is freed, to avoid leaking memory. */
> -guest_remove_page(d, gpfn);
> +guest_remove_page(d, gfn_x(gpfn));
>  }
>  /* In the XENMAPSPACE_gmfn case we still hold a ref on the old page. */
> -put_gfn(d, gpfn);
> +put_gfn(d, gfn_x(gpfn));
>  
>  /* Unmap from old location, if any. */
>  old_gpfn = get_gpfn_from_mfn(mfn);
> @@ -4872,7 +4871,7 @@ int xenmem_add_to_physmap_one(
>  guest_physmap_remove_page(d, _gfn(old_gpfn), _mfn(mfn), 
> PAGE_ORDER_4K);
>  
>  /* Map at new location. */
> -rc = guest_physmap_add_page(d, _gfn(gpfn), _mfn(mfn), PAGE_ORDER_4K);
> +rc = guest_physmap_add_page(d, gpfn, _mfn(mfn), PAGE_ORDER_4K);
>  
>  /* In the XENMAPSPACE_gmfn, we took a ref of the gfn at the top */
>  if ( space == XENMAPSPACE_gmfn || space == XENMAPSPACE_gmfn_range )
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index a8a75e0..812334b 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -649,7 +649,7 @@ static int xenmem_add_to_physmap(struct domain *d,
>  
>  if (