Re: [Xen-devel] [PATCH] VT-d: Chop down the DMAR_OPERATION_TIMEOUT to a low number of milliseconds.

[Xu, Quan]

On March 15, 2016 12:38pm, Tian, Kevin  wrote:
> > From: Xu, Quan
> > Sent: Monday, March 14, 2016 3:16 PM
> >
> > We confirmed with VT-d hardware team that 1ms is large enough for
> > IOMMU internal flush. So We can change the DMAR_OPERATION_TIMEOUT
> from
> > 1000 ms to 1 ms.
> >
> > Signed-off-by: Quan Xu 
> >
> 
> Acked-by: Kevin Tian 

Kevin, thanks!!
Quan

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

Re: [Xen-devel] [PATCH v2] vmx: Restore debug registers when injecting #DB traps

[Tian, Kevin]

> From: Ross Lagerwall [mailto:ross.lagerw...@citrix.com]
> Sent: Saturday, March 12, 2016 12:24 AM
> 
> Commit a929bee0e652 ("x86/vmx: Fix injection of #DB traps following
> XSA-156") prevents an infinite loop in certain #DB traps. However, it
> changed the behavior to not call hvm_hw_inject_trap() for #DB and #AC
> traps which which means that the debug registers are not restored
> correctly and nullified commit b56ae5b48c38 ("VMX: fix/adjust trap
> injection").
> 
> To fix this, restore the original code path through hvm_inject_trap(),
> but ensure that the struct hvm_trap is populated with all the required
> data.
> 
> Signed-off-by: Ross Lagerwall 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH] VT-d: Chop down the DMAR_OPERATION_TIMEOUT to a low number of milliseconds.

[Tian, Kevin]

> From: Xu, Quan
> Sent: Monday, March 14, 2016 3:16 PM
> 
> We confirmed with VT-d hardware team that 1ms is large enough for IOMMU
> internal flush. So We can change the DMAR_OPERATION_TIMEOUT from 1000 ms
> to 1 ms.
> 
> Signed-off-by: Quan Xu 
> 

Acked-by: Kevin Tian 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   3 host-install(3) broken REGR. vs. 83004
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 83004
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
83004

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
86149

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

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

version targeted for testing:
 xen  4db81940ee9eb82b3b3895c449ccbbab4a7147a4
baseline version:
 xen  ccc7adf9cff5d5f93720afcc1d0f7227d50feab2

Last test of basis83004  2016-02-18 14:47:44 Z   25 days
Failing since 84923  2016-03-01 13:41:07 Z   13 days   16 attempts
Testing same since85979  2016-03-11 05:16:24 Z3 days5 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Konrad Rzeszutek Wilk 
  Wei Liu 

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

[Xen-devel] Sharing memory between two virtual machine on XEN Hypervisor

[Zakirasafi]

*Dear All*

*I have installed two virtual machine on XEN hyper-visor. Now I want two
write a program which share the memory between two virtual machine. Could
any help me please.*



*Thanks and Regards,*
Zakira Inayat
Ph.D Scholar in University of Malaya, Malaysia
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-4.1 test] 86197: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 66399
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 66399

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  3 host-install(3)   broken pass in 86144
 test-armhf-armhf-xl-xsm  11 guest-startfail in 85641 pass in 86197
 test-armhf-armhf-xl-credit2   6 xen-boot   fail in 85641 pass in 86197
 test-armhf-armhf-xl-cubietruck  9 debian-install   fail in 86070 pass in 86197
 test-armhf-armhf-xl-credit2  11 guest-startfail in 86070 pass in 86197
 test-armhf-armhf-xl-rtds 14 guest-stop fail in 86144 pass in 85972
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 85641
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat  fail pass in 85972
 test-armhf-armhf-xl  15 guest-start/debian.repeat   fail pass in 86070
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 86144

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 85641 like 66399
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399

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

version targeted for testing:
 linuxb9a9cfdbf7254f4a231cc8ddf685cc29d3a9c6e5
baseline version:
 linux07cc49f66973f49a391c91bf4b158fa0f2562ca8

Last test of basis66399  2015-12-15 18:20:39 Z   90 days
Failing since 78925  2016-01-24 13:50:39 Z   50 days   53 attempts
Testing same since85582  2016-03-06 13:53:34 Z8 d

Re: [Xen-devel] [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

[Toshi Kani]

On Tue, 2016-03-15 at 01:29 +0100, Luis R. Rodriguez wrote:
> I like this approach more as it stuff more PAT setup on its own type
> of calls, but:
> 
> On Sat, Mar 12, 2016 at 12:55:44PM +0100, Borislav Petkov wrote:
> > diff --git a/arch/x86/kernel/cpu/mtrr/main.c
> > b/arch/x86/kernel/cpu/mtrr/main.c
> > index 10f8d4796240..5c442b4bd52a 100644
> > --- a/arch/x86/kernel/cpu/mtrr/main.c
> > +++ b/arch/x86/kernel/cpu/mtrr/main.c
> > @@ -759,8 +761,11 @@ void __init mtrr_bp_init(void)
> >     }
> >     }
> >  
> > -   if (!mtrr_enabled())
> > +   if (!__mtrr_enabled) {
> >     pr_info("MTRR: Disabled\n");
> > +   pat_disable("PAT disabled by MTRR");
> > +   pat_setup();
> > +   }
> >  }
> 
> This hunk would break PAT on Xen.

Can you try the attached patches?  They apply on top of my original patch-
set.  With this change, PAT code generally supports Xen, and the PAT init
code in Xen is now removed.  If they look OK, I will reorganize the patch
series.

Thanks,
-ToshiFrom: Toshi Kani 

Add support of PAT emulation that matches with the PAT MSR.

---
 arch/x86/mm/pat.c |   73 +++--
 1 file changed, 43 insertions(+), 30 deletions(-)

diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 1ff8aa9..565a478 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -40,7 +40,7 @@
 static bool boot_cpu_done;
 
 static int __read_mostly __pat_enabled = IS_ENABLED(CONFIG_X86_PAT);
-static void pat_disable_init(void);
+static void pat_emu_init(void);
 
 void pat_disable(const char *reason)
 {
@@ -52,7 +52,7 @@ void pat_disable(const char *reason)
 	__pat_enabled = 0;
 	pr_info("x86/PAT: %s\n", reason);
 
-	pat_disable_init();
+	pat_emu_init();
 }
 
 static int __init nopat(char *str)
@@ -239,40 +239,53 @@ static void pat_ap_init(u64 pat)
 	wrmsrl(MSR_IA32_CR_PAT, pat);
 }
 
-static void pat_disable_init(void)
+static void pat_emu_init(void)
 {
-	u64 pat;
-	static int disable_init_done;
+	u64 pat = 0;
+	static int emu_init_done;
 
-	if (disable_init_done)
+	if (emu_init_done)
 		return;
 
-	/*
-	 * No PAT. Emulate the PAT table that corresponds to the two
-	 * cache bits, PWT (Write Through) and PCD (Cache Disable). This
-	 * setup is the same as the BIOS default setup when the system
-	 * has PAT but the "nopat" boot option has been specified. This
-	 * emulated PAT table is used when MSR_IA32_CR_PAT returns 0.
-	 *
-	 * PTE encoding:
-	 *
-	 *   PCD
-	 *   |PWT  PAT
-	 *   ||slot
-	 *   000WB : _PAGE_CACHE_MODE_WB
-	 *   011WT : _PAGE_CACHE_MODE_WT
-	 *   102UC-: _PAGE_CACHE_MODE_UC_MINUS
-	 *   113UC : _PAGE_CACHE_MODE_UC
-	 *
-	 * NOTE: When WC or WP is used, it is redirected to UC- per
-	 * the default setup in __cachemode2pte_tbl[].
-	 */
-	pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
-	  PAT(4, WB) | PAT(5, WT) | PAT(6, UC_MINUS) | PAT(7, UC);
+	if (cpu_has_pat) {
+		/*
+		 * CPU supports PAT. Initialize the PAT table to match with
+		 * the PAT MSR value. This setup is used by "nopat" boot
+		 * option, or by virtual machine environments which do not
+		 * support MTRRs but support PAT.
+		 *
+		 * If the MSR returns 0, it is considered invalid and emulate
+		 * as No PAT.
+		 */
+		rdmsrl(MSR_IA32_CR_PAT, pat);
+	}
+
+	if (!pat) {
+		/*
+		 * No PAT. Emulate the PAT table that corresponds to the two
+		 * cache bits, PWT (Write Through) and PCD (Cache Disable).
+		 * This setup is also the same as the BIOS default setup.
+		 *
+		 * PTE encoding:
+		 *
+		 *   PCD
+		 *   |PWT  PAT
+		 *   ||slot
+		 *   000WB : _PAGE_CACHE_MODE_WB
+		 *   011WT : _PAGE_CACHE_MODE_WT
+		 *   102UC-: _PAGE_CACHE_MODE_UC_MINUS
+		 *   113UC : _PAGE_CACHE_MODE_UC
+		 *
+		 * NOTE: When WC or WP is used, it is redirected to UC- per
+		 * the default setup in __cachemode2pte_tbl[].
+		 */
+		pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
+		  PAT(4, WB) | PAT(5, WT) | PAT(6, UC_MINUS) | PAT(7, UC);
+	}
 
 	pat_init_cache_modes(pat);
 
-	disable_init_done = 1;
+	emu_init_done = 1;
 }
 
 void pat_init(void)
@@ -281,7 +294,7 @@ void pat_init(void)
 	struct cpuinfo_x86 *c = &boot_cpu_data;
 
 	if (!pat_enabled()) {
-		pat_disable_init();
+		pat_emu_init();
 		return;
 	}
 
From: Toshi Kani 

Delete the PAT table initialization code from Xen as this case
is now supported by PAT.

---
 arch/x86/include/asm/mtrr.h |2 +-
 arch/x86/kernel/cpu/mtrr/main.c |4 ++--
 arch/x86/xen/enlighten.c|9 -
 3 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index a965e74..77420c3 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -86,7 +86,7 @@ static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
 }
 static inline void mtrr_bp_init(void)
 {
-	pat_disable("PAT dis

[Xen-devel] [PATCH v4 2/3] tools: change checkpointed_stream's type from int to xc_migration_stream_t

[Wen Congyang]

checkpointed_stream is also renamed to stream_type

Signed-off-by: Wen Congyang 
Acked-by: Wei Liu 
---
v2->v3: Rename checkpointed_stream to stream_type
 tools/libxc/include/xenguest.h  |  8 
 tools/libxc/xc_nomigrate.c  |  4 ++--
 tools/libxc/xc_sr_restore.c | 10 +-
 tools/libxc/xc_sr_save.c|  8 
 tools/libxl/libxl_save_helper.c | 42 -
 5 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index cf521c3..4f0b06e 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -86,14 +86,14 @@ typedef enum {
  * @parm xch a handle to an open hypervisor interface
  * @parm fd the file descriptor to save a domain to
  * @parm dom the id of the domain
- * @param checkpointed_stream XC_MIG_STREAM_NONE if the far end of the stream
+ * @param stream_type XC_MIG_STREAM_NONE if the far end of the stream
  *doesn't use checkpointing
  * @return 0 on success, -1 on failure
  */
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t 
max_iters,
uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
struct save_callbacks* callbacks, int hvm,
-   int checkpointed_stream);
+   xc_migration_stream_t stream_type);
 
 /* callbacks provided by xc_domain_restore */
 struct restore_callbacks {
@@ -121,7 +121,7 @@ struct restore_callbacks {
  * @parm hvm non-zero if this is a HVM restore
  * @parm pae non-zero if this HVM domain has PAE support enabled
  * @parm superpages non-zero to allocate guest memory with superpages
- * @parm checkpointed_stream non-zero if the far end of the stream is using 
checkpointing
+ * @parm stream_type non-zero if the far end of the stream is using 
checkpointing
  * @parm callbacks non-NULL to receive a callback to restore toolstack
  *   specific data
  * @return 0 on success, -1 on failure
@@ -131,7 +131,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, 
uint32_t dom,
   domid_t store_domid, unsigned int console_evtchn,
   unsigned long *console_mfn, domid_t console_domid,
   unsigned int hvm, unsigned int pae, int superpages,
-  int checkpointed_stream,
+  xc_migration_stream_t stream_type,
   struct restore_callbacks *callbacks);
 
 /**
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
index c9124df..08e1f8c 100644
--- a/tools/libxc/xc_nomigrate.c
+++ b/tools/libxc/xc_nomigrate.c
@@ -23,7 +23,7 @@
 int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t 
max_iters,
uint32_t max_factor, uint32_t flags,
struct save_callbacks* callbacks, int hvm,
-   int checkpointed_stream)
+   xc_migration_stream_t stream_type)
 {
 errno = ENOSYS;
 return -1;
@@ -34,7 +34,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t 
dom,
   domid_t store_domid, unsigned int console_evtchn,
   unsigned long *console_mfn, domid_t console_domid,
   unsigned int hvm, unsigned int pae, int superpages,
-  int checkpointed_stream,
+  xc_migration_stream_t stream_type,
   struct restore_callbacks *callbacks)
 {
 errno = ENOSYS;
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index d4d33fd..819401d 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -725,7 +725,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, 
uint32_t dom,
   domid_t store_domid, unsigned int console_evtchn,
   unsigned long *console_gfn, domid_t console_domid,
   unsigned int hvm, unsigned int pae, int superpages,
-  int checkpointed_stream,
+  xc_migration_stream_t stream_type,
   struct restore_callbacks *callbacks)
 {
 struct xc_sr_context ctx =
@@ -739,16 +739,16 @@ int xc_domain_restore(xc_interface *xch, int io_fd, 
uint32_t dom,
 ctx.restore.console_domid = console_domid;
 ctx.restore.xenstore_evtchn = store_evtchn;
 ctx.restore.xenstore_domid = store_domid;
-ctx.restore.checkpointed = checkpointed_stream;
+ctx.restore.checkpointed = stream_type;
 ctx.restore.callbacks = callbacks;
 
 /* Sanity checks for callbacks. */
-if ( checkpointed_stream )
+if ( stream_type )
 assert(callbacks->checkpoint);
 
 DPRINTF("fd %d, dom %u, hvm %u, pae %u, superpages %d"
-", checkpointed_stream %d", io_fd, dom, hvm, pae,
-superpages, checkpointed_stream);
+", stream_type %d", io_fd, dom, hvm, pae,
+superpages, stream_type);
 
 if ( xc_domain_getin

[Xen-devel] [PATCH v4 3/3] libxl: rename checkpointed_stream to stream_type

[Wen Congyang]

Signed-off-by: Wen Congyang 
---
v3->v4: Remove the new macro, and updte the macro LIBXL_HAVE_CHECKPOINTED_STREAM
 tools/libxl/libxl.c  |  4 ++--
 tools/libxl/libxl.h  |  4 +++-
 tools/libxl/libxl_create.c   |  4 ++--
 tools/libxl/libxl_dom_save.c |  6 +++---
 tools/libxl/libxl_internal.h |  2 +-
 tools/libxl/libxl_save_callout.c |  4 ++--
 tools/libxl/libxl_stream_read.c  |  4 ++--
 tools/libxl/libxl_stream_write.c |  2 +-
 tools/libxl/libxl_types.idl  |  2 +-
 tools/libxl/xl_cmdimpl.c | 16 
 10 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 93e228d..7579dd2 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -876,7 +876,7 @@ int libxl_domain_remus_start(libxl_ctx *ctx, 
libxl_domain_remus_info *info,
 dss->live = 1;
 dss->debug = 0;
 dss->remus = info;
-dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_REMUS;
+dss->stream_type = LIBXL_CHECKPOINTED_STREAM_REMUS;
 
 assert(info);
 
@@ -937,7 +937,7 @@ int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, 
int fd, int flags,
 dss->type = type;
 dss->live = flags & LIBXL_SUSPEND_LIVE;
 dss->debug = flags & LIBXL_SUSPEND_DEBUG;
-dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_NONE;
+dss->stream_type = LIBXL_CHECKPOINTED_STREAM_NONE;
 
 rc = libxl__fd_flags_modify_save(gc, dss->fd,
  ~(O_NONBLOCK|O_NDELAY), 0,
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index f9e3ef5..c55094b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -879,7 +879,9 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
libxl_mac *src);
 /*
  * LIBXL_HAVE_CHECKPOINTED_STREAM
  *
- * If this is defined, then libxl_checkpointed_stream exists.
+ * If this is defined, then libxl_checkpointed_stream exists, and the
+ * libxl_domain_create_restore() interface's parameter checkpointed_stream
+ * is renamed to stream_type
  */
 #define LIBXL_HAVE_CHECKPOINTED_STREAM 1
 
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f1028bc..b28eb89 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -993,7 +993,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 libxl_domain_config *const d_config = dcs->guest_config;
 const int restore_fd = dcs->restore_fd;
 libxl__domain_build_state *const state = &dcs->build_state;
-const int checkpointed_stream = dcs->restore_params.checkpointed_stream;
+const int stream_type = dcs->restore_params.stream_type;
 
 if (rc) {
 domcreate_rebuild_done(egc, dcs, rc);
@@ -1033,7 +1033,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 dcs->srs.completion_callback = domcreate_stream_done;
 
 if (restore_fd >= 0) {
-switch (checkpointed_stream) {
+switch (stream_type) {
 case LIBXL_CHECKPOINTED_STREAM_REMUS:
 libxl__remus_restore_setup(egc, dcs);
 /* fall through */
diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
index f3288b9..ff92ef0 100644
--- a/tools/libxl/libxl_dom_save.c
+++ b/tools/libxl/libxl_dom_save.c
@@ -338,7 +338,7 @@ void libxl__domain_save(libxl__egc *egc, 
libxl__domain_save_state *dss)
 unsigned int nr_vnodes = 0, nr_vmemranges = 0, nr_vcpus = 0;
 libxl__domain_suspend_state *dsps = &dss->dsps;
 
-if (dss->checkpointed_stream != LIBXL_CHECKPOINTED_STREAM_NONE && !r_info) 
{
+if (dss->stream_type != LIBXL_CHECKPOINTED_STREAM_NONE && !r_info) {
 LOG(ERROR, "Migration stream is checkpointed, but there's no "
"checkpoint info!");
 rc = ERROR_INVAL;
@@ -383,12 +383,12 @@ void libxl__domain_save(libxl__egc *egc, 
libxl__domain_save_state *dss)
 goto out;
 }
 
-if (dss->checkpointed_stream == LIBXL_CHECKPOINTED_STREAM_REMUS) {
+if (dss->stream_type == LIBXL_CHECKPOINTED_STREAM_REMUS) {
 if (libxl_defbool_val(r_info->compression))
 dss->xcflags |= XCFLAGS_CHECKPOINT_COMPRESS;
 }
 
-if (dss->checkpointed_stream == LIBXL_CHECKPOINTED_STREAM_NONE)
+if (dss->stream_type == LIBXL_CHECKPOINTED_STREAM_NONE)
 callbacks->suspend = libxl__domain_suspend_callback;
 
 callbacks->switch_qemu_logdirty = 
libxl__domain_suspend_common_switch_qemu_logdirty;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 005fe53..0aada0d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3128,7 +3128,7 @@ struct libxl__domain_save_state {
 libxl_domain_type type;
 int live;
 int debug;
-int checkpointed_stream;
+libxl_checkpointed_stream stream_type;
 const libxl_domain_remus_info *remus;
 /* private */
 int rc;
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 7f1f5d4..133d74e 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tool

[Xen-devel] [PATCH v4 1/3] libxc: move migration_stream's definition to xenguest.h

[Wen Congyang]

xc_domain_save() and xc_domain_restore's parameter will use this type,
so it should be public.

Signed-off-by: Wen Congyang 
Acked-by: Wei Liu 
---
v2->v3: Rename MIG_STREAM_* to XC_MIG_STREAM_*
 tools/libxc/include/xenguest.h |  7 ++-
 tools/libxc/xc_sr_common.h | 10 --
 tools/libxc/xc_sr_save.c   | 12 ++--
 3 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index affc42b..cf521c3 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -75,13 +75,18 @@ struct save_callbacks {
 void* data;
 };
 
+typedef enum {
+XC_MIG_STREAM_NONE, /* plain stream */
+XC_MIG_STREAM_REMUS,
+} xc_migration_stream_t;
+
 /**
  * This function will save a running domain.
  *
  * @parm xch a handle to an open hypervisor interface
  * @parm fd the file descriptor to save a domain to
  * @parm dom the id of the domain
- * @param checkpointed_stream MIG_STREAM_NONE if the far end of the stream
+ * @param checkpointed_stream XC_MIG_STREAM_NONE if the far end of the stream
  *doesn't use checkpointing
  * @return 0 on success, -1 on failure
  */
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 66f595f..e7568b5 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -180,16 +180,6 @@ struct xc_sr_context
 
 xc_dominfo_t dominfo;
 
-/*
- * migration stream
- * 0: Plain VM
- * 1: Remus
- */
-enum {
-MIG_STREAM_NONE, /* plain stream */
-MIG_STREAM_REMUS,
-} migration_stream;
-
 union /* Common save or restore data. */
 {
 struct /* Save data. */
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index e258b7c..ab59673 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -629,7 +629,7 @@ static int send_domain_memory_live(struct xc_sr_context 
*ctx)
 if ( rc )
 goto out;
 
-if ( ctx->save.debug && ctx->save.checkpointed != MIG_STREAM_NONE )
+if ( ctx->save.debug && ctx->save.checkpointed != XC_MIG_STREAM_NONE )
 {
 rc = verify_frames(ctx);
 if ( rc )
@@ -758,7 +758,7 @@ static int save(struct xc_sr_context *ctx, uint16_t 
guest_type)
 
 if ( ctx->save.live )
 rc = send_domain_memory_live(ctx);
-else if ( ctx->save.checkpointed != MIG_STREAM_NONE )
+else if ( ctx->save.checkpointed != XC_MIG_STREAM_NONE )
 rc = send_domain_memory_checkpointed(ctx);
 else
 rc = send_domain_memory_nonlive(ctx);
@@ -778,7 +778,7 @@ static int save(struct xc_sr_context *ctx, uint16_t 
guest_type)
 if ( rc )
 goto err;
 
-if ( ctx->save.checkpointed != MIG_STREAM_NONE )
+if ( ctx->save.checkpointed != XC_MIG_STREAM_NONE )
 {
 /*
  * We have now completed the initial live portion of the checkpoint
@@ -799,7 +799,7 @@ static int save(struct xc_sr_context *ctx, uint16_t 
guest_type)
 if ( rc <= 0 )
 goto err;
 }
-} while ( ctx->save.checkpointed != MIG_STREAM_NONE );
+} while ( ctx->save.checkpointed != XC_MIG_STREAM_NONE );
 
 xc_report_progress_single(xch, "End of stream");
 
@@ -845,8 +845,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t 
dom,
 ctx.save.checkpointed = checkpointed_stream;
 
 /* If altering migration_stream update this assert too. */
-assert(checkpointed_stream == MIG_STREAM_NONE ||
-   checkpointed_stream == MIG_STREAM_REMUS);
+assert(checkpointed_stream == XC_MIG_STREAM_NONE ||
+   checkpointed_stream == XC_MIG_STREAM_REMUS);
 
 /*
  * TODO: Find some time to better tweak the live migration algorithm.
-- 
2.5.0




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

Re: [Xen-devel] [PATCH] tools: Restrict configuration of qemu processes

[Jim Fehlig]

Opps, forgot to cc the tools maintainers, sorry. I can resend if needed.

Regards,
Jim

On 03/14/2016 07:08 PM, Jim Fehlig wrote:
> Commit 6ef823fd added '-nodefaults' to the qemu args created by
> libxl, which is a good step in restricting qemu's default
> configuration. This change takes another step by adding
> -no-user-config, which ignores any user-provided config files in
> sysconfdir. Together, -nodefaults and -no-user-config allow Xen
> to avoid unkown and uncontrolled qemu configuration.
>
> Both options are also added to the qemu invocation in the
> xen-qemu-dom0-disk-backend systemd service file.
>
> Signed-off-by: Jim Fehlig 
> ---
>  tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 +
>  tools/libxl/libxl_dm.c| 6 ++
>  2 files changed, 7 insertions(+)
>
> diff --git 
> a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in 
> b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> index acf61a8..f56775b 100644
> --- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> +++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
> @@ -14,6 +14,7 @@ ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
>  ExecStart=@qemu_xen_systemd@ -xen-domid 0 \
>   -xen-attach -name dom0 -nographic -M xenpv -daemonize \
>   -monitor /dev/null -serial /dev/null -parallel /dev/null \
> + -nodefaults -no-user-config \
>   -pidfile @XEN_RUN_DIR@/qemu-dom0.pid
>  
>  [Install]
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 4aca38e..cfda24c 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -828,6 +828,12 @@ static int libxl__build_device_model_args_new(libxl__gc 
> *gc,
>   */
>  flexarray_append(dm_args, "-nodefaults");
>  
> +/*
> + * Do not use any of the user-provided config files in sysconfdir,
> + * avoiding unkown and uncontrolled configuration.
> + */
> +flexarray_append(dm_args, "-no-user-config");
> +
>  if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
>  flexarray_append(dm_args, "-xen-attach");
>  }


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

[Xen-devel] [PATCH] tools: Restrict configuration of qemu processes

[Jim Fehlig]

Commit 6ef823fd added '-nodefaults' to the qemu args created by
libxl, which is a good step in restricting qemu's default
configuration. This change takes another step by adding
-no-user-config, which ignores any user-provided config files in
sysconfdir. Together, -nodefaults and -no-user-config allow Xen
to avoid unkown and uncontrolled qemu configuration.

Both options are also added to the qemu invocation in the
xen-qemu-dom0-disk-backend systemd service file.

Signed-off-by: Jim Fehlig 
---
 tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in | 1 +
 tools/libxl/libxl_dm.c| 6 ++
 2 files changed, 7 insertions(+)

diff --git a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in 
b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
index acf61a8..f56775b 100644
--- a/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
+++ b/tools/hotplug/Linux/systemd/xen-qemu-dom0-disk-backend.service.in
@@ -14,6 +14,7 @@ ExecStartPre=/bin/mkdir -p @XEN_RUN_DIR@
 ExecStart=@qemu_xen_systemd@ -xen-domid 0 \
-xen-attach -name dom0 -nographic -M xenpv -daemonize \
-monitor /dev/null -serial /dev/null -parallel /dev/null \
+   -nodefaults -no-user-config \
-pidfile @XEN_RUN_DIR@/qemu-dom0.pid
 
 [Install]
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 4aca38e..cfda24c 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -828,6 +828,12 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
  */
 flexarray_append(dm_args, "-nodefaults");
 
+/*
+ * Do not use any of the user-provided config files in sysconfdir,
+ * avoiding unkown and uncontrolled configuration.
+ */
+flexarray_append(dm_args, "-no-user-config");
+
 if (b_info->type == LIBXL_DOMAIN_TYPE_PV) {
 flexarray_append(dm_args, "-xen-attach");
 }
-- 
2.1.4


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

[Xen-devel] [PATCH] docs: update FLASK cmd line instructions

[Doug Goldstein]

The command line instructions for FLASK include a note on how to compile
Xen with FLASK but the note was out of date after the change to Kconfig.

Signed-off-by: Doug Goldstein 
---
CC: Ian Jackson 
CC: Jan Beulich 
CC: Keir Fraser 
CC: Tim Deegan 
CC: Konrad Rzeszutek Wilk 
CC: Daniel De Graaf 

Not sure if you want backticks around `make -C menuconfig`. I also figured
we should route people towards menuconfig by default. The committer of
this patch is welcome to change the wording or style in anyway they see
fit.

---
 docs/misc/xen-command-line.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index ca77e3b..949e210 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -665,8 +665,8 @@ to use the default.
 > Default: `permissive`
 
 Specify how the FLASK security server should be configured.  This option is 
only
-available if the hypervisor was compiled with XSM support (which can be enabled
-by setting XSM\_ENABLE = y in .config).
+available if the hypervisor was compiled with FLASK support.  This can be
+enabled by running make -C xen menuconfig and enabling XSM and FLASK.
 
 * `permissive`: This is intended for development and is not suitable for use
   with untrusted guests.  If a policy is provided by the bootloader, it will be
-- 
2.4.10


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

[Xen-devel] can xenrt be used to test libxenlight/libvirt APIs directly?

[Zhangbo (Oscar)]

Hi all:
   I'm not sure but doubt that xenRT is used to just test xenserver/xapi, it's 
not
appropriate for testing libxenlight, am I right?

   Although it uses libvirt to do guest lifecycle jobs, see file
" ./exec/xenrt/lib/libvirt/guest.py", but it seems that these functions are all
used by testcases for xenserver, this means that, it doesn't test libvirt APIs
either.

   So the question is:
 Is xenRT just used to test xenserver/xenapi, rather than libxenlight or
libvirt APIs ?


   Thanks in advance.

Oscar.

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

Re: [Xen-devel] [PATCH 1/2] x86/mm/pat: Change pat_disable() to emulate PAT table

[Luis R. Rodriguez]

I like this approach more as it stuff more PAT setup on its own type
of calls, but:

On Sat, Mar 12, 2016 at 12:55:44PM +0100, Borislav Petkov wrote:
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index 10f8d4796240..5c442b4bd52a 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -759,8 +761,11 @@ void __init mtrr_bp_init(void)
>   }
>   }
>  
> - if (!mtrr_enabled())
> + if (!__mtrr_enabled) {
>   pr_info("MTRR: Disabled\n");
> + pat_disable("PAT disabled by MTRR");
> + pat_setup();
> + }
>  }

This hunk would break PAT on Xen.

  Luis

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

Re: [Xen-devel] [RFC PATCH v1] Splitting off stubdom to a different tree

[Samuel Thibault]

Hello,

Wei Liu, on Thu 10 Mar 2016 16:46:39 +, wrote:
> 1. There are some open questions -- see individual commits.

Not sure I have seen them all, but here are some bits of answers:

- Not sure what the version number of stubdom.git should be.

Indeed. I don't really have an opinion on this, I'd let Xen maintainer
choose.

- (README file in stubdom.git) Not sure what I should put in here other
than building.

stubdom/ used to have a README file, which is now in
docs/misc/stubdom.txt, which should probably be moved to stubdom.git.

Samuel

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

Re: [Xen-devel] [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

[Luis R. Rodriguez]

On Fri, Mar 11, 2016 at 06:16:36PM -0700, Toshi Kani wrote:
> On Fri, 2016-03-11 at 15:34 -0800, Luis R. Rodriguez wrote:
> > On Fri, Mar 11, 2016 at 3:56 PM, Toshi Kani  wrote:
> > > On Fri, 2016-03-11 at 23:17 +0100, Luis R. Rodriguez wrote:
> > > > On Fri, Mar 11, 2016 at 11:57:12AM -0700, Toshi Kani wrote:
> > > > > On Fri, 2016-03-11 at 10:24 +0100, Borislav Petkov wrote:
> > > > > > On Thu, Mar 10, 2016 at 09:45:46PM -0700, Toshi Kani wrote:
> > > > > > > MTRR manages PAT initialization as it implements a rendezvous
> > > > > > > handler that initializes PAT as part of MTRR initialization.
>  :
> > > > > 
> > > > > No, it does not fix it. The problem in this particular case, i.e.
> > > > > MTRR disabled by its MSR, is that mtrr_bp_init() calls pat_init()
> > > > > (as PAT enabled) and initializes PAT on BSP. After APs are
> > > > > launched, we need the MTRR's rendezvous handler to initialize PAT
> > > > > on APs to be consistent with BSP. However, MTRR rendezvous handler
> > > > > is no-op since MTRR is disabled.
> > > > 
> > > > This seems like a hack on enabling PAT through MTRR code, can we have
> > > > a PAT rendezvous handler on its own, or provide a generic rendezvous
> > > > handler that lets you deal with whatever interfaces need setup. Then
> > > > conflicts can just be negotiated early.
> > > 
> > > The MTRR code can be enhanced so that the rendezvous handler can handle
> > > MTRR and PAT state independently.  I noted this case as (*) in the
> > > table of this patch description.  This is a separate item, however.
> > > 
> > > MTRR calling PAT was not a hack (as I suppose we did not have VMs at
> > > that time), although this can surely be improved.  As Intel SDM state
> > > below, both MTRR and PAT require the same procedure, and the PAT
> > > initialization sequence is defined in the MTRR section.
> > > 
> > > ===
> > > 11.12.4 Programming the PAT
> > >  :
> > > The operating system is responsible for insuring that changes to a PAT
> > > entry occur in a manner that maintains the consistency of the processor
> > > caches and translation lookaside buffers (TLB). This is accomplished by
> > > following the procedure as specified in Section 11.11.8, “MTRR
> > > Considerations in MP Systems,” for changing the value of an MTRR in a
> > > multiple processor system. It requires a specific sequence of
> > > operations that includes flushing the processors caches and TLBs.
> > > ===
> > > 
> > > > What I'm after is seeing if we can ultimately disable MTRR on kernel
> > > > code but still have PAT enabled. I realize you've mentioned BIOS code
> > > > may use some MTRR setup code but this is only true for some systems.
> > > > I know for a fact Xen cannot use MTRR, it seems qemu32 does not
> > > > enable
> > > > it either. So why not have the ability to skip through its set up ?
> > > 
> > > MTRR support has two meanings:
> > >  1) The kernel keeps the MTRR setup by BIOS.
> > >  2) The kernel modifies the MTRR setup.
> > > 
> > > I am in a position that we need 1) but 2).
> > 
> > I take it you meant "but not 2)" ? 
> 
> Yes. :)

OK -- we are in agreement but we know 1) is only needed for a portion of
systems: Xen and qemu32 systems fly with no MTRR set up, and as such it
would be incorrect to run MTRR code on such systems. To these systems
MTRR functionality code should be dead, since PAT currently depends on
MTRR PAT should also be dead but as the report you're fixing shows
it wasn't. That's an issue for qemu that uses the regular x86 init path
but not for Xen. Its different for Xen as the hypervisor is the one that
set up the MSR_IA32_CR_PAT for each CPU. The *only* thing Xen does is:

void xen_start_kernel(void)
{
...
rdmsrl(MSR_IA32_CR_PAT, pat);   
pat_init_cache_modes(pat); 
...
}

Fortunately we only have to call pat_init_cache_modes() once, its
not per-CPU. Xen has shown then that you *can* live with PAT without
any of the complex MTRR setup / code. Please add to your table the
Xen case as well then as its important to consider. If you make it
a strong requirement to have MTRR enabled to enable PAT you'd
be disabling PAT on Xen guest boots.

As-is then your this patch which calls pat_disable() on mtrr_bp_init() for the
case where MTRR is disabled would essentially break PAT on Xen guests, so this
cannot be done. It is no longer true that if MTRR is disabled you can force
disable PAT. To do what you want you want to do we have to consider Xen.

I don't think its a good idea to keep PAT initialization meshed together
with MTRR and making it a strong requirement on enabling PAT. The MTRR
code is extremely complex. I'd like instead to encourage for us to
consider for this situation to let PAT become a first class citizen,
if MTRR is disabled but you've enabled PAT you should be able to use
it, just as Xen does. There are more reasons to enable such setup than
not to. Long term I'm advocating to see if we can get an ACPI le

[Xen-devel] [PATCH v9]xen: sched: convert RTDS from time to event driven model

[Tianyang Chen]

Budget replenishment and enforcement are separated by adding
a replenishment timer, which fires at the next most imminent
release time of all runnable vcpus.

A replenishment queue has been added to keep track of all vcpus that
are runnable.

The following functions have major changes to manage the replenishment
events and timer.

repl_handler(): It is a timer handler which is re-programmed
to fire at the nearest vcpu deadline to replenish vcpus.

rt_schedule(): picks the highest runnable vcpu based on cpu
affinity and ret.time will be passed to schedule(). If an idle
vcpu is picked, -1 is returned to avoid busy-waiting. repl_update()
has been removed.

rt_vcpu_wake(): when a vcpu wakes up, it tickles instead of
picking one from the run queue.

rt_context_saved(): when context switching is finished, the
preempted vcpu will be put back into the runq.

Simplified funtional graph:

schedule.c SCHEDULE_SOFTIRQ:
rt_schedule():
[spin_lock]
burn_budget(scurr)
snext = runq_pick()
[spin_unlock]

sched_rt.c TIMER_SOFTIRQ
replenishment_timer_handler()
[spin_lock]
 {
replenish(i)
runq_tickle(i)
}>
program_timer()
[spin_lock]

Signed-off-by: Tianyang Chen 
Signed-off-by: Meng Xu 
Signed-off-by: Dagaen Golomb 
---
changes since v8:
Replaced spin_lock_irqsave with spin_lock_irq.
Bug fix in burn_budget() where budget == 0.
Removed unnecessary tickling in the timer handler when
vcpus have the same deadline.

changes since v7:
Coding sytle.
Added a flag to indicate that a vcpu was depleted.
Added a local list including updated vcpus in the
timer handler. It is used to decide which vcpu should
tickle.

changes since v6:
Removed unnecessary vcpu_on_q() checks for runq_insert()
Renamed replenishment queue related functions without
underscores
New replq_reinsert() function for rt_vcpu_wake()

changes since v5:
Removed unnecessary vcpu_on_replq() checks
deadline_queue_insert() returns a flag to indicate if it's
needed to re-program the timer
Removed unnecessary timer checks
Added helper functions to remove vcpus from queues
coding style

Changes since v4:
removed unnecessary replenishment queue checks in vcpu_wake()
extended replq_remove() to all cases in vcpu_sleep()
used _deadline_queue_insert() helper function for both queues
_replq_insert() and _replq_remove() program timer internally

Changes since v3:
removed running queue.
added repl queue to keep track of repl events.
timer is now per scheduler.
timer is init on a valid cpu in a cpupool.
---
 xen/common/sched_rt.c |  437 ++---
 1 file changed, 341 insertions(+), 96 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index bfed2e2..b491915 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -3,7 +3,9 @@
  * EDF scheduling is a real-time scheduling algorithm used in embedded field.
  *
  * by Sisu Xi, 2013, Washington University in Saint Louis
- * and Meng Xu, 2014, University of Pennsylvania
+ * Meng Xu, 2014-2016, University of Pennsylvania
+ * Tianyang Chen, 2016, University of Pennsylvania
+ * Dagaen Golomb, 2016, University of Pennsylvania
  *
  * based on the code of credit Scheduler
  */
@@ -16,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -87,7 +90,7 @@
 #define RTDS_DEFAULT_BUDGET (MICROSECS(4000))
 
 #define UPDATE_LIMIT_SHIFT  10
-#define MAX_SCHEDULE(MILLISECS(1))
+
 /*
  * Flags
  */
@@ -115,6 +118,18 @@
 #define RTDS_delayed_runq_add (1<<__RTDS_delayed_runq_add)
 
 /*
+ * The replenishment timer handler needs to check this bit
+ * to know where a replenished vcpu was, when deciding which
+ * vcpu should tickle.
+ * A replenished vcpu should tickle if it was moved from the
+ * depleted queue to the run queue.
+ * + Set in burn_budget() if a vcpu has zero budget left.
+ * + Cleared and checked in the repenishment handler.
+ */
+#define __RTDS_was_depleted 3
+#define RTDS_was_depleted (1<<__RTDS_was_depleted)
+
+/*
  * rt tracing events ("only" 512 available!). Check
  * include/public/trace.h for more details.
  */
@@ -142,6 +157,9 @@ static cpumask_var_t *_cpumask_scratch;
  */
 static unsigned int nr_rt_ops;
 
+/* handler for the replenishment timer */
+static void repl_handler(void *data);
+
 /*
  * Systme-wide private data, include global RunQueue/DepletedQ
  * Global lock is referenced by schedule_data.schedule_lock from all
@@ -152,7 +170,9 @@ struct rt_private {
 struct list_head sdom;  /* list of availalbe domains, used for dump */
 struct list_head runq;  /* ordered list of runnable vcpus */
 struct list_head depletedq; /* unordered list of depleted vcpus */
+struct list_head replq; /* ordered list of vcpus that need 
replenishment */
 cpumask_t tickled;  /* c

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linuxa26555498849489fb87139a15abe2eeb8a366ae7
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  249 days
Failing since 59348  2015-07-10 04:24:05 Z  248 days  177 attempts
Testing same since86187  2016-03-14 04:26:31 Z0 days1 attempts


4183 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm 

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 53c1329529e47a7da3a0bb5169b5fe0b44f4307e
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   97 days
Failing since 65593  2015-12-08 23:44:51 Z   96 days  104 attempts
Testing same since86194  2016-03-14 06:52:14 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  Jordan Justen 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leif Lindholm 
  Liming Gao 
  Mark Rutland 
  Marvin Haeuser 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH 0/5] Allow tmem to be disabled via Kconfig

[Konrad Rzeszutek Wilk]

On Mon, Mar 14, 2016 at 03:29:20PM -0500, Doug Goldstein wrote:
> First swag at allowing tmem to be disabled via Kconfig. I've only build
> tested this first version because I expect a bunch of feedback that will
> necessitate changes and then v2 will hopefully be worth testing. The
> first 4 patches can go in regardless of the final patch and are really
> just cleanups.

Reviewed-by: Konrad Rzeszutek Wilk 

Let me first run them through regression bucket before commiting.

Thank you!
> 
> Doug Goldstein (5):
>   tmem: add tmem_disable() function
>   tmem: drop direct usage of opt_tmem
>   tmem: make tmem_freeable_pages() check tmem status
>   tmem: don't assume stdbool.h is included
>   tmem: allow tmem to be disabled with Kconfig
> 
>  xen/arch/x86/hvm/hvm.c |  4 
>  xen/arch/x86/setup.c   |  6 +++---
>  xen/arch/x86/x86_64/compat/entry.S |  4 
>  xen/arch/x86/x86_64/entry.S|  4 
>  xen/common/Kconfig | 11 +++
>  xen/common/Makefile|  7 ---
>  xen/common/memory.c|  2 +-
>  xen/common/page_alloc.c|  8 
>  xen/common/tmem.c  |  3 +++
>  xen/include/xen/tmem.h | 26 ++
>  xen/include/xen/tmem_xen.h | 17 +
>  11 files changed, 81 insertions(+), 11 deletions(-)
> 
> -- 
> 2.4.10
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] [PATCH 3/5] tmem: make tmem_freeable_pages() check tmem status

[Doug Goldstein]

Most callers of tmem_freeable_pages() checked to see if tmem was enabled
before calling tmem_freeable_pages() but not all of them did. This
seemed like an oversight and to avoid similar situations like that, stick
the check of tmem into tmem_freeable_pages().

Signed-off-by: Doug Goldstein 
---
CC: Konrad Rzeszutek Wilk 
---
 xen/common/page_alloc.c | 4 ++--
 xen/common/tmem.c   | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 1e6246e..98e30e5 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -652,7 +652,7 @@ static void __init setup_low_mem_virq(void)
 static void check_low_mem_virq(void)
 {
 unsigned long avail_pages = total_avail_pages +
-(tmem_enabled() ? tmem_freeable_pages() : 0) - outstanding_claims;
+tmem_freeable_pages() - outstanding_claims;
 
 if ( unlikely(avail_pages <= low_mem_virq_th) )
 {
@@ -738,7 +738,7 @@ static struct page_info *alloc_heap_pages(
  * Others try tmem pools then fail.  This is a workaround until all
  * post-dom0-creation-multi-page allocations can be eliminated.
  */
-if ( tmem_enabled() && ((order == 0) || (order >= 9)) &&
+if ( ((order == 0) || (order >= 9)) &&
  (total_avail_pages <= midsize_alloc_zone_pages) &&
  tmem_freeable_pages() )
 goto try_tmem;
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 0436e49..16e249a 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -2837,6 +2837,9 @@ void *tmem_relinquish_pages(unsigned int order, unsigned 
int memflags)
 
 unsigned long tmem_freeable_pages(void)
 {
+if ( !tmem_enabled() )
+return 0;
+
 return tmem_page_list_pages + _atomic_read(freeable_page_count);
 }
 
-- 
2.4.10


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

[Xen-devel] [PATCH 1/5] tmem: add tmem_disable() function

[Doug Goldstein]

Instead of manipulating the opt_tmem variable directly utilize a wrapper
function.

Signed-off-by: Doug Goldstein 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/setup.c   | 4 ++--
 xen/include/xen/tmem_xen.h | 5 +
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8431f06..5485468 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 #include 
-#include  /* for opt_tmem only */
+#include 
 #include 
 #include 
 #include 
@@ -1247,7 +1247,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 {
printk(XENLOG_WARNING
   "TMEM physical RAM limit exceeded, disabling TMEM\n");
-   opt_tmem = 0;
+   tmem_disable();
 }
 }
 else
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index c770f3e..f516bbe 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -69,6 +69,11 @@ static inline bool_t tmem_enabled(void)
 return opt_tmem;
 }
 
+static inline void tmem_disable(void)
+{
+opt_tmem = 0;
+}
+
 /*
  * Memory free page list management
  */
-- 
2.4.10


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

[Xen-devel] [PATCH 2/5] tmem: drop direct usage of opt_tmem

[Doug Goldstein]

Don't use the opt_tmem variable to check if tmem is enabled, instead use
the tmem_enabled() helper function everywhere.

Signed-off-by: Doug Goldstein 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/setup.c| 2 +-
 xen/common/memory.c | 2 +-
 xen/common/page_alloc.c | 8 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 5485468..7181624 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1243,7 +1243,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 init_domheap_pages(s, e);
 }
 
-if ( opt_tmem )
+if ( tmem_enabled() )
 {
printk(XENLOG_WARNING
   "TMEM physical RAM limit exceeded, disabling TMEM\n");
diff --git a/xen/common/memory.c b/xen/common/memory.c
index ef57219..c7fca96 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -202,7 +202,7 @@ static void populate_physmap(struct memop_args *a)
 
 if ( unlikely(!page) )
 {
-if ( !opt_tmem || a->extent_order )
+if ( !tmem_enabled() || a->extent_order )
 gdprintk(XENLOG_INFO,
  "Could not allocate order=%u extent: id=%d 
memflags=%#x (%u of %u)\n",
  a->extent_order, d->domain_id, a->memflags,
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 22e8feb..1e6246e 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -652,7 +652,7 @@ static void __init setup_low_mem_virq(void)
 static void check_low_mem_virq(void)
 {
 unsigned long avail_pages = total_avail_pages +
-(opt_tmem ? tmem_freeable_pages() : 0) - outstanding_claims;
+(tmem_enabled() ? tmem_freeable_pages() : 0) - outstanding_claims;
 
 if ( unlikely(avail_pages <= low_mem_virq_th) )
 {
@@ -738,7 +738,7 @@ static struct page_info *alloc_heap_pages(
  * Others try tmem pools then fail.  This is a workaround until all
  * post-dom0-creation-multi-page allocations can be eliminated.
  */
-if ( opt_tmem && ((order == 0) || (order >= 9)) &&
+if ( tmem_enabled() && ((order == 0) || (order >= 9)) &&
  (total_avail_pages <= midsize_alloc_zone_pages) &&
  tmem_freeable_pages() )
 goto try_tmem;
@@ -984,7 +984,7 @@ static void free_heap_pages(
 avail[node][zone] += 1 << order;
 total_avail_pages += 1 << order;
 
-if ( opt_tmem )
+if ( tmem_enabled() )
 midsize_alloc_zone_pages = max(
 midsize_alloc_zone_pages, total_avail_pages / MIDSIZE_ALLOC_FRAC);
 
@@ -1755,7 +1755,7 @@ int assign_pages(
 {
 if ( unlikely((d->tot_pages + (1 << order)) > d->max_pages) )
 {
-if ( !opt_tmem || order != 0 || d->tot_pages != d->max_pages )
+if ( !tmem_enabled() || order != 0 || d->tot_pages != d->max_pages 
)
 gprintk(XENLOG_INFO, "Over-allocation for domain %u: "
 "%u > %u\n", d->domain_id,
 d->tot_pages + (1 << order), d->max_pages);
-- 
2.4.10


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

[Xen-devel] [PATCH 4/5] tmem: don't assume stdbool.h is included

[Doug Goldstein]

tmem_xen.h assumes that all users will have already included stdbool.h
which might not always be true.

Signed-off-by: Doug Goldstein 
---
CC: Konrad Rzeszutek Wilk 
---
 xen/include/xen/tmem_xen.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index f516bbe..b95bde9 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -9,6 +9,7 @@
 #ifndef __XEN_TMEM_XEN_H__
 #define __XEN_TMEM_XEN_H__
 
+#include 
 #include  /* heap alloc/free */
 #include 
 #include  /* xmalloc/xfree */
-- 
2.4.10


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

[Xen-devel] [PATCH 5/5] tmem: allow tmem to be disabled with Kconfig

[Doug Goldstein]

Wrap the various tmem functions with the Kconfig generated CONFIG_TMEM
option allowing users to build Xen without tmem support.

Signed-off-by: Doug Goldstein 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/hvm/hvm.c |  4 
 xen/arch/x86/x86_64/compat/entry.S |  4 
 xen/arch/x86/x86_64/entry.S|  4 
 xen/common/Kconfig | 11 +++
 xen/common/Makefile|  7 ---
 xen/include/xen/tmem.h | 26 ++
 xen/include/xen/tmem_xen.h | 11 +++
 7 files changed, 64 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 255a1d6..e05a4d9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5311,6 +5311,10 @@ typedef unsigned long hvm_hypercall_t(
 #define compat_grant_table_op hvm_grant_table_op_compat32
 #define do_arch_1 paging_domctl_continuation
 
+#ifndef CONFIG_TMEM
+#define do_tmem_op do_ni_hypercall
+#endif
+
 static const struct {
 hvm_hypercall_t *native;
 hvm_hypercall_t *compat;
diff --git a/xen/arch/x86/x86_64/compat/entry.S 
b/xen/arch/x86/x86_64/compat/entry.S
index 927439d..5218f8a 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -345,6 +345,10 @@ compat_crash_page_fault:
 #define compat_kexec_op do_ni_hypercall
 #endif
 
+#ifndef CONFIG_TMEM
+#define do_tmem_op do_ni_hypercall
+#endif
+
 #ifndef CONFIG_XENOPROF
 #define compat_xenoprof_op do_ni_hypercall
 #endif
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index dd7f114..cab9763 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -681,6 +681,10 @@ ENTRY(exception_table)
 #define do_kexec_op do_ni_hypercall
 #endif
 
+#ifndef CONFIG_TMEM
+#define do_tmem_op do_ni_hypercall
+#endif
+
 #ifndef CONFIG_XENOPROF
 #define do_xenoprof_op do_ni_hypercall
 #endif
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 8fbc46d..24eb60b 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -87,6 +87,17 @@ config LATE_HWDOM
 
  If unsure, say N.
 
+# Enables transactional memory support
+config TMEM
+   bool "Transaction Memory Support"
+   default y
+   ---help---
+ fill me out
+
+config TMEM_COMPAT
+   bool
+   default y if COMPAT && TMEM
+
 # Adds support for Xenoprof
 config XENOPROF
def_bool y
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 82625a5..8a3c87a 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -49,8 +49,8 @@ obj-y += sysctl.o
 obj-y += tasklet.o
 obj-y += time.o
 obj-y += timer.o
-obj-y += tmem.o
-obj-y += tmem_xen.o
+obj-$(CONFIG_TMEM) += tmem.o
+obj-$(CONFIG_TMEM) += tmem_xen.o
 obj-y += trace.o
 obj-y += version.o
 obj-y += vm_event.o
@@ -65,7 +65,8 @@ obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz 
unlzma unlzo unlz4
 obj-$(perfc)   += perfc.o
 obj-$(crash_debug) += gdbstub.o
 
-obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o kernel.o memory.o 
multicall.o tmem_xen.o xlat.o)
+obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o kernel.o memory.o 
multicall.o xlat.o)
+obj-$(CONFIG_TMEM_COMPAT) += compat/tmem_xen.o
 
 subdir-$(CONFIG_X86) += hvm
 
diff --git a/xen/include/xen/tmem.h b/xen/include/xen/tmem.h
index 32a542a..414a14d 100644
--- a/xen/include/xen/tmem.h
+++ b/xen/include/xen/tmem.h
@@ -11,9 +11,35 @@
 
 struct xen_sysctl_tmem_op;
 
+#ifdef CONFIG_TMEM
 extern int tmem_control(struct xen_sysctl_tmem_op *op);
 extern void tmem_destroy(void *);
 extern void *tmem_relinquish_pages(unsigned int, unsigned int);
 extern unsigned long tmem_freeable_pages(void);
+#else
+static inline int
+tmem_control(struct xen_sysctl_tmem_op *op)
+{
+return -ENOSYS;
+}
+
+static inline void
+tmem_destroy(void *p)
+{
+return;
+}
+
+static inline void *
+tmem_relinquish_pages(unsigned int x, unsigned int y)
+{
+return NULL;
+}
+
+static inline unsigned long
+tmem_freeable_pages(void)
+{
+return 0;
+}
+#endif /* CONFIG_TMEM */
 
 #endif /* __XEN_TMEM_H__ */
diff --git a/xen/include/xen/tmem_xen.h b/xen/include/xen/tmem_xen.h
index b95bde9..33f75e0 100644
--- a/xen/include/xen/tmem_xen.h
+++ b/xen/include/xen/tmem_xen.h
@@ -64,6 +64,7 @@ static inline bool_t tmem_shared_auth(void)
 return opt_tmem_shared_auth;
 }
 
+#ifdef CONFIG_TMEM
 extern bool_t opt_tmem;
 static inline bool_t tmem_enabled(void)
 {
@@ -74,6 +75,16 @@ static inline void tmem_disable(void)
 {
 opt_tmem = 0;
 }
+#else
+static inline bool_t tmem_enabled(void)
+{
+return false;
+}
+
+static inline void tmem_disable(void)
+{
+}
+#endif /* CONFIG_TMEM */
 
 /*
  * Memory free page list management
-- 
2.4.10


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

[Xen-devel] [PATCH 0/5] Allow tmem to be disabled via Kconfig

[Doug Goldstein]

First swag at allowing tmem to be disabled via Kconfig. I've only build
tested this first version because I expect a bunch of feedback that will
necessitate changes and then v2 will hopefully be worth testing. The
first 4 patches can go in regardless of the final patch and are really
just cleanups.

Doug Goldstein (5):
  tmem: add tmem_disable() function
  tmem: drop direct usage of opt_tmem
  tmem: make tmem_freeable_pages() check tmem status
  tmem: don't assume stdbool.h is included
  tmem: allow tmem to be disabled with Kconfig

 xen/arch/x86/hvm/hvm.c |  4 
 xen/arch/x86/setup.c   |  6 +++---
 xen/arch/x86/x86_64/compat/entry.S |  4 
 xen/arch/x86/x86_64/entry.S|  4 
 xen/common/Kconfig | 11 +++
 xen/common/Makefile|  7 ---
 xen/common/memory.c|  2 +-
 xen/common/page_alloc.c|  8 
 xen/common/tmem.c  |  3 +++
 xen/include/xen/tmem.h | 26 ++
 xen/include/xen/tmem_xen.h | 17 +
 11 files changed, 81 insertions(+), 11 deletions(-)

-- 
2.4.10


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  c2b9b97775e9de061dd72b22fb96293daaa77f98
baseline version:
 xen  71b165d2d4215c1556b62231d127a233225360ee

Last test of basis86218  2016-03-14 13:01:52 Z0 days
Testing same since86241  2016-03-14 19:03:05 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  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=c2b9b97775e9de061dd72b22fb96293daaa77f98
+ . ./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 
c2b9b97775e9de061dd72b22fb96293daaa77f98
+ branch=xen-unstable-smoke
+ revision=c2b9b97775e9de061dd72b22fb96293daaa77f98
+ . ./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-coverity
+ '[' xc2b9b97775e9de061dd72b22fb96293daaa77f98 = 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:941

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Peter Zijlstra]

On Mon, Mar 14, 2016 at 11:10:16AM -0700, Andy Lutomirski wrote:
> A couple of the wrmsr users actually care about performance.  These
> are the ones involved in context switching and, to a lesser extent, in
> switching in and out of guest mode.

Right, this very much includes a number of perf MSRs. Some of those get
called from the context switch path, others from the NMI handler.

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

Re: [Xen-devel] [RFC] tools: don't use qemu default config

[Jim Fehlig]

On 03/11/2016 03:28 PM, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 11, 2016 at 03:08:30PM -0700, Jim Fehlig wrote:
>> I recently changed SUSE's Xen package to use the distro qemu instead of 
>> building
>> qemu-xen. This got some other eyes looking at Xen's use of qemu and it was
>> noticed that libxl and xen-qemu-dom0-disk-backend.service do not include
>> '-no-user-config' when invoking qemu. The latter also does not include
>> '-nodefaults'. Commit 6ef823fd added '-nodefaults' to the qemu args created 
>> by
>> libxl, but missed adding it to the qemu args in 
>> xen-qemu-dom0-disk-backend.service.
>>
>> I _think_ adding '-nodefaults' to the qemu args in the service file is
>> non-controversial. What do folks think of also adding '-no-user-config'? It
>> seems the global config in /etc/qemu/qemu.conf would end up being more
>> problematic than helpful for Xen.
> Is there a description (or URL) of what one can jam in there?

I failed to find one. I asked a few SUSE qemu devs and they too had no
documentation hints, but noted "pretty much anything that fits in the command
line can go into the config file these days".

The user config files are .ini-style. Command line option  '-opt_a foo=1,bar=2'
becomes

  [opt_a]
foo=1
bar=2

Regards,
Jim


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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

On Mon, Mar 14, 2016 at 11:40 AM, Linus Torvalds
 wrote:
> On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski  wrote:
>>
>> The code in my queue is, literally:
>>
>> bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
>>  struct pt_regs *regs, int trapnr)
>> {
>> WARN_ONCE(1, "unchecked MSR access error: RDMSR from 0x%x",
>>   (unsigned int)regs->cx);
>>
>> /* Pretend that the read succeeded and returned 0. */
>> regs->ip = ex_fixup_addr(fixup);
>> regs->ax = 0;
>> regs->dx = 0;
>> return true;
>> }
>> EXPORT_SYMBOL(ex_handler_rdmsr_unsafe);
>
> I guess I can live with this, as long as we also extend the
> early-fault handling to work with the special exception handlers.

OK, will do.  I need to rewrork the early IDT code a bit so it
generates a real pt_regs layout, but that's arguably a cleanup anyway.

--Andy

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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Linus Torvalds]

On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski  wrote:
>
> The code in my queue is, literally:
>
> bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
>  struct pt_regs *regs, int trapnr)
> {
> WARN_ONCE(1, "unchecked MSR access error: RDMSR from 0x%x",
>   (unsigned int)regs->cx);
>
> /* Pretend that the read succeeded and returned 0. */
> regs->ip = ex_fixup_addr(fixup);
> regs->ax = 0;
> regs->dx = 0;
> return true;
> }
> EXPORT_SYMBOL(ex_handler_rdmsr_unsafe);

I guess I can live with this, as long as we also extend the
early-fault handling to work with the special exception handlers.

And as long as people start understanding that killing the machine is
a bad bad bad thing. It's a debugging nightmare.

   Linus

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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

On Mon, Mar 14, 2016 at 11:15 AM, Linus Torvalds
 wrote:
> On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski  wrote:
>>
>> A couple of the wrmsr users actually care about performance.  These
>> are the ones involved in context switching and, to a lesser extent, in
>> switching in and out of guest mode.
>
> .. ok, see the crossed emails.
>
> I'd *much* rather special case the special cases. Not make the generic
> case something complex.

The code in my queue is, literally:

bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
 struct pt_regs *regs, int trapnr)
{
WARN_ONCE(1, "unchecked MSR access error: RDMSR from 0x%x",
  (unsigned int)regs->cx);

/* Pretend that the read succeeded and returned 0. */
regs->ip = ex_fixup_addr(fixup);
regs->ax = 0;
regs->dx = 0;
return true;
}
EXPORT_SYMBOL(ex_handler_rdmsr_unsafe);

The only regard in which this is any more complex than the _safe
variant is because there's a warning (one line of code) and because
the _safe variant forgot to zero the result (two lines of code).  My
series fixes the latter, so we're talking about almost no source code
size difference.  There *is* a difference in binary size, though --
the _safe variant emits a copy of its fixup every time it appears,
whereas the new fixup appears once.

So I think we should apply my patches (with the early handling fixed
and the panic_on_oops removed), and then consider reimplementing the
_safe variant using fancy handlers to reduce number of lines of asm
and code size, and then consider changing the overall API on top if we
think there's a better API to be had.

Is that okay?

>
> And *particularly* not make the generic case be something where people
> think it's sane to oops and kill the machine. Christ.

I've already removed the panic_on_oops thing from my tree.

--Andy

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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds
 wrote:
> On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski  wrote:
>>
>> So yes, let's please warn.  I'm okay with removing the panic_on_oops
>> thing though.  (But if anyone suggests that we should stop OOPSing on
>> bad kernel page faults, I *will* fight back.)
>
> Bad kernel page faults are something completely different. They would
> be actual bugs regardless.
>
> The MSR thing has *often* been just silly "this CPU doesn't do that
> MSR". Generic bootup setup code etc that just didn't know or care
> about the particular badly documented rule for one particular random
> CPU version and stepping.
>
> In fact, when I say "often", I suspect I should really just say
> "always". I don't think we've ever found a case where oopsing would
> have been the right thing. But it has definitely caused lots of
> problems, especially in the early paths where your code doesn't even
> work right now.

I can fix that part by literally deleting a few lines of code.  I just
need to audit things to make sure that won't break anything.

>
> Now, when it comes to the warning, I guess I could live with it, but I
> think it's stupid to make this a low-level exception handler thing.
>
> So what I think should be done:
>
>  - make sure that wr/rdmsr_safe() actually works during very early
> init. At some point it didn't.
>
>  - get rid of the current wrmsr/rdmsr *entirely*. It's shit.
>
>  - Add this wrapper:
>
>   #define wrmsr(msr, low, high) \
> WARN_ON_ONCE(wrmsr_safe(msr, low, high))
>
> and be done with it. We could even decide to make that WARN_ON_ONCE()
> be something we could configure out, because it's really a debugging
> thing and isn't like it should be all that fatal.
>
> None of this insane complicated crap that buys us exactly *nothing*,
> and depends on fancy new exception handling support etc etc.
>
> So what's the downside to just doing this simple thing?

More code size increase and extra branches on fast paths.  Using the
fancy new exception handling means we get to have the check and the
warning completely out of line.  In fact, I'm tempted to change the
_safe variants to use the fancy new handling as well (once it works in
early boot) to shorten the code size and remove some asm code.

A couple of the wrmsr users actually care about performance.  These
are the ones involved in context switching and, to a lesser extent, in
switching in and out of guest mode.

--Andy

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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Linus Torvalds]

On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski  wrote:
>
> A couple of the wrmsr users actually care about performance.  These
> are the ones involved in context switching and, to a lesser extent, in
> switching in and out of guest mode.

.. ok, see the crossed emails.

I'd *much* rather special case the special cases. Not make the generic
case something complex.

And *particularly* not make the generic case be something where people
think it's sane to oops and kill the machine. Christ.

  Linus

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 60684
 test-amd64-amd64-libvirt 14 guest-saverestore fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linuxf64a4592fa326b5e0c52829fb4988e2a9d34ec5f
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  214 days
Failing since 60712  2015-08-15 18:33:48 Z  211 days  157 attempts
Testing same since86186  2016-03-14 04:24:47 Z0 days1 attempts

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

Re: [Xen-devel] [PATCH] xen: Restore p2m_access_t enum order to allow bitmask semantics

[George Dunlap]

On Fri, Mar 11, 2016 at 8:53 AM, Malcolm Crossley
 wrote:
> On 10/03/16 20:48, Tamas K Lengyel wrote:
>>
>>
>> On Wed, Mar 9, 2016 at 5:30 PM, George Dunlap > > wrote:
>>
>> On 08/03/16 15:30, Malcolm Crossley wrote:
>> > Nested hap code assumed implict bitmask semantics of the p2m_access_t
>> > enum prior to C/S 4c63692d7c38c5ac414fe97f8ef37b66e05abe5c
>> >
>> > The change to the enum ordering broke this assumption and caused 
>> functional
>> > problems for the nested hap code. As it may be error prone to audit 
>> and find
>> > all other p2m_access users assuming bitmask semantics, instead restore 
>> the
>> > previous enum order and make it explict that bitmask semantics are to 
>> be
>> > preserved for the read, write and execute access types.
>> >
>> > Signed-off-by: Malcolm Crossley > >
>>
>> Looks good; but following up Jan's point, could you do a brief survey of
>> the places where the p2m_access values are used, and confirm that none
>> of them now implicitly assume that p2m_access_rwx is zero?
>>
>> (Or Tamas, can you say that you're reasonably certain nothing has now
>> come to depend on the value of p2m_access_rwx being zero?)
>>
>>
>> Yes, from my perspective it's all fine as checks of p2m_access values are 
>> done with the enum names
>> and not the values directly.
>
> I can't see any other usages of p2m_access_t without enum values either.

Great, thanks:

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Linus Torvalds]

On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds
 wrote:
>
> None of this insane complicated crap that buys us exactly *nothing*,
> and depends on fancy new exception handling support etc etc.

Actually, the one _new_ thing we could do is to instead of removing
the old crappy rdmsr()/wrmsr() implementation entirely, we'll just
rename it to "rd/wrmsr_unsafe()", and not have any exception table
stuff for that at all (so now you *will* get an oops and panic if you
use that).

The only reason to do that is for performance-critical MSR's that
really don't want any overhead. Sure, they could just be changed to
use "wrmsr_safe()", but for things like the APIC accesses, or
update_debugctlmsr() (that is supposed to check for processor version)
that can be truly critical, an explicitly _unsafe_ version may be the
right thing to do.

The fact is, the problem with rd/wrmsr is that we just did the
defaults the wrong way around. Making the simple and obvious version
be unsafe is just wrong.

  Linus

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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Linus Torvalds]

On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski  wrote:
>
> So yes, let's please warn.  I'm okay with removing the panic_on_oops
> thing though.  (But if anyone suggests that we should stop OOPSing on
> bad kernel page faults, I *will* fight back.)

Bad kernel page faults are something completely different. They would
be actual bugs regardless.

The MSR thing has *often* been just silly "this CPU doesn't do that
MSR". Generic bootup setup code etc that just didn't know or care
about the particular badly documented rule for one particular random
CPU version and stepping.

In fact, when I say "often", I suspect I should really just say
"always". I don't think we've ever found a case where oopsing would
have been the right thing. But it has definitely caused lots of
problems, especially in the early paths where your code doesn't even
work right now.

Now, when it comes to the warning, I guess I could live with it, but I
think it's stupid to make this a low-level exception handler thing.

So what I think should be done:

 - make sure that wr/rdmsr_safe() actually works during very early
init. At some point it didn't.

 - get rid of the current wrmsr/rdmsr *entirely*. It's shit.

 - Add this wrapper:

  #define wrmsr(msr, low, high) \
WARN_ON_ONCE(wrmsr_safe(msr, low, high))

and be done with it. We could even decide to make that WARN_ON_ONCE()
be something we could configure out, because it's really a debugging
thing and isn't like it should be all that fatal.

None of this insane complicated crap that buys us exactly *nothing*,
and depends on fancy new exception handling support etc etc.

So what's the downside to just doing this simple thing?

  Linus

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

[Xen-devel] [PATCH v4 10/14] hvmloader: Load SeaBIOS from hvm_start_info modules

[Anthony PERARD]

... and do not include the SeaBIOS ROM into hvmloader anymore.

This also fix the dependency on roms.inc, hvmloader.o does not include it.

Signed-off-by: Anthony PERARD 
---
Change in V4:
- check that seabios_config.bios_address have a probably good value
  instead of checking only if it's set.

Change in V3:
- change makefile to not include seabios roms into roms.inc.
- update the struct bios_config with the location of the bios blob.
---
 tools/firmware/hvmloader/Makefile  | 15 +--
 tools/firmware/hvmloader/seabios.c | 24 ++--
 2 files changed, 15 insertions(+), 24 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index f2f4791..ed0bfad 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -45,7 +45,6 @@ CIRRUSVGA_DEBUG ?= n
 
 OVMF_DIR := ../ovmf-dir
 ROMBIOS_DIR := ../rombios
-SEABIOS_DIR := ../seabios-dir
 
 ifeq ($(CONFIG_ROMBIOS),y)
 STDVGA_ROM:= ../vgabios/VGABIOS-lgpl-latest.bin
@@ -80,19 +79,13 @@ endif
 ifeq ($(CONFIG_SEABIOS),y)
 OBJS += seabios.o
 CFLAGS += -DENABLE_SEABIOS
-ifeq ($(SEABIOS_PATH),)
-   SEABIOS_ROM := $(SEABIOS_DIR)/out/bios.bin
-else
-   SEABIOS_ROM := $(SEABIOS_PATH)
-endif
-ROMS += $(SEABIOS_ROM)
 endif
 
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
 
-ovmf.o rombios.o seabios.o hvmloader.o: roms.inc
+ovmf.o rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
 hvmloader: $(OBJS) acpi/acpi.a
@@ -109,12 +102,6 @@ ifneq ($(ROMBIOS_ROM),)
echo "#endif" >> $@.new
 endif
 
-ifneq ($(SEABIOS_ROM),)
-   echo "#ifdef ROM_INCLUDE_SEABIOS" >> $@.new
-   sh ./mkhex seabios $(SEABIOS_ROM) >> $@.new
-   echo "#endif" >> $@.new
-endif
-
 ifneq ($(OVMF_ROM),)
echo "#ifdef ROM_INCLUDE_OVMF" >> $@.new
sh ./mkhex ovmf $(OVMF_ROM) >> $@.new
diff --git a/tools/firmware/hvmloader/seabios.c 
b/tools/firmware/hvmloader/seabios.c
index c6b3d9f..5d0a491 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -27,9 +27,6 @@
 #include "smbios_types.h"
 #include "acpi/acpi2_0.h"
 
-#define ROM_INCLUDE_SEABIOS
-#include "roms.inc"
-
 extern unsigned char dsdt_anycpu_qemu_xen[];
 extern int dsdt_anycpu_qemu_xen_len;
 
@@ -127,22 +124,29 @@ static void seabios_setup_e820(void)
 struct e820entry *e820 = scratch_alloc(sizeof(struct e820entry)*16, 0);
 info->e820 = (uint32_t)e820;
 
+BUG_ON(seabios_config.bios_address < 0xc || 
seabios_config.bios_address >= 0x10);
 /* SeaBIOS reserves memory in e820 as necessary so no low reservation. */
-info->e820_nr = build_e820_table(e820, 0, 0x10-sizeof(seabios));
+info->e820_nr = build_e820_table(e820, 0, seabios_config.bios_address);
 dump_e820_table(e820, info->e820_nr);
 }
 
-struct bios_config seabios_config = {
-.name = "SeaBIOS",
+static void seabios_load(const struct bios_config *bios,
+ void *bios_addr, uint32_t bios_length)
+{
+unsigned int bios_dest = 0x10 - bios_length;
 
-.image = seabios,
-.image_size = sizeof(seabios),
+BUG_ON(bios_dest + bios_length > HVMLOADER_PHYSICAL_ADDRESS);
+memcpy((void *)bios_dest, bios_addr, bios_length);
+seabios_config.bios_address = bios_dest;
+seabios_config.image_size = bios_length;
+}
 
-.bios_address = 0x10 - sizeof(seabios),
+struct bios_config seabios_config = {
+.name = "SeaBIOS",
 
 .load_roms = NULL,
 
-.bios_load = NULL,
+.bios_load = seabios_load,
 
 .bios_info_setup = seabios_setup_bios_info,
 .bios_info_finish = seabios_finish_bios_info,
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 12/14] hvmloader: Specific bios_load function required

[Anthony PERARD]

All BIOS but ROMBIOS needs to be loaded via modules.

ROMBIOS is handled as a special case.

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---
No change in V4.

Change in V3:
- reprint Main BIOS in bios map with now available information from bios
  modules.
- handle rombios, and keep its built-in ROMs.
---
 tools/firmware/hvmloader/hvmloader.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 460efb9..bb2a309 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -323,21 +323,25 @@ int main(void)
 
 printf("Loading %s ...\n", bios->name);
 bios_module = get_module_entry(hvm_start_info, "bios");
-if ( bios_module && bios->bios_load )
+if ( bios_module )
 {
 uint32_t paddr = bios_module->paddr;
 bios->bios_load(bios, (void*)paddr, bios_module->size);
 }
-else if ( bios->bios_load )
+#ifdef ENABLE_ROMBIOS
+else if ( bios == &rombios_config )
 {
 bios->bios_load(bios, 0, 0);
 }
+#endif
 else
 {
-BUG_ON(bios->bios_address + bios->image_size >
-   HVMLOADER_PHYSICAL_ADDRESS);
-memcpy((void *)bios->bios_address, bios->image,
-   bios->image_size);
+/*
+ * If there is no BIOS module supplied and if there is no embeded BIOS
+ * image, then we failed. Only rombios might have an embedded bios 
blob.
+ */
+printf("no BIOS ROM image found\n");
+BUG();
 }
 
 if ( (hvm_info->nr_vcpus > 1) || hvm_info->apic_mode )
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 14/14] configure: do not depend on SEABIOS_PATH or OVMF_PATH ...

[Anthony PERARD]

... to compile SeaBIOS and OVMF. Only depends on CONFIG_*.

If --with-system-* configure option is used, then set *_CONFIG=n to not
compile SEABIOS and OVMF.

Signed-off-by: Anthony PERARD 

---
Change in V4:
- change subject prefix

Please, run ./autogen.sh on this patch.
---
 tools/configure.ac  | 6 --
 tools/firmware/Makefile | 8 
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/tools/configure.ac b/tools/configure.ac
index 7e5452e..ef306ae 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -212,12 +212,13 @@ AC_ARG_WITH([system-seabios],
 AS_HELP_STRING([--with-system-seabios@<:@=PATH@:>@],
[Use system supplied seabios PATH instead of building and installing
 our own version]),[
+# Disable compilation of SeaBIOS.
+seabios=n
 case $withval in
 no) seabios_path= ;;
 *)  seabios_path=$withval ;;
 esac
 ],[])
-AC_SUBST(seabios_path)
 AC_DEFINE_UNQUOTED([SEABIOS_PATH],
["${seabios_path:-$XENFIRMWAREDIR/seabios.bin}"],
[SeaBIOS path])
@@ -226,12 +227,13 @@ AC_ARG_WITH([system-ovmf],
 AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
[Use system supplied OVMF PATH instead of building and installing
 our own version]),[
+# Disable compilation of OVMF.
+ovmf=n
 case $withval in
 no) ovmf_path= ;;
 *)  ovmf_path=$withval ;;
 esac
 ],[])
-AC_SUBST(ovmf_path)
 AC_DEFINE_UNQUOTED([OVMF_PATH],
["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
[OVMF path])
diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 6a37758..4975cb4 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -6,12 +6,8 @@ TARGET  := hvmloader/hvmloader
 INST_DIR := $(DESTDIR)$(XENFIRMWAREDIR)
 
 SUBDIRS-y :=
-ifeq ($(OVMF_PATH),)
 SUBDIRS-$(CONFIG_OVMF) += ovmf-dir
-endif
-ifeq ($(SEABIOS_PATH),)
 SUBDIRS-$(CONFIG_SEABIOS) += seabios-dir
-endif
 SUBDIRS-$(CONFIG_ROMBIOS) += rombios
 SUBDIRS-$(CONFIG_ROMBIOS) += vgabios
 SUBDIRS-$(CONFIG_ROMBIOS) += etherboot
@@ -49,15 +45,11 @@ install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
 ifeq ($(CONFIG_SEABIOS),y)
-ifeq ($(SEABIOS_PATH),)
$(INSTALL_DATA) $(SEABIOS_ROM) $(INST_DIR)/seabios.bin
 endif
-endif
 ifeq ($(CONFIG_OVMF),y)
-ifeq ($(OVMF_PATH),)
$(INSTALL_DATA) $(OVMF_ROM) $(INST_DIR)/ovmf.bin
 endif
-endif
 
 .PHONY: clean
 clean: subdirs-clean
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 11/14] hvmloader: Load OVMF from modules

[Anthony PERARD]

... and do not include the OVMF ROM into hvmloader anymore.

Signed-off-by: Anthony PERARD 
---
Change in V4:
- check if source and dest of ovmf binary does not overlaps

Change in V3:
- change makefile to not include ovmf rom into roms.inc.
- update the struct bios_config with bios destination
---
 tools/firmware/hvmloader/Makefile | 15 +--
 tools/firmware/hvmloader/ovmf.c   | 30 +-
 2 files changed, 14 insertions(+), 31 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index ed0bfad..dee1c6b 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -43,7 +43,6 @@ endif
 
 CIRRUSVGA_DEBUG ?= n
 
-OVMF_DIR := ../ovmf-dir
 ROMBIOS_DIR := ../rombios
 
 ifeq ($(CONFIG_ROMBIOS),y)
@@ -61,12 +60,6 @@ ROMS :=
 ifeq ($(CONFIG_OVMF),y)
 OBJS += ovmf.o
 CFLAGS += -DENABLE_OVMF
-ifeq ($(OVMF_PATH),)
-   OVMF_ROM := $(OVMF_DIR)/ovmf.bin
-else
-   OVMF_ROM := $(OVMF_PATH)
-endif
-ROMS += $(OVMF_ROM)
 endif
 
 ifeq ($(CONFIG_ROMBIOS),y)
@@ -85,7 +78,7 @@ endif
 all: subdirs-all
$(MAKE) hvmloader
 
-ovmf.o rombios.o: roms.inc
+rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
 hvmloader: $(OBJS) acpi/acpi.a
@@ -102,12 +95,6 @@ ifneq ($(ROMBIOS_ROM),)
echo "#endif" >> $@.new
 endif
 
-ifneq ($(OVMF_ROM),)
-   echo "#ifdef ROM_INCLUDE_OVMF" >> $@.new
-   sh ./mkhex ovmf $(OVMF_ROM) >> $@.new
-   echo "#endif" >> $@.new 
-endif 
-
 ifneq ($(STDVGA_ROM),)
echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 858a2d4..6607e57 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -34,17 +34,10 @@
 #include 
 #include 
 
-#define ROM_INCLUDE_OVMF
-#include "roms.inc"
-
-#define OVMF_SIZE   (sizeof(ovmf))
 #define OVMF_MAXOFFSET  0x000FULL
-#define OVMF_BEGIN  (0x1ULL - ((OVMF_SIZE + 
OVMF_MAXOFFSET) & ~OVMF_MAXOFFSET))
-#define OVMF_END(OVMF_BEGIN + OVMF_SIZE)
 #define LOWCHUNK_BEGIN  0x000F
 #define LOWCHUNK_SIZE   0x0001
 #define LOWCHUNK_MAXOFFSET  0x
-#define LOWCHUNK_END(OVMF_BEGIN + OVMF_SIZE)
 #define OVMF_INFO_PHYSICAL_ADDRESS 0x1000
 
 extern unsigned char dsdt_anycpu_qemu_xen[];
@@ -97,24 +90,31 @@ static void ovmf_load(const struct bios_config *config,
   void *bios_addr, uint32_t bios_length)
 {
 xen_pfn_t mfn;
-uint64_t addr = OVMF_BEGIN;
+uint64_t addr = 0x1ULL
+- ((bios_length + OVMF_MAXOFFSET) & ~OVMF_MAXOFFSET);
+uint64_t ovmf_end = addr + bios_length;
+
+ovmf_config.bios_address = addr;
+ovmf_config.image_size = bios_length;
 
 /* Copy low-reset vector portion. */
-memcpy((void *) LOWCHUNK_BEGIN, (uint8_t *) config->image
-   + OVMF_SIZE
-   - LOWCHUNK_SIZE,
+memcpy((void *) LOWCHUNK_BEGIN,
+   (uint8_t *) bios_addr + bios_length - LOWCHUNK_SIZE,
LOWCHUNK_SIZE);
 
 /* Ensure we have backing page prior to moving FD. */
-while ( (addr >> PAGE_SHIFT) != (OVMF_END >> PAGE_SHIFT) )
+while ( (addr >> PAGE_SHIFT) != (ovmf_end >> PAGE_SHIFT) )
 {
 mfn = (uint32_t) (addr >> PAGE_SHIFT);
 addr += PAGE_SIZE;
 mem_hole_populate_ram(mfn, 1);
 }
 
+/* Check that source and destination does not overlaps. */
+BUG_ON(addr + bios_length > (unsigned)bios_addr
+   && addr < (unsigned)bios_addr + bios_length);
 /* Copy FD. */
-memcpy((void *) OVMF_BEGIN, config->image, OVMF_SIZE);
+memcpy((void *) ovmf_config.bios_address, bios_addr, bios_length);
 }
 
 static void ovmf_acpi_build_tables(void)
@@ -151,10 +151,6 @@ static void ovmf_setup_e820(void)
 struct bios_config ovmf_config =  {
 .name = "OVMF",
 
-.image = ovmf,
-.image_size = sizeof(ovmf),
-
-.bios_address = OVMF_BEGIN,
 .bios_load = ovmf_load,
 
 .load_roms = 0,
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 13/14] hvmloader: Always build-in SeaBIOS and OVMF loader

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Acked-by: Jan Beulich 
---
 tools/firmware/hvmloader/Makefile| 11 +--
 tools/firmware/hvmloader/hvmloader.c |  4 
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index dee1c6b..9f7357f 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -37,6 +37,7 @@ OBJS  = hvmloader.o mp_tables.o util.o smbios.o
 OBJS += smp.o cacheattr.o xenbus.o vnuma.o
 OBJS += e820.o pci.o pir.o ctype.o
 OBJS += hvm_param.o
+OBJS += ovmf.o seabios.o
 ifeq ($(debug),y)
 OBJS += tests.o
 endif
@@ -57,11 +58,6 @@ endif
 
 ROMS := 
 
-ifeq ($(CONFIG_OVMF),y)
-OBJS += ovmf.o
-CFLAGS += -DENABLE_OVMF
-endif
-
 ifeq ($(CONFIG_ROMBIOS),y)
 OBJS += optionroms.o 32bitbios_support.o rombios.o
 CFLAGS += -DENABLE_ROMBIOS
@@ -69,11 +65,6 @@ ROMBIOS_ROM := $(ROMBIOS_DIR)/BIOS-bochs-latest
 ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) $(ETHERBOOT_ROMS)
 endif
 
-ifeq ($(CONFIG_SEABIOS),y)
-OBJS += seabios.o
-CFLAGS += -DENABLE_SEABIOS
-endif
-
 .PHONY: all
 all: subdirs-all
$(MAKE) hvmloader
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index bb2a309..7631de2 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -209,12 +209,8 @@ struct bios_info {
 #ifdef ENABLE_ROMBIOS
 { "rombios", &rombios_config, },
 #endif
-#ifdef ENABLE_SEABIOS
 { "seabios", &seabios_config, },
-#endif
-#ifdef ENABLE_OVMF
 { "ovmf", &ovmf_config, },
-#endif
 { NULL, NULL }
 };
 
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 04/14] firmware/makefile: install BIOS blob ...

[Anthony PERARD]

... into the firmware directory, along with hvmloader.

Signed-off-by: Anthony PERARD 
---
Change in V4:
- remove install of acpi dsdt table

Change in V3:
- do not check if ROMs file exist before installing, they should exist
- change rules for dsdt_anycpu_qemu_xen.c in oder to generate both .c and
  .aml files without changing temporarly the other dsdt_*.c rules.
---
 tools/firmware/Makefile | 13 +
 1 file changed, 13 insertions(+)

diff --git a/tools/firmware/Makefile b/tools/firmware/Makefile
index 6cc86ce..6a37758 100644
--- a/tools/firmware/Makefile
+++ b/tools/firmware/Makefile
@@ -19,6 +19,9 @@ SUBDIRS-y += hvmloader
 
 LD32BIT-$(CONFIG_FreeBSD) := LD32BIT_FLAG=-melf_i386_fbsd
 
+SEABIOS_ROM := seabios-dir/out/bios.bin
+OVMF_ROM := ovmf-dir/ovmf.bin
+
 ovmf-dir:
GIT=$(GIT) $(XEN_ROOT)/scripts/git-checkout.sh $(OVMF_UPSTREAM_URL) 
$(OVMF_UPSTREAM_REVISION) ovmf-dir
cp ovmf-makefile ovmf-dir/Makefile;
@@ -45,6 +48,16 @@ endif
 install: all
[ -d $(INST_DIR) ] || $(INSTALL_DIR) $(INST_DIR)
[ ! -e $(TARGET) ] || $(INSTALL_DATA) $(TARGET) $(INST_DIR)
+ifeq ($(CONFIG_SEABIOS),y)
+ifeq ($(SEABIOS_PATH),)
+   $(INSTALL_DATA) $(SEABIOS_ROM) $(INST_DIR)/seabios.bin
+endif
+endif
+ifeq ($(CONFIG_OVMF),y)
+ifeq ($(OVMF_PATH),)
+   $(INSTALL_DATA) $(OVMF_ROM) $(INST_DIR)/ovmf.bin
+endif
+endif
 
 .PHONY: clean
 clean: subdirs-clean
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 05/14] libxl: Load guest BIOS from file

[Anthony PERARD]

The path to the BIOS blob can be override by the xl's bios_override option,
or provided by u.hvm.bios_firmware in the domain_build_info struct by other
libxl user.

Signed-off-by: Anthony PERARD 

---
Change in V4:
- updating man page to have bios_override described.
- return ERROR_INVAL in libxl__load_hvm_firmware_module when the file is
  empty.

Change in V3:
- move seabios_path and ovmf_path to libxl_path.c (with renaming)
- fix some coding style
- warn for empty file
- remove rombios stuff (will still be built-in hvmloader)
- rename field bios_filename in domain_build_info to bios_firmware to
  follow naming of acpi and smbios.
- log an error after libxl_read_file_contents() only when it return ENOENT
- return an error on empty file.
- added #define LIBXL_HAVE_BUILDINFO_HVM_BIOS_FIRMWARE
---
 docs/man/xl.cfg.pod.5|  9 +++
 tools/libxl/libxl.h  |  8 +++
 tools/libxl/libxl_dom.c  | 57 
 tools/libxl/libxl_internal.h |  2 ++
 tools/libxl/libxl_paths.c| 10 
 tools/libxl/libxl_types.idl  |  1 +
 tools/libxl/xl_cmdimpl.c | 11 ++---
 7 files changed, 95 insertions(+), 3 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 56b1117..165915b 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1121,6 +1121,15 @@ Requires device_model_version=qemu-xen.
 
 =back
 
+=item B
+
+Override the path to the blob to be used as BIOS. The blob provided here MUST
+be consistent with the `bios` which you have specified. You should not normally
+need to specify this option.
+
+This options does not have any effect if using bios="rombios" or
+device_model_version="qemu-xen-traditional".
+
 =item B
 
 Hide or expose the IA32 Physical Address Extensions. These extensions
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index f9e3ef5..d06c6c5 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -884,6 +884,14 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
libxl_mac *src);
 #define LIBXL_HAVE_CHECKPOINTED_STREAM 1
 
 /*
+ * LIBXL_HAVE_BUILDINFO_HVM_BIOS_FIRMWARE
+ *
+ * libxl_domain_build_info has u.hvm.bios_firmware field which can be use
+ * to provide a different bios blob (like SeaBIOS or OVMF).
+ */
+#define LIBXL_HAVE_BUILDINFO_HVM_BIOS_FIRMWARE
+
+/*
  * ERROR_REMUS_XXX error code only exists from Xen 4.5, Xen 4.6 and it
  * is changed to ERROR_CHECKPOINT_XXX in Xen 4.7
  */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b825b98..c112cc5 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -862,6 +862,38 @@ err:
 return ret;
 }
 
+static int libxl__load_hvm_firmware_module(libxl__gc *gc,
+   const char *filename,
+   const char *what,
+   struct xc_hvm_firmware_module *m)
+{
+int datalen = 0;
+void *data = NULL;
+int e;
+
+LOG(DEBUG, "Loading %s: %s", what, filename);
+e = libxl_read_file_contents(CTX, filename, &data, &datalen);
+if (e) {
+/*
+ * Print a message only on ENOENT, other error are logged by the
+ * function libxl_read_file_contents().
+ */
+if (e == ENOENT)
+LOGEV(ERROR, e, "failed to read %s file", what);
+return ERROR_FAIL;
+}
+libxl__ptr_add(gc, data);
+if (datalen) {
+/* Only accept non-empty files */
+m->data = data;
+m->length = datalen;
+} else {
+LOG(ERROR, "file %s for %s is empty", filename, what);
+return ERROR_INVAL;
+}
+return 0;
+}
+
 static int libxl__domain_firmware(libxl__gc *gc,
   libxl_domain_build_info *info,
   struct xc_dom_image *dom)
@@ -871,6 +903,7 @@ static int libxl__domain_firmware(libxl__gc *gc,
 int e, rc;
 int datalen = 0;
 void *data;
+const char *bios_filename = NULL;
 
 if (info->u.hvm.firmware)
 firmware = info->u.hvm.firmware;
@@ -914,6 +947,30 @@ static int libxl__domain_firmware(libxl__gc *gc,
 goto out;
 }
 
+if (info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
+if (info->u.hvm.bios_firmware) {
+bios_filename = info->u.hvm.bios_firmware;
+} else {
+switch (info->u.hvm.bios) {
+case LIBXL_BIOS_TYPE_SEABIOS:
+bios_filename = libxl__seabios_path();
+break;
+case LIBXL_BIOS_TYPE_OVMF:
+bios_filename = libxl__ovmf_path();
+break;
+case LIBXL_BIOS_TYPE_ROMBIOS:
+default:
+abort();
+}
+}
+}
+
+if (bios_filename) {
+rc = libxl__load_hvm_firmware_module(gc, bios_filename, "BIOS",
+ &dom->bios_module);
+if (rc) goto out;
+}
+
 if (info->u

[Xen-devel] [PATCH v4 06/14] xen: Move the hvm_start_info C representation from libxc to public/xen.h

[Anthony PERARD]

Instead of having several representation of hvm_start_info in C, define
it in public/xen.h so both libxc and hvmloader can use it.

Signed-off-by: Anthony PERARD 
---
New in V4.
---
 tools/libxc/include/xc_dom.h | 31 ---
 xen/include/public/xen.h | 31 +++
 2 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 93f894c..567016c 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -219,37 +219,6 @@ struct xc_dom_image {
 struct xc_hvm_firmware_module smbios_module;
 };
 
-#if defined(__i386__) || defined(__x86_64__)
-/* C representation of the x86/HVM start info layout.
- *
- * The canonical definition of this layout resides in public/xen.h, this
- * is just a way to represent the layout described there using C types.
- *
- * NB: the packed attribute is not really needed, but it helps us enforce
- * the fact this this is just a representation, and it might indeed
- * be required in the future if there are alignment changes.
- */
-struct hvm_start_info {
-uint32_t magic; /* Contains the magic value 0x336ec578   */
-/* ("xEn3" with the 0x80 bit of the "E" set).*/
-uint32_t version;   /* Version of this structure.*/
-uint32_t flags; /* SIF_xxx flags.*/
-uint32_t cmdline_paddr; /* Physical address of the command line. */
-uint32_t nr_modules;/* Number of modules passed to the kernel.   */
-uint32_t modlist_paddr; /* Physical address of an array of   */
-/* hvm_modlist_entry.*/
-uint32_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
-/* structure.*/
-} __attribute__((packed));
-
-struct hvm_modlist_entry {
-uint64_t paddr; /* Physical address of the module.   */
-uint64_t size;  /* Size of the module in bytes.  */
-uint64_t cmdline_paddr; /* Physical address of the command line. */
-uint64_t reserved;
-} __attribute__((packed));
-#endif /* x86 */
-
 /* --- pluggable kernel loader - */
 
 struct xc_dom_loader {
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 1cfec5c..c270cf1 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -841,6 +841,37 @@ typedef struct start_info start_info_t;
  */
 #define XEN_HVM_START_MAGIC_VALUE 0x336ec578
 
+#if defined(__i386__) || defined(__x86_64__)
+/* C representation of the x86/HVM start info layout.
+ *
+ * The canonical definition of this layout is abrove, this is just a way to
+ * represent the layout described there using C types.
+ *
+ * NB: the packed attribute is not really needed, but it helps us enforce
+ * the fact this this is just a representation, and it might indeed
+ * be required in the future if there are alignment changes.
+ */
+struct hvm_start_info {
+uint32_t magic; /* Contains the magic value 0x336ec578   */
+/* ("xEn3" with the 0x80 bit of the "E" set).*/
+uint32_t version;   /* Version of this structure.*/
+uint32_t flags; /* SIF_xxx flags.*/
+uint32_t cmdline_paddr; /* Physical address of the command line. */
+uint32_t nr_modules;/* Number of modules passed to the kernel.   */
+uint32_t modlist_paddr; /* Physical address of an array of   */
+/* hvm_modlist_entry.*/
+uint32_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
+/* structure.*/
+} __attribute__((packed));
+
+struct hvm_modlist_entry {
+uint64_t paddr; /* Physical address of the module.   */
+uint64_t size;  /* Size of the module in bytes.  */
+uint64_t cmdline_paddr; /* Physical address of the command line. */
+uint64_t reserved;
+} __attribute__((packed));
+#endif /* x86 */
+
 /* New console union for dom0 introduced in 0x00030203. */
 #if __XEN_INTERFACE_VERSION__ < 0x00030203
 #define console_mfnconsole.domU.mfn
-- 
Anthony PERARD


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

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

[Anthony PERARD]

... and load BIOS into guest memory.

This adds a new firmware module, bios_module. It is
loaded in the guest memory and final location is provided to hvmloader
via the hvm_start_info struct.

This patch create the hvm_start_info struct for HVM guest that have a
device model, so this is now common code with HVM guest without device
model.

Signed-off-by: Anthony PERARD 
---
Change in V4:
- change title to suggest the change of beavior
- remove code to load acpi tables (dsdt)
- Update public/xen.h about hvm_start_info available on other HVM guest
  in %ebx.

Change in V3:
- rename acpi_table_module to full_acpi_module.
- factorise module loading, using new function to load existing optinal
  module, this should not change anything
- should now use the same code to loads modules as for HVMlite VMs.
  this avoid duplication of code.
- no more generic cmdline with a list of modules, each module have its name
  in the module specific cmdline.
- scope change for common code between hvmlite and hvmloader
---
 tools/libxc/include/xc_dom.h   |   3 +
 tools/libxc/xc_dom_hvmloader.c |   2 +
 tools/libxc/xc_dom_x86.c   | 132 -
 xen/include/public/xen.h   |   2 +-
 4 files changed, 96 insertions(+), 43 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6ebe946..93f894c 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -209,6 +209,9 @@ struct xc_dom_image {
 /* If unset disables the setup of the IOREQ pages. */
 bool device_model;
 
+/* BIOS passed to HVMLOADER */
+struct xc_hvm_firmware_module bios_module;
+
 /* Extra ACPI tables passed to HVMLOADER */
 struct xc_hvm_firmware_module acpi_module;
 
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 7cf5854..606351a 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -167,6 +167,8 @@ static int modules_init(struct xc_dom_image *dom)
 {
 int rc;
 
+rc = module_init_one(dom, &dom->bios_module, "bios module");
+if ( rc ) goto err;
 rc = module_init_one(dom, &dom->acpi_module, "acpi module");
 if ( rc ) goto err;
 rc = module_init_one(dom, &dom->smbios_module, "smbios module");
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index bdec40a..9c56d55 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -69,6 +69,9 @@
 #define round_up(addr, mask) ((addr) | (mask))
 #define round_pg_up(addr)  (((addr) + PAGE_SIZE_X86 - 1) & ~(PAGE_SIZE_X86 - 
1))
 
+#define HVMLOADER_MODULE_MAX_COUNT 1
+#define HVMLOADER_MODULE_NAME_SIZE 10
+
 struct xc_dom_params {
 unsigned levels;
 xen_vaddr_t vaddr_mask;
@@ -590,6 +593,7 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 xen_pfn_t special_array[X86_HVM_NR_SPECIAL_PAGES];
 xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
 xc_interface *xch = dom->xch;
+size_t start_info_size = sizeof(struct hvm_start_info);
 
 /* Allocate and clear special pages. */
 for ( i = 0; i < X86_HVM_NR_SPECIAL_PAGES; i++ )
@@ -624,8 +628,6 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 
 if ( !dom->device_model )
 {
-size_t start_info_size = sizeof(struct hvm_start_info);
-
 if ( dom->cmdline )
 {
 dom->cmdline_size = ROUNDUP(strlen(dom->cmdline) + 1, 8);
@@ -635,17 +637,26 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
 /* Limited to one module. */
 if ( dom->ramdisk_blob )
 start_info_size += sizeof(struct hvm_modlist_entry);
-
-rc = xc_dom_alloc_segment(dom, &dom->start_info_seg,
-  "HVMlite start info", 0, start_info_size);
-if ( rc != 0 )
-{
-DOMPRINTF("Unable to reserve memory for the start info");
-goto out;
-}
 }
 else
 {
+start_info_size +=
+sizeof(struct hvm_modlist_entry) * HVMLOADER_MODULE_MAX_COUNT;
+/* Add extra space to write modules name */
+start_info_size +=
+HVMLOADER_MODULE_NAME_SIZE * HVMLOADER_MODULE_MAX_COUNT;
+}
+
+rc = xc_dom_alloc_segment(dom, &dom->start_info_seg,
+  "HVMlite start info", 0, start_info_size);
+if ( rc != 0 )
+{
+DOMPRINTF("Unable to reserve memory for the start info");
+goto out;
+}
+
+if ( dom->device_model )
+{
 /*
  * Allocate and clear additional ioreq server pages. The default
  * server will use the IOREQ and BUFIOREQ special pages above.
@@ -1696,39 +1707,68 @@ static int alloc_pgtables_hvm(struct xc_dom_image *dom)
 return 0;
 }
 
+static void add_module_to_list(struct xc_dom_image *dom,
+   struct xc_hvm_firmware_module *module,
+   const char *name,
+   struct hvm_modlist_e

[Xen-devel] [PATCH v4 07/14] hvmloader: Grab the hvm_start_info pointer

[Anthony PERARD]

Signed-off-by: Anthony PERARD 

---
Change in V4:
- remove struct hvm_info_start redefinition, as it's moved to
  public/xen.h in a previous patch.

Change in V3:
- remove cmdline parser
- load hvm_start_info pointer earlier, before calling main().
- Add struct hvm_start_info definition to hvmloader.
---
 tools/firmware/hvmloader/hvmloader.c | 5 +
 tools/firmware/hvmloader/util.h  | 3 +++
 2 files changed, 8 insertions(+)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 716d03c..c45f367 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 
+const struct hvm_start_info *hvm_start_info;
+
 asm (
 ".text   \n"
 ".globl _start   \n"
@@ -46,6 +48,8 @@ asm (
 "ljmp $"STR(SEL_CODE32)",$1f \n"
 "1:  movl $stack_top,%esp\n"
 "movl %esp,%ebp  \n"
+/* store HVM start info ptr */
+"mov  %ebx, hvm_start_info   \n"
 "call main   \n"
 /* Relocate real-mode trampoline to 0x0. */
 "mov  $trampoline_start,%esi \n"
@@ -258,6 +262,7 @@ int main(void)
 memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
 
 printf("HVM Loader\n");
+BUG_ON(hvm_start_info->magic != XEN_HVM_START_MAGIC_VALUE);
 
 init_hypercalls();
 
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 3126817..9808016 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -158,6 +158,9 @@ static inline void cpu_relax(void)
 struct hvm_info_table *get_hvm_info_table(void) __attribute__ ((const));
 #define hvm_info (get_hvm_info_table())
 
+/* HVM start info */
+extern const struct hvm_start_info *hvm_start_info;
+
 /* String and memory functions */
 int strcmp(const char *cs, const char *ct);
 int strncmp(const char *s1, const char *s2, uint32_t n);
-- 
Anthony PERARD


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

Re: [Xen-devel] [PATCHv1] hvmloader: add high memory e820 region if needed

[Andrew Cooper]

On 14/03/16 17:53, David Vrabel wrote:
> If the MMIO hole is large and hvmloader needs to relocate memory to
> immediately above the 4 GiB boundary, the e820 presented to the guest
> will not have a RAM region above 4 GiB.
>
> e.g., a guest with 3 GiB of memory and a 2 GiB MMIO hole will only see
> 2 GiB.
>
> The required e820 memory region above 4 GiB needs to be added, and not
> just filled in.
>
> Signed-off-by: David Vrabel 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v4 00/14] Load BIOS via toolstack instead of been embedded in hvmloader.

[Anthony PERARD]

Hi all,

Few changes in V4:
  I leave the ACPI alone and only load the BIOS via libxl now.

  Detail of changes in each patches.

I've look at loading the BIOS 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.

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 and store a name for each module into the module cmdline.
- hvmloader read the addresses from the hvm_start_info, find out which
  module to load and copy the blob to the right place.

A git tree can be found here:
git://xenbits.xen.org/people/aperard/xen-unstable.git
tag: hvmloader-with-separated-bios-v4

Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: Jan Beulich 

Regards,

Anthony PERARD (14):
  libxc: Rework extra module initialisation
  libxc: Prepare a start info structure for hvmloader
  configure: #define SEABIOS_PATH and OVMF_PATH
  firmware/makefile: install BIOS blob ...
  libxl: Load guest BIOS from file
  xen: Move the hvm_start_info C representation from libxc to
public/xen.h
  hvmloader: Grab the hvm_start_info pointer
  hvmloader: Locate the BIOS blob
  hvmloader: Check modules whereabouts in perform_tests
  hvmloader: Load SeaBIOS from hvm_start_info modules
  hvmloader: Load OVMF from modules
  hvmloader: Specific bios_load function required
  hvmloader: Always build-in SeaBIOS and OVMF loader
  configure: do not depend on SEABIOS_PATH or OVMF_PATH ...

 docs/man/xl.cfg.pod.5|   9 +++
 tools/configure.ac   |  12 +++-
 tools/firmware/Makefile  |  13 ++--
 tools/firmware/hvmloader/Makefile|  39 +-
 tools/firmware/hvmloader/config.h|   2 +-
 tools/firmware/hvmloader/hvmloader.c |  63 ++---
 tools/firmware/hvmloader/ovmf.c  |  33 -
 tools/firmware/hvmloader/rombios.c   |   3 +-
 tools/firmware/hvmloader/seabios.c   |  24 ---
 tools/firmware/hvmloader/tests.c |  20 ++
 tools/firmware/hvmloader/util.h  |   5 ++
 tools/libxc/include/xc_dom.h |  34 +
 tools/libxc/xc_dom_hvmloader.c   | 133 +++
 tools/libxc/xc_dom_x86.c | 132 +++---
 tools/libxl/libxl.h  |   8 +++
 tools/libxl/libxl_dom.c  |  57 +++
 tools/libxl/libxl_internal.h |   2 +
 tools/libxl/libxl_paths.c|  10 +++
 tools/libxl/libxl_types.idl  |   1 +
 tools/libxl/xl_cmdimpl.c |  11 ++-
 xen/include/public/xen.h |  33 -
 21 files changed, 391 insertions(+), 253 deletions(-)

-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 01/14] libxc: Rework extra module initialisation

[Anthony PERARD]

This patch use xc_dom_alloc_segment() to allocate the memory space for the
ACPI modules and the SMBIOS modules. This is to replace the arbitrary
placement of 1MB after the hvmloader image.

In later patches, while trying to load a firmware such as OVMF, the later
could easily be loaded past the address 4MB (OVMF is a 2MB binary), but
hvmloader use a range of memory from 4MB to 8MB to perform tests and in the
process, clear the memory, before loading the modules.

Signed-off-by: Anthony PERARD 
---
Changes in V4:
- check that guest_addr_out have a reasonable value.

New patch in V3.
---
 tools/libxc/xc_dom_hvmloader.c | 131 -
 1 file changed, 38 insertions(+), 93 deletions(-)

diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 330d5e8..7cf5854 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -129,98 +129,52 @@ static elf_errorstatus xc_dom_parse_hvm_kernel(struct 
xc_dom_image *dom)
 return rc;
 }
 
-static int modules_init(struct xc_dom_image *dom,
-uint64_t vend, struct elf_binary *elf,
-uint64_t *mstart_out, uint64_t *mend_out)
+static int module_init_one(struct xc_dom_image *dom,
+   struct xc_hvm_firmware_module *module,
+   char *name)
 {
-#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;
+struct xc_dom_seg seg;
+void *dest;
 
-if ( dom->acpi_module.length == 0 && dom->smbios_module.length == 0 )
-return 0;
-
-/* 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);
-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);
-*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;
-if ( dom->smbios_module.length != 0 )
-dom->smbios_module.guest_addr_out = *mstart_out + offset1;
+if ( module->length )
+{
+if ( xc_dom_alloc_segment(dom, &seg, name, 0, module->length) )
+goto err;
+dest = xc_dom_seg_to_ptr(dom, &seg);
+if ( dest == NULL )
+{
+DOMPRINTF("%s: xc_dom_seg_to_ptr(dom, &seg) => NULL",
+  __FUNCTION__);
+goto err;
+}
+memcpy(dest, module->data, module->length);
+module->guest_addr_out = seg.vstart;
+if ( module->guest_addr_out > UINT32_MAX ||
+ module->guest_addr_out + module->length > UINT32_MAX )
+{
+DOMPRINTF("%s: Module %s would be loaded abrove 4GB",
+  __FUNCTION__, name);
+goto err;
+}
+}
 
 return 0;
+err:
+return -1;
 }
 
-static int loadmodules(struct xc_dom_image *dom,
-   uint64_t mstart, uint64_t mend,
-   uint32_t domid)
+static int modules_init(struct xc_dom_image *dom)
 {
-privcmd_mmap_entry_t *entries = NULL;
-unsigned long pfn_start;
-unsigned long pfn_end;
-size_t pages;
-uint32_t i;
-uint8_t *dest;
-int rc = -1;
-xc_interface *xch = dom->xch;
-
-if ( mstart == 0 || mend == 0 )
-return 0;
-
-pfn_start = (unsigned long)(mstart >> PAGE_SHIFT);
-pfn_end = (unsigned long)((mend + PAGE_SIZE - 1) >> PAGE_SHIFT);
-pages = pfn_end - pfn_start;
-
-/* Map address space for module list. */
-entries = calloc(pages, sizeof(privcmd_mmap_entry_t));
-if ( entries == NULL )
-goto error_out;
-
-for ( i = 0; i < pages; i++ )
-entries[i].mfn = (mstart >> PAGE_SHIFT) + i;
-
-dest = xc_map_foreign_ranges(
-xch, domid, pages << PAGE_SHIFT, PROT_READ | PROT_WRITE, 1 << 
PAGE_SHIFT,
-entries, pages);
-if ( dest == NULL )
-goto error_out;
-
-/* Zero the range so padding is clear between modules */
-memset(dest, 0, pages << PAGE_SHIFT);
-
-/* Load modules into range */
-if ( dom->acpi_module.length != 0 )
-{
-memcpy(dest,
-   dom->acpi_module.data,
-   dom->acpi_module.length);
-}
-if ( dom->smbios_module.length != 0 )
-{
-memcpy(dest + (dom->smbios_module.guest_addr_out - mstart),
-   dom->smbios_module.data,
-   dom->smbios_module.length);
-}
-
-munmap(dest, pages << PAGE_SHIFT);
-rc = 0;
+int rc;
 
- error_out:
-free(entries);
+rc = module_init_one(dom, &dom->acpi_module, "acpi module");
+if ( rc ) goto err;
+ 

[Xen-devel] [PATCH v4 03/14] configure: #define SEABIOS_PATH and OVMF_PATH

[Anthony PERARD]

Those paths are to be used by libxl, in order to load the firmware in
memory. If a system path is not define via --with-system-seabios or
--with-system-ovmf, then this default to the Xen firmware directory.

Signed-off-by: Anthony PERARD 

---
Please, run ./autogen.sh on this patch.
---
 tools/configure.ac | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/configure.ac b/tools/configure.ac
index 5b5dda4..7e5452e 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -218,6 +218,9 @@ AC_ARG_WITH([system-seabios],
 esac
 ],[])
 AC_SUBST(seabios_path)
+AC_DEFINE_UNQUOTED([SEABIOS_PATH],
+   ["${seabios_path:-$XENFIRMWAREDIR/seabios.bin}"],
+   [SeaBIOS path])
 
 AC_ARG_WITH([system-ovmf],
 AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
@@ -229,6 +232,9 @@ AC_ARG_WITH([system-ovmf],
 esac
 ],[])
 AC_SUBST(ovmf_path)
+AC_DEFINE_UNQUOTED([OVMF_PATH],
+   ["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
+   [OVMF path])
 
 AC_ARG_WITH([extra-qemuu-configure-args],
 AS_HELP_STRING([--with-extra-qemuu-configure-args@<:@="--ARG1 ..."@:>@],
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 09/14] hvmloader: Check modules whereabouts in perform_tests

[Anthony PERARD]

As perform_tests() is going to clear memory past 4MB, we check that the
memory can be use or we skip the tests.

Signed-off-by: Anthony PERARD 
---
Changes in v4:
- move the check into the perform_test() function.
- skip tests instead of using BUG.

New in V3
---
 tools/firmware/hvmloader/tests.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/tools/firmware/hvmloader/tests.c b/tools/firmware/hvmloader/tests.c
index fea3ad3..7996206 100644
--- a/tools/firmware/hvmloader/tests.c
+++ b/tools/firmware/hvmloader/tests.c
@@ -210,6 +210,26 @@ void perform_tests(void)
 return;
 }
 
+/* Check that tests does not use memory where modules are stored */
+if ( ((uint32_t)hvm_start_info + sizeof(struct hvm_start_info)) > 4 << 20
+ && (uint32_t)hvm_start_info < 8 << 20 )
+{
+printf("Skipping tests due to memory used by hvm_start_info\n");
+return;
+}
+for ( unsigned i = 0; i < hvm_start_info->nr_modules; i++ )
+{
+const struct hvm_modlist_entry *modlist =
+(struct hvm_modlist_entry *)hvm_start_info->modlist_paddr;
+if ( modlist[i].paddr
+ && modlist[i].paddr + modlist[i].size > 4ul << 20
+ && modlist[i].paddr < 8ul << 20 )
+{
+printf("Skipping tests due to memory used by a module\n");
+return;
+}
+}
+
 passed = skipped = 0;
 for ( i = 0; tests[i].test; i++ )
 {
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 08/14] hvmloader: Locate the BIOS blob

[Anthony PERARD]

The BIOS can be found an entry called "bios" of the modlist of the
hvm_start_info struct.

The found BIOS blob is not loaded by this patch, but only passed as
argument to bios_load() function. It is going to be used by the next few
patches.

Signed-off-by: Anthony PERARD 

---
Changes in V4:
- add more BUG_ON into get_module_entry(). Check that modules paddr and
  size are 32bits.

Changes in V3:
- fix some codying style
- use module.cmdline to look for a module name instead of the main cmdline
  from hvm_start_info.
---
 tools/firmware/hvmloader/config.h|  2 +-
 tools/firmware/hvmloader/hvmloader.c | 42 ++--
 tools/firmware/hvmloader/ovmf.c  |  3 ++-
 tools/firmware/hvmloader/rombios.c   |  3 ++-
 tools/firmware/hvmloader/util.h  |  2 ++
 5 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index b838cf9..4c6d8ad 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -22,7 +22,7 @@ struct bios_config {
 /* ROMS */
 void (*load_roms)(void);
 
-void (*bios_load)(const struct bios_config *config);
+void (*bios_load)(const struct bios_config *config, void *addr, uint32_t 
size);
 
 void (*bios_info_setup)(void);
 void (*bios_info_finish)(void);
diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index c45f367..460efb9 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -253,10 +253,40 @@ static void acpi_enable_sci(void)
 BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN));
 }
 
+const struct hvm_modlist_entry *get_module_entry(
+const struct hvm_start_info *info,
+const char *name)
+{
+const struct hvm_modlist_entry *modlist =
+(struct hvm_modlist_entry *)info->modlist_paddr;
+unsigned int i;
+
+if ( !modlist )
+return NULL;
+
+for ( i = 0; i < info->nr_modules; i++ )
+{
+uint32_t module_name = modlist[i].cmdline_paddr;
+
+BUG_ON(!modlist[i].cmdline_paddr ||
+   modlist[i].cmdline_paddr > UINT_MAX);
+
+if ( !strcmp(name, (char*)module_name) )
+{
+BUG_ON(!modlist[i].paddr || modlist[i].paddr > UINT_MAX ||
+   modlist[i].size > UINT_MAX);
+return &modlist[i];
+}
+}
+
+return NULL;
+}
+
 int main(void)
 {
 const struct bios_config *bios;
 int acpi_enabled;
+const struct hvm_modlist_entry *bios_module;
 
 /* Initialise hypercall stubs with RET, rendering them no-ops. */
 memset((void *)HYPERCALL_PHYSICAL_ADDRESS, 0xc3 /* RET */, PAGE_SIZE);
@@ -292,8 +322,16 @@ int main(void)
 }
 
 printf("Loading %s ...\n", bios->name);
-if ( bios->bios_load )
-bios->bios_load(bios);
+bios_module = get_module_entry(hvm_start_info, "bios");
+if ( bios_module && bios->bios_load )
+{
+uint32_t paddr = bios_module->paddr;
+bios->bios_load(bios, (void*)paddr, bios_module->size);
+}
+else if ( bios->bios_load )
+{
+bios->bios_load(bios, 0, 0);
+}
 else
 {
 BUG_ON(bios->bios_address + bios->image_size >
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index db9fa7a..858a2d4 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -93,7 +93,8 @@ static void ovmf_finish_bios_info(void)
 info->checksum = -checksum;
 }
 
-static void ovmf_load(const struct bios_config *config)
+static void ovmf_load(const struct bios_config *config,
+  void *bios_addr, uint32_t bios_length)
 {
 xen_pfn_t mfn;
 uint64_t addr = OVMF_BEGIN;
diff --git a/tools/firmware/hvmloader/rombios.c 
b/tools/firmware/hvmloader/rombios.c
index 1f15b94..2ded844 100644
--- a/tools/firmware/hvmloader/rombios.c
+++ b/tools/firmware/hvmloader/rombios.c
@@ -121,7 +121,8 @@ static void rombios_load_roms(void)
option_rom_phys_addr + option_rom_sz - 1);
 }
 
-static void rombios_load(const struct bios_config *config)
+static void rombios_load(const struct bios_config *config,
+ void *unused_addr, uint32_t unused_size)
 {
 uint32_t bioshigh;
 struct rombios_info *info;
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 9808016..003dc71 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -34,6 +34,8 @@ enum {
 #undef NULL
 #define NULL ((void*)0)
 
+#define UINT_MAX (~0U)
+
 void __assert_failed(char *assertion, char *file, int line)
 __attribute__((noreturn));
 #define ASSERT(p) \
-- 
Anthony PERARD


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

[Xen-devel] [PATCHv1] hvmloader: add high memory e820 region if needed

[David Vrabel]

If the MMIO hole is large and hvmloader needs to relocate memory to
immediately above the 4 GiB boundary, the e820 presented to the guest
will not have a RAM region above 4 GiB.

e.g., a guest with 3 GiB of memory and a 2 GiB MMIO hole will only see
2 GiB.

The required e820 memory region above 4 GiB needs to be added, and not
just filled in.

Signed-off-by: David Vrabel 
---
 tools/firmware/hvmloader/e820.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index bbde2be..5541b18 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -99,6 +99,7 @@ void adjust_memory_map(void)
 ((uint64_t)hvm_info->high_mem_pgend << PAGE_SHIFT) -
 memory_map.map[i].addr;
 memory_map.map[i].type = E820_RAM;
+memory_map.nr_map++;
 }
 }
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Meng Xu]

On Mon, Mar 14, 2016 at 12:35 PM, Dario Faggioli
 wrote:
> On Mon, 2016-03-14 at 12:03 -0400, Meng Xu wrote:
>> On Mon, Mar 14, 2016 at 11:38 AM, Meng Xu 
>> wrote:
>> >
>> > I'm ok that we keep using spin_lock_irqsave() for now. But maybe
>> > later, it will be a better idea to explore if spin_lock_irq() can
>> > replace all spin_lock_irqsave() in the RTDS scheduler?
>> >
>> I rethink about the choice of replacing spin_lock_irqsave with
>> spin_lock_irq().
>> If in the future ,we will introduce new locks and there may exit the
>> situaiton when we want to lock two locks in the same function. In
>> that
>> case, we won't use spin_lock_irq() but have to use
>> spin_lock_irqsave(). If we can mix up spin_lock_irq() with
>> spin_lock_irqsave() in different fucntiosn for the same lock, which I
>> think we can (right?), we should be fine. Otherwise, we will have to
>> keep using spin_lock_irqsave().
>>
> Mixing per se is not a problem, it's how you mix...
>
> If you call spin_unlock_irq() within a critical section protected by
> either spin_lock_irq() or spin_lock_irqsave(), that is not a good mix!
> :-)
>
> if you call _irqsave() inside a critical section protected by either
> _irq() or _irqsave(), that's what should be done (it's the purpose of
> _irqsave(), actually!).
>
> Actually, in case of nesting, most of the time the inner lock can be
> taken by just spin_lock(). Look, for instance, at csched2_dump_pcpu().

Yes. I totally agree. Then we can use _irq() lock in this patch first.
Then we can try to replace _irqsave() lock with irq() lock in another
patch for the RTDS scheduler and see if it works. (It should work if I
didn't miss something in the corner case.)

As to the nested lock issues, we can handle it later when we are
facing the issue, as long as we can mix the lock in a correct way. :-D

Thanks,

Meng

-- 
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Meng Xu]

>
>> So IMHO, the replenishment handler will be called in interrupt
>> handler
>> *and* with interrupt enabled.
>> The only difference between lock_irq() and lock_irqsave() is that
>> lock_irq() can only be called with interrupt enabled. (lock_irq will
>> check if the interrupt is enabled before it disable the interrupt.)
>> So I think it is safe to use lock_irq() inside replenishment handler,
>> unless there is somewhere call this handler *with interrupt
>> disabled*.
>>
> I totally agree: _irq() is ok. (Last sentence it's a bit pointless,
> considering that this function is a timer handler, and I would not
> expect to have a timer handler called by much else than one of the
> timer's interupt. :-) )
>
>> OK. I changed the spin_lock_irqsave to spin_lock_irq based on this
>> patch. The system works well: system can boot up and will not crash
>> after I create a VM
>> So I think spin_lock_irq should work...
>>
> Glad to hear that.
>
>> Of course, spin_lock_irqsave() is a more safe choice, with several
>> extra instruction overhead.
>> And in order to be sure _irq works, we need further tests for sure.
>>
> Nah, we're talking about correctness, which is something one should be
> really be able to assess by looking at the code, rather than by
> testing! Looking at the code, one concludes that spin_lock_irq() is
> what should be used. If testing causes crashes due to using it, either:
>  - we were wrong when looking at the code, and we should look better!
>  - there is a bug somewhere else.
>
> As said, I'm glad that testing so far is confirming the analysis that
> seemed the correct one. :-)
>
> And I wouldn't say that _irqsave() is "more safe choice". It's either
> necessary, and then it should be used, or unnecessary, and then it
> should not.

OK. From what I saw/read in the code, _irq is enough. Further testing
just to "make sure" I didn't miss anything. :-)

>
> There may be situations whether it is hard or impossible to tell
> whether interrupt are disabled already or not (because, e.g., there are
> multiple call paths, with either IRQs disabled or not), and in those
> cases, using _irqsave() can be seen as wanting to be on the safer
> side... But this is not one of those cases, so using _irq() is what's
> right and not less safe than anything else.
>
>> I actually checked somewhere else in schedule.c and couldn't find a
>> place that the priv->lock is used in an irq context with interrupt
>> disabled.
>> So I guess maybe we overuse the spin_lock_irqsave() in the scheduler?
>>
> Perhaps, but I've got a patch series, which I'm trying to find some
> time to finish, where I basically convert almost all locking in
> schedule.c in just plain spin_lock() --i.e., allowing us to keep IRQs
> enabled. If I manage to, _irq() or _irqsave() would not matter any
> longer. :-)
>
> But I'm confused, by the fact that you mention schedule.c, whether you
> are talking about locking that happens inside RTDS code, or in
> schedule.c (me, I'm talking about the latter).

Some of the functions in RTDS code assumes that lock is grab in the
caller, which is in the schedule.c. That's what I meant by looking at
the locking inside schedule.c.
When RTDS functions is called by function in schedule.c with lock
held, I want to make sure the lock is not held in an interrupt
disabled context, i.e., interrupt has not been disabled before it
tries to grab the lock.

>
>> I'm ok that we keep using spin_lock_irqsave() for now.
>>
> If you're talking about this patch, then no, _irq() should be used.
>

OK. then let's use _irq() then unless it causes problem.

>> But maybe
>> later, it will be a better idea to explore if spin_lock_irq() can
>> replace all spin_lock_irqsave() in the RTDS scheduler?
>>
> Maybe, but as I said, I'd like to explore other approaches (I am
> already, actually).

Looking forward to your findings. :-)

>
>> BTW, I'm unsure about the impact of such change on ARM right now.
>>
> And I'm unsure about why you think this is, or should be, architecture
> dependant... can you elaborate?

I don't think it should have difference in x86 and in ARM. However,
perviously, I remembered that RTDS does not work in ARM because the
critical section in context switch in ARM is much longer than that in
x86. That's why RTDS reports error in ARM in terms of locks and was
fixed by global logic guys.

That's why I'm a little bit concern or hold my opinion on the impact
on ARM, since I didn't run the code on ARM yet and have no test data
to back up my understanding.

Thanks and Best Regards,

Meng

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH] xen: arm: zero EL2 pagetable pages before use

[Shanker Donthineni]

Hi Julien,


On 03/12/2016 10:03 AM, Julien Grall wrote:
> Hi,
>
> On 11/03/2016 20:24, Andrew Cooper wrote:
>> On 11/03/16 13:13, Jan Beulich wrote:
>> On 11.03.16 at 13:56,  wrote:
 On 11/03/16 11:29, Jan Beulich wrote:
 On 10.03.16 at 23:00,  wrote:
>> @@ -771,6 +772,7 @@ void __init setup_frametable_mappings(paddr_t ps, 
>> paddr_t pe)
>>   nr_second = frametable_size >> SECOND_SHIFT;
>>   second_base = alloc_boot_pages(nr_second, 1);
>>   second = mfn_to_virt(second_base);
>> +memset(second, 0, nr_second * PAGE_SIZE);
>>   for ( i = 0; i < nr_second; i++ )
>>   {
>>   pte = mfn_to_xen_entry(second_base + i, WRITEALLOC);
> Along those lines here - use clear_page(), presumably by moving it
> into the loop.
 This need only initialise the entries which are not filled by the loop,
 which will only be the rounding size up to the next 2M or 32M boundary.

 Most of the content of 'second' is explicitly initialised, so zeroing it
 all first is redundant.
>>> Well, I certainly don't know all the details of how this works on
>>> ARM, but the way I remember the original problem description
>>> (sent a few days ago) the problem was with bogus translations
>>> to be visible transiently. Of course all depends on whether the
>>> page tables that are being modified here are live ones, which
>>> I simply don't know.
>>
>> Looking at the code here, second is hooked into the live pagetables
>> immediately after the loop.  Therefore, bogus translations will only be
>> present for the untouched PTEs which make up the alignment space.
>
> The frame table size is always aligned to 2MB/32MB. However, the frame table 
> may not use all the entries in a level 2 page table (which cover 1GB of 
> memory). Those unused entries will be unknown if we don't clear them.
>
> Keeping them unknown is not a problem as long as nobody is trying to access 
> the underlying virtual address.
>

I don't agree keeping a garbage value in PTE is not a problem. The ARMv8 
Architecture
allows to perform speculative data/instruction read accesses from memory (type 
normal)
as along as its PTE valid bit is set.

CPU prefetch logic might access garbage PTEs and cause system panic if VA-PA 
translation
happens to be physical address that is not addressable by system BUS.
 

> In the case of setup_frametable_mappings, Xen is still running with a single 
> processor and the frame_table is not access until after create_mappings is 
> called. The function should nuke all the TLBs at the end, so it looks like to 
> me that zeroed the entries will hide the real problem.
>

Not true, zeroed PTE entries fixing the asynchronous aborts and Serror 
exceptions due to garbage
PTEs.

> Nonetheless, I would invalidate all the entries in the table to avoid 
> polluting the TLBs with bogus entries and get a better crash.
>
> Regards,
>

-- 
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

On Mon, Mar 14, 2016 at 10:11 AM, Linus Torvalds
 wrote:
>
> On Mar 14, 2016 10:05 AM, "Andy Lutomirski"  wrote:
>>
>> We could probably remove that check and let custom fixups run early.
>> I don't see any compelling reason to keep them disabled.  That should
>> probably be a separate change, though.
>
> Or we could just use the existing wrmsr_safe() code and not add this new
> special code at all.
>
> Look, why are you doing this? We should get rid of the difference between
> wrmsr and wrmsr_safe(), not make it bigger.
>
> Just make everything safe. There has never in the history of anything been
> an advantage to making things oops and to making things more complicated.
>
> Why is rd/wrmsr() so magically important?

Because none of this is actually safe unless the code that calls
whatever_safe actually does something intelligent with the return
value.  I think that most code that does rdmsr or wrmsr actually
thinks "I know that this MSR exists and I want to access it" and the
code may actually malfunction if the access fails.  So I think we
really do want the warning so we can fix the bugs if they happen.  And
I wouldn't be at all surprised if there's a bug or two in perf where
some perf event registers itself incorrectly in some cases because it
messed up the probe sequence.  We don't want to totally ignore the
resulting failure of the perf event -- we want to get a warning so
that we know about the bug.

Or suppose we're writing some important but easy-to-miss MSR, like PAT
or one of the excessive number of system call setup MSRs.  If the
write fails, the system could easily still appear to work until
something unfortunate happens.

So yes, let's please warn.  I'm okay with removing the panic_on_oops
thing though.  (But if anyone suggests that we should stop OOPSing on
bad kernel page faults, I *will* fight back.)

--Andy

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

Re: [Xen-devel] [PATCH] libxl: use LIBXL__LOG in libxl_ctx_alloc

[Ian Jackson]

Wei Liu writes ("[PATCH] libxl: use LIBXL__LOG in libxl_ctx_alloc"):
> Coverity points out that using LOG macro dereferences gc which is NULL
> at that point. Use LIBXL__LOG instead.
> 
> CID: 1343291
> 
> Signed-off-by: Wei Liu 

Acked-by: Ian Jackson 
Committed-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Linus Torvalds]

On Mar 14, 2016 10:05 AM, "Andy Lutomirski"  wrote:
>
> We could probably remove that check and let custom fixups run early.
> I don't see any compelling reason to keep them disabled.  That should
> probably be a separate change, though.

Or we could just use the existing wrmsr_safe() code and not add this new
special code at all.

Look, why are you doing this? We should get rid of the difference between
wrmsr and wrmsr_safe(), not make it bigger.

Just make everything safe. There has never in the history of anything been
an advantage to making things oops and to making things more complicated.

Why is rd/wrmsr() so magically important?

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

Re: [Xen-devel] [PATCH v4 1/5] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks

[Andy Lutomirski]

On Mon, Mar 14, 2016 at 4:57 AM, Borislav Petkov  wrote:
> On Sat, Mar 12, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
>> These hooks match the _safe variants, so name them accordingly.
>> This will make room for unsafe PV hooks.
>>
>> Signed-off-by: Andy Lutomirski 
>> ---
>>  arch/x86/include/asm/paravirt.h   | 33 +
>>  arch/x86/include/asm/paravirt_types.h |  8 
>>  arch/x86/kernel/paravirt.c|  4 ++--
>>  arch/x86/xen/enlighten.c  |  4 ++--
>>  4 files changed, 25 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/paravirt.h 
>> b/arch/x86/include/asm/paravirt.h
>> index f6192502149e..2e49228ed9a3 100644
>> --- a/arch/x86/include/asm/paravirt.h
>> +++ b/arch/x86/include/asm/paravirt.h
>> @@ -129,34 +129,35 @@ static inline void wbinvd(void)
>>
>>  #define get_kernel_rpl()  (pv_info.kernel_rpl)
>>
>> -static inline u64 paravirt_read_msr(unsigned msr, int *err)
>> +static inline u64 paravirt_read_msr_safe(unsigned msr, int *err)
>>  {
>> - return PVOP_CALL2(u64, pv_cpu_ops.read_msr, msr, err);
>> + return PVOP_CALL2(u64, pv_cpu_ops.read_msr_safe, msr, err);
>>  }
>>
>> -static inline int paravirt_write_msr(unsigned msr, unsigned low, unsigned 
>> high)
>> +static inline int paravirt_write_msr_safe(unsigned msr,
>> +   unsigned low, unsigned high)
>>  {
>> - return PVOP_CALL3(int, pv_cpu_ops.write_msr, msr, low, high);
>> + return PVOP_CALL3(int, pv_cpu_ops.write_msr_safe, msr, low, high);
>>  }
>>
>>  /* These should all do BUG_ON(_err), but our headers are too tangled. */
>>  #define rdmsr(msr, val1, val2)   \
>>  do { \
>>   int _err;   \
>> - u64 _l = paravirt_read_msr(msr, &_err); \
>> + u64 _l = paravirt_read_msr_safe(msr, &_err);\
>>   val1 = (u32)_l; \
>>   val2 = _l >> 32;\
>>  } while (0)
>>
>>  #define wrmsr(msr, val1, val2)   \
>>  do { \
>> - paravirt_write_msr(msr, val1, val2);\
>> + paravirt_write_msr_safe(msr, val1, val2);   \
>>  } while (0)
>>
>>  #define rdmsrl(msr, val) \
>>  do { \
>>   int _err;   \
>> - val = paravirt_read_msr(msr, &_err);\
>> + val = paravirt_read_msr_safe(msr, &_err);   \
>>  } while (0)
>>
>>  static inline void wrmsrl(unsigned msr, u64 val)
>> @@ -164,23 +165,23 @@ static inline void wrmsrl(unsigned msr, u64 val)
>>   wrmsr(msr, (u32)val, (u32)(val>>32));
>>  }
>>
>> -#define wrmsr_safe(msr, a, b)paravirt_write_msr(msr, a, b)
>> +#define wrmsr_safe(msr, a, b)paravirt_write_msr_safe(msr, a, b)
>>
>>  /* rdmsr with exception handling */
>> -#define rdmsr_safe(msr, a, b)\
>> -({   \
>> - int _err;   \
>> - u64 _l = paravirt_read_msr(msr, &_err); \
>> - (*a) = (u32)_l; \
>> - (*b) = _l >> 32;\
>> - _err;   \
>> +#define rdmsr_safe(msr, a, b)\
>> +({   \
>> + int _err;   \
>> + u64 _l = paravirt_read_msr_safe(msr, &_err);\
>> + (*a) = (u32)_l; \
>> + (*b) = _l >> 32;\
>> + _err;   \
>>  })
>>
>>  static inline int rdmsrl_safe(unsigned msr, unsigned long long *p)
>>  {
>>   int err;
>>
>> - *p = paravirt_read_msr(msr, &err);
>> + *p = paravirt_read_msr_safe(msr, &err);
>>   return err;
>>  }
>>
>> diff --git a/arch/x86/include/asm/paravirt_types.h 
>> b/arch/x86/include/asm/paravirt_types.h
>> index 77db5616a473..5a06cccd36f0 100644
>> --- a/arch/x86/include/asm/paravirt_types.h
>> +++ b/arch/x86/include/asm/paravirt_types.h
>> @@ -155,10 +155,10 @@ struct pv_cpu_ops {
>>   void (*cpuid)(unsigned int *eax, unsigned int *ebx,
>> unsigned int *ecx, unsigned int *edx);
>>
>> - /* MSR, PMC and TSR operations.
>> -err = 0/-EFAULT.  wrmsr returns 0/-EFAULT. */
>> - u64 (*read_msr)(unsigned int msr, int *err);
>> - int (*write_msr)(unsigned int msr, unsigned low, unsigned high);
>> + /* MSR operations.
>> +err = 0/-EIO.  wrmsr returns 0/-EIO. */
>
> Please fix the comment format while you're touching this :
>
> /*
>  * A sentence.
>  * Another sentence.
>  */
>
> Other than that:
>
> Acked-by: Borislav Petkov 

I fixed this in "x86/paravirt: Add paravirt_{read,write}_msr" later in
the series.  Is that good enough?

--Andy

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH v2 3/3] xl: new "loglvl" command"):
> They could become more fine grained (for example, Linux has a
> few more than we have now). And the string/number correlation
> is an implementation detail anyway.

Could we solve that problem by multiplying the numbers by 10 ?

Ian.

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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Andy Lutomirski]

On Mon, Mar 14, 2016 at 5:02 AM, Borislav Petkov  wrote:
> On Sat, Mar 12, 2016 at 10:08:49AM -0800, Andy Lutomirski wrote:
>> This demotes an OOPS and likely panic due to a failed non-"safe" MSR
>> access to a WARN_ONCE and, for RDMSR, a return value of zero.  If
>> panic_on_oops is set, then failed unsafe MSR accesses will still
>> oops and panic.
>>
>> To be clear, this type of failure should *not* happen.  This patch
>> exists to minimize the chance of nasty undebuggable failures due on
>> systems that used to work due to a now-fixed CONFIG_PARAVIRT=y bug.
>>
>> Signed-off-by: Andy Lutomirski 
>> ---
>>  arch/x86/include/asm/msr.h | 10 --
>>  arch/x86/mm/extable.c  | 33 +
>>  2 files changed, 41 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
>> index 93fb7c1cffda..1487054a1a70 100644
>> --- a/arch/x86/include/asm/msr.h
>> +++ b/arch/x86/include/asm/msr.h
>> @@ -92,7 +92,10 @@ static inline unsigned long long native_read_msr(unsigned 
>> int msr)
>>  {
>>   DECLARE_ARGS(val, low, high);
>>
>> - asm volatile("rdmsr" : EAX_EDX_RET(val, low, high) : "c" (msr));
>> + asm volatile("1: rdmsr\n"
>> +  "2:\n"
>> +  _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_rdmsr_unsafe)
>> +  : EAX_EDX_RET(val, low, high) : "c" (msr));
>>   if (msr_tracepoint_active(__tracepoint_read_msr))
>>   do_trace_read_msr(msr, EAX_EDX_VAL(val, low, high), 0);
>>   return EAX_EDX_VAL(val, low, high);
>> @@ -119,7 +122,10 @@ static inline unsigned long long 
>> native_read_msr_safe(unsigned int msr,
>>  static inline void native_write_msr(unsigned int msr,
>>   unsigned low, unsigned high)
>>  {
>> - asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high) : "memory");
>> + asm volatile("1: wrmsr\n"
>> +  "2:\n"
>> +  _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)
>
> This might be a good idea:
>
> [0.220066] cpuidle: using governor menu
> [0.224000] [ cut here ]
> [0.224000] WARNING: CPU: 0 PID: 1 at arch/x86/mm/extable.c:74 
> ex_handler_wrmsr_unsafe+0x73/0x80()
> [0.224000] unchecked MSR access error: WRMSR to 0xdeadbeef (tried to 
> write 0xcaca)
> [0.224000] Modules linked in:
> [0.224000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc7+ #7
> [0.224000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.7.5-20140531_083030-gandalf 04/01/2014
> [0.224000]   88007c0d7c08 812f13a3 
> 88007c0d7c50
> [0.224000]  81a40ffe 88007c0d7c40 8105c3b1 
> 81717710
> [0.224000]  88007c0d7d18  816207d0 
> 
> [0.224000] Call Trace:
> [0.224000]  [] dump_stack+0x67/0x94
> [0.224000]  [] warn_slowpath_common+0x91/0xd0
> [0.224000]  [] ? amd_cpu_notify+0x40/0x40
> [0.224000]  [] warn_slowpath_fmt+0x4c/0x50
> [0.224000]  [] ? amd_cpu_notify+0x40/0x40
> [0.224000]  [] ? __this_cpu_preempt_check+0x13/0x20
> [0.224000]  [] ex_handler_wrmsr_unsafe+0x73/0x80
>
> and it looks helpful and all but when you do it pretty early - for
> example I added a
>
>  wrmsrl(0xdeadbeef, 0xcafe);
>
> at the end of pat_bsp_init() and the machine explodes with an early
> panic. I'm wondering what is better - early panic or an early #GP from a
> missing MSR.

You're hitting:

/* special handling not supported during early boot */
if (handler != ex_handler_default)
return 0;


which means that the behavior with and without my series applied is
identical, for better or for worse.

>
> And more specifically, can we do better to handle the early case
> gracefully too?

We could probably remove that check and let custom fixups run early.
I don't see any compelling reason to keep them disabled.  That should
probably be a separate change, though.

--Andy

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

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

[Andy Lutomirski]

On Mon, Mar 14, 2016 at 9:58 AM, Linus Torvalds
 wrote:
>
> On Mar 14, 2016 9:53 AM, "Andy Lutomirski"  wrote:
>>
>> Can you clarify?  KVM uses the native version, and the native version
>> only oopses with this series applied if panic_on_oops is set.
>
> Can we please remove that idiocy?
>
> There is no reason to panic whatsoever. Seriously. What's the upside of that
> logic?

I imagine that people who set panic_on_oops want their systems to stop
running user code if something happens that could corrupt the state or
if there's any sign that user code is trying some non-deterministic
exploit.  So I'm guessing that they'd want this type of "the kernel
screwed up -- abort" to actually result in a panic.

As a concrete, although somewhat silly, example, suppose that a write
to MSR_SYSENTER_STACK fails.  If that happened, then user code could
subsequently try to take over the kernel by evil manipulation of TF
and/or perf.

I'd be okay with removing this too, though, since arranging for MSR
access to fail seems unlikely as an exploit vector.

Borislav: SUSE actually uses panic_on_oops, right?  What's their goal?

--Andy

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

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Jan Beulich]

>>> On 14.03.16 at 17:01,  wrote:
> On Mon, Mar 14, 2016 at 09:49:11AM -0600, Jan Beulich wrote:
>> >>> On 14.03.16 at 16:36,  wrote:
>> > On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote:
>> >> >>> On 08.03.16 at 17:20,  wrote:
>> >> > On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote:
>> >> >> --- a/tools/libxl/xl_cmdimpl.c
>> >> >> +++ b/tools/libxl/xl_cmdimpl.c
>> >> >> @@ -6469,6 +6469,84 @@ int main_debug_keys(int argc, char **arg
>> >> >>  return 0;
>> >> >>  }
>> >> >>  
>> >> >> +static const struct {
>> >> >> +int level;
>> >> >> +char string[8];
>> >> >> +} loglvls[] = {
>> >> >> +{ 0, "none" },
>> >> >> +{ 1, "error" },
>> >> >> +{ 2, "warning" },
>> >> >> +{ 3, "info" },
>> >> >> +{ 4, "all" },
>> >> >> +{ 4, "debug" },
>> >> > 
>> >> > The semantics of the numbers should go into libxl_types.idl. Maybe
>> >> > something like
>> >> > 
>> >> > # Keep in sync with Xen log level.
>> >> > libxl_xen_log_level = Enumeration (...);
>> >> > 
>> >> > Then in here
>> >> > 
>> >> > static const struct {
>> >> > int level;
>> >> > char string[8];
>> >> > } loglvls[] = {
>> >> > { LIBXL_XEN_LOG_LEVEL_NONE, "none" },
>> >> > { ..., "error" },
>> >> > { ..., "warning" },
>> >> > { ..., "info" },
>> >> > { ..., "all" },
>> >> > { ..., "debug" },
>> >> > 
>> >> > Please also note that after the introduction of this API, Xen log level
>> >> > will become part of the stable API and subject to some compatibility
>> >> > constraints. Is this what you wanted?
>> >> 
>> >> No, and I actually I'm having trouble following your request: This
>> >> lives in xl_cmdimpl.c, which I didn't think is subject to any stability
>> >> requirements in the mapping of strings (from the xl command line)
>> >> to numbers. It is _specifically_ that I do not want to fix those
>> >> mappings.
>> > 
>> > The new API libxl_log_level relies on the semantics of these mappings.
>> > To make the new API useful to all clients, the semantics of log levels
>> > needs to go into libxl_types.idl (as mentioned a few lines above), hence
>> > it becomes part of the stable API. Otherwise you end up with an API
>> > accepting arbitrary magic numbers.
>> 
>> Well - what do you suggest? I'm meanwhile willing to give up on this,
>> as baking the mapping into some ABI is clearly not what we should do
>> or what I want. Moving the translation into libxl also wouldn't help.
>> Which would leave the option of doing this in libxc, but then again I'm
>> generally opposed to passing around strings instead of numbers, as
>> the latter are better to work with at all layers.
>> 
> 
> I don't have a very clear idea on what to suggest at the moment, sorry.
> What kind of changes to xen log level might happen in the future?

They could become more fine grained (for example, Linux has a
few more than we have now). And the string/number correlation
is an implementation detail anyway.

Jan


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

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

[Linus Torvalds]

On Mar 14, 2016 9:53 AM, "Andy Lutomirski"  wrote:
>
> Can you clarify?  KVM uses the native version, and the native version
> only oopses with this series applied if panic_on_oops is set.

Can we please remove that idiocy?

There is no reason to panic whatsoever. Seriously. What's the upside of
that logic?

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

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

[Andy Lutomirski]

On Mar 14, 2016 7:03 AM, "Paolo Bonzini"  wrote:
>
>
>
> On 11/03/2016 20:06, Andy Lutomirski wrote:
> > This adds paravirt hooks for unsafe MSR access.  On native, they
> > call native_{read,write}_msr.  On Xen, they use
> > xen_{read,write}_msr_safe.
> >
> > Nothing uses them yet for ease of bisection.  The next patch will
> > use them in rdmsrl, wrmsrl, etc.
> >
> > I intentionally didn't make them OOPS on #GP on Xen.  I think that
> > should be done separately by the Xen maintainers.
>
> Please do the same for KVM.

Can you clarify?  KVM uses the native version, and the native version
only oopses with this series applied if panic_on_oops is set.

--Andy

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

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Dario Faggioli]

On Mon, 2016-03-14 at 12:03 -0400, Meng Xu wrote:
> On Mon, Mar 14, 2016 at 11:38 AM, Meng Xu 
> wrote:
> > 
> > I'm ok that we keep using spin_lock_irqsave() for now. But maybe
> > later, it will be a better idea to explore if spin_lock_irq() can
> > replace all spin_lock_irqsave() in the RTDS scheduler?
> > 
> I rethink about the choice of replacing spin_lock_irqsave with
> spin_lock_irq().
> If in the future ,we will introduce new locks and there may exit the
> situaiton when we want to lock two locks in the same function. In
> that
> case, we won't use spin_lock_irq() but have to use
> spin_lock_irqsave(). If we can mix up spin_lock_irq() with
> spin_lock_irqsave() in different fucntiosn for the same lock, which I
> think we can (right?), we should be fine. Otherwise, we will have to
> keep using spin_lock_irqsave().
> 
Mixing per se is not a problem, it's how you mix...

If you call spin_unlock_irq() within a critical section protected by
either spin_lock_irq() or spin_lock_irqsave(), that is not a good mix!
:-)

if you call _irqsave() inside a critical section protected by either
_irq() or _irqsave(), that's what should be done (it's the purpose of
_irqsave(), actually!).

Actually, in case of nesting, most of the time the inner lock can be
taken by just spin_lock(). Look, for instance, at csched2_dump_pcpu().

With more locks (which I agree is something we want for RTDS), the
biggest issue is going to be getting the actual nesting right, rather
than the various _irq* variants. :-)

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



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

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Dario Faggioli]

On Mon, 2016-03-14 at 11:38 -0400, Meng Xu wrote:
> Hi Dario,
> 
Hi,

> On Mon, Mar 14, 2016 at 7:58 AM, Dario Faggioli
>  wrote:
> > I recommend looking at what happens inside init_timer(), i.e.,
> > where a
> > pointer to this function is stashed. Then, still in
> > xen/common/timer.c,
> > check where this (and, in general, a timer handling function
> > provided
> > to timer_init()) is actually invoked.
> > 
> > When you'll find that spot, the answer to whether spin_lock_irq()
> > is
> > safe or not in here, will appear quite evident. :-)
> Thanks for the pointer! However, it just makes me think that
> spin_lock_irq() can be used.
> 
Well, why the "just" ? :-)

> So IMHO, the replenishment handler will be called in interrupt
> handler
> *and* with interrupt enabled.
> The only difference between lock_irq() and lock_irqsave() is that
> lock_irq() can only be called with interrupt enabled. (lock_irq will
> check if the interrupt is enabled before it disable the interrupt.)
> So I think it is safe to use lock_irq() inside replenishment handler,
> unless there is somewhere call this handler *with interrupt
> disabled*.
> 
I totally agree: _irq() is ok. (Last sentence it's a bit pointless,
considering that this function is a timer handler, and I would not
expect to have a timer handler called by much else than one of the
timer's interupt. :-) )

> OK. I changed the spin_lock_irqsave to spin_lock_irq based on this
> patch. The system works well: system can boot up and will not crash
> after I create a VM
> So I think spin_lock_irq should work...
>
Glad to hear that.

> Of course, spin_lock_irqsave() is a more safe choice, with several
> extra instruction overhead.
> And in order to be sure _irq works, we need further tests for sure.
> 
Nah, we're talking about correctness, which is something one should be
really be able to assess by looking at the code, rather than by
testing! Looking at the code, one concludes that spin_lock_irq() is
what should be used. If testing causes crashes due to using it, either:
 - we were wrong when looking at the code, and we should look better!
 - there is a bug somewhere else.

As said, I'm glad that testing so far is confirming the analysis that
seemed the correct one. :-)

And I wouldn't say that _irqsave() is "more safe choice". It's either
necessary, and then it should be used, or unnecessary, and then it
should not.

There may be situations whether it is hard or impossible to tell
whether interrupt are disabled already or not (because, e.g., there are
multiple call paths, with either IRQs disabled or not), and in those
cases, using _irqsave() can be seen as wanting to be on the safer
side... But this is not one of those cases, so using _irq() is what's
right and not less safe than anything else.

> I actually checked somewhere else in schedule.c and couldn't find a
> place that the priv->lock is used in an irq context with interrupt
> disabled.
> So I guess maybe we overuse the spin_lock_irqsave() in the scheduler?
> 
Perhaps, but I've got a patch series, which I'm trying to find some
time to finish, where I basically convert almost all locking in
schedule.c in just plain spin_lock() --i.e., allowing us to keep IRQs
enabled. If I manage to, _irq() or _irqsave() would not matter any
longer. :-)

But I'm confused, by the fact that you mention schedule.c, whether you
are talking about locking that happens inside RTDS code, or in
schedule.c (me, I'm talking about the latter).

> I'm ok that we keep using spin_lock_irqsave() for now.
>
If you're talking about this patch, then no, _irq() should be used.

> But maybe
> later, it will be a better idea to explore if spin_lock_irq() can
> replace all spin_lock_irqsave() in the RTDS scheduler?
> 
Maybe, but as I said, I'd like to explore other approaches (I am
already, actually).

> BTW, I'm unsure about the impact of such change on ARM right now.
> 
And I'm unsure about why you think this is, or should be, architecture
dependant... can you elaborate?

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



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

[Xen-devel] [PATCH] libxl: use LIBXL__LOG in libxl_ctx_alloc

[Wei Liu]

Coverity points out that using LOG macro dereferences gc which is NULL
at that point. Use LIBXL__LOG instead.

CID: 1343291

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/libxl/libxl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 4cdc169..93e228d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -90,7 +90,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 /* The mutex is special because we can't idempotently destroy it */
 
 if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
-LOG(ERROR, "Failed to initialize mutex");
+LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "Failed to initialize mutex");
 free(ctx);
 ctx = 0;
 rc = ERROR_FAIL;
-- 
2.1.4


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

[Xen-devel] [PATCH v2] xen/arm64: Fix incorrect memory region size in TCR_EL2

[Shanker Donthineni]

The maximum and minimum values for TxSZ depend on level of
translation as per AArch64 Virtual Memory System Architecture.
According to ARM specification DDI0487A_h (sec D4.2.2, page 1752),
the minimum TxSZ value is 16. If TxSZ is programmed to a value
smaller than 16 then it is IMPLEMENTATION DEFINED.

This patch sets T0SZ to (64-48)bits since XEN uses all 4 levels
to cover 48bit (256TB) virtual address instead of value zero.

Signed-off-by: Shanker Donthineni 
---
Changed since v1:
Edit commit descriprtion.

 xen/arch/arm/arm64/head.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 19fa2bb..946e2c9 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -342,8 +342,8 @@ skip_bss:
  * Top byte is used
  * PT walks use Inner-Shareable accesses,
  * PT walks are write-back, write-allocate in both cache levels,
- * Full 64-bit address space goes through this table. */
-ldr   x0, 
=(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(0))
+ * 48-bit virtual address space goes through this table. */
+ldr   x0, 
=(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(64-48))
 /* ID_AA64MMFR0_EL1[3:0] (PARange) corresponds to TCR_EL2[18:16] (PS) 
*/
 mrs   x1, ID_AA64MMFR0_EL1
 bfi   x0, x1, #16, #3
-- 
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
a Linux Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH] x86: partially revert use of 2M mappings for hypervisor image

[Andrew Cooper]

On 14/03/16 15:41, Jan Beulich wrote:
 On 14.03.16 at 16:23,  wrote:
>> On 14/03/16 15:12, Jan Beulich wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -497,6 +497,17 @@ static void __init kexec_reserve_area(st
>>>  #endif
>>>  }
>>>  
>>> +static inline bool_t using_2M_mapping(void)
>>> +{
>>> +return !l1_table_offset((unsigned long)__2M_text_end) &&
>>> +   !l1_table_offset((unsigned long)__2M_rodata_start) &&
>>> +   !l1_table_offset((unsigned long)__2M_rodata_end) &&
>>> +   !l1_table_offset((unsigned long)__2M_init_start) &&
>>> +   !l1_table_offset((unsigned long)__2M_init_end) &&
>>> +   !l1_table_offset((unsigned long)__2M_rwdata_start) &&
>>> +   !l1_table_offset((unsigned long)__2M_rwdata_end);
>> I would recommend
>>
>> #ifdef EFI
>> return 1;
>> #else
>> return 0;
>> #endif
>>
>> The compiler is unable to collapse that expression into a constant,
>> because it can only be evaluated at link time.
> But that wouldn't work, since setup.c gets compiled just once. The
> only usable difference in building is the linking stage. (And
> performance here is of no issue - this gets executed exactly twice.)

Oh yes - that fact keeps on escaping me.  It is only an interim
solution, so is fine to stay.

>>> @@ -922,6 +942,8 @@ void __init noreturn __start_xen(unsigne
>>>   * Undo the temporary-hooking of the l1_identmap.  
>>> __2M_text_start
>>>   * is contained in this PTE.
>>>   */
>>> +BUG_ON(l2_table_offset((unsigned long)_erodata) ==
>>> +   l2_table_offset((unsigned long)_stext));
>> Is this intentional to stay, or the remnants of debugging?
> This is intentional, as it documents the validity of the immediately
> following page table write: The change is not undoing the RWX ->
> RX change that your original patch did, and using RX past
> _erodata would obviously be wrong.

Ah yes.

~Andrew

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

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Wei Liu]

On Mon, Mar 14, 2016 at 09:49:11AM -0600, Jan Beulich wrote:
> >>> On 14.03.16 at 16:36,  wrote:
> > On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote:
> >> >>> On 08.03.16 at 17:20,  wrote:
> >> > On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote:
> >> >> --- a/tools/libxl/xl_cmdimpl.c
> >> >> +++ b/tools/libxl/xl_cmdimpl.c
> >> >> @@ -6469,6 +6469,84 @@ int main_debug_keys(int argc, char **arg
> >> >>  return 0;
> >> >>  }
> >> >>  
> >> >> +static const struct {
> >> >> +int level;
> >> >> +char string[8];
> >> >> +} loglvls[] = {
> >> >> +{ 0, "none" },
> >> >> +{ 1, "error" },
> >> >> +{ 2, "warning" },
> >> >> +{ 3, "info" },
> >> >> +{ 4, "all" },
> >> >> +{ 4, "debug" },
> >> > 
> >> > The semantics of the numbers should go into libxl_types.idl. Maybe
> >> > something like
> >> > 
> >> > # Keep in sync with Xen log level.
> >> > libxl_xen_log_level = Enumeration (...);
> >> > 
> >> > Then in here
> >> > 
> >> > static const struct {
> >> > int level;
> >> > char string[8];
> >> > } loglvls[] = {
> >> > { LIBXL_XEN_LOG_LEVEL_NONE, "none" },
> >> > { ..., "error" },
> >> > { ..., "warning" },
> >> > { ..., "info" },
> >> > { ..., "all" },
> >> > { ..., "debug" },
> >> > 
> >> > Please also note that after the introduction of this API, Xen log level
> >> > will become part of the stable API and subject to some compatibility
> >> > constraints. Is this what you wanted?
> >> 
> >> No, and I actually I'm having trouble following your request: This
> >> lives in xl_cmdimpl.c, which I didn't think is subject to any stability
> >> requirements in the mapping of strings (from the xl command line)
> >> to numbers. It is _specifically_ that I do not want to fix those
> >> mappings.
> > 
> > The new API libxl_log_level relies on the semantics of these mappings.
> > To make the new API useful to all clients, the semantics of log levels
> > needs to go into libxl_types.idl (as mentioned a few lines above), hence
> > it becomes part of the stable API. Otherwise you end up with an API
> > accepting arbitrary magic numbers.
> 
> Well - what do you suggest? I'm meanwhile willing to give up on this,
> as baking the mapping into some ABI is clearly not what we should do
> or what I want. Moving the translation into libxl also wouldn't help.
> Which would leave the option of doing this in libxc, but then again I'm
> generally opposed to passing around strings instead of numbers, as
> the latter are better to work with at all layers.
> 

I don't have a very clear idea on what to suggest at the moment, sorry.
What kind of changes to xen log level might happen in the future?

Wei.


> Jan
> 

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

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Meng Xu]

On Mon, Mar 14, 2016 at 11:38 AM, Meng Xu  wrote:
> Hi Dario,
>
> On Mon, Mar 14, 2016 at 7:58 AM, Dario Faggioli
>  wrote:
>> On Fri, 2016-03-11 at 23:54 -0500, Meng Xu wrote:
>>>
>>> > @@ -1150,6 +1300,101 @@ rt_dom_cntl(
>>> >  return rc;
>>> >  }
>>> >
>>> > +/*
>>> > + * The replenishment timer handler picks vcpus
>>> > + * from the replq and does the actual replenishment.
>>> > + */
>>> > +static void repl_handler(void *data){
>>> > +unsigned long flags;
>>> > +s_time_t now = NOW();
>>> > +struct scheduler *ops = data;
>>> > +struct rt_private *prv = rt_priv(ops);
>>> > +struct list_head *replq = rt_replq(ops);
>>> > +struct list_head *runq = rt_runq(ops);
>>> > +struct timer *repl_timer = prv->repl_timer;
>>> > +struct list_head *iter, *tmp;
>>> > +struct list_head tmp_replq;
>>> > +struct rt_vcpu *svc = NULL;
>>> > +
>>> > +spin_lock_irqsave(&prv->lock, flags);
>>> Hmm, I haven't thought hard about the choice between
>>> spin_lock_irqsave() and spin_lock_irq(), before.
>>>
>>> Hi Dario,
>>> Is it better to use spin_lock_irqsave() or spin_lock_irq() at this
>>> place?
>>>
>> Just very quickly about this (I'll comment about the rest of the patch
>> later).
>>
>>> I'm not quite sure if the handler can be called in an interrupt
>>> disabled context? Can it?
>>>
>> I recommend looking at what happens inside init_timer(), i.e., where a
>> pointer to this function is stashed. Then, still in xen/common/timer.c,
>> check where this (and, in general, a timer handling function provided
>> to timer_init()) is actually invoked.
>>
>> When you'll find that spot, the answer to whether spin_lock_irq() is
>> safe or not in here, will appear quite evident. :-)
>
> Thanks for the pointer! However, it just makes me think that
> spin_lock_irq() can be used.
>
> timer_softirq_action() will call the execute_timer(), which will call
> the handler function.
>
> static void execute_timer(struct timers *ts, struct timer *t)
>
> {
>
> void (*fn)(void *) = t->function;
>
> void *data = t->data;
>
>
> t->status = TIMER_STATUS_inactive;
>
> list_add(&t->inactive, &ts->inactive);
>
>
> ts->running = t;
>
> spin_unlock_irq(&ts->lock);
>
> (*fn)(data);
>
> spin_lock_irq(&ts->lock);
>
> ts->running = NULL;
>
> }
>
> I loooked into the spin_unlock_irq()
>
> void _spin_unlock_irq(spinlock_t *lock)
>
> {
>
> _spin_unlock(lock);
>
> local_irq_enable();
>
> }
>
> in which, lock_irq_enable() will set the interrupt flag:
> #define local_irq_enable()  asm volatile ( "sti" : : : "memory" )
>
> So IMHO, the replenishment handler will be called in interrupt handler
> *and* with interrupt enabled.
> The only difference between lock_irq() and lock_irqsave() is that
> lock_irq() can only be called with interrupt enabled. (lock_irq will
> check if the interrupt is enabled before it disable the interrupt.)
> So I think it is safe to use lock_irq() inside replenishment handler,
> unless there is somewhere call this handler *with interrupt disabled*.
>
> OK. I changed the spin_lock_irqsave to spin_lock_irq based on this
> patch. The system works well: system can boot up and will not crash
> after I create a VM
> So I think spin_lock_irq should work...
> Of course, spin_lock_irqsave() is a more safe choice, with several
> extra instruction overhead.
> And in order to be sure _irq works, we need further tests for sure.
>
> I actually checked somewhere else in schedule.c and couldn't find a
> place that the priv->lock is used in an irq context with interrupt
> disabled.
> So I guess maybe we overuse the spin_lock_irqsave() in the scheduler?
>
> What do you think?
>
> I'm ok that we keep using spin_lock_irqsave() for now. But maybe
> later, it will be a better idea to explore if spin_lock_irq() can
> replace all spin_lock_irqsave() in the RTDS scheduler?
>
> BTW, I'm unsure about the impact of such change on ARM right now.
>

I rethink about the choice of replacing spin_lock_irqsave with spin_lock_irq().
If in the future ,we will introduce new locks and there may exit the
situaiton when we want to lock two locks in the same function. In that
case, we won't use spin_lock_irq() but have to use
spin_lock_irqsave(). If we can mix up spin_lock_irq() with
spin_lock_irqsave() in different fucntiosn for the same lock, which I
think we can (right?), we should be fine. Otherwise, we will have to
keep using spin_lock_irqsave().

Thanks,

Meng

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Jan Beulich]

>>> On 14.03.16 at 16:36,  wrote:
> On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote:
>> >>> On 08.03.16 at 17:20,  wrote:
>> > On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote:
>> >> --- a/tools/libxl/xl_cmdimpl.c
>> >> +++ b/tools/libxl/xl_cmdimpl.c
>> >> @@ -6469,6 +6469,84 @@ int main_debug_keys(int argc, char **arg
>> >>  return 0;
>> >>  }
>> >>  
>> >> +static const struct {
>> >> +int level;
>> >> +char string[8];
>> >> +} loglvls[] = {
>> >> +{ 0, "none" },
>> >> +{ 1, "error" },
>> >> +{ 2, "warning" },
>> >> +{ 3, "info" },
>> >> +{ 4, "all" },
>> >> +{ 4, "debug" },
>> > 
>> > The semantics of the numbers should go into libxl_types.idl. Maybe
>> > something like
>> > 
>> > # Keep in sync with Xen log level.
>> > libxl_xen_log_level = Enumeration (...);
>> > 
>> > Then in here
>> > 
>> > static const struct {
>> > int level;
>> > char string[8];
>> > } loglvls[] = {
>> > { LIBXL_XEN_LOG_LEVEL_NONE, "none" },
>> > { ..., "error" },
>> > { ..., "warning" },
>> > { ..., "info" },
>> > { ..., "all" },
>> > { ..., "debug" },
>> > 
>> > Please also note that after the introduction of this API, Xen log level
>> > will become part of the stable API and subject to some compatibility
>> > constraints. Is this what you wanted?
>> 
>> No, and I actually I'm having trouble following your request: This
>> lives in xl_cmdimpl.c, which I didn't think is subject to any stability
>> requirements in the mapping of strings (from the xl command line)
>> to numbers. It is _specifically_ that I do not want to fix those
>> mappings.
> 
> The new API libxl_log_level relies on the semantics of these mappings.
> To make the new API useful to all clients, the semantics of log levels
> needs to go into libxl_types.idl (as mentioned a few lines above), hence
> it becomes part of the stable API. Otherwise you end up with an API
> accepting arbitrary magic numbers.

Well - what do you suggest? I'm meanwhile willing to give up on this,
as baking the mapping into some ABI is clearly not what we should do
or what I want. Moving the translation into libxl also wouldn't help.
Which would leave the option of doing this in libxc, but then again I'm
generally opposed to passing around strings instead of numbers, as
the latter are better to work with at all layers.

Jan


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

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Meng Xu]

Hi Dario,

On Mon, Mar 14, 2016 at 7:58 AM, Dario Faggioli
 wrote:
> On Fri, 2016-03-11 at 23:54 -0500, Meng Xu wrote:
>>
>> > @@ -1150,6 +1300,101 @@ rt_dom_cntl(
>> >  return rc;
>> >  }
>> >
>> > +/*
>> > + * The replenishment timer handler picks vcpus
>> > + * from the replq and does the actual replenishment.
>> > + */
>> > +static void repl_handler(void *data){
>> > +unsigned long flags;
>> > +s_time_t now = NOW();
>> > +struct scheduler *ops = data;
>> > +struct rt_private *prv = rt_priv(ops);
>> > +struct list_head *replq = rt_replq(ops);
>> > +struct list_head *runq = rt_runq(ops);
>> > +struct timer *repl_timer = prv->repl_timer;
>> > +struct list_head *iter, *tmp;
>> > +struct list_head tmp_replq;
>> > +struct rt_vcpu *svc = NULL;
>> > +
>> > +spin_lock_irqsave(&prv->lock, flags);
>> Hmm, I haven't thought hard about the choice between
>> spin_lock_irqsave() and spin_lock_irq(), before.
>>
>> Hi Dario,
>> Is it better to use spin_lock_irqsave() or spin_lock_irq() at this
>> place?
>>
> Just very quickly about this (I'll comment about the rest of the patch
> later).
>
>> I'm not quite sure if the handler can be called in an interrupt
>> disabled context? Can it?
>>
> I recommend looking at what happens inside init_timer(), i.e., where a
> pointer to this function is stashed. Then, still in xen/common/timer.c,
> check where this (and, in general, a timer handling function provided
> to timer_init()) is actually invoked.
>
> When you'll find that spot, the answer to whether spin_lock_irq() is
> safe or not in here, will appear quite evident. :-)

Thanks for the pointer! However, it just makes me think that
spin_lock_irq() can be used.

timer_softirq_action() will call the execute_timer(), which will call
the handler function.

static void execute_timer(struct timers *ts, struct timer *t)

{

void (*fn)(void *) = t->function;

void *data = t->data;


t->status = TIMER_STATUS_inactive;

list_add(&t->inactive, &ts->inactive);


ts->running = t;

spin_unlock_irq(&ts->lock);

(*fn)(data);

spin_lock_irq(&ts->lock);

ts->running = NULL;

}

I loooked into the spin_unlock_irq()

void _spin_unlock_irq(spinlock_t *lock)

{

_spin_unlock(lock);

local_irq_enable();

}

in which, lock_irq_enable() will set the interrupt flag:
#define local_irq_enable()  asm volatile ( "sti" : : : "memory" )

So IMHO, the replenishment handler will be called in interrupt handler
*and* with interrupt enabled.
The only difference between lock_irq() and lock_irqsave() is that
lock_irq() can only be called with interrupt enabled. (lock_irq will
check if the interrupt is enabled before it disable the interrupt.)
So I think it is safe to use lock_irq() inside replenishment handler,
unless there is somewhere call this handler *with interrupt disabled*.

OK. I changed the spin_lock_irqsave to spin_lock_irq based on this
patch. The system works well: system can boot up and will not crash
after I create a VM
So I think spin_lock_irq should work...
Of course, spin_lock_irqsave() is a more safe choice, with several
extra instruction overhead.
And in order to be sure _irq works, we need further tests for sure.

I actually checked somewhere else in schedule.c and couldn't find a
place that the priv->lock is used in an irq context with interrupt
disabled.
So I guess maybe we overuse the spin_lock_irqsave() in the scheduler?

What do you think?

I'm ok that we keep using spin_lock_irqsave() for now. But maybe
later, it will be a better idea to explore if spin_lock_irq() can
replace all spin_lock_irqsave() in the RTDS scheduler?

BTW, I'm unsure about the impact of such change on ARM right now.

>
>> When I used the spin_lock_irq(save), I just refered to what credit2
>> scheduler does, but didn't think hard enough about which one has
>> better performance.
>>
> I'm not sure what you mean when you talk about Credit2, as there are no
> timers in there. In any case, it is indeed the case that, if just
> _irq() is safe, we should use it, as it's cheaper.

I mean when I first wrote the RTDS scheduler, I just use
spin_lock_irqsave() instead of spin_lock_irq() without considering the
overhead. At that time, I just refer to credit2 and see how it uses
locks. Since it uses spin_lock_irqsave() in other functions, say
_dom_cntl(), I just use the same function and it worked. ;-) (Well, I
should have thought more about the better choice as what I'm doing
now. :-))

Meng

-- 
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH] x86: partially revert use of 2M mappings for hypervisor image

[Jan Beulich]

>>> On 14.03.16 at 16:23,  wrote:
> On 14/03/16 15:12, Jan Beulich wrote:
>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -497,6 +497,17 @@ static void __init kexec_reserve_area(st
>>  #endif
>>  }
>>  
>> +static inline bool_t using_2M_mapping(void)
>> +{
>> +return !l1_table_offset((unsigned long)__2M_text_end) &&
>> +   !l1_table_offset((unsigned long)__2M_rodata_start) &&
>> +   !l1_table_offset((unsigned long)__2M_rodata_end) &&
>> +   !l1_table_offset((unsigned long)__2M_init_start) &&
>> +   !l1_table_offset((unsigned long)__2M_init_end) &&
>> +   !l1_table_offset((unsigned long)__2M_rwdata_start) &&
>> +   !l1_table_offset((unsigned long)__2M_rwdata_end);
> 
> I would recommend
> 
> #ifdef EFI
> return 1;
> #else
> return 0;
> #endif
> 
> The compiler is unable to collapse that expression into a constant,
> because it can only be evaluated at link time.

But that wouldn't work, since setup.c gets compiled just once. The
only usable difference in building is the linking stage. (And
performance here is of no issue - this gets executed exactly twice.)

>> @@ -509,10 +520,19 @@ static void noinline init_done(void)
>>  for ( va = __init_begin; va < _p(__init_end); va += PAGE_SIZE )
>>  clear_page(va);
>>  
>> -/* Destroy Xen's mappings, and reuse the pages. */
>> -destroy_xen_mappings((unsigned long)&__2M_init_start,
>> - (unsigned long)&__2M_init_end);
>> -init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
>> +if ( using_2M_mapping() )
>> +{
>> +/* Destroy Xen's mappings, and reuse the pages. */
> 
> I would be tempted to leave this comment back outside using_2M_mapping()
> which reduces the size of this hunk.

Oh, of course.

>> @@ -922,6 +942,8 @@ void __init noreturn __start_xen(unsigne
>>   * Undo the temporary-hooking of the l1_identmap.  
>> __2M_text_start
>>   * is contained in this PTE.
>>   */
>> +BUG_ON(l2_table_offset((unsigned long)_erodata) ==
>> +   l2_table_offset((unsigned long)_stext));
> 
> Is this intentional to stay, or the remnants of debugging?

This is intentional, as it documents the validity of the immediately
following page table write: The change is not undoing the RWX ->
RX change that your original patch did, and using RX past
_erodata would obviously be wrong.

> Irrespective of some of these minor tweaks, Reviewed-by: Andrew Cooper
> 

Thanks.

Jan


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

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Wei Liu]

On Mon, Mar 14, 2016 at 09:23:35AM -0600, Jan Beulich wrote:
> >>> On 08.03.16 at 17:20,  wrote:
> > On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote:
> >> This is pretty simplistic for now, but I'd rather have someone better
> >> friends with the tools improve it (if desired).
> >> 
> >> Signed-off-by: Jan Beulich 
> >> 
> >> --- a/tools/libxl/libxl.c
> >> +++ b/tools/libxl/libxl.c
> >> @@ -5958,6 +5958,26 @@ int libxl_send_debug_keys(libxl_ctx *ctx
> >>  return 0;
> >>  }
> >>  
> >> +int libxl_log_level(libxl_ctx *ctx, bool set, bool guest,
> >> +int *lower_thresh, int *upper_thresh)
> >> +{
> >> +int ret;
> >> +GC_INIT(ctx);
> >> +if (set) {
> >> +ret = xc_set_log_level(ctx->xch, guest, *lower_thresh, 
> >> *upper_thresh);
> >> +} else {
> >> +ret = xc_get_log_level(ctx->xch, guest, lower_thresh, 
> >> upper_thresh);
> >> +}
> >> +if ( ret < 0 ) {
> >> +LOGE(ERROR, "%s %slog level",
> >> + set ? "setting" : "getting", guest ? "guest " : "");
> >> +GC_FREE;
> >> +return ERROR_FAIL;
> >> +}
> >> +GC_FREE;
> >> +return 0;
> >> +}
> >> +
> > 
> > As Dario said, libxl tends to have getter and setter pair.
> 
> "Tends to have" still leaves room for me to get away without
> adjustments. Could you please clearly state whether splitting
> this is required for acceptance?
> 

Yes, please make a pair of getter and setter.

> >> --- a/tools/libxl/xl_cmdimpl.c
> >> +++ b/tools/libxl/xl_cmdimpl.c
> >> @@ -6469,6 +6469,84 @@ int main_debug_keys(int argc, char **arg
> >>  return 0;
> >>  }
> >>  
> >> +static const struct {
> >> +int level;
> >> +char string[8];
> >> +} loglvls[] = {
> >> +{ 0, "none" },
> >> +{ 1, "error" },
> >> +{ 2, "warning" },
> >> +{ 3, "info" },
> >> +{ 4, "all" },
> >> +{ 4, "debug" },
> > 
> > The semantics of the numbers should go into libxl_types.idl. Maybe
> > something like
> > 
> > # Keep in sync with Xen log level.
> > libxl_xen_log_level = Enumeration (...);
> > 
> > Then in here
> > 
> > static const struct {
> > int level;
> > char string[8];
> > } loglvls[] = {
> > { LIBXL_XEN_LOG_LEVEL_NONE, "none" },
> > { ..., "error" },
> > { ..., "warning" },
> > { ..., "info" },
> > { ..., "all" },
> > { ..., "debug" },
> > 
> > Please also note that after the introduction of this API, Xen log level
> > will become part of the stable API and subject to some compatibility
> > constraints. Is this what you wanted?
> 
> No, and I actually I'm having trouble following your request: This
> lives in xl_cmdimpl.c, which I didn't think is subject to any stability
> requirements in the mapping of strings (from the xl command line)
> to numbers. It is _specifically_ that I do not want to fix those
> mappings.
> 

The new API libxl_log_level relies on the semantics of these mappings.
To make the new API useful to all clients, the semantics of log levels
needs to go into libxl_types.idl (as mentioned a few lines above), hence
it becomes part of the stable API. Otherwise you end up with an API
accepting arbitrary magic numbers.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH] x86: partially revert use of 2M mappings for hypervisor image

[Andrew Cooper]

On 14/03/16 15:12, Jan Beulich wrote:
> As explained by Andrew in
> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01380.html 
> that change makes the uncompressed xen.gz image too large for certain
> boot environments. As a result this change makes some of the effects of
> commits cf393624ee ("x86: use 2M superpages for text/data/bss
> mappings") and 53aa3dde17 ("x86: unilaterally remove .init mappings")
> conditional, restoring alternative previous code where necessary. This
> is so that xen.efi can still benefit from the new mechanisms, as it is
> unaffected by said limitations.
>
> Signed-off-by: Jan Beulich 
> ---
> The first, neater attempt (making the __2M_* symbols weak) failed:
> - older gcc doesn't access the weak symbols through .got
> - GOTPCREL relocations get treated just like PCREL ones by ld when
>   linking xen.efi
>
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -497,6 +497,17 @@ static void __init kexec_reserve_area(st
>  #endif
>  }
>  
> +static inline bool_t using_2M_mapping(void)
> +{
> +return !l1_table_offset((unsigned long)__2M_text_end) &&
> +   !l1_table_offset((unsigned long)__2M_rodata_start) &&
> +   !l1_table_offset((unsigned long)__2M_rodata_end) &&
> +   !l1_table_offset((unsigned long)__2M_init_start) &&
> +   !l1_table_offset((unsigned long)__2M_init_end) &&
> +   !l1_table_offset((unsigned long)__2M_rwdata_start) &&
> +   !l1_table_offset((unsigned long)__2M_rwdata_end);

I would recommend

#ifdef EFI
return 1;
#else
return 0;
#endif

The compiler is unable to collapse that expression into a constant,
because it can only be evaluated at link time.

> +}
> +
>  static void noinline init_done(void)
>  {
>  void *va;
> @@ -509,10 +520,19 @@ static void noinline init_done(void)
>  for ( va = __init_begin; va < _p(__init_end); va += PAGE_SIZE )
>  clear_page(va);
>  
> -/* Destroy Xen's mappings, and reuse the pages. */
> -destroy_xen_mappings((unsigned long)&__2M_init_start,
> - (unsigned long)&__2M_init_end);
> -init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
> +if ( using_2M_mapping() )
> +{
> +/* Destroy Xen's mappings, and reuse the pages. */

I would be tempted to leave this comment back outside using_2M_mapping()
which reduces the size of this hunk.

> +destroy_xen_mappings((unsigned long)&__2M_init_start,
> + (unsigned long)&__2M_init_end);
> +init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
> +}
> +else
> +{
> +destroy_xen_mappings((unsigned long)&__init_begin,
> + (unsigned long)&__init_end);
> +init_xenheap_pages(__pa(__init_begin), __pa(__init_end));
> +}
>  
>  printk("Freed %ldkB init memory.\n", 
> (long)(__init_end-__init_begin)>>10);
>  
> @@ -922,6 +942,8 @@ void __init noreturn __start_xen(unsigne
>   * Undo the temporary-hooking of the l1_identmap.  
> __2M_text_start
>   * is contained in this PTE.
>   */
> +BUG_ON(l2_table_offset((unsigned long)_erodata) ==
> +   l2_table_offset((unsigned long)_stext));

Is this intentional to stay, or the remnants of debugging?

Irrespective of some of these minor tweaks, Reviewed-by: Andrew Cooper


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

Re: [Xen-devel] [PATCH] x86: move both exception tables into .rodata

[Andrew Cooper]

On 14/03/16 15:15, Jan Beulich wrote:
> While they are being written during early boot (when sorting them),
> that writing takes place before we actually start fiddling with page
> table permissions, so these tables can benefit from getting write
> protected just like ordinary r/o data does (for now only when using
> 2M mappings).
>
> Signed-off-by: Jan Beulich 

I had a plan to modify the build to sort these at build time, like Linux
does.  But either way, this is an improvement.

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Jan Beulich]

>>> On 08.03.16 at 17:20,  wrote:
> On Fri, Mar 04, 2016 at 09:48:16AM -0700, Jan Beulich wrote:
>> This is pretty simplistic for now, but I'd rather have someone better
>> friends with the tools improve it (if desired).
>> 
>> Signed-off-by: Jan Beulich 
>> 
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -5958,6 +5958,26 @@ int libxl_send_debug_keys(libxl_ctx *ctx
>>  return 0;
>>  }
>>  
>> +int libxl_log_level(libxl_ctx *ctx, bool set, bool guest,
>> +int *lower_thresh, int *upper_thresh)
>> +{
>> +int ret;
>> +GC_INIT(ctx);
>> +if (set) {
>> +ret = xc_set_log_level(ctx->xch, guest, *lower_thresh, 
>> *upper_thresh);
>> +} else {
>> +ret = xc_get_log_level(ctx->xch, guest, lower_thresh, upper_thresh);
>> +}
>> +if ( ret < 0 ) {
>> +LOGE(ERROR, "%s %slog level",
>> + set ? "setting" : "getting", guest ? "guest " : "");
>> +GC_FREE;
>> +return ERROR_FAIL;
>> +}
>> +GC_FREE;
>> +return 0;
>> +}
>> +
> 
> As Dario said, libxl tends to have getter and setter pair.

"Tends to have" still leaves room for me to get away without
adjustments. Could you please clearly state whether splitting
this is required for acceptance?

>> --- a/tools/libxl/xl_cmdimpl.c
>> +++ b/tools/libxl/xl_cmdimpl.c
>> @@ -6469,6 +6469,84 @@ int main_debug_keys(int argc, char **arg
>>  return 0;
>>  }
>>  
>> +static const struct {
>> +int level;
>> +char string[8];
>> +} loglvls[] = {
>> +{ 0, "none" },
>> +{ 1, "error" },
>> +{ 2, "warning" },
>> +{ 3, "info" },
>> +{ 4, "all" },
>> +{ 4, "debug" },
> 
> The semantics of the numbers should go into libxl_types.idl. Maybe
> something like
> 
> # Keep in sync with Xen log level.
> libxl_xen_log_level = Enumeration (...);
> 
> Then in here
> 
> static const struct {
> int level;
> char string[8];
> } loglvls[] = {
> { LIBXL_XEN_LOG_LEVEL_NONE, "none" },
> { ..., "error" },
> { ..., "warning" },
> { ..., "info" },
> { ..., "all" },
> { ..., "debug" },
> 
> Please also note that after the introduction of this API, Xen log level
> will become part of the stable API and subject to some compatibility
> constraints. Is this what you wanted?

No, and I actually I'm having trouble following your request: This
lives in xl_cmdimpl.c, which I didn't think is subject to any stability
requirements in the mapping of strings (from the xl command line)
to numbers. It is _specifically_ that I do not want to fix those
mappings.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  71b165d2d4215c1556b62231d127a233225360ee
baseline version:
 xen  e46a729b18af85b4dd040578643f7fa430b22a48

Last test of basis85936  2016-03-10 20:01:05 Z3 days
Testing same since86218  2016-03-14 13:01:52 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Kevin Tian 
  Quan Xu 

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=71b165d2d4215c1556b62231d127a233225360ee
+ . ./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 
71b165d2d4215c1556b62231d127a233225360ee
+ branch=xen-unstable-smoke
+ revision=71b165d2d4215c1556b62231d127a233225360ee
+ . ./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-coverity
+ '[' x71b165d2d4215c1556b62231d127a233225360ee = 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 
'g

[Xen-devel] [PATCH] x86: move both exception tables into .rodata

[Jan Beulich]

While they are being written during early boot (when sorting them),
that writing takes place before we actually start fiddling with page
table permissions, so these tables can benefit from getting write
protected just like ordinary r/o data does (for now only when using
2M mappings).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -73,6 +73,17 @@ SECTIONS
*(.rodata)
*(.rodata.*)
 
+   . = ALIGN(8);
+   /* Exception table */
+   __start___ex_table = .;
+   *(.ex_table)
+   __stop___ex_table = .;
+
+   /* Pre-exception table */
+   __start___pre_ex_table = .;
+   *(.ex_table.pre)
+   __stop___pre_ex_table = .;
+
 #ifdef LOCK_PROFILE
. = ALIGN(POINTER_ALIGN);
__lock_profile_start = .;
@@ -154,16 +165,6 @@ SECTIONS
   __2M_rwdata_start = .;   /* Start of 2M superpages, mapped RW. */
   . = ALIGN(SMP_CACHE_BYTES);
   .data.read_mostly : {
-   /* Exception table */
-   __start___ex_table = .;
-   *(.ex_table)
-   __stop___ex_table = .;
-
-   /* Pre-exception table */
-   __start___pre_ex_table = .;
-   *(.ex_table.pre)
-   __stop___pre_ex_table = .;
-
*(.data.read_mostly)
. = ALIGN(8);
__start_schedulers_array = .;



x86: move both exception tables into .rodata

While they are being written during early boot (when sorting them),
that writing takes place before we actually start fiddling with page
table permissions, so these tables can benefit from getting write
protected just like ordinary r/o data does (for now only when using
2M mappings).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -73,6 +73,17 @@ SECTIONS
*(.rodata)
*(.rodata.*)
 
+   . = ALIGN(8);
+   /* Exception table */
+   __start___ex_table = .;
+   *(.ex_table)
+   __stop___ex_table = .;
+
+   /* Pre-exception table */
+   __start___pre_ex_table = .;
+   *(.ex_table.pre)
+   __stop___pre_ex_table = .;
+
 #ifdef LOCK_PROFILE
. = ALIGN(POINTER_ALIGN);
__lock_profile_start = .;
@@ -154,16 +165,6 @@ SECTIONS
   __2M_rwdata_start = .;   /* Start of 2M superpages, mapped RW. */
   . = ALIGN(SMP_CACHE_BYTES);
   .data.read_mostly : {
-   /* Exception table */
-   __start___ex_table = .;
-   *(.ex_table)
-   __stop___ex_table = .;
-
-   /* Pre-exception table */
-   __start___pre_ex_table = .;
-   *(.ex_table.pre)
-   __stop___pre_ex_table = .;
-
*(.data.read_mostly)
. = ALIGN(8);
__start_schedulers_array = .;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] x86: partially revert use of 2M mappings for hypervisor image

[Jan Beulich]

As explained by Andrew in
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01380.html 
that change makes the uncompressed xen.gz image too large for certain
boot environments. As a result this change makes some of the effects of
commits cf393624ee ("x86: use 2M superpages for text/data/bss
mappings") and 53aa3dde17 ("x86: unilaterally remove .init mappings")
conditional, restoring alternative previous code where necessary. This
is so that xen.efi can still benefit from the new mechanisms, as it is
unaffected by said limitations.

Signed-off-by: Jan Beulich 
---
The first, neater attempt (making the __2M_* symbols weak) failed:
- older gcc doesn't access the weak symbols through .got
- GOTPCREL relocations get treated just like PCREL ones by ld when
  linking xen.efi

--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -497,6 +497,17 @@ static void __init kexec_reserve_area(st
 #endif
 }
 
+static inline bool_t using_2M_mapping(void)
+{
+return !l1_table_offset((unsigned long)__2M_text_end) &&
+   !l1_table_offset((unsigned long)__2M_rodata_start) &&
+   !l1_table_offset((unsigned long)__2M_rodata_end) &&
+   !l1_table_offset((unsigned long)__2M_init_start) &&
+   !l1_table_offset((unsigned long)__2M_init_end) &&
+   !l1_table_offset((unsigned long)__2M_rwdata_start) &&
+   !l1_table_offset((unsigned long)__2M_rwdata_end);
+}
+
 static void noinline init_done(void)
 {
 void *va;
@@ -509,10 +520,19 @@ static void noinline init_done(void)
 for ( va = __init_begin; va < _p(__init_end); va += PAGE_SIZE )
 clear_page(va);
 
-/* Destroy Xen's mappings, and reuse the pages. */
-destroy_xen_mappings((unsigned long)&__2M_init_start,
- (unsigned long)&__2M_init_end);
-init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
+if ( using_2M_mapping() )
+{
+/* Destroy Xen's mappings, and reuse the pages. */
+destroy_xen_mappings((unsigned long)&__2M_init_start,
+ (unsigned long)&__2M_init_end);
+init_xenheap_pages(__pa(__2M_init_start), __pa(__2M_init_end));
+}
+else
+{
+destroy_xen_mappings((unsigned long)&__init_begin,
+ (unsigned long)&__init_end);
+init_xenheap_pages(__pa(__init_begin), __pa(__init_end));
+}
 
 printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
 
@@ -922,6 +942,8 @@ void __init noreturn __start_xen(unsigne
  * Undo the temporary-hooking of the l1_identmap.  __2M_text_start
  * is contained in this PTE.
  */
+BUG_ON(l2_table_offset((unsigned long)_erodata) ==
+   l2_table_offset((unsigned long)_stext));
 *pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
PAGE_HYPERVISOR_RX | _PAGE_PSE);
 for ( i = 1; i < L2_PAGETABLE_ENTRIES; i++, pl2e++ )
@@ -931,6 +953,13 @@ void __init noreturn __start_xen(unsigne
 if ( !(l2e_get_flags(*pl2e) & _PAGE_PRESENT) )
 continue;
 
+if ( !using_2M_mapping() )
+{
+*pl2e = l2e_from_intpte(l2e_get_intpte(*pl2e) +
+xen_phys_start);
+continue;
+}
+
 if ( i < l2_table_offset((unsigned long)&__2M_text_end) )
 {
 flags = PAGE_HYPERVISOR_RX | _PAGE_PSE;
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -53,11 +53,14 @@ SECTIONS
_etext = .; /* End of text section */
   } :text = 0x9090
 
+#ifdef EFI
   . = ALIGN(MB(2));
+#endif
   __2M_text_end = .;
 
   __2M_rodata_start = .;   /* Start of 2M superpages, mapped RO. */
   .rodata : {
+   _srodata = .;
/* Bug frames table */
. = ALIGN(4);
__start_bug_frames = .;
@@ -79,9 +82,12 @@ SECTIONS
*(.lockprofile.data)
__lock_profile_end = .;
 #endif
+   _erodata = .;
   } :text
 
+#ifdef EFI
   . = ALIGN(MB(2));
+#endif
   __2M_rodata_end = .;
 
   __2M_init_start = .; /* Start of 2M superpages, mapped RWX (boot 
only). */
@@ -148,7 +154,9 @@ SECTIONS
   . = ALIGN(PAGE_SIZE);
   __init_end = .;
 
+#ifdef EFI
   . = ALIGN(MB(2));
+#endif
   __2M_init_end = .;
 
   __2M_rwdata_start = .;   /* Start of 2M superpages, mapped RW. */
@@ -200,7 +208,9 @@ SECTIONS
   } :text
   _end = . ;
 
+#ifdef EFI
   . = ALIGN(MB(2));
+#endif
   __2M_rwdata_end = .;
 
 #ifdef EFI
@@ -250,6 +260,7 @@ ASSERT(kexec_reloc_size - kexec_reloc <=
 #endif
 
 ASSERT(IS_ALIGNED(__2M_text_start,   MB(2)), "__2M_text_start misaligned")
+#ifdef EFI
 ASSERT(IS_ALIGNED(__2M_text_end, MB(2)), "__2M_text_end misaligned")
 ASSERT(IS_ALIGNED(__2M_rodata_start, MB(2)), "__2M_rodata_start misaligned")
 ASSERT(IS_ALIGNED(__2M_rodata_end,   MB(2)), "__2M_rodata_end misalign

[Xen-devel] [xen-unstable test] 86183: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-i386  6 xen-boot fail in 86132 pass in 86183
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 86132
 test-armhf-armhf-libvirt-xsm  4 host-ping-check-native  fail pass in 86132

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 86132 like 86059
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail   like 85995
 build-amd64-rumpuserxen   6 xen-buildfail   like 86132
 build-i386-rumpuserxen6 xen-buildfail   like 86132
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 86132
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 86132
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86132
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86132

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-rtds 13 saverestore-support-check fail in 86132 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 86132 never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 86132 never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail in 86132 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-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-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-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  e46a729b18af85b4dd040578643f7fa430b22a48
baseline version:
 xen  e46a729b18af85b4dd040578643f7fa430b22a48

Last test of basis86183  2016-03-14 03:44:29 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16874 days0 attempts

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 

Re: [Xen-devel] [PATCH] xen/arm64: Fix incorrect memory region size in TCR2_EL2

[Julien Grall]

On 14/03/16 14:37, Shanker Donthineni wrote:

HI Jullen,


Hi Shanker,


On 03/12/2016 07:13 AM, Julien Grall wrote:

Hi Shanker,

On 11/03/2016 04:28, Shanker Donthineni wrote:

The maximum and minimum values for T0SZ depend on level of
translation as per AArch64 Virtual Memory System Architecture.
The current code sets T0SZ to zero in TCR2_EL2 which is not


s/TCR2_EL2/TCR_EL2/



Sorry for typo, I will fix in next patch


valid and also might see unexpected behavior on some CPUs.


Can you provide more details?



We are not able to boot XEN on Qualcomm platforms and CPU hung after
after executing this line of ASM code.


I looked at the specification, programming the field T0SZ to 0 is valid
(see D4-1463 ARM DDI 0487A.b):

"For a stage 1 translation
The minimum TxSZ value is 16. If TxSZ is programmed to a value smaller
than 16 then the implementation behaves as if the field were programmed
to 16 for all purposes other than reading back the value of the field."



The behavior of T0SZ=0 is described in ARM spec (DDI0487A_h, page 1752). Still 
I think setting
the T0SZ to 48bit is the right fix similar to LINUX KVM64 EL2 code.

For a stage 1 translation
The minimum TxSZ value is 16. If TxSZ is programmed to a value smaller than 16 
then it is
IMPLEMENTATION DEFINED whether:

• The implementation behaves as if the field were programmed to 16 for all 
purposes other than
reading back the value of the field.

• Any use of the TxSZ value generates a stage 1 Level 0 Translation fault.


Sorry, I was looking at an older version of the ARM ARM where only a 
single possible behavior was described. So this change looks valid to me.


Can you please mention the version and the section of the spec in the 
commit message?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm64: Fix incorrect memory region size in TCR2_EL2

[Shanker Donthineni]

HI Jullen,

On 03/12/2016 07:13 AM, Julien Grall wrote:
> Hi Shanker,
>
> On 11/03/2016 04:28, Shanker Donthineni wrote:
>> The maximum and minimum values for T0SZ depend on level of
>> translation as per AArch64 Virtual Memory System Architecture.
>> The current code sets T0SZ to zero in TCR2_EL2 which is not
>
> s/TCR2_EL2/TCR_EL2/
>

Sorry for typo, I will fix in next patch

>> valid and also might see unexpected behavior on some CPUs.
>
> Can you provide more details?
>

We are not able to boot XEN on Qualcomm platforms and CPU hung after
after executing this line of ASM code.

> I looked at the specification, programming the field T0SZ to 0 is valid
> (see D4-1463 ARM DDI 0487A.b):
>
> "For a stage 1 translation
> The minimum TxSZ value is 16. If TxSZ is programmed to a value smaller
> than 16 then the implementation behaves as if the field were programmed
> to 16 for all purposes other than reading back the value of the field."
>

The behavior of T0SZ=0 is described in ARM spec (DDI0487A_h, page 1752). Still 
I think setting
the T0SZ to 48bit is the right fix similar to LINUX KVM64 EL2 code.

For a stage 1 translation
The minimum TxSZ value is 16. If TxSZ is programmed to a value smaller than 16 
then it is
IMPLEMENTATION DEFINED whether:

• The implementation behaves as if the field were programmed to 16 for all 
purposes other than
reading back the value of the field.

• Any use of the TxSZ value generates a stage 1 Level 0 Translation fault.


>> This patch sets T0SZ to (64-48)bits since XEN uses all 4 levels
>> to cover 48bit (256TB) virtual address space.
>>
>> Signed-off-by: Shanker Donthineni 
>> ---
>>   xen/arch/arm/arm64/head.S | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
>> index 19fa2bb..28ee404 100644
>> --- a/xen/arch/arm/arm64/head.S
>> +++ b/xen/arch/arm/arm64/head.S
>> @@ -343,7 +343,7 @@ skip_bss:
>>* PT walks use Inner-Shareable accesses,
>>* PT walks are write-back, write-allocate in both cache levels,
>>* Full 64-bit address space goes through this table. */
>
> This comment is no longer valid with your changes. Please update it.
>

Sure, I will change to 48bit virtual address space.
>> -ldr   x0, 
>> =(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(0))
>> +ldr   x0, 
>> =(TCR_RES1|TCR_SH0_IS|TCR_ORGN0_WBWA|TCR_IRGN0_WBWA|TCR_T0SZ(64-48))
>>   /* ID_AA64MMFR0_EL1[3:0] (PARange) corresponds to TCR_EL2[18:16] 
>> (PS) */
>>   mrs   x1, ID_AA64MMFR0_EL1
>>   bfi   x0, x1, #16, #3
>>
>
> Regards,
>

-- 
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH v4 0/5] [PATCH v3 0/5] Improve non-"safe" MSR access failure handling

[Boris Ostrovsky]

On 03/12/2016 01:08 PM, Andy Lutomirski wrote:

Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently
turns all rdmsr and wrmsr operations into the safe variants without
any checks that the operations actually succeed.

With CONFIG_PARAVIRT=n, unchecked MSR failures OOPS and probably
cause boot to fail if they happen before init starts.

Neither behavior is very good, and it's particularly unfortunate that
the behavior changes depending on CONFIG_PARAVIRT.

In particular, KVM guests might be unwittingly depending on the
PARAVIRT=y behavior because CONFIG_KVM_GUEST currently depends on
CONFIG_PARAVIRT, and, because accesses in that case are completely
unchecked, we wouldn't even see a warning.

This series changes the native behavior, regardless of
CONFIG_PARAVIRT.  A non-"safe" MSR failure will give an informative
warning once and will be fixed up -- native_read_msr will return
zero, and both reads and writes will continue where they left off.

If panic_on_oops is set, they will still OOPS and panic.

By using the shiny new custom exception handler infrastructure,
there should be no overhead on the success paths.

I didn't change the behavior on Xen, but, with this series applied,
it would be straightforward for the Xen maintainers to make the
corresponding change -- knowledge of whether the access is "safe" is
now propagated into the pvops.

Doing this is probably a prerequisite to sanely decoupling
CONFIG_KVM_GUEST and CONFIG_PARAVIRT, which would probably make
Arjan and the rest of the Clear Containers people happy :)

There's also room to reduce the code size of the "safe" variants
using custom exception handlers in the future.

Changes from v3:
  - WARN_ONCE instead of WARN (Ingo)
  - In the warning text, s/unsafe/unchecked/ (Ingo, sort of)

Changes from earlier versions: lots of changes!

Andy Lutomirski (5):
   x86/paravirt: Add _safe to the read_msr and write_msr PV hooks
   x86/msr: Carry on after a non-"safe" MSR access fails without
 !panic_on_oops
   x86/paravirt: Add paravirt_{read,write}_msr
   x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y
   x86/msr: Set the return value to zero when native_rdmsr_safe fails

  arch/x86/include/asm/msr.h| 20 
  arch/x86/include/asm/paravirt.h   | 45 +--
  arch/x86/include/asm/paravirt_types.h | 14 +++
  arch/x86/kernel/paravirt.c|  6 +++--
  arch/x86/mm/extable.c | 33 +
  arch/x86/xen/enlighten.c  | 27 +++--
  6 files changed, 114 insertions(+), 31 deletions(-)



I don't see any issues as far as Xen is concerned but let me run this 
through our nightly. I'll wait for the next version (which I think you 
might have based on the comments). Please copy me.


-boris

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

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

[Dushyant Behl]

Hi Konrad,

On Mon, Mar 14, 2016 at 7:42 PM, Konrad Rzeszutek Wilk
 wrote:
>> After changing the console name to hvc0 the only thing which I noticed
>> differently is
>> that after the last line where Xen frees some init memory, I am able to see
>> the linux
>> kernel decompression message -
>>
>> "(XEN) DOM0: Uncompressing Linux... done, booting the kernel.
>>
>> But after that the system just hangs the same way without any response on
>> the network either.
>
> Has Linux been compiled with the appropiate CONFIG_ parameters? That is you
> have Xen enabled on it?

Yes, I have enabled these configuration parameters when compiling linux -

CONFIG_XEN_DOM0=y
CONFIG_XEN=y
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_NETDEV_FRONTEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PRIVCMD=y
CONFIG_XEN_AUTO_XLATE=y

Thanks,
Dushyant

>>
>> Thanks,
>> Dushyant
>
>> ___
>> 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] Running Xen on Nvidia Jetson-TK1

[Konrad Rzeszutek Wilk]

> After changing the console name to hvc0 the only thing which I noticed
> differently is
> that after the last line where Xen frees some init memory, I am able to see
> the linux
> kernel decompression message -
> 
> "(XEN) DOM0: Uncompressing Linux... done, booting the kernel.
> 
> But after that the system just hangs the same way without any response on
> the network either.

Has Linux been compiled with the appropiate CONFIG_ parameters? That is you
have Xen enabled on it?

> 
> Thanks,
> Dushyant

> ___
> 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 1/3] xenalyze: handle DOM0 operaions events

[Dario Faggioli]

On Mon, 2016-03-14 at 10:06 -0400, Konrad Rzeszutek Wilk wrote:
> On Sat, Mar 12, 2016 at 12:33:57PM +0100, Dario Faggioli wrote:
> > 
> > (i.e., domain creation and destruction) so the
> > trace will show properly decoded info, rather
> > than just a bunch of hex codes.
> Weirdly you also lost your SoB.
> 
So, typo in subject and no SoB... What a great patch I sent!! :-O

I guess I'll resend. :-)

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



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

Re: [Xen-devel] [PATCH 1/3] xenalyze: handle DOM0 operaions events

[Konrad Rzeszutek Wilk]

On Sat, Mar 12, 2016 at 12:33:57PM +0100, Dario Faggioli wrote:
> (i.e., domain creation and destruction) so the
> trace will show properly decoded info, rather
> than just a bunch of hex codes.

Weirdly you also lost your SoB.

> ---
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Konrad Rzeszutek Wilk 
> ---
> Changes from v1:
>  * new patch in the series.
> ---
>  tools/xentrace/xenalyze.c |   26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
> index d4a5b0c..353bed7 100644
> --- a/tools/xentrace/xenalyze.c
> +++ b/tools/xentrace/xenalyze.c
> @@ -8388,6 +8388,30 @@ void hw_process(struct pcpu_info *p)
>  }
>  
>  }
> +
> +#define TRC_DOM0_SUB_DOMOPS 1
> +void dom0_process(struct pcpu_info *p)
> +{
> +struct record_info *ri = &p->ri;
> +
> +switch(ri->evt.sub)
> +{
> +case TRC_DOM0_SUB_DOMOPS:
> +if(opt.dump_all) {
> +struct {
> +unsigned int domid;
> +} *r = (typeof(r))ri->d;
> +
> +printf(" %s %s domain d%u\n", ri->dump_header,
> +   ri->event == TRC_DOM0_DOM_ADD ? "creating" : "destroying",
> +   r->domid);
> +}
> +break;
> +default:
> +process_generic(&p->ri);
> +}
> +}
> +
>  /*  Base - */
>  void dump_generic(FILE * f, struct record_info *ri)
>  {
> @@ -9224,6 +9248,8 @@ void process_record(struct pcpu_info *p) {
>  hw_process(p);
>  break;
>  case TRC_DOM0OP_MAIN:
> +dom0_process(p);
> +break;
>  default:
>  process_generic(ri);
>  }
> 

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

Re: [Xen-devel] [PATCH 2/2] xsm: move FLASK_AVC_STATS to Kconfig

[Doug Goldstein]

On 3/8/16 12:01 PM, Daniel De Graaf wrote:
> On 03/08/2016 11:51 AM, Jan Beulich wrote:
> On 08.03.16 at 17:22,  wrote:
>>> On 03/08/2016 04:46 AM, Jan Beulich wrote:
>>> On 07.03.16 at 19:42,  wrote:
> Have Kconfig set CONFIG_FLASK_AVC_STATS and prefix all uses with
> CONFIG_
> to use the Kconfig variable.

 Same question here: What's the benefit of doing it this way?
>>>
>>> This removes the stats tracking, which might (I have not tested)
>>> speed up
>>> the security server by avoiding the __get_cpu_var call and increment.
>>
>> No, I don not think the patch removes anything. The Kconfig option
>> doesn't have a prompt. But anyway, ...
> 
> Ah, I missed that: I saw the --help-- line and assumed it was the prompt.
> Either way, this #define is a configuration-like knob that doesn't need to
> be hard-coded in a header as it currently is.
> 
>>
>>> The
>>> corresponding SELinux knob is a Kconfig option in Linux.
>>>
>>> Acked-by: Daniel De Graaf 
>>
>> ... if you're fine with it, we'll put it in (once the mechanical issues
>> got addressed).
> 

Daniel,

Would you like me to make this a real configuration option? Or proceed
with the current path and we can make a configuration option later?

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

[Paolo Bonzini]

On 11/03/2016 20:06, Andy Lutomirski wrote:
> This adds paravirt hooks for unsafe MSR access.  On native, they
> call native_{read,write}_msr.  On Xen, they use
> xen_{read,write}_msr_safe.
> 
> Nothing uses them yet for ease of bisection.  The next patch will
> use them in rdmsrl, wrmsrl, etc.
> 
> I intentionally didn't make them OOPS on #GP on Xen.  I think that
> should be done separately by the Xen maintainers.

Please do the same for KVM.

Paolo

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

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Meng Xu]

On Mon, Mar 14, 2016 at 7:48 AM, Dario Faggioli
 wrote:
> On Sun, 2016-03-13 at 11:43 -0400, Meng Xu wrote:
>> On Sat, Mar 12, 2016 at 5:21 PM, Chen, Tianyang > > wrote:
>> > On 03/11/2016 11:54 PM, Meng Xu wrote:
>> > > One more thing we should think about is:
>> > > How can we "prove/test" the correctness of the scheduler?
>> > > Can we use xentrace to record the scheduling trace and then write
>> > > a
>> > > userspace program to check the scheduling trace is obeying the
>> > > priority rules of the scheduler.
>> > >
>> > Thanks for the review Meng, I am still exploring xentrace and it
>> > can output
>> > scheduling events such as which vcpu is running on a pcpu. I think
>> > it's
>> > possible for the userspace program to check RTDS, based on
>> > cur_budget and
>> > cur_deadline. We need to have a very clear outline of rules, for
>> > the things
>> > we are concerned about. When you say correctness, what does it
>> > include? I'm
>> > thinking about rules for when a vcpu should preempt, tickle and
>> > actually be
>> > picked.
>> What you said should be included...
>> What's in my mind is checking the invariants in the EDF scheduling
>> policy.
>> For example, at any time, the running VCPUs should have higher
>> priority than the VCPUs in runq;
>> At any time, the runq and replenish queue should be sorted based on
>> EDF policy.
>>
> This would be rather useful, but it's really difficult. It was "a
> thing" already when I was doing research on RT systems, i.e., a few
> years ago.
>
> Fact is, there always be (transitory, hopefully) situations where the
> schedule is not compliant with EDF, because of scheduling overhead,
> timers resolution, irq waiting being re-enabled, etc.
> The, as far as I can remember, is how to distinguish with an actual
> transient state and a real bug in the coding of the algorithm.
>
> At the time, there was some work on it, and my research group was also
> interested in doing something similar for the EDF scheduler we were
> pushing to Linux. We never got to do much, though, and the only
> reference I can recall of and find, right now, of others' work is this:
>
> https://www.cs.unc.edu/~mollison/unit-trace/index.html
> http://www.cs.unc.edu/~mollison/pubs/ospert09.pdf

Right! I knew this one in LITMUS and it is great! Every time when
Bjorn update LITMUS, he only needs to run a bunches of test to make
sure the update does not mess things up.
If we could have something like this, that will be awesome!
I suspect that they should also have the similar situation as we face
here. They also have the scheduling latency, timers resolution, etc.
We could probably ask them.

Actually, we can bound the time spent in the transient state, that
will be also useful! This will at least tell us how well the scheduler
follows the gEDF scheduling policy. :-)

>
> It was for LITMUS-RT, so adaptation would be required to make it
> process a xentrace/xenalyze event log (provided it's finished and
> working, which I don't think).
>
> I can ask my old colleagues if they remember more, and whether anything
> happened since I left, in the RT community about that (although, the
> latter, you guys are in a way better position than me to check! :-P).
>

Sure! I will also ask around and will get back to this list later.

Thanks,

Meng

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [patch 1/4] hotplug: Prevent alloc/free of irq descriptors during cpu up/down

[Boris Ostrovsky]

On 03/12/2016 04:19 AM, Thomas Gleixner wrote:

Boris,

On Tue, 14 Jul 2015, Boris Ostrovsky wrote:

On 07/14/2015 04:15 PM, Thomas Gleixner wrote:

The issue here is that all architectures need that protection and just
Xen does irq allocations in cpu_up.

So moving that protection into architecture code is not really an
option.


Otherwise we will need to have something like arch_post_cpu_up()
after the lock is released.

I'm not sure, that this will work. You probably want to do this in the
cpu prepare stage, i.e. before calling __cpu_up().

For PV guests (the ones that use xen_cpu_up()) it will work either before
or
after __cpu_up(). At least my (somewhat limited) testing didn't show any
problems so far.

However, HVM CPUs use xen_hvm_cpu_up() and if you read comments there you
will
see that xen_smp_intr_init() needs to be called before native_cpu_up() but
xen_init_lock_cpu() (which eventually calls irq_alloc_descs()) needs to be
called after.

I think I can split xen_init_lock_cpu() so that the part that needs to be
called after will avoid going into irq core code. And then the rest will
go
into arch_cpu_prepare().

I think we should revisit this for 4.3. For 4.2 we can do the trivial
variant and move the locking in native_cpu_up() and x86 only. x86 was
the only arch on which such wreckage has been seen in the wild, but we
should have that protection for all archs in the long run.

Patch below should fix the issue.

Thanks! Most of my tests passed, I had a couple of failures but I will need to
see whether they are related to this patch.

Did you ever come around to address that irq allocation from within cpu_up()?

I really want to generalize the protection instead of carrying that x86 only
hack forever.


Sorry, I completely forgot about this. Let me see how I can take 
allocations from under the lock. I might just be able to put them in CPU 
notifiers --- most into CPU_UP_PREPARE but spinlock interrupt may need 
to go into CPU_ONLINE.


-boris


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

Re: [Xen-devel] [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

[Borislav Petkov]

On Sat, Mar 12, 2016 at 10:08:49AM -0800, Andy Lutomirski wrote:
> This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> access to a WARN_ONCE and, for RDMSR, a return value of zero.  If
> panic_on_oops is set, then failed unsafe MSR accesses will still
> oops and panic.
> 
> To be clear, this type of failure should *not* happen.  This patch
> exists to minimize the chance of nasty undebuggable failures due on
> systems that used to work due to a now-fixed CONFIG_PARAVIRT=y bug.
> 
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/include/asm/msr.h | 10 --
>  arch/x86/mm/extable.c  | 33 +
>  2 files changed, 41 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
> index 93fb7c1cffda..1487054a1a70 100644
> --- a/arch/x86/include/asm/msr.h
> +++ b/arch/x86/include/asm/msr.h
> @@ -92,7 +92,10 @@ static inline unsigned long long native_read_msr(unsigned 
> int msr)
>  {
>   DECLARE_ARGS(val, low, high);
>  
> - asm volatile("rdmsr" : EAX_EDX_RET(val, low, high) : "c" (msr));
> + asm volatile("1: rdmsr\n"
> +  "2:\n"
> +  _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_rdmsr_unsafe)
> +  : EAX_EDX_RET(val, low, high) : "c" (msr));
>   if (msr_tracepoint_active(__tracepoint_read_msr))
>   do_trace_read_msr(msr, EAX_EDX_VAL(val, low, high), 0);
>   return EAX_EDX_VAL(val, low, high);
> @@ -119,7 +122,10 @@ static inline unsigned long long 
> native_read_msr_safe(unsigned int msr,
>  static inline void native_write_msr(unsigned int msr,
>   unsigned low, unsigned high)
>  {
> - asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high) : "memory");
> + asm volatile("1: wrmsr\n"
> +  "2:\n"
> +  _ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_wrmsr_unsafe)

This might be a good idea:

[0.220066] cpuidle: using governor menu
[0.224000] [ cut here ]
[0.224000] WARNING: CPU: 0 PID: 1 at arch/x86/mm/extable.c:74 
ex_handler_wrmsr_unsafe+0x73/0x80()
[0.224000] unchecked MSR access error: WRMSR to 0xdeadbeef (tried to write 
0xcaca)
[0.224000] Modules linked in:
[0.224000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc7+ #7
[0.224000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
[0.224000]   88007c0d7c08 812f13a3 
88007c0d7c50
[0.224000]  81a40ffe 88007c0d7c40 8105c3b1 
81717710
[0.224000]  88007c0d7d18  816207d0 

[0.224000] Call Trace:
[0.224000]  [] dump_stack+0x67/0x94
[0.224000]  [] warn_slowpath_common+0x91/0xd0
[0.224000]  [] ? amd_cpu_notify+0x40/0x40
[0.224000]  [] warn_slowpath_fmt+0x4c/0x50
[0.224000]  [] ? amd_cpu_notify+0x40/0x40
[0.224000]  [] ? __this_cpu_preempt_check+0x13/0x20
[0.224000]  [] ex_handler_wrmsr_unsafe+0x73/0x80

and it looks helpful and all but when you do it pretty early - for
example I added a

 wrmsrl(0xdeadbeef, 0xcafe);

at the end of pat_bsp_init() and the machine explodes with an early
panic. I'm wondering what is better - early panic or an early #GP from a
missing MSR.

And more specifically, can we do better to handle the early case
gracefully too?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

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

Re: [Xen-devel] [PATCH v8]xen: sched: convert RTDS from time to event driven model

[Dario Faggioli]

On Fri, 2016-03-11 at 23:54 -0500, Meng Xu wrote:
> 
> > @@ -1150,6 +1300,101 @@ rt_dom_cntl(
> >  return rc;
> >  }
> > 
> > +/*
> > + * The replenishment timer handler picks vcpus
> > + * from the replq and does the actual replenishment.
> > + */
> > +static void repl_handler(void *data){
> > +unsigned long flags;
> > +s_time_t now = NOW();
> > +struct scheduler *ops = data;
> > +struct rt_private *prv = rt_priv(ops);
> > +struct list_head *replq = rt_replq(ops);
> > +struct list_head *runq = rt_runq(ops);
> > +struct timer *repl_timer = prv->repl_timer;
> > +struct list_head *iter, *tmp;
> > +struct list_head tmp_replq;
> > +struct rt_vcpu *svc = NULL;
> > +
> > +spin_lock_irqsave(&prv->lock, flags);
> Hmm, I haven't thought hard about the choice between
> spin_lock_irqsave() and spin_lock_irq(), before.
> 
> Hi Dario,
> Is it better to use spin_lock_irqsave() or spin_lock_irq() at this
> place?
> 
Just very quickly about this (I'll comment about the rest of the patch
later).

> I'm not quite sure if the handler can be called in an interrupt
> disabled context? Can it?
>
I recommend looking at what happens inside init_timer(), i.e., where a
pointer to this function is stashed. Then, still in xen/common/timer.c,
check where this (and, in general, a timer handling function provided
to timer_init()) is actually invoked.

When you'll find that spot, the answer to whether spin_lock_irq() is
safe or not in here, will appear quite evident. :-)

> When I used the spin_lock_irq(save), I just refered to what credit2
> scheduler does, but didn't think hard enough about which one has
> better performance.
>
I'm not sure what you mean when you talk about Credit2, as there are no
timers in there. In any case, it is indeed the case that, if just
_irq() is safe, we should use it, as it's cheaper.

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



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