[Xen-devel] [PATCH] arm64: Fix the bug in fdt module

[fu . wei]

From: Fu Wei 

This patch goes with commit:
4d0cb755387d6f109b901386ed4d3d475df239fe
 arm64: Move FDT functions to separate module

linux and xen_boot modules can't work without this patch.

Signed-off-by: Fu Wei 
---
 grub-core/Makefile.core.def  | 1 +
 grub-core/loader/arm64/fdt.c | 5 +
 2 files changed, 6 insertions(+)

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 2ef10d1..3ea4e49 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1674,6 +1674,7 @@ module = {
 module = {
   name = fdt;
   arm64 = loader/arm64/fdt.c;
+  fdt = lib/fdt.c;
   enable = arm64;
 };
 
diff --git a/grub-core/loader/arm64/fdt.c b/grub-core/loader/arm64/fdt.c
index 5202c14..d160ca0 100644
--- a/grub-core/loader/arm64/fdt.c
+++ b/grub-core/loader/arm64/fdt.c
@@ -25,6 +25,10 @@
 #include 
 #include 
 
+GRUB_MOD_LICENSE ("GPLv3+");
+
+static grub_dl_t my_mod;
+
 static void *loaded_fdt;
 static void *fdt;
 
@@ -177,6 +181,7 @@ GRUB_MOD_INIT (fdt)
   cmd_devicetree =
 grub_register_command ("devicetree", grub_cmd_devicetree, 0,
   N_("Load DTB file."));
+  my_mod = mod;
 }
 
 GRUB_MOD_FINI (fdt)
-- 
2.4.3


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

[Xen-devel] [PATCH v9 15/17] vmx: VT-d posted-interrupt core logic handling

[Feng Wu]

This patch includes the following aspects:
- Handling logic when vCPU is blocked:
* Add a global vector to wake up the blocked vCPU
  when an interrupt is being posted to it (This part
  was sugguested by Yang Zhang ).
* Define two per-cpu variables:
  1. pi_blocked_vcpu:
A list storing the vCPUs which were blocked
on this pCPU.

  2. pi_blocked_vcpu_lock:
The spinlock to protect pi_blocked_vcpu.

- Add the following hooks, this part was suggested
  by George Dunlap  and
  Dario Faggioli .
* arch_vcpu_block()
  Called alled before vcpu is blocking and update the PID
  (posted-interrupt descriptor).

* vmx_pi_switch_from()
  Called before context switch, we update the PID when the
  vCPU is preempted or going to sleep.

* vmx_pi_switch_to()
  Called after context switch, we update the PID when the vCPU
  is going to run.

- Before VM-entry, check the state of PI descriptor, make sure the
'NV' field is set to '_intr_vector' when the guest is running
in non-root mode. Suggested by Jan Beulich .

When we handle the lazy context switch for the following two scenarios:
- Preempted by a tasklet, which uses in an idle context.
- the prev vcpu is in offline and no new available vcpus in run queue.
We don't change the 'SN' bit in posted-interrupt descriptor, this
may incur spurious PI notification events, but since PI notification
event is only sent when 'ON' is clear, and once the PI notificatoin
is sent, ON is set by hardware, hence no more notification events
before 'ON' is clear. Besides that, spurious PI notification events are
going to happen from time to time in Xen hypervisor, such as, when
guests trap to Xen and PI notification event happens, there is
nothing Xen actually needs to do about it, the interrupts will be
delivered to guest atht the next time we do a VMENTRY.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Kevin Tian 
CC: George Dunlap 
CC: Dario Faggioli 
Suggested-by: Yang Zhang 
Suggested-by: Dario Faggioli 
Suggested-by: George Dunlap 
Suggested-by: Jan Beulich 
Signed-off-by: Feng Wu 
---
v9:
- Remove arch_vcpu_block_cancel() and arch_vcpu_wake_prepare()
- Add vmx_pi_state_change() and call it before VM Entry

v8:
- Remove the lazy context switch handling for PI state transition
- Change PI state in vcpu_block() and do_poll() when the vCPU
  is going to be blocked

v7:
- Merge [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted 
interrupts
  and "[PATCH v6 14/18] vmx: posted-interrupt handling when vCPU is blocked"
  into this patch, so it is self-contained and more convenient
  for code review.
- Make 'pi_blocked_vcpu' and 'pi_blocked_vcpu_lock' static
- Coding style
- Use per_cpu() instead of this_cpu() in pi_wakeup_interrupt()
- Move ack_APIC_irq() to the beginning of pi_wakeup_interrupt()
- Rename 'pi_ctxt_switch_from' to 'ctxt_switch_prepare'
- Rename 'pi_ctxt_switch_to' to 'ctxt_switch_cancel'
- Use 'has_hvm_container_vcpu' instead of 'is_hvm_vcpu'
- Use 'spin_lock' and 'spin_unlock' when the interrupt has been
  already disabled.
- Rename arch_vcpu_wake_prepare to vmx_vcpu_wake_prepare
- Define vmx_vcpu_wake_prepare in xen/arch/x86/hvm/hvm.c
- Call .pi_ctxt_switch_to() __context_switch() instead of directly
  calling vmx_post_ctx_switch_pi() in vmx_ctxt_switch_to()
- Make .pi_block_cpu unsigned int
- Use list_del() instead of list_del_init()
- Coding style

One remaining item in v7:
Jan has concern about calling vcpu_unblock() in vmx_pre_ctx_switch_pi(),
need Dario or George's input about this.

v6:
- Add two static inline functions for pi context switch
- Fix typos

v5:
- Rename arch_vcpu_wake to arch_vcpu_wake_prepare
- Make arch_vcpu_wake_prepare() inline for ARM
- Merge the ARM dummy hook with together
- Changes to some code comments
- Leave 'pi_ctxt_switch_from' and 'pi_ctxt_switch_to' NULL if
  PI is disabled or the vCPU is not in HVM
- Coding style

v4:
- Newly added

Changlog for "vmx: posted-interrupt handling when vCPU is blocked"
v6:
- Fix some typos
- Ack the interrupt right after the spin_unlock in pi_wakeup_interrupt()

v4:
- Use local variables in pi_wakeup_interrupt()
- Remove vcpu from the blocked list when pi_desc.on==1, this
- avoid kick vcpu multiple times.
- Remove tasklet

v3:
- This patch is generated by merging the following three patches in v2:
   [RFC v2 09/15] Add a new per-vCPU tasklet to wakeup the blocked vCPU
   [RFC v2 10/15] vmx: Define two per-cpu variables
   [RFC v2 11/15] vmx: Add a global wake-up vector for VT-d Posted-Interrupts
- rename 'vcpu_wakeup_tasklet' to 

[Xen-devel] [PATCH v9 17/17] Add a command line parameter for VT-d posted-interrupts

[Feng Wu]

Enable VT-d Posted-Interrupts and add a command line
parameter for it.

CC: Jan Beulich 
Signed-off-by: Feng Wu 
Reviewed-by: Kevin Tian 
Acked-by: Jan Beulich 
---
v6:
- Change the default value to 'false' in xen-command-line.markdown

 docs/misc/xen-command-line.markdown | 9 -
 xen/drivers/passthrough/iommu.c | 3 +++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index a2e427c..ecaf221 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -855,7 +855,7 @@ debug hypervisor only).
 > Default: `new` unless directed-EOI is supported
 
 ### iommu
-> `= List of [  | force | required | intremap | qinval | snoop | 
sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | 
workaround_bios_bug | igfx | verbose | debug ]`
+> `= List of [  | force | required | intremap | intpost | qinval | 
snoop | sharept | dom0-passthrough | dom0-strict | amd-iommu-perdev-intremap | 
workaround_bios_bug | igfx | verbose | debug ]`
 
 > Sub-options:
 
@@ -882,6 +882,13 @@ debug hypervisor only).
 >> Control the use of interrupt remapping (DMA remapping will always be enabled
 >> if IOMMU functionality is enabled).
 
+> `intpost`
+
+> Default: `false`
+
+>> Control the use of interrupt posting, which depends on the availability of
+>> interrupt remapping.
+
 > `qinval` (VT-d)
 
 > Default: `true`
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 36d5cc0..8d03076 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -38,6 +38,7 @@ static void iommu_dump_p2m_table(unsigned char key);
  *   no-snoop   Disable VT-d Snoop Control
  *   no-qinval  Disable VT-d Queued Invalidation
  *   no-intremapDisable VT-d Interrupt Remapping
+ *   no-intpost Disable VT-d Interrupt posting
  */
 custom_param("iommu", parse_iommu_param);
 bool_t __initdata iommu_enable = 1;
@@ -105,6 +106,8 @@ static void __init parse_iommu_param(char *s)
 iommu_qinval = val;
 else if ( !strcmp(s, "intremap") )
 iommu_intremap = val;
+else if ( !strcmp(s, "intpost") )
+iommu_intpost = val;
 else if ( !strcmp(s, "debug") )
 {
 iommu_debug = val;
-- 
2.1.0


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

[Xen-devel] [linux-3.14 test] 63470: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 63368
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 63395

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail in 63395 blocked in 62648
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62648
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62648
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62648

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux07bd6f89f7ff56495c31505985af690c976374d6
baseline version:
 linux1230ae0e99e05ced8a945a1a2c5762ce5c6c97c9

Last test of basis62648  2015-10-03 22:43:24 Z   30 days
Failing since 63225  2015-10-22 22:20:24 Z   11 days9 attempts
Testing same since63336  2015-10-27 17:53:49 Z6 days5 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adam Radford 
  Adrian Hunter 
  Al Viro 
  Alex Deucher 
  Alexander Couzens 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andrey Vagin 
  Andy Lutomirski 
  Andy Shevchenko 
  Antoine Tenart 
  Antoine Ténart 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Dooks 
  Ben Hutchings 
  Ben Skeggs 
  Brian Norris 
  Charles Keepax 
  Chris Mason 
  Christoph Biedl 
  Christoph Hellwig 
  Christoph Lameter 
  cov...@ccs.covici.com 
  Daniel Vetter 
  Daniel Vetter 
  Dann Frazier 
  Dave Airlie 
  Dave Kleikamp 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Dirk Mueller 
  Dirk Müller 
  Eric Dumazet 
  Eric W. Biederman 
  Eryu Guan 

[Xen-devel] [PATCH v9 09/17] VT-d: Remove pointless casts

[Feng Wu]

Remove pointless casts.

CC: Yang Zhang 
CC: Kevin Tian 
Suggested-by: Jan Beulich 
Signed-off-by: Feng Wu 
Reviewed-by: Konrad Rzeszutek Wilk 
---
v7:
- Remove an 'u32' casting omitted in v5

v5:
- Newly added.

 xen/drivers/passthrough/vtd/utils.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/utils.c 
b/xen/drivers/passthrough/vtd/utils.c
index 44c4ef5..a75059f 100644
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -234,10 +234,9 @@ static void dump_iommu_info(unsigned char key)
 continue;
 printk("  %04x:  %x   %x  %04x %08x %02x%x   %x  %x  %x  
%x"
 "   %x %x\n", i,
-(u32)p->hi.svt, (u32)p->hi.sq, (u32)p->hi.sid,
-(u32)p->lo.dst, (u32)p->lo.vector, (u32)p->lo.avail,
-(u32)p->lo.dlm, (u32)p->lo.tm, (u32)p->lo.rh,
-(u32)p->lo.dm, (u32)p->lo.fpd, (u32)p->lo.p);
+p->hi.svt, p->hi.sq, p->hi.sid, p->lo.dst, p->lo.vector,
+p->lo.avail, p->lo.dlm, p->lo.tm, p->lo.rh, p->lo.dm,
+p->lo.fpd, p->lo.p);
 print_cnt++;
 }
 if ( iremap_entries )
@@ -281,11 +280,10 @@ static void dump_iommu_info(unsigned char key)
 
 printk("   %02x:  %04x   %x%x   %x   %x   %x%x"
 "%x %02x\n", i,
-(u32)remap->index_0_14 | ((u32)remap->index_15 << 15),
-(u32)remap->format, (u32)remap->mask, (u32)remap->trigger,
-(u32)remap->irr, (u32)remap->polarity,
-(u32)remap->delivery_status, (u32)remap->delivery_mode,
-(u32)remap->vector);
+remap->index_0_14 | (remap->index_15 << 15),
+remap->format, remap->mask, remap->trigger, remap->irr,
+remap->polarity, remap->delivery_status, 
remap->delivery_mode,
+remap->vector);
 }
 }
 }
-- 
2.1.0


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

[Xen-devel] [PATCH v9 03/17] iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

This patch adds variable 'iommu_intpost' to control whether enable VT-d
posted-interrupt or not in the generic IOMMU code.

CC: Jan Beulich 
CC: Kevin Tian 
Signed-off-by: Feng Wu 
Reviewed-by: Kevin Tian 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Jan Beulich 
---
v5:
- Remove the "if no intremap then no intpost" logic in parse_iommu_param(), 
which
  can be covered in iommu_setup()

v3:
- Remove pointless initializer for 'iommu_intpost'.
- Some adjustment for "if no intremap then no intpost" logic.
* For parse_iommu_param(), move it to the end of the function,
  so we don't need to add the some logic when introduing the
  new kernel parameter 'intpost' in later patch.
* Add this logic in iommu_setup() after iommu_hardware_setup()
  is called.

 xen/drivers/passthrough/iommu.c | 13 -
 xen/include/xen/iommu.h |  2 +-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index fc7831e..36d5cc0 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -51,6 +51,14 @@ bool_t __read_mostly iommu_passthrough;
 bool_t __read_mostly iommu_snoop = 1;
 bool_t __read_mostly iommu_qinval = 1;
 bool_t __read_mostly iommu_intremap = 1;
+
+/*
+ * In the current implementation of VT-d posted interrupts, in some extreme
+ * cases, the per cpu list which saves the blocked vCPU will be very long,
+ * and this will affect the interrupt latency, so let this feature off by
+ * default until we find a good solution to resolve it.
+ */
+bool_t __read_mostly iommu_intpost;
 bool_t __read_mostly iommu_hap_pt_share = 1;
 bool_t __read_mostly iommu_debug;
 bool_t __read_mostly amd_iommu_perdev_intremap = 1;
@@ -307,6 +315,9 @@ int __init iommu_setup(void)
 panic("Couldn't enable %s and iommu=required/force",
   !iommu_enabled ? "IOMMU" : "Interrupt Remapping");
 
+if ( !iommu_intremap )
+iommu_intpost = 0;
+
 if ( !iommu_enabled )
 {
 iommu_snoop = 0;
@@ -374,7 +385,7 @@ void iommu_crash_shutdown(void)
 const struct iommu_ops *ops = iommu_get_ops();
 if ( iommu_enabled )
 ops->crash_shutdown();
-iommu_enabled = iommu_intremap = 0;
+iommu_enabled = iommu_intremap = iommu_intpost = 0;
 }
 
 int iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8f3a20e..1f5d04a 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -30,7 +30,7 @@
 extern bool_t iommu_enable, iommu_enabled;
 extern bool_t force_iommu, iommu_verbose;
 extern bool_t iommu_workaround_bios_bug, iommu_igfx, iommu_passthrough;
-extern bool_t iommu_snoop, iommu_qinval, iommu_intremap;
+extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
 extern bool_t iommu_hap_pt_share;
 extern bool_t iommu_debug;
 extern bool_t amd_iommu_perdev_intremap;
-- 
2.1.0


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

[Xen-devel] [PATCH v9 04/17] vt-d: VT-d Posted-Interrupts feature detection

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

CC: Yang Zhang 
CC: Kevin Tian 
Signed-off-by: Feng Wu 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
---
v7:
- Remove pointless "if non iommu_intremap then disable iommu_intpost" logic
- Don't need to check !iommu_intremap or !iommu_intpost when setting 
iommu_intpost to 0

v5:
- Remove blank line

v4:
- Correct a logic error when setting iommu_intpost to 0

v3:
- Remove the "if no intremap then no intpost" logic in
  intel_vtd_setup(), it is covered in the iommu_setup().
- Add "if no intremap then no intpost" logic in the end
  of init_vtd_hw() which is called by vtd_resume().

So the logic exists in the following three places:
- parse_iommu_param()
- iommu_setup()
- init_vtd_hw()

 xen/drivers/passthrough/vtd/iommu.c | 14 --
 xen/drivers/passthrough/vtd/iommu.h |  1 +
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 1dffc40..8dee731 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2147,8 +2147,8 @@ int __init intel_vtd_setup(void)
 }
 
 /* We enable the following features only if they are supported by all VT-d
- * engines: Snoop Control, DMA passthrough, Queued Invalidation and
- * Interrupt Remapping.
+ * engines: Snoop Control, DMA passthrough, Queued Invalidation, Interrupt
+ * Remapping, and Posted Interrupt
  */
 for_each_drhd_unit ( drhd )
 {
@@ -2176,6 +2176,14 @@ int __init intel_vtd_setup(void)
 if ( iommu_intremap && !ecap_intr_remap(iommu->ecap) )
 iommu_intremap = 0;
 
+/*
+ * We cannot use posted interrupt if X86_FEATURE_CX16 is
+ * not supported, since we count on this feature to
+ * atomically update 16-byte IRTE in posted format.
+ */
+if ( !cap_intr_post(iommu->cap) || !cpu_has_cx16 )
+iommu_intpost = 0;
+
 if ( !vtd_ept_page_compatible(iommu) )
 iommu_hap_pt_share = 0;
 
@@ -2201,6 +2209,7 @@ int __init intel_vtd_setup(void)
 P(iommu_passthrough, "Dom0 DMA Passthrough");
 P(iommu_qinval, "Queued Invalidation");
 P(iommu_intremap, "Interrupt Remapping");
+P(iommu_intpost, "Posted Interrupt");
 P(iommu_hap_pt_share, "Shared EPT tables");
 #undef P
 
@@ -2220,6 +2229,7 @@ int __init intel_vtd_setup(void)
 iommu_passthrough = 0;
 iommu_qinval = 0;
 iommu_intremap = 0;
+iommu_intpost = 0;
 return ret;
 }
 
diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index ac71ed1..22abefe 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -61,6 +61,7 @@
 /*
  * Decoding Capability Register
  */
+#define cap_intr_post(c)   (((c) >> 59) & 1)
 #define cap_read_drain(c)  (((c) >> 55) & 1)
 #define cap_write_drain(c) (((c) >> 54) & 1)
 #define cap_max_amask_val(c)   (((c) >> 48) & 0x3f)
-- 
2.1.0


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

[Xen-devel] [ovmf test] 63472: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 8aa6ebe83f91fcd5e1a67d316e444f4ac8b1319d
baseline version:
 ovmf df60fb4cc2ca896fcea9e37b06c276d569f1a6b8

Last test of basis63396  2015-10-31 09:49:58 Z2 days
Testing same since63472  2015-11-02 02:10:32 Z1 days1 attempts


People who touched revisions under test:
  Star Zeng 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=8aa6ebe83f91fcd5e1a67d316e444f4ac8b1319d
+ . ./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 ovmf 
8aa6ebe83f91fcd5e1a67d316e444f4ac8b1319d
+ branch=ovmf
+ revision=8aa6ebe83f91fcd5e1a67d316e444f4ac8b1319d
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x8aa6ebe83f91fcd5e1a67d316e444f4ac8b1319d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 

[Xen-devel] [RFC PATCH] x86/paravirt: Kill some unused patching functions

[Borislav Petkov]

From: Borislav Petkov 

paravirt_patch_ignore() is completely unused and paravirt_patch_nop()
doesn't do a whole lot. Remove them both.

Signed-off-by: Borislav Petkov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Chris Wright 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jeremy Fitzhardinge 
Cc: Juergen Gross 
Cc: "Peter Zijlstra (Intel)" 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/include/asm/paravirt_types.h |  2 --
 arch/x86/kernel/paravirt.c| 13 +
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 31247b5bff7c..e1f31dfc3b31 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -402,10 +402,8 @@ extern struct pv_lock_ops pv_lock_ops;
__visible extern const char start_##ops##_##name[], 
end_##ops##_##name[];   \
asm(NATIVE_LABEL("start_", ops, name) code NATIVE_LABEL("end_", ops, 
name))
 
-unsigned paravirt_patch_nop(void);
 unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len);
 unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len);
-unsigned paravirt_patch_ignore(unsigned len);
 unsigned paravirt_patch_call(void *insnbuf,
 const void *target, u16 tgt_clobbers,
 unsigned long addr, u16 site_clobbers,
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index c2130aef3f9d..4f32a10979db 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -74,16 +74,6 @@ void __init default_banner(void)
 /* Undefined instruction for dealing with missing ops pointers. */
 static const unsigned char ud2a[] = { 0x0f, 0x0b };
 
-unsigned paravirt_patch_nop(void)
-{
-   return 0;
-}
-
-unsigned paravirt_patch_ignore(unsigned len)
-{
-   return len;
-}
-
 struct branch {
unsigned char opcode;
u32 delta;
@@ -152,8 +142,7 @@ unsigned paravirt_patch_default(u8 type, u16 clobbers, void 
*insnbuf,
/* If there's no function, patch it with a ud2a (BUG) */
ret = paravirt_patch_insns(insnbuf, len, ud2a, 
ud2a+sizeof(ud2a));
else if (opfunc == _paravirt_nop)
-   /* If the operation is a nop, then nop the callsite */
-   ret = paravirt_patch_nop();
+   ret = 0;
 
/* identity functions just return their single argument */
else if (opfunc == _paravirt_ident_32)
-- 
2.3.5


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

[Xen-devel] [PATCH v9 12/17] x86: move some APIC related macros to apicdef.h

[Feng Wu]

Move some APIC related macros to apicdef.h, so they can be used
outside of vlapic.c.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Feng Wu 
Acked-by: Jan Beulich 
---
v8:
- Minor changes

v7:
- Put the Macros to the right place inside the file.

v6:
- Newly introduced.

 xen/arch/x86/hvm/vlapic.c | 5 -
 xen/include/asm-x86/apicdef.h | 3 +++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index b893b40..9b7c871 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -65,11 +65,6 @@ static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM] =
  LVT_MASK
 };
 
-/* Following could belong in apicdef.h */
-#define APIC_SHORT_MASK  0xc
-#define APIC_DEST_NOSHORT0x0
-#define APIC_DEST_MASK   0x800
-
 #define vlapic_lvt_vector(vlapic, lvt_type) \
 (vlapic_get_reg(vlapic, lvt_type) & APIC_VECTOR_MASK)
 
diff --git a/xen/include/asm-x86/apicdef.h b/xen/include/asm-x86/apicdef.h
index 6069fce..8752287 100644
--- a/xen/include/asm-x86/apicdef.h
+++ b/xen/include/asm-x86/apicdef.h
@@ -54,9 +54,11 @@
 #defineAPIC_ESR_RECVILL0x00040
 #defineAPIC_ESR_ILLREGA0x00080
 #defineAPIC_ICR0x300
+#defineAPIC_DEST_NOSHORT   0x0
 #defineAPIC_DEST_SELF  0x4
 #defineAPIC_DEST_ALLINC0x8
 #defineAPIC_DEST_ALLBUT0xC
+#defineAPIC_SHORT_MASK 0xC
 #defineAPIC_ICR_RR_MASK0x3
 #defineAPIC_ICR_RR_INVALID 0x0
 #defineAPIC_ICR_RR_INPROG  0x1
@@ -64,6 +66,7 @@
 #defineAPIC_INT_LEVELTRIG  0x08000
 #defineAPIC_INT_ASSERT 0x04000
 #defineAPIC_ICR_BUSY   0x01000
+#defineAPIC_DEST_MASK  0x00800
 #defineAPIC_DEST_LOGICAL   0x00800
 #defineAPIC_DEST_PHYSICAL  0x0
 #defineAPIC_DM_FIXED   0x0
-- 
2.1.0


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

[Xen-devel] [PATCH v9 13/17] Update IRTE according to guest interrupt config changes

[Feng Wu]

When guest changes its interrupt configuration (such as, vector, etc.)
for direct-assigned devices, we need to update the associated IRTE
with the new guest vector, so external interrupts from the assigned
devices can be injected to guests without VM-Exit.

For lowest-priority interrupts, we use vector-hashing mechamisn to find
the destination vCPU. This follows the hardware behavior, since modern
Intel CPUs use vector hashing to handle the lowest-priority interrupt.

For multicast/broadcast vCPU, we cannot handle it via interrupt posting,
still use interrupt remapping.

CC: Jan Beulich 
Signed-off-by: Feng Wu 
Acked-by: Jan Beulich 
---
v8:
- Remove local variable 'bitmap_array_size'
- Use switch to replace if-else

v7:
- Remove some pointless debug printk
- Fix a logic error when assigning 'delivery_mode'
- Adjust the definition of local variable 'idx'
- Add a dprintk if we cannot find the vCPU from 'pi_find_dest_vcpu'
- Add 'else if ( delivery_mode == dest_Fixed )' in 'pi_find_dest_vcpu'

v6:
- Use macro to replace plain numbers
- Correct the overflow error in a loop

v5:
- Make 'struct vcpu *vcpu' const

v4:
- Make some 'int' variables 'unsigned int' in pi_find_dest_vcpu()
- Make 'dest_id' uint32_t
- Rename 'size' to 'bitmap_array_size'
- find_next_bit() and find_first_bit() always return unsigned int,
  so no need to check whether the return value is less than 0.
- Message error level XENLOG_G_WARNING -> XENLOG_G_INFO
- Remove useless warning message
- Create a seperate function vector_hashing_dest() to find the
- destination of lowest-priority interrupts.
- Change some comments

v3:
- Use bitmap to store the all the possible destination vCPUs of an
  interrupt, then trying to find the right destination from the bitmap
- Typo and some small changes

 xen/drivers/passthrough/io.c | 123 ++-
 1 file changed, 122 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index bda9374..6b1ee6a 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static DEFINE_PER_CPU(struct list_head, dpci_list);
 
@@ -198,6 +199,108 @@ void free_hvm_irq_dpci(struct hvm_irq_dpci *dpci)
 xfree(dpci);
 }
 
+/*
+ * This routine handles lowest-priority interrupts using vector-hashing
+ * mechanism. As an example, modern Intel CPUs use this method to handle
+ * lowest-priority interrupts.
+ *
+ * Here is the details about the vector-hashing mechanism:
+ * 1. For lowest-priority interrupts, store all the possible destination
+ *vCPUs in an array.
+ * 2. Use "gvec % max number of destination vCPUs" to find the right
+ *destination vCPU in the array for the lowest-priority interrupt.
+ */
+static struct vcpu *vector_hashing_dest(const struct domain *d,
+uint32_t dest_id,
+bool_t dest_mode,
+uint8_t gvec)
+
+{
+unsigned long *dest_vcpu_bitmap;
+unsigned int dest_vcpus = 0;
+struct vcpu *v, *dest = NULL;
+unsigned int i;
+
+dest_vcpu_bitmap = xzalloc_array(unsigned long,
+ BITS_TO_LONGS(d->max_vcpus));
+if ( !dest_vcpu_bitmap )
+return NULL;
+
+for_each_vcpu ( d, v )
+{
+if ( !vlapic_match_dest(vcpu_vlapic(v), NULL, APIC_DEST_NOSHORT,
+dest_id, dest_mode) )
+continue;
+
+__set_bit(v->vcpu_id, dest_vcpu_bitmap);
+dest_vcpus++;
+}
+
+if ( dest_vcpus != 0 )
+{
+unsigned int mod = gvec % dest_vcpus;
+unsigned int idx = 0;
+
+for ( i = 0; i <= mod; i++ )
+{
+idx = find_next_bit(dest_vcpu_bitmap, d->max_vcpus, idx) + 1;
+BUG_ON(idx >= d->max_vcpus);
+}
+
+dest = d->vcpu[idx - 1];
+}
+
+xfree(dest_vcpu_bitmap);
+
+return dest;
+}
+
+/*
+ * The purpose of this routine is to find the right destination vCPU for
+ * an interrupt which will be delivered by VT-d posted-interrupt. There
+ * are several cases as below:
+ *
+ * - For lowest-priority interrupts, use vector-hashing mechanism to find
+ *   the destination.
+ * - Otherwise, for single destination interrupt, it is straightforward to
+ *   find the destination vCPU and return true.
+ * - For multicast/broadcast vCPU, we cannot handle it via interrupt posting,
+ *   so return NULL.
+ */
+static struct vcpu *pi_find_dest_vcpu(const struct domain *d, uint32_t dest_id,
+  bool_t dest_mode, uint8_t delivery_mode,
+  uint8_t gvec)
+{
+unsigned int dest_vcpus = 0;
+struct vcpu *v, *dest = NULL;
+
+switch ( delivery_mode )
+{
+case dest_LowestPrio:
+return vector_hashing_dest(d, dest_id, dest_mode, gvec);

[Xen-devel] [PATCH v9 00/17] Add VT-d Posted-Interrupts support

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

You can find the VT-d Posted-Interrtups Spec. in the following URL:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html

v9:
- [PATCH v9 01/17] VT-d Posted-intterrupt (PI) design
* Make the description more generic.

- [PATCH v9 02/17] Add cmpxchg16b support for x86-64
* Make the *ptr operand an input and output.

- [PATCH v9 15/17] vmx: VT-d posted-interrupt core logic handling
* Remove arch_vcpu_block_cancel() and arch_vcpu_wake_prepare().
* Add vmx_pi_state_change() and call it before VM Entry.

Feng Wu (17):
 r   VT-d Posted-intterrupt (PI) design
 Add cmpxchg16b support for x86-64
 ra  iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature
 r   vt-d: VT-d Posted-Interrupts feature detection
 ra  vmx: Extend struct pi_desc to support VT-d Posted-Interrupts
 r   vmx: Add some helper functions for Posted-Interrupts
 ra  vmx: Initialize VT-d Posted-Interrupts Descriptor
 r   vmx: Suppress posting interrupts when 'SN' is set
 r   VT-d: Remove pointless casts
  a  vt-d: Extend struct iremap_entry to support VT-d Posted-Interrupts
 r   vt-d: Add API to update IRTE when VT-d PI is used
  a  x86: move some APIC related macros to apicdef.h
  a  Update IRTE according to guest interrupt config changes
  a  vmx: Properly handle notification event when vCPU is running
 vmx: VT-d posted-interrupt core logic handling
 VT-d: Dump the posted format IRTE
 ra  Add a command line parameter for VT-d posted-interrupts
 
 r = has been 'Reviewed-by'
 a = has been 'Acked-by'

 docs/misc/vtd-pi.txt   | 329 +
 docs/misc/xen-command-line.markdown|   9 +-
 xen/arch/x86/hvm/hvm.c |   6 +
 xen/arch/x86/hvm/vlapic.c  |   5 -
 xen/arch/x86/hvm/vmx/vmcs.c|  24 +++
 xen/arch/x86/hvm/vmx/vmx.c | 270 ++-
 xen/common/schedule.c  |   7 +-
 xen/drivers/passthrough/io.c   | 123 +++-
 xen/drivers/passthrough/iommu.c|  16 +-
 xen/drivers/passthrough/vtd/intremap.c | 212 -
 xen/drivers/passthrough/vtd/iommu.c|  14 +-
 xen/drivers/passthrough/vtd/iommu.h|  51 +++--
 xen/drivers/passthrough/vtd/utils.c|  40 ++--
 xen/include/asm-arm/domain.h   |   2 +
 xen/include/asm-x86/apicdef.h  |   3 +
 xen/include/asm-x86/domain.h   |   2 +
 xen/include/asm-x86/hvm/hvm.h  |   2 +
 xen/include/asm-x86/hvm/vmx/vmcs.h |  24 ++-
 xen/include/asm-x86/hvm/vmx/vmx.h  |  27 +++
 xen/include/asm-x86/iommu.h|   2 +
 xen/include/asm-x86/x86_64/system.h|  33 
 xen/include/xen/iommu.h|   2 +-
 22 files changed, 1113 insertions(+), 90 deletions(-)
 create mode 100644 docs/misc/vtd-pi.txt

-- 
2.1.0


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

[Xen-devel] [PATCH v9 02/17] Add cmpxchg16b support for x86-64

[Feng Wu]

This patch adds cmpxchg16b support for x86-64, so software
can perform 128-bit atomic write/read.

CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Feng Wu 
---
v9:
- Make the *ptr operand an input and output.

v8:
- Remove pointless cast when assigning 'new_low'
- properly parenthesize cmpxchg16b()

v7:
- Make the last two parameters of __cmpxchg16b() const
- Remove memory clobber
- Add run-time and build-build check in cmpxchg16b()
- Cast the last two parameter to void * when calling __cmpxchg16b()

v6:
- Fix a typo

v5:
- Change back the parameters of __cmpxchg16b() to __uint128_t *
- Remove pointless cast for 'ptr'
- Remove pointless parentheses
- Use A constraint for the output

v4:
- Use pointer as the parameter of __cmpxchg16b().
- Use gcc's __uint128_t built-in type
- Make the parameters of __cmpxchg16b() void *

v3:
- Newly added.

 xen/include/asm-x86/x86_64/system.h | 33 +
 1 file changed, 33 insertions(+)

diff --git a/xen/include/asm-x86/x86_64/system.h 
b/xen/include/asm-x86/x86_64/system.h
index 662813a..7026c05 100644
--- a/xen/include/asm-x86/x86_64/system.h
+++ b/xen/include/asm-x86/x86_64/system.h
@@ -6,6 +6,39 @@
(unsigned long)(n),sizeof(*(ptr
 
 /*
+ * Atomic 16 bytes compare and exchange.  Compare OLD with MEM, if
+ * identical, store NEW in MEM.  Return the initial value in MEM.
+ * Success is indicated by comparing RETURN with OLD.
+ *
+ * This function can only be called when cpu_has_cx16 is true.
+ */
+
+static always_inline __uint128_t __cmpxchg16b(
+volatile void *ptr, const __uint128_t *old, const __uint128_t *new)
+{
+__uint128_t prev;
+uint64_t new_high = *new >> 64;
+uint64_t new_low = *new;
+
+ASSERT(cpu_has_cx16);
+
+asm volatile ( "lock; cmpxchg16b %1"
+   : "=A" (prev), "+m" (*__xg(ptr))
+   : "c" (new_high), "b" (new_low),
+ "0" (*old) );
+
+return prev;
+}
+
+#define cmpxchg16b(ptr, o, n) ({   \
+volatile void *_p = (ptr); \
+ASSERT(!((unsigned long)_p & 0xf));\
+BUILD_BUG_ON(sizeof(*(o)) != sizeof(__uint128_t)); \
+BUILD_BUG_ON(sizeof(*(n)) != sizeof(__uint128_t)); \
+__cmpxchg16b(_p, (void *)(o), (void *)(n));\
+})
+
+/*
  * This function causes value _o to be changed to _n at location _p.
  * If this access causes a fault then we return 1, otherwise we return 0.
  * If no fault occurs then _o is updated to the value we saw at _p. If this
-- 
2.1.0


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

[Xen-devel] [PATCH v9 01/17] VT-d Posted-intterrupt (PI) design

[Feng Wu]

Add the design doc for VT-d PI.

CC: Kevin Tian 
CC: Yang Zhang 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Andrew Cooper 
CC: George Dunlap 
Signed-off-by: Feng Wu 
Reviewed-by: Kevin Tian 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 docs/misc/vtd-pi.txt | 329 +++
 1 file changed, 329 insertions(+)
 create mode 100644 docs/misc/vtd-pi.txt

diff --git a/docs/misc/vtd-pi.txt b/docs/misc/vtd-pi.txt
new file mode 100644
index 000..f9b4637
--- /dev/null
+++ b/docs/misc/vtd-pi.txt
@@ -0,0 +1,329 @@
+Authors: Feng Wu 
+
+VT-d Posted-interrupt (PI) design for XEN
+
+Background
+==
+With the development of virtualization, there are more and more device
+assignment requirements. However, today when a VM is running with
+assigned devices (such as, NIC), external interrupt handling for the assigned
+devices always needs VMM intervention.
+
+VT-d Posted-interrupt is a more enhanced method to handle interrupts
+in the virtualization environment. Interrupt posting is the process by
+which an interrupt request is recorded in a memory-resident
+posted-interrupt-descriptor structure by the root-complex, followed by
+an optional notification event issued to the CPU complex.
+
+With VT-d Posted-interrupt we can get the following advantages:
+- Direct delivery of external interrupts to running vCPUs without VMM
+intervention
+- Decrease the interrupt migration complexity. On vCPU migration, software
+can atomically co-migrate all interrupts targeting the migrating vCPU. For
+virtual machines with assigned devices, migrating a vCPU across pCPUs
+either incurs the overhead of forwarding interrupts in software (e.g. via VMM
+generated IPIs), or complexity to independently migrate each interrupt 
targeting
+the vCPU to the new pCPU. However, after enabling VT-d PI, the destination vCPU
+of an external interrupt from assigned devices is stored in the IRTE (i.e.
+Posted-interrupt Descriptor Address), when vCPU is migrated to another pCPU,
+we will set this new pCPU in the 'NDST' filed of Posted-interrupt descriptor, 
this
+make the interrupt migration automatic.
+
+Here is what Xen currently does for external interrupts from assigned devices:
+
+When a VM is running and an external interrupt from an assigned device occurs
+for it. VM-EXIT happens, then:
+
+vmx_do_extint() --> do_IRQ() --> __do_IRQ_guest() --> hvm_do_IRQ_dpci() -->
+raise_softirq_for(pirq_dpci) --> raise_softirq(HVM_DPCI_SOFTIRQ)
+
+softirq HVM_DPCI_SOFTIRQ is bound to dpci_softirq()
+
+dpci_softirq() --> hvm_dirq_assist() --> vmsi_deliver_pirq() --> 
vmsi_deliver() -->
+vmsi_inj_irq() --> vlapic_set_irq()
+
+vlapic_set_irq() does the following things:
+1. If CPU-side posted-interrupt is supported, call vmx_deliver_posted_intr() 
to deliver
+the virtual interrupt via posted-interrupt infrastructure.
+2. Else if CPU-side posted-interrupt is not supported, set the related vIRR in 
vLAPIC
+page and call vcpu_kick() to kick the related vCPU. Before VM-Entry, 
vmx_intr_assist()
+will help to inject the interrupt to guests.
+
+However, after VT-d PI is supported, when a guest is running in non-root and an
+external interrupt from an assigned device occurs for it. No VM-Exit is needed,
+the guest can handle this totally in non-root mode, thus avoiding all the above
+code flow.
+
+Posted-interrupt Introduction
+
+There are two components to the Posted-interrupt architecture:
+Processor Support and Root-Complex Support
+
+- Processor Support
+Posted-interrupt processing is a feature by which a processor processes
+the virtual interrupts by recording them as pending on the virtual-APIC
+page.
+
+Posted-interrupt processing is enabled by setting the process posted
+interrupts VM-execution control. The processing is performed in response
+to the arrival of an interrupt with the posted-interrupt notification vector.
+In response to such an interrupt, the processor processes virtual interrupts
+recorded in a data structure called a posted-interrupt descriptor.
+
+More information about APICv and CPU-side Posted-interrupt, please refer
+to Chapter 29, and Section 29.6 in the Intel SDM:
+http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
+
+- Root-Complex Support
+Interrupt posting is the process by which an interrupt request (from IOAPIC
+or MSI/MSIx capable sources) is recorded in a memory-resident
+posted-interrupt-descriptor structure by the root-complex, followed by
+an optional notification event issued to the CPU complex. The interrupt
+request arriving at the root-complex carry the identity of the interrupt
+request source and a 'remapping-index'. The remapping-index is used to
+look-up an entry from the 

[Xen-devel] [PATCH v9 05/17] vmx: Extend struct pi_desc to support VT-d Posted-Interrupts

[Feng Wu]

Extend struct pi_desc according to VT-d Posted-Interrupts Spec.

CC: Kevin Tian 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Feng Wu 
Reviewed-by: Andrew Cooper 
Acked-by: Kevin Tian 
Reviewed-by: Konrad Rzeszutek Wilk 
---
v8:
- Coding style

v7:
- Coding style.

v3:
- Use u32 instead of u64 for the bitfield in 'struct pi_desc'

 xen/include/asm-x86/hvm/vmx/vmcs.h | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index f1126d4..81c9e63 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -80,8 +80,18 @@ struct vmx_domain {
 
 struct pi_desc {
 DECLARE_BITMAP(pir, NR_VECTORS);
-u32 control;
-u32 rsvd[7];
+union {
+struct {
+u16 on : 1,  /* bit 256 - Outstanding Notification */
+sn : 1,  /* bit 257 - Suppress Notification */
+rsvd_1 : 14; /* bit 271:258 - Reserved */
+u8  nv;  /* bit 279:272 - Notification Vector */
+u8  rsvd_2;  /* bit 287:280 - Reserved */
+u32 ndst;/* bit 319:288 - Notification Destination */
+};
+u64 control;
+};
+u32 rsvd[6];
 } __attribute__ ((aligned (64)));
 
 #define ept_get_wl(ept)   ((ept)->ept_wl)
-- 
2.1.0


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

[Xen-devel] [PATCH v9 10/17] vt-d: Extend struct iremap_entry to support VT-d Posted-Interrupts

[Feng Wu]

Extend struct iremap_entry according to VT-d Posted-Interrupts Spec.

CC: Yang Zhang 
CC: Kevin Tian 
Signed-off-by: Feng Wu 
Acked-by: Kevin Tian 
---
v8:
- Make use of the __uint128_t member in struct iremap_entry when needed

v7:
- Add a __uint128_t member to the union in struct iremap_entry

v4:
- res_4 is not a bitfiled, correct it.
- Expose 'im' to remapped irte as well.

v3:
- Use u32 instead of u64 to define the bitfields in 'struct iremap_entry'
- Limit using bitfield if possible

 xen/drivers/passthrough/vtd/intremap.c | 92 +-
 xen/drivers/passthrough/vtd/iommu.h| 44 ++--
 xen/drivers/passthrough/vtd/utils.c|  8 +--
 3 files changed, 81 insertions(+), 63 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/intremap.c 
b/xen/drivers/passthrough/vtd/intremap.c
index 987bbe9..8f135e1 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -122,9 +122,9 @@ static u16 hpetid_to_bdf(unsigned int hpet_id)
 static void set_ire_sid(struct iremap_entry *ire,
 unsigned int svt, unsigned int sq, unsigned int sid)
 {
-ire->hi.svt = svt;
-ire->hi.sq = sq;
-ire->hi.sid = sid;
+ire->remap.svt = svt;
+ire->remap.sq = sq;
+ire->remap.sid = sid;
 }
 
 static void set_ioapic_source_id(int apic_id, struct iremap_entry *ire)
@@ -219,7 +219,7 @@ static unsigned int alloc_remap_entry(struct iommu *iommu, 
unsigned int nr)
 else
 p = _entries[i % (1 << IREMAP_ENTRY_ORDER)];
 
-if ( p->lo_val || p->hi_val ) /* not a free entry */
+if ( p->val ) /* not a free entry */
 found = 0;
 else if ( ++found == nr )
 break;
@@ -253,7 +253,7 @@ static int remap_entry_to_ioapic_rte(
 GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
  iremap_entries, iremap_entry);
 
-if ( iremap_entry->hi_val == 0 && iremap_entry->lo_val == 0 )
+if ( iremap_entry->val == 0 )
 {
 dprintk(XENLOG_ERR VTDPREFIX,
 "%s: index (%d) get an empty entry!\n",
@@ -263,13 +263,13 @@ static int remap_entry_to_ioapic_rte(
 return -EFAULT;
 }
 
-old_rte->vector = iremap_entry->lo.vector;
-old_rte->delivery_mode = iremap_entry->lo.dlm;
-old_rte->dest_mode = iremap_entry->lo.dm;
-old_rte->trigger = iremap_entry->lo.tm;
+old_rte->vector = iremap_entry->remap.vector;
+old_rte->delivery_mode = iremap_entry->remap.dlm;
+old_rte->dest_mode = iremap_entry->remap.dm;
+old_rte->trigger = iremap_entry->remap.tm;
 old_rte->__reserved_2 = 0;
 old_rte->dest.logical.__reserved_1 = 0;
-old_rte->dest.logical.logical_dest = iremap_entry->lo.dst >> 8;
+old_rte->dest.logical.logical_dest = iremap_entry->remap.dst >> 8;
 
 unmap_vtd_domain_page(iremap_entries);
 spin_unlock_irqrestore(_ctrl->iremap_lock, flags);
@@ -317,27 +317,28 @@ static int ioapic_rte_to_remap_entry(struct iommu *iommu,
 if ( rte_upper )
 {
 if ( x2apic_enabled )
-new_ire.lo.dst = value;
+new_ire.remap.dst = value;
 else
-new_ire.lo.dst = (value >> 24) << 8;
+new_ire.remap.dst = (value >> 24) << 8;
 }
 else
 {
 *(((u32 *)_rte) + 0) = value;
-new_ire.lo.fpd = 0;
-new_ire.lo.dm = new_rte.dest_mode;
-new_ire.lo.tm = new_rte.trigger;
-new_ire.lo.dlm = new_rte.delivery_mode;
+new_ire.remap.fpd = 0;
+new_ire.remap.dm = new_rte.dest_mode;
+new_ire.remap.tm = new_rte.trigger;
+new_ire.remap.dlm = new_rte.delivery_mode;
 /* Hardware require RH = 1 for LPR delivery mode */
-new_ire.lo.rh = (new_ire.lo.dlm == dest_LowestPrio);
-new_ire.lo.avail = 0;
-new_ire.lo.res_1 = 0;
-new_ire.lo.vector = new_rte.vector;
-new_ire.lo.res_2 = 0;
+new_ire.remap.rh = (new_ire.remap.dlm == dest_LowestPrio);
+new_ire.remap.avail = 0;
+new_ire.remap.res_1 = 0;
+new_ire.remap.vector = new_rte.vector;
+new_ire.remap.res_2 = 0;
 
 set_ioapic_source_id(IO_APIC_ID(apic), _ire);
-new_ire.hi.res_1 = 0;
-new_ire.lo.p = 1; /* finally, set present bit */
+new_ire.remap.res_3 = 0;
+new_ire.remap.res_4 = 0;
+new_ire.remap.p = 1; /* finally, set present bit */
 
 /* now construct new ioapic rte entry */
 remap_rte->vector = new_rte.vector;
@@ -510,7 +511,7 @@ static int remap_entry_to_msi_msg(
 GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
  iremap_entries, iremap_entry);
 
-if ( iremap_entry->hi_val == 0 && iremap_entry->lo_val == 0 )
+if ( iremap_entry->val == 0 )
 {
 dprintk(XENLOG_ERR VTDPREFIX,
 "%s: index (%d) get an empty entry!\n",
@@ -523,25 +524,25 @@ static 

[Xen-devel] [PATCH v9 14/17] vmx: Properly handle notification event when vCPU is running

[Feng Wu]

When a vCPU is running in Root mode and a notification event
has been injected to it. we need to set VCPU_KICK_SOFTIRQ for
the current cpu, so the pending interrupt in PIRR will be
synced to vIRR before VM-Exit in time.

CC: Kevin Tian 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Feng Wu 
Acked-by: Kevin Tian 
---
v7:
- Retain 'cli' in the comments to make it more understandable.
- Register another notification event handler when VT-d PI is enabled

v6:
- Ack the interrupt in the beginning of pi_notification_interrupt()

v4:
- Coding style.

v3:
- Make pi_notification_interrupt() static

 xen/arch/x86/hvm/vmx/vmx.c | 54 +-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 741a271..e448b31 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1975,6 +1975,53 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .altp2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc,
 };
 
+/* Handle VT-d posted-interrupt when VCPU is running. */
+static void pi_notification_interrupt(struct cpu_user_regs *regs)
+{
+ack_APIC_irq();
+this_cpu(irq_count)++;
+
+/*
+ * We get here when a vCPU is running in root-mode (such as via hypercall,
+ * or any other reasons which can result in VM-Exit), and before vCPU is
+ * back to non-root, external interrupts from an assigned device happen
+ * and a notification event is delivered to this logical CPU.
+ *
+ * we need to set VCPU_KICK_SOFTIRQ for the current cpu, just like
+ * __vmx_deliver_posted_interrupt(). So the pending interrupt in PIRR will
+ * be synced to vIRR before VM-Exit in time.
+ *
+ * Please refer to the following code fragments from
+ * xen/arch/x86/hvm/vmx/entry.S:
+ *
+ * .Lvmx_do_vmentry
+ *
+ *  ..
+ *
+ *  point 1
+ *
+ *  cli
+ *  cmp  %ecx,(%rdx,%rax,1)
+ *  jnz  .Lvmx_process_softirqs
+ *
+ *  ..
+ *
+ *  je   .Lvmx_launch
+ *
+ *  ..
+ *
+ * .Lvmx_process_softirqs:
+ *  sti
+ *  call do_softirq
+ *  jmp  .Lvmx_do_vmentry
+ *
+ * If VT-d engine issues a notification event at point 1 above, it cannot
+ * be delivered to the guest during this VM-entry without raising the
+ * softirq in this notification handler.
+ */
+raise_softirq(VCPU_KICK_SOFTIRQ);
+}
+
 const struct hvm_function_table * __init start_vmx(void)
 {
 set_in_cr4(X86_CR4_VMXE);
@@ -2012,7 +2059,12 @@ const struct hvm_function_table * __init start_vmx(void)
 }
 
 if ( cpu_has_vmx_posted_intr_processing )
-alloc_direct_apic_vector(_intr_vector, event_check_interrupt);
+{
+if ( iommu_intpost )
+alloc_direct_apic_vector(_intr_vector, 
pi_notification_interrupt);
+else
+alloc_direct_apic_vector(_intr_vector, 
event_check_interrupt);
+}
 else
 {
 vmx_function_table.deliver_posted_intr = NULL;
-- 
2.1.0


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

[Xen-devel] [PATCH v9 07/17] vmx: Initialize VT-d Posted-Interrupts Descriptor

[Feng Wu]

This patch initializes the VT-d Posted-interrupt Descriptor.

CC: Kevin Tian 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Feng Wu 
Acked-by: Kevin Tian 
Reviewed-by: Konrad Rzeszutek Wilk 
---
v7:
- Add comments to function 'pi_desc_init' to clarify why we
  update the posted-interrupt descriptor in non-atomical way
  in it.

v3:
- Move pi_desc_init() to xen/arch/x86/hvm/vmx/vmcs.c
- Remove the 'inline' flag of pi_desc_init()

 xen/arch/x86/hvm/vmx/vmcs.c   | 22 ++
 xen/include/asm-x86/hvm/vmx/vmx.h |  2 ++
 2 files changed, 24 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index a0a97e7..5f67797 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool_t __read_mostly opt_vpid_enabled = 1;
 boolean_param("vpid", opt_vpid_enabled);
@@ -951,6 +952,24 @@ void virtual_vmcs_vmwrite(void *vvmcs, u32 vmcs_encoding, 
u64 val)
 virtual_vmcs_exit(vvmcs);
 }
 
+/*
+ * This function is only called in a vCPU's initialization phase,
+ * so we can update the posted-interrupt descriptor in non-atomic way.
+ */
+static void pi_desc_init(struct vcpu *v)
+{
+uint32_t dest;
+
+v->arch.hvm_vmx.pi_desc.nv = posted_intr_vector;
+
+dest = cpu_physical_id(v->processor);
+
+if ( x2apic_enabled )
+v->arch.hvm_vmx.pi_desc.ndst = dest;
+else
+v->arch.hvm_vmx.pi_desc.ndst = MASK_INSR(dest, PI_xAPIC_NDST_MASK);
+}
+
 static int construct_vmcs(struct vcpu *v)
 {
 struct domain *d = v->domain;
@@ -1089,6 +1108,9 @@ static int construct_vmcs(struct vcpu *v)
 
 if ( cpu_has_vmx_posted_intr_processing )
 {
+if ( iommu_intpost )
+pi_desc_init(v);
+
 __vmwrite(PI_DESC_ADDR, virt_to_maddr(>arch.hvm_vmx.pi_desc));
 __vmwrite(POSTED_INTR_NOTIFICATION_VECTOR, posted_intr_vector);
 }
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 8d91110..70b254f 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -88,6 +88,8 @@ typedef enum {
 #define EPT_EMT_WB  6
 #define EPT_EMT_RSV27
 
+#define PI_xAPIC_NDST_MASK  0xFF00
+
 void vmx_asm_vmexit_handler(struct cpu_user_regs);
 void vmx_asm_do_vmentry(void);
 void vmx_intr_assist(void);
-- 
2.1.0


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

[Xen-devel] [PATCH v9 08/17] vmx: Suppress posting interrupts when 'SN' is set

[Feng Wu]

Currently, we don't support urgent interrupt, all interrupts
are recognized as non-urgent interrupt, so we cannot send
posted-interrupt when 'SN' is set.

CC: Kevin Tian 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Feng Wu 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
---
v8:
- Parenthesize '1 << POSTED_INTR_ON' and '1 << POSTED_INTR_SN'

v7:
- Coding style
- Read the current pi_desc.control as the intial value of prev.control

v6:
- Add some comments

v5:
- keep the vcpu_kick() at the end of vmx_deliver_posted_intr()
- Keep the 'return' after calling __vmx_deliver_posted_interrupt()

v4:
- Coding style.
- V3 removes a vcpu_kick() from the eoi_exitmap_changed path
  incorrectly, fix it.

v3:
- use cmpxchg to test SN/ON and set ON

 xen/arch/x86/hvm/vmx/vmx.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index c32d863..741a271 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1701,8 +1701,35 @@ static void vmx_deliver_posted_intr(struct vcpu *v, u8 
vector)
  */
 pi_set_on(>arch.hvm_vmx.pi_desc);
 }
-else if ( !pi_test_and_set_on(>arch.hvm_vmx.pi_desc) )
+else
 {
+struct pi_desc old, new, prev;
+
+prev.control = v->arch.hvm_vmx.pi_desc.control;
+
+do {
+/*
+ * Currently, we don't support urgent interrupt, all
+ * interrupts are recognized as non-urgent interrupt,
+ * so we cannot send posted-interrupt when 'SN' is set.
+ * Besides that, if 'ON' is already set, we cannot set
+ * posted-interrupts as well.
+ */
+if ( pi_test_sn() || pi_test_on() )
+{
+vcpu_kick(v);
+return;
+}
+
+old.control = v->arch.hvm_vmx.pi_desc.control &
+  ~((1 << POSTED_INTR_ON) | (1 << POSTED_INTR_SN));
+new.control = v->arch.hvm_vmx.pi_desc.control |
+  (1 << POSTED_INTR_ON);
+
+prev.control = cmpxchg(>arch.hvm_vmx.pi_desc.control,
+   old.control, new.control);
+} while ( prev.control != old.control );
+
 __vmx_deliver_posted_interrupt(v);
 return;
 }
-- 
2.1.0


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

[Xen-devel] [PATCH v9 11/17] vt-d: Add API to update IRTE when VT-d PI is used

[Feng Wu]

This patch adds an API which is used to update the IRTE
for posted-interrupt when guest changes MSI/MSI-X information.

CC: Yang Zhang 
CC: Kevin Tian 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Feng Wu 
Reviewed-by: Jan Beulich 
---
v8:
- Some minor adjustment

v7:
- Remove __uint128_t cast
- Remove Kevin's Ack due to a bug fix for v6
- Reword some comments
- Setup posted IRTE from zeroed structure

v6:
- In some error cases, the desc->lock will be unlocked twice, fix it.
- Coding style fix.
- Add some comments.

v5:
- Make some function parameters const
- Call "spin_unlock_irq(>lock);" a little eariler
- Add "ASSERT(spin_is_locked(_lock))"
- -EBADSLT -> -ENODEV, EBADSLT is removed in the lasted Xen

v4:
- Don't inline setup_posted_irte()
- const struct pi_desc *pi_desc for setup_posted_irte()
- return -EINVAL when pirq_spin_lock_irq_desc() fails.
- Make some variables const
- Release irq desc lock earlier in pi_update_irte()
- Remove the pointless do-while() loop when doing cmpxchg16b()

v3:
- Remove "adding PDA_MASK()" when updating 'pda_l' and 'pda_h' for IRTE.
- Change the return type of pi_update_irte() to int.
- Remove some pointless printk message in pi_update_irte().
- Use structure assignment instead of memcpy() for irte copy.

 xen/drivers/passthrough/vtd/intremap.c | 120 +
 xen/drivers/passthrough/vtd/iommu.h|   6 ++
 xen/include/asm-x86/iommu.h|   2 +
 3 files changed, 128 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/intremap.c 
b/xen/drivers/passthrough/vtd/intremap.c
index 8f135e1..67e4f6d 100644
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -899,3 +899,123 @@ void iommu_disable_x2apic_IR(void)
 for_each_drhd_unit ( drhd )
 disable_qinval(drhd->iommu);
 }
+
+static void setup_posted_irte(
+struct iremap_entry *new_ire, const struct iremap_entry *old_ire,
+const struct pi_desc *pi_desc, const uint8_t gvec)
+{
+memset(new_ire, sizeof(*new_ire), 0);
+
+if ( !old_ire->remap.im )
+{
+new_ire->post.p = old_ire->remap.p;
+new_ire->post.fpd = old_ire->remap.fpd;
+new_ire->post.sid = old_ire->remap.sid;
+new_ire->post.sq = old_ire->remap.sq;
+new_ire->post.svt = old_ire->remap.svt;
+}
+else
+{
+new_ire->post.p = old_ire->post.p;
+new_ire->post.fpd = old_ire->post.fpd;
+new_ire->post.sid = old_ire->post.sid;
+new_ire->post.sq = old_ire->post.sq;
+new_ire->post.svt = old_ire->post.svt;
+new_ire->post.urg = old_ire->post.urg;
+}
+
+new_ire->post.im = 1;
+new_ire->post.vector = gvec;
+new_ire->post.pda_l = virt_to_maddr(pi_desc) >> (32 - PDA_LOW_BIT);
+new_ire->post.pda_h = virt_to_maddr(pi_desc) >> 32;
+}
+
+/*
+ * This function is used to update the IRTE for posted-interrupt
+ * when guest changes MSI/MSI-X information.
+ */
+int pi_update_irte(const struct vcpu *v, const struct pirq *pirq,
+const uint8_t gvec)
+{
+struct irq_desc *desc;
+const struct msi_desc *msi_desc;
+int remap_index;
+int rc = 0;
+const struct pci_dev *pci_dev;
+const struct acpi_drhd_unit *drhd;
+struct iommu *iommu;
+struct ir_ctrl *ir_ctrl;
+struct iremap_entry *iremap_entries = NULL, *p = NULL;
+struct iremap_entry new_ire, old_ire;
+const struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
+__uint128_t ret;
+
+desc = pirq_spin_lock_irq_desc(pirq, NULL);
+if ( !desc )
+return -EINVAL;
+
+msi_desc = desc->msi_desc;
+if ( !msi_desc )
+{
+rc = -ENODEV;
+goto unlock_out;
+}
+
+pci_dev = msi_desc->dev;
+if ( !pci_dev )
+{
+rc = -ENODEV;
+goto unlock_out;
+}
+
+remap_index = msi_desc->remap_index;
+
+spin_unlock_irq(>lock);
+
+ASSERT(spin_is_locked(_lock));
+
+/*
+ * FIXME: For performance reasons we should store the 'iommu' pointer in
+ * 'struct msi_desc' in some other place, so we don't need to waste
+ * time searching it here.
+ */
+drhd = acpi_find_matched_drhd_unit(pci_dev);
+if ( !drhd )
+return -ENODEV;
+
+iommu = drhd->iommu;
+ir_ctrl = iommu_ir_ctrl(iommu);
+if ( !ir_ctrl )
+return -ENODEV;
+
+spin_lock_irq(_ctrl->iremap_lock);
+
+GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, iremap_entries, p);
+
+old_ire = *p;
+
+/* Setup/Update interrupt remapping table entry. */
+setup_posted_irte(_ire, _ire, pi_desc, gvec);
+ret = cmpxchg16b(p, _ire, _ire);
+
+/*
+ * In the above, we use cmpxchg16 to atomically update the 128-bit IRTE,
+ * and the hardware cannot update the IRTE behind us, so the return value
+ * of cmpxchg16 should be the same as old_ire. This ASSERT 

[Xen-devel] [PATCH v9 16/17] VT-d: Dump the posted format IRTE

[Feng Wu]

Add the utility to dump the posted format IRTE.

CC: Yang Zhang 
CC: Kevin Tian 
Signed-off-by: Feng Wu 
---
v8:
- Coding style

v7:
- Remove the two stage loop

v6:
- Fix a typo

v4:
- Newly added

 xen/drivers/passthrough/vtd/utils.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/utils.c 
b/xen/drivers/passthrough/vtd/utils.c
index 6daa156..a1b3ebc 100644
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -203,6 +203,9 @@ static void dump_iommu_info(unsigned char key)
 ecap_intr_remap(iommu->ecap) ? "" : "not ",
 (status & DMA_GSTS_IRES) ? " and enabled" : "" );
 
+printk("  Interrupt Posting: %ssupported.\n",
+   cap_intr_post(iommu->cap) ? "" : "not ");
+
 if ( status & DMA_GSTS_IRES )
 {
 /* Dump interrupt remapping table. */
@@ -213,8 +216,9 @@ static void dump_iommu_info(unsigned char key)
 
 printk("  Interrupt remapping table (nr_entry=%#x. "
 "Only dump P=1 entries here):\n", nr_entry);
-printk("   SVT  SQ   SID  DST  V  AVL DLM TM RH DM "
-   "FPD P\n");
+printk("R means remapped format, P means posted format.\n");
+printk("R:   SVT  SQ   SID  V  AVL FPD  DST DLM TM RH DM 
P\n");
+printk("P:   SVT  SQ   SID  V  AVL FPD  PDA  URG 
P\n");
 for ( i = 0; i < nr_entry; i++ )
 {
 struct iremap_entry *p;
@@ -232,11 +236,21 @@ static void dump_iommu_info(unsigned char key)
 
 if ( !p->remap.p )
 continue;
-printk("  %04x:  %x   %x  %04x %08x %02x%x   %x  %x  %x  
%x"
-"   %x %x\n", i,
-p->remap.svt, p->remap.sq, p->remap.sid, p->remap.dst,
-p->remap.vector, p->remap.avail, p->remap.dlm, p->remap.tm,
-p->remap.rh, p->remap.dm, p->remap.fpd, p->remap.p);
+if ( !p->remap.im )
+printk("R:  %04x:  %x   %x  %04x %02x%x   %x %08x   %x 
 %x  %x  %x %x\n",
+   i,
+   p->remap.svt, p->remap.sq, p->remap.sid,
+   p->remap.vector, p->remap.avail, p->remap.fpd,
+   p->remap.dst, p->remap.dlm, p->remap.tm, 
p->remap.rh,
+   p->remap.dm, p->remap.p);
+else
+printk("P:  %04x:  %x   %x  %04x %02x%x   %x %16lx
%x %x\n",
+   i,
+   p->post.svt, p->post.sq, p->post.sid, 
p->post.vector,
+   p->post.avail, p->post.fpd,
+   ((u64)p->post.pda_h << 32) | (p->post.pda_l << 6),
+   p->post.urg, p->post.p);
+
 print_cnt++;
 }
 if ( iremap_entries )
-- 
2.1.0


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

[Xen-devel] [PATCH v9 06/17] vmx: Add some helper functions for Posted-Interrupts

[Feng Wu]

This patch adds some helper functions to manipulate the
Posted-Interrupts Descriptor.

CC: Kevin Tian 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Feng Wu 
Reviewed-by: Konrad Rzeszutek Wilk 
---
v7:
- Use bitfield in pi_test_on() and pi_test_sn()

v4:
- Newly added

 xen/include/asm-x86/hvm/vmx/vmx.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 3fbfa44..8d91110 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -101,6 +101,7 @@ void vmx_update_cpu_exec_control(struct vcpu *v);
 void vmx_update_secondary_exec_control(struct vcpu *v);
 
 #define POSTED_INTR_ON  0
+#define POSTED_INTR_SN  1
 static inline int pi_test_and_set_pir(int vector, struct pi_desc *pi_desc)
 {
 return test_and_set_bit(vector, pi_desc->pir);
@@ -121,11 +122,31 @@ static inline int pi_test_and_clear_on(struct pi_desc 
*pi_desc)
 return test_and_clear_bit(POSTED_INTR_ON, _desc->control);
 }
 
+static inline int pi_test_on(struct pi_desc *pi_desc)
+{
+return pi_desc->on;
+}
+
 static inline unsigned long pi_get_pir(struct pi_desc *pi_desc, int group)
 {
 return xchg(_desc->pir[group], 0);
 }
 
+static inline int pi_test_sn(struct pi_desc *pi_desc)
+{
+return pi_desc->sn;
+}
+
+static inline void pi_set_sn(struct pi_desc *pi_desc)
+{
+set_bit(POSTED_INTR_SN, _desc->control);
+}
+
+static inline void pi_clear_sn(struct pi_desc *pi_desc)
+{
+clear_bit(POSTED_INTR_SN, _desc->control);
+}
+
 /*
  * Exit Reasons
  */
-- 
2.1.0


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

Re: [Xen-devel] [PATCH v9 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

BTW, In the previous discussion, we will do the PI state adjustment in 
vmx_do_resume, however, seems this is not a good place to do this, since this 
function gets called only if the scheduling occurs, no matter it switches to 
another vCPU or continue runs the current vCPU. If no scheduling happens during 
"VM->Xen->VM", vmx-do_resume() will not get called. So I put the PI state 
adjustment code in vmx_vmenter_helper(), if you have any other good 
suggestions, please let me know, thanks a lot!

Thanks,
Feng

> -Original Message-
> From: Wu, Feng
> Sent: Tuesday, November 3, 2015 4:43 PM
> To: xen-devel@lists.xen.org
> Cc: Wu, Feng ; Keir Fraser ; Jan Beulich
> ; Andrew Cooper ; Tian,
> Kevin ; George Dunlap ;
> Dario Faggioli 
> Subject: [PATCH v9 15/17] vmx: VT-d posted-interrupt core logic handling
> 
> This patch includes the following aspects:
> - Handling logic when vCPU is blocked:
> * Add a global vector to wake up the blocked vCPU
>   when an interrupt is being posted to it (This part
>   was sugguested by Yang Zhang ).
> * Define two per-cpu variables:
>   1. pi_blocked_vcpu:
> A list storing the vCPUs which were blocked
> on this pCPU.
> 
>   2. pi_blocked_vcpu_lock:
> The spinlock to protect pi_blocked_vcpu.
> 
> - Add the following hooks, this part was suggested
>   by George Dunlap  and
>   Dario Faggioli .
> * arch_vcpu_block()
>   Called alled before vcpu is blocking and update the PID
>   (posted-interrupt descriptor).
> 
> * vmx_pi_switch_from()
>   Called before context switch, we update the PID when the
>   vCPU is preempted or going to sleep.
> 
> * vmx_pi_switch_to()
>   Called after context switch, we update the PID when the vCPU
>   is going to run.
> 
> - Before VM-entry, check the state of PI descriptor, make sure the
> 'NV' field is set to '_intr_vector' when the guest is running
> in non-root mode. Suggested by Jan Beulich .
> 
> When we handle the lazy context switch for the following two scenarios:
> - Preempted by a tasklet, which uses in an idle context.
> - the prev vcpu is in offline and no new available vcpus in run queue.
> We don't change the 'SN' bit in posted-interrupt descriptor, this
> may incur spurious PI notification events, but since PI notification
> event is only sent when 'ON' is clear, and once the PI notificatoin
> is sent, ON is set by hardware, hence no more notification events
> before 'ON' is clear. Besides that, spurious PI notification events are
> going to happen from time to time in Xen hypervisor, such as, when
> guests trap to Xen and PI notification event happens, there is
> nothing Xen actually needs to do about it, the interrupts will be
> delivered to guest atht the next time we do a VMENTRY.
> 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Kevin Tian 
> CC: George Dunlap 
> CC: Dario Faggioli 
> Suggested-by: Yang Zhang 
> Suggested-by: Dario Faggioli 
> Suggested-by: George Dunlap 
> Suggested-by: Jan Beulich 
> Signed-off-by: Feng Wu 
> ---
> v9:
> - Remove arch_vcpu_block_cancel() and arch_vcpu_wake_prepare()
> - Add vmx_pi_state_change() and call it before VM Entry
> 
> v8:
> - Remove the lazy context switch handling for PI state transition
> - Change PI state in vcpu_block() and do_poll() when the vCPU
>   is going to be blocked
> 
> v7:
> - Merge [PATCH v6 16/18] vmx: Add some scheduler hooks for VT-d posted
> interrupts
>   and "[PATCH v6 14/18] vmx: posted-interrupt handling when vCPU is blocked"
>   into this patch, so it is self-contained and more convenient
>   for code review.
> - Make 'pi_blocked_vcpu' and 'pi_blocked_vcpu_lock' static
> - Coding style
> - Use per_cpu() instead of this_cpu() in pi_wakeup_interrupt()
> - Move ack_APIC_irq() to the beginning of pi_wakeup_interrupt()
> - Rename 'pi_ctxt_switch_from' to 'ctxt_switch_prepare'
> - Rename 'pi_ctxt_switch_to' to 'ctxt_switch_cancel'
> - Use 'has_hvm_container_vcpu' instead of 'is_hvm_vcpu'
> - Use 'spin_lock' and 'spin_unlock' when the interrupt has been
>   already disabled.
> - Rename arch_vcpu_wake_prepare to vmx_vcpu_wake_prepare
> - Define vmx_vcpu_wake_prepare in xen/arch/x86/hvm/hvm.c
> - Call .pi_ctxt_switch_to() __context_switch() instead of directly
>   calling vmx_post_ctx_switch_pi() in vmx_ctxt_switch_to()
> - Make .pi_block_cpu unsigned int
> - Use list_del() instead of list_del_init()
> - Coding style
> 
> One remaining 

[Xen-devel] [linux-3.10 test] 63468: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-xsm 18 guest-start/debian.repeat fail in 63391 pass 
in 63468
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 63391
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 63391
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 63391

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail in 63391 blocked in 62642
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62642
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 62642

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxd17332ebfb5f2010ae5d3332a52df361f28ae4a8
baseline version:
 linuxf5552cd830e58c46dffae3617b3ce0c839771981

Last test of basis62642  2015-10-03 17:59:45 Z   30 days
Failing since 63224  2015-10-22 22:20:05 Z   11 days9 attempts
Testing same since63332  2015-10-27 12:23:40 Z6 days5 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adam Radford 
  Al Viro 
  Alexander Couzens 
  Alexey Klimov 
  Andi Kleen 
  Andreas Schwab 
  Andrew Morton 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Charles Keepax 
  Christoph Biedl 
  Christoph Hellwig 
  cov...@ccs.covici.com 
  Daniel Vetter 
  Daniel Vetter 
  Dave Kleikamp 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Ding Tianhong 
  dingtianhong 
  Dirk Mueller 
  Dirk Müller 
  Doug Ledford 
  Eric Dumazet 
  Eric W. Biederman 
  Geert Uytterhoeven 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Guillaume Nault 
  H. Peter Anvin 
  Herbert Xu 
  Ian Abbott 
  Ilya Dryomov 
  Ingo Molnar 
  James Bottomley 
  James Chapman 
  James Hogan 
  Jan Kara 
  Jann Horn 
  Jarkko Nikula 
  Jeff Mahoney 
  Jiri Slaby 
  Joe Perches 
  Joe Stringer 
  Joe Thornber 
  Johan Hovold 
  John Covici 
  Julian Anastasov 
  Kees Cook 
  Linus Torvalds 
  Liu.Zhao 
  Mark Brown 
  Mark Salyzyn 
  Mathias Nyman 
  Mel Gorman 
  Michael Ellerman 
  Michal Hocko 
  Michel Stam 
  Mike Marciniszyn 

Re: [Xen-devel] Revisit VT-d asynchronous flush issue

[Jan Beulich]

>>> On 03.11.15 at 10:58,  wrote:
> On 02/11/15 14:10, Jan Beulich wrote:
> On 02.11.15 at 09:03,  wrote:
>>> Based on above information, we propose to continue spin-timeout
>>> model w/ some adjustment, which fixes current timeout concern
>>> and also allows limited ATS support in a light way:
>>>
>>> 1) reduce spin timeout to 1ms, which can be boot-time changed
>>> up to 10ms.
> 
> Out of curiosity, is there a reason to limit the timeout to 10ms?
> 
> I'm generally a believer that we should do something sensible by
> default, but that an admin -- particularly someone who is going to be
> messing around with this sort of setting -- should be allowed to "shoot
> themselves in the foot" if they want to.
> 
> Suppose that there's some particularly grotty piece of hardware that
> really does require a 30ms, or 100ms timeout to work effectively?  If we
> have a hard limit of 10ms, there's nothing the person can do other than
> re-compile Xen.  If we have no hard limit, they can simply set it to
> 100ms as a work-around until we get asynchronous flushing working.

Andrew requested that too, and I understood that's what's planned
to be implemented.

Jan


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

Re: [Xen-devel] [PATCH] libxlu: avoid linker warnings

[Ian Campbell]

On Tue, 2015-11-03 at 03:02 -0700, Jan Beulich wrote:
> > > > On 02.11.15 at 15:01,  wrote:
> > On Thu, 2015-10-29 at 04:05 -0600, Jan Beulich wrote:
> > > Recent ld warns about libxenlight.so's dependency libraries not being
> > > available, which can be easily avoided by not just passing the raw
> > > library name on ld's command line.
> > 
> > > In the course of checking how things fit together (I originally
> > > suspected the warning to come from the linking of xl) I also noticed
> > > a
> > > stray L in SHLIB_libxenguest, which gets removed at once.
> > 
> > Looks like I (unwittingly) fixed this aspect in
> > 
> > http://lists.xen.org/archives/html/xen-devel/2015-10/msg02256.html 
> > too. I can easily rebase.
> > 
> > Since you have a pickier ld than me I wonder if you would mind trying
> > my 
> > patch out on top of yours too?
> 
> No warnings.

Thanks!

> 
> Jan
> 

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

Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw

[Ian Campbell]

On Mon, 2015-11-02 at 15:55 +, Stefano Stabellini wrote:
> 
> > +/*
> > + * Macro to set a guest pointer in the handle.
> > + *
> > + * Note that it's not possible to implement safely a macro to retrieve the
> > + * handle unless the guest is built with strict aliasing disabling.
> > + * Hence, we don't provide a such macro in the public headers.
> > + */
> > +#define set_xen_guest_handle_raw(hnd, val)  \
> > +do {\
> > +/* Check if the handle is 64-bit (i.e 8-byte) */\
> > +(void) sizeof(struct { int : -!!(sizeof (hnd) != 8);
> > });\
> > +/* Check if the type of val is compatible with the handle
> > */\
> > +(void) sizeof((val) !=
> > (hnd).p);\
> > +(hnd).q =
> > (uint64_t)(uintptr_t)(val);   \
> >  } while ( 0 )
> 
> Honestly I would be OK with having a typeof in the public headers to
> avoid this code, which is much harder to follow.

I suppose your objection is to two things:

+    /* Check if the handle is 64-bit (i.e 8-byte) */    \
+    (void) sizeof(struct { int : -!!(sizeof (hnd) != 8); });    \

and

+    /* Check if the type of val is compatible with the handle */    \
+    (void) sizeof((val) != (hnd).p);    \

The first is really just an open coding of BUILD_BUG_ON, I suppose for some
reason BUILD_BUG_ON cannot just be used here (I assume because this is
itself a macro).

Personally I think a comment referring back to BUILD_BUG_ON e.g.:
/* BUILD_BUG_ON(sizeof(hnd) != 8); Cannot use real B_B_O in a macro */
would be sufficient.

For the second I think the comparison of two pointers in this as a macro
type safety check is a common enough idiom that it should be understood.
But I wouldn't object to a more explicit comment explaining this, or
explaining that sizeof is necessary to not evaluate hnd a second time in
the macro.

On the second though, Julien I think it needs to be () since you need
to compare the pointers to the types to trigger the compiler's "comparing
distinct pointer types" warning/error. Also given this new usage I think it
would be worth renaming p and q to something less opaque, value and
type_check or something would be fine IMHO.

>  Why don't we do something like the following:

Apart from Jan's comment about __asm__ and a question I have about whether
it isn't even needed, how certain are you that this doesn't violate any of
the C aliasing rules etc?

BTW, Julien, I think it would be fine to also make this macro differ for
arm32 and arm64, since the arm64 variant would then surely be simpler and
the arm32 one might (or might not) be.

> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-
> arm.h
> index 9a96401..e676ffb 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -189,11 +189,12 @@
>  #define __XEN_GUEST_HANDLE(name)__guest_handle_64_ ## name
>  #define XEN_GUEST_HANDLE(name)  __XEN_GUEST_HANDLE(name)
>  #define XEN_GUEST_HANDLE_PARAM(name)__guest_handle_ ## name
> +#define barrier() __asm__ __volatile__("": : :"memory")
>  #define set_xen_guest_handle_raw(hnd, val)  \
>  do {\
> -typeof(&(hnd)) _sxghr_tmp = &(hnd); \
> -_sxghr_tmp->q = 0;  \
> -_sxghr_tmp->p = val;\
> +*((uint64_aligned_t *)&(hnd)) = 0;  \
> +barrier();  \
> +(hnd).p = val;  \
>  } while ( 0 )
>  #ifdef __XEN_TOOLS__
>  #define get_xen_guest_handle(val, hnd)  do { val = (hnd).p; } while (0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 16/32] xen/x86: allow disabling the pmtimer

[Jan Beulich]

>>> On 03.11.15 at 11:57,  wrote:
> On 03/11/15 07:21, Jan Beulich wrote:
> On 30.10.15 at 16:36,  wrote:
>>> On 30/10/15 13:16, Jan Beulich wrote:
>>> On 30.10.15 at 13:50,  wrote:
> El 14/10/15 a les 16.37, Jan Beulich ha escrit:
> On 02.10.15 at 17:48,  wrote:
>>> Signed-off-by: Roger Pau Monné 
>>> Cc: Jan Beulich 
>>> Cc: Andrew Cooper 
>>> ---
>>> Changes since v6:
>>>  - Return ENODEV in pmtimer_load if the timer is disabled.
>>>  - hvm_acpi_power_button and hvm_acpi_sleep_button become noops if the
>>>pmtimer is disabled.
>> But how are those two features connected? I don't think you can
>> assume absence of a PM block just because there's no PM timer.
>> Or if you want to tie them together for now, the predicate needs
>> to be renamed.
>>
>>>  - Return ENODEV if pmtimer_change_ioport is called with the pmtimer
>>>disabled.
>> Same here.
> What about changing XEN_X86_EMU_PMTIMER into XEN_X86_EMU_PM and this
> flags disables all PM stuff?
 Ah, right, that's a reasonable option.
>>> It still might be a nice idea to split them in two, given future work.
>>>
>>> To support hotplug properly (cpu, ram and pci), Xen needs to inject
>>> GPEs, which comes from part of the PM infrastructure.  To support PCI
>>> devices in the future without the whole PM infrastructure, it would be
>>> nice to keep the split.
>> Coming back to this - I'm not sure: The hotplug aspect as you
>> mention it should matter for Dom0 only. DomU could (and perhaps
>> should) use a PV interface instead.
> 
> I disagree.
> 
> All PVH guests should use the same mechanism; making a split between
> dom0 and domU will only make our lives harder.
> 
> Where reasonable, we should follow what happens on native; one of the
> underlying points of PVH is to have less of an impact on the guest
> side.  In some cases it is indeed nasty, but has the advantage of being
> well understood.

What meaning would ACPI have to a PVH DomU?

>> So I'd like to suggest quite the opposite: Don't call the thing PM,
>> but make it more general and call it ACPI. And instead of
>> separating HPET, we might have this fall under ACPI as well, or
>> we might have a second TIMER flag, requiring both to be set
>> for there to be a HPET and PMTMR. This leaves open the option
>> of Dom0 getting ACPI enabled (despite this then being "real",
>> not emulated ACPI), but TIMER left off.
> 
> An HPET can exist independently of other features such as ACPI.  It
> should have its own option.

Without ACPI there's no defined way to discover it. Doing what
Linux does - applying chipset knowledge - won't work on PVH either,
because there's no emulated chipset. Which would leave scanning
physical memory, but if there is none, none can be found.

> +1 to having an ACPI option, but as indicated above, I expect it to be
> used in the longterm even for domU.

Again - why and how?

Jan

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

Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

[Jan Beulich]

>>> On 03.11.15 at 13:22,  wrote:
> On Mon, 2015-11-02 at 09:11 -0700, Jan Beulich wrote:
>> > Does all of that fall out from a desire to reuse __FILE__? If so I'm
>> > inclined to suggest that -DBUILD_FILENAME_PREFIX="compat/" or whatever
>> > would seem likely to me to end up less strange (but maybe you tried
>> > that
>> > and it was worse?).
>> 
>> Yes to the first question. And no, I didn't try the alternative you
>> suggest, but discarded it as the uglier variant from the beginning.
>> In particular I dislike (parts of) file names to be specified on the
>> command line, rather than getting derived from what we have
>> anyway.
> 
> Hrm, ok.
> 
> What I was actually thinking (but not expressing very well in the example I
> gave) was that the code being compiled a second time in "compat" mode would
> be tagged as that, e.g. by listing them in obj-compat-y and adding
> something to CFLAGS (which may or may not look like a subpath, it might
> e.g. just be "(compat)").

I definitely want this to be a real path, i.e. a representation allowing
to connect thing to how the source file layout is without any guessing.

> Many of the double compiled files end up #defineing COMPAT, even without
> moving that to CFLAGS isn't that enough to key such a distinction on.

Of course that would be possible, but since that would mean
e.g. adding #ifdef-s it would clutter the code.

>> Considering that Andrew was fine with the x86 parts, I'd want to
>> change the approach (the x86 side of which I understand is of
>> particular concern to you) only if you're convinced this alternative
>> approach is sufficiently much better.
> 
> I'm mostly concerned with precedent being set by x86 and also implied by
> the common code Makefile infra which supports it causing people to think it
> is acceptable outside of x86.
> 
> I wouldn't ack an arm patch which made it such that the files in a single
> subdirectory fell in two "classes" like this, and I'd probably argue more
> strongly against it if it was being used in common code.

Okay, so for common code you didn't object to (but also didn't ack)
the change to compile the whole compat/ subtree from one level up.
That's certainly an option on x86 too, the more that the x86_64/
subtree is a remnant of x86_32 days only anyway. Just that doing
this will mean quite a bit more work (not the least because, to be
done properly, I think it implies merging files from x86_64/ into their
[formerly] shared files where sensible).

Jan


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

Re: [Xen-devel] [PATCH] libxlu: avoid linker warnings

[Jan Beulich]

>>> On 02.11.15 at 15:01,  wrote:
> On Thu, 2015-10-29 at 04:05 -0600, Jan Beulich wrote:
>> Recent ld warns about libxenlight.so's dependency libraries not being
>> available, which can be easily avoided by not just passing the raw
>> library name on ld's command line.
> 
>> In the course of checking how things fit together (I originally
>> suspected the warning to come from the linking of xl) I also noticed a
>> stray L in SHLIB_libxenguest, which gets removed at once.
> 
> Looks like I (unwittingly) fixed this aspect in
> 
> http://lists.xen.org/archives/html/xen-devel/2015-10/msg02256.html 
> too. I can easily rebase.
> 
> Since you have a pickier ld than me I wonder if you would mind trying my 
> patch out on top of yours too?

No warnings.

Jan


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

Re: [Xen-devel] [PATCH] sched_credit: Remove cpu argument to __runq_insert()

[George Dunlap]

On Fri, Oct 30, 2015 at 5:00 PM, Jan Beulich  wrote:
 On 30.10.15 at 17:33,  wrote:
>> On Fri, 2015-10-30 at 10:25 -0600, Jan Beulich wrote:
>>> > > > On 30.10.15 at 16:09,  wrote:
>>> > --- a/xen/common/sched_credit.c
>>> > +++ b/xen/common/sched_credit.c
>>> > @@ -252,13 +252,12 @@ __runq_elem(struct list_head *elem)
>>> >  }
>>> >
>>> >  static inline void
>>> > -__runq_insert(unsigned int cpu, struct csched_vcpu *svc)
>>> > +__runq_insert(struct csched_vcpu *svc)
>>> >  {
>>> > -const struct list_head * const runq = RUNQ(cpu);
>>> > +const struct list_head * const runq = RUNQ(svc->vcpu
>>> > ->processor);
>>>
>>> ... this being an inline function the change will likely make the
>>> compiler produce worse code, if only ...
>>>
>>> >  struct list_head *iter;
>>> >
>>> >  BUG_ON( __vcpu_on_runq(svc) );
>>> > -BUG_ON( cpu != svc->vcpu->processor );
>>>
>>> ... this was an ASSERT() instead of a BUG_ON() (which it looks like
>>> it should be).
>>>
>> Mmm... I'm sorry, but I'm not getting what you are actually suggesting.
>>
>> Are you saying that we shouldn't make the change at all? Or that we
>> should make the change and also turn the BUG_ON() (the one that is left
>> in place) into an ASSERT()? Or that we should not mark the function as
>> 'inline'?
>
> No, I'm suggesting that instead of this change the BUG_ON() (or
> perhaps both and also others) should be converted to ASSERT().

So you agree that this change makes the source code make more sense
("looks like an improvement at the source level"), but you think that
this will make the compiled code less efficient; and you recommend
instead of making the source code clearer, to make things even
*better* by changing the BUG_ON() to an ASSERT?

Why do you think the compiler output will be less efficient?

Overall I think the burden of proof is on you to show that the code as
it is introduces a sufficient performance improvement over the more
readable code, rather than on Harmandeep (or Dario or I) to show that
it doesn't.

 -George

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

[Xen-devel] [xen-4.6-testing baseline-only test] 38242: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38242 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38242/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail REGR. vs. 38229

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 38229
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38229

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-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-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 xen  40d7a7454835c2f7c639c78f6c09e7b6f0e4a4e2
baseline version:
 xen  bdc9fdf9d468cb94ca0fbed1b969c20bf173dc9b

Last test of basis38229  2015-10-30 17:26:07 Z3 days
Testing same since38242  2015-11-02 19:56:53 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

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

Re: [Xen-devel] [PATCH RFC] vmalloc/vzalloc: Add memflags parameter.

[Ian Campbell]

On Mon, 2015-11-02 at 12:12 -0500, Konrad Rzeszutek Wilk wrote:
> And use it amongst the callers of this function.

I expect this will also need some (hopefully trivial) changes for ARM too?

> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  xen/arch/x86/mm/hap/hap.c   | 2 +-
>  xen/arch/x86/mm/shadow/common.c | 2 +-
>  xen/common/domain.c | 2 +-
>  xen/common/domctl.c | 2 +-
>  xen/common/grant_table.c| 3 ++-
>  xen/common/vmap.c   | 8 
>  xen/include/asm-x86/domain.h| 4 ++--
>  xen/include/xen/vmap.h  | 4 ++--
>  8 files changed, 14 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index e9c0080..acc5219 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -86,7 +86,7 @@ int hap_track_dirty_vram(struct domain *d,
>  }
>  
>  rc = -ENOMEM;
> -dirty_bitmap = vzalloc(size);
> +dirty_bitmap = vzalloc(size, MEMF_node(domain_to_node(d)));
>  if ( !dirty_bitmap )
>  goto out;
>  
> diff --git a/xen/arch/x86/mm/shadow/common.c
> b/xen/arch/x86/mm/shadow/common.c
> index bad355b..4169083 100644
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -3491,7 +3491,7 @@ int shadow_track_dirty_vram(struct domain *d,
>  if ( !nr )
>  goto out;
>  
> -dirty_bitmap = vzalloc(dirty_size);
> +dirty_bitmap = vzalloc(dirty_size, MEMF_node(domain_to_node(d)));
>  if ( dirty_bitmap == NULL )
>  {
>  rc = -ENOMEM;
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index b0378aa..55a94d4 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1223,7 +1223,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid,
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  if ( v->vcpu_info == _vcpu_info )
>  return -EINVAL;
>  
> -if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
> +if ( (ctxt =
> alloc_vcpu_guest_context(MEMF_node(domain_to_node(d == NULL )
>  return -ENOMEM;
>  
>  if ( copy_from_guest(ctxt, arg, 1) )
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 46b967e..b874b01 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -492,7 +492,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
>   < sizeof(struct compat_vcpu_guest_context));
>  #endif
>  ret = -ENOMEM;
> -if ( (c.nat = alloc_vcpu_guest_context()) == NULL )
> +if ( (c.nat =
> alloc_vcpu_guest_context(MEMF_node(domain_to_node(d == NULL )
>  break;
>  
>  #ifdef CONFIG_COMPAT
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index c92abda..b86286f 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3200,7 +3200,8 @@ grant_table_create(
>  }
>  
>  /* Tracking of mapped foreign frames table */
> -t->maptrack = vzalloc(max_maptrack_frames * sizeof(*t->maptrack));
> +t->maptrack = vzalloc(max_maptrack_frames * sizeof(*t->maptrack),
> +  MEMF_node(domain_to_node(d)));
>  if ( t->maptrack == NULL )
>  goto no_mem_2;
>  
> diff --git a/xen/common/vmap.c b/xen/common/vmap.c
> index c57239f..fd295b1 100644
> --- a/xen/common/vmap.c
> +++ b/xen/common/vmap.c
> @@ -216,7 +216,7 @@ void vunmap(const void *va)
>  vm_free(va);
>  }
>  
> -void *vmalloc(size_t size)
> +void *vmalloc(size_t size, unsigned int memflags)
>  {
>  mfn_t *mfn;
>  size_t pages, i;
> @@ -232,7 +232,7 @@ void *vmalloc(size_t size)
>  
>  for ( i = 0; i < pages; i++ )
>  {
> -pg = alloc_domheap_page(NULL, 0);
> +pg = alloc_domheap_page(NULL, memflags);
>  if ( pg == NULL )
>  goto error;
>  mfn[i] = _mfn(page_to_mfn(pg));
> @@ -252,9 +252,9 @@ void *vmalloc(size_t size)
>  return NULL;
>  }
>  
> -void *vzalloc(size_t size)
> +void *vzalloc(size_t size, unsigned int memflags)
>  {
> -void *p = vmalloc(size);
> +void *p = vmalloc(size, memflags);
>  int i;
>  
>  if ( p == NULL )
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index f1d7ed6..a98bf3b 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -577,9 +577,9 @@ void domain_cpuid(struct domain *d,
>  
>  #define domain_max_vcpus(d) (is_hvm_domain(d) ? HVM_MAX_VCPUS :
> MAX_VIRT_CPUS)
>  
> -static inline struct vcpu_guest_context *alloc_vcpu_guest_context(void)
> +static inline struct vcpu_guest_context
> *alloc_vcpu_guest_context(unsigned int memflags)
>  {
> -return vmalloc(sizeof(struct vcpu_guest_context));
> +return vmalloc(sizeof(struct vcpu_guest_context), memflags);
>  }
>  
>  static inline void free_vcpu_guest_context(struct vcpu_guest_context
> *vgc)
> diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
> index 5671ac8..f24a29e 

Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

[Ian Campbell]

On Mon, 2015-11-02 at 09:11 -0700, Jan Beulich wrote:
> > > > 
> > It seems quite inconsistent to me to have xen/arch/x86/x86_64/Makefile
> > building some files directly and xen/arch/x86/Makefile to be building
> > another subset of those files via x86_64/FOO.o. Even more so that other
> > than compat.o I can't see what makes many affected files (e.g. mm.o or
> > platform_hypercall.o) special in this regard.
> 
> The platform_hypercall one is quite obvious, because
> x86_64/platform_hypercall.c just includes platform_hypercall.c
> (which is the general pattern we're dealing with here). For mm.c
> it was just prompted by actual collisions seen.

Neither of those seem obvious to me.

> > Does all of that fall out from a desire to reuse __FILE__? If so I'm
> > inclined to suggest that -DBUILD_FILENAME_PREFIX="compat/" or whatever
> > would seem likely to me to end up less strange (but maybe you tried
> > that
> > and it was worse?).
> 
> Yes to the first question. And no, I didn't try the alternative you
> suggest, but discarded it as the uglier variant from the beginning.
> In particular I dislike (parts of) file names to be specified on the
> command line, rather than getting derived from what we have
> anyway.

Hrm, ok.

What I was actually thinking (but not expressing very well in the example I
gave) was that the code being compiled a second time in "compat" mode would
be tagged as that, e.g. by listing them in obj-compat-y and adding
something to CFLAGS (which may or may not look like a subpath, it might
e.g. just be "(compat)").

Many of the double compiled files end up #defineing COMPAT, even without
moving that to CFLAGS isn't that enough to key such a distinction on.

> Considering that Andrew was fine with the x86 parts, I'd want to
> change the approach (the x86 side of which I understand is of
> particular concern to you) only if you're convinced this alternative
> approach is sufficiently much better.

I'm mostly concerned with precedent being set by x86 and also implied by
the common code Makefile infra which supports it causing people to think it
is acceptable outside of x86.

I wouldn't ack an arm patch which made it such that the files in a single
subdirectory fell in two "classes" like this, and I'd probably argue more
strongly against it if it was being used in common code.

As it is today only for x86 I suppose I have no real grounds to nack it,
except to preemptively nack any use of it outside of x86.

Ian.

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

Re: [Xen-devel] Revisit VT-d asynchronous flush issue

[George Dunlap]

On 02/11/15 14:10, Jan Beulich wrote:
 On 02.11.15 at 09:03,  wrote:
>> Based on above information, we propose to continue spin-timeout
>> model w/ some adjustment, which fixes current timeout concern
>> and also allows limited ATS support in a light way:
>>
>> 1) reduce spin timeout to 1ms, which can be boot-time changed
>> up to 10ms.

Out of curiosity, is there a reason to limit the timeout to 10ms?

I'm generally a believer that we should do something sensible by
default, but that an admin -- particularly someone who is going to be
messing around with this sort of setting -- should be allowed to "shoot
themselves in the foot" if they want to.

Suppose that there's some particularly grotty piece of hardware that
really does require a 30ms, or 100ms timeout to work effectively?  If we
have a hard limit of 10ms, there's nothing the person can do other than
re-compile Xen.  If we have no hard limit, they can simply set it to
100ms as a work-around until we get asynchronous flushing working.

Other than that, this sounds sensible to me.

 -George


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

Re: [Xen-devel] [PATCH v7 16/32] xen/x86: allow disabling the pmtimer

[Andrew Cooper]

On 03/11/15 07:21, Jan Beulich wrote:
 On 30.10.15 at 16:36,  wrote:
>> On 30/10/15 13:16, Jan Beulich wrote:
>> On 30.10.15 at 13:50,  wrote:
 El 14/10/15 a les 16.37, Jan Beulich ha escrit:
 On 02.10.15 at 17:48,  wrote:
>> Signed-off-by: Roger Pau Monné 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> ---
>> Changes since v6:
>>  - Return ENODEV in pmtimer_load if the timer is disabled.
>>  - hvm_acpi_power_button and hvm_acpi_sleep_button become noops if the
>>pmtimer is disabled.
> But how are those two features connected? I don't think you can
> assume absence of a PM block just because there's no PM timer.
> Or if you want to tie them together for now, the predicate needs
> to be renamed.
>
>>  - Return ENODEV if pmtimer_change_ioport is called with the pmtimer
>>disabled.
> Same here.
 What about changing XEN_X86_EMU_PMTIMER into XEN_X86_EMU_PM and this
 flags disables all PM stuff?
>>> Ah, right, that's a reasonable option.
>> It still might be a nice idea to split them in two, given future work.
>>
>> To support hotplug properly (cpu, ram and pci), Xen needs to inject
>> GPEs, which comes from part of the PM infrastructure.  To support PCI
>> devices in the future without the whole PM infrastructure, it would be
>> nice to keep the split.
> Coming back to this - I'm not sure: The hotplug aspect as you
> mention it should matter for Dom0 only. DomU could (and perhaps
> should) use a PV interface instead.

I disagree.

All PVH guests should use the same mechanism; making a split between
dom0 and domU will only make our lives harder.

Where reasonable, we should follow what happens on native; one of the
underlying points of PVH is to have less of an impact on the guest
side.  In some cases it is indeed nasty, but has the advantage of being
well understood.

>
> So I'd like to suggest quite the opposite: Don't call the thing PM,
> but make it more general and call it ACPI. And instead of
> separating HPET, we might have this fall under ACPI as well, or
> we might have a second TIMER flag, requiring both to be set
> for there to be a HPET and PMTMR. This leaves open the option
> of Dom0 getting ACPI enabled (despite this then being "real",
> not emulated ACPI), but TIMER left off.

An HPET can exist independently of other features such as ACPI.  It
should have its own option.

+1 to having an ACPI option, but as indicated above, I expect it to be
used in the longterm even for domU.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

[Jan Beulich]

>>> On 03.11.15 at 14:39,  wrote:
> On Tue, 2015-11-03 at 05:50 -0700, Jan Beulich wrote:
>> That's certainly an option on x86 too, the more that the x86_64/
>> subtree is a remnant of x86_32 days only anyway. Just that doing
>> this will mean quite a bit more work (not the least because, to be
>> done properly, I think it implies merging files from x86_64/ into their
>> [formerly] shared files where sensible).
> 
> FWIW IMHO compiling arch/x86/x86_64/*.c from arch/x86/Makefile now and then
> tackling the merging as and when it makes sense would be fine.

Great. It's on my list to do this merge (in steps) anyway. So does
this mean I can go ahead and commit both this and patch 1, i.e.
at least kind-of-an-ack?

Jan


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

Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

[Ian Campbell]

On Tue, 2015-11-03 at 08:31 -0700, Jan Beulich wrote:
> > > > On 03.11.15 at 14:39,  wrote:
> > On Tue, 2015-11-03 at 05:50 -0700, Jan Beulich wrote:
> > > That's certainly an option on x86 too, the more that the x86_64/
> > > subtree is a remnant of x86_32 days only anyway. Just that doing
> > > this will mean quite a bit more work (not the least because, to be
> > > done properly, I think it implies merging files from x86_64/ into
> > > their
> > > [formerly] shared files where sensible).
> > 
> > FWIW IMHO compiling arch/x86/x86_64/*.c from arch/x86/Makefile now and
> > then
> > tackling the merging as and when it makes sense would be fine.
> 
> Great. It's on my list to do this merge (in steps) anyway. So does
> this mean I can go ahead and commit both this and patch 1, i.e.
> at least kind-of-an-ack?

Acked-by: Ian Campbell 

with the provisos regarding common code and not setting a precedent for ARM
I mentioned before (which doesn't need reflecting in the ack in the commit
message, I'll just remember it)

Ian.

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

[Xen-devel] [ovmf baseline-only test] 38245: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38245 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38245/

Regressions :-(

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

version targeted for testing:
 ovmf 8aa6ebe83f91fcd5e1a67d316e444f4ac8b1319d
baseline version:
 ovmf df60fb4cc2ca896fcea9e37b06c276d569f1a6b8

Last test of basis38237  2015-11-01 21:20:34 Z1 days
Testing same since38245  2015-11-03 08:58:06 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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



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

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

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


Push not applicable.


commit 8aa6ebe83f91fcd5e1a67d316e444f4ac8b1319d
Author: Star Zeng 
Date:   Mon Nov 2 01:42:51 2015 +

MdeModulePkg SmbiosMeasurementDxe: NULL check to String from 
GetSmbiosStringById

When StringId is not 0, String returned from GetSmbiosStringById is 
expected to non-NULL.
Add ASSERT (String != NULL); to ensure this.

Cc: Jiewen Yao 
Cc: Shumin Qiu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by: Shumin Qiu 

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

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

Re: [Xen-devel] [PATCH v3 2/4] arm64: Add xen_boot module file

[Ian Campbell]

On Tue, 2015-11-03 at 22:57 +0800, Fu Wei wrote:
> Hi Vladimir,
> 
> After discussing with Ian Campbell,   Since we already can load all
> the necessary binaries for Xen boot on arm64 for now,  we don't really
> need "xen_module" command now.
> But maybe someday , xen need a new type of binary in boot time, then
> we still need this support.

You mean support for "--type" passed to the xen_module command, right? I
thought the xen_module stuff had been applied. Or am I misunderstanding
which bits have been applied?

> So I will submit  a   "xen_module" command patch soon, in case we need
> it.

Just to clarify, my suggestion was to repost the bits which were omitted
from the prior patches just so that they are available in the ML archives
etc should anyone ever want to resurrect them in the future.

Ian.


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

Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw

[Julien Grall]

On 03/11/15 14:18, Stefano Stabellini wrote:
>> +#define set_xen_guest_handle_raw(hnd, val)  \
>> +do {\
>> +/* Check if the handle is 64-bit (i.e 8-byte) */\
>> +(void) sizeof(struct { int : -!!(sizeof (hnd) != 8); });\
>> +/* Check if the type of val is compatible with the handle */\
>> +(void) sizeof((val) != (hnd).p);\
>> +(hnd).q = (uint64_t)(uintptr_t)(val);   \
>>  } while ( 0 )
>>  #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
> 
> will get_xen_guest_handle, which access (hnd).p, have undefined behaviour?

get_xen_guest_handle has been removed in staging.

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH v1 08/11] xsplice: Implement support for applying patches

[Ross Lagerwall]

Implement support for the apply, revert and replace actions.

To perform and action on a payload, the hypercall sets up a data
structure to schedule the work.  A hook is added in all the
return-to-guest paths to check for work to do and execute it if needed.
In this way, patches can be applied with all CPUs idle and without
stacks.  The first CPU to do_xsplice() becomes the master and triggers a
reschedule softirq to trigger all the other CPUs to enter do_xsplice()
with no stack.  Once all CPUs have rendezvoused, all CPUs disable IRQs
and NMIs are ignored. The system is then quiscient and the master
performs the action.  After this, all CPUs enable IRQs and NMIs are
re-enabled.

The action to perform is one of:
- APPLY: For each function in the module, store the first 5 bytes of the
  old function and replace it with a jump to the new function.
- REVERT: Copy the previously stored bytes into the first 5 bytes of the
  old function.
- REPLACE: Revert each applied module and then apply the new module.

To prevent a deadlock with any other barrier in the system, the master
will wait for up to 30ms before timing out.  I've taken some
measurements and found the patch application to take about 100 μs on a
72 CPU system, whether idle or fully loaded.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/arm/xsplice.c  |   8 ++
 xen/arch/x86/domain.c   |   4 +
 xen/arch/x86/hvm/svm/svm.c  |   2 +
 xen/arch/x86/hvm/vmx/vmcs.c |   2 +
 xen/arch/x86/xsplice.c  |  19 
 xen/common/xsplice.c| 264 ++--
 xen/include/asm-arm/nmi.h   |  13 +++
 xen/include/xen/xsplice.h   |   7 +-
 8 files changed, 306 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/xsplice.c b/xen/arch/arm/xsplice.c
index 8d85fa9..3c34eb3 100644
--- a/xen/arch/arm/xsplice.c
+++ b/xen/arch/arm/xsplice.c
@@ -3,6 +3,14 @@
 #include 
 #include 
 
+void xsplice_apply_jmp(struct xsplice_patch_func *func)
+{
+}
+
+void xsplice_revert_jmp(struct xsplice_patch_func *func)
+{
+}
+
 int xsplice_verify_elf(uint8_t *data, ssize_t len)
 {
 return -ENOSYS;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index fe3be30..4420cfc 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -120,6 +121,7 @@ static void idle_loop(void)
 (*pm_idle)();
 do_tasklet();
 do_softirq();
+do_xsplice();
 }
 }
 
@@ -136,6 +138,7 @@ void startup_cpu_idle_loop(void)
 
 static void noreturn continue_idle_domain(struct vcpu *v)
 {
+do_xsplice();
 reset_stack_and_jump(idle_loop);
 }
 
@@ -143,6 +146,7 @@ static void noreturn continue_nonidle_domain(struct vcpu *v)
 {
 check_wakeup_from_wait();
 mark_regs_dirty(guest_cpu_user_regs());
+do_xsplice();
 reset_stack_and_jump(ret_from_intr);
 }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8de41fa..65bf7e9 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1071,6 +1072,7 @@ static void noreturn svm_do_resume(struct vcpu *v)
 
 hvm_do_resume(v);
 
+do_xsplice();
 reset_stack_and_jump(svm_asm_do_resume);
 }
 
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 4ea1ad1..d996f47 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1685,6 +1686,7 @@ void vmx_do_resume(struct vcpu *v)
 }
 
 hvm_do_resume(v);
+do_xsplice();
 reset_stack_and_jump(vmx_asm_do_vmentry);
 }
 
diff --git a/xen/arch/x86/xsplice.c b/xen/arch/x86/xsplice.c
index dbff0d5..31e4124 100644
--- a/xen/arch/x86/xsplice.c
+++ b/xen/arch/x86/xsplice.c
@@ -3,6 +3,25 @@
 #include 
 #include 
 
+#define PATCH_INSN_SIZE 5
+
+void xsplice_apply_jmp(struct xsplice_patch_func *func)
+{
+uint32_t val;
+uint8_t *old_ptr;
+
+old_ptr = (uint8_t *)func->old_addr;
+memcpy(func->undo, old_ptr, PATCH_INSN_SIZE);
+*old_ptr++ = 0xe9; /* Relative jump */
+val = func->new_addr - func->old_addr - PATCH_INSN_SIZE;
+memcpy(old_ptr, , sizeof val);
+}
+
+void xsplice_revert_jmp(struct xsplice_patch_func *func)
+{
+memcpy((void *)func->old_addr, func->undo, PATCH_INSN_SIZE);
+}
+
 int xsplice_verify_elf(uint8_t *data, ssize_t len)
 {
 
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 5e88c55..4476be5 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -11,16 +11,21 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 #include 
+#include 
 
 static DEFINE_SPINLOCK(payload_list_lock);
 static LIST_HEAD(payload_list);
 
+static LIST_HEAD(applied_list);
+
 static unsigned int payload_cnt;
 static unsigned int payload_version 

[Xen-devel] [PATCH v1 05/11] elf: Add relocation types to elfstructs.h

[Ross Lagerwall]

Signed-off-by: Ross Lagerwall 
---
 xen/include/xen/elfstructs.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/xen/include/xen/elfstructs.h b/xen/include/xen/elfstructs.h
index 12ffb82..5ca2956 100644
--- a/xen/include/xen/elfstructs.h
+++ b/xen/include/xen/elfstructs.h
@@ -348,6 +348,27 @@ typedef struct {
 #defineELF64_R_TYPE(info)  ((info) & 0x)
 #define ELF64_R_INFO(s,t)  (((s) << 32) + (u_int32_t)(t))
 
+/* x86-64 relocation types */
+#define R_X86_64_NONE  0   /* No reloc */
+#define R_X86_64_641   /* Direct 64 bit  */
+#define R_X86_64_PC32  2   /* PC relative 32 bit signed */
+#define R_X86_64_GOT32 3   /* 32 bit GOT entry */
+#define R_X86_64_PLT32 4   /* 32 bit PLT address */
+#define R_X86_64_COPY  5   /* Copy symbol at runtime */
+#define R_X86_64_GLOB_DAT  6   /* Create GOT entry */
+#define R_X86_64_JUMP_SLOT 7   /* Create PLT entry */
+#define R_X86_64_RELATIVE  8   /* Adjust by program base */
+#define R_X86_64_GOTPCREL  9   /* 32 bit signed pc relative
+  offset to GOT */
+#define R_X86_64_3210  /* Direct 32 bit zero extended */
+#define R_X86_64_32S   11  /* Direct 32 bit sign extended */
+#define R_X86_64_1612  /* Direct 16 bit zero extended */
+#define R_X86_64_PC16  13  /* 16 bit sign extended pc relative */
+#define R_X86_64_8 14  /* Direct 8 bit sign extended  */
+#define R_X86_64_PC8   15  /* 8 bit sign extended pc relative */
+
+#define R_X86_64_NUM   16
+
 /* Program Header */
 typedef struct {
Elf32_Word  p_type; /* segment type */
-- 
2.4.3


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

[Xen-devel] [PATCH v1 06/11] xsplice: Add helper elf routines

[Ross Lagerwall]

Add some elf routines and data structures in preparation for loading an
xsplice payload.

Signed-off-by: Ross Lagerwall 
---
 xen/common/Makefile   |   1 +
 xen/common/xsplice_elf.c  | 122 ++
 xen/include/xen/xsplice_elf.h |  44 +++
 3 files changed, 167 insertions(+)
 create mode 100644 xen/common/xsplice_elf.c
 create mode 100644 xen/include/xen/xsplice_elf.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1b17c9d..de7c08a 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -57,6 +57,7 @@ obj-y += vsprintf.o
 obj-y += wait.o
 obj-y += xmalloc_tlsf.o
 obj-y += xsplice.o
+obj-y += xsplice_elf.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo 
unlz4 earlycpio,$(n).init.o)
 
diff --git a/xen/common/xsplice_elf.c b/xen/common/xsplice_elf.c
new file mode 100644
index 000..13a9229
--- /dev/null
+++ b/xen/common/xsplice_elf.c
@@ -0,0 +1,122 @@
+#include 
+#include 
+#include 
+
+struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf *elf,
+const char *name)
+{
+int i;
+
+for ( i = 0; i < elf->hdr->e_shnum; i++ )
+{
+if ( !strcmp(name, elf->sec[i].name) )
+return >sec[i];
+}
+
+return NULL;
+}
+
+static int elf_get_sections(struct xsplice_elf *elf, uint8_t *data)
+{
+struct xsplice_elf_sec *sec;
+int i;
+
+sec = xmalloc_array(struct xsplice_elf_sec, elf->hdr->e_shnum);
+if ( !sec )
+{
+printk(XENLOG_ERR "Could not find section table\n");
+return -ENOMEM;
+}
+
+for ( i = 0; i < elf->hdr->e_shnum; i++ )
+{
+#ifdef CONFIG_ARM_32
+sec[i].sec = (Elf32_Shdr *)(data + elf->hdr->e_shoff +
+i * elf->hdr->e_shentsize);
+#else
+sec[i].sec = (Elf64_Shdr *)(data + elf->hdr->e_shoff +
+i * elf->hdr->e_shentsize);
+#endif
+sec[i].data = data + sec[i].sec->sh_offset;
+}
+elf->sec = sec;
+
+return 0;
+}
+
+static int elf_get_sym(struct xsplice_elf *elf, uint8_t *data)
+{
+struct xsplice_elf_sec *symtab, *strtab_sec;
+struct xsplice_elf_sym *sym;
+const char *strtab;
+int i;
+
+symtab = xsplice_elf_sec_by_name(elf, ".symtab");
+if ( !symtab )
+{
+printk(XENLOG_ERR "Could not find symbol table\n");
+return -EINVAL;
+}
+
+strtab_sec = xsplice_elf_sec_by_name(elf, ".strtab");
+if ( !strtab_sec )
+{
+printk(XENLOG_ERR "Could not find string table\n");
+return -EINVAL;
+}
+strtab = (const char *)(data + strtab_sec->sec->sh_offset);
+
+elf->nsym = symtab->sec->sh_size / symtab->sec->sh_entsize;
+
+sym = xmalloc_array(struct xsplice_elf_sym, elf->nsym);
+if ( !sym )
+{
+printk(XENLOG_ERR "Could not allocate memory for symbols\n");
+return -ENOMEM;
+}
+
+for ( i = 0; i < elf->nsym; i++ )
+{
+#ifdef CONFIG_ARM_32
+sym[i].sym = (Elf32_Sym *)(symtab->data + i * symtab->sec->sh_entsize);
+#else
+sym[i].sym = (Elf64_Sym *)(symtab->data + i * symtab->sec->sh_entsize);
+#endif
+sym[i].name = strtab + sym[i].sym->st_name;
+}
+elf->sym = sym;
+
+return 0;
+}
+
+int xsplice_elf_load(struct xsplice_elf *elf, uint8_t *data, ssize_t len)
+{
+const char *shstrtab;
+int i, rc;
+
+#ifdef CONFIG_ARM_32
+elf->hdr = (Elf32_Ehdr *)data;
+#else
+elf->hdr = (Elf64_Ehdr *)data;
+#endif
+
+rc = elf_get_sections(elf, data);
+if ( rc )
+return rc;
+
+shstrtab = (const char *)(data + 
elf->sec[elf->hdr->e_shstrndx].sec->sh_offset);
+for ( i = 0; i < elf->hdr->e_shnum; i++ )
+elf->sec[i].name = shstrtab + elf->sec[i].sec->sh_name;
+
+rc = elf_get_sym(elf, data);
+if ( rc )
+return rc;
+
+return 0;
+}
+
+void xsplice_elf_free(struct xsplice_elf *elf)
+{
+xfree(elf->sec);
+xfree(elf->sym);
+}
diff --git a/xen/include/xen/xsplice_elf.h b/xen/include/xen/xsplice_elf.h
new file mode 100644
index 000..bac0053
--- /dev/null
+++ b/xen/include/xen/xsplice_elf.h
@@ -0,0 +1,44 @@
+#ifndef __XEN_XSPLICE_ELF_H__
+#define __XEN_XSPLICE_ELF_H__
+
+#include 
+#include 
+
+/* The following describes an Elf file as consumed by xsplice. */
+struct xsplice_elf_sec {
+#ifdef CONFIG_ARM_32
+Elf32_Shdr *sec;
+#else
+Elf64_Shdr *sec;
+#endif
+const char *name;
+const uint8_t *data;   /* A pointer to the data section */
+uint8_t *load_addr;/* A pointer to the allocated destination */
+};
+
+struct xsplice_elf_sym {
+#ifdef CONFIG_ARM_32
+Elf32_Sym *sym;
+#else
+Elf64_Sym *sym;
+#endif
+const char *name;
+};
+
+struct xsplice_elf {
+#ifdef CONFIG_ARM_32
+Elf32_Ehdr *hdr;
+#else
+Elf64_Ehdr *hdr;
+#endif
+struct xsplice_elf_sec *sec;   /* Array of sections */
+struct xsplice_elf_sym 

Re: [Xen-devel] [PATCH v10 2/5] missing include in cputime.c, remove #ifdef CONFIG_PARAVIRT from sched/core.c

[kbuild test robot]

Hi Stefano,

[auto build test ERROR on arm64/for-next/core]
[cannot apply to: xen-tip/linux-next]
[also ERROR on: v4.3 next-20151103]

url:
https://github.com/0day-ci/linux/commits/Stefano-Stabellini/xen-arm-arm64-CONFIG_PARAVIRT-and-stolen-ticks-accounting/20151104-002433
base:   https://github.com/0day-ci/linux 
Stefano-Stabellini/xen-arm-arm64-CONFIG_PARAVIRT-and-stolen-ticks-accounting/20151104-002433
config: mips-jz4740 (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> kernel/sched/core.c:82:26: fatal error: asm/paravirt.h: No such file or 
>> directory
   compilation terminated.
--
>> kernel/sched/cputime.c:8:26: fatal error: asm/paravirt.h: No such file or 
>> directory
   compilation terminated.

vim +82 kernel/sched/core.c

52f5684c kernel/sched/core.c Gideon Israel Dsouza  2014-04-07  76  #include 

^1da177e kernel/sched.c  Linus Torvalds2005-04-16  77  
96f951ed kernel/sched/core.c David Howells 2012-03-28  78  #include 

5517d86b kernel/sched.c  Eric Dumazet  2007-05-08  79  #include 

838225b4 kernel/sched.c  Satyam Sharma 2007-10-24  80  #include 

db7e527d kernel/sched/core.c Christian Borntraeger 2012-01-11  81  #include 

e6e6685a kernel/sched.c  Glauber Costa 2011-07-11 @82  #include 

^1da177e kernel/sched.c  Linus Torvalds2005-04-16  83  
029632fb kernel/sched.c  Peter Zijlstra2011-10-25  84  #include 
"sched.h"
ea138446 kernel/sched/core.c Tejun Heo 2013-01-18  85  #include 
"../workqueue_internal.h"

:: The code at line 82 was first introduced by commit
:: e6e6685accfa81f509fadfc9624bc7c3862d75c4 KVM guest: Steal time accounting

:: TO: Glauber Costa <glom...@redhat.com>
:: CC: Avi Kivity <a...@redhat.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/2] grant_table: convert grant table rwlock to percpu rwlock

[Malcolm Crossley]

The per domain grant table read lock suffers from significant contention when
performance multi-queue block or network IO due to the parallel
grant map/unmaps/copies occuring on the DomU's grant table.

On multi-socket systems, the contention results in the locked compare swap
operation failing frequently which results in a tight loop of retries of the
compare swap operation. As the coherency fabric can only support a specific
rate of compare swap operations for a particular data location then taking
the read lock itself becomes a bottleneck for grant operations.

Standard rwlock performance of a single VIF VM-VM transfer with 16 queues
configured was limited to approxmiately 10 gbit/s on a 2 socket Haswell-EP
host.

Percpu rwlock performance with the same configuration is approximately
50 gbit/s.

Oprofile was used to determine the initial overhead of the read-write locks
and to confirm the overhead was dramatically reduced by the percpu rwlocks.

Signed-off-by: Malcolm Crossley 
---
 xen/arch/arm/mm.c |   5 ++-
 xen/arch/x86/mm.c |   5 ++-
 xen/common/grant_table.c  | 100 ++
 xen/include/xen/grant_table.h |   4 ++
 4 files changed, 62 insertions(+), 52 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 8b6d915..596cabf 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1055,7 +1055,8 @@ int xenmem_add_to_physmap_one(
 switch ( space )
 {
 case XENMAPSPACE_grant_table:
-write_lock(>grant_table->lock);
+percpu_write_lock(_per_cpu_var(grant_rwlock), 
_rwlock_barrier,
+   >grant_table->lock);
 
 if ( d->grant_table->gt_version == 0 )
 d->grant_table->gt_version = 1;
@@ -1085,7 +1086,7 @@ int xenmem_add_to_physmap_one(
 
 t = p2m_ram_rw;
 
-write_unlock(>grant_table->lock);
+percpu_write_unlock(_rwlock_barrier, >grant_table->lock);
 break;
 case XENMAPSPACE_shared_info:
 if ( idx != 0 )
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 92df36f..2a6fe61 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4654,7 +4654,8 @@ int xenmem_add_to_physmap_one(
 mfn = virt_to_mfn(d->shared_info);
 break;
 case XENMAPSPACE_grant_table:
-write_lock(>grant_table->lock);
+percpu_write_lock(_per_cpu_var(grant_rwlock), 
_rwlock_barrier,
+   >grant_table->lock);
 
 if ( d->grant_table->gt_version == 0 )
 d->grant_table->gt_version = 1;
@@ -4676,7 +4677,7 @@ int xenmem_add_to_physmap_one(
 mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
 }
 
-write_unlock(>grant_table->lock);
+percpu_write_unlock(_rwlock_barrier, >grant_table->lock);
 break;
 case XENMAPSPACE_gmfn_range:
 case XENMAPSPACE_gmfn:
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 5d52d1e..8d19d2a 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -178,6 +178,10 @@ struct active_grant_entry {
 #define _active_entry(t, e) \
 ((t)->active[(e)/ACGNT_PER_PAGE][(e)%ACGNT_PER_PAGE])
 
+bool_t grant_rwlock_barrier;
+
+DEFINE_PER_CPU(rwlock_t *, grant_rwlock);
+
 static inline void gnttab_flush_tlb(const struct domain *d)
 {
 if ( !paging_mode_external(d) )
@@ -270,23 +274,23 @@ double_gt_lock(struct grant_table *lgt, struct 
grant_table *rgt)
  */
 if ( lgt < rgt )
 {
-write_lock(>lock);
-write_lock(>lock);
+percpu_write_lock(_per_cpu_var(grant_rwlock), 
_rwlock_barrier, >lock);
+percpu_write_lock(_per_cpu_var(grant_rwlock), 
_rwlock_barrier, >lock);
 }
 else
 {
 if ( lgt != rgt )
-write_lock(>lock);
-write_lock(>lock);
+percpu_write_lock(_per_cpu_var(grant_rwlock), 
_rwlock_barrier, >lock);
+percpu_write_lock(_per_cpu_var(grant_rwlock), 
_rwlock_barrier, >lock);
 }
 }
 
 static inline void
 double_gt_unlock(struct grant_table *lgt, struct grant_table *rgt)
 {
-write_unlock(>lock);
+percpu_write_unlock(_rwlock_barrier, >lock);
 if ( lgt != rgt )
-write_unlock(>lock);
+percpu_write_unlock(_rwlock_barrier, >lock);
 }
 
 static inline int
@@ -796,7 +800,7 @@ __gnttab_map_grant_ref(
 }
 
 rgt = rd->grant_table;
-read_lock(>lock);
+percpu_read_lock(_per_cpu_var(grant_rwlock), _rwlock_barrier, 
>lock);
 
 /* Bounds check on the grant ref */
 if ( unlikely(op->ref >= nr_grant_entries(rgt)))
@@ -859,7 +863,7 @@ __gnttab_map_grant_ref(
 cache_flags = (shah->flags & (GTF_PAT | GTF_PWT | GTF_PCD) );
 
 active_entry_release(act);
-read_unlock(>lock);
+percpu_read_unlock(_per_cpu_var(grant_rwlock));
 
 /* pg may be set, with a refcount included, from __get_paged_frame */
 if ( !pg )
@@ -1006,7 

[Xen-devel] [PATCH 1/2] rwlock: add per-cpu reader-writer locks

[Malcolm Crossley]

Per-cpu read-write locks allow for the fast path read case to have low overhead
by only setting/clearing a per-cpu variable for using the read lock.
The per-cpu read fast path also avoids locked compare swap operations which can
be particularly slow on coherent multi-socket systems, particularly if there is
heavy usage of the read lock itself.

The per-cpu reader-writer lock uses a global variable to control the read lock
fast path. This allows a writer to disable the fast path and ensure the readers
use the underlying read-write lock implementation.

Once the writer has taken the write lock and disabled the fast path, it must
poll the per-cpu variable for all CPU's which have entered the critical section
for the specific read-write lock the writer is attempting to take. This design
allows for a single per-cpu variable to be used for read/write locks belonging
to seperate data structures as long as multiple per-cpu read locks are not
simultaneously held by one particular cpu. This also means per-cpu
reader-writer locks are not recursion safe.

Slow path readers which are unblocked set the per-cpu variable and drop the
read lock. This simplifies the implementation and allows for fairness in the
underlying read-write lock to be taken advantage of.

There may be slightly more overhead on the per-cpu write lock path due to
checking each CPUs fast path read variable but this overhead is likely be hidden
by the required delay of waiting for readers to exit the critical section.
The loop is optimised to only iterate over the per-cpu data of active readers
of the rwlock.

Signed-off-by: Malcolm Crossley 
---
 xen/common/spinlock.c| 32 
 xen/include/asm-arm/percpu.h |  5 +
 xen/include/asm-x86/percpu.h |  6 ++
 xen/include/xen/percpu.h |  4 
 xen/include/xen/spinlock.h   | 37 +
 5 files changed, 84 insertions(+)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 7f89694..a526216 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -492,6 +492,38 @@ int _rw_is_write_locked(rwlock_t *lock)
 return (lock->lock == RW_WRITE_FLAG); /* writer in critical section? */
 }
 
+void percpu_write_lock(rwlock_t **per_cpudata, bool_t *writer_activating,
+   rwlock_t *rwlock)
+{
+int cpu;
+cpumask_t active_readers;
+
+cpumask_copy(_readers, _online_map);
+/* First take the write lock to protect against other writers */
+write_lock(rwlock);
+
+/* Now set the global variable so that readers start using read_lock */
+*writer_activating = true;
+smp_mb();
+
+/* Check if there are any percpu readers in progress on our rwlock*/
+do
+{
+for_each_cpu(cpu, _readers)
+{
+/* Remove any percpu readers not contending 
+ * from our check mask */
+if ( per_cpu_ptr(per_cpudata, cpu) != rwlock )
+cpumask_clear_cpu(cpu, _readers);
+}
+/* Check if we've cleared all percpu readers */
+if ( cpumask_empty(_readers) )
+break;
+/* Give the coherency fabric a break */
+cpu_relax();
+} while ( 1 );
+}
+
 #ifdef LOCK_PROFILE
 
 struct lock_profile_anc {
diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
index 71e7649..c308a56 100644
--- a/xen/include/asm-arm/percpu.h
+++ b/xen/include/asm-arm/percpu.h
@@ -27,6 +27,11 @@ void percpu_init_areas(void);
 #define __get_cpu_var(var) \
 (*RELOC_HIDE(_cpu__##var, READ_SYSREG(TPIDR_EL2)))
 
+#define per_cpu_ptr(var, cpu)  \
+(*RELOC_HIDE(, __per_cpu_offset[cpu]))
+#define __get_cpu_ptr(var) \
+(*RELOC_HIDE(, READ_SYSREG(TPIDR_EL2)))
+
 #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
 
 DECLARE_PER_CPU(unsigned int, cpu_id);
diff --git a/xen/include/asm-x86/percpu.h b/xen/include/asm-x86/percpu.h
index 604ff0d..51562b9 100644
--- a/xen/include/asm-x86/percpu.h
+++ b/xen/include/asm-x86/percpu.h
@@ -20,4 +20,10 @@ void percpu_init_areas(void);
 
 #define DECLARE_PER_CPU(type, name) extern __typeof__(type) per_cpu__##name
 
+#define __get_cpu_ptr(var) \
+(*RELOC_HIDE(var, get_cpu_info()->per_cpu_offset))
+
+#define per_cpu_ptr(var, cpu)  \
+(*RELOC_HIDE(var, __per_cpu_offset[cpu]))
+
 #endif /* __X86_PERCPU_H__ */
diff --git a/xen/include/xen/percpu.h b/xen/include/xen/percpu.h
index abe0b11..c896863 100644
--- a/xen/include/xen/percpu.h
+++ b/xen/include/xen/percpu.h
@@ -16,6 +16,10 @@
 /* Preferred on Xen. Also see arch-defined per_cpu(). */
 #define this_cpu(var)__get_cpu_var(var)
 
+#define this_cpu_ptr(ptr)__get_cpu_ptr(ptr)
+
+#define get_per_cpu_var(var)  (per_cpu__##var)
+
 /* Linux compatibility. */
 #define get_cpu_var(var) this_cpu(var)
 #define put_cpu_var(var)
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index fb0438e..f929f1b 100644
--- a/xen/include/xen/spinlock.h
+++ 

Re: [Xen-devel] [PATCH v2] blkif.h: document blkif multi-queue/ring extension

[Konrad Rzeszutek Wilk]

On Fri, Oct 30, 2015 at 07:24:27AM +0800, Bob Liu wrote:
> Document the multi-queue/ring feature in terms of XenStore keys to be written
> by the backend and by the frontend.
> 
> Signed-off-by: Bob Liu 

Reviewed-by: Konrad Rzeszutek Wilk 
> --
> v2: Comments from Konrad
> ---
>  xen/include/public/io/blkif.h |   48 
> +
>  1 file changed, 48 insertions(+)
> 
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index 8f0f9a6..fbc9ddb 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -394,6 +394,54 @@
>   */
>  
>  /*
> + * Multiple hardware queues/rings:
> + * If supported, the backend will write the key "multi-queue-max-queues" to
> + * the directory for that vbd, and set its value to the maximum supported
> + * number of queues.
> + * Frontends that are aware of this feature and wish to use it can write the
> + * key "multi-queue-num-queues" with the number they wish to use, which must 
> be
> + * greater than zero, and no more than the value reported by the backend in
> + * "multi-queue-max-queues".
> + *
> + * For frontends requesting just one queue, the usual event-channel and
> + * ring-ref keys are written as before, simplifying the backend processing
> + * to avoid distinguishing between a frontend that doesn't understand the
> + * multi-queue feature, and one that does, but requested only one queue.
> + *
> + * Frontends requesting two or more queues must not write the toplevel
> + * event-channel and ring-ref keys, instead writing those keys under sub-keys
> + * having the name "queue-N" where N is the integer ID of the queue/ring for
> + * which those keys belong. Queues are indexed from zero.
> + * For example, a frontend with two queues must write the following set of
> + * queue-related keys:
> + *
> + * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
> + * /local/domain/1/device/vbd/0/queue-0 = ""
> + * /local/domain/1/device/vbd/0/queue-0/ring-ref = ""
> + * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
> + * /local/domain/1/device/vbd/0/queue-1 = ""
> + * /local/domain/1/device/vbd/0/queue-1/ring-ref = ""
> + * /local/domain/1/device/vbd/0/queue-1/event-channel = ""
> + *
> + * It is also possible to use multiple queues/rings together with
> + * feature multi-page ring buffer.
> + * For example, a frontend requests two queues/rings and the size of each 
> ring
> + * buffer is two pages must write the following set of related keys:
> + *
> + * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
> + * /local/domain/1/device/vbd/0/ring-page-order = "1"
> + * /local/domain/1/device/vbd/0/queue-0 = ""
> + * /local/domain/1/device/vbd/0/queue-0/ring-ref0 = ""
> + * /local/domain/1/device/vbd/0/queue-0/ring-ref1 = ""
> + * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
> + * /local/domain/1/device/vbd/0/queue-1 = ""
> + * /local/domain/1/device/vbd/0/queue-1/ring-ref0 = ""
> + * /local/domain/1/device/vbd/0/queue-1/ring-ref1 = ""
> + * /local/domain/1/device/vbd/0/queue-1/event-channel = ""
> + *
> + */
> +
> +/*
>   * STATE DIAGRAMS
>   *
>   
> *
> -- 
> 1.7.10.4
> 

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

[Xen-devel] [PATCH v2 3/3] xen/x86: Cleanup of early cpuid handling

[Andrew Cooper]

Use register names for variables, rather than their content for leaf 1.
Reduce the number of cpuid instructions issued.  Also drop some trailing
whitespace.

No functional change.

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

v2: Record the correct registers for the 0x8001 feature leaves
---
 xen/arch/x86/cpu/common.c | 68 +++
 1 file changed, 33 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index ac8a258..a111ed6 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -180,7 +180,7 @@ static inline u32 phys_pkg_id(u32 cpuid_apic, int index_msb)
 static void __init early_cpu_detect(void)
 {
struct cpuinfo_x86 *c = _cpu_data;
-   u32 cap4, tfms, cap0, misc;
+   u32 eax, ebx, ecx, edx;
 
c->x86_cache_alignment = 32;
 
@@ -192,21 +192,21 @@ static void __init early_cpu_detect(void)
 
c->x86_vendor = get_cpu_vendor(c->x86_vendor_id, gcv_host_early);
 
-   cpuid(0x0001, , , , );
-   c->x86 = (tfms >> 8) & 15;
-   c->x86_model = (tfms >> 4) & 15;
+   cpuid(0x0001, , , , );
+   c->x86 = (eax >> 8) & 15;
+   c->x86_model = (eax >> 4) & 15;
if (c->x86 == 0xf)
-   c->x86 += (tfms >> 20) & 0xff;
+   c->x86 += (eax >> 20) & 0xff;
if (c->x86 >= 0x6)
-   c->x86_model += ((tfms >> 16) & 0xF) << 4;
-   c->x86_mask = tfms & 15;
-   cap0 &= ~cleared_caps[cpufeat_word(X86_FEATURE_FPU)];
-   cap4 &= ~cleared_caps[cpufeat_word(X86_FEATURE_XMM3)];
-   if (cap0 & cpufeat_mask(X86_FEATURE_CLFLSH))
-   c->x86_cache_alignment = ((misc >> 8) & 0xff) * 8;
+   c->x86_model += ((eax >> 16) & 0xF) << 4;
+   c->x86_mask = eax & 15;
+   edx &= ~cleared_caps[cpufeat_word(X86_FEATURE_FPU)];
+   ecx &= ~cleared_caps[cpufeat_word(X86_FEATURE_XMM3)];
+   if (edx & cpufeat_mask(X86_FEATURE_CLFLSH))
+   c->x86_cache_alignment = ((ebx >> 8) & 0xff) * 8;
/* Leaf 0x1 capabilities filled in early for Xen. */
-   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = cap0;
-   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = cap4;
+   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
+   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = ecx;
 
if ( cpuid_eax(0x8000) >= 0x8008 )
paddr_bits = cpuid_eax(0x8008) & 0xff;
@@ -214,29 +214,29 @@ static void __init early_cpu_detect(void)
 
 static void __cpuinit generic_identify(struct cpuinfo_x86 *c)
 {
-   u32 tfms, capability, excap, ebx;
+   u32 eax, ebx, ecx, edx, tmp;
 
/* Get vendor name */
cpuid(0x, >cpuid_level,
  (int *)>x86_vendor_id[0],
  (int *)>x86_vendor_id[8],
  (int *)>x86_vendor_id[4]);
-   
+
c->x86_vendor = get_cpu_vendor(c->x86_vendor_id, gcv_host_late);
/* Initialize the standard set of capabilities */
/* Note that the vendor-specific code below might override */
-   
+
/* Intel-defined flags: level 0x0001 */
-   cpuid(0x0001, , , , );
-   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = capability;
-   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = excap;
-   c->x86 = (tfms >> 8) & 15;
-   c->x86_model = (tfms >> 4) & 15;
+   cpuid(0x0001, , , , );
+   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
+   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = ecx;
+   c->x86 = (eax >> 8) & 15;
+   c->x86_model = (eax >> 4) & 15;
if (c->x86 == 0xf)
-   c->x86 += (tfms >> 20) & 0xff;
+   c->x86 += (eax >> 20) & 0xff;
if (c->x86 >= 0x6)
-   c->x86_model += ((tfms >> 16) & 0xF) << 4;
-   c->x86_mask = tfms & 15;
+   c->x86_model += ((eax >> 16) & 0xF) << 4;
+   c->x86_mask = eax & 15;
c->apicid = phys_pkg_id((ebx >> 24) & 0xFF, 0);
c->phys_proc_id = c->apicid;
if ( cpu_has(c, X86_FEATURE_CLFLSH) )
@@ -249,12 +249,11 @@ static void __cpuinit generic_identify(struct cpuinfo_x86 
*c)
/* AMD-defined flags: level 0x8001 */
c->extended_cpuid_level = cpuid_eax(0x8000);
if ( (c->extended_cpuid_level & 0x) == 0x8000 ) {
-   if ( c->extended_cpuid_level >= 0x8001 ) {
-   c->x86_capability[cpufeat_word(X86_FEATURE_SYSCALL)]
-   = cpuid_edx(0x8001);
-   c->x86_capability[cpufeat_word(X86_FEATURE_LAHF_LM)]
-   = cpuid_ecx(0x8001);
-   }
+   if ( c->extended_cpuid_level >= 0x8001 )
+   cpuid(0x8001, , ,
+ 
>x86_capability[cpufeat_word(X86_FEATURE_LAHF_LM)],
+   

Re: [Xen-devel] [PATCH v2] tools/hotplug: xendomains.service conflicts with libvirt

[Ian Campbell]

On Thu, 2015-10-29 at 11:26 +, Wei Liu wrote:
> On Thu, Oct 29, 2015 at 11:02:54AM +, Olaf Hering wrote:
> > xendomains will manage guests behind libvirts back:
> > - libvirt starts a guest
> > - that guest can be "managed" by libvirt and xl at the same time
> > - when xendomains runs on shutdown it will save the guest using xl
> >   libvirt does not know about this
> > - when xendomains runs on boot it will restore the saved guest using xl
> >   libvirt does not know about this, it will just fail to manage the
> >   restored guest
> > 
> > To prevent xendomains from interfering with libvirt add a Conflicts= to
> > xendomains.service. It will cause libvirt to be stopped if xendomains
> > is
> > started manually with 'systemctl start'
> 
> Missing period at the end.

Fixed and committed with your ack.


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

Re: [Xen-devel] [PATCH] tools: create XEN_DUMP_DIR with mode 0700

[Ian Campbell]

On Thu, 2015-10-22 at 17:32 +0100, Ian Campbell wrote:
> On Wed, 2015-10-21 at 15:15 +0100, Wei Liu wrote:
> > That directory is used to store guest memory dump which contains
> > sensitive information.
> > 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Ian Campbell 

Applied.

> Have you audited all the paths we create and determined that this is the
> only one which needs adjusting in this way?
> 
> OOI, what lead you to be concerned about the permissions on the
> directories
> we are creating (first the xenpaging one, now this)?

Thanks for your reply to this bit.

Ian.

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

Re: [Xen-devel] [PATCH] MAINTAINERS: adding myself as co-maintainer of vTPM

[Ian Campbell]

On Fri, 2015-10-30 at 18:57 -0400, Daniel De Graaf wrote:
> On 10/10/15 12:26, Quan Xu wrote:
> > Signed-off-by: Quan Xu 
> Acked-by: Daniel De Graaf 

Applied, thanks.

Ian

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

Re: [Xen-devel] [PATCH v10 2/5] missing include in cputime.c, remove #ifdef CONFIG_PARAVIRT from sched/core.c

[Stefano Stabellini]

On Wed, 4 Nov 2015, kbuild test robot wrote:
> Hi Stefano,
> 
> [auto build test ERROR on arm64/for-next/core]
> [cannot apply to: xen-tip/linux-next]
> [also ERROR on: v4.3 next-20151103]
> 
> url:
> https://github.com/0day-ci/linux/commits/Stefano-Stabellini/xen-arm-arm64-CONFIG_PARAVIRT-and-stolen-ticks-accounting/20151104-002433
> base:   https://github.com/0day-ci/linux 
> Stefano-Stabellini/xen-arm-arm64-CONFIG_PARAVIRT-and-stolen-ticks-accounting/20151104-002433
> config: mips-jz4740 (attached as .config)

Ah, of course! I only tested x86, arm and arm64, but this wouldn't work
on any arches without arm/paravirt.h. Damn.

I guess we'll have to keep

#ifdef CONFIG_PARAVIRT
#include 
#endif


BTW this auto build test is awesome.

> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=mips 
> 
> All errors (new ones prefixed by >>):
> 
> >> kernel/sched/core.c:82:26: fatal error: asm/paravirt.h: No such file or 
> >> directory
>compilation terminated.
> --
> >> kernel/sched/cputime.c:8:26: fatal error: asm/paravirt.h: No such file or 
> >> directory
>compilation terminated.
> 
> vim +82 kernel/sched/core.c
> 
> 52f5684c kernel/sched/core.c Gideon Israel Dsouza  2014-04-07  76  #include 
> 
> ^1da177e kernel/sched.c  Linus Torvalds2005-04-16  77  
> 96f951ed kernel/sched/core.c David Howells 2012-03-28  78  #include 
> 
> 5517d86b kernel/sched.c  Eric Dumazet  2007-05-08  79  #include 
> 
> 838225b4 kernel/sched.c  Satyam Sharma 2007-10-24  80  #include 
> 
> db7e527d kernel/sched/core.c Christian Borntraeger 2012-01-11  81  #include 
> 
> e6e6685a kernel/sched.c  Glauber Costa 2011-07-11 @82  #include 
> 
> ^1da177e kernel/sched.c  Linus Torvalds2005-04-16  83  
> 029632fb kernel/sched.c  Peter Zijlstra2011-10-25  84  #include 
> "sched.h"
> ea138446 kernel/sched/core.c Tejun Heo 2013-01-18  85  #include 
> "../workqueue_internal.h"
> 
> :: The code at line 82 was first introduced by commit
> :: e6e6685accfa81f509fadfc9624bc7c3862d75c4 KVM guest: Steal time 
> accounting
> 
> :: TO: Glauber Costa <glom...@redhat.com>
> :: CC: Avi Kivity <a...@redhat.com>
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

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

[Xen-devel] [PATCH v1 01/11] xsplice: Design document (v2).

[Ross Lagerwall]

From: Konrad Rzeszutek Wilk 

A mechanism is required to binarily patch the running hypervisor with new
opcodes that have come about due to primarily security updates.

This document describes the design of the API that would allow us to
upload to the hypervisor binary patches.

This document has been shaped by the input from:
  Martin Pohlack 
  Jan Beulich 

Thank you!

Input-from: Martin Pohlack 
Input-from: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ross Lagerwall 
---
 docs/misc/xsplice.markdown | 999 +
 1 file changed, 999 insertions(+)
 create mode 100644 docs/misc/xsplice.markdown

diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
new file mode 100644
index 000..501056e
--- /dev/null
+++ b/docs/misc/xsplice.markdown
@@ -0,0 +1,999 @@
+# xSplice Design v1
+
+## Rationale
+
+A mechanism is required to binarily patch the running hypervisor with new
+opcodes that have come about due to primarily security updates.
+
+This document describes the design of the API that would allow us to
+upload to the hypervisor binary patches.
+
+The document is split in four sections:
+
+ * Detailed descriptions of the problem statement.
+ * Design of the data structures.
+ * Design of the hypercalls.
+ * Implementation notes that should be taken into consideration.
+
+
+## Glossary
+
+ * splice - patch in the binary code with new opcodes
+ * trampoline - a jump to a new instruction.
+ * payload - telemetries of the old code along with binary blob of the new
+   function (if needed).
+ * reloc - telemetries contained in the payload to construct proper trampoline.
+
+## History
+
+The document has gone under various reviews and only covers v1 design.
+
+The end of the document has a section titled `Not Yet Done` which
+outlines ideas and design for the v2 version of this work.
+
+## Multiple ways to patch
+
+The mechanism needs to be flexible to patch the hypervisor in multiple ways
+and be as simple as possible. The compiled code is contiguous in memory with
+no gaps - so we have no luxury of 'moving' existing code and must either
+insert a trampoline to the new code to be executed - or only modify in-place
+the code if there is sufficient space. The placement of new code has to be done
+by hypervisor and the virtual address for the new code is allocated 
dynamically.
+
+This implies that the hypervisor must compute the new offsets when splicing
+in the new trampoline code. Where the trampoline is added (inside
+the function we are patching or just the callers?) is also important.
+
+To lessen the amount of code in hypervisor, the consumer of the API
+is responsible for identifying which mechanism to employ and how many locations
+to patch. Combinations of modifying in-place code, adding trampoline, etc
+has to be supported. The API should allow read/write any memory within
+the hypervisor virtual address space.
+
+We must also have a mechanism to query what has been applied and a mechanism
+to revert it if needed.
+
+## Workflow
+
+The expected workflows of higher-level tools that manage multiple patches
+on production machines would be:
+
+ * The first obvious task is loading all available / suggested
+   hotpatches around system start.
+ * Whenever new hotpatches are installed, they should be loaded too.
+ * One wants to query which modules have been loaded at runtime.
+ * If unloading is deemed safe (see unloading below), one may want to
+   support a workflow where a specific hotpatch is marked as bad and
+   unloaded.
+ * If we do no restrict module activation order and want to report tboot
+   state on sequences, we might have a complexity explosion problem, in
+   what system hashes should be considered acceptable.
+
+## Patching code
+
+The first mechanism to patch that comes in mind is in-place replacement.
+That is replace the affected code with new code. Unfortunately the x86
+ISA is variable size which places limits on how much space we have available
+to replace the instructions. That is not a problem if the change is smaller
+than the original opcode and we can fill it with nops. Problems will
+appear if the replacement code is longer.
+
+The second mechanism is by replacing the call or jump to the
+old function with the address of the new function.
+
+A third mechanism is to add a jump to the new function at the
+start of the old function.
+
+### Example of trampoline and in-place splicing
+
+As example we will assume the hypervisor does not have XSA-132 (see
+*domctl/sysctl: don't leak hypervisor stack to toolstacks*
+4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
+the hypervisor with it. The original code looks as so:
+
+
+   48 89 e0  mov%rsp,%rax  
+   48 25 00 80 ff ff and$0x8000,%rax  
+

[Xen-devel] [PATCH v1 03/11] libxc: Implementation of XEN_XSPLICE_op in libxc.

[Ross Lagerwall]

From: Konrad Rzeszutek Wilk 

The underlaying toolstack code to do the basic
operations when using the XEN_XSPLICE_op syscalls:
 - upload the payload,
 - get status of an payload,
 - list all the payloads,
 - apply, check, replace, and revert the payload.

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ross Lagerwall 
---
v2: Actually set zero for the _pad entries.
v3: Split status into state and error code.
Add REPLACE action.
---
 tools/libxc/include/xenctrl.h |  18 +++
 tools/libxc/xc_misc.c | 283 ++
 2 files changed, 301 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2fec1fb..b6e2fb2 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2859,6 +2859,24 @@ int xc_psr_cat_get_l3_info(xc_interface *xch, uint32_t 
socket,
bool *cdp_enabled);
 #endif
 
+int xc_xsplice_upload(xc_interface *xch,
+  char *id, char *payload, uint32_t size);
+
+int xc_xsplice_get(xc_interface *xch,
+   char *id,
+   xen_xsplice_status_t *status);
+
+int xc_xsplice_list(xc_interface *xch, unsigned int max, unsigned int start,
+xen_xsplice_status_t *info, char *id,
+uint32_t *len, unsigned int *done,
+unsigned int *left);
+
+int xc_xsplice_apply(xc_interface *xch, char *id);
+int xc_xsplice_revert(xc_interface *xch, char *id);
+int xc_xsplice_unload(xc_interface *xch, char *id);
+int xc_xsplice_check(xc_interface *xch, char *id);
+int xc_xsplice_replace(xc_interface *xch, char *id);
+
 #endif /* XENCTRL_H */
 
 /*
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index c613545..6e6ffc0 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -718,6 +718,289 @@ int xc_hvm_inject_trap(
 return rc;
 }
 
+int xc_xsplice_upload(xc_interface *xch,
+  char *id,
+  char *payload,
+  uint32_t size)
+{
+int rc;
+DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(payload, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(id, 0 /* adjust later */, 
XC_HYPERCALL_BUFFER_BOUNCE_IN);
+ssize_t len;
+
+if ( !id || !payload )
+return -1;
+
+len = strlen(id);
+if ( len > XEN_XSPLICE_NAME_SIZE )
+return -1;
+
+HYPERCALL_BOUNCE_SET_SIZE(id, len);
+
+if ( xc_hypercall_bounce_pre(xch, id) )
+return -1;
+
+if ( xc_hypercall_bounce_pre(xch, payload) )
+return -1;
+
+sysctl.cmd = XEN_SYSCTL_xsplice_op;
+sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_UPLOAD;
+sysctl.u.xsplice.u.upload.size = size;
+set_xen_guest_handle(sysctl.u.xsplice.u.upload.payload, payload);
+
+sysctl.u.xsplice.u.upload.id.size = len;
+sysctl.u.xsplice.u.upload.id.pad = 0;
+set_xen_guest_handle(sysctl.u.xsplice.u.upload.id.name, id);
+
+rc = do_sysctl(xch, );
+
+xc_hypercall_bounce_post(xch, payload);
+xc_hypercall_bounce_post(xch, id);
+
+return rc;
+}
+
+int xc_xsplice_get(xc_interface *xch,
+   char *id,
+   xen_xsplice_status_t *status)
+{
+int rc;
+DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(id, 0 /*adjust later */, 
XC_HYPERCALL_BUFFER_BOUNCE_IN);
+ssize_t len;
+
+if ( !id )
+return -1;
+
+len = strlen(id);
+if ( len > XEN_XSPLICE_NAME_SIZE )
+return -1;
+
+HYPERCALL_BOUNCE_SET_SIZE(id, len);
+
+if ( xc_hypercall_bounce_pre(xch, id) )
+return -1;
+
+sysctl.cmd = XEN_SYSCTL_xsplice_op;
+sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_GET;
+
+sysctl.u.xsplice.u.get.status.state = 0;
+sysctl.u.xsplice.u.get.status.rc = 0;
+
+sysctl.u.xsplice.u.get.id.size = len;
+sysctl.u.xsplice.u.get.id.pad = 0;
+set_xen_guest_handle(sysctl.u.xsplice.u.get.id.name, id);
+
+rc = do_sysctl(xch, );
+
+xc_hypercall_bounce_post(xch, id);
+
+memcpy(status, , sizeof(*status));
+
+return rc;
+}
+
+int xc_xsplice_list(xc_interface *xch, unsigned int max, unsigned int start,
+xen_xsplice_status_t *info,
+char *id, uint32_t *len,
+unsigned int *done,
+unsigned int *left)
+{
+int rc;
+DECLARE_SYSCTL;
+DECLARE_HYPERCALL_BOUNCE(info, 0 /* adjust later. */, 
XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(id, 0 /* adjust later. */, 
XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+DECLARE_HYPERCALL_BOUNCE(len, 0 /* adjust later. */, 
XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+uint32_t max_batch_sz, nr;
+uint32_t version = 0, retries = 0;
+uint32_t adjust = 0;
+
+if ( !max || !info || !id || !len )
+return -1;
+
+sysctl.cmd = XEN_SYSCTL_xsplice_op;
+sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_LIST;
+

[Xen-devel] [PATCH v1 04/11] xen-xsplice: Tool to manipulate xsplice payloads.

[Ross Lagerwall]

From: Konrad Rzeszutek Wilk 

A simple tool that allows an system admin to perform
basic xsplice operations:

 - Upload a xsplice file (with an unique id)
 - List all the xsplice payloads loaded.
 - Apply, revert, replace, unload, or check the payload using the
   unique id.
 - Do all three - upload, check, and apply the
   payload in one go (all).

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ross Lagerwall 
---
v2:
 - Removed REVERTED state.
 - Fixed bugs handling XSPLICE_STATUS_PROGRESS.
 - Split status into state and error.
   Add REPLACE action.
---
 .gitignore   |   1 +
 tools/misc/Makefile  |   4 +
 tools/misc/xen-xsplice.c | 439 +++
 3 files changed, 444 insertions(+)
 create mode 100644 tools/misc/xen-xsplice.c

diff --git a/.gitignore b/.gitignore
index 91e1430..02d5c4a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -168,6 +168,7 @@ tools/misc/xc_shadow
 tools/misc/xen_cpuperf
 tools/misc/xen-detect
 tools/misc/xen-tmem-list-parse
+tools/misc/xen-xsplice
 tools/misc/xenperf
 tools/misc/xenpm
 tools/misc/xen-hvmctx
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index c4490f3..c46873e 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -30,6 +30,7 @@ INSTALL_SBIN   += xenlockprof
 INSTALL_SBIN   += xenperf
 INSTALL_SBIN   += xenpm
 INSTALL_SBIN   += xenwatchdogd
+INSTALL_SBIN   += xen-xsplice
 INSTALL_SBIN += $(INSTALL_SBIN-y)
 
 # Everything to be installed in a private bin/
@@ -98,6 +99,9 @@ xen-mfndump: xen-mfndump.o
 xenwatchdogd: xenwatchdogd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+xen-xsplice: xen-xsplice.o
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) 
$(APPEND_LDFLAGS)
 
diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
new file mode 100644
index 000..a208aa4
--- /dev/null
+++ b/tools/misc/xen-xsplice.c
@@ -0,0 +1,439 @@
+/*
+ * Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+static xc_interface *xch;
+
+void show_help(void)
+{
+fprintf(stderr,
+"xen-xsplice: Xsplice test tool\n"
+"Usage: xen-xsplice  [args]\n"
+"  An unique name of payload. Up to %d characters.\n"
+"Commands:\n"
+"  help display this help\n"
+"  upload upload file  with  name\n"
+"  list list payloads uploaded.\n"
+"  applyapply  patch.\n"
+"  revert   revert id  patch.\n"
+"  replace  apply  patch and revert all others.\n"
+"  unload   unload id  patch.\n"
+"  checkcheck id  patch.\n"
+"  allupload, check and apply .\n",
+XEN_XSPLICE_NAME_SIZE);
+}
+
+/* wrapper function */
+static int help_func(int argc, char *argv[])
+{
+show_help();
+return 0;
+}
+
+#define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))
+
+static const char *state2str(long state)
+{
+#define STATE(x) [XSPLICE_STATE_##x] = #x
+static const char *const names[] = {
+STATE(LOADED),
+STATE(CHECKED),
+STATE(APPLIED),
+};
+#undef STATE
+if (state >= ARRAY_SIZE(names))
+return "unknown";
+
+if (state < 0)
+return "-EXX";
+
+if (!names[state])
+return "unknown";
+
+return names[state];
+}
+
+#define MAX_LEN 11
+static int list_func(int argc, char *argv[])
+{
+unsigned int idx, done, left, i;
+xen_xsplice_status_t *info = NULL;
+char *id = NULL;
+uint32_t *len = NULL;
+int rc = ENOMEM;
+
+if ( argc )
+{
+show_help();
+return -1;
+}
+idx = left = 0;
+info = malloc(sizeof(*info) * MAX_LEN);
+if ( !info )
+goto out;
+id = malloc(sizeof(*id) * XEN_XSPLICE_NAME_SIZE * MAX_LEN);
+if ( !id )
+goto out;
+len = malloc(sizeof(*len) * MAX_LEN);
+if ( !len )
+goto out;
+
+fprintf(stdout," ID | status\n"
+   "+\n");
+do {
+done = 0;
+memset(info, 'A', sizeof(*info) * MAX_LEN); /* Optional. */
+memset(id, 'i', sizeof(*id) * MAX_LEN * XEN_XSPLICE_NAME_SIZE); /* 
Optional. */
+memset(len, 'l', sizeof(*len) * MAX_LEN); /* Optional. */
+rc = xc_xsplice_list(xch, MAX_LEN, idx, info, id, len, , );
+if ( rc )
+{
+fprintf(stderr, "Failed to list %d/%d: %d(%s)!\n", idx, left, 
errno, strerror(errno));
+

[Xen-devel] [PATCH v1 02/11] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

[Ross Lagerwall]

From: Konrad Rzeszutek Wilk 

The implementation does not actually do any patching.

It just adds the framework for doing the hypercalls,
keeping track of ELF payloads, and the basic operations:
 - query which payloads exist,
 - query for specific payloads,
 - check*1, apply*1, replace*1, and unload payloads.

*1: Which of course in this patch are nops.

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ross Lagerwall 
---
v2: Rebased on keyhandler: rework keyhandler infrastructure
v3: Fixed XSM.
v4: Removed REVERTED state.
Split status and error code.
Add REPLACE action.
Separate payload data from the payload structure.
s/XSPLICE_ID_../XSPLICE_NAME_../
---
 tools/flask/policy/policy/modules/xen/xen.te |   1 +
 xen/common/Makefile  |   1 +
 xen/common/sysctl.c  |   6 +
 xen/common/xsplice.c | 398 +++
 xen/include/public/sysctl.h  | 157 +++
 xen/include/xen/xsplice.h|   9 +
 xen/xsm/flask/hooks.c|   4 +
 xen/xsm/flask/policy/access_vectors  |   2 +
 8 files changed, 578 insertions(+)
 create mode 100644 xen/common/xsplice.c
 create mode 100644 xen/include/xen/xsplice.h

diff --git a/tools/flask/policy/policy/modules/xen/xen.te 
b/tools/flask/policy/policy/modules/xen/xen.te
index d35ae22..542c3e1 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -72,6 +72,7 @@ allow dom0_t xen_t:xen2 {
 allow dom0_t xen_t:xen2 {
 pmu_ctrl
 get_symbol
+xsplice_op
 };
 allow dom0_t xen_t:mmu memorymap;
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index a7829db..1b17c9d 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -56,6 +56,7 @@ obj-y += vmap.o
 obj-y += vsprintf.o
 obj-y += wait.o
 obj-y += xmalloc_tlsf.o
+obj-y += xsplice.o
 
 obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo 
unlz4 earlycpio,$(n).init.o)
 
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 85e853f..517d684 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
 {
@@ -460,6 +461,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 ret = tmem_control(>u.tmem_op);
 break;
 
+case XEN_SYSCTL_xsplice_op:
+ret = xsplice_control(>u.xsplice);
+copyback = 1;
+break;
+
 default:
 ret = arch_do_sysctl(op, u_sysctl);
 copyback = 0;
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
new file mode 100644
index 000..d984c8a
--- /dev/null
+++ b/xen/common/xsplice.c
@@ -0,0 +1,398 @@
+/*
+ * Copyright (c) 2015 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static DEFINE_SPINLOCK(payload_list_lock);
+static LIST_HEAD(payload_list);
+
+static unsigned int payload_cnt;
+static unsigned int payload_version = 1;
+
+struct payload {
+int32_t state; /* One of XSPLICE_STATE_*. */
+int32_t rc; /* 0 or -EXX. */
+
+struct list_head   list;   /* Linked to 'payload_list'. */
+
+char  id[XEN_XSPLICE_NAME_SIZE + 1];  /* Name of it. */
+};
+
+static const char *state2str(int32_t state)
+{
+#define STATE(x) [XSPLICE_STATE_##x] = #x
+static const char *const names[] = {
+STATE(LOADED),
+STATE(CHECKED),
+STATE(APPLIED),
+};
+#undef STATE
+
+if (state >= ARRAY_SIZE(names))
+return "unknown";
+
+if (state < 0)
+return "-EXX";
+
+if (!names[state])
+return "unknown";
+
+return names[state];
+}
+
+void xsplice_printall(unsigned char key)
+{
+struct payload *data;
+
+spin_lock(_list_lock);
+
+list_for_each_entry ( data, _list, list )
+{
+printk(" id=%s state=%s(%d): \n", data->id,
+   state2str(data->state), data->state);
+}
+spin_unlock(_list_lock);
+}
+
+static int verify_id(xen_xsplice_id_t *id)
+{
+if ( id->size == 0 || id->size > XEN_XSPLICE_NAME_SIZE )
+return -EINVAL;
+
+if ( id->pad != 0 )
+return -EINVAL;
+
+if ( !guest_handle_okay(id->name, id->size) )
+return -EINVAL;
+
+return 0;
+}
+
+int find_payload(xen_xsplice_id_t *id, bool_t need_lock, struct payload **f)
+{
+struct payload *data;
+XEN_GUEST_HANDLE_PARAM(char) str;
+char name[XEN_XSPLICE_NAME_SIZE + 1] = { 0 }; /* 128 + 1 bytes on stack. 
Perhaps kzalloc? */
+int rc = -EINVAL;
+
+rc = verify_id(id);
+if ( rc )
+return rc;
+
+str = guest_handle_cast(id->name, char);
+if ( copy_from_guest(name, str, id->size) )
+return 

[Xen-devel] [PATCH v1 07/11] xsplice: Implement payload loading

[Ross Lagerwall]

Add support for loading xsplice payloads. This is somewhat similar to
the Linux kernel module loader, implementing the following steps:
- Verify the elf file.
- Parse the elf file.
- Allocate a region of memory mapped within a free area of
  [xen_virt_end, XEN_VIRT_END].
- Copy allocated sections into the new region.
- Resolve section symbols. All other symbols must be absolute addresses.
- Perform relocations.
- Process xsplice specific sections.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/xsplice.c|  23 
 xen/arch/x86/Makefile |   1 +
 xen/arch/x86/setup.c  |   7 +
 xen/arch/x86/xsplice.c|  90 
 xen/common/xsplice.c  | 282 ++
 xen/include/asm-x86/x86_64/page.h |   2 +
 xen/include/xen/xsplice.h |  22 +++
 8 files changed, 428 insertions(+)
 create mode 100644 xen/arch/arm/xsplice.c
 create mode 100644 xen/arch/x86/xsplice.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1ef39f7..f785c07 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -39,6 +39,7 @@ obj-y += device.o
 obj-y += decode.o
 obj-y += processor.o
 obj-y += smc.o
+obj-y += xsplice.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/xsplice.c b/xen/arch/arm/xsplice.c
new file mode 100644
index 000..8d85fa9
--- /dev/null
+++ b/xen/arch/arm/xsplice.c
@@ -0,0 +1,23 @@
+#include 
+#include 
+#include 
+#include 
+
+int xsplice_verify_elf(uint8_t *data, ssize_t len)
+{
+return -ENOSYS;
+}
+
+int xsplice_perform_rel(struct xsplice_elf *elf,
+struct xsplice_elf_sec *base,
+struct xsplice_elf_sec *rela)
+{
+return -ENOSYS;
+}
+
+int xsplice_perform_rela(struct xsplice_elf *elf,
+ struct xsplice_elf_sec *base,
+ struct xsplice_elf_sec *rela)
+{
+return -ENOSYS;
+}
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 39a8059..6e05532 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -61,6 +61,7 @@ obj-y += x86_emulate.o
 obj-y += tboot.o
 obj-y += hpet.o
 obj-y += vm_event.o
+obj-y += xsplice.o
 obj-y += xstate.o
 
 obj-$(crash_debug) += gdbstub.o
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 4ed0110..a79c5e3 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -99,6 +99,9 @@ unsigned long __read_mostly xen_phys_start;
 
 unsigned long __read_mostly xen_virt_end;
 
+unsigned long __read_mostly module_virt_start;
+unsigned long __read_mostly module_virt_end;
+
 DEFINE_PER_CPU(struct tss_struct, init_tss);
 
 char __section(".bss.stack_aligned") cpu0_stack[STACK_SIZE];
@@ -1145,6 +1148,10 @@ void __init noreturn __start_xen(unsigned long mbi_p)
~((1UL << L2_PAGETABLE_SHIFT) - 1);
 destroy_xen_mappings(xen_virt_end, XEN_VIRT_START + BOOTSTRAP_MAP_BASE);
 
+module_virt_start = xen_virt_end;
+module_virt_end = XEN_VIRT_END - NR_CPUS * PAGE_SIZE;
+BUG_ON(module_virt_end <= module_virt_start);
+
 memguard_init();
 
 nr_pages = 0;
diff --git a/xen/arch/x86/xsplice.c b/xen/arch/x86/xsplice.c
new file mode 100644
index 000..dbff0d5
--- /dev/null
+++ b/xen/arch/x86/xsplice.c
@@ -0,0 +1,90 @@
+#include 
+#include 
+#include 
+#include 
+
+int xsplice_verify_elf(uint8_t *data, ssize_t len)
+{
+
+Elf64_Ehdr *hdr = (Elf64_Ehdr *)data;
+
+if ( len < (sizeof *hdr) ||
+ !IS_ELF(*hdr) ||
+ hdr->e_ident[EI_CLASS] != ELFCLASS64 ||
+ hdr->e_ident[EI_DATA] != ELFDATA2LSB ||
+ hdr->e_machine != EM_X86_64 )
+{
+printk(XENLOG_ERR "Invalid ELF file\n");
+return -EINVAL;
+}
+
+return 0;
+}
+
+int xsplice_perform_rel(struct xsplice_elf *elf,
+struct xsplice_elf_sec *base,
+struct xsplice_elf_sec *rela)
+{
+printk(XENLOG_ERR "SHT_REL relocation unsupported\n");
+return -ENOSYS;
+}
+
+int xsplice_perform_rela(struct xsplice_elf *elf,
+ struct xsplice_elf_sec *base,
+ struct xsplice_elf_sec *rela)
+{
+Elf64_Rela *r;
+int symndx, i;
+uint64_t val;
+uint8_t *dest;
+
+for ( i = 0; i < (rela->sec->sh_size / rela->sec->sh_entsize); i++ )
+{
+r = (Elf64_Rela *)(rela->data + i * rela->sec->sh_entsize);
+symndx = ELF64_R_SYM(r->r_info);
+dest = base->load_addr + r->r_offset;
+val = r->r_addend + elf->sym[symndx].sym->st_value;
+
+switch ( ELF64_R_TYPE(r->r_info) )
+{
+case R_X86_64_NONE:
+break;
+case R_X86_64_64:
+*(uint64_t *)dest = val;
+break;
+case R_X86_64_32:
+*(uint32_t *)dest = val;
+if (val != *(uint32_t *)dest)
+goto overflow;
+break;
+case 

[Xen-devel] [PATCH v1 09/11] xsplice: Add support for bug frames

[Ross Lagerwall]

Add support for handling bug frames contained with xsplice modules. If a
trap occurs search either the kernel bug table or an applied module's
bug table depending on the instruction pointer.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/traps.c  |  30 -
 xen/common/symbols.c  |   7 +++
 xen/common/xsplice.c  | 107 +-
 xen/include/xen/kernel.h  |   1 +
 xen/include/xen/xsplice.h |   4 ++
 5 files changed, 129 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index b32f696..cd51cfd 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -48,6 +48,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1076,20 +1077,29 @@ void do_invalid_op(struct cpu_user_regs *regs)
 return;
 }
 
-if ( !is_active_kernel_text(regs->eip) ||
+if ( !is_active_text(regs->eip) ||
  __copy_from_user(bug_insn, eip, sizeof(bug_insn)) ||
  memcmp(bug_insn, "\xf\xb", sizeof(bug_insn)) )
 goto die;
 
-for ( bug = __start_bug_frames, id = 0; stop_frames[id]; ++bug )
+if ( likely(is_active_kernel_text(regs->eip)) )
 {
-while ( unlikely(bug == stop_frames[id]) )
-++id;
-if ( bug_loc(bug) == eip )
-break;
+for ( bug = __start_bug_frames, id = 0; stop_frames[id]; ++bug )
+{
+while ( unlikely(bug == stop_frames[id]) )
+++id;
+if ( bug_loc(bug) == eip )
+break;
+}
+if ( !stop_frames[id] )
+goto die;
+}
+else
+{
+bug = xsplice_find_bug(eip, );
+if ( !bug )
+goto die;
 }
-if ( !stop_frames[id] )
-goto die;
 
 eip += sizeof(bug_insn);
 if ( id == BUGFRAME_run_fn )
@@ -1103,7 +1113,7 @@ void do_invalid_op(struct cpu_user_regs *regs)
 
 /* WARN, BUG or ASSERT: decode the filename pointer and line number. */
 filename = bug_ptr(bug);
-if ( !is_kernel(filename) )
+if ( !is_kernel(filename) && !is_module(filename) )
 goto die;
 fixup = strlen(filename);
 if ( fixup > 50 )
@@ -1130,7 +1140,7 @@ void do_invalid_op(struct cpu_user_regs *regs)
 case BUGFRAME_assert:
 /* ASSERT: decode the predicate string pointer. */
 predicate = bug_msg(bug);
-if ( !is_kernel(predicate) )
+if ( !is_kernel(predicate) && !is_module(predicate) )
 predicate = "";
 
 printk("Assertion '%s' failed at %s%s:%d\n",
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index a59c59d..bf5623f 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -101,6 +102,12 @@ bool_t is_active_kernel_text(unsigned long addr)
 (system_state < SYS_STATE_active && is_kernel_inittext(addr)));
 }
 
+bool_t is_active_text(unsigned long addr)
+{
+return is_active_kernel_text(addr) ||
+   is_active_module_text(addr);
+}
+
 const char *symbols_lookup(unsigned long addr,
unsigned long *symbolsize,
unsigned long *offset,
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 4476be5..982954b 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -40,6 +40,11 @@ struct payload {
 int nfuncs;
 void *module_address;
 size_t module_pages;
+size_t core_size;
+size_t core_text_size;
+
+struct bug_frame *start_bug_frames[4];
+struct bug_frame *stop_bug_frames[4];
 
 char  id[XEN_XSPLICE_NAME_SIZE + 1];  /* Name of it. */
 };
@@ -525,26 +530,27 @@ static void free_module(struct payload *payload)
 payload->module_pages = 0;
 }
 
-static void alloc_section(struct xsplice_elf_sec *sec, size_t *core_size)
+static void alloc_section(struct xsplice_elf_sec *sec, size_t *size)
 {
-size_t align_size = ROUNDUP(*core_size, sec->sec->sh_addralign);
+size_t align_size = ROUNDUP(*size, sec->sec->sh_addralign);
 sec->sec->sh_entsize = align_size;
-*core_size = sec->sec->sh_size + align_size;
+*size = sec->sec->sh_size + align_size;
 }
 
 static int move_module(struct payload *payload, struct xsplice_elf *elf)
 {
 uint8_t *buf;
 int i;
-size_t core_size = 0;
+size_t size = 0;
 
 /* Allocate text regions */
 for ( i = 0; i < elf->hdr->e_shnum; i++ )
 {
 if ( (elf->sec[i].sec->sh_flags & (SHF_ALLOC|SHF_EXECINSTR)) ==
  (SHF_ALLOC|SHF_EXECINSTR) )
-alloc_section(>sec[i], _size);
+alloc_section(>sec[i], );
 }
+payload->core_text_size = size;
 
 /* Allocate rw data */
 for ( i = 0; i < elf->hdr->e_shnum; i++ )
@@ -552,7 +558,7 @@ static int move_module(struct payload *payload, struct 
xsplice_elf *elf)
 if ( (elf->sec[i].sec->sh_flags & SHF_ALLOC) &&
  

[Xen-devel] [PATCH v1 10/11] xsplice: Add support for exception tables

[Ross Lagerwall]

Add support for exception tables contained within xsplice modules. If an
exception occurs search either the main exception table or a particular
active module's exception table depending on the instruction pointer.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/extable.c| 36 ++--
 xen/common/xsplice.c  | 41 +
 xen/include/asm-x86/uaccess.h |  5 +
 xen/include/xen/xsplice.h |  2 ++
 4 files changed, 70 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 89b5bcb..2787a92 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field)
@@ -18,7 +19,7 @@ static inline unsigned long ex_cont(const struct 
exception_table_entry *x)
return EX_FIELD(x, cont);
 }
 
-static int __init cmp_ex(const void *a, const void *b)
+static int cmp_ex(const void *a, const void *b)
 {
const struct exception_table_entry *l = a, *r = b;
unsigned long lip = ex_addr(l);
@@ -33,7 +34,7 @@ static int __init cmp_ex(const void *a, const void *b)
 }
 
 #ifndef swap_ex
-static void __init swap_ex(void *a, void *b, int size)
+static void swap_ex(void *a, void *b, int size)
 {
struct exception_table_entry *l = a, *r = b, tmp;
long delta = b - a;
@@ -46,19 +47,23 @@ static void __init swap_ex(void *a, void *b, int size)
 }
 #endif
 
-void __init sort_exception_tables(void)
+void sort_exception_table(struct exception_table_entry *start,
+  struct exception_table_entry *stop)
 {
-sort(__start___ex_table, __stop___ex_table - __start___ex_table,
- sizeof(struct exception_table_entry), cmp_ex, swap_ex);
-sort(__start___pre_ex_table,
- __stop___pre_ex_table - __start___pre_ex_table,
+sort(start, stop - start,
  sizeof(struct exception_table_entry), cmp_ex, swap_ex);
 }
 
-static inline unsigned long
-search_one_table(const struct exception_table_entry *first,
- const struct exception_table_entry *last,
- unsigned long value)
+void __init sort_exception_tables(void)
+{
+sort_exception_table(__start___ex_table, __stop___ex_table);
+sort_exception_table(__start___pre_ex_table, __stop___pre_ex_table);
+}
+
+unsigned long
+search_one_extable(const struct exception_table_entry *first,
+   const struct exception_table_entry *last,
+   unsigned long value)
 {
 const struct exception_table_entry *mid;
 long diff;
@@ -80,15 +85,18 @@ search_one_table(const struct exception_table_entry *first,
 unsigned long
 search_exception_table(unsigned long addr)
 {
-return search_one_table(
-__start___ex_table, __stop___ex_table-1, addr);
+if ( likely(is_kernel(addr)) )
+return search_one_extable(
+__start___ex_table, __stop___ex_table-1, addr);
+else
+return search_module_extables(addr);
 }
 
 unsigned long
 search_pre_exception_table(struct cpu_user_regs *regs)
 {
 unsigned long addr = (unsigned long)regs->eip;
-unsigned long fixup = search_one_table(
+unsigned long fixup = search_one_extable(
 __start___pre_ex_table, __stop___pre_ex_table-1, addr);
 if ( fixup )
 {
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 982954b..c5a403b 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -45,6 +45,10 @@ struct payload {
 
 struct bug_frame *start_bug_frames[4];
 struct bug_frame *stop_bug_frames[4];
+#ifdef CONFIG_X86
+struct exception_table_entry *start_ex_table;
+struct exception_table_entry *stop_ex_table;
+#endif
 
 char  id[XEN_XSPLICE_NAME_SIZE + 1];  /* Name of it. */
 };
@@ -691,6 +695,17 @@ static int find_special_sections(struct payload *payload,
 payload->stop_bug_frames[i] = (struct bug_frame *)(sec->load_addr + 
sec->sec->sh_size);
 }
 
+#ifdef CONFIG_X86
+sec = xsplice_elf_sec_by_name(elf, ".ex_table");
+if ( sec )
+{
+payload->start_ex_table = (struct exception_table_entry 
*)sec->load_addr;
+payload->stop_ex_table = (struct exception_table_entry 
*)(sec->load_addr + sec->sec->sh_size);
+
+sort_exception_table(payload->start_ex_table, payload->stop_ex_table);
+}
+#endif
+
 return 0;
 }
 
@@ -999,6 +1014,32 @@ bool_t is_active_module_text(unsigned long addr)
 return false;
 }
 
+#ifdef CONFIG_X86
+unsigned long search_module_extables(unsigned long addr)
+{
+struct payload *data;
+unsigned long ret;
+
+/* No locking since this list is only ever changed during apply or revert
+ * context. */
+list_for_each_entry ( data, _list, applied_list )
+{
+if ( !data->start_ex_table )
+continue;
+if ( !((void *)addr >= data->module_address &&

Re: [Xen-devel] [PATCH v4 02/10] xen/blkfront: separate per ring information out of device info

[Konrad Rzeszutek Wilk]

On Mon, Nov 02, 2015 at 12:21:38PM +0800, Bob Liu wrote:
> Split per ring information to an new structure "blkfront_ring_info".
> 
> A ring is the representation of a hardware queue, every vbd device can 
> associate
> with one or more rings depending on how many hardware queues/rings to be used.

This along with the patch built with kbuild looks good.

However you will need to rebase it on top v4.4-rc1 to deal with
"block/xen-blkfront: Make it running on 64KB page granularity"

in mind.
> 
> This patch is a preparation for supporting real multi hardware queues/rings.
> 
> Signed-off-by: Arianna Avanzini 
> Signed-off-by: Bob Liu 
> ---
>  drivers/block/xen-blkfront.c | 321 
> ---
>  1 file changed, 178 insertions(+), 143 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index a69c02d..2a557e4 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -115,6 +115,23 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order of 
> pages to be used for the
>  #define RINGREF_NAME_LEN (20)
>  
>  /*
> + *  Per-ring info.
> + *  Every blkfront device can associate with one or more blkfront_ring_info,
> + *  depending on how many hardware queues/rings to be used.
> + */
> +struct blkfront_ring_info {
> + struct blkif_front_ring ring;
> + unsigned int ring_ref[XENBUS_MAX_RING_PAGES];
> + unsigned int evtchn, irq;
> + struct work_struct work;
> + struct gnttab_free_callback callback;
> + struct blk_shadow shadow[BLK_MAX_RING_SIZE];
> + struct list_head indirect_pages;
> + unsigned long shadow_free;
> + struct blkfront_info *dev_info;
> +};
> +
> +/*
>   * We have one of these per vbd, whether ide, scsi or 'other'.  They
>   * hang in private_data off the gendisk structure. We may end up
>   * putting all kinds of interesting stuff here :-)
> @@ -128,18 +145,10 @@ struct blkfront_info
>   int vdevice;
>   blkif_vdev_t handle;
>   enum blkif_state connected;
> - int ring_ref[XENBUS_MAX_RING_PAGES];
>   unsigned int nr_ring_pages;
> - struct blkif_front_ring ring;
> - unsigned int evtchn, irq;
>   struct request_queue *rq;
> - struct work_struct work;
> - struct gnttab_free_callback callback;
> - struct blk_shadow shadow[BLK_MAX_RING_SIZE];
>   struct list_head grants;
> - struct list_head indirect_pages;
>   unsigned int persistent_gnts_c;
> - unsigned long shadow_free;
>   unsigned int feature_flush;
>   unsigned int feature_discard:1;
>   unsigned int feature_secdiscard:1;
> @@ -149,6 +158,7 @@ struct blkfront_info
>   unsigned int max_indirect_segments;
>   int is_ready;
>   struct blk_mq_tag_set tag_set;
> + struct blkfront_ring_info rinfo;
>  };
>  
>  static unsigned int nr_minors;
> @@ -179,33 +189,35 @@ static DEFINE_SPINLOCK(minor_lock);
>  #define INDIRECT_GREFS(_segs) \
>   ((_segs + SEGS_PER_INDIRECT_FRAME - 1)/SEGS_PER_INDIRECT_FRAME)
>  
> -static int blkfront_setup_indirect(struct blkfront_info *info);
> +static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo);
>  static int blkfront_gather_backend_features(struct blkfront_info *info);
>  
> -static int get_id_from_freelist(struct blkfront_info *info)
> +static int get_id_from_freelist(struct blkfront_ring_info *rinfo)
>  {
> - unsigned long free = info->shadow_free;
> - BUG_ON(free >= BLK_RING_SIZE(info));
> - info->shadow_free = info->shadow[free].req.u.rw.id;
> - info->shadow[free].req.u.rw.id = 0x0fee; /* debug */
> + unsigned long free = rinfo->shadow_free;
> +
> + BUG_ON(free >= BLK_RING_SIZE(rinfo->dev_info));
> + rinfo->shadow_free = rinfo->shadow[free].req.u.rw.id;
> + rinfo->shadow[free].req.u.rw.id = 0x0fee; /* debug */
>   return free;
>  }
>  
> -static int add_id_to_freelist(struct blkfront_info *info,
> +static int add_id_to_freelist(struct blkfront_ring_info *rinfo,
>  unsigned long id)
>  {
> - if (info->shadow[id].req.u.rw.id != id)
> + if (rinfo->shadow[id].req.u.rw.id != id)
>   return -EINVAL;
> - if (info->shadow[id].request == NULL)
> + if (rinfo->shadow[id].request == NULL)
>   return -EINVAL;
> - info->shadow[id].req.u.rw.id  = info->shadow_free;
> - info->shadow[id].request = NULL;
> - info->shadow_free = id;
> + rinfo->shadow[id].req.u.rw.id  = rinfo->shadow_free;
> + rinfo->shadow[id].request = NULL;
> + rinfo->shadow_free = id;
>   return 0;
>  }
>  
> -static int fill_grant_buffer(struct blkfront_info *info, int num)
> +static int fill_grant_buffer(struct blkfront_ring_info *rinfo, int num)
>  {
> + struct blkfront_info *info = rinfo->dev_info;
>   struct page *granted_page;
>   struct grant *gnt_list_entry, *n;
>   int i = 0;
> @@ -341,8 +353,8 @@ static void 

Re: [Xen-devel] [PATCH v2] xl: log an error if libxl_cpupool_destroy() fails

[Ian Campbell]

On Wed, 2015-10-28 at 16:51 +, Wei Liu wrote:
> On Wed, Oct 28, 2015 at 05:43:51PM +0100, Dario Faggioli wrote:
> > In fact, right now, failing at destroying a cpupool is just
> > not reported to the user in any explicit way.
> > 
> > Let's log an error, as it is customary for xl in these cases.
> > 
> > Signed-off-by: Dario Faggioli 
> > Reviewed-by: Juergen Gross 
> 
> Acked-by: Wei Liu 

This conflicted with the changes to use EXIT_(ERROR|SUCCESS). By changing
"return 0" into "return EXIT_SUCCESS" and "return 1" into "return
EXIT_ERROR" in the context it applied cleanly. 

I was about to apply when I noticed the strange Reviewed-by: Jueregen
(having already spotted and fixed in the Cc). I don't think I want to apply
it like that. Please can you fix and rebase (after I push Harman's changes
soon) and resend.

Ian.

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

Re: [Xen-devel] [PATCH v3 1/6] xen: sched: fix locking of remove_vcpu() in credit1

[Dario Faggioli]

On Mon, 2015-11-02 at 18:04 +, George Dunlap wrote:
> On 29/10/15 23:04, Dario Faggioli wrote:

> > @@ -936,15 +936,19 @@ csched_vcpu_remove(const struct scheduler
> > *ops, struct vcpu *vc)
> >  vcpu_unpause(svc->vcpu);
> >  }
> >  
> > +lock = vcpu_schedule_lock_irq(vc);
> > +
> >  if ( __vcpu_on_runq(svc) )
> >  __runq_remove(svc);
> >  
> > -spin_lock_irqsave(&(prv->lock), flags);
> > +vcpu_schedule_unlock_irq(lock, vc);
> 
> Actually, at this point the domain should be either paused or in the
> middle of being destroyed, so it shouldn't be possible for the vcpu
> to
> be on the runqueue, should it?
>
Makes sense.

>   Should we instead change that if() to an
> ASSERT(!__vcpu_on_runqueue(svc))?
> 
I like the idea, I'll do it like this.

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



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

Re: [Xen-devel] [RFC PATCH v2 02/16] libxc: Load BIOS and ACPI table into guest memory

[Ian Campbell]

On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:

At first it seems like not loading the ACPI table already was an unnoticed
functional regression from the switch to HVM using the regular PV domain
builder. But then looking at that code I see there is an acpi_module field
which Roger added to the same xc_dom_image struct and appears to have added
code to support.

So I guess I am confused about how what you are adding here differs from
that, which at the least requires discussion in the commit message, but it
seems like either one or the other is misleadingly named now or they should
somehow be combined.

Ian.

> ... and prepare a cmdline for hvmloader with the order of the modules.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  tools/libxc/include/xc_dom.h   |  4 ++
>  tools/libxc/xc_dom_hvmloader.c | 44 +
>  tools/libxc/xc_dom_x86.c   | 90
> ++
>  3 files changed, 130 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 4939f76..c7003a4 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -203,6 +203,10 @@ struct xc_dom_image {
>  
>  /* Extra SMBIOS structures passed to HVMLOADER */
>  struct xc_hvm_firmware_module smbios_module;
> +
> +/* BIOS as module */
> +struct xc_hvm_firmware_module bios_module;
> +struct xc_hvm_firmware_module acpi_table_module;
>  };
>  
>  /* --- pluggable kernel loader - */
> diff --git a/tools/libxc/xc_dom_hvmloader.c
> b/tools/libxc/xc_dom_hvmloader.c
> index 79a3b99..3987ed8 100644
> --- a/tools/libxc/xc_dom_hvmloader.c
> +++ b/tools/libxc/xc_dom_hvmloader.c
> @@ -129,6 +129,18 @@ static elf_errorstatus
> xc_dom_parse_hvm_kernel(struct xc_dom_image *dom)
>  return rc;
>  }
>  
> +static uint64_t module_init(struct xc_hvm_firmware_module *module,
> +uint64_t mstart)
> +{
> +#define MODULE_ALIGN 1UL << 7
> +#define MKALIGN(x, a) (((uint64_t)(x) + (a) - 1) & ~(uint64_t)((a) - 1))
> +if ( module->length != 0 ) {
> +module->guest_addr_out = mstart;
> +return MKALIGN(module->length, MODULE_ALIGN);
> +} else
> +return 0;
> +}
> +
>  static int modules_init(struct xc_dom_image *dom,
>  uint64_t vend, struct elf_binary *elf,
>  uint64_t *mstart_out, uint64_t *mend_out)
> @@ -136,33 +148,47 @@ static int modules_init(struct xc_dom_image *dom,
>  #define MODULE_ALIGN 1UL << 7
>  #define MB_ALIGN 1UL << 20
>  #define MKALIGN(x, a) (((uint64_t)(x) + (a) - 1) & ~(uint64_t)((a) - 1))
> -uint64_t total_len = 0, offset1 = 0;
> +uint64_t total_len = 0, offset1 = 0, offset0;
> +uint64_t mstart;
>  
> -if ( dom->acpi_module.length == 0 && dom->smbios_module.length == 0
> )
> -return 0;
> +/* Want to place the modules 1Mb+change behind the loader image. */
> +mstart = MKALIGN(elf->pend, MB_ALIGN) + (MB_ALIGN);
>  
>  /* Find the total length for the firmware modules with a reasonable
> large
>   * alignment size to align each the modules.
>   */
> -total_len = MKALIGN(dom->acpi_module.length, MODULE_ALIGN);
> +total_len += module_init(>bios_module, mstart + total_len);
> +total_len += module_init(>acpi_table_module, mstart +
> total_len);
> +offset0 = total_len;
> +total_len += MKALIGN(dom->acpi_module.length, MODULE_ALIGN);
>  offset1 = total_len;
>  total_len += MKALIGN(dom->smbios_module.length, MODULE_ALIGN);
>  
> -/* Want to place the modules 1Mb+change behind the loader image. */
> -*mstart_out = MKALIGN(elf->pend, MB_ALIGN) + (MB_ALIGN);
> +if ( total_len == 0 )
> +return 0;
> +
> +*mstart_out = mstart;
>  *mend_out = *mstart_out + total_len;
>  
>  if ( *mend_out > vend )
>  return -1;
>  
>  if ( dom->acpi_module.length != 0 )
> -dom->acpi_module.guest_addr_out = *mstart_out;
> +dom->acpi_module.guest_addr_out = *mstart_out + offset0;
>  if ( dom->smbios_module.length != 0 )
>  dom->smbios_module.guest_addr_out = *mstart_out + offset1;
>  
>  return 0;
>  }
>  
> +static void loadmodule(struct xc_hvm_firmware_module *module,
> +   uint8_t *dest, uint64_t mstart)
> +{
> +if ( module->length != 0 )
> +memcpy(dest + (module->guest_addr_out - mstart),
> +   module->data, module->length);
> +}
> +
>  static int loadmodules(struct xc_dom_image *dom,
> uint64_t mstart, uint64_t mend,
> uint32_t domid)
> @@ -201,9 +227,11 @@ static int loadmodules(struct xc_dom_image *dom,
>  memset(dest, 0, pages << PAGE_SHIFT);
>  
>  /* Load modules into range */
> +loadmodule(>bios_module, dest, mstart);
> +loadmodule(>acpi_table_module, dest, mstart);
>  if ( dom->acpi_module.length != 0 )

Re: [Xen-devel] [PATCH v4 01/10] xen/blkif: document blkif multi-queue/ring extension

[Konrad Rzeszutek Wilk]

On Mon, Nov 02, 2015 at 12:21:37PM +0800, Bob Liu wrote:
> Document the multi-queue/ring feature in terms of XenStore keys to be written 
> by
> the backend and by the frontend.
> 
> Signed-off-by: Bob Liu 

I queued this up, but obviously we need to wait for the Xen version to
be accepted.

> --
> v2:
> Add descriptions together with multi-page ring buffer.
> ---
>  include/xen/interface/io/blkif.h | 48 
> 
>  1 file changed, 48 insertions(+)
> 
> diff --git a/include/xen/interface/io/blkif.h 
> b/include/xen/interface/io/blkif.h
> index c33e1c4..8b8cfad 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -28,6 +28,54 @@ typedef uint16_t blkif_vdev_t;
>  typedef uint64_t blkif_sector_t;
>  
>  /*
> + * Multiple hardware queues/rings:
> + * If supported, the backend will write the key "multi-queue-max-queues" to
> + * the directory for that vbd, and set its value to the maximum supported
> + * number of queues.
> + * Frontends that are aware of this feature and wish to use it can write the
> + * key "multi-queue-num-queues" with the number they wish to use, which must 
> be
> + * greater than zero, and no more than the value reported by the backend in
> + * "multi-queue-max-queues".
> + *
> + * For frontends requesting just one queue, the usual event-channel and
> + * ring-ref keys are written as before, simplifying the backend processing
> + * to avoid distinguishing between a frontend that doesn't understand the
> + * multi-queue feature, and one that does, but requested only one queue.
> + *
> + * Frontends requesting two or more queues must not write the toplevel
> + * event-channel and ring-ref keys, instead writing those keys under sub-keys
> + * having the name "queue-N" where N is the integer ID of the queue/ring for
> + * which those keys belong. Queues are indexed from zero.
> + * For example, a frontend with two queues must write the following set of
> + * queue-related keys:
> + *
> + * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
> + * /local/domain/1/device/vbd/0/queue-0 = ""
> + * /local/domain/1/device/vbd/0/queue-0/ring-ref = ""
> + * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
> + * /local/domain/1/device/vbd/0/queue-1 = ""
> + * /local/domain/1/device/vbd/0/queue-1/ring-ref = ""
> + * /local/domain/1/device/vbd/0/queue-1/event-channel = ""
> + *
> + * It is also possible to use multiple queues/rings together with
> + * feature multi-page ring buffer.
> + * For example, a frontend requests two queues/rings and the size of each 
> ring
> + * buffer is two pages must write the following set of related keys:
> + *
> + * /local/domain/1/device/vbd/0/multi-queue-num-queues = "2"
> + * /local/domain/1/device/vbd/0/ring-page-order = "1"
> + * /local/domain/1/device/vbd/0/queue-0 = ""
> + * /local/domain/1/device/vbd/0/queue-0/ring-ref0 = ""
> + * /local/domain/1/device/vbd/0/queue-0/ring-ref1 = ""
> + * /local/domain/1/device/vbd/0/queue-0/event-channel = ""
> + * /local/domain/1/device/vbd/0/queue-1 = ""
> + * /local/domain/1/device/vbd/0/queue-1/ring-ref0 = ""
> + * /local/domain/1/device/vbd/0/queue-1/ring-ref1 = ""
> + * /local/domain/1/device/vbd/0/queue-1/event-channel = ""
> + *
> + */
> +
> +/*
>   * REQUEST CODES.
>   */
>  #define BLKIF_OP_READ  0
> -- 
> 1.8.3.1
> 

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

[Xen-devel] [PATCH v1 00/11] xSplice implementation

[Ross Lagerwall]

This is the initial implementation of xSplice, live patching for Xen.

Patch series overview:

Patch 1: Design document
Patches 2, 5-11: Hypervisor implementation
Patches 3, 4: Toolstack changes

Live patches work at the function level by replacing functions. Any
function may be replaced, but whether it semantically is safe to do so
is up to the patch author. Live patches can contain bug frames,
exception tables and alternative instructions (required when patching
any non-trivial function). Patches are applied with the system in a
quiescent state.

This is the initial implementation and implements a usable subset of the
design document. It is enough to apply interesting patches (for example,
try XSA-148). A follow-up patch series implementing the remainder is
expected in this release cycle.

Although most of the code is architecture independent, there are a few
bits which are arch dependent and these have only been developed for
x86. There are stubs for arm (which have been compile-tested).

There is a separate tool to generate patches. Currently this lives at:
https://github.com/rosslagerwall/xsplice-build

Konrad Rzeszutek Wilk (4):
  xsplice: Design document (v2).
  xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op
  libxc: Implementation of XEN_XSPLICE_op in libxc.
  xen-xsplice: Tool to manipulate xsplice payloads.

Ross Lagerwall (7):
  elf: Add relocation types to elfstructs.h
  xsplice: Add helper elf routines
  xsplice: Implement payload loading
  xsplice: Implement support for applying patches
  xsplice: Add support for bug frames
  xsplice: Add support for exception tables
  xsplice: Add support for alternatives

 .gitignore   |1 +
 docs/misc/xsplice.markdown   |  999 
 tools/flask/policy/policy/modules/xen/xen.te |1 +
 tools/libxc/include/xenctrl.h|   18 +
 tools/libxc/xc_misc.c|  283 +++
 tools/misc/Makefile  |4 +
 tools/misc/xen-xsplice.c |  439 +++
 xen/arch/arm/Makefile|1 +
 xen/arch/arm/xsplice.c   |   31 +
 xen/arch/x86/Makefile|3 +-
 xen/arch/x86/alternative.c   |   12 +-
 xen/arch/x86/domain.c|4 +
 xen/arch/x86/extable.c   |   36 +-
 xen/arch/x86/hvm/svm/svm.c   |2 +
 xen/arch/x86/hvm/vmx/vmcs.c  |2 +
 xen/arch/x86/setup.c |7 +
 xen/arch/x86/traps.c |   30 +-
 xen/arch/x86/xsplice.c   |  109 +++
 xen/common/Makefile  |2 +
 xen/common/symbols.c |7 +
 xen/common/sysctl.c  |6 +
 xen/common/xsplice.c | 1059 ++
 xen/common/xsplice_elf.c |  122 +++
 xen/include/asm-arm/nmi.h|   13 +
 xen/include/asm-x86/alternative.h|1 +
 xen/include/asm-x86/uaccess.h|5 +
 xen/include/asm-x86/x86_64/page.h|2 +
 xen/include/public/sysctl.h  |  157 
 xen/include/xen/elfstructs.h |   21 +
 xen/include/xen/kernel.h |1 +
 xen/include/xen/xsplice.h|   42 +
 xen/include/xen/xsplice_elf.h|   44 ++
 xen/xsm/flask/hooks.c|4 +
 xen/xsm/flask/policy/access_vectors  |2 +
 34 files changed, 3439 insertions(+), 31 deletions(-)
 create mode 100644 docs/misc/xsplice.markdown
 create mode 100644 tools/misc/xen-xsplice.c
 create mode 100644 xen/arch/arm/xsplice.c
 create mode 100644 xen/arch/x86/xsplice.c
 create mode 100644 xen/common/xsplice.c
 create mode 100644 xen/common/xsplice_elf.c
 create mode 100644 xen/include/xen/xsplice.h
 create mode 100644 xen/include/xen/xsplice_elf.h

-- 
2.4.3


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

Re: [Xen-devel] [PATCH v10 2/5] missing include in cputime.c, remove #ifdef CONFIG_PARAVIRT from sched/core.c

[kbuild test robot]

Hi Stefano,

[auto build test ERROR on arm64/for-next/core]
[cannot apply to: xen-tip/linux-next]
[also ERROR on: v4.3 next-20151103]

url:
https://github.com/0day-ci/linux/commits/Stefano-Stabellini/xen-arm-arm64-CONFIG_PARAVIRT-and-stolen-ticks-accounting/20151104-002433
base:   https://github.com/0day-ci/linux 
Stefano-Stabellini/xen-arm-arm64-CONFIG_PARAVIRT-and-stolen-ticks-accounting/20151104-002433
config: avr32-atngw100_defconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=avr32 

All errors (new ones prefixed by >>):

>> kernel/sched/core.c:82:26: error: asm/paravirt.h: No such file or directory
--
>> kernel/sched/cputime.c:8:26: error: asm/paravirt.h: No such file or directory

vim +82 kernel/sched/core.c

52f5684c kernel/sched/core.c Gideon Israel Dsouza  2014-04-07  76  #include 

^1da177e kernel/sched.c  Linus Torvalds2005-04-16  77  
96f951ed kernel/sched/core.c David Howells 2012-03-28  78  #include 

5517d86b kernel/sched.c  Eric Dumazet  2007-05-08  79  #include 

838225b4 kernel/sched.c  Satyam Sharma 2007-10-24  80  #include 

db7e527d kernel/sched/core.c Christian Borntraeger 2012-01-11  81  #include 

e6e6685a kernel/sched.c  Glauber Costa 2011-07-11 @82  #include 

^1da177e kernel/sched.c  Linus Torvalds2005-04-16  83  
029632fb kernel/sched.c  Peter Zijlstra2011-10-25  84  #include 
"sched.h"
ea138446 kernel/sched/core.c Tejun Heo 2013-01-18  85  #include 
"../workqueue_internal.h"

:: The code at line 82 was first introduced by commit
:: e6e6685accfa81f509fadfc9624bc7c3862d75c4 KVM guest: Steal time accounting

:: TO: Glauber Costa <glom...@redhat.com>
:: CC: Avi Kivity <a...@redhat.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.

[Anthony PERARD]

On Tue, Nov 03, 2015 at 05:30:32PM +, Ian Campbell wrote:
> On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> > Hi all,
> > 
> > I've start to look at loading the BIOS and the ACPI tables via the
> > toolstack instead of having them embedded in the hvmloader binary. After
> > this patch series, hvmloader compilation would be indenpendant from
> > SeaBIOS
> > and OVMF compilation.
> > 
> > Compare to the V1, this is now done via the struct hvm_start_info from
> > Roger's patch series "Introduce HVM without dm and new boot ABI".
> 
> Just to be clear, does this therefore requires the rest of (or some more
> of) Roger's series to be applied or just the initial dozen patches which
> are already in?

The struct in introduced in this patch:
<1443800943-17668-30-git-send-email-roger@citrix.com>
[PATCH v7 29/32] libxc/xen: introduce a start info structure for HVMlite guests

And is not yet applied, so yes, it does require the rest of the patch
series, I have not look at which patches in particular.

> > Here is a general view of the few step to load the BIOS:
> > - libxl load the BIOS blob into it's memory and add it to struct
> >   xc_hvm_build_args.bios_module
> > - libxc load the blob into the guest memory and fill the struct
> >   hvm_start_info, with a cmdline which would contain the order in which the
> >   modules (bios, acpi_table) are loaded into the modlist.
> > - hvmloader read the addresses from the hvm_start_info, find out which
> >   module are which by reading the cmdline and copy the blob to the right
> >   place.
> 
> Hrm, it's a shame that the mod list doesn't contain this information,
> laundering it via a string cmdline seems a bit sub optimal. I haven't
> looked yet but my intuition is that this will involve hvmloader doing some
> string parsing, which I'm not keen on.
> 
> Is the modlist a stable API (yet?) or can we extend it if we want?

I'm not sure what could be added to it. An extra string that describe the
module maybe? Or ...

> Failing that perhaps hvmloader and libx? could collude such that the first
> module is always some data structure (a private interface between hvmloader
> and the tools) which describes the contents of the remaining modules?

... or we could have the modules been allocated in the same order, on a
specific position. So BIOS always first, ACPI table always second ..., and
if one is missing or not needed, replace it by a module of size 0.

> > Right now, this patch series would only work for SeaBIOS and OVMF. I have
> > not look into what to do about qemu-xen-traditionnal and rombios.
> 
> FWIW I think it would be fine to leave those legacy components using the
> existing mechanisms. No one in their right mind is going to want to use a
> system supplied version of rambios... Or if they do then I think it is up
> to them to patch it. (Unless actually doing this makes your life easier
> somehow WRT your actual goal)

I'll think about it.

-- 
Anthony PERARD

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  1dbe5d9ed6d698b0a24ada014d6747fb984dc13d
baseline version:
 xen  990ea04ebedf543156dc2afa980061eb6645c390

Last test of basis63484  2015-11-02 15:37:37 Z1 days
Testing same since63542  2015-11-03 17:01:31 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Ian Campbell 
  Ian Jackson 
  Julien Grall 
  Olaf Hering 
  Quan Xu 
  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=1dbe5d9ed6d698b0a24ada014d6747fb984dc13d
+ . ./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 
1dbe5d9ed6d698b0a24ada014d6747fb984dc13d
+ branch=xen-unstable-smoke
+ revision=1dbe5d9ed6d698b0a24ada014d6747fb984dc13d
+ . ./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-unstable
+ '[' x1dbe5d9ed6d698b0a24ada014d6747fb984dc13d = 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 '
  

Re: [Xen-devel] [PATCH v2] xl: log an error if libxl_cpupool_destroy() fails

[Dario Faggioli]

On Tue, 2015-11-03 at 17:08 +, Ian Campbell wrote:
> On Wed, 2015-10-28 at 16:51 +, Wei Liu wrote:
> > On Wed, Oct 28, 2015 at 05:43:51PM +0100, Dario Faggioli wrote:
> > > In fact, right now, failing at destroying a cpupool is just
> > > not reported to the user in any explicit way.
> > > 
> > > Let's log an error, as it is customary for xl in these cases.
> > > 
> > > Signed-off-by: Dario Faggioli 
> > > Reviewed-by: Juergen Gross 
> > 
> > Acked-by: Wei Liu 
> 
> This conflicted with the changes to use EXIT_(ERROR|SUCCESS). By
> changing
> "return 0" into "return EXIT_SUCCESS" and "return 1" into "return
> EXIT_ERROR" in the context it applied cleanly. 
> 
Right, thanks for trying.

> I was about to apply when I noticed the strange Reviewed-by: Jueregen
> (having already spotted and fixed in the Cc). I don't think I want to
> apply
> it like that. 
>
Oh, come on! How the heck did I manage to put it in there like that,
and to not notice it until now! :-(

Anyway, sorry for wasting your time.

> Please can you fix and rebase (after I push Harman's changes
> soon) and resend.
> 
Sure thing.

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



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

Re: [Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior

[Wei Liu]

On Mon, Nov 02, 2015 at 04:45:37PM +, Ross Lagerwall wrote:
> On 11/02/2015 04:37 PM, Wei Liu wrote:
> >On Mon, Nov 02, 2015 at 11:17:38AM +, Ross Lagerwall wrote:
> >>Previously, xenconsoled's daemonize function would do nothing if its
> >>parent process is init (as it is under systemd but not sysv init).
> >>This is confusing. Instead, always daemonize when asked to, but use the
> >>"interactive" switch when running from the systemd service.
> >>
> >>Because a pidfile is only written when daemonizing, drop the pidfile
> >>parameters from the service file (systemd keeps track of the pids
> >>anyway).
> >>
> >>Signed-off-by: Ross Lagerwall 
> >>---
> >>  tools/console/daemon/utils.c   | 4 
> >>  tools/hotplug/Linux/systemd/xenconsoled.service.in | 3 +--
> >>  2 files changed, 1 insertion(+), 6 deletions(-)
> >>
> >>diff --git a/tools/console/daemon/utils.c b/tools/console/daemon/utils.c
> >>index dbb3b12..644f6af 100644
> >>--- a/tools/console/daemon/utils.c
> >>+++ b/tools/console/daemon/utils.c
> >>@@ -52,10 +52,6 @@ void daemonize(const char *pidfile)
> >>int i;
> >>char buf[100];
> >>
> >>-   if (getppid() == 1) {
> >>-   return;
> >>-   }
> >>-
> >
> >Er, I never noticed this before. And code archeology doesn't tell me why
> >it was written like this either.
> 
> The fact that the service type was set to simple rather than forking was a
> sign...
> 
> >
> >>if ((pid = fork()) > 0) {
> >>exit(0);
> >>} else if (pid == -1) {
> >>diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in 
> >>b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> >>index cd282bf..8e333b1 100644
> >>--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> >>+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> >>@@ -10,10 +10,9 @@ Environment=XENCONSOLED_ARGS=
> >>  Environment=XENCONSOLED_TRACE=none
> >>  Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
> >>  EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
> >>-PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
> >>  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> >>  ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
> >>-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid 
> >>--log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} 
> >>$XENCONSOLED_ARGS
> >>+ExecStart=@sbindir@/xenconsoled -i --log=${XENCONSOLED_TRACE} 
> >>--log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
> >>
> >
> >To the best of my knowledge this seems to conform with man 7 daemon in
> >Linux, "New-Style Daemons" session:
> >
> >"For developing a new-style daemon, none of the initialization steps
> >recommended for SysV daemons need to be implemented. New-style init
> >systems such as systemd make all of them redundant. Moreover, since some
> >of these steps interfere with process monitoring, file descriptor
> >passing and other functionality of the init system, it is recommended
> >not to execute them when run as new-style service."
> >
> >So the use of "-i" seems justified.
> >
> 
> If a service needs to listen on a port or something and other services need
> to depend on it, then the preferred method would be using something like
> sd_notify. A less satisfactory approach would be to use forking, and then
> only writing the pidfile after the port is opened.
> 
> In this case, I don't think xenconsoled has any of these requirements so
> using Type=simple and keeping it in the foreground is the correct thing to
> do.
> 

I think I'm convinced.

Acked-by: Wei Liu 

> -- 
> Ross Lagerwall

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

Re: [Xen-devel] [PATCH] xl: Die on unknown options

[Ian Campbell]

On Mon, 2015-10-26 at 10:52 +, Wei Liu wrote:
> On Fri, Oct 23, 2015 at 04:44:11PM +0100, Ian Jackson wrote:
> > def_getopt would print a message to stderr, but blunder on anyway.
> > 
> > Sadly this is probably not a backport candidate.
> > 
> > Signed-off-by: Ian Jackson 
> 
> Acked-by: Wei Liu 

Applied.

> 
> > ---
> >  tools/libxl/xl_cmdimpl.c |1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index ea43761..de28593 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -2759,6 +2759,7 @@ static int def_getopt(int argc, char * const
> > argv[],
> >  exit(0);
> >  }
> >  fprintf(stderr, "option `%c' not supported.\n", optopt);
> > +exit(2);
> >  }
> >  if (opt == 'h') {
> >  help(helpstr);

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

Re: [Xen-devel] [RFC PATCH v2 01/16] hvmloader: Fix scratch_alloc to avoid overlaps

[Ian Campbell]

On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:

Please remember to CC the relevant maintainers.

> scratch_alloc() set scratch_start to the last byte of the current
> allocation.  The value of scratch_start is then reused as is (if it is
> already aligned) in the next allocation.  This result in a potential reuse
> of the last byte of the previous allocation.

This will, in one obscure case, now result in the BUG_ON triggering when it
wouldn't before. Namely in the case where e was previously MAX_INT and is
now 0.

I'm not sure we care, since the end result previously would be that the
next scratch allocation came from address 0, which seems unlikely to end
well. So the only case we might actually care would be if the allocation
triggering the BUG_ON was the last one.

I think we probably don't care about this obscure corner case, especially
given that the allocations are starting from 0x0001 and using enough
scratch to wrap seems like an indication the world has gone wrong anyway.

Maybe you want to discuss some of this in an updated commit message.

> Signed-off-by: Anthony PERARD 

Acked-by: Ian Campbell 

(NB: hvmloader is formally maintained by the X86 ARCHITECTURE maintainers,
not the tools ones)

> ---
>  tools/firmware/hvmloader/util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/firmware/hvmloader/util.c
> b/tools/firmware/hvmloader/util.c
> index d779fd7..42e8af4 100644
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -479,7 +479,7 @@ void *scratch_alloc(uint32_t size, uint32_t align)
>  align = 16;
>  
>  s = (scratch_start + align - 1) & ~(align - 1);
> -e = s + size - 1;
> +e = s + size;
>  
>  BUG_ON(e < s);
>  

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

[Xen-devel] [PATCH v1 11/11] xsplice: Add support for alternatives

[Ross Lagerwall]

Add support for applying alternative sections within xsplice modules. At
module load time, apply any alternative sections that are found.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/Makefile |  2 +-
 xen/arch/x86/alternative.c| 12 ++--
 xen/common/xsplice.c  | 11 +++
 xen/include/asm-x86/alternative.h |  1 +
 4 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 6e05532..5dbe2e8 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -7,7 +7,7 @@ subdir-y += oprofile
 
 subdir-$(x86_64) += x86_64
 
-obj-bin-y += alternative.init.o
+obj-bin-y += alternative.o
 obj-y += apic.o
 obj-y += bitops.o
 obj-bin-y += bzimage.init.o
diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index 46ac0fd..8d895ad 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -28,7 +28,7 @@
 extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
 
 #ifdef K8_NOP1
-static const unsigned char k8nops[] __initconst = {
+static const unsigned char k8nops[] = {
 K8_NOP1,
 K8_NOP2,
 K8_NOP3,
@@ -52,7 +52,7 @@ static const unsigned char * const k8_nops[ASM_NOP_MAX+1] = {
 #endif
 
 #ifdef P6_NOP1
-static const unsigned char p6nops[] __initconst = {
+static const unsigned char p6nops[] = {
 P6_NOP1,
 P6_NOP2,
 P6_NOP3,
@@ -75,7 +75,7 @@ static const unsigned char * const p6_nops[ASM_NOP_MAX+1] = {
 };
 #endif
 
-static const unsigned char * const *ideal_nops __initdata = k8_nops;
+static const unsigned char * const *ideal_nops = k8_nops;
 
 static int __init mask_nmi_callback(const struct cpu_user_regs *regs, int cpu)
 {
@@ -100,7 +100,7 @@ static void __init arch_init_ideal_nops(void)
 }
 
 /* Use this to add nops to a buffer, then text_poke the whole buffer. */
-static void __init add_nops(void *insns, unsigned int len)
+static void add_nops(void *insns, unsigned int len)
 {
 while ( len > 0 )
 {
@@ -127,7 +127,7 @@ static void __init add_nops(void *insns, unsigned int len)
  *
  * This routine is called with local interrupt disabled.
  */
-static void *__init text_poke_early(void *addr, const void *opcode, size_t len)
+static void *text_poke_early(void *addr, const void *opcode, size_t len)
 {
 memcpy(addr, opcode, len);
 sync_core();
@@ -142,7 +142,7 @@ static void *__init text_poke_early(void *addr, const void 
*opcode, size_t len)
  * APs have less capabilities than the boot processor are not handled.
  * Tough. Make sure you disable such features by hand.
  */
-static void __init apply_alternatives(struct alt_instr *start, struct 
alt_instr *end)
+void apply_alternatives(struct alt_instr *start, struct alt_instr *end)
 {
 struct alt_instr *a;
 u8 *instr, *replacement;
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index c5a403b..6a368af 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -682,6 +682,17 @@ static int find_special_sections(struct payload *payload,
 payload->funcs = (struct xsplice_patch_func *)sec->load_addr;
 payload->nfuncs = sec->sec->sh_size / (sizeof *payload->funcs);
 
+#ifdef CONFIG_X86
+sec = xsplice_elf_sec_by_name(elf, ".altinstructions");
+if ( sec )
+{
+local_irq_disable();
+apply_alternatives((struct alt_instr *)sec->load_addr,
+   (struct alt_instr *)(sec->load_addr + 
sec->sec->sh_size));
+local_irq_enable();
+}
+#endif
+
 for ( i = 0; i < 4; i++ )
 {
 char str[14];
diff --git a/xen/include/asm-x86/alternative.h 
b/xen/include/asm-x86/alternative.h
index 23c9b9f..8e83572 100644
--- a/xen/include/asm-x86/alternative.h
+++ b/xen/include/asm-x86/alternative.h
@@ -23,6 +23,7 @@ struct alt_instr {
 u8  replacementlen; /* length of new instruction, <= instrlen */
 };
 
+extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
 extern void alternative_instructions(void);
 
 #define OLDINSTR(oldinstr)  "661:\n\t" oldinstr "\n662:\n"
-- 
2.4.3


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

Re: [Xen-devel] [PATCH 1/6] xen/arm: domain_build: Avoid to shadow the variable "mod" in write_properties

[Ian Campbell]

On Tue, 2015-10-27 at 15:39 +, Julien Grall wrote:
> The variable "mod" is defined twice with different value. This make the
> code confusing to read.
> 
> Rename the 2 "mod" in something more meaningful.
> 
> Signed-off-by: Julien Grall 

Acked + applied.


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

Re: [Xen-devel] [PATCH v9] run QEMU as non-root

[Ian Campbell]

On Tue, 2015-11-03 at 16:49 +, Ian Campbell wrote:
> On Mon, 2015-11-02 at 12:30 +, Stefano Stabellini wrote:
> > Try to use "xen-qemudepriv-domid$domid" first, then
> > "xen-qemudepriv-shared" and root if everything else fails.
> > 
> > The uids need to be manually created by the user or, more likely, by
> > the
> > xen package maintainer.
> > 
> > Expose a device_model_user setting in libxl_domain_build_info, so that
> > opinionated callers, such as libvirt, can set any user they like. Do
> > not
> > fall back to root if device_model_user is set. Users can also set
> > device_model_user by hand in the xl domain config file.
> > 
> > QEMU is going to setuid and setgid to the user ID and the group ID of
> > the specified user, soon after initialization, before starting to deal
> > with any guest IO.
> > 
> > To actually secure QEMU when running in Dom0, we need at least to
> > deprivilege the privcmd and xenstore interfaces, this is just the first
> > step in that direction.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> Acked-by: Ian Campbell 

There were some minor conflicts against some patches committed at the start
of October. I had fixed them up (I think) but then I noticed
that docs/misc/qemu-deprivilege.txt in my working tree wasn't actually
committed.

Since this patch refers to it, but didn't include it I checked before
acking that it was already in tree some how, but didn't realise it wasn't
actually committed (somehow, not sure how). Was it supposed to be in this
patch or was it supposed to be in some earlier patch?

In any case given something odd is clearly going on I don't want to just
commit some random version of that doc which I just found in my working
directory along with this patch. Please can you resubmit with that file
included (or in a precursor patch).

Also please check the coding style of the comment in libxl.h, the "/*"
should be by itself.

Thanks,
Ian.

> 
> (based on previous plus eyeballing only the changes from:
> >  
> > Changes in v9:
> > - add a device_model_user option to the xl domain config file
> 
> Ian.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.

[Ian Campbell]

On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> Hi all,
> 
> I've start to look at loading the BIOS and the ACPI tables via the
> toolstack instead of having them embedded in the hvmloader binary. After
> this patch series, hvmloader compilation would be indenpendant from
> SeaBIOS
> and OVMF compilation.
> 
> Compare to the V1, this is now done via the struct hvm_start_info from
> Roger's patch series "Introduce HVM without dm and new boot ABI".

Just to be clear, does this therefore requires the rest of (or some more
of) Roger's series to be applied or just the initial dozen patches which
are already in?

> Here is a general view of the few step to load the BIOS:
> - libxl load the BIOS blob into it's memory and add it to struct
>   xc_hvm_build_args.bios_module
> - libxc load the blob into the guest memory and fill the struct
>   hvm_start_info, with a cmdline which would contain the order in which the
>   modules (bios, acpi_table) are loaded into the modlist.
> - hvmloader read the addresses from the hvm_start_info, find out which
>   module are which by reading the cmdline and copy the blob to the right
>   place.

Hrm, it's a shame that the mod list doesn't contain this information,
laundering it via a string cmdline seems a bit sub optimal. I haven't
looked yet but my intuition is that this will involve hvmloader doing some
string parsing, which I'm not keen on.

Is the modlist a stable API (yet?) or can we extend it if we want?

Failing that perhaps hvmloader and libx? could collude such that the first
module is always some data structure (a private interface between hvmloader
and the tools) which describes the contents of the remaining modules?

> Right now, this patch series would only work for SeaBIOS and OVMF. I have
> not look into what to do about qemu-xen-traditionnal and rombios.

FWIW I think it would be fine to leave those legacy components using the
existing mechanisms. No one in their right mind is going to want to use a
system supplied version of rambios... Or if they do then I think it is up
to them to patch it. (Unless actually doing this makes your life easier
somehow WRT your actual goal)

> 
> A git tree can be found here:
> git://xenbits.xen.org/people/aperard/xen-unstable.git
> tag: hvmloader-with-separated-bios-v2
> 
> Regards,
> 
> Anthony PERARD (16):
>   hvmloader: Fix scratch_alloc to avoid overlaps
>   libxc: Load BIOS and ACPI table into guest memory
>   configure: #define SEABIOS_PATH and OVMF_PATH
>   firmware/makefile: install BIOS and ACPI blob ...
>   libxl: Load guest BIOS from file
>   libxl: Load guest ACPI table from file
>   hvmloader: Grab the hvmlite info page and parse the cmdline
>   hvmloader: Locate the BIOS blob
>   hvmloader: Load SeaBIOS from hvm_start_info modules ...
>   hvmloader: Load OVMF from modules
>   hvmloader: No BIOS ROM image allowed to be compiled in
>   hvmloader: Load ACPI tables from hvm_start_info module
>   hvmloader/makefile: Compile out SeaBIOS and OVMF ROM blob
>   hvmloader: Always build-in SeaBIOS and OVMF loader
>   hvmloader: Compile out the qemu-xen ACPI tables
>   hvmloader: do not depend on SEABIOS_PATH or OVMF_PATH ...
> 
>  .gitignore |   1 +
>  tools/configure.ac |  12 +++-
>  tools/firmware/Makefile|  15 ++--
>  tools/firmware/hvmloader/Makefile  |  32 -
>  tools/firmware/hvmloader/acpi/Makefile |   8 ++-
>  tools/firmware/hvmloader/config.h  |  11 +--
>  tools/firmware/hvmloader/hvmloader.c   | 127
> -
>  tools/firmware/hvmloader/ovmf.c|  34 -
>  tools/firmware/hvmloader/seabios.c |  33 -
>  tools/firmware/hvmloader/util.c|   2 +-
>  tools/libxc/include/xc_dom.h   |   4 ++
>  tools/libxc/xc_dom_hvmloader.c |  44 +---
>  tools/libxc/xc_dom_x86.c   |  90 +++
>  tools/libxl/libxl_dom.c|  83 +
>  tools/libxl/libxl_types.idl|   2 +
>  tools/libxl/xl_cmdimpl.c   |  14 +++-
>  16 files changed, 394 insertions(+), 118 deletions(-)
> 

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

Re: [Xen-devel] Hotpatch construction and __LINE__

[Ross Lagerwall]

On 08/05/2015 09:55 AM, Martin Pohlack wrote:

Hi,

Another high-level point to think about is how we want to handle inlined
__LINE__ references.  This problem is related to hotpatch construction
and potentially has influence on the design of the hotpatching
infrastructure in Xen.

Let me try to explain the problem:

We have file1.c with functions f1 and f2 (in that order).  f2 contains a
BUG() (or WARN()) macro and at that point embeds the source line number
into the generated code for f2.

Now we want to hotpatch f1 and the hotpatch source-code patch adds 2
lines to f1 and as a consequence shifts out f2 by two lines.  The newly
constructed file1.o will now contain differences in both binary
functions f1 (because we actually changed it with the applied patch) and
f2 (because the contained BUG macro embeds the new line number).

Without additional information, an algorithm comparing file1.o before
and after hotpatch application will determine both functions to be
changed and will have to include both into the binary hotpatch.

Options:

1. Transform source code patches for hotpatches to be line-neutral for
each chunk.  This can be done in almost all cases with either
reformatting of the source code or by introducing artificial
preprocessor "#line n" directives to adjust for the introduced
differences.

This approach is low-tech and simple.  Potentially generated
backtraces and existing debug information refers to the original
build and does not reflect hotpatching state except for actually
hotpatched functions but should be mostly correct.

2. Ignoring the problem and living with artificially large hotpatches
that unnecessarily patch many functions.

This approach might lead to some very large hotpatches depending on
content of specific source file.  It may also trigger pulling in
functions into the hotpatch that cannot reasonable be hotpatched due
to limitations of a hotpatching framework (init-sections, parts of
the hotpatching framework itself, ...) and may thereby prevent us
from patching a specific problem.

The decision between 1. and 2. can be made on a patch--by-patch
basis.

3. Introducing an indirection table for storing line numbers and
treating that specially for binary diffing.  I believe Linux follows
this approach, but the details escape me ATM.

We might either use this indirection table for runtime use and patch
that with each hotpatch (similarly to exception tables) or we might
purely use it when building hotpatches to ignore functions that only
differ at exactly the location where a line-number is embedded.



For BUG, ASSERT, and WARN, the line number is stored in the bug frame 
table and as currently implemented, the build tool ignores changes to 
the bug frame table if there's no corresponding functional change. Which 
mostly fixes this issue.


--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH v4 06/10] xen/blkback: separate ring information out of struct xen_blkif

[Konrad Rzeszutek Wilk]

On Mon, Nov 02, 2015 at 12:21:42PM +0800, Bob Liu wrote:
> Split per ring information to an new structure "xen_blkif_ring", so that one 
> vbd
> device can associate with one or more rings/hardware queues.

s/can associate/can be associated/
> 
> Introduce 'pers_gnts_lock' to protect the pool of persistent grants since we
> may have multi backend threads.
> 
> This patch is a preparation for supporting multi hardware queues/rings.
> 
> Signed-off-by: Arianna Avanzini 
> Signed-off-by: Bob Liu 
> ---
>  drivers/block/xen-blkback/blkback.c | 233 
> 
>  drivers/block/xen-blkback/common.h  |  64 ++
>  drivers/block/xen-blkback/xenbus.c  | 107 ++---
>  3 files changed, 234 insertions(+), 170 deletions(-)
> 
> diff --git a/drivers/block/xen-blkback/blkback.c 
> b/drivers/block/xen-blkback/blkback.c
> index 6a685ae..eaf7ec0 100644
> --- a/drivers/block/xen-blkback/blkback.c
> +++ b/drivers/block/xen-blkback/blkback.c
> @@ -173,11 +173,11 @@ static inline void shrink_free_pagepool(struct 
> xen_blkif *blkif, int num)
>  
>  #define vaddr(page) ((unsigned long)pfn_to_kaddr(page_to_pfn(page)))
>  
> -static int do_block_io_op(struct xen_blkif *blkif);
> -static int dispatch_rw_block_io(struct xen_blkif *blkif,
> +static int do_block_io_op(struct xen_blkif_ring *ring);
> +static int dispatch_rw_block_io(struct xen_blkif_ring *ring,
>   struct blkif_request *req,
>   struct pending_req *pending_req);
> -static void make_response(struct xen_blkif *blkif, u64 id,
> +static void make_response(struct xen_blkif_ring *ring, u64 id,
> unsigned short op, int st);
>  
>  #define foreach_grant_safe(pos, n, rbtree, node) \
> @@ -189,14 +189,8 @@ static void make_response(struct xen_blkif *blkif, u64 
> id,
>  
>  
>  /*
> - * We don't need locking around the persistent grant helpers
> - * because blkback uses a single-thread for each backed, so we
> - * can be sure that this functions will never be called recursively.
> - *
> - * The only exception to that is put_persistent_grant, that can be called
> - * from interrupt context (by xen_blkbk_unmap), so we have to use atomic
> - * bit operations to modify the flags of a persistent grant and to count
> - * the number of used grants.
> + * pers_gnts_lock must be used around all the persistent grant helpers
> + * because blkback may use multi-thread/queue for each backend.
>   */

Would it make sense to have an ASSERT on the holding of the
pers_gnts_lock in this functioni (and also in get_persistent_gnt,
put_persistent_gnt, free_persistent_gnts?

>  static int add_persistent_gnt(struct xen_blkif *blkif,
>  struct persistent_gnt *persistent_gnt)
> @@ -322,11 +316,13 @@ void xen_blkbk_unmap_purged_grants(struct work_struct 
> *work)
>   int segs_to_unmap = 0;
>   struct xen_blkif *blkif = container_of(work, typeof(*blkif), 
> persistent_purge_work);
>   struct gntab_unmap_queue_data unmap_data;
> + unsigned long flags;
>  
>   unmap_data.pages = pages;
>   unmap_data.unmap_ops = unmap;
>   unmap_data.kunmap_ops = NULL;
>  
> + spin_lock_irqsave(>pers_gnts_lock, flags);
>   while(!list_empty(>persistent_purge_list)) {
>   persistent_gnt = list_first_entry(>persistent_purge_list,
> struct persistent_gnt,
> @@ -348,6 +344,7 @@ void xen_blkbk_unmap_purged_grants(struct work_struct 
> *work)
>   }
>   kfree(persistent_gnt);
>   }
> + spin_unlock_irqrestore(>pers_gnts_lock, flags);
>   if (segs_to_unmap > 0) {
>   unmap_data.count = segs_to_unmap;
>   BUG_ON(gnttab_unmap_refs_sync(_data));
> @@ -362,16 +359,18 @@ static void purge_persistent_gnt(struct xen_blkif 
> *blkif)
>   unsigned int num_clean, total;
>   bool scan_used = false, clean_used = false;
>   struct rb_root *root;
> + unsigned long flags;
>  
> + spin_lock_irqsave(>pers_gnts_lock, flags);
>   if (blkif->persistent_gnt_c < xen_blkif_max_pgrants ||
>   (blkif->persistent_gnt_c == xen_blkif_max_pgrants &&
>   !blkif->vbd.overflow_max_grants)) {
> - return;
> + goto out;
>   }
>  
>   if (work_busy(>persistent_purge_work)) {

Hm, looking at 'work_busy' it says that you should hold on a pool mutex.

But that is a seperate bug

>   pr_alert_ratelimited("Scheduled work from previous purge is 
> still busy, cannot purge list\n");
> - return;
> + goto out;
>   }
>  
>   num_clean = (xen_blkif_max_pgrants / 100) * LRU_PERCENT_CLEAN;
> @@ -379,7 +378,7 @@ static void purge_persistent_gnt(struct xen_blkif *blkif)
>   num_clean = min(blkif->persistent_gnt_c, num_clean);
>   if ((num_clean == 0) ||
>   (num_clean > (blkif->persistent_gnt_c - 
> 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  32b31c17da1ba0da970cd182a8865ac20fabd0fa
baseline version:
 xen  1dbe5d9ed6d698b0a24ada014d6747fb984dc13d

Last test of basis63542  2015-11-03 17:01:31 Z0 days
Testing same since63544  2015-11-03 19:01:38 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Kevin Tian 

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=32b31c17da1ba0da970cd182a8865ac20fabd0fa
+ . ./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 
32b31c17da1ba0da970cd182a8865ac20fabd0fa
+ branch=xen-unstable-smoke
+ revision=32b31c17da1ba0da970cd182a8865ac20fabd0fa
+ . ./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-unstable
+ '[' x32b31c17da1ba0da970cd182a8865ac20fabd0fa = 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;

Re: [Xen-devel] [PATCH v4 04/10] xen/blkfront: split per device io_lock

[Konrad Rzeszutek Wilk]

On Mon, Nov 02, 2015 at 12:21:40PM +0800, Bob Liu wrote:
> The per device io_lock became a coarser grained lock after multi-queues/rings
> was introduced, this patch introduced a fine-grained ring_lock for each ring.

s/was introduced/was introduced (see commit titled XYZ)/

s/introdued/introduces/
> 
> The old io_lock was renamed to dev_lock and only protect the ->grants list

s/was/is/
s/protect/protects/

> which is shared by all rings.
> 
> Signed-off-by: Bob Liu 
> ---
>  drivers/block/xen-blkfront.c | 57 
> ++--
>  1 file changed, 34 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index eab78e7..8cc5995 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -121,6 +121,7 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order of 
> pages to be used for the
>   */
>  struct blkfront_ring_info {
>   struct blkif_front_ring ring;

Can you add a comment explaining the lock semantic? As in under what conditions
should it be taken? Like you have it below.

> + spinlock_t ring_lock;
>   unsigned int ring_ref[XENBUS_MAX_RING_PAGES];
>   unsigned int evtchn, irq;
>   struct work_struct work;
> @@ -138,7 +139,8 @@ struct blkfront_ring_info {
>   */
>  struct blkfront_info
>  {
> - spinlock_t io_lock;
> + /* Lock to proect info->grants list shared by multi rings */

s/proect/protect/

Missing full stop.

> + spinlock_t dev_lock;

Shouldn't it be right next to what it is protecting?

That is right below (or above): 'struct list_head grants;'?

>   struct mutex mutex;
>   struct xenbus_device *xbdev;
>   struct gendisk *gd;
> @@ -224,6 +226,7 @@ static int fill_grant_buffer(struct blkfront_ring_info 
> *rinfo, int num)
>   struct grant *gnt_list_entry, *n;
>   int i = 0;
>  
> + spin_lock_irq(>dev_lock);

Why there? Why not where you add it to the list?
>   while(i < num) {
>   gnt_list_entry = kzalloc(sizeof(struct grant), GFP_NOIO);
>   if (!gnt_list_entry)
> @@ -242,6 +245,7 @@ static int fill_grant_buffer(struct blkfront_ring_info 
> *rinfo, int num)
>   list_add(_list_entry->node, >grants);

Right here that is?

You are holding the lock for the duration of 'kzalloc' and 'alloc_page'.

And more interestingly, GFP_NOIO translates to __GFP_WAIT which means
it can call 'schedule'. - And you have taken an spinlock. That should
have thrown lots of warnings?

>   i++;
>   }
> + spin_unlock_irq(>dev_lock);
>  
>   return 0;
>  
> @@ -254,6 +258,7 @@ out_of_memory:
>   kfree(gnt_list_entry);
>   i--;
>   }
> + spin_unlock_irq(>dev_lock);

Just do it around the 'list_del' operation. You are using an
'safe'
>   BUG_ON(i != 0);
>   return -ENOMEM;
>  }
> @@ -265,6 +270,7 @@ static struct grant *get_grant(grant_ref_t *gref_head,
>   struct grant *gnt_list_entry;
>   unsigned long buffer_gfn;
>  
> + spin_lock(>dev_lock);
>   BUG_ON(list_empty(>grants));
>   gnt_list_entry = list_first_entry(>grants, struct grant,
> node);
> @@ -272,8 +278,10 @@ static struct grant *get_grant(grant_ref_t *gref_head,
>  
>   if (gnt_list_entry->gref != GRANT_INVALID_REF) {
>   info->persistent_gnts_c--;
> + spin_unlock(>dev_lock);
>   return gnt_list_entry;
>   }
> + spin_unlock(>dev_lock);

Just have one spin_unlock. Put it right before the 'if 
(gnt_list_entry->gref)..'.
>  
>   /* Assign a gref to this page */
>   gnt_list_entry->gref = gnttab_claim_grant_reference(gref_head);
> @@ -639,7 +647,7 @@ static int blkif_queue_rq(struct blk_mq_hw_ctx *hctx,
>   struct blkfront_ring_info *rinfo = (struct blkfront_ring_info 
> *)hctx->driver_data;
>  
>   blk_mq_start_request(qd->rq);
> - spin_lock_irq(>io_lock);
> + spin_lock_irq(>ring_lock);
>   if (RING_FULL(>ring))
>   goto out_busy;
>  
> @@ -650,15 +658,15 @@ static int blkif_queue_rq(struct blk_mq_hw_ctx *hctx,
>   goto out_busy;
>  
>   flush_requests(rinfo);
> - spin_unlock_irq(>io_lock);
> + spin_unlock_irq(>ring_lock);
>   return BLK_MQ_RQ_QUEUE_OK;
>  
>  out_err:
> - spin_unlock_irq(>io_lock);
> + spin_unlock_irq(>ring_lock);
>   return BLK_MQ_RQ_QUEUE_ERROR;
>  
>  out_busy:
> - spin_unlock_irq(>io_lock);
> + spin_unlock_irq(>ring_lock);
>   blk_mq_stop_hw_queue(hctx);
>   return BLK_MQ_RQ_QUEUE_BUSY;
>  }
> @@ -959,21 +967,22 @@ static void xlvbd_release_gendisk(struct blkfront_info 
> *info)
>   info->gd = NULL;
>  }
>  
> -/* Must be called with io_lock holded */
>  static void kick_pending_request_queues(struct blkfront_ring_info *rinfo)
>  {
> + unsigned long flags;
> +
> + spin_lock_irqsave(>ring_lock, flags);
>   if (!RING_FULL(>ring))
> 

Re: [Xen-devel] [PATCH v4 05/10] xen/blkfront: negotiate number of queues/rings to be used with backend

[Konrad Rzeszutek Wilk]

On Mon, Nov 02, 2015 at 12:21:41PM +0800, Bob Liu wrote:
> The number of hardware queues for xen/blkfront is set by parameter
> 'max_queues'(default 4), while the max value xen/blkback supported is notified
> through xenstore("multi-queue-max-queues").

That is not right.

s/The number/The max number/

The second part: ",while the max value xen/blkback supported is..". I think
you are trying to say: "it is also capped by the max value that
the xen/blkback exposes through XenStore key 'multi-queue-max-queues'.

> 
> The negotiated number is the smaller one and would be written back to xenstore
> as "multi-queue-num-queues", blkback need to read this negotiated number.

s/blkback need to read/blkback needs to read this/

> 
> Signed-off-by: Bob Liu 
> ---
>  drivers/block/xen-blkfront.c | 166 
> +++
>  1 file changed, 120 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 8cc5995..23096d7 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -98,6 +98,10 @@ static unsigned int xen_blkif_max_segments = 32;
>  module_param_named(max, xen_blkif_max_segments, int, S_IRUGO);
>  MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests 
> (default is 32)");
>  
> +static unsigned int xen_blkif_max_queues = 4;
> +module_param_named(max_queues, xen_blkif_max_queues, uint, S_IRUGO);
> +MODULE_PARM_DESC(max_queues, "Maximum number of hardware queues/rings used 
> per virtual disk");
> +
>  /*
>   * Maximum order of pages to be used for the shared ring between front and
>   * backend, 4KB page granularity is used.
> @@ -113,6 +117,7 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order of 
> pages to be used for the
>   * characters are enough. Define to 20 to keep consist with backend.
>   */
>  #define RINGREF_NAME_LEN (20)
> +#define QUEUE_NAME_LEN (12)

Little bit of documentation please. Why 12? Why not 31415 for example?
I presume it is 'queue-%u' and since so that is 7 + 10 (UINT_MAX is
4294967295) = 17!


>  
>  /*
>   *  Per-ring info.
> @@ -695,7 +700,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 
> sector_size,
>  
>   memset(>tag_set, 0, sizeof(info->tag_set));
>   info->tag_set.ops = _mq_ops;
> - info->tag_set.nr_hw_queues = 1;
> + info->tag_set.nr_hw_queues = info->nr_rings;
>   info->tag_set.queue_depth =  BLK_RING_SIZE(info);
>   info->tag_set.numa_node = NUMA_NO_NODE;
>   info->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_SG_MERGE;
> @@ -1352,6 +1357,51 @@ fail:
>   return err;
>  }
>  
> +static int write_per_ring_nodes(struct xenbus_transaction xbt,
> + struct blkfront_ring_info *rinfo, const char 
> *dir)
> +{
> + int err, i;

Please make 'i' be an unsigned int. Especially as you are using '%u' in the 
snprintf.


> + const char *message = NULL;
> + struct blkfront_info *info = rinfo->dev_info;
> +
> + if (info->nr_ring_pages == 1) {
> + err = xenbus_printf(xbt, dir, "ring-ref", "%u", 
> rinfo->ring_ref[0]);
> + if (err) {
> + message = "writing ring-ref";
> + goto abort_transaction;
> + }
> + pr_info("%s: write ring-ref:%d\n", dir, rinfo->ring_ref[0]);

Ewww. No.

> + } else {
> + for (i = 0; i < info->nr_ring_pages; i++) {
> + char ring_ref_name[RINGREF_NAME_LEN];
> +
> + snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", 
> i);
> + err = xenbus_printf(xbt, dir, ring_ref_name,
> + "%u", rinfo->ring_ref[i]);
> + if (err) {
> + message = "writing ring-ref";
> + goto abort_transaction;
> + }
> + pr_info("%s: write ring-ref:%d\n", dir, 
> rinfo->ring_ref[i]);

No no please.

> + }
> + }
> +
> + err = xenbus_printf(xbt, dir, "event-channel", "%u", rinfo->evtchn);

That is not right.

That only creates one. But the blkif.h says (And the example agrees)
that there are N 'event-channel' for N-rings.

Shouldn't this be part of the above loop?

> + if (err) {
> + message = "writing event-channel";
> + goto abort_transaction;
> + }
> + pr_info("%s: write event-channel:%d\n", dir, rinfo->evtchn);

Please no.

> +
> + return 0;
> +
> +abort_transaction:
> + xenbus_transaction_end(xbt, 1);
> + if (message)
> + xenbus_dev_fatal(info->xbdev, err, "%s", message);
> +
> + return err;
> +}
>  
>  /* Common code used when first setting up, and when resuming. */
>  static int talk_to_blkback(struct xenbus_device *dev,
> @@ -1362,7 +1412,6 @@ static int talk_to_blkback(struct xenbus_device *dev,
>   int err, i;
>   unsigned int max_page_order = 

Re: [Xen-devel] [PATCH v4 03/10] xen/blkfront: pseudo support for multi hardware queues/rings

[Konrad Rzeszutek Wilk]

On Mon, Nov 02, 2015 at 12:21:39PM +0800, Bob Liu wrote:
> Preparatory patch for multiple hardware queues (rings). The number of
> rings is unconditionally set to 1, larger number will be enabled in next
> patch so as to make every single patch small and readable.

s/next patch/"xen/blkfront: negotiate number of queues/rings to be used with 
backend"

> 
> Signed-off-by: Bob Liu 
> ---
>  drivers/block/xen-blkfront.c | 327 
> +--
>  1 file changed, 188 insertions(+), 139 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2a557e4..eab78e7 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -145,6 +145,7 @@ struct blkfront_info
>   int vdevice;
>   blkif_vdev_t handle;
>   enum blkif_state connected;
> + /* Number of pages per ring buffer */

Missing full stop, aka '.'.

>   unsigned int nr_ring_pages;
>   struct request_queue *rq;
>   struct list_head grants;
> @@ -158,7 +159,8 @@ struct blkfront_info
>   unsigned int max_indirect_segments;
>   int is_ready;
>   struct blk_mq_tag_set tag_set;
> - struct blkfront_ring_info rinfo;
> + struct blkfront_ring_info *rinfo;
> + unsigned int nr_rings;
>  };
>  
>  static unsigned int nr_minors;
> @@ -190,7 +192,7 @@ static DEFINE_SPINLOCK(minor_lock);
>   ((_segs + SEGS_PER_INDIRECT_FRAME - 1)/SEGS_PER_INDIRECT_FRAME)
>  
>  static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo);
> -static int blkfront_gather_backend_features(struct blkfront_info *info);
> +static void blkfront_gather_backend_features(struct blkfront_info *info);
>  
>  static int get_id_from_freelist(struct blkfront_ring_info *rinfo)
>  {
> @@ -443,12 +445,13 @@ static int blkif_queue_request(struct request *req, 
> struct blkfront_ring_info *r
>*/
>   max_grefs += INDIRECT_GREFS(req->nr_phys_segments);
>  
> - /* Check if we have enough grants to allocate a requests */
> - if (info->persistent_gnts_c < max_grefs) {
> + /* Check if we have enough grants to allocate a requests, we have to
> +  * reserve 'max_grefs' grants because persistent grants are shared by 
> all
> +  * rings */

Missing full stop.

> + if (0 < max_grefs) {

 ? 0!?

max_grefs will at least be BLKIF_MAX_SEGMENTS_PER_REQUEST
so this will always be true.

In which ase why not just ..
>   new_persistent_gnts = 1;
>   if (gnttab_alloc_grant_references(
> - max_grefs - info->persistent_gnts_c,
> - _head) < 0) {
> + max_grefs, _head) < 0) {
>   gnttab_request_free_callback(
>   >callback,
>   blkif_restart_queue_callback,

.. move this whole code down? And get rid of 'new_persistent_gnts'
since it will always be true?

But more importantly, why do we not check for 'info->persistent_gnts_c' anymore?

> @@ -665,7 +668,7 @@ static int blk_mq_init_hctx(struct blk_mq_hw_ctx *hctx, 
> void *data,
>  {
>   struct blkfront_info *info = (struct blkfront_info *)data;
>  
> - hctx->driver_data = >rinfo;
> + hctx->driver_data = >rinfo[index];

Please add an ASSERT here to check to make sure
that info->nr_rings < index.

>   return 0;
>  }
>  
> @@ -924,8 +927,7 @@ static int xlvbd_alloc_gendisk(blkif_sector_t capacity,
>  
>  static void xlvbd_release_gendisk(struct blkfront_info *info)
>  {
> - unsigned int minor, nr_minors;
> - struct blkfront_ring_info *rinfo = >rinfo;
> + unsigned int minor, nr_minors, i;
>  
>   if (info->rq == NULL)
>   return;
> @@ -933,11 +935,15 @@ static void xlvbd_release_gendisk(struct blkfront_info 
> *info)
>   /* No more blkif_request(). */
>   blk_mq_stop_hw_queues(info->rq);
>  
> - /* No more gnttab callback work. */
> - gnttab_cancel_free_callback(>callback);
> + for (i = 0; i < info->nr_rings; i++) {
> + struct blkfront_ring_info *rinfo = >rinfo[i];
>  
> - /* Flush gnttab callback work. Must be done with no locks held. */
> - flush_work(>work);
> + /* No more gnttab callback work. */
> + gnttab_cancel_free_callback(>callback);
> +
> + /* Flush gnttab callback work. Must be done with no locks held. 
> */
> + flush_work(>work);
> + }
>  
>   del_gendisk(info->gd);
>  
> @@ -970,37 +976,11 @@ static void blkif_restart_queue(struct work_struct 
> *work)
>   spin_unlock_irq(>dev_info->io_lock);
>  }
>  
> -static void blkif_free(struct blkfront_info *info, int suspend)
> +static void blkif_free_ring(struct blkfront_ring_info *rinfo)
>  {
>   struct grant *persistent_gnt;
> - struct grant *n;
> + struct blkfront_info *info = rinfo->dev_info;
>   int i, j, segs;
> - struct blkfront_ring_info *rinfo = >rinfo;
> -
> - /* Prevent new requests being 

[Xen-devel] [linux-next test] 63476: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 63398
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 63398
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 63398
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 63398
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
63398
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
63398
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 63398
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 63398
 test-armhf-armhf-xl-rtds 15 guest-start.2 fail REGR. vs. 63398
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 63398
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 63398
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 63398
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host fail REGR. vs. 63398

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 

Re: [Xen-devel] [PATCH] sched_credit: Remove cpu argument to __runq_insert()

[Dario Faggioli]

On Tue, 2015-11-03 at 05:38 -0700, Jan Beulich wrote:
> > > > On 03.11.15 at 11:16,  wrote:

> > So you agree that this change makes the source code make more sense
> > ("looks like an improvement at the source level"), but you think
> > that
> > this will make the compiled code less efficient; and you recommend
> > instead of making the source code clearer, to make things even
> > *better* by changing the BUG_ON() to an ASSERT?
> > 
> > Why do you think the compiler output will be less efficient?
> 
> Due to the two extra memory references, which the compiler is
> unlikely to be able to eliminate in all cases?.
> 
Right. I had a quick look at the assembly code, and I think I saw
something like that. As far as I've seen, though, the text sections of
the generated binaries --with and without this patch-- were equally big
(due to alignment, I think).

Also, for the reasons explained here:
 http://lists.xen.org/archives/html/xen-devel/2015-11/msg00051.html

As far as I'm concerned, this patch is:

Acked-by: Dario Faggioli 

That being said...

> > Overall I think the burden of proof is on you to show that the code
> > as
> > it is introduces a sufficient performance improvement over the more
> > readable code, rather than on Harmandeep (or Dario or I) to show
> > that
> > it doesn't.
> 
> Okay, so far I thought people suggesting a change are the ones
> to prove that the change doesn't have undesirable effects. 
>
...just FTY, I probably will try having a look at what it means to make
__runq_insert() non-inline. But that's another patch. :-)

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



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

Re: [Xen-devel] [PATCH v4 03/10] xen/blkfront: pseudo support for multi hardware queues/rings

[Bob Liu]

On 11/04/2015 03:44 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:39PM +0800, Bob Liu wrote:
>> Preparatory patch for multiple hardware queues (rings). The number of
>> rings is unconditionally set to 1, larger number will be enabled in next
>> patch so as to make every single patch small and readable.
> 
> s/next patch/"xen/blkfront: negotiate number of queues/rings to be used with 
> backend"
> 
>>
>> Signed-off-by: Bob Liu 
>> ---
>>  drivers/block/xen-blkfront.c | 327 
>> +--
>>  1 file changed, 188 insertions(+), 139 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 2a557e4..eab78e7 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -145,6 +145,7 @@ struct blkfront_info
>>  int vdevice;
>>  blkif_vdev_t handle;
>>  enum blkif_state connected;
>> +/* Number of pages per ring buffer */
> 
> Missing full stop, aka '.'.
> 
>>  unsigned int nr_ring_pages;
>>  struct request_queue *rq;
>>  struct list_head grants;
>> @@ -158,7 +159,8 @@ struct blkfront_info
>>  unsigned int max_indirect_segments;
>>  int is_ready;
>>  struct blk_mq_tag_set tag_set;
>> -struct blkfront_ring_info rinfo;
>> +struct blkfront_ring_info *rinfo;
>> +unsigned int nr_rings;
>>  };
>>  
>>  static unsigned int nr_minors;
>> @@ -190,7 +192,7 @@ static DEFINE_SPINLOCK(minor_lock);
>>  ((_segs + SEGS_PER_INDIRECT_FRAME - 1)/SEGS_PER_INDIRECT_FRAME)
>>  
>>  static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo);
>> -static int blkfront_gather_backend_features(struct blkfront_info *info);
>> +static void blkfront_gather_backend_features(struct blkfront_info *info);
>>  
>>  static int get_id_from_freelist(struct blkfront_ring_info *rinfo)
>>  {
>> @@ -443,12 +445,13 @@ static int blkif_queue_request(struct request *req, 
>> struct blkfront_ring_info *r
>>   */
>>  max_grefs += INDIRECT_GREFS(req->nr_phys_segments);
>>  
>> -/* Check if we have enough grants to allocate a requests */
>> -if (info->persistent_gnts_c < max_grefs) {
>> +/* Check if we have enough grants to allocate a requests, we have to
>> + * reserve 'max_grefs' grants because persistent grants are shared by 
>> all
>> + * rings */
> 
> Missing full stop.
> 
>> +if (0 < max_grefs) {
> 
>  ? 0!?
> 
> max_grefs will at least be BLKIF_MAX_SEGMENTS_PER_REQUEST
> so this will always be true.
> 

No,  max_grefs = req->nr_phys_segments;

It's 0 in some cases(flush req?), and gnttable_alloc_grant_references() can not 
handle 0 as the parameter.

> In which ase why not just ..
>>  new_persistent_gnts = 1;
>>  if (gnttab_alloc_grant_references(
>> -max_grefs - info->persistent_gnts_c,
>> -_head) < 0) {
>> +max_grefs, _head) < 0) {
>>  gnttab_request_free_callback(
>>  >callback,
>>  blkif_restart_queue_callback,
> 
> .. move this whole code down? And get rid of 'new_persistent_gnts'
> since it will always be true?
> 

Unless we fix gnttable_alloc_grant_references(0).

> But more importantly, why do we not check for 'info->persistent_gnts_c' 
> anymore?
> 

Info->persistent_gnts_c is for per-device not per-ring, the persistent grants 
may be taken by other queues/rings after we checked the value here.
Which would make get_grant() fail, so we have to reserved enough grants in 
advance.
Those new-allocated grants will be freed if there are enough grants in 
persistent list.

Will fix all other comments for this patch.

Thanks,
Bob

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

Re: [Xen-devel] [PATCH v4 03/10] xen/blkfront: pseudo support for multi hardware queues/rings

[Konrad Rzeszutek Wilk]

On Wed, Nov 04, 2015 at 09:01:11AM +0800, Bob Liu wrote:
> 
> On 11/04/2015 03:44 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 02, 2015 at 12:21:39PM +0800, Bob Liu wrote:
> >> Preparatory patch for multiple hardware queues (rings). The number of
> >> rings is unconditionally set to 1, larger number will be enabled in next
> >> patch so as to make every single patch small and readable.
> > 
> > s/next patch/"xen/blkfront: negotiate number of queues/rings to be used 
> > with backend"
> > 
> >>
> >> Signed-off-by: Bob Liu 
> >> ---
> >>  drivers/block/xen-blkfront.c | 327 
> >> +--
> >>  1 file changed, 188 insertions(+), 139 deletions(-)
> >>
> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >> index 2a557e4..eab78e7 100644
> >> --- a/drivers/block/xen-blkfront.c
> >> +++ b/drivers/block/xen-blkfront.c
> >> @@ -145,6 +145,7 @@ struct blkfront_info
> >>int vdevice;
> >>blkif_vdev_t handle;
> >>enum blkif_state connected;
> >> +  /* Number of pages per ring buffer */
> > 
> > Missing full stop, aka '.'.
> > 
> >>unsigned int nr_ring_pages;
> >>struct request_queue *rq;
> >>struct list_head grants;
> >> @@ -158,7 +159,8 @@ struct blkfront_info
> >>unsigned int max_indirect_segments;
> >>int is_ready;
> >>struct blk_mq_tag_set tag_set;
> >> -  struct blkfront_ring_info rinfo;
> >> +  struct blkfront_ring_info *rinfo;
> >> +  unsigned int nr_rings;
> >>  };
> >>  
> >>  static unsigned int nr_minors;
> >> @@ -190,7 +192,7 @@ static DEFINE_SPINLOCK(minor_lock);
> >>((_segs + SEGS_PER_INDIRECT_FRAME - 1)/SEGS_PER_INDIRECT_FRAME)
> >>  
> >>  static int blkfront_setup_indirect(struct blkfront_ring_info *rinfo);
> >> -static int blkfront_gather_backend_features(struct blkfront_info *info);
> >> +static void blkfront_gather_backend_features(struct blkfront_info *info);
> >>  
> >>  static int get_id_from_freelist(struct blkfront_ring_info *rinfo)
> >>  {
> >> @@ -443,12 +445,13 @@ static int blkif_queue_request(struct request *req, 
> >> struct blkfront_ring_info *r
> >> */
> >>max_grefs += INDIRECT_GREFS(req->nr_phys_segments);
> >>  
> >> -  /* Check if we have enough grants to allocate a requests */
> >> -  if (info->persistent_gnts_c < max_grefs) {
> >> +  /* Check if we have enough grants to allocate a requests, we have to
> >> +   * reserve 'max_grefs' grants because persistent grants are shared by 
> >> all
> >> +   * rings */
> > 
> > Missing full stop.
> > 
> >> +  if (0 < max_grefs) {
> > 
> >  ? 0!?
> > 
> > max_grefs will at least be BLKIF_MAX_SEGMENTS_PER_REQUEST
> > so this will always be true.
> > 
> 
> No,  max_grefs = req->nr_phys_segments;
> 
> It's 0 in some cases(flush req?), and gnttable_alloc_grant_references() can 
> not handle 0 as the parameter.

Yes, indeed they would be zero!
> 
> > In which ase why not just ..
> >>new_persistent_gnts = 1;
> >>if (gnttab_alloc_grant_references(
> >> -  max_grefs - info->persistent_gnts_c,
> >> -  _head) < 0) {
> >> +  max_grefs, _head) < 0) {
> >>gnttab_request_free_callback(
> >>>callback,
> >>blkif_restart_queue_callback,
> > 
> > .. move this whole code down? And get rid of 'new_persistent_gnts'
> > since it will always be true?
> > 
> 
> Unless we fix gnttable_alloc_grant_references(0).

Sure, why not?
> 
> > But more importantly, why do we not check for 'info->persistent_gnts_c' 
> > anymore?
> > 
> 
> Info->persistent_gnts_c is for per-device not per-ring, the persistent grants 
> may be taken by other queues/rings after we checked the value here.
> Which would make get_grant() fail, so we have to reserved enough grants in 
> advance.
> Those new-allocated grants will be freed if there are enough grants in 
> persistent list.
> 
> Will fix all other comments for this patch.
> 
> Thanks,
> Bob

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

Re: [Xen-devel] [PATCH v4 04/10] xen/blkfront: split per device io_lock

[Bob Liu]

On 11/04/2015 04:09 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:40PM +0800, Bob Liu wrote:
>> The per device io_lock became a coarser grained lock after multi-queues/rings
>> was introduced, this patch introduced a fine-grained ring_lock for each ring.
> 
> s/was introduced/was introduced (see commit titled XYZ)/
> 
> s/introdued/introduces/
>>
>> The old io_lock was renamed to dev_lock and only protect the ->grants list
> 
> s/was/is/
> s/protect/protects/
> 
>> which is shared by all rings.
>>
>> Signed-off-by: Bob Liu 
>> ---
>>  drivers/block/xen-blkfront.c | 57 
>> ++--
>>  1 file changed, 34 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index eab78e7..8cc5995 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -121,6 +121,7 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order of 
>> pages to be used for the
>>   */
>>  struct blkfront_ring_info {
>>  struct blkif_front_ring ring;
> 
> Can you add a comment explaining the lock semantic? As in under what 
> conditions
> should it be taken? Like you have it below.
> 
>> +spinlock_t ring_lock;
>>  unsigned int ring_ref[XENBUS_MAX_RING_PAGES];
>>  unsigned int evtchn, irq;
>>  struct work_struct work;
>> @@ -138,7 +139,8 @@ struct blkfront_ring_info {
>>   */
>>  struct blkfront_info
>>  {
>> -spinlock_t io_lock;
>> +/* Lock to proect info->grants list shared by multi rings */
> 
> s/proect/protect/
> 
> Missing full stop.
> 
>> +spinlock_t dev_lock;
> 
> Shouldn't it be right next to what it is protecting?
> 
> That is right below (or above): 'struct list_head grants;'?
> 
>>  struct mutex mutex;
>>  struct xenbus_device *xbdev;
>>  struct gendisk *gd;
>> @@ -224,6 +226,7 @@ static int fill_grant_buffer(struct blkfront_ring_info 
>> *rinfo, int num)
>>  struct grant *gnt_list_entry, *n;
>>  int i = 0;
>>  
>> +spin_lock_irq(>dev_lock);
> 
> Why there? Why not where you add it to the list?
>>  while(i < num) {
>>  gnt_list_entry = kzalloc(sizeof(struct grant), GFP_NOIO);
>>  if (!gnt_list_entry)
>> @@ -242,6 +245,7 @@ static int fill_grant_buffer(struct blkfront_ring_info 
>> *rinfo, int num)
>>  list_add(_list_entry->node, >grants);
> 
> Right here that is?
> 
> You are holding the lock for the duration of 'kzalloc' and 'alloc_page'.
> 
> And more interestingly, GFP_NOIO translates to __GFP_WAIT which means
> it can call 'schedule'. - And you have taken an spinlock. That should
> have thrown lots of warnings?
> 
>>  i++;
>>  }
>> +spin_unlock_irq(>dev_lock);
>>  
>>  return 0;
>>  
>> @@ -254,6 +258,7 @@ out_of_memory:
>>  kfree(gnt_list_entry);
>>  i--;
>>  }
>> +spin_unlock_irq(>dev_lock);
> 
> Just do it around the 'list_del' operation. You are using an
> 'safe'
>>  BUG_ON(i != 0);
>>  return -ENOMEM;
>>  }
>> @@ -265,6 +270,7 @@ static struct grant *get_grant(grant_ref_t *gref_head,
>>  struct grant *gnt_list_entry;
>>  unsigned long buffer_gfn;
>>  
>> +spin_lock(>dev_lock);
>>  BUG_ON(list_empty(>grants));
>>  gnt_list_entry = list_first_entry(>grants, struct grant,
>>node);
>> @@ -272,8 +278,10 @@ static struct grant *get_grant(grant_ref_t *gref_head,
>>  
>>  if (gnt_list_entry->gref != GRANT_INVALID_REF) {
>>  info->persistent_gnts_c--;
>> +spin_unlock(>dev_lock);
>>  return gnt_list_entry;
>>  }
>> +spin_unlock(>dev_lock);
> 
> Just have one spin_unlock. Put it right before the 'if 
> (gnt_list_entry->gref)..'.

That's used to protect info->persistent_gnts_c, will update all other place.

Thanks,
-Bob

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

Re: [Xen-devel] [PATCH v4 05/10] xen/blkfront: negotiate number of queues/rings to be used with backend

[Bob Liu]

On 11/04/2015 04:40 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:41PM +0800, Bob Liu wrote:
>> The number of hardware queues for xen/blkfront is set by parameter
>> 'max_queues'(default 4), while the max value xen/blkback supported is 
>> notified
>> through xenstore("multi-queue-max-queues").
> 
> That is not right.
> 
> s/The number/The max number/
> 
> The second part: ",while the max value xen/blkback supported is..". I think
> you are trying to say: "it is also capped by the max value that
> the xen/blkback exposes through XenStore key 'multi-queue-max-queues'.
> 
>>
>> The negotiated number is the smaller one and would be written back to 
>> xenstore
>> as "multi-queue-num-queues", blkback need to read this negotiated number.
> 
> s/blkback need to read/blkback needs to read this/
> 
>>
>> Signed-off-by: Bob Liu 
>> ---
>>  drivers/block/xen-blkfront.c | 166 
>> +++
>>  1 file changed, 120 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index 8cc5995..23096d7 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>> @@ -98,6 +98,10 @@ static unsigned int xen_blkif_max_segments = 32;
>>  module_param_named(max, xen_blkif_max_segments, int, S_IRUGO);
>>  MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests 
>> (default is 32)");
>>  
>> +static unsigned int xen_blkif_max_queues = 4;
>> +module_param_named(max_queues, xen_blkif_max_queues, uint, S_IRUGO);
>> +MODULE_PARM_DESC(max_queues, "Maximum number of hardware queues/rings used 
>> per virtual disk");
>> +
>>  /*
>>   * Maximum order of pages to be used for the shared ring between front and
>>   * backend, 4KB page granularity is used.
>> @@ -113,6 +117,7 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order of 
>> pages to be used for the
>>   * characters are enough. Define to 20 to keep consist with backend.
>>   */
>>  #define RINGREF_NAME_LEN (20)
>> +#define QUEUE_NAME_LEN (12)
> 
> Little bit of documentation please. Why 12? Why not 31415 for example?
> I presume it is 'queue-%u' and since so that is 7 + 10 (UINT_MAX is
> 4294967295) = 17!
> 
> 
>>  
>>  /*
>>   *  Per-ring info.
>> @@ -695,7 +700,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, u16 
>> sector_size,
>>  
>>  memset(>tag_set, 0, sizeof(info->tag_set));
>>  info->tag_set.ops = _mq_ops;
>> -info->tag_set.nr_hw_queues = 1;
>> +info->tag_set.nr_hw_queues = info->nr_rings;
>>  info->tag_set.queue_depth =  BLK_RING_SIZE(info);
>>  info->tag_set.numa_node = NUMA_NO_NODE;
>>  info->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_SG_MERGE;
>> @@ -1352,6 +1357,51 @@ fail:
>>  return err;
>>  }
>>  
>> +static int write_per_ring_nodes(struct xenbus_transaction xbt,
>> +struct blkfront_ring_info *rinfo, const char 
>> *dir)
>> +{
>> +int err, i;
> 
> Please make 'i' be an unsigned int. Especially as you are using '%u' in the 
> snprintf.
> 
> 
>> +const char *message = NULL;
>> +struct blkfront_info *info = rinfo->dev_info;
>> +
>> +if (info->nr_ring_pages == 1) {
>> +err = xenbus_printf(xbt, dir, "ring-ref", "%u", 
>> rinfo->ring_ref[0]);
>> +if (err) {
>> +message = "writing ring-ref";
>> +goto abort_transaction;
>> +}
>> +pr_info("%s: write ring-ref:%d\n", dir, rinfo->ring_ref[0]);
> 
> Ewww. No.
> 
>> +} else {
>> +for (i = 0; i < info->nr_ring_pages; i++) {
>> +char ring_ref_name[RINGREF_NAME_LEN];
>> +
>> +snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", 
>> i);
>> +err = xenbus_printf(xbt, dir, ring_ref_name,
>> +"%u", rinfo->ring_ref[i]);
>> +if (err) {
>> +message = "writing ring-ref";
>> +goto abort_transaction;
>> +}
>> +pr_info("%s: write ring-ref:%d\n", dir, 
>> rinfo->ring_ref[i]);
> 
> No no please.
> 
>> +}
>> +}
>> +
>> +err = xenbus_printf(xbt, dir, "event-channel", "%u", rinfo->evtchn);
> 
> That is not right.
> 
> That only creates one. But the blkif.h says (And the example agrees)
> that there are N 'event-channel' for N-rings.
> 
> Shouldn't this be part of the above loop?
> 

No, this loop is only for per-ring each with "multipage".

The loop you want is..

>> +if (err) {
>> +message = "writing event-channel";
>> +goto abort_transaction;
>> +}
>> +pr_info("%s: write event-channel:%d\n", dir, rinfo->evtchn);
> 
> Please no.
> 
>> +
>> +return 0;
>> +
>> +abort_transaction:
>> +xenbus_transaction_end(xbt, 1);
>> +if (message)
>> +xenbus_dev_fatal(info->xbdev, err, "%s", message);
>> +
>> +

Re: [Xen-devel] [PATCH v4 05/10] xen/blkfront: negotiate number of queues/rings to be used with backend

[Konrad Rzeszutek Wilk]

On Wed, Nov 04, 2015 at 09:11:10AM +0800, Bob Liu wrote:
> 
> On 11/04/2015 04:40 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 02, 2015 at 12:21:41PM +0800, Bob Liu wrote:
> >> The number of hardware queues for xen/blkfront is set by parameter
> >> 'max_queues'(default 4), while the max value xen/blkback supported is 
> >> notified
> >> through xenstore("multi-queue-max-queues").
> > 
> > That is not right.
> > 
> > s/The number/The max number/
> > 
> > The second part: ",while the max value xen/blkback supported is..". I think
> > you are trying to say: "it is also capped by the max value that
> > the xen/blkback exposes through XenStore key 'multi-queue-max-queues'.
> > 
> >>
> >> The negotiated number is the smaller one and would be written back to 
> >> xenstore
> >> as "multi-queue-num-queues", blkback need to read this negotiated number.
> > 
> > s/blkback need to read/blkback needs to read this/
> > 
> >>
> >> Signed-off-by: Bob Liu 
> >> ---
> >>  drivers/block/xen-blkfront.c | 166 
> >> +++
> >>  1 file changed, 120 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >> index 8cc5995..23096d7 100644
> >> --- a/drivers/block/xen-blkfront.c
> >> +++ b/drivers/block/xen-blkfront.c
> >> @@ -98,6 +98,10 @@ static unsigned int xen_blkif_max_segments = 32;
> >>  module_param_named(max, xen_blkif_max_segments, int, S_IRUGO);
> >>  MODULE_PARM_DESC(max, "Maximum amount of segments in indirect requests 
> >> (default is 32)");
> >>  
> >> +static unsigned int xen_blkif_max_queues = 4;
> >> +module_param_named(max_queues, xen_blkif_max_queues, uint, S_IRUGO);
> >> +MODULE_PARM_DESC(max_queues, "Maximum number of hardware queues/rings 
> >> used per virtual disk");
> >> +
> >>  /*
> >>   * Maximum order of pages to be used for the shared ring between front and
> >>   * backend, 4KB page granularity is used.
> >> @@ -113,6 +117,7 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order 
> >> of pages to be used for the
> >>   * characters are enough. Define to 20 to keep consist with backend.
> >>   */
> >>  #define RINGREF_NAME_LEN (20)
> >> +#define QUEUE_NAME_LEN (12)
> > 
> > Little bit of documentation please. Why 12? Why not 31415 for example?
> > I presume it is 'queue-%u' and since so that is 7 + 10 (UINT_MAX is
> > 4294967295) = 17!
> > 
> > 
> >>  
> >>  /*
> >>   *  Per-ring info.
> >> @@ -695,7 +700,7 @@ static int xlvbd_init_blk_queue(struct gendisk *gd, 
> >> u16 sector_size,
> >>  
> >>memset(>tag_set, 0, sizeof(info->tag_set));
> >>info->tag_set.ops = _mq_ops;
> >> -  info->tag_set.nr_hw_queues = 1;
> >> +  info->tag_set.nr_hw_queues = info->nr_rings;
> >>info->tag_set.queue_depth =  BLK_RING_SIZE(info);
> >>info->tag_set.numa_node = NUMA_NO_NODE;
> >>info->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_SG_MERGE;
> >> @@ -1352,6 +1357,51 @@ fail:
> >>return err;
> >>  }
> >>  
> >> +static int write_per_ring_nodes(struct xenbus_transaction xbt,
> >> +  struct blkfront_ring_info *rinfo, const char 
> >> *dir)
> >> +{
> >> +  int err, i;
> > 
> > Please make 'i' be an unsigned int. Especially as you are using '%u' in the 
> > snprintf.
> > 
> > 
> >> +  const char *message = NULL;
> >> +  struct blkfront_info *info = rinfo->dev_info;
> >> +
> >> +  if (info->nr_ring_pages == 1) {
> >> +  err = xenbus_printf(xbt, dir, "ring-ref", "%u", 
> >> rinfo->ring_ref[0]);
> >> +  if (err) {
> >> +  message = "writing ring-ref";
> >> +  goto abort_transaction;
> >> +  }
> >> +  pr_info("%s: write ring-ref:%d\n", dir, rinfo->ring_ref[0]);
> > 
> > Ewww. No.
> > 
> >> +  } else {
> >> +  for (i = 0; i < info->nr_ring_pages; i++) {
> >> +  char ring_ref_name[RINGREF_NAME_LEN];
> >> +
> >> +  snprintf(ring_ref_name, RINGREF_NAME_LEN, "ring-ref%u", 
> >> i);
> >> +  err = xenbus_printf(xbt, dir, ring_ref_name,
> >> +  "%u", rinfo->ring_ref[i]);
> >> +  if (err) {
> >> +  message = "writing ring-ref";
> >> +  goto abort_transaction;
> >> +  }
> >> +  pr_info("%s: write ring-ref:%d\n", dir, 
> >> rinfo->ring_ref[i]);
> > 
> > No no please.
> > 
> >> +  }
> >> +  }
> >> +
> >> +  err = xenbus_printf(xbt, dir, "event-channel", "%u", rinfo->evtchn);
> > 
> > That is not right.
> > 
> > That only creates one. But the blkif.h says (And the example agrees)
> > that there are N 'event-channel' for N-rings.
> > 
> > Shouldn't this be part of the above loop?
> > 
> 
> No, this loop is only for per-ring each with "multipage".
> 
> The loop you want is..
> 
> >> +  if (err) {
> >> +  message = "writing event-channel";
> >> +  goto abort_transaction;
> >> +  }
> >> +  pr_info("%s: 

Re: [Xen-devel] About Xen bridged pci devices and suspend/resume for the X10SAE motherboard (SuperMicro)

[M. Ivanov]

Hello,

I've experimented with my X10SAE and I think the problem with being
unable to resume after suspending to RAM has something to do with the
PCI Bridge violating the spec by trying to DMA from another address,
since I got a DMAR error about DMA access on address 05:00.0(but in the
bios event log it says Bus06), also the Tundra PCI Bridge is on address
04:00.0. (so like your case with address 7 and 8, but mine's 4 and 5),
btw adding a PCI-E vga seems to change the addresses.

When I disable IOMMU+Xen it works fine, so I mostly sure it's that.
Though I've tried running just Linux with the iommu param on and I
didn't get an error when sleeping/resuming. But I haven't tried doing a
pass-through with it

I've read in a previous thread about a patch of yours for the X10SAE
problem. Which version of Xen can I use it on?(I am currently tinkering
with 4.4.3-RELEASE).

Also I take it - I need to use hack.c to tell xen to create the fake
device,(in my case 05:00.0) and to link it with 04:00.0? But how do I
get that file to compile? Since I don't have a makefile/etc. for it.

Also, can't I just disable the PCI Tundra bridge somehow? And what about
phantom pci and the pciback-hide? Can they help?

I've read about problems regarding the Asmedia controller, so I've
disabled it from the bios, but that didn't help at all.


As for my Xen crash log

DMAR:[DMA Write] Request device [05:00.0] fault addr Can't remember it
DMAR:[fault reason 02] Present bit in context entry is clear

Here is my tree:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3 Processor DRAM
Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3
Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 8 Series/C220 Series
Chipset Family KT Controller (rev 04)
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection
I217-LM (rev 05)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset
High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #1 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #4 (rev d5)
00:1c.5 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #6 (rev d5)
00:1c.6 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #7 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation C226 Series Chipset Family Server
Advanced SKU LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset
Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family
SMBus Controller (rev 05)
00:1f.6 Signal processing controller: Intel Corporation 8 Series Chipset
Family Thermal Management Controller (rev 05)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Cayman PRO [Radeon HD 6950]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI]
Cayman/Antilles HDMI Audio [Radeon HD 6900 Series]
03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network
Connection (rev 03)
04:00.0 PCI bridge: Tundra Semiconductor Corp. Device 8113 (rev 01)
05:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22A
IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx]
06:00.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host
Controller (rev 02)




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

Re: [Xen-devel] [PATCH] MAINTAINERS: adding myself as co-maintainer of vTPM

[Xu, Quan]

>>>On 04.11.2015 at 1:02,  wrote:
> On Fri, 2015-10-30 at 18:57 -0400, Daniel De Graaf wrote:
> > On 10/10/15 12:26, Quan Xu wrote:
> > > Signed-off-by: Quan Xu 
> > Acked-by: Daniel De Graaf 
> 
> Applied, thanks.
> 
Ian / Daniel / Wei,  Thanks.

Quan

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

Re: [Xen-devel] [PATCH v4 04/10] xen/blkfront: split per device io_lock

[Konrad Rzeszutek Wilk]

On Wed, Nov 04, 2015 at 09:07:12AM +0800, Bob Liu wrote:
> 
> On 11/04/2015 04:09 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 02, 2015 at 12:21:40PM +0800, Bob Liu wrote:
> >> The per device io_lock became a coarser grained lock after 
> >> multi-queues/rings
> >> was introduced, this patch introduced a fine-grained ring_lock for each 
> >> ring.
> > 
> > s/was introduced/was introduced (see commit titled XYZ)/
> > 
> > s/introdued/introduces/
> >>
> >> The old io_lock was renamed to dev_lock and only protect the ->grants list
> > 
> > s/was/is/
> > s/protect/protects/
> > 
> >> which is shared by all rings.
> >>
> >> Signed-off-by: Bob Liu 
> >> ---
> >>  drivers/block/xen-blkfront.c | 57 
> >> ++--
> >>  1 file changed, 34 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >> index eab78e7..8cc5995 100644
> >> --- a/drivers/block/xen-blkfront.c
> >> +++ b/drivers/block/xen-blkfront.c
> >> @@ -121,6 +121,7 @@ MODULE_PARM_DESC(max_ring_page_order, "Maximum order 
> >> of pages to be used for the
> >>   */
> >>  struct blkfront_ring_info {
> >>struct blkif_front_ring ring;
> > 
> > Can you add a comment explaining the lock semantic? As in under what 
> > conditions
> > should it be taken? Like you have it below.
> > 
> >> +  spinlock_t ring_lock;
> >>unsigned int ring_ref[XENBUS_MAX_RING_PAGES];
> >>unsigned int evtchn, irq;
> >>struct work_struct work;
> >> @@ -138,7 +139,8 @@ struct blkfront_ring_info {
> >>   */
> >>  struct blkfront_info
> >>  {
> >> -  spinlock_t io_lock;
> >> +  /* Lock to proect info->grants list shared by multi rings */
> > 
> > s/proect/protect/
> > 
> > Missing full stop.
> > 
> >> +  spinlock_t dev_lock;
> > 
> > Shouldn't it be right next to what it is protecting?
> > 
> > That is right below (or above): 'struct list_head grants;'?
> > 
> >>struct mutex mutex;
> >>struct xenbus_device *xbdev;
> >>struct gendisk *gd;
> >> @@ -224,6 +226,7 @@ static int fill_grant_buffer(struct blkfront_ring_info 
> >> *rinfo, int num)
> >>struct grant *gnt_list_entry, *n;
> >>int i = 0;
> >>  
> >> +  spin_lock_irq(>dev_lock);
> > 
> > Why there? Why not where you add it to the list?
> >>while(i < num) {
> >>gnt_list_entry = kzalloc(sizeof(struct grant), GFP_NOIO);
> >>if (!gnt_list_entry)
> >> @@ -242,6 +245,7 @@ static int fill_grant_buffer(struct blkfront_ring_info 
> >> *rinfo, int num)
> >>list_add(_list_entry->node, >grants);
> > 
> > Right here that is?
> > 
> > You are holding the lock for the duration of 'kzalloc' and 'alloc_page'.
> > 
> > And more interestingly, GFP_NOIO translates to __GFP_WAIT which means
> > it can call 'schedule'. - And you have taken an spinlock. That should
> > have thrown lots of warnings?
> > 
> >>i++;
> >>}
> >> +  spin_unlock_irq(>dev_lock);
> >>  
> >>return 0;
> >>  
> >> @@ -254,6 +258,7 @@ out_of_memory:
> >>kfree(gnt_list_entry);
> >>i--;
> >>}
> >> +  spin_unlock_irq(>dev_lock);
> > 
> > Just do it around the 'list_del' operation. You are using an
> > 'safe'
> >>BUG_ON(i != 0);
> >>return -ENOMEM;
> >>  }
> >> @@ -265,6 +270,7 @@ static struct grant *get_grant(grant_ref_t *gref_head,
> >>struct grant *gnt_list_entry;
> >>unsigned long buffer_gfn;
> >>  
> >> +  spin_lock(>dev_lock);
> >>BUG_ON(list_empty(>grants));
> >>gnt_list_entry = list_first_entry(>grants, struct grant,
> >>  node);
> >> @@ -272,8 +278,10 @@ static struct grant *get_grant(grant_ref_t *gref_head,
> >>  
> >>if (gnt_list_entry->gref != GRANT_INVALID_REF) {
> >>info->persistent_gnts_c--;
> >> +  spin_unlock(>dev_lock);
> >>return gnt_list_entry;
> >>}
> >> +  spin_unlock(>dev_lock);
> > 
> > Just have one spin_unlock. Put it right before the 'if 
> > (gnt_list_entry->gref)..'.
> 
> That's used to protect info->persistent_gnts_c, will update all other place.

But you don't mention that in the description - that the lock is suppose
to also protect persistent_gnts_c. Please update that.

> 
> Thanks,
> -Bob

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

Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API

[Chun Yan Liu]

Ian & George, any comments?

>>> On 10/21/2015 at 05:08 PM, in message
<1445418510-19614-4-git-send-email-cy...@suse.com>, Chunyan Liu
 wrote: 
> Add pvusb APIs, including: 
>  - attach/detach (create/destroy) virtual usb controller. 
>  - attach/detach usb device 
>  - list usb controller and usb devices 
>  - some other helper functions 
>  
> Signed-off-by: Chunyan Liu  
> Signed-off-by: Simon Cao  
>  
> --- 
> changes: 
>   - update COMPARE_USB to compare ctrl and port 
>   - add check in usb_add/remove to disable non-Dom0 backend so that 
> not worring about codes which are effective on Dom0 but not 
> compatible on non-Dom0 backend. 
>   - define READ_SUBPATH macro within functions 
>   - do not initialize rc but give it value in each return case 
>   - libxl__strdup gc or NOGC update, internal function using gc, 
> external using NOGC. 
>   - address other comments from George and Ian J. 
>  
>  tools/libxl/Makefile |2 +- 
>  tools/libxl/libxl.c  |   53 ++ 
>  tools/libxl/libxl.h  |   74 ++ 
>  tools/libxl/libxl_device.c   |5 +- 
>  tools/libxl/libxl_internal.h |   18 + 
>  tools/libxl/libxl_osdeps.h   |   13 + 
>  tools/libxl/libxl_pvusb.c| 1451  
> ++ 
>  tools/libxl/libxl_types.idl  |   57 ++ 
>  tools/libxl/libxl_types_internal.idl |1 + 
>  tools/libxl/libxl_utils.c|   16 + 
>  tools/libxl/libxl_utils.h|5 + 
>  11 files changed, 1693 insertions(+), 2 deletions(-) 
>  create mode 100644 tools/libxl/libxl_pvusb.c 
>  
> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile 
> index c5ecec1..ef9ccd3 100644 
> --- a/tools/libxl/Makefile 
> +++ b/tools/libxl/Makefile 
> @@ -103,7 +103,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o  
> libxl_dm.o libxl_pci.o \ 
>   libxl_stream_read.o libxl_stream_write.o \ 
>   libxl_save_callout.o _libxl_save_msgs_callout.o \ 
>   libxl_qmp.o libxl_event.o libxl_fork.o \ 
> - libxl_dom_suspend.o $(LIBXL_OBJS-y) 
> + libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y) 
>  LIBXL_OBJS += libxl_genid.o 
>  LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o 
>   
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c 
> index dacfaae..a050e8b 100644 
> --- a/tools/libxl/libxl.c 
> +++ b/tools/libxl/libxl.c 
> @@ -4218,11 +4218,54 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1) 
>   
>   
> / 
> **/ 
>   
> +/* Macro for defining device remove/destroy functions for usbctrl */ 
> +/* Follo:wing functions are defined: 
> + * libxl_device_usbctrl_remove 
> + * libxl_device_usbctrl_destroy 
> + */ 
> + 
> +#define DEFINE_DEVICE_REMOVE_EXT(type, removedestroy, f)\ 
> +int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \ 
> +uint32_t domid, libxl_device_##type *type,  \ 
> +const libxl_asyncop_how *ao_how)\ 
> +{   \ 
> +AO_CREATE(ctx, domid, ao_how);  \ 
> +libxl__device *device;  \ 
> +libxl__ao_device *aodev;\ 
> +int rc; \ 
> +\ 
> +GCNEW(device);  \ 
> +rc = libxl__device_from_##type(gc, domid, type, device);\ 
> +if (rc != 0) goto out;  \ 
> +\ 
> +GCNEW(aodev);   \ 
> +libxl__prepare_ao_device(ao, aodev);\ 
> +aodev->action = LIBXL__DEVICE_ACTION_REMOVE;\ 
> +aodev->dev = device;\ 
> +aodev->callback = device_addrm_aocomplete;  \ 
> +aodev->force = f;   \ 
> +libxl__initiate_device_##type##_remove(egc, aodev); \ 
> +\ 
> +out:\ 
> +if (rc) return AO_CREATE_FAIL(rc);  \ 
> +return AO_INPROGRESS;   \ 
> +} 
> + 
> + 
> +DEFINE_DEVICE_REMOVE_EXT(usbctrl, remove, 0) 
> +DEFINE_DEVICE_REMOVE_EXT(usbctrl, destroy, 1) 
> + 
> +#undef 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 62277
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 62277
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 62277
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 62277
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 62277

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-amd64-pvgrub  3 host-install(3) broken in 63294 pass in 63485
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 63294 pass in 
63485
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 63294 pass in 
63485
 test-amd64-i386-xl-xsm3 host-install(3)  broken in 63310 pass in 63485
 test-amd64-amd64-xl-qcow2 3 host-install(3)  broken in 63310 pass in 63485
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 
63310 pass in 63485
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 63310 pass in 
63485
 test-amd64-amd64-xl-credit2   3 host-install(3)  broken in 63324 pass in 63485
 test-amd64-i386-xl-raw3 host-install(3)  broken in 63324 pass in 63485
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
in 63324 pass in 63485
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 63324 
pass in 63485
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 63324 pass in 
63485
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63310 pass in 63294
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
63228
 test-amd64-amd64-xl-rtds  6 xen-bootfail pass in 63228
 test-amd64-amd64-i386-pvgrub  6 xen-bootfail pass in 63294
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 63310
 test-amd64-i386-pair 10 xen-boot/dst_host   fail pass in 63310
 test-amd64-i386-pair  9 xen-boot/src_host   fail pass in 63310
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host  fail pass in 63310
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host  fail pass in 63310
 test-amd64-amd64-amd64-pvgrub  6 xen-boot   fail pass in 63324
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail pass in 63324
 test-amd64-amd64-xl-qcow2 6 xen-bootfail pass in 63338
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail pass in 63374
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail pass in 63374
 test-amd64-amd64-pair10 xen-boot/dst_host   fail pass in 63404
 test-amd64-amd64-pair 9 xen-boot/src_host   fail pass in 63404
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-install fail pass in 63404

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63228 blocked in 62277
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 63324 like 62277
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62277
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62277
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62277

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 63228 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 

[Xen-devel] [xen-4.3-testing test] 63524: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs. 
63212

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   3 host-install(3)   broken pass in 63464
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 63464 pass 
in 63524
 test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail in 63464 
pass in 63524

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

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-armhf-armhf-xl   6 xen-boot  fail in 63464 never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-amd64-i386-migrupgrade 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass

version targeted for testing:
 xen  e875e0e5fcc5912f71422b53674a97e5c0ae77be
baseline version:
 xen  85ca813ec23c5a60680e4a13777dad530065902b

Last test of basis63212  2015-10-22 10:03:01 Z   12 days
Failing since 63360  2015-10-29 13:39:04 Z5 days4 attempts
Testing same since63381  2015-10-30 18:44:54 Z4 days3 attempts


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

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  broken
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 60684
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host fail 

Re: [Xen-devel] [PATCH 2/3] xen/x86: Query for paddr_bits in early_cpu_detect()

[Konrad Rzeszutek Wilk]

On Mon, Nov 02, 2015 at 05:59:44PM +, Andrew Cooper wrote:
> It is __read_mostly, so repeatedly writing to it is suboptiomal.  As the
> MTRRs have already been set up, nothing good will come from its value
> changing across CPUs.

Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> ---
>  xen/arch/x86/cpu/common.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index 02f2504..ac8a258 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -207,6 +207,9 @@ static void __init early_cpu_detect(void)
>   /* Leaf 0x1 capabilities filled in early for Xen. */
>   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = cap0;
>   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = cap4;
> +
> + if ( cpuid_eax(0x8000) >= 0x8008 )
> + paddr_bits = cpuid_eax(0x8008) & 0xff;
>  }
>  
>  static void __cpuinit generic_identify(struct cpuinfo_x86 *c)
> @@ -254,8 +257,6 @@ static void __cpuinit generic_identify(struct cpuinfo_x86 
> *c)
>   }
>   if ( c->extended_cpuid_level >= 0x8004 )
>   get_model_name(c); /* Default name */
> - if ( c->extended_cpuid_level >= 0x8008 )
> - paddr_bits = cpuid_eax(0x8008) & 0xff;
>   }
>  
>   /* Might lift BIOS max_leaf=3 limit. */
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 3/3] xen/x86: Cleanup of early cpuid handling

[Konrad Rzeszutek Wilk]

On Mon, Nov 02, 2015 at 05:59:45PM +, Andrew Cooper wrote:
> Use register names for variables, rather than their content for leaf 1.
> Reduce the number of cpuid instructions issued.  Also drop some trailing
> whitespace.
> 
> No functional change.

I checked for that and:

Reviewed-by: Konrad Rzeszutek Wilk 

> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> ---
>  xen/arch/x86/cpu/common.c | 69 
> +++
>  1 file changed, 34 insertions(+), 35 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
> index ac8a258..c71fb13 100644
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -180,7 +180,7 @@ static inline u32 phys_pkg_id(u32 cpuid_apic, int 
> index_msb)
>  static void __init early_cpu_detect(void)
>  {
>   struct cpuinfo_x86 *c = _cpu_data;
> - u32 cap4, tfms, cap0, misc;
> + u32 eax, ebx, ecx, edx;
>  
>   c->x86_cache_alignment = 32;
>  
> @@ -192,21 +192,21 @@ static void __init early_cpu_detect(void)
>  
>   c->x86_vendor = get_cpu_vendor(c->x86_vendor_id, gcv_host_early);
>  
> - cpuid(0x0001, , , , );
> - c->x86 = (tfms >> 8) & 15;
> - c->x86_model = (tfms >> 4) & 15;
> + cpuid(0x0001, , , , );
> + c->x86 = (eax >> 8) & 15;
> + c->x86_model = (eax >> 4) & 15;
>   if (c->x86 == 0xf)
> - c->x86 += (tfms >> 20) & 0xff;
> + c->x86 += (eax >> 20) & 0xff;
>   if (c->x86 >= 0x6)
> - c->x86_model += ((tfms >> 16) & 0xF) << 4;
> - c->x86_mask = tfms & 15;
> - cap0 &= ~cleared_caps[cpufeat_word(X86_FEATURE_FPU)];
> - cap4 &= ~cleared_caps[cpufeat_word(X86_FEATURE_XMM3)];
> - if (cap0 & cpufeat_mask(X86_FEATURE_CLFLSH))
> - c->x86_cache_alignment = ((misc >> 8) & 0xff) * 8;
> + c->x86_model += ((eax >> 16) & 0xF) << 4;
> + c->x86_mask = eax & 15;
> + edx &= ~cleared_caps[cpufeat_word(X86_FEATURE_FPU)];
> + ecx &= ~cleared_caps[cpufeat_word(X86_FEATURE_XMM3)];
> + if (edx & cpufeat_mask(X86_FEATURE_CLFLSH))
> + c->x86_cache_alignment = ((ebx >> 8) & 0xff) * 8;
>   /* Leaf 0x1 capabilities filled in early for Xen. */
> - c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = cap0;
> - c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = cap4;
> + c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
> + c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = ecx;
>  
>   if ( cpuid_eax(0x8000) >= 0x8008 )
>   paddr_bits = cpuid_eax(0x8008) & 0xff;
> @@ -214,29 +214,29 @@ static void __init early_cpu_detect(void)
>  
>  static void __cpuinit generic_identify(struct cpuinfo_x86 *c)
>  {
> - u32 tfms, capability, excap, ebx;
> + u32 eax, ebx, ecx, edx, tmp;
>  
>   /* Get vendor name */
>   cpuid(0x, >cpuid_level,
> (int *)>x86_vendor_id[0],
> (int *)>x86_vendor_id[8],
> (int *)>x86_vendor_id[4]);
> - 
> +
>   c->x86_vendor = get_cpu_vendor(c->x86_vendor_id, gcv_host_late);
>   /* Initialize the standard set of capabilities */
>   /* Note that the vendor-specific code below might override */
> - 
> +
>   /* Intel-defined flags: level 0x0001 */
> - cpuid(0x0001, , , , );
> - c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = capability;
> - c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = excap;
> - c->x86 = (tfms >> 8) & 15;
> - c->x86_model = (tfms >> 4) & 15;
> + cpuid(0x0001, , , , );
> + c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
> + c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = ecx;
> + c->x86 = (eax >> 8) & 15;
> + c->x86_model = (eax >> 4) & 15;
>   if (c->x86 == 0xf)
> - c->x86 += (tfms >> 20) & 0xff;
> + c->x86 += (eax >> 20) & 0xff;
>   if (c->x86 >= 0x6)
> - c->x86_model += ((tfms >> 16) & 0xF) << 4;
> - c->x86_mask = tfms & 15;
> + c->x86_model += ((eax >> 16) & 0xF) << 4;
> + c->x86_mask = eax & 15;
>   c->apicid = phys_pkg_id((ebx >> 24) & 0xFF, 0);
>   c->phys_proc_id = c->apicid;
>   if ( cpu_has(c, X86_FEATURE_CLFLSH) )
> @@ -249,12 +249,12 @@ static void __cpuinit generic_identify(struct 
> cpuinfo_x86 *c)
>   /* AMD-defined flags: level 0x8001 */
>   c->extended_cpuid_level = cpuid_eax(0x8000);
>   if ( (c->extended_cpuid_level & 0x) == 0x8000 ) {
> - if ( c->extended_cpuid_level >= 0x8001 ) {
> - c->x86_capability[cpufeat_word(X86_FEATURE_SYSCALL)]
> - = cpuid_edx(0x8001);
> - c->x86_capability[cpufeat_word(X86_FEATURE_LAHF_LM)]
> - = cpuid_ecx(0x8001);
> - }
> + if ( c->extended_cpuid_level >= 

[Xen-devel] [qemu-mainline baseline-only test] 38243: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38243 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38243/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-installfail blocked in 38230
 test-amd64-amd64-xl  21 guest-start/debian.repeatfail   like 38230
 test-amd64-amd64-xl-xsm  21 guest-start/debian.repeatfail   like 38230
 test-amd64-amd64-xl-credit2  21 guest-start/debian.repeatfail   like 38230

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 qemuu3a958f559ecd0511583d27b10011fa7f3cf79b63
baseline version:
 qemuu7bc8e0c967a4ef77657174d28af775691e18b4ce

Last test of basis38230  2015-10-30 22:25:36 Z3 days
Testing same since38243  2015-11-03 04:22:03 Z0 days1 attempts


People who touched revisions under test:
  Christian Borntraeger 
  Cornelia Huck 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  James Hogan 
  Kevin Wolf 
  Leon Alrae 
  Markus Armbruster 
  Paolo Bonzini 
  Pavel Butsykin 
  Peter Maydell 
  Sai Pavan Boddu 
  Sai Pavan Boddu 
  Stefan Hajnoczi 
  Yongbok Kim 

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