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

[osstest service owner]

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

Regressions :-(

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

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

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

version targeted for testing:
 linux99f614a3bb23603a947be2e95b78507112c484e5
baseline version:
 linux558ba5fd7d8dbe0b233c309ce89317c1d0858bd7

Last test of basis   100383  2016-08-10 06:22:51 Z   12 days
Testing same since   100587  2016-08-22 21:44:19 Z0 days1 attempts


People who touched revisions under test:
  Adrien Vergé 
  Al Viro 
  Alan Stern 
  Alex Deucher 
  Alex Hung 
  Alexandre Belloni 
  Alexey Dobriyan 
  Alexey Kuznetsov 
  Alexey Kuznetsov 
  Alim Akhtar 
  Amadeusz Sławiński 
  Andreas Gruenbacher 
  Andrew Morton 
  Andrey Ryabinin 
  Andy Shevchenko 
  Aurelien Aptel 
  Ben Hutchings 
  Ben Skeggs 
  Benjamin Coddington 

Re: [Xen-devel] [PATCH v1 7/7] tools: add userspace linker table sandbox

[H. Peter Anvin]

Vrabel ,Konrad Rzeszutek Wilk 
,Michael Brown ,Juergen Gross 
,Andrew Cooper ,Andy Shevchenko 
,Paul Gortmaker 
,"xen-de...@lists.xensource.com" 
,Andi Kleen 
,pali.ro...@gmail.com,dvh...@infradead.org,platform-driver-...@vger.kernel.org,Michal
 Marek ,Rasmus Villemoes ,Jiri 
Kosina ,=?UTF-8?B?7KGw6rK966+8?= 
,linux-kbuild ,Tony Luck 
,Andrew Morton 
,linux-i...@vger.kernel.org,"linux-arm-ker...@lists.infradead.org"
 ,linux-sh 
,sparclinux ,Catalin 
Marinas ,Will Deacon ,Ste!
 ven
Rostedt ,Jani Nikula ,Mauro 
Carvalho Chehab 
,markus.hei...@darmarit.de,jo...@kernel.org,Mark 
Salter ,Chris Zankel ,Max Filippov 
,linux-xte...@linux-xtensa.org,Paul Mackerras 
,Michael Ellerman ,James Bottomley 

Message-ID: <58f06cea-aeb3-4ed7-8211-95f402c9d...@zytor.com>

On August 22, 2016 5:07:39 PM PDT, "Luis R. Rodriguez"  
wrote:
>On Fri, Aug 19, 2016 at 03:31:47PM -0700, Kees Cook wrote:
>> On Fri, Aug 19, 2016 at 2:41 PM,   wrote:
>> > From: "Luis R. Rodriguez" 
>> >
>> > Add a userspace sandbox to allow easy experimentation and
>> > test extensions with linker tables, section ranges and the
>> > new section core definitions.
>> >
>> > The userspace sandbox tries to mimic the Linux kernel development
>> > flow as much as possible, it however relies on and uses libc.
>Support
>> > is currently only provided to x86_64.
>> >
>> > v4: this patch is new in this series -- added to the kenrel as
>> > suggested by Boris, as otherwise it'd be really hard to keep
>> > an external userspace repository in sync.
>> >
>> > Signed-off-by: Luis R. Rodriguez 
>> > ---
>> >  Documentation/sections/linker-tables.rst   |   4 +-
>> >  MAINTAINERS|   1 +
>> >  include/linux/tables.h |   5 +-
>> >  tools/Makefile |   3 +-
>> >  .../arch/x86/include/generated/asm/section-core.h  |   1 +
>> >  tools/arch/x86/include/generated/ranges.h  |   1 +
>> >  tools/arch/x86/include/generated/tables.h  |   1 +
>> >  tools/include/asm-generic/ranges.h | 103 
>> >  tools/include/asm-generic/section-core.h   | 341
>+++
>> >  tools/include/asm-generic/tables.h |  50 ++
>> 
>> Aren't a bunch of these files exact duplicates of the headers in
>include/linux?
>
>Indeed... This a userspace tools/ architecture decision that was made
>long ago,
>so its not up to me, I am just following the strategy devised and
>picked up.
>Refer to 7d7d1bf1d1dabe435ef50efb051724b8664749cb ("perf bench: Copy
>kernel
>files needed to build mem{cpy,set} x86_64 benchmarks") for an example
>of
>previous similar work. By sharing header files this enable more tools/
>to be hacked on.
>
>  Luis

I think this is a legacy from before the uapi change that should really be 
fixed.  If we need to export additional kernel structures for the tools, we 
could define a third level of we really need it.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

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

[Xen-devel] [PATCH -next] xen-netback: using kfree_rcu() to simplify the code

[Wei Yongjun]

From: Wei Yongjun 

The callback function of call_rcu() just calls a kfree(), so we
can use kfree_rcu() instead of call_rcu() + callback function.

Signed-off-by: Wei Yongjun 
---
 drivers/net/xen-netback/hash.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-netback/hash.c
index 282b16d..e8c5ddd 100644
--- a/drivers/net/xen-netback/hash.c
+++ b/drivers/net/xen-netback/hash.c
@@ -32,15 +32,6 @@
 #include 
 #include 
 
-static void xenvif_del_hash(struct rcu_head *rcu)
-{
-   struct xenvif_hash_cache_entry *entry;
-
-   entry = container_of(rcu, struct xenvif_hash_cache_entry, rcu);
-
-   kfree(entry);
-}
-
 static void xenvif_add_hash(struct xenvif *vif, const u8 *tag,
unsigned int len, u32 val)
 {
@@ -76,7 +67,7 @@ static void xenvif_add_hash(struct xenvif *vif, const u8 *tag,
if (++vif->hash.cache.count > xenvif_hash_cache_size) {
list_del_rcu(>link);
vif->hash.cache.count--;
-   call_rcu(>rcu, xenvif_del_hash);
+   kfree_rcu(oldest, rcu);
}
}
 
@@ -114,7 +105,7 @@ static void xenvif_flush_hash(struct xenvif *vif)
list_for_each_entry_rcu(entry, >hash.cache.list, link) {
list_del_rcu(>link);
vif->hash.cache.count--;
-   call_rcu(>rcu, xenvif_del_hash);
+   kfree_rcu(entry, rcu);
}
 
spin_unlock_irqrestore(>hash.cache.lock, flags);




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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Yang Zhang]

On 2016/8/22 22:57, Jan Beulich wrote:

On 22.08.16 at 15:09,  wrote:

On 2016/8/22 20:04, Jan Beulich wrote:

On 22.08.16 at 13:41,  wrote:

On August 22, 2016 6:36 PM,  wrote:

On 19.08.16 at 14:58,  wrote:

From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
From: Quan Xu 
Date: Fri, 19 Aug 2016 20:40:31 +0800
Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
with high payload (with 2vCPU, captured from xentrace, in high payload, the
count of IPI interrupt increases rapidly between these vCPUs).

If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
are both pending (index of bit set in VIRR), unfortunately, the IPI intrrupt
is high priority than periodic timer interrupt. Xen updates IPI interrupt

bit

set in VIRR to guest interrupt status (RVI) as a high priority and apicv
(Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
operation without a VM exit. Within VMX non-root operation, if periodic timer
interrupt index of bit is set in VIRR and highest, the apicv delivers

periodic

timer interrupt within VMX non-root operation as well.

But in current code, if Xen doesn't update periodic timer interrupt bit set
in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
case to decrease the count (pending_intr_nr) of pending periodic timer
interrupt,
then Xen will deliver a periodic timer interrupt again. The guest receives
more
periodic timer interrupt.

If the periodic timer interrut is delivered and not the highest priority,

make

Xen be aware of this case to decrease the count of pending periodic timer
interrupt.


I can see the issue you're trying to address, but for one - doesn't
this lead to other double accounting, namely once the pt irq becomes
the highest priority one?



It is does NOT lead to other double accounting..
As if the pt irq becomes the highest priority one, the intack is pt one..
Then:

 +else
 +pt_intr_post(v, intack);


As just said in reply to Yang: If this is still the same interrupt instance
as in a prior run through here which took the if() branch, this change
looks like having the potential of double accounting.


This cannot happen: if pt intr is the second priority one, then
corresponding vIRR bit will be cleared by hardware while the highest
priority intr is delivered to guest. And the next vmx_intr_assit cannot
aware of it since the vIRR bit is zero.


In addition to what Quan said in response - aren't you mixing up
vISR and vIRR here? I can see vISR being clear when a higher prio


Right. It should be ISR not IRR.


interrupt gets delivered (unless that happened to interrupt the pt
interrupt handler), but I would hope that virtualized behavior
matches non-virtualized one in that vIRR accumulates requests.


--
Yang
Alibaba Cloud Computing

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

[Xen-devel] [PATCH v5] x86/cpuid: AVX-512 Feature Detection

[Luwei Kang]

AVX512 is an extention of AVX2. Its spec can be found at:
https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
This patch detects AVX512 features by CPUID.

Signed-off-by: Luwei Kang 
---
[V5]:
Modify the comment of dependency between AVX512 and AVX2.
[V4]:
Update the description about features dependency.
[V3]:
Adjust dependencies between features.
[V2]:
1.get max xstate_size from each bit.
2.change get cpuid function parameter from 0x07 to 7.
3.add dependencies between features in xen/tools/gen-cpuid.py.
4.split the cpuid call just like the way the hvm_cpuid() side works.
---
 xen/arch/x86/hvm/hvm.c  | 14 ++
 xen/arch/x86/traps.c| 22 +-
 xen/include/public/arch-x86/cpufeatureset.h |  9 +
 xen/tools/gen-cpuid.py  | 10 ++
 4 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7f99087..edea87e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3472,6 +3472,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
   xstate_sizes[_XSTATE_BNDCSR]);
 }
 
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_OPMASK] +
+  xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_ZMM] +
+  xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_HI_ZMM] +
+  xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
 if ( _ecx & cpufeat_mask(X86_FEATURE_PKU) )
 {
 xfeature_mask |= XSTATE_PKRU;
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 767d0b0..8fb697b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -975,7 +975,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
 
 switch ( leaf )
 {
-uint32_t tmp, _ecx;
+uint32_t tmp, _ecx, _ebx;
 
 case 0x0001:
 c &= pv_featureset[FEATURESET_1c];
@@ -1157,6 +1157,26 @@ void pv_cpuid(struct cpu_user_regs *regs)
xstate_sizes[_XSTATE_YMM]);
 }
 
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, 7, 0, , &_ebx, , );
+else
+cpuid_count(7, 0, , &_ebx, , );
+_ebx &= pv_featureset[FEATURESET_7b0];
+
+if ( _ebx & cpufeat_mask(X86_FEATURE_AVX512F) )
+{
+xfeature_mask |= XSTATE_OPMASK | XSTATE_ZMM | XSTATE_HI_ZMM;
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_OPMASK] +
+  xstate_sizes[_XSTATE_OPMASK]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_ZMM] +
+  xstate_sizes[_XSTATE_ZMM]);
+xstate_size = max(xstate_size,
+  xstate_offsets[_XSTATE_HI_ZMM] +
+  xstate_sizes[_XSTATE_HI_ZMM]);
+}
+
 a = (uint32_t)xfeature_mask;
 d = (uint32_t)(xfeature_mask >> 32);
 c = xstate_size;
diff --git a/xen/include/public/arch-x86/cpufeatureset.h 
b/xen/include/public/arch-x86/cpufeatureset.h
index 39acf8c..9320c9e 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -206,15 +206,24 @@ XEN_CPUFEATURE(PQM,   5*32+12) /*   Platform QoS 
Monitoring */
 XEN_CPUFEATURE(NO_FPU_SEL,5*32+13) /*!  FPU CS/DS stored as zero */
 XEN_CPUFEATURE(MPX,   5*32+14) /*S  Memory Protection Extensions */
 XEN_CPUFEATURE(PQE,   5*32+15) /*   Platform QoS Enforcement */
+XEN_CPUFEATURE(AVX512F,   5*32+16) /*A  AVX-512 Foundation Instructions */
+XEN_CPUFEATURE(AVX512DQ,  5*32+17) /*A  AVX-512 Doubleword & Quadword 
Instrs */
 XEN_CPUFEATURE(RDSEED,5*32+18) /*A  RDSEED instruction */
 XEN_CPUFEATURE(ADX,   5*32+19) /*A  ADCX, ADOX instructions */
 XEN_CPUFEATURE(SMAP,  5*32+20) /*S  Supervisor Mode Access Prevention 
*/
+XEN_CPUFEATURE(AVX512IFMA,5*32+21) /*A  AVX-512 Integer Fused Multiply Add 
*/
 XEN_CPUFEATURE(CLFLUSHOPT,5*32+23) /*A  CLFLUSHOPT instruction */
 XEN_CPUFEATURE(CLWB,  5*32+24) /*A  CLWB instruction */
+XEN_CPUFEATURE(AVX512PF,  5*32+26) /*A  AVX-512 Prefetch Instructions */
+XEN_CPUFEATURE(AVX512ER,  5*32+27) /*A  AVX-512 Exponent & 

Re: [Xen-devel] [RFC 11/22] xen/arm: p2m: Introduce p2m_get_root_pointer and use it in __p2m_lookup

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> Mapping the root table is always done the same way. To avoid duplicating
> the code in a later patch, move the code in a separate helper.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/p2m.c | 53 +++--
>  1 file changed, 35 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index ea582c8..d4a4b62 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -204,6 +204,37 @@ static void p2m_flush_tlb_sync(struct p2m_domain *p2m)
>  }
>  
>  /*
> + * Find and map the root page table. The caller is responsible for
> + * unmapping the table.
> + *
> + * The function will return NULL if the offset of the root table is
> + * invalid.
> + */
> +static lpae_t *p2m_get_root_pointer(struct p2m_domain *p2m,
> +gfn_t gfn)
> +{
> +unsigned int root_table;
> +
> +if ( P2M_ROOT_PAGES == 1 )
> +return __map_domain_page(p2m->root);
> +
> +/*
> + * Concatenated root-level tables. The table number will be the
> + * offset at the previous level. It is not possible to
> + * concatenate a level-0 root.
> + */
> +ASSERT(P2M_ROOT_LEVEL > 0);
> +
> +root_table = gfn_x(gfn) >>  (level_shifts[P2M_ROOT_LEVEL - 1] - 
> PAGE_SHIFT);
> +root_table &= LPAE_ENTRY_MASK;
> +
> +if ( root_table >= P2M_ROOT_PAGES )
> +return NULL;
> +
> +return __map_domain_page(p2m->root + root_table);
> +}
> +
> +/*
>   * Lookup the MFN corresponding to a domain's GFN.
>   *
>   * There are no processor functions to do a stage 2 only lookup therefore we
> @@ -226,7 +257,7 @@ static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, 
> p2m_type_t *t)
>  mfn_t mfn = INVALID_MFN;
>  paddr_t mask = 0;
>  p2m_type_t _t;
> -unsigned int level, root_table;
> +unsigned int level;
>  
>  ASSERT(p2m_is_locked(p2m));
>  BUILD_BUG_ON(THIRD_MASK != PAGE_MASK);
> @@ -236,22 +267,9 @@ static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, 
> p2m_type_t *t)
>  
>  *t = p2m_invalid;
>  
> -if ( P2M_ROOT_PAGES > 1 )
> -{
> -/*
> - * Concatenated root-level tables. The table number will be
> - * the offset at the previous level. It is not possible to
> - * concatenate a level-0 root.
> - */
> -ASSERT(P2M_ROOT_LEVEL > 0);
> -root_table = offsets[P2M_ROOT_LEVEL - 1];
> -if ( root_table >= P2M_ROOT_PAGES )
> -goto err;
> -}
> -else
> -root_table = 0;
> -
> -map = __map_domain_page(p2m->root + root_table);
> +map = p2m_get_root_pointer(p2m, gfn);
> +if ( !map )
> +return INVALID_MFN;
>  
>  ASSERT(P2M_ROOT_LEVEL < 4);
>  
> @@ -286,7 +304,6 @@ static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, 
> p2m_type_t *t)
>  *t = pte.p2m.type;
>  }
>  
> -err:
>  return mfn;
>  }
>  
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

[Nicholas Piggin]

On Fri, 19 Aug 2016 14:34:02 -0700
mcg...@kernel.org wrote:

> From: "Luis R. Rodriguez" 
> 
> Linux makes extensive use of custom ELF header sections,
> documentation for these are well scatterred. Unify this
> documentation in a central place and provide helpers to
> build custom Linux sections.
> 
> This also generalizes sections code to enable avoiding
> modifying the linker scripts when we want to add new
> custom Linux sections. In order to make this generally
> useful we need to ensure all architectures can make use of
> core section helpers but that they can also override should
> this be needed. Instead of relying on section.h this adds
> a sections-core.h since this will be targetted to be safe
> to be used on asm code, linker scripts and C code.

Hi Luis,

The linker stuff in the kernel definitely needs someone to take care
of it, so it's good to see some effort to clean up and generalize some
of it.

Not all your patches seem to depend on each other, so it might be good
to push some of the cleanups through first. And some of these core
patches could go in bit by bit if necessary.

On this specific patch: while the as and ld sections syntax and
semantics are pretty ugly and esoteric, I question how much of this is
actually an improvement. Some of it seems to just be wrapping one name
with another, or hiding some behaviour in a maybe not intuitive way.


> +/**
> + * DOC: Standard ELF section use in Linux
> + *
> + * Linux makes use of the standard ELF sections, this sections documents
> + * these.
> + */
> +
> +/**
> + * DOC: SECTION_RODATA
> + *
> + * Macro name for code which must be protected from write access, read only
> + * data.
> + */
> +#define SECTION_RODATA   .rodata

These, for example. The exact name of the section is important in linker
scripts and asm, so I can't see the benefit of hiding it. I could be
missing the bigger picture.


> +/**
> + * DOC: SECTION_TEXT
> + *
> + * Macro name used to annotate code (functions) used during regular
> + * kernel run time. This is combined with `SECTION_RODATA`, only this
> + * section also allows for execution.
> + *
> + */
> +#define SECTION_TEXT .text

I can't see how these comments are right. .rodata doesn't seem like it
should be combined with .text, and is not currently on powerpc. I think
it's for data, not code.


> +/*
> + * These section _ALL() helpers are for use on linker scripts and helpers
> + */
> +#define SECTION_ALL(__section)   
> \
> + __section##.*

This is another example. We know what .text.* does in the linker scripts
-- it's self documenting. But SECTION_ALL(.text)? I'm not sure that's an
improvement. Actually I saw it in the linker script changes and had to
come find the definition because I was a bit mislead:

SECTION_ALL(.text)

Initially I would expect this to be

.text*

Not

.text.*

The latter does not grab the .text section!


> +/*
> + * As per gcc's documentation a common asm separator is a new line followed
> + * by tab [0], it however seems possible to also just use a newline as its
> + * the most commonly empirically observed semantic and folks seem to agree
> + * this even works on S390. In case your architecture disagrees you may
> + * override this and define your own and keep the rest of the macros.
> + *
> + * [0] https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
> + */
> +# ifndef ASM_CMD_SEP
> +#  define ASM_CMD_SEP"\n"
> +# endif

This does not seem like it belongs here. The name is fairly ugly too.
I guess something might be needed like this when dealing with generic
as directives common to all architectures, though. I would say
include/asm-generic/asm.h should be a better place.


> diff --git a/include/linux/sections.h b/include/linux/sections.h
> new file mode 100644
> index ..f21c6ee88ded
> --- /dev/null
> +++ b/include/linux/sections.h
> @@ -0,0 +1,111 @@
> +#ifndef _LINUX_SECTIONS_H
> +#define _LINUX_SECTIONS_H
> +/*
> + * Linux de-facto sections
> + *
> + * Copyright (C) 2016 Luis R. Rodriguez 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of copyleft-next (version 0.3.1 or later) as published
> + * at http://copyleft-next.org/.
> + */
> +
> +#include 
> +#include 
> +
> +#ifndef __ASSEMBLY__
> +
> +/**
> + * DOC: Introduction
> + *
> + * Linux defines a set of common helpers which can be used to against its use
> + * of standard or custom Linux sections, this section is dedicated to these
> + * helpers.

I'm still not quite sure what a Linux de-facto/standard/common section is
after this. Are they output sections?

I think it would be reasonable to drop the LINUX_ prefix and references to
Linux.

Thanks,
Nick

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

Re: [Xen-devel] [RFC 09/22] xen/arm: p2m: Change the type of level_shifts from paddr_t to unsigned int

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> The level shift can be encoded with 32-bit. So it is not necessary to
> use paddr_t (i.e 64-bit).

You might as well use 8 bit. 


> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/p2m.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index a6dce0c..798faa8 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -675,7 +675,7 @@ static const paddr_t level_sizes[] =
>  { ZEROETH_SIZE, FIRST_SIZE, SECOND_SIZE, THIRD_SIZE };
>  static const paddr_t level_masks[] =
>  { ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK };
> -static const paddr_t level_shifts[] =
> +static const unsigned int level_shifts[] =
>  { ZEROETH_SHIFT, FIRST_SHIFT, SECOND_SHIFT, THIRD_SHIFT };
>  
>  static int p2m_shatter_page(struct p2m_domain *p2m,
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [RFC 08/22] xen/arm: p2m: Invalidate the TLBs when write unlocking the p2m

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> Sometimes the invalidation of the TLBs can be deferred until the p2m is
> unlocked. This is for instance the case when multiple mappings are
> removed. In other case, such as shattering a superpage, an immediate
> flush is required.
> 
> Keep track whether a flush is needed directly in the p2m_domain structure
> to allow serializing multiple changes. The TLBs will be invalidated when
> write unlocking the p2m if necessary.
> 
> Also a new helper, p2m_flush_sync, has been introduced to force a
> synchronous TLB invalidation.
> 
> Finally, replace the call to p2m_flush_tlb by p2m_flush_tlb_sync in
> apply_p2m_changes.
> 
> Note this patch is not useful today, however follow-up patches will make
> advantage of it.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/p2m.c| 33 -
>  xen/include/asm-arm/p2m.h | 11 +++
>  2 files changed, 43 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 6b29cf0..a6dce0c 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -52,8 +52,21 @@ static inline void p2m_write_lock(struct p2m_domain *p2m)
>  write_lock(>lock);
>  }
>  
> +static void p2m_flush_tlb(struct p2m_domain *p2m);
> +
>  static inline void p2m_write_unlock(struct p2m_domain *p2m)
>  {
> +if ( p2m->need_flush )
> +{
> +p2m->need_flush = false;
> +/*
> + * The final flush is done with the P2M write lock taken to
> + * to avoid someone else modify the P2M before the TLB
> + * invalidation has completed.
> + */
> +p2m_flush_tlb(p2m);
> +}
> +
>  write_unlock(>lock);
>  }
>  
> @@ -72,6 +85,11 @@ static inline int p2m_is_locked(struct p2m_domain *p2m)
>  return rw_is_locked(>lock);
>  }
>  
> +static inline int p2m_is_write_locked(struct p2m_domain *p2m)
> +{
> +return rw_is_write_locked(>lock);
> +}
> +
>  void p2m_dump_info(struct domain *d)
>  {
>  struct p2m_domain *p2m = >arch.p2m;
> @@ -165,6 +183,19 @@ static void p2m_flush_tlb(struct p2m_domain *p2m)
>  }
>  
>  /*
> + * Force a synchronous P2M TLB flush.
> + *
> + * Must be called with the p2m lock held.
> + */
> +static void p2m_flush_tlb_sync(struct p2m_domain *p2m)
> +{
> +ASSERT(p2m_is_write_locked(p2m));
> +
> +p2m_flush_tlb(p2m);
> +p2m->need_flush = false;
> +}
> +
> +/*
>   * Lookup the MFN corresponding to a domain's GFN.
>   *
>   * There are no processor functions to do a stage 2 only lookup therefore we
> @@ -1142,7 +1173,7 @@ static int apply_p2m_changes(struct domain *d,
>  out:
>  if ( flush )
>  {
> -p2m_flush_tlb(>arch.p2m);
> +p2m_flush_tlb_sync(>arch.p2m);
>  ret = iommu_iotlb_flush(d, gfn_x(sgfn), nr);
>  if ( !rc )
>  rc = ret;
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 03bfd5e..e6be3ea 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -51,6 +51,17 @@ struct p2m_domain {
>  /* Indicate if it is required to clean the cache when writing an entry */
>  bool_t clean_pte;
>  
> +/*
> + * P2M updates may required TLBs to be flushed (invalidated).
> + *
> + * Flushes may be deferred by setting 'need_flush' and then flushing
> + * when the p2m write lock is released.
> + *
> + * If an immediate flush is required (e.g, if a super page is
> + * shattered), call p2m_tlb_flush_sync().
> + */
> +bool need_flush;
> +
>  /* Gather some statistics for information purposes only */
>  struct {
>  /* Number of mappings at each p2m tree level */
> -- 
> 1.9.1
> 

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

[Xen-devel] [xen-unstable test] 100585: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail REGR. vs. 100578
 build-amd64-rumpuserxen   6 xen-buildfail  like 100578
 build-i386-rumpuserxen6 xen-buildfail  like 100578
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100578
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100578
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100578
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100578
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100578

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

version targeted for testing:
 xen  94d3b9990bf73459919fb5b234d088d1ac41c9da
baseline version:
 xen  2a99aa99fc84a45f505f84802af56b006d14c52e

Last test of basis   100578  2016-08-22 01:59:55 Z0 days
Testing same since   100585  2016-08-22 15:44:37 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Wei Liu 

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

Re: [Xen-devel] [RFC 07/22] xen/arm: p2m: Rework p2m_put_l3_page

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> Modify the prototype to directly pass the mfn and the type in
> parameters. This will be useful later when we do not have the entry in
> hand.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/p2m.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index aecdd1e..6b29cf0 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -584,10 +584,8 @@ enum p2m_operation {
>   * TODO: Handle superpages, for now we only take special references for leaf
>   * pages (specifically foreign ones, which can't be super mapped today).
>   */
> -static void p2m_put_l3_page(const lpae_t pte)
> +static void p2m_put_l3_page(mfn_t mfn, p2m_type_t type)
>  {
> -ASSERT(p2m_valid(pte));
> -
>  /*
>   * TODO: Handle other p2m types
>   *
> @@ -595,12 +593,10 @@ static void p2m_put_l3_page(const lpae_t pte)
>   * flush the TLBs if the page is reallocated before the end of
>   * this loop.
>   */
> -if ( p2m_is_foreign(pte.p2m.type) )
> +if ( p2m_is_foreign(type) )
>  {
> -unsigned long mfn = pte.p2m.base;
> -
> -ASSERT(mfn_valid(mfn));
> -put_page(mfn_to_page(mfn));
> +ASSERT(mfn_valid(mfn_x(mfn)));
> +put_page(mfn_to_page(mfn_x(mfn)));
>  }
>  }
>  
> @@ -734,7 +730,8 @@ static int apply_one_level(struct domain *d,
>   */
>  BUG_ON(level < 3 && p2m_table(orig_pte));
>  if ( level == 3 )
> -p2m_put_l3_page(orig_pte);
> +p2m_put_l3_page(_mfn(orig_pte.p2m.base),
> +orig_pte.p2m.type);
>  }
>  else /* New mapping */
>  p2m->stats.mappings[level]++;
> @@ -834,7 +831,7 @@ static int apply_one_level(struct domain *d,
>  p2m->stats.mappings[level]--;
>  
>  if ( level == 3 )
> -p2m_put_l3_page(orig_pte);
> +p2m_put_l3_page(_mfn(orig_pte.p2m.base), orig_pte.p2m.type);
>  
>  /*
>   * This is still a single pte write, no matter the level, so no need 
> to
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [RFC 06/22] xen/arm: traps: Check the P2M before injecting a data/instruction abort

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> A data/instruction abort may have occurred if another CPU was playing
> with the stage-2 page table when following the break-before-make
> sequence (see D4.7.1 in ARM DDI 0487A.j). Rather than injecting directly
> the fault to the guest, we need to check whether the mapping exists. If
> it exists, return to the guest to replay the instruction.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/traps.c | 40 ++--
>  1 file changed, 38 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index b46284c..da56cc0 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2404,6 +2404,7 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  register_t gva = READ_SYSREG(FAR_EL2);
>  uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
>  paddr_t gpa;
> +mfn_t mfn;
>  
>  if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
>  gpa = get_faulting_ipa(gva);
> @@ -2417,6 +2418,11 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>   */
>  flush_tlb_local();
>  
> +/*
> + * We may not be able to translate because someone is
> + * playing with the Stage-2 page table of the domain.
> + * Return to the guest.
> + */
>  rc = gva_to_ipa(gva, , GV2M_READ);
>  if ( rc == -EFAULT )
>  return; /* Try again */
> @@ -2437,8 +2443,17 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>  /* Trap was triggered by mem_access, work here is done */
>  if ( !rc )
>  return;
> +break;
>  }
> -break;
> +case FSC_FLT_TRANS:

Please add brackets under the case statement for code style


> +/*
> + * The PT walk may have failed because someone was playing
> + * with the Stage-2 page table. Walk the Stage-2 PT to check
> + * if the entry exists. If it's the case, return to the guest
> + */
> +mfn = p2m_lookup(current->domain, _gfn(paddr_to_pfn(gpa)), NULL);
> +if ( !mfn_eq(mfn, INVALID_MFN) )
> +return;

Just checking, but isn't it possible to get a genuine translation abort
with an mfn != invalid_mfn?


>  }
>  
>  inject_iabt_exception(regs, gva, hsr.len);
> @@ -2455,7 +2470,7 @@ static bool_t try_handle_mmio(struct cpu_user_regs 
> *regs,
>  return 0;
>  
>  /* All the instructions used on emulated MMIO region should be valid */
> -if ( !dabt.valid )
> +if ( !info->dabt.valid )
>  return 0;

Spurious change?


>  /*
> @@ -2483,6 +2498,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  int rc;
>  mmio_info_t info;
>  uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;
> +mfn_t mfn;
>  
>  info.dabt = dabt;
>  #ifdef CONFIG_ARM_32
> @@ -2496,6 +2512,11 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  else
>  {
>  rc = gva_to_ipa(info.gva, , GV2M_READ);
> +/*
> + * We may not be able to translate because someone is
> + * playing with the Stage-2 page table of the domain.
> + * Return to the guest.
> + */
>  if ( rc == -EFAULT )
>  return; /* Try again */
>  }
> @@ -2519,11 +2540,26 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>  break;
>  }
>  case FSC_FLT_TRANS:
> +/*
> + * Attempt first to emulate the MMIO has the data abort will
^ as

> + * likely happen an emulated region.
   ^ on/in

> + */
>  if ( try_handle_mmio(regs, ) )
>  {
>  advance_pc(regs, hsr);
>  return;
>  }
> +
> +/*
> + * The PT walk may have failed because someone was playing
> + * with the Stage-2 page table. Walk the Stage-2 PT to check
> + * if the entry exists. If it's the case, return to the guest
> + */
> +mfn = p2m_lookup(current->domain, _gfn(paddr_to_pfn(info.gpa)), 
> NULL);
> +if ( !mfn_eq(mfn, INVALID_MFN) )
> +return;
> +
> +break;
>  default:
>  gprintk(XENLOG_WARNING, "Unsupported DFSC: HSR=%#x DFSC=%#x\n",
>  hsr.bits, dabt.dfsc);
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCHv3 0/2] libfs, xenfs: replace /proc/xen/xenbus with a symlink

[Doug Goldstein]

On 6/28/16 2:06 PM, David Vrabel wrote:
> Using /proc/xen/xenbus can cause deadlocks on the atomic file position
> mutex since this file should behave like a character device and not a
> regular file.  This is easiest to achive by making it a symlink to the
> existing /dev/xen/xenbus device.
> 
> This requires extending simple_fill_super() to add symlinks as well as
> regular files.
> 
> Changes in v3:
> - Rebased on v4.7-rc5.
> 
> David

Just a bit of a nudge to see where the status of this is at? We're at
the point of potentially having yet another kernel release go out the
door where the default behavior with Xen 4.6 and earlier is to deadlock
domUs.

-- 
Doug Goldstein



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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

On August 22, 2016 11:12 PM,  wrote:
 On 22.08.16 at 16:02,  wrote:
>> On August 22, 2016 8:04 PM,  wrote:
>> On 22.08.16 at 13:41,  wrote:
 On August 22, 2016 6:36 PM,  wrote:
 On 19.08.16 at 14:58,  wrote:
>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17
>00:00:00
>> 2001
>> From: Quan Xu 
>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv
>> issue
>>
>> When Xen apicv is enabled, wall clock time is faster on
>> Windows7-32 guest with high payload (with 2vCPU, captured from
>> xentrace, in high payload, the count of IPI interrupt increases rapidly
>between these vCPUs).
>>
>> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
>> 0xd1) are both pending (index of bit set in VIRR), unfortunately,
>> the IPI intrrupt is high priority than periodic timer interrupt.
>> Xen updates IPI interrupt bit set in VIRR to guest interrupt
>> status
>> (RVI) as a high priority and apicv (Virtual-Interrupt Delivery)
>> delivers IPI interrupt within VMX non-root operation without a VM
>> exit. Within VMX non-root operation, if periodic timer interrupt
>> index of bit is set in VIRR and highest, the apicv delivers
>> periodic timer
>>>interrupt within VMX non-root operation as well.
>>
>> But in current code, if Xen doesn't update periodic timer
>> interrupt bit set in VIRR to guest interrupt status (RVI)
>> directly, Xen is not aware of this case to decrease the count
>> (pending_intr_nr) of pending periodic timer interrupt, then Xen
>> will deliver a periodic timer interrupt again. The guest receives
>> more periodic timer interrupt.
>>
>> If the periodic timer interrut is delivered and not the highest
>> priority, make Xen be aware of this case to decrease the count of
>> pending periodic timer interrupt.
>
>I can see the issue you're trying to address, but for one - doesn't
>this lead to other double accounting, namely once the pt irq becomes
>the highest priority one?
>

 It is does NOT lead to other double accounting..
 As if the pt irq becomes the highest priority one, the intack is pt one..
 Then:

  +else
  +pt_intr_post(v, intack);
>>>
>>>As just said in reply to Yang: If this is still the same interrupt
>>>instance
>> as in a
>>>prior run through here which took the if() branch, this change looks
>>>like
>> having
>>>the potential of double accounting.
>>>
>>
>> I very appreciate your detail review. It looks like, but actually it
>> doesn't happen.
>>
>>  As the key parameter 'pt->irq_issued'..
>>
>> In pt_update_irq(), once the PT irq is issued, set the pt->irq_issued..
>> In pt_intr_post(), clear the pt->irq_issued before touching the count
>> 'pt->pending_intr_nr'..
>>
>> According to your assumption, at the second call to pt_intr_post(), As
>> if 'pt->irq_issued' is clear, pt is NULL in is_pt_irq() check, then
>> return, there is no chance to touch the count 'pt->pending_intr_nr'..
>
>Hmm, wait: That second pass would also get us through
>pt_update_irq() a second time, which might cause irq_issued to get set again.
>

 iiuc this case is IRQ combination, issue twice but delivery once..
Another enhancement may be required here,
 IF  hvm_intsrc_lapic && the PT IRQ index bit in VIRR is not clear
THEN don't issue PT IRQ in pt_update_irq()
 FI

>Granted this code is fragile, therefore please excuse that I'm trying to be 
>extra
>careful with accepting changes to it.

Understood :):)...

Quan

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

Re: [Xen-devel] [PATCH 1/2] xen/Kconfig: Drop redundant comments from Kconfig files

[Doug Goldstein]

On 8/19/16 11:54 AM, Andrew Cooper wrote:
> Most of the comments are duplicated from the help text, and those without help
> provide no useful additional input.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Doug Goldstein 
> CC: Jan Beulich 
> CC: Stefano Stabellini 
> CC: Julien Grall 

Reviewed-by: Doug Goldstein 


-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v1 7/7] tools: add userspace linker table sandbox

[Luis R. Rodriguez]

On Fri, Aug 19, 2016 at 03:31:47PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:41 PM,   wrote:
> > From: "Luis R. Rodriguez" 
> >
> > Add a userspace sandbox to allow easy experimentation and
> > test extensions with linker tables, section ranges and the
> > new section core definitions.
> >
> > The userspace sandbox tries to mimic the Linux kernel development
> > flow as much as possible, it however relies on and uses libc. Support
> > is currently only provided to x86_64.
> >
> > v4: this patch is new in this series -- added to the kenrel as
> > suggested by Boris, as otherwise it'd be really hard to keep
> > an external userspace repository in sync.
> >
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> >  Documentation/sections/linker-tables.rst   |   4 +-
> >  MAINTAINERS|   1 +
> >  include/linux/tables.h |   5 +-
> >  tools/Makefile |   3 +-
> >  .../arch/x86/include/generated/asm/section-core.h  |   1 +
> >  tools/arch/x86/include/generated/ranges.h  |   1 +
> >  tools/arch/x86/include/generated/tables.h  |   1 +
> >  tools/include/asm-generic/ranges.h | 103 
> >  tools/include/asm-generic/section-core.h   | 341 +++
> >  tools/include/asm-generic/tables.h |  50 ++
> 
> Aren't a bunch of these files exact duplicates of the headers in 
> include/linux?

Indeed... This a userspace tools/ architecture decision that was made long ago,
so its not up to me, I am just following the strategy devised and picked up.
Refer to 7d7d1bf1d1dabe435ef50efb051724b8664749cb ("perf bench: Copy kernel
files needed to build mem{cpy,set} x86_64 benchmarks") for an example of
previous similar work. By sharing header files this enable more tools/
to be hacked on.

  Luis

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

Re: [Xen-devel] [PATCH v4 08/16] kbuild: enable option to force compile force-obj-y and force-lib-y

[Luis R. Rodriguez]

On Fri, Aug 19, 2016 at 03:10:33PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> > diff --git a/init/Kconfig b/init/Kconfig
> > index cac3f096050d..ef09e83b9196 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -53,6 +53,28 @@ config CROSS_COMPILE
> >   need to set this unless you want the configured kernel build
> >   directory to select the cross-compiler automatically.
> >
> > +config BUILD_AVOID_BITROT
> > +   bool "Enable force building of force-obj-y and force-lib-y"
> 
> Sorry to continue the bikeshedding on this, but if I encounter
> something in a Makefile named "force-obj-y" I would expect it to
> always be built, no matter what. But this is not the case: the
> "force-" prefix is tied to this CONFIG_BUILD_AVOID_BITROT. This verb
> usage is weird, as I'd expect an adjective, like "forceable-obj-y" or
> something that describes that it CAN be built even with the CONFIG for
> it is missing, etc.
> 
> Regardless, I defer to Michal on this, but I'm not a fan of "force"
> being used when it's an optional action. :)

Sure, Michal let me know if forceable-obj-y and forceable-lib-y is the
way to go.

  Luis

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

Re: [Xen-devel] [PATCH v4 07/16] tables.h: add linker table support

[Luis R. Rodriguez]

On Fri, Aug 19, 2016 at 03:02:07PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> > diff --git a/arch/c6x/include/asm/tables.h b/arch/c6x/include/asm/tables.h
> > new file mode 100644
> > index ..09a9e31c573a
> > --- /dev/null
> > +++ b/arch/c6x/include/asm/tables.h
> > @@ -0,0 +1,26 @@
> > +#ifndef _ASM_C6X_ASM_TABLES_H
> > +#define _ASM_C6X_ASM_TABLES_H
> > +/*
> > + * Copyright (C) 2016 Luis R. Rodriguez 
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of copyleft-next (version 0.3.1 or later) as published
> > + * at http://copyleft-next.org/.
> > + */
> > +
> > +/*
> > + * The c6x toolchain has a bug present even on gcc-6 when non-weak 
> > attributes
> > + * are used and sends them to .rodata even though const data with weak
> > + * attributes are put in .const, this forces the linker to believe the 
> > address
> > + * is relative relative to the a base + offset and you end up with 
> > SB-relative
> > + * reloc error upon linking. Work around this by by forcing both start and
> > + * ending const RO waek linker table entry to be .const to fix this for 
> > now.
> 
> Type: waek -> weak

Thanks, fixed.

  Luis

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

Re: [Xen-devel] [PATCH v4 06/16] ranges.h: add helpers to build and identify Linux section ranges

[Luis R. Rodriguez]

On Fri, Aug 19, 2016 at 02:55:43PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> > From: "Luis R. Rodriguez" 
> >
> > Section ranges are on one of the types of custom sections
> > types used in Linux. This provides a series of helpers for
> > defining them and using them. Most importantly this also
> > enables us to avoid modifying the linker script when we
> > add a new section range.
> >
> > It turns out a lot of custom sections are actually section ranges,
> > and these are typically spelled out in their architecture specific
> > asm/sections.h file -- we anable architectures to override what asm
> 
> Typo: anable -> enable

Fixed.

> > is used for section ranges but start by default trusting the
> > asm-generic version all around.
> 
> Can you explain the addition of the SORT() stuff in this patch? Its
> purpose isn't clear to me and doesn't appear to be mentioned in the
> commit log.

Indeed, let me explain and I'll also add this to the commit log.
We need to use SORT() in vmlinux.lds.S for section ranges for two
reasons:

a) By using SORT() and using "any" for cases where order does not
   matter we're able to extend section ranges without modifying the
   linker script. The special annotation used for the "order" for
   the first element of a section range is the empty string (see
   __SECTION_RANGE_BEGIN(), the ending element uses the character
   "~", see __SECTION_RANGE_END(). By default anything added in between
   uses the "any" order, when you use SORT() on this you end up stuffing
   all elements with the "any" order in between, and allowing you to have
   a beginning and end reference -- without modifying the linker script.

b) Although explicit order is typically not required for section ranges
   there is one use case brought to my attention we wanted to support
   where order was desired -- to build synthetic functions. An example
   is provided in asm in tools in the last patch where the linker tables
   sandbox is provided. Refer to tools/linker-tables/drivers/synth/or.S

> > diff --git a/include/asm-generic/ranges.h b/include/asm-generic/ranges.h
> > new file mode 100644
> > index ..74cd941aa2f8
> > --- /dev/null
> > +++ b/include/asm-generic/ranges.h
> > @@ -0,0 +1,89 @@
> > +#ifndef _ASM_GENERIC_RANGES_H_
> > +#define _ASM_GENERIC_RANGES_H_
> > +/*
> > + * Copyright (C) 2016 Luis R. Rodriguez 
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of copyleft-next (version 0.3.1 or later) as published
> > + * at http://copyleft-next.org/.
> > + */
> > +#include 
> > +
> > +#define SECTION_RNG(section, name) \
> 
> I would really prefer to avoid shortening "range" to the acronym for
> "random number generator". That's very confusing. :P It's only two
> letters more...

Speaking of, it'd be great if you could trim your reply to the hunks of
interest :) but yes sure, more bike shedding -- I'm happy to go with that
if that is the consensus.

  Luis

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail REGR. vs. 67566

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 67566
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67566
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67566

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

version targeted for testing:
 qemuu62680fad7fd63b1f5cfd049a85993e4b24b03958
baseline version:
 qemuu5f9f818ea88a013b2464563be354dd2f0f316407

Last test of basis67566  2016-08-20 00:18:54 Z2 days
Testing same since67578  2016-08-22 15:46:57 Z0 days1 attempts


People who touched revisions under test:
  Cao jin 
  Dmitry Fleytman 
  Jason Wang 
  Marc-André Lureau 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

[Luis R. Rodriguez]

On Fri, Aug 19, 2016 at 02:47:48PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> > From: "Luis R. Rodriguez" 
> >
> > +SECTION_RODATA
> > +--
> > +.. kernel-doc:: include/asm-generic/section-core.h
> > +   :doc: SECTION_RODATA
> > +
> > +SECTION_RODATA
> 
> Typo: should this be called SECTION_TEXT instead?

Fixed thanks.

> > +--
> > +.. kernel-doc:: include/asm-generic/section-core.h
> > +   :doc: SECTION_TEXT
> > +
> > +SECTION_DATA
> > +
> > +.. kernel-doc:: include/asm-generic/section-core.h
> > +   :doc: SECTION_DATA
> 
> Missing from this list are things like the __read_mostly
> (".data..read_mostly") and __ro_after_init (".data..ro_after_init")
> sections. Should those be included too, or are you only doing the "top
> level" sections?

I'm doing top level right now just to start off and get the
bikeshedding out of the way. We can add more with more time
or as we port more things or as the need arises.

  Luis

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

Re: [Xen-devel] [PATCH v4 00/16] linux: generalize sections, ranges and linker tables

[Luis R. Rodriguez]

On Fri, Aug 19, 2016 at 03:29:24PM -0700, Kees Cook wrote:
> On Fri, Aug 19, 2016 at 2:32 PM,   wrote:
> > From: "Luis R. Rodriguez" 
> >
> > This v4 addresses feedback from the previous v3 series [0], and also
> > addresses a huge array of additional tests against many architectures
> > outside of what 0-day provides. As I mentioned in my last v3 series,
> > 0-day had only found one issue with the series, a blackfin architecture
> > linker issue with the last series. Guenter Rock was kind enough to give
> > my series a test spin on his test bed and he found quite a bit of other
> > oddball issues with obscure architectures, and even on x86 with an old
> > toolchain. After a lot of work and coordinating with a few maintainers
> > I'm happy to report all issues found so far through all possible testing
> > I could do are now fixed, this series also addresses all feedback from
> > the last series, as such this goes submitted as PATCH form.
> >
> > In addressing fixing this work on a few architectures some of the previous
> > patches are further simplified. The kprobes port to linker tables is made
> > much easier now that I've addressed moving out core kprobe declarations
> > into asm-generic/kprobes.h. Refer to the patch "kprobes: move kprobe
> > declarations to asm-generic/kprobes.h". This makes for a much cleaner
> > solution across architectures.
> >
> > Boris feedback on making the code bit rot feature optional is addressed
> > by using a new Kconfig symbol for this, CONFIG_BUILD_AVOID_BITROT,
> > but given Greg's concerns over lack of clarity over what this was all about
> > I've ripped that functionality out into its own patch with a bit more
> > extensive documentation and re-wording. See the patch "kbuild: enable option
> > to force compile force-obj-y and force-lib-y". I hope makes it clear how
> > linker tables can help with avoiding code bit rot. I've gone with a new
> > Kconfig symbol CONFIG_BUILD_AVOID_BITROT given CONFIG_COMPILE_TEST is
> > not available on UML, this feature is desirable on all architectures.
> >
> > The documentation is revamped, now that the DocBook format is deprecated
> > I ported the documention into the trendy hipster Sphinx documentation
> > format.
> >
> > AT Boris' request I've adapated the userspace linker table application
> > forintegration into the kernel under tools/ to make it easier to keep
> > things in sync, however since this requires a bit of changes to some headers
> > in tools/ I'll submit that separately.
> >
> > [0] 
> > https://lkml.kernel.org/r/1469222687-1600-1-git-send-email-mcg...@kernel.org
> >
> > If you'd like this in git-form, you can get it on the 
> > 20160819-linker-table-v4
> > branch of my linux-next tree on kernel.org, this also includes the series of
> > the linker table userspace sandbox:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160819-linker-table-v4
> >
> > Please let me know if there are any concerns or questions.
> 
> Thanks for the documentation and examples on this feature; I appreciate it! :)
> 
> While it seems like all the section declarations work in this series
> is designed for assembler source, I'm curious if I've missed a way to
> do this in .c source too.

Actually, the whole point to this originally was to provide helpers to
only do this in .c source code -- the fact that there are a few asm helpers
now is an after thought to provide parity of functionality to asm code to do
the exact same thing. The same macros provide the same functionality in
both C and asm code then and if there is some functionality lacking it may
for now just be on the asm side.

So for instance we have DECLARE_SECTION_RANGE() and that exist for C and
asm, but DECLARE_LINKTABLE() is currently only implemented for C code,
when and if we want it we can add it. DECLARE_SECTION_RANGE() has a demo
use in the userspace linker table sandbox.

> I'd love to avoid doing the crazy thing I'm currently doing in lkdtm 
> with section markings. Namely, I want to write a function in .c and have it
> moved into the .rodata section. The linkers get very very angry with me and I
> don't seem to be able to override the progbits to lose "x". Right now I'm
> doing an objcopy in
> drivers/misc/Makefile:
> 
> OBJCOPYFLAGS_lkdtm_rodata_objcopy.o := \
> --set-section-flags .text=alloc,readonly \
> --rename-section .text=.rodata
> targets += lkdtm_rodata.o lkdtm_rodata_objcopy.o
> $(obj)/lkdtm_rodata_objcopy.o: $(obj)/lkdtm_rodata.o FORCE
> $(call if_changed,objcopy)
> 
> Thanks!

I'd have to take a closer look but from what you describe indeed this is
something that linker tables and section ranges is supposed to help with -- a
generic API to set sections in an architecture-agnostic way.  If you can
classify your functions with section ranges or linker tables then you should be
set. They flags used is whatever the architecture has 

[Xen-devel] [ovmf baseline-only test] 67579: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 72388f9c10126a718a7ac381dc6879d3337ccb8b
baseline version:
 ovmf d36447418d32d82c4d1033ffcf5cb6244031ac9f

Last test of basis67577  2016-08-22 09:48:26 Z0 days
Testing same since67579  2016-08-22 17:23:09 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Hao Wu 
  Liming Gao 
  Vikas C Sajjan 

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



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

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

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


Push not applicable.


commit 72388f9c10126a718a7ac381dc6879d3337ccb8b
Author: Hao Wu 
Date:   Wed Aug 17 21:28:39 2016 +0800

SecurityPkg Tcg2: Remove use of module internal API InternalIsZeroBuffer()

This commit removes the internal implementation of the function
InternalIsZeroBuffer(). Instead, it will use the API IsZeroBuffer() from
BaseMemoryLib in MdePkg.

Cc: Jiewen Yao 
Cc: Chao Zhang 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Chao Zhang 
Reviewed-by: Liming Gao 

commit 102b4c7cdd11172d5b7fde35a0c472ecd7fa49e7
Author: Hao Wu 
Date:   Wed Aug 17 14:27:49 2016 +0800

MdePkg BaseMemoryLibSse2: Add SSE2 implementation of API IsZeroBuffer()

Add the implementation of API IsZeroBuffer() via assembly in
BaseMemoryLibSse2.

The assembly codes use SSE2 XMM registers and related instructions.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Liming Gao 

commit 02b5cf7fb1824e089f19ca03b685a1f196860bf6
Author: Hao Wu 
Date:   Wed Aug 17 14:26:25 2016 +0800

MdePkg BaseMemoryLib: Add assembly implementation of API IsZeroBuffer()

Add the implementation of API IsZeroBuffer() via assembly for the
following library instances:
BaseMemoryLibMmx
BaseMemoryLibOptDxe
BaseMemoryLibOptPei
BaseMemoryLibRepStr

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Liming Gao 

commit 1944b02b03e14d023e8f2cd3d614df6eca9dc8f0
Author: Hao Wu 
Date:   Wed Aug 17 14:24:04 2016 +0800

MdePkg BaseMemoryLib: Add C implementation of API IsZeroBuffer()

Add the implementation of API IsZeroBuffer() via C language for the
following library instances:
BaseMemoryLib
PeiMemoryLib
UefiMemoryLib

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
Reviewed-by: Liming Gao 

commit bce0133b7f0d5583c53fae0e80597568a3c8c411
Author: Hao Wu 
Date:   Wed Aug 17 21:12:57 2016 +0800

SecurityPkg Tcg2: Rename internal API IsZeroBuffer to InternalIsZeroBuffer

Before adding API IsZeroBuffer() in BaseMemoryLib at MdePkg, rename the
internal implementations 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install  fail REGR. vs. 100581

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

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

version targeted for testing:
 qemuud75aa4372f0414c9960534026a562b0302fcff29
baseline version:
 qemuu62680fad7fd63b1f5cfd049a85993e4b24b03958

Last test of basis   100581  2016-08-22 10:14:32 Z0 days
Testing same since   100584  2016-08-22 15:43:34 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 

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

Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

[Konrad Rzeszutek Wilk]

> > > @@ -24,7 +27,9 @@ const char *xen_hello_world(void)
> > >   */
> > >  rc = __get_user(tmp, non_canonical_addr);
> > >  BUG_ON(rc != -EFAULT);
> > > -
> > > +#else
> > > + asm(ALTERNATIVE("nop", "nop", 1));
> > 
> > Why the hardcoded 1 here? I am wondering if we should introduce a new
> > capability "LIVEPATCH_TEST" which is enabled by default. So we can test that
> > the the alternative is working on all the platform. What do you think?
> 
> Sure, but I am not sure what number you would like? Perhaps 42 :-) ?

I am coming back to this and I think it may be better to just piggyback
on the ones that exist.

On x86 it is simple - just pick the most common one. On ARM - I have no clue?

Also having an 'LIVEPATCH_TEST" cpu configuration bit means it can be exposed
via the framework to domctl users. And that seems rather odd.



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

[Xen-devel] [PATCH v05 56/72] include/uapi/xen/evtchn.h: include xen/privcmd.h

[Mikko Rapeli]

It has definition of domid_t. Fixes userspace compiler error when
xen/privcmd.h is compiled alone:

xen/evtchn.h:100:2: error: unknown type name ‘domid_t’
  domid_t domid;
  ^~~

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/evtchn.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/xen/evtchn.h b/include/uapi/xen/evtchn.h
index cb4aa4b..81df4b3 100644
--- a/include/uapi/xen/evtchn.h
+++ b/include/uapi/xen/evtchn.h
@@ -33,6 +33,8 @@
 #ifndef __LINUX_PUBLIC_EVTCHN_H__
 #define __LINUX_PUBLIC_EVTCHN_H__
 
+#include 
+
 /*
  * Bind a fresh port to VIRQ @virq.
  * Return allocated port.
-- 
2.8.1


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

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

[Konrad Rzeszutek Wilk]

> > > -/* On ARM32,64 instructions are always 4 bytes long. */
> > > -#define PATCH_INSN_SIZE 4
> > 
> > Rather than moving again PATCH_INSN_SIZE in this patch. Can you directly
> > move it in patch [1]?
> 
> Sure.

The patch [1] changed where it does not have  anymore. And because
of that (and some other changes) this patch is the one that introduces
the #define. So I think having it in include/asm-arm/livepatch.h would
work. When I send out the patchset that hopefully should be more clarified.
..
> > [1]
> > https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg01832.html
> > 
> > -- 
> > Julien Grall

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

[Xen-devel] [PATCH v05 54/72] include/uapi/xen/privcmd.h: fix compilation in userspace

[Mikko Rapeli]

xen/interface/xen.h is not exported from kernel headers so remove the
dependency and provide needed defines for domid_t and xen_pfn_t if they
are not already defined by some other e.g. Xen specific headers.

Suggested by Andrew Cooper  on lkml message
<5569f9c9.8000...@citrix.com>.

The ifdef for ARM is ugly but did not find better solutions for it.

Fixes userspace compilation error:

xen/privcmd.h:38:31: fatal error: xen/interface/xen.h: No such file or directory

Signed-off-by: Mikko Rapeli 
Cc: David Vrabel 
---
 arch/arm/include/asm/xen/interface.h |  2 +-
 include/uapi/xen/privcmd.h   | 12 +++-
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/xen/interface.h 
b/arch/arm/include/asm/xen/interface.h
index 75d5968..6898ee1 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -38,7 +38,7 @@
  * fine since it simply wouldn't be able to create any sure pfns in
  * the first place.
  */
-typedef uint64_t xen_pfn_t;
+typedef __u64 xen_pfn_t;
 #define PRI_xen_pfn "llx"
 typedef uint64_t xen_ulong_t;
 #define PRI_xen_ulong "llx"
diff --git a/include/uapi/xen/privcmd.h b/include/uapi/xen/privcmd.h
index 7ddeeda..16c11f9 100644
--- a/include/uapi/xen/privcmd.h
+++ b/include/uapi/xen/privcmd.h
@@ -35,7 +35,17 @@
 
 #include 
 #include 
-#include 
+
+/* Defined by include/xen/interface/xen.h, but it is not part of Linux uapi */
+#ifndef __XEN_PUBLIC_XEN_H__
+typedef __u16 domid_t;
+
+#if (defined __ARMEL__ || defined __ARMEB__)
+typedef __u64 xen_pfn_t;
+#else
+typedef unsigned long xen_pfn_t;
+#endif /* (defined __ARMEL__ || defined __ARMEB__) */
+#endif /* __XEN_PUBLIC_XEN_H__ */
 
 struct privcmd_hypercall {
__u64 op;
-- 
2.8.1


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

Re: [Xen-devel] HVMOP_altp2m_vcpu_enable_notify code example usage

[Dmitry Rockosov]

Tamas,

My experiment is using the same HVMOP - HVMOP_get_param.
Usermode code is using it from
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/hvm/hvm_op.h;hb=2a99aa99fc84a45f505f84802af56b006d14c52e
Kernelmode is using it from
http://lxr.free-electrons.com/source/include/xen/interface/hvm/hvm_op.h?v=3.16#L27

One difference I see, in usermode we are allocating buffer with
DECLARE_HYPERCALL_BUFFER in CPL3 space, in kernelmode it's made in CPL0
space, however privcmd IOCTL handler does copy_from_user call for argument
buffer... I'm very confused, why it happens :-(

Best Regards,
Rockosov Dmitry

2016-08-22 21:54 GMT+03:00 Tamas K Lengyel :

> On Mon, Aug 22, 2016 at 12:42 PM, Dmitry Rockosov 
> wrote:
> > Tamas, what do you think, why the same hypercall operations (get_param)
> are
> > executed by Xen differently? Does Xen know anything about caller domU
> CPL:
> > usermode or kernelmode?
>
> It's not about the guest's CPL - all hypercalls are issued ultimately
> from kernelmode anyway - but depending on which HVMOP the guest issues
> it can get treated differently by Xen. You can follow the path from
> here: https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=
> xen/arch/x86/hvm/hvm.c;h=0180f26b56b75c08c8c53b58a599de
> 6085949bce;hb=HEAD#l5510.
> I'm not sure which HVMOPs are allowed by default to be executed by the
> guest itself.
>
> Tamas
>
> >
> > Thank you for answers!
> >
> > Best Regards,
> > Rockosov Dmitry
> >
> > 2016-08-22 21:28 GMT+03:00 Tamas K Lengyel :
> >>
> >> On Mon, Aug 22, 2016 at 12:12 PM, Dmitry Rockosov 
> >> wrote:
> >> > The problem is in hypervisor checking definitely. I deeper debugged
> the
> >> > code, I met vmcall instruction execution. This means EFAULT is coming
> >> > from
> >> > hypervisor.
> >>
> >> As it should, question is where exactly it gets denied in Xen.
> >>
> >> >
> >> > Best Regards,
> >> > Rockosov Dmitry
> >> >
> >> > 2016-08-22 18:09 GMT+03:00 Dmitry Rockosov :
> >> >>
> >> >> Hello Tamas,
> >> >>
> >> >> Thank you for the answer!
> >> >>
> >> >> I installed the same xen source code (4.7.0) as on dom0 to domU,
> built
> >> >> dist-tools, installed xen-tools, updated rc.d configuration and
> >> >> rebooted.
> >> >> IOCTL channel to privcmd driver is working fine, but all requests to
> >> >> hypervisor like hvm_get_param, translate_foreign_address,
> >> >> altp2m_vcpu_enable_notify return EFAULT errno (Bad access).
> >> >>
> >> >> Just for experiment I wrote below code in usermode:
> >> >> ===
> >> >> ...
> >> >> rc = xc_hvm_param_get(xch, DOMID_SELF, HVM_PARAM_CONSOLE_PFN,
> );
> >> >> if (rc < 0) {
> >> >> PERROR("Fail to get CONSOLE PFN HVM PARAM\n");
> >> >> goto exit;
> >> >> }
> >> >> DPRINTF("CONSOLE PFN == %llx", (unsigned long long)value);
> >> >> ...
> >> >> ===
> >> >>
> >> >> and below code in kernelmode:
> >> >> ===
> >> >> ...
> >> >> printk(KERN_INFO "We are in Xen domain HVM = %d\n",
> xen_hvm_domain());
> >> >> err = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, );
> >> >> printk(KERN_INFO "err = %d\n", err);
> >> >> printk(KERN_INFO "CONSOLE PFN = %llx\n", value);
> >> >> ...
> >> >> ===
> >> >>
> >> >> In the usermode I got an error:
> >> >> ===
> >> >> Fail to get CONSOLE PFN HVM PARAM
> >> >> : Bad address
> >> >> ===
> >> >>
> >> >> In the kernelmode code executed fine:
> >> >> ===
> >> >> [23261.230188] We are in Xen domain HVM = 1
> >> >> [23261.307840] err = 0
> >> >> [23261.352587] CONSOLE PFN = fefff
> >> >> ===
> >> >>
> >> >> Looks like usermode wrappers don't support many requests to
> hypervisor,
> >> >> right?
> >>
> >> Not sure about HVMOP_get_param but AFAIK for
> >> HVMOP_altp2m_vcpu_enable_notify to work you would have to create the
> >> domain with altp2mhvm=1 enabled, then also issue the required commands
> >> from dom0 to enable it (xc_altp2m_set_domain_state) and also perhaps
> >> create a couple altp2m views.
> >>
> >> Tamas
> >>
> >> >>
> >> >> Best Regards,
> >> >> Rockosov Dmitry
> >> >>
> >> >> 2016-08-21 20:27 GMT+03:00 Tamas K Lengyel <
> tamas.k.leng...@gmail.com>:
> >> >>>
> >> >>> Hi Dmitry,
> >> >>> as long as you are testing with a HVM Linux guest you should be able
> >> >>> to just compile the Xen tools in the guest and then use libxc from
> >> >>> within the guest to issue that hypercall via
> >> >>> xc_altp2m_set_vcpu_enable_notify. You will need to load a couple
> Xen
> >> >>> related kernel-modules for it to work (like xen-privcmd). Let us
> know
> >> >>> if you got it working!
> >> >>>
> >> >>> Cheers,
> >> >>> Tamas
> >> >>>
> >> >>> On Fri, Aug 19, 2016 at 1:19 PM, Dmitry Rockosov <
> rocko...@gmail.com>
> >> >>> 

[Xen-devel] [PATCH v05 55/72] include/uapi/xen/gntdev.h: include xen/privcmd.h and define grant_ref_t

[Mikko Rapeli]

Both are needed to compile  wihtout compiler warnings
in userspace. Fixes these userspace compile errors:

xen/gntdev.h:151:4: error: unknown type name ‘grant_ref_t’
grant_ref_t ref;
^
xen/gntdev.h:153:4: error: unknown type name ‘domid_t’
domid_t domid;
^

Signed-off-by: Mikko Rapeli 
---
 include/uapi/xen/gntdev.h   | 6 ++
 include/xen/interface/grant_table.h | 6 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
index d066197..f208706 100644
--- a/include/uapi/xen/gntdev.h
+++ b/include/uapi/xen/gntdev.h
@@ -34,6 +34,12 @@
 #define __LINUX_PUBLIC_GNTDEV_H__
 
 #include 
+#include 
+
+/*
+ * Reference to a grant entry in a specified domain's grant table.
+ */
+typedef __u32 grant_ref_t;
 
 struct ioctl_gntdev_grant_ref {
/* The domain ID of the grant to be mapped. */
diff --git a/include/xen/interface/grant_table.h 
b/include/xen/interface/grant_table.h
index 56806bc..7e064d6 100644
--- a/include/xen/interface/grant_table.h
+++ b/include/xen/interface/grant_table.h
@@ -29,6 +29,7 @@
 #define __XEN_PUBLIC_GRANT_TABLE_H__
 
 #include 
+#include  /* for grant_ref_t */
 
 /***
  * GRANT TABLE REPRESENTATION
@@ -85,11 +86,6 @@
  */
 
 /*
- * Reference to a grant entry in a specified domain's grant table.
- */
-typedef uint32_t grant_ref_t;
-
-/*
  * A grant table comprises a packed array of grant entries in one or more
  * page frames shared between Xen and a guest.
  * [XEN]: This field is written by Xen and read by the sharing guest.
-- 
2.8.1


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

Re: [Xen-devel] HVMOP_altp2m_vcpu_enable_notify code example usage

[Tamas K Lengyel]

On Mon, Aug 22, 2016 at 12:42 PM, Dmitry Rockosov  wrote:
> Tamas, what do you think, why the same hypercall operations (get_param) are
> executed by Xen differently? Does Xen know anything about caller domU CPL:
> usermode or kernelmode?

It's not about the guest's CPL - all hypercalls are issued ultimately
from kernelmode anyway - but depending on which HVMOP the guest issues
it can get treated differently by Xen. You can follow the path from
here: 
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;h=0180f26b56b75c08c8c53b58a599de6085949bce;hb=HEAD#l5510.
I'm not sure which HVMOPs are allowed by default to be executed by the
guest itself.

Tamas

>
> Thank you for answers!
>
> Best Regards,
> Rockosov Dmitry
>
> 2016-08-22 21:28 GMT+03:00 Tamas K Lengyel :
>>
>> On Mon, Aug 22, 2016 at 12:12 PM, Dmitry Rockosov 
>> wrote:
>> > The problem is in hypervisor checking definitely. I deeper debugged the
>> > code, I met vmcall instruction execution. This means EFAULT is coming
>> > from
>> > hypervisor.
>>
>> As it should, question is where exactly it gets denied in Xen.
>>
>> >
>> > Best Regards,
>> > Rockosov Dmitry
>> >
>> > 2016-08-22 18:09 GMT+03:00 Dmitry Rockosov :
>> >>
>> >> Hello Tamas,
>> >>
>> >> Thank you for the answer!
>> >>
>> >> I installed the same xen source code (4.7.0) as on dom0 to domU, built
>> >> dist-tools, installed xen-tools, updated rc.d configuration and
>> >> rebooted.
>> >> IOCTL channel to privcmd driver is working fine, but all requests to
>> >> hypervisor like hvm_get_param, translate_foreign_address,
>> >> altp2m_vcpu_enable_notify return EFAULT errno (Bad access).
>> >>
>> >> Just for experiment I wrote below code in usermode:
>> >> ===
>> >> ...
>> >> rc = xc_hvm_param_get(xch, DOMID_SELF, HVM_PARAM_CONSOLE_PFN, );
>> >> if (rc < 0) {
>> >> PERROR("Fail to get CONSOLE PFN HVM PARAM\n");
>> >> goto exit;
>> >> }
>> >> DPRINTF("CONSOLE PFN == %llx", (unsigned long long)value);
>> >> ...
>> >> ===
>> >>
>> >> and below code in kernelmode:
>> >> ===
>> >> ...
>> >> printk(KERN_INFO "We are in Xen domain HVM = %d\n", xen_hvm_domain());
>> >> err = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, );
>> >> printk(KERN_INFO "err = %d\n", err);
>> >> printk(KERN_INFO "CONSOLE PFN = %llx\n", value);
>> >> ...
>> >> ===
>> >>
>> >> In the usermode I got an error:
>> >> ===
>> >> Fail to get CONSOLE PFN HVM PARAM
>> >> : Bad address
>> >> ===
>> >>
>> >> In the kernelmode code executed fine:
>> >> ===
>> >> [23261.230188] We are in Xen domain HVM = 1
>> >> [23261.307840] err = 0
>> >> [23261.352587] CONSOLE PFN = fefff
>> >> ===
>> >>
>> >> Looks like usermode wrappers don't support many requests to hypervisor,
>> >> right?
>>
>> Not sure about HVMOP_get_param but AFAIK for
>> HVMOP_altp2m_vcpu_enable_notify to work you would have to create the
>> domain with altp2mhvm=1 enabled, then also issue the required commands
>> from dom0 to enable it (xc_altp2m_set_domain_state) and also perhaps
>> create a couple altp2m views.
>>
>> Tamas
>>
>> >>
>> >> Best Regards,
>> >> Rockosov Dmitry
>> >>
>> >> 2016-08-21 20:27 GMT+03:00 Tamas K Lengyel :
>> >>>
>> >>> Hi Dmitry,
>> >>> as long as you are testing with a HVM Linux guest you should be able
>> >>> to just compile the Xen tools in the guest and then use libxc from
>> >>> within the guest to issue that hypercall via
>> >>> xc_altp2m_set_vcpu_enable_notify. You will need to load a couple Xen
>> >>> related kernel-modules for it to work (like xen-privcmd). Let us know
>> >>> if you got it working!
>> >>>
>> >>> Cheers,
>> >>> Tamas
>> >>>
>> >>> On Fri, Aug 19, 2016 at 1:19 PM, Dmitry Rockosov 
>> >>> wrote:
>> >>> > Hello Xen Team!
>> >>> >
>> >>> > Does anybody have any code examples of
>> >>> > HVMOP_altp2m_vcpu_enable_notify?
>> >>> >
>> >>> > I want to fully test #VE, VMFUNC and EPTP Switching VM Function 0 in
>> >>> > Xen,
>> >>> > but doesn't have any documentations/examples for it.
>> >>> > I tried xen-access test from tools/tests/xen-access, but looks like
>> >>> > it
>> >>> > doesn't use VMFUNC and #VE, it simply changes VMCS entries with
>> >>> > vmwrite, w/o
>> >>> > VMFUNC 0 (EPTP Switching).
>> >>> >
>> >>> > Thanks in advance!
>> >>> >
>> >>> > Best Regards,
>> >>> > Rockosov Dmitry
>> >>> >
>> >>> > ___
>> >>> > Xen-devel mailing list
>> >>> > Xen-devel@lists.xen.org
>> >>> > https://lists.xen.org/xen-devel
>> >>> >
>> >>
>> >>
>> >
>
>

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

Re: [Xen-devel] HVMOP_altp2m_vcpu_enable_notify code example usage

[Dmitry Rockosov]

Tamas, what do you think, why the same hypercall operations (get_param) are
executed by Xen differently? Does Xen know anything about caller domU CPL:
usermode or kernelmode?

Thank you for answers!

Best Regards,
Rockosov Dmitry

2016-08-22 21:28 GMT+03:00 Tamas K Lengyel :

> On Mon, Aug 22, 2016 at 12:12 PM, Dmitry Rockosov 
> wrote:
> > The problem is in hypervisor checking definitely. I deeper debugged the
> > code, I met vmcall instruction execution. This means EFAULT is coming
> from
> > hypervisor.
>
> As it should, question is where exactly it gets denied in Xen.
>
> >
> > Best Regards,
> > Rockosov Dmitry
> >
> > 2016-08-22 18:09 GMT+03:00 Dmitry Rockosov :
> >>
> >> Hello Tamas,
> >>
> >> Thank you for the answer!
> >>
> >> I installed the same xen source code (4.7.0) as on dom0 to domU, built
> >> dist-tools, installed xen-tools, updated rc.d configuration and
> rebooted.
> >> IOCTL channel to privcmd driver is working fine, but all requests to
> >> hypervisor like hvm_get_param, translate_foreign_address,
> >> altp2m_vcpu_enable_notify return EFAULT errno (Bad access).
> >>
> >> Just for experiment I wrote below code in usermode:
> >> ===
> >> ...
> >> rc = xc_hvm_param_get(xch, DOMID_SELF, HVM_PARAM_CONSOLE_PFN, );
> >> if (rc < 0) {
> >> PERROR("Fail to get CONSOLE PFN HVM PARAM\n");
> >> goto exit;
> >> }
> >> DPRINTF("CONSOLE PFN == %llx", (unsigned long long)value);
> >> ...
> >> ===
> >>
> >> and below code in kernelmode:
> >> ===
> >> ...
> >> printk(KERN_INFO "We are in Xen domain HVM = %d\n", xen_hvm_domain());
> >> err = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, );
> >> printk(KERN_INFO "err = %d\n", err);
> >> printk(KERN_INFO "CONSOLE PFN = %llx\n", value);
> >> ...
> >> ===
> >>
> >> In the usermode I got an error:
> >> ===
> >> Fail to get CONSOLE PFN HVM PARAM
> >> : Bad address
> >> ===
> >>
> >> In the kernelmode code executed fine:
> >> ===
> >> [23261.230188] We are in Xen domain HVM = 1
> >> [23261.307840] err = 0
> >> [23261.352587] CONSOLE PFN = fefff
> >> ===
> >>
> >> Looks like usermode wrappers don't support many requests to hypervisor,
> >> right?
>
> Not sure about HVMOP_get_param but AFAIK for
> HVMOP_altp2m_vcpu_enable_notify to work you would have to create the
> domain with altp2mhvm=1 enabled, then also issue the required commands
> from dom0 to enable it (xc_altp2m_set_domain_state) and also perhaps
> create a couple altp2m views.
>
> Tamas
>
> >>
> >> Best Regards,
> >> Rockosov Dmitry
> >>
> >> 2016-08-21 20:27 GMT+03:00 Tamas K Lengyel :
> >>>
> >>> Hi Dmitry,
> >>> as long as you are testing with a HVM Linux guest you should be able
> >>> to just compile the Xen tools in the guest and then use libxc from
> >>> within the guest to issue that hypercall via
> >>> xc_altp2m_set_vcpu_enable_notify. You will need to load a couple Xen
> >>> related kernel-modules for it to work (like xen-privcmd). Let us know
> >>> if you got it working!
> >>>
> >>> Cheers,
> >>> Tamas
> >>>
> >>> On Fri, Aug 19, 2016 at 1:19 PM, Dmitry Rockosov 
> >>> wrote:
> >>> > Hello Xen Team!
> >>> >
> >>> > Does anybody have any code examples of HVMOP_altp2m_vcpu_enable_
> notify?
> >>> >
> >>> > I want to fully test #VE, VMFUNC and EPTP Switching VM Function 0 in
> >>> > Xen,
> >>> > but doesn't have any documentations/examples for it.
> >>> > I tried xen-access test from tools/tests/xen-access, but looks like
> it
> >>> > doesn't use VMFUNC and #VE, it simply changes VMCS entries with
> >>> > vmwrite, w/o
> >>> > VMFUNC 0 (EPTP Switching).
> >>> >
> >>> > Thanks in advance!
> >>> >
> >>> > Best Regards,
> >>> > Rockosov Dmitry
> >>> >
> >>> > ___
> >>> > Xen-devel mailing list
> >>> > Xen-devel@lists.xen.org
> >>> > https://lists.xen.org/xen-devel
> >>> >
> >>
> >>
> >
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] HVMOP_altp2m_vcpu_enable_notify code example usage

[Tamas K Lengyel]

On Mon, Aug 22, 2016 at 12:12 PM, Dmitry Rockosov  wrote:
> The problem is in hypervisor checking definitely. I deeper debugged the
> code, I met vmcall instruction execution. This means EFAULT is coming from
> hypervisor.

As it should, question is where exactly it gets denied in Xen.

>
> Best Regards,
> Rockosov Dmitry
>
> 2016-08-22 18:09 GMT+03:00 Dmitry Rockosov :
>>
>> Hello Tamas,
>>
>> Thank you for the answer!
>>
>> I installed the same xen source code (4.7.0) as on dom0 to domU, built
>> dist-tools, installed xen-tools, updated rc.d configuration and rebooted.
>> IOCTL channel to privcmd driver is working fine, but all requests to
>> hypervisor like hvm_get_param, translate_foreign_address,
>> altp2m_vcpu_enable_notify return EFAULT errno (Bad access).
>>
>> Just for experiment I wrote below code in usermode:
>> ===
>> ...
>> rc = xc_hvm_param_get(xch, DOMID_SELF, HVM_PARAM_CONSOLE_PFN, );
>> if (rc < 0) {
>> PERROR("Fail to get CONSOLE PFN HVM PARAM\n");
>> goto exit;
>> }
>> DPRINTF("CONSOLE PFN == %llx", (unsigned long long)value);
>> ...
>> ===
>>
>> and below code in kernelmode:
>> ===
>> ...
>> printk(KERN_INFO "We are in Xen domain HVM = %d\n", xen_hvm_domain());
>> err = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, );
>> printk(KERN_INFO "err = %d\n", err);
>> printk(KERN_INFO "CONSOLE PFN = %llx\n", value);
>> ...
>> ===
>>
>> In the usermode I got an error:
>> ===
>> Fail to get CONSOLE PFN HVM PARAM
>> : Bad address
>> ===
>>
>> In the kernelmode code executed fine:
>> ===
>> [23261.230188] We are in Xen domain HVM = 1
>> [23261.307840] err = 0
>> [23261.352587] CONSOLE PFN = fefff
>> ===
>>
>> Looks like usermode wrappers don't support many requests to hypervisor,
>> right?

Not sure about HVMOP_get_param but AFAIK for
HVMOP_altp2m_vcpu_enable_notify to work you would have to create the
domain with altp2mhvm=1 enabled, then also issue the required commands
from dom0 to enable it (xc_altp2m_set_domain_state) and also perhaps
create a couple altp2m views.

Tamas

>>
>> Best Regards,
>> Rockosov Dmitry
>>
>> 2016-08-21 20:27 GMT+03:00 Tamas K Lengyel :
>>>
>>> Hi Dmitry,
>>> as long as you are testing with a HVM Linux guest you should be able
>>> to just compile the Xen tools in the guest and then use libxc from
>>> within the guest to issue that hypercall via
>>> xc_altp2m_set_vcpu_enable_notify. You will need to load a couple Xen
>>> related kernel-modules for it to work (like xen-privcmd). Let us know
>>> if you got it working!
>>>
>>> Cheers,
>>> Tamas
>>>
>>> On Fri, Aug 19, 2016 at 1:19 PM, Dmitry Rockosov 
>>> wrote:
>>> > Hello Xen Team!
>>> >
>>> > Does anybody have any code examples of HVMOP_altp2m_vcpu_enable_notify?
>>> >
>>> > I want to fully test #VE, VMFUNC and EPTP Switching VM Function 0 in
>>> > Xen,
>>> > but doesn't have any documentations/examples for it.
>>> > I tried xen-access test from tools/tests/xen-access, but looks like it
>>> > doesn't use VMFUNC and #VE, it simply changes VMCS entries with
>>> > vmwrite, w/o
>>> > VMFUNC 0 (EPTP Switching).
>>> >
>>> > Thanks in advance!
>>> >
>>> > Best Regards,
>>> > Rockosov Dmitry
>>> >
>>> > ___
>>> > Xen-devel mailing list
>>> > Xen-devel@lists.xen.org
>>> > https://lists.xen.org/xen-devel
>>> >
>>
>>
>

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

Re: [Xen-devel] [DRAFT v5] PV Calls protocol design document (former XenSock)

[Stefano Stabellini]

Thank you!

On Sun, 21 Aug 2016, Christopher Clark wrote:
> The PV Calls (formerly XenSock) protocol design has recently attracted 
> interest within the OpenXT software
> development community, as it is a novel interdomain communication mechanism 
> and protocol.
> 
> We have a longstanding and active interest in interdomain communication 
> transport. v4v is a protocol and mechanism
> originally designed at Citrix for XenClient and XenClient XT, now in use by 
> OpenXT, and has been deployed in
> production systems for several years at this point. It has benefitted from 
> previous reviews by the Xen Community,
> and continued engagement from its original designers, and is our selection of 
> protocol and implementation to meet
> the particular software requirements of our project. Members of the OpenXT 
> community also have interdomain
> protocol experience through being involved in the development of both vchan 
> and the XSM architecture.
> 
> The PV Calls (formerly XenSock) work described in this thread is interesting 
> and quite a different technology,
> evidently with a different set of design constraints and focus on solving a 
> different problem: it enables the
> insertion of VM boundaries and separation in-between components that are 
> communicating via the POSIX socket API,
> which could not otherwise be so isolated from each other.
> 
> In contrast, v4v prioritizes isolation between VMs over seamless integration 
> of existing components, preferring no
> memory sharing between VMs, and mandatory access control enforced on 
> communication channels by the hypervisor.
> 
> So while PV Calls is not a fit for the needs of OpenXT, this proposed 
> approach looks very good for the problem
> that it aims to address. It is complimentary to the other mechanisms 
> available in the Xen ecosystem.
> 
> I would like to convey my positive support for the PV Calls proposal.
> 
> Christopher Clark
> BAE Systems, OpenXT Project
> http://openxt.org
> 
> 
> On Thu, Aug 4, 2016 at 10:17 AM, Stefano Stabellini  
> wrote:
>   Hi all,
> 
>   This is the design document of the PV Calls protocol. You can find
>   prototypes of the Linux frontend and backend drivers here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git 
> pvcalls-5
> 
>   To use them, make sure to enable CONFIG_PVCALLS in your kernel config
>   and add "pvcalls=1" to the command line of your DomU Linux kernel. You
>   also need the toolstack to create the initial xenstore nodes for the
>   protocol. To do that, please apply the attached patch to libxl (the
>   patch is based on Xen 4.7.0-rc3) and add "pvcalls=1" to your DomU config
>   file.
> 
>   Note that previous versions of the protocols were named XenSock. It has
>   been renamed for clarity of scope and to avoid confusion with hv_sock
>   and vsock, which are used for inter-VMs communications.
> 
>   Cheers,
> 
>   Stefano
> 
>   Changes in v5:
>   - clarify text
>   - rename id to req_id
>   - rename sockid to id
>   - move id to request and response specific fields
>   - add version node to xenstore
> 
>   Changes in v4:
>   - rename xensock to pvcalls
> 
>   Changes in v3:
>   - add a dummy element to struct xen_xensock_request to make sure the
>     size of the struct is the same on both x86_32 and x86_64
> 
>   Changes in v2:
>   - add max-dataring-page-order
>   - add "Publish backend features and transport parameters" to backend
>     xenbus workflow
>   - update new cmd values
>   - update xen_xensock_request
>   - add backlog parameter to listen and binary layout
>   - add description of new data ring format (interface+data)
>   - modify connect and accept to reflect new data ring format
>   - add link to POSIX docs
>   - add error numbers
>   - add address format section and relevant numeric definitions
>   - add explicit mention of unimplemented commands
>   - add protocol node name
>   - add xenbus shutdown diagram
>   - add socket operation
> 
>   ---
> 
>   # PV Calls Protocol version 1
> 
>   ## Rationale
> 
>   PV Calls is a paravirtualized protocol that allows the implementation of
>   a set of POSIX functions in a different domain. The PV Calls frontend
>   sends POSIX function calls to the backend, which implements them and
>   returns a value to the frontend.
> 
>   This version of the document covers networking function calls, such as
>   connect, accept, bind, release, listen, poll, recvmsg and sendmsg; but
>   the protocol is meant to be easily extended to cover different sets of
>   calls. Unimplemented commands return ENOTSUPP.
> 
>   PV Calls provide the following benefits:
>   * full visibility of the guest behavior on the backend domain, allowing
>     for inexpensive filtering and manipulation of 

Re: [Xen-devel] HVMOP_altp2m_vcpu_enable_notify code example usage

[Dmitry Rockosov]

The problem is in hypervisor checking definitely. I deeper debugged the
code, I met vmcall instruction execution. This means EFAULT is coming from
hypervisor.

Best Regards,
Rockosov Dmitry

2016-08-22 18:09 GMT+03:00 Dmitry Rockosov :

> Hello Tamas,
>
> Thank you for the answer!
>
> I installed the same xen source code (4.7.0) as on dom0 to domU, built
> dist-tools, installed xen-tools, updated rc.d configuration and rebooted.
> IOCTL channel to privcmd driver is working fine, but all requests to
> hypervisor like hvm_get_param, translate_foreign_address,
> altp2m_vcpu_enable_notify return EFAULT errno (Bad access).
>
> Just for experiment I wrote below code in usermode:
> ===
> ...
> rc = xc_hvm_param_get(xch, DOMID_SELF, HVM_PARAM_CONSOLE_PFN, );
> if (rc < 0) {
> PERROR("Fail to get CONSOLE PFN HVM PARAM\n");
> goto exit;
> }
> DPRINTF("CONSOLE PFN == %llx", (unsigned long long)value);
> ...
> ===
>
> and below code in kernelmode:
> ===
> ...
> printk(KERN_INFO "We are in Xen domain HVM = %d\n", xen_hvm_domain());
> err = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, );
> printk(KERN_INFO "err = %d\n", err);
> printk(KERN_INFO "CONSOLE PFN = %llx\n", value);
> ...
> ===
>
> In the usermode I got an error:
> ===
> Fail to get CONSOLE PFN HVM PARAM
> : Bad address
> ===
>
> In the kernelmode code executed fine:
> ===
> [23261.230188] We are in Xen domain HVM = 1
> [23261.307840] err = 0
> [23261.352587] CONSOLE PFN = fefff
> ===
>
> Looks like usermode wrappers don't support many requests to hypervisor,
> right?
>
> Best Regards,
> Rockosov Dmitry
>
> 2016-08-21 20:27 GMT+03:00 Tamas K Lengyel :
>
>> Hi Dmitry,
>> as long as you are testing with a HVM Linux guest you should be able
>> to just compile the Xen tools in the guest and then use libxc from
>> within the guest to issue that hypercall via
>> xc_altp2m_set_vcpu_enable_notify. You will need to load a couple Xen
>> related kernel-modules for it to work (like xen-privcmd). Let us know
>> if you got it working!
>>
>> Cheers,
>> Tamas
>>
>> On Fri, Aug 19, 2016 at 1:19 PM, Dmitry Rockosov 
>> wrote:
>> > Hello Xen Team!
>> >
>> > Does anybody have any code examples of HVMOP_altp2m_vcpu_enable_notify?
>> >
>> > I want to fully test #VE, VMFUNC and EPTP Switching VM Function 0 in
>> Xen,
>> > but doesn't have any documentations/examples for it.
>> > I tried xen-access test from tools/tests/xen-access, but looks like it
>> > doesn't use VMFUNC and #VE, it simply changes VMCS entries with
>> vmwrite, w/o
>> > VMFUNC 0 (EPTP Switching).
>> >
>> > Thanks in advance!
>> >
>> > Best Regards,
>> > Rockosov Dmitry
>> >
>> > ___
>> > Xen-devel mailing list
>> > Xen-devel@lists.xen.org
>> > https://lists.xen.org/xen-devel
>> >
>>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

[Konrad Rzeszutek Wilk]

> > > > +#else
> > > > + asm(ALTERNATIVE("nop", "nop", 1));
> > > 
> > > Why the hardcoded 1 here? I am wondering if we should introduce a new
> > > capability "LIVEPATCH_TEST" which is enabled by default. So we can test 
> > > that
> > > the the alternative is working on all the platform. What do you think?
> > 
> > Sure, but I am not sure what number you would like? Perhaps 42 :-) ?
> 
> Unfortunately the number is an index in the bitmap, so we have to allocate
> them contiguously.

OK.
> 
> Also, this made me realize that the current implementation of
> apply_alternatives cannot work if we are patching outside the xen binary. :/

Oh yeah. The vmap part :-)
> 
> I need to have a think to see how we can handle any region.

We can just double-check that the region->begin address >= __alt_instructions
and region->End <= __alt_instructions_end and then use vmap.

Otherwise, just writemap = replptr I think?

Let me prep a patch and test it.
> 
> Cheers,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/PV: don't wrongly hide/expose CPUID.OSXSAVE from/to user mode

[Andrew Cooper]

On 19/08/16 19:07, Andrew Cooper wrote:
> On 19/08/16 18:09, Andrew Cooper wrote:
>> On 19/08/16 13:53, Jan Beulich wrote:
>>> User mode code generally cannot be expected to invoke the PV-enabled
>>> CPUID Xen supports, and prior to the CPUID levelling changes for 4.7
>>> (as well as even nowadays on levelling incapable hardware) such CPUID
>>> invocations actually saw the host CR4.OSXSAVE value, whereas prior to
>>> this patch
>>> - on Intel guest user mode always saw the flag clear,
>>> - on AMD guest user mode saw the flag set even when the guest kernel
>>>   didn't enable use of XSAVE/XRSTOR.
>>> Fold in the guest view of CR4.OSXSAVE when setting the levelling MSRs,
>>> just like we do in other CPUID handling.
>>>
>>> To make guest CR4 changes immediately visible via CPUID, also invoke
>>> ctxt_switch_levelling() from the CR4 write path.

I was just putting together a patch series to make these changes in a
more consistent manor, and have found a spanner in the works.

Hiding Xen's view of OSXSAVE from a guests native cpuid will break
Linux, because of the pile of hacks making up the current PV XSAVE support.

Some PV guests needs to see OSXSAVE in native CPUID before they will
consider trying to use xsetbv.  I realise I have completely broken this
on Intel following the mistake in determining how the MSR masks
functioned, but seeing the value from CR4 of next will be no better.

Our choices are:
1) Always expose Xen's OSXSAVE, even to guest userspace
2) Context switch the MSRs even on guest userspace/kernel context switch.

The latter would allow us to expose Xen's OSXSAVE to guest kernels, but
expose guest kernels' OSXSAVE to guest userspace.  However, given the
number of ways for a guest kernel to context switch back to guest
userspace without Xen's interaction, we can't reliably provide an
architectural view to guest userspace.

Option 1 is the easiest patch, and least overhead.

~Andrew

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

Re: [Xen-devel] [PATCHv2 0/2] xen/privcmd: prevent page migration for hypercall buffers

[David Vrabel]

On 04/08/16 16:16, David Vrabel wrote:
> Currently libxencall using mlocked buffers for hypercall buffers.
> This pages are subject to compaction and page migration. A userspace
> process may see a hypercall fail with -EFAULT if a page backing a
> hypercall buffer is in the process of being migrated.
> 
> Page migration can be prevented by taking an additional reference to
> the page.
> 
> There are three possible ways to do this:
> 
> 1. Add a new device which when mmap()'d populated the VMA with
>suitable memory that has an additional reference.  This would give
>VMAs that have appropriate properties set (e.g., VM_DONTCOPY)
>without having to do additional madvise() calls.
> 
> 2. Add a new ioctl to privcmd to populate a VMA with suitably
>ref-counted pages.  However, mmap() on privcmd is already used for
>foreign mappings and the VMA properties for hypercall buffers and
>foreign mappings might need to be different and the handling of
>unmap will need to be different.  This might be tricky.
> 
> 3. Add a pair of ioctls to privcmd to lock/unlock a buffer by
>getting/putting an additional reference to the page.  This is
>what's implemented in this series.
> 
> Any thoughts on which is the best approach?

Did no one have an opinions on these three options?

David

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

Re: [Xen-devel] [PATCHv2 2/2] xen/privcmd: add ioctls for locking/unlocking hypercall buffers

[David Vrabel]

On 04/08/16 17:02, Jan Beulich wrote:
 On 04.08.16 at 17:16,  wrote:
>> Using mlock() for hypercall buffers is not sufficient since mlocked
>> pages are still subject to compaction and page migration.  Page
>> migration can be prevented by taking additional references to the
>> pages.
>>
>> Introduce two new ioctls: IOCTL_PRIVCMD_HCALL_BUF_LOCK and
>> IOCTL_PRIVCMD_HCALL_BUF_UNLOCK which get and put the necessary page
>> references.  The buffers do not need to be page aligned and they may
>> overlap with other buffers.  However, it is not possible to partially
>> unlock a buffer (i.e., the LOCK/UNLOCK must always be paired).  Any
>> locked buffers are automatically unlocked when the file descriptor is
>> closed.
>>
>> An alternative approach would be to extend the driver with an ioctl to
>> populate a VMA with "special", non-migratable pages.  But the
>> LOCK/UNLOCK ioctls are more flexible as they allow any page to be used
>> for hypercalls (e.g., stack, mmap'd files, etc.).  This could be used
>> to minimize bouncing for performance critical hypercalls.
>>
>> Signed-off-by: David Vrabel 
> 
> Reviewed-by: Jan Beulich 
> 
> with two remarks: Do you not care about compat mode callers?

No.  Compat mode callers can't make hypercalls since the hypervisor ABI
structures aren't converted anywhere.

> case you indeed mean to not support them, does the default
> handling ensure they will see an error instead of you mis-interpreting
> (and overrunning) the presented structure?

I will look at this.

>> +static struct privcmd_hbuf *privcmd_hbuf_alloc(struct privcmd_hcall_buf 
>> *buf)
>> +{
>> +struct privcmd_hbuf *hbuf;
>> +unsigned long start, end, nr_pages;
>> +int ret;
>> +
>> +start = (unsigned long)buf->start & PAGE_MASK;
>> +end = ALIGN((unsigned long)buf->start + buf->len, PAGE_SIZE);
>> +nr_pages = (end - start) / PAGE_SIZE;
> 
> So entry re-use is based on the actual length the caller passed,
> while page tracking of course is page granular. Wouldn't it make
> sense to re-use entries based on the pages they encompass,
> which in particular would mean that two distinct buffers on the
> same page would get just a single entry?

If you make the entries page aligned, you can't give always give an
error when the user unlocks something of the wrong size.

David

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

Re: [Xen-devel] [PATCH v1 7/9] livepatch: ARM64: Ignore mapping symbols: $[a, d, x, p]

[Konrad Rzeszutek Wilk]

On Wed, Aug 17, 2016 at 06:21:03AM -0600, Jan Beulich wrote:
> >>> On 15.08.16 at 01:07,  wrote:
> 
> According to the code you mean $t instead of $p in the subject.

Yes! Thanks for noticing that.
> 
> > --- a/xen/arch/arm/livepatch.c
> > +++ b/xen/arch/arm/livepatch.c
> > @@ -90,6 +90,35 @@ void arch_livepatch_unmask(void)
> >  local_abort_enable();
> >  }
> >  
> > +int arch_is_payload_symbol(const struct livepatch_elf *elf,
> > +   const struct livepatch_elf_sym *sym)
> > +{
> > +/*
> > + * - Mapping symbols - denote the "start of a sequence of bytes of the
> > + *   appropiate type" to mark certain features - such as start of 
> > region
> > + *   containing A64 ($x), ARM ($a), or Thumb instructions ($t); or 
> > data ($d)
> > + *
> > + * The format is either short: '$x' or long: '$x.'. We do not
> > + * need this and more importantly - each payload will contain this
> > + * resulting in symbol collisions.
> > + */
> > +if ( *sym->name == '$' && sym->name[1] != '\0' )
> > +{
> > +char p = sym->name[1];
> > +size_t len = strlen(sym->name);
> > +
> > +if ( (len >= 3 && ( sym->name[2] == '.' )) || (len == 2) )
> > +if ( p == 'd' ||
> 
> May I suggest not nesting two if()-s like this?
> 
> > --- a/xen/common/livepatch.c
> > +++ b/xen/common/livepatch.c
> > @@ -780,7 +780,7 @@ static bool_t is_payload_symbol(const struct 
> > livepatch_elf *elf,
> >   !strncmp(sym->name, ".L", 2) )
> >  return 0;
> >  
> > -return 1;
> > +return arch_is_payload_symbol(elf, sym);
> >  }
> 
> Taking into consideration what's still visible as context here - are .L
> prefixed symbols really architecture independent? If not, checking

They are architecture independent and even the ARM ELF document mentions
it:
"Note: Multiple conventions exist for the names of compiler temporary symbols
(for example, ARMCC uses Lxxx.yyy, while GNU uses .Lxxx)."

(pg 23)

> for them should probably be moved.
> 
> Jan
> 

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

Re: [Xen-devel] [PATCH v1 2/9] x86/arm: Make 'make debug' work properly.

[Konrad Rzeszutek Wilk]

On Wed, Aug 17, 2016 at 06:00:22AM -0600, Jan Beulich wrote:
> >>> On 15.08.16 at 01:07,  wrote:
> > On x86 it works great but on ARM 32,64 not so much.
> 
> Considering the nature of the change ...
> 
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -101,7 +101,7 @@ _uninstall:
> >  
> >  .PHONY: _debug
> >  _debug:
> > -   objdump -D -S $(TARGET)-syms > $(TARGET).s
> > +   $(OBJDUMP) -D -S $(TARGET)-syms > $(TARGET).s
> 
> ... I'd have expected breakage to be the other way around (works
> in native build but breaks in cross ones). Can you explain in which

Yes!
> way a plain objdump fails here in the native case?

I meant cross-builds. Doing compiling on ARM 32 proper platform
takes quite a while. And got so used that I am doing it now all the time.

> 
> Irrespective of that the patch of course if fine, i.e.
> Acked-by: Jan Beulich 
> just that's it like it to be explained better.

Thank you. Changing the commit to say;

When doing cross-compilation we should use proper $(OBJDUMP).
Otherwise decompiling say ARM32 code using x86 objdump won't help much.

> 
> Jan
> 

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

[Xen-devel] [ovmf baseline-only test] 67577: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d36447418d32d82c4d1033ffcf5cb6244031ac9f
baseline version:
 ovmf 35dc964bf1eab3f0725389811d2316b1331d6cee

Last test of basis67564  2016-08-19 19:22:16 Z2 days
Testing same since67577  2016-08-22 09:48:26 Z0 days1 attempts


People who touched revisions under test:
  Vikas C Sajjan 

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



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

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

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


Push not applicable.


commit d36447418d32d82c4d1033ffcf5cb6244031ac9f
Author: Vikas C Sajjan 
Date:   Fri Aug 19 12:25:55 2016 +0530

ArmVirtPkg: Add Ramdisk support to ArmVirtPkg platforms

Adds the RAMDisk support to ArmVirtPkg platforms.
This patch actually ports OvmfPkg commit 259d87146b07 to
ArmVirtPkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vikas C Sajjan 
Reviewed-by: Laszlo Ersek 

commit fde03c8065ea6f695d13407ff4fc32c79c04522d
Author: Vikas C Sajjan 
Date:   Fri Aug 19 12:25:54 2016 +0530

ArmVirtPkg: Move inclusion of AcpiTableDxe.inf to ArmVirt.dsc.inc

Since ArmVirt.dsc.inc is included in all the ArmVirt dsc files,
move inclusion of AcpiTableDxe.inf to ArmVirt.dsc.inc.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vikas C Sajjan 
Reviewed-by: Laszlo Ersek 

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

Re: [Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[David Vrabel]

On 22/08/16 16:42, Vitaly Kuznetsov wrote:
> 
> I see two ways to fix the issue:
> - Change the 'wire' protocol between netfront and netback to start keeping
>   the original SKB structure. We'll have to add a flag indicating the fact
>   that the particular request is a part of the original linear part and not
>   a frag. We'll need to know the length of the linear part to pre-allocate
>   memory.

I don't think there needs to be a protocol change.  I think the check in
netback is bogus -- it's the total packet length that must be >
HLEN_ETH.  The upper layers will pull any headers from the frags as
needed (or if necessary, netback could pull a minimum amount).

There's no need to preserve the skb layout (e.g., look how the to-guest
direction we do not do this).

David

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

[Xen-devel] [PATCH net-next] xen-netfront: avoid packet loss when ethernet header crosses page boundary

[Vitaly Kuznetsov]

Small packet loss is reported on complex multi host network configurations
including tunnels, NAT, ... My investigation led me to the following check
in netback which drops packets:

if (unlikely(txreq.size < ETH_HLEN)) {
netdev_err(queue->vif->dev,
   "Bad packet size: %d\n", txreq.size);
xenvif_tx_err(queue, , extra_count, idx);
break;
}

But this check itself is legitimate. SKBs consist of a linear part (which
has to have the ethernet header) and (optionally) a number of frags.
Netfront transmits the head of the linear part up to the page boundary
as the first request and all the rest becomes frags so when we're
reconstructing the SKB in netback we can't distinguish between original
frags and the 'tail' of the linear part. The first SKB needs to be at
least ETH_HLEN size. So in case we have an SKB with its linear part
starting too close to the page boundary the packet is lost.

I see two ways to fix the issue:
- Change the 'wire' protocol between netfront and netback to start keeping
  the original SKB structure. We'll have to add a flag indicating the fact
  that the particular request is a part of the original linear part and not
  a frag. We'll need to know the length of the linear part to pre-allocate
  memory.
- Avoid transmitting SKBs with linear parts starting too close to the page
  boundary. That seems preferable short-term and shouldn't bring
  significant performance degradation as such packets are rare. That's what
  this patch is trying to achieve with skb_copy().

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/net/xen-netfront.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 96ccd4e..28c4a66 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -565,6 +565,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
struct netfront_queue *queue = NULL;
unsigned int num_queues = dev->real_num_tx_queues;
u16 queue_index;
+   struct sk_buff *nskb;
 
/* Drop the packet if no queues are set up */
if (num_queues < 1)
@@ -595,6 +596,19 @@ static int xennet_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
offset = offset_in_page(skb->data);
len = skb_headlen(skb);
 
+   /* The first req should be at least ETH_HLEN size or the packet will be
+* dropped by netback.
+*/
+   if (unlikely(PAGE_SIZE - offset < ETH_HLEN)) {
+   nskb = skb_copy(skb, GFP_ATOMIC);
+   if (!nskb)
+   goto drop;
+   dev_kfree_skb_any(skb);
+   skb = nskb;
+   page = virt_to_page(skb->data);
+   offset = offset_in_page(skb->data);
+   }
+
spin_lock_irqsave(>tx_lock, flags);
 
if (unlikely(!netif_carrier_ok(dev) ||
-- 
2.7.4


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

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

[osstest service owner]

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

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  94d3b9990bf73459919fb5b234d088d1ac41c9da
baseline version:
 xen  2a99aa99fc84a45f505f84802af56b006d14c52e

Last test of basis   100568  2016-08-19 21:02:00 Z2 days
Testing same since   100583  2016-08-22 14:01:54 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  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=94d3b9990bf73459919fb5b234d088d1ac41c9da
+ . ./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 
94d3b9990bf73459919fb5b234d088d1ac41c9da
+ branch=xen-unstable-smoke
+ revision=94d3b9990bf73459919fb5b234d088d1ac41c9da
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x94d3b9990bf73459919fb5b234d088d1ac41c9da = 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/ 

[Xen-devel] [qemu-mainline test] 100581: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100562
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100562
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100562

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

version targeted for testing:
 qemuu62680fad7fd63b1f5cfd049a85993e4b24b03958
baseline version:
 qemuu5f9f818ea88a013b2464563be354dd2f0f316407

Last test of basis   100562  2016-08-19 16:12:36 Z2 days
Testing same since   100581  2016-08-22 10:14:32 Z0 days1 attempts


People who touched revisions under test:
  Cao jin 
  Dmitry Fleytman 
  Jason Wang 
  Marc-André Lureau 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH v8 05/13] libxl: Load guest BIOS from file

[Wei Liu]

On Mon, Aug 22, 2016 at 04:09:07PM +0100, Andrew Cooper wrote:
> On 22/08/16 15:26, Wei Liu wrote:
> > On Mon, Aug 22, 2016 at 02:26:11PM +0100, Andrew Cooper wrote:
> >> On 22/08/16 14:13, Wei Liu wrote:
> >>> On Fri, Aug 19, 2016 at 03:43:00PM +0100, Andrew Cooper wrote:
>  On 18/08/16 15:13, Wei Liu wrote:
> > From: Anthony PERARD 
> >
> > The path to the BIOS blob can be overriden by the xl's
> > bios_path_override option, or provided by u.hvm.bios_firmware in the
> > domain_build_info struct by other libxl user.
> >
> > Signed-off-by: Anthony PERARD 
> > Acked-by: Wei Liu 
>  This introduces a regression, but I am not sure how best to fix it.
> 
>  [root@xrtuk-09-12 xen-test-framework]# xl -vvv create -p
>  tests/selftest/test-hvm32-selftest.cfg
>  Parsing config from tests/selftest/test-hvm32-selftest.cfg
>  libxl: debug: libxl_create.c:1603:do_domain_create: ao 0xa6b9f0: create:
>  how=(nil) callback=(nil) poller=0xa6c120
>  libxl: debug: libxl_create.c:959:initiate_domain_create: running 
>  bootloader
>  libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV
>  domain, skipping bootloader
>  libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
>  w=0xa6cc30: deregister unregistered
>  libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA
>  placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=17,
>  free_memkb=30611
>  libxl: detail: libxl_dom.c:182:numa_place_domain: NUMA placement
>  candidate with 1 nodes, 12 cpus and 30611 KB free selected
>  domainbuilder: detail: xc_dom_allocate: cmdline="(null)", 
>  features="(null)"
>  domainbuilder: detail: xc_dom_kernel_file:
>  filename="/opt/xen-test-framework/tests/selftest/test-hvm32-selftest"
>  domainbuilder: detail: xc_dom_malloc_filemap: 1090 kB
>  libxl: debug: libxl_dom.c:874:libxl__load_hvm_firmware_module: Loading
>  BIOS: /usr/libexec/xen/boot/bios.bin
>  libxl: error: libxl_dom.c:882:libxl__load_hvm_firmware_module: failed to
>  read BIOS file: No such file or directory
> 
>  In this case, tools have been built with ./configure --disable-seabios
> 
>  As a result, /usr/libexec/xen/boot/bios.bin (name altered a patch sent
>  separately) isn't built or installed.
> 
>  I think libxl needs to logic to determine which firmware to use based on
>  the available CONFIG_* options it was built with.
> >>> I don' quite follow here.
> >>>
> >>> Do you mean if user hasn't specified any bios= option, (s)he gets
> >>> whatever available?
> >>>
> >>> I think we should stick with the seabios-default behaviour to avoid
> >>> surprising breakage.
> >>>
> >>> If you don't want any bois, maybe we should provide a bios=none option?
> >> XenServer is built with ./configure --disable-seabios because we don't
> >> use it (yet).  This means that SeaBIOS is not built, installed, or
> >> available.
> >>
> >> Because of this change, libxl unconditionally assumes the presence of
> >> SeaBIOS, and tries to use the installed seabios binary.
> > Right, this needs fixing.
> >
> > We can restore the behaviour in libxl -- if you specify a not available
> > bios, libxl won't complain, hvmloader will crash in the same way as
> > before.
> 
> HVMLoader works fine.  I am not sure how you got this idea.
> 

Huh? If you don't embed seabios or ovmf in hvmloader and then specify
bios=seabios or bios=ovmf in guest config file, I'm sure it will crash
when trying to load bios.

Wei.

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

Re: [Xen-devel] [PATCH v4 14/16] kprobes: move kprobe declarations to asm-generic/kprobes.h

[Masami Hiramatsu]

On Fri, 19 Aug 2016 14:34:12 -0700
mcg...@kernel.org wrote:

> From: "Luis R. Rodriguez" 
> 
> Often all is needed is these small helpers, instead of compiler.h
> or a full kprobes.h. This is important for asm helpers, in fact even
> some asm/kprobes.h make use of these helpers... instead just keep a
> generic asm file with helpers useful for asm code with the least amount
> of clutter as possible.
> 
> Likewise we need now to also address what to do about this file for both
> when architectures have CONFIG_HAVE_KPROBES, and when they do not. Then
> for when architectures have CONFIG_HAVE_KPROBES but have disabled
> CONFIG_KPROBES.
> 
> Right now most asm/kprobes.h do not have guards against CONFIG_KPROBES,
> this means most architecture code cannot include asm/kprobes.h safely.
> Correct this and add guards for architectures missing them. Additionally
> provide architectures that not have kprobes support with the default
> asm-generic solution. This lets us force asm/kprobes.h on the header
> include/linux/kprobes.h always, but most importantly we can now safely
> include just asm/kprobes.h on architecture code without bringing
> the full kitchen sink of header files.
> 
> Two architectures already provided a guard against CONFIG_KPROBES on
> its kprobes.h: sh, arch. The rest of the architectures needed gaurds
> added. We avoid including any not-needed headers on asm/kprobes.h
> unless kprobes have been enabled.
> 
> In a subsequent atomic change we can try now to remove compiler.h from
> include/linux/kprobes.h.

Hmm, this looks a bit overkill... I rather like move it into linux/table.h.

Thanks,

> 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  arch/alpha/include/asm/Kbuild  |  1 +
>  arch/arc/include/asm/kprobes.h |  6 --
>  arch/arm/include/asm/kprobes.h |  4 
>  arch/arm/probes/decode.h   |  1 +
>  arch/arm64/include/asm/kprobes.h   |  4 
>  arch/arm64/kernel/insn.c   |  1 +
>  arch/avr32/include/asm/kprobes.h   |  4 
>  arch/blackfin/include/asm/Kbuild   |  1 +
>  arch/c6x/include/asm/Kbuild|  1 +
>  arch/cris/include/asm/Kbuild   |  1 +
>  arch/frv/include/asm/Kbuild|  1 +
>  arch/h8300/include/asm/Kbuild  |  1 +
>  arch/hexagon/include/asm/Kbuild|  1 +
>  arch/ia64/include/asm/kprobes.h|  7 ++-
>  arch/m32r/include/asm/Kbuild   |  1 +
>  arch/m68k/include/asm/Kbuild   |  1 +
>  arch/metag/include/asm/Kbuild  |  1 +
>  arch/microblaze/include/asm/Kbuild |  1 +
>  arch/mips/include/asm/kprobes.h|  6 +-
>  arch/mn10300/include/asm/kprobes.h |  4 
>  arch/nios2/include/asm/Kbuild  |  1 +
>  arch/openrisc/include/asm/Kbuild   |  1 +
>  arch/parisc/include/asm/Kbuild |  1 +
>  arch/powerpc/include/asm/kprobes.h |  6 ++
>  arch/s390/include/asm/kprobes.h|  4 
>  arch/score/include/asm/Kbuild  |  1 +
>  arch/sh/include/asm/kprobes.h  |  2 ++
>  arch/sparc/include/asm/kprobes.h   |  5 +
>  arch/tile/include/asm/kprobes.h|  6 +-
>  arch/um/include/asm/Kbuild |  1 +
>  arch/unicore32/include/asm/Kbuild  |  1 +
>  arch/x86/include/asm/kprobes.h |  6 ++
>  arch/xtensa/include/asm/Kbuild |  1 +
>  include/asm-generic/kprobes.h  | 25 +
>  include/linux/compiler.h   |  8 
>  include/linux/kprobes.h| 19 +++
>  36 files changed, 107 insertions(+), 29 deletions(-)
>  create mode 100644 include/asm-generic/kprobes.h
> 
> diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
> index f3bdc31d3c97..54d388fd026f 100644
> --- a/arch/alpha/include/asm/Kbuild
> +++ b/arch/alpha/include/asm/Kbuild
> @@ -13,3 +13,4 @@ generic-y += trace_clock.h
>  generic-y += section-core.h
>  generic-y += ranges.h
>  generic-y += tables.h
> +generic-y += kprobes.h
> diff --git a/arch/arc/include/asm/kprobes.h b/arch/arc/include/asm/kprobes.h
> index 944dbedb38b5..00bdbe167615 100644
> --- a/arch/arc/include/asm/kprobes.h
> +++ b/arch/arc/include/asm/kprobes.h
> @@ -9,6 +9,8 @@
>  #ifndef _ARC_KPROBES_H
>  #define _ARC_KPROBES_H
>  
> +#include 
> +
>  #ifdef CONFIG_KPROBES
>  
>  typedef u16 kprobe_opcode_t;
> @@ -55,6 +57,6 @@ void trap_is_kprobe(unsigned long address, struct pt_regs 
> *regs);
>  static void trap_is_kprobe(unsigned long address, struct pt_regs *regs)
>  {
>  }
> -#endif
> +#endif /* CONFIG_KPROBES */
>  
> -#endif
> +#endif /* _ARC_KPROBES_H */
> diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
> index 3ea9be559726..59655459da59 100644
> --- a/arch/arm/include/asm/kprobes.h
> +++ b/arch/arm/include/asm/kprobes.h
> @@ -16,6 +16,9 @@
>  #ifndef _ARM_KPROBES_H
>  #define _ARM_KPROBES_H
>  
> +#include 
> +
> +#ifdef CONFIG_KPROBES
>  #include 
>  #include 
>  #include 
> @@ -83,4 +86,5 @@ struct arch_optimized_insn {
>*/
>  };
>  
> +#endif /* CONFIG_KPROBES */
>  #endif /* _ARM_KPROBES_H */
> diff 

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Jan Beulich]

>>> On 22.08.16 at 16:02,  wrote:
> On August 22, 2016 8:04 PM,  wrote: 
> On 22.08.16 at 13:41,  wrote:
>>> On August 22, 2016 6:36 PM,  wrote:
>>> On 19.08.16 at 14:58,  wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
> 2001
> From: Quan Xu 
> Date: Fri, 19 Aug 2016 20:40:31 +0800
> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv
> issue
>
> When Xen apicv is enabled, wall clock time is faster on Windows7-32
> guest with high payload (with 2vCPU, captured from xentrace, in high
> payload, the count of IPI interrupt increases rapidly between these 
> vCPUs).
>
> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
> 0xd1) are both pending (index of bit set in VIRR), unfortunately,
> the IPI intrrupt is high priority than periodic timer interrupt. Xen
> updates IPI interrupt bit set in VIRR to guest interrupt status
> (RVI) as a high priority and apicv (Virtual-Interrupt Delivery)
> delivers IPI interrupt within VMX non-root operation without a VM
> exit. Within VMX non-root operation, if periodic timer interrupt
> index of bit is set in VIRR and highest, the apicv delivers periodic timer
>>interrupt within VMX non-root operation as well.
>
> But in current code, if Xen doesn't update periodic timer interrupt
> bit set in VIRR to guest interrupt status (RVI) directly, Xen is not
> aware of this case to decrease the count (pending_intr_nr) of
> pending periodic timer interrupt, then Xen will deliver a periodic
> timer interrupt again. The guest receives more periodic timer
> interrupt.
>
> If the periodic timer interrut is delivered and not the highest
> priority, make Xen be aware of this case to decrease the count of
> pending periodic timer interrupt.

I can see the issue you're trying to address, but for one - doesn't
this lead to other double accounting, namely once the pt irq becomes
the highest priority one?

>>>
>>> It is does NOT lead to other double accounting..
>>> As if the pt irq becomes the highest priority one, the intack is pt one..
>>> Then:
>>>
>>>  +else
>>>  +pt_intr_post(v, intack);
>>
>>As just said in reply to Yang: If this is still the same interrupt instance 
> as in a
>>prior run through here which took the if() branch, this change looks like 
> having
>>the potential of double accounting.
>>
> 
> I very appreciate your detail review. It looks like, but actually it doesn't 
> happen.
> 
>  As the key parameter 'pt->irq_issued'..
> 
> In pt_update_irq(), once the PT irq is issued, set the pt->irq_issued..
> In pt_intr_post(), clear the pt->irq_issued before touching the count 
> 'pt->pending_intr_nr'..
> 
> According to your assumption, at the second call to pt_intr_post(), As if 
> 'pt->irq_issued' is clear, pt is NULL in is_pt_irq() check,
> then return, there is no chance to touch the count 'pt->pending_intr_nr'..

Hmm, wait: That second pass would also get us through
pt_update_irq() a second time, which might cause irq_issued to get
set again.

Granted this code is fragile, therefore please excuse that I'm trying
to be extra careful with accepting changes to it.

Jan


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

Re: [Xen-devel] HVMOP_altp2m_vcpu_enable_notify code example usage

[Dmitry Rockosov]

Hello Tamas,

Thank you for the answer!

I installed the same xen source code (4.7.0) as on dom0 to domU, built
dist-tools, installed xen-tools, updated rc.d configuration and rebooted.
IOCTL channel to privcmd driver is working fine, but all requests to
hypervisor like hvm_get_param, translate_foreign_address,
altp2m_vcpu_enable_notify return EFAULT errno (Bad access).

Just for experiment I wrote below code in usermode:
===
...
rc = xc_hvm_param_get(xch, DOMID_SELF, HVM_PARAM_CONSOLE_PFN, );
if (rc < 0) {
PERROR("Fail to get CONSOLE PFN HVM PARAM\n");
goto exit;
}
DPRINTF("CONSOLE PFN == %llx", (unsigned long long)value);
...
===

and below code in kernelmode:
===
...
printk(KERN_INFO "We are in Xen domain HVM = %d\n", xen_hvm_domain());
err = hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, );
printk(KERN_INFO "err = %d\n", err);
printk(KERN_INFO "CONSOLE PFN = %llx\n", value);
...
===

In the usermode I got an error:
===
Fail to get CONSOLE PFN HVM PARAM
: Bad address
===

In the kernelmode code executed fine:
===
[23261.230188] We are in Xen domain HVM = 1
[23261.307840] err = 0
[23261.352587] CONSOLE PFN = fefff
===

Looks like usermode wrappers don't support many requests to hypervisor,
right?

Best Regards,
Rockosov Dmitry

2016-08-21 20:27 GMT+03:00 Tamas K Lengyel :

> Hi Dmitry,
> as long as you are testing with a HVM Linux guest you should be able
> to just compile the Xen tools in the guest and then use libxc from
> within the guest to issue that hypercall via
> xc_altp2m_set_vcpu_enable_notify. You will need to load a couple Xen
> related kernel-modules for it to work (like xen-privcmd). Let us know
> if you got it working!
>
> Cheers,
> Tamas
>
> On Fri, Aug 19, 2016 at 1:19 PM, Dmitry Rockosov 
> wrote:
> > Hello Xen Team!
> >
> > Does anybody have any code examples of HVMOP_altp2m_vcpu_enable_notify?
> >
> > I want to fully test #VE, VMFUNC and EPTP Switching VM Function 0 in Xen,
> > but doesn't have any documentations/examples for it.
> > I tried xen-access test from tools/tests/xen-access, but looks like it
> > doesn't use VMFUNC and #VE, it simply changes VMCS entries with vmwrite,
> w/o
> > VMFUNC 0 (EPTP Switching).
> >
> > Thanks in advance!
> >
> > Best Regards,
> > Rockosov Dmitry
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
> >
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v8 05/13] libxl: Load guest BIOS from file

[Andrew Cooper]

On 22/08/16 15:26, Wei Liu wrote:
> On Mon, Aug 22, 2016 at 02:26:11PM +0100, Andrew Cooper wrote:
>> On 22/08/16 14:13, Wei Liu wrote:
>>> On Fri, Aug 19, 2016 at 03:43:00PM +0100, Andrew Cooper wrote:
 On 18/08/16 15:13, Wei Liu wrote:
> From: Anthony PERARD 
>
> The path to the BIOS blob can be overriden by the xl's
> bios_path_override option, or provided by u.hvm.bios_firmware in the
> domain_build_info struct by other libxl user.
>
> Signed-off-by: Anthony PERARD 
> Acked-by: Wei Liu 
 This introduces a regression, but I am not sure how best to fix it.

 [root@xrtuk-09-12 xen-test-framework]# xl -vvv create -p
 tests/selftest/test-hvm32-selftest.cfg
 Parsing config from tests/selftest/test-hvm32-selftest.cfg
 libxl: debug: libxl_create.c:1603:do_domain_create: ao 0xa6b9f0: create:
 how=(nil) callback=(nil) poller=0xa6c120
 libxl: debug: libxl_create.c:959:initiate_domain_create: running bootloader
 libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV
 domain, skipping bootloader
 libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
 w=0xa6cc30: deregister unregistered
 libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA
 placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=17,
 free_memkb=30611
 libxl: detail: libxl_dom.c:182:numa_place_domain: NUMA placement
 candidate with 1 nodes, 12 cpus and 30611 KB free selected
 domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"
 domainbuilder: detail: xc_dom_kernel_file:
 filename="/opt/xen-test-framework/tests/selftest/test-hvm32-selftest"
 domainbuilder: detail: xc_dom_malloc_filemap: 1090 kB
 libxl: debug: libxl_dom.c:874:libxl__load_hvm_firmware_module: Loading
 BIOS: /usr/libexec/xen/boot/bios.bin
 libxl: error: libxl_dom.c:882:libxl__load_hvm_firmware_module: failed to
 read BIOS file: No such file or directory

 In this case, tools have been built with ./configure --disable-seabios

 As a result, /usr/libexec/xen/boot/bios.bin (name altered a patch sent
 separately) isn't built or installed.

 I think libxl needs to logic to determine which firmware to use based on
 the available CONFIG_* options it was built with.
>>> I don' quite follow here.
>>>
>>> Do you mean if user hasn't specified any bios= option, (s)he gets
>>> whatever available?
>>>
>>> I think we should stick with the seabios-default behaviour to avoid
>>> surprising breakage.
>>>
>>> If you don't want any bois, maybe we should provide a bios=none option?
>> XenServer is built with ./configure --disable-seabios because we don't
>> use it (yet).  This means that SeaBIOS is not built, installed, or
>> available.
>>
>> Because of this change, libxl unconditionally assumes the presence of
>> SeaBIOS, and tries to use the installed seabios binary.
> Right, this needs fixing.
>
> We can restore the behaviour in libxl -- if you specify a not available
> bios, libxl won't complain, hvmloader will crash in the same way as
> before.

HVMLoader works fine.  I am not sure how you got this idea.


For XTF, we use firmware_override= to replace hvmloader with something
else.  As bios= is specific to hvmloader, it shouldn't be mandatory, and
should probably have an explicit none option.

~Andrew

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

[Xen-devel] [PATCH 1/2] tools: only define {OVMF, SEABIOS}_PATH when they are enabled

[Wei Liu]

Signed-off-by: Wei Liu 
---
Rerun autogen.sh
---
 tools/configure|  8 
 tools/configure.ac | 16 ++--
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/tools/configure b/tools/configure
index 81ccf34..998090a 100755
--- a/tools/configure
+++ b/tools/configure
@@ -4449,12 +4449,16 @@ if test "${with_system_seabios+set}" = set; then :
 
 fi
 
+if test "x$seabios" = "xy"; then :
+
 
 cat >>confdefs.h <<_ACEOF
 #define SEABIOS_PATH "${seabios_path:-$XENFIRMWAREDIR/bios.bin}"
 _ACEOF
 
 
+fi
+
 
 # Check whether --with-system-ovmf was given.
 if test "${with_system_ovmf+set}" = set; then :
@@ -4468,12 +4472,16 @@ if test "${with_system_ovmf+set}" = set; then :
 
 fi
 
+if test "x$ovmf" = "xy"; then :
+
 
 cat >>confdefs.h <<_ACEOF
 #define OVMF_PATH "${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"
 _ACEOF
 
 
+fi
+
 
 # Check whether --with-extra-qemuu-configure-args was given.
 if test "${with_extra_qemuu_configure_args+set}" = set; then :
diff --git a/tools/configure.ac b/tools/configure.ac
index c12ad79..1fb4a55 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -222,9 +222,11 @@ AC_ARG_WITH([system-seabios],
 *)  seabios_path=$withval ;;
 esac
 ],[])
-AC_DEFINE_UNQUOTED([SEABIOS_PATH],
-   ["${seabios_path:-$XENFIRMWAREDIR/bios.bin}"],
-   [SeaBIOS path])
+AS_IF([test "x$seabios" = "xy"], [
+AC_DEFINE_UNQUOTED([SEABIOS_PATH],
+   ["${seabios_path:-$XENFIRMWAREDIR/bios.bin}"],
+   [SeaBIOS path])
+])
 
 AC_ARG_WITH([system-ovmf],
 AS_HELP_STRING([--with-system-ovmf@<:@=PATH@:>@],
@@ -237,9 +239,11 @@ AC_ARG_WITH([system-ovmf],
 *)  ovmf_path=$withval ;;
 esac
 ],[])
-AC_DEFINE_UNQUOTED([OVMF_PATH],
-   ["${ovmf_path:-$XENFIRMWAREDIR/ovmf.bin}"],
-   [OVMF path])
+AS_IF([test "x$ovmf" = "xy"], [
+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 ..."@:>@],
-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] libxl: only return {OVMF, SEABIOS}_PATH if available

[Wei Liu]

Signed-off-by: Wei Liu 
---
 tools/libxl/libxl_paths.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/libxl/libxl_paths.c b/tools/libxl/libxl_paths.c
index 6972b90..0643c1b 100644
--- a/tools/libxl/libxl_paths.c
+++ b/tools/libxl/libxl_paths.c
@@ -37,12 +37,20 @@ const char *libxl__run_dir_path(void)
 
 const char *libxl__seabios_path(void)
 {
+#ifdef SEABIOS_PATH
 return SEABIOS_PATH;
+#else
+return NULL;
+#endif
 }
 
 const char *libxl__ovmf_path(void)
 {
+#ifdef OVMF_PATH
 return OVMF_PATH;
+#else
+return NULL;
+#endif
 }
 
 /*
-- 
2.1.4


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

[Xen-devel] [PATCH 0/2] Fix issue with {OVMF,SEABIOS}_PATH

[Wei Liu]

They shouldn't be available when the respective BIOS is disabled at build time.

This should fix the issus that causes xtf fail to launch hvm guests.

Wei Liu (2):
  tools: only define {OVMF,SEABIOS}_PATH when they are enabled
  libxl: only return {OVMF,SEABIOS}_PATH if available

 tools/configure   |  8 
 tools/configure.ac| 16 ++--
 tools/libxl/libxl_paths.c |  8 
 3 files changed, 26 insertions(+), 6 deletions(-)

-- 
2.1.4


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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Jan Beulich]

>>> On 22.08.16 at 15:09,  wrote:
> On 2016/8/22 20:04, Jan Beulich wrote:
> On 22.08.16 at 13:41,  wrote:
>>> On August 22, 2016 6:36 PM,  wrote:
>>> On 19.08.16 at 14:58,  wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
> From: Quan Xu 
> Date: Fri, 19 Aug 2016 20:40:31 +0800
> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
>
> When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
> with high payload (with 2vCPU, captured from xentrace, in high payload, 
> the
> count of IPI interrupt increases rapidly between these vCPUs).
>
> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
> are both pending (index of bit set in VIRR), unfortunately, the IPI 
> intrrupt
> is high priority than periodic timer interrupt. Xen updates IPI interrupt 
> bit
> set in VIRR to guest interrupt status (RVI) as a high priority and apicv
> (Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
> operation without a VM exit. Within VMX non-root operation, if periodic 
> timer
> interrupt index of bit is set in VIRR and highest, the apicv delivers 
> periodic
> timer interrupt within VMX non-root operation as well.
>
> But in current code, if Xen doesn't update periodic timer interrupt bit 
> set
> in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
> case to decrease the count (pending_intr_nr) of pending periodic timer
> interrupt,
> then Xen will deliver a periodic timer interrupt again. The guest receives
> more
> periodic timer interrupt.
>
> If the periodic timer interrut is delivered and not the highest priority, 
> make
> Xen be aware of this case to decrease the count of pending periodic timer
> interrupt.

 I can see the issue you're trying to address, but for one - doesn't
 this lead to other double accounting, namely once the pt irq becomes
 the highest priority one?

>>>
>>> It is does NOT lead to other double accounting..
>>> As if the pt irq becomes the highest priority one, the intack is pt one..
>>> Then:
>>>
>>>  +else
>>>  +pt_intr_post(v, intack);
>>
>> As just said in reply to Yang: If this is still the same interrupt instance
>> as in a prior run through here which took the if() branch, this change
>> looks like having the potential of double accounting.
> 
> This cannot happen: if pt intr is the second priority one, then 
> corresponding vIRR bit will be cleared by hardware while the highest 
> priority intr is delivered to guest. And the next vmx_intr_assit cannot 
> aware of it since the vIRR bit is zero.

In addition to what Quan said in response - aren't you mixing up
vISR and vIRR here? I can see vISR being clear when a higher prio
interrupt gets delivered (unless that happened to interrupt the pt
interrupt handler), but I would hope that virtualized behavior
matches non-virtualized one in that vIRR accumulates requests.

Jan


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

Re: [Xen-devel] [PATCH v8 05/13] libxl: Load guest BIOS from file

[Wei Liu]

On Mon, Aug 22, 2016 at 02:26:11PM +0100, Andrew Cooper wrote:
> On 22/08/16 14:13, Wei Liu wrote:
> > On Fri, Aug 19, 2016 at 03:43:00PM +0100, Andrew Cooper wrote:
> >> On 18/08/16 15:13, Wei Liu wrote:
> >>> From: Anthony PERARD 
> >>>
> >>> The path to the BIOS blob can be overriden by the xl's
> >>> bios_path_override option, or provided by u.hvm.bios_firmware in the
> >>> domain_build_info struct by other libxl user.
> >>>
> >>> Signed-off-by: Anthony PERARD 
> >>> Acked-by: Wei Liu 
> >> This introduces a regression, but I am not sure how best to fix it.
> >>
> >> [root@xrtuk-09-12 xen-test-framework]# xl -vvv create -p
> >> tests/selftest/test-hvm32-selftest.cfg
> >> Parsing config from tests/selftest/test-hvm32-selftest.cfg
> >> libxl: debug: libxl_create.c:1603:do_domain_create: ao 0xa6b9f0: create:
> >> how=(nil) callback=(nil) poller=0xa6c120
> >> libxl: debug: libxl_create.c:959:initiate_domain_create: running bootloader
> >> libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV
> >> domain, skipping bootloader
> >> libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
> >> w=0xa6cc30: deregister unregistered
> >> libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA
> >> placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=17,
> >> free_memkb=30611
> >> libxl: detail: libxl_dom.c:182:numa_place_domain: NUMA placement
> >> candidate with 1 nodes, 12 cpus and 30611 KB free selected
> >> domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"
> >> domainbuilder: detail: xc_dom_kernel_file:
> >> filename="/opt/xen-test-framework/tests/selftest/test-hvm32-selftest"
> >> domainbuilder: detail: xc_dom_malloc_filemap: 1090 kB
> >> libxl: debug: libxl_dom.c:874:libxl__load_hvm_firmware_module: Loading
> >> BIOS: /usr/libexec/xen/boot/bios.bin
> >> libxl: error: libxl_dom.c:882:libxl__load_hvm_firmware_module: failed to
> >> read BIOS file: No such file or directory
> >>
> >> In this case, tools have been built with ./configure --disable-seabios
> >>
> >> As a result, /usr/libexec/xen/boot/bios.bin (name altered a patch sent
> >> separately) isn't built or installed.
> >>
> >> I think libxl needs to logic to determine which firmware to use based on
> >> the available CONFIG_* options it was built with.
> > I don' quite follow here.
> >
> > Do you mean if user hasn't specified any bios= option, (s)he gets
> > whatever available?
> >
> > I think we should stick with the seabios-default behaviour to avoid
> > surprising breakage.
> >
> > If you don't want any bois, maybe we should provide a bios=none option?
> 
> XenServer is built with ./configure --disable-seabios because we don't
> use it (yet).  This means that SeaBIOS is not built, installed, or
> available.
> 
> Because of this change, libxl unconditionally assumes the presence of
> SeaBIOS, and tries to use the installed seabios binary.

Right, this needs fixing.

We can restore the behaviour in libxl -- if you specify a not available
bios, libxl won't complain, hvmloader will crash in the same way as
before.

> 
> >
> >>> @@ -914,6 +951,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.system_firmware) {
> >>> +bios_filename = info->u.hvm.system_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;
> >> At the very least, these need to be guarded by #ifdef
> >> CONFIG_{SEABIOS,OVMF}, as it is explicitly permitted for them not to be
> >> present in a build.
> >>
> >>> +case LIBXL_BIOS_TYPE_ROMBIOS:
> >> ROMBIOS certainly does function correctly with QEMU_XEN, and is how
> >> XenServer is planning to start the migration from a qemu-trad world to a
> >> qemu-upstream world.  Even if libxl doesn't want to formally support
> >> such a configuration, it shouldn't be excluded.
> >>
> > There is no written statement, but I would rather not support this
> > configuration.
> 
> Rightly or wrongly, it is already available, usable and working (until
> this changeset), via supported configuration options.
> 

Ian, do you have more insight on whether that is supported?

> > I expect this is an impossible situation to get into, since verification
> > should have been done a few steps before -- hence the abort(3) here is
> > justified. But I would need to double-check if that's not the case and
> > will do something about it either here or at the place I see
> > appropriate.
> >
> >>> +default:
> >>> + 

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Yang Zhang]

2016年8月22日星期一，Xuquan (Euler)  写道：

> On August 22, 2016 8:04 PM, > wrote:
>  On 22.08.16 at 13:41, > wrote:
> >> On August 22, 2016 6:36 PM, > wrote:
> >> On 19.08.16 at 14:58,  wrote:
>  From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
>  2001
>  From: Quan Xu 
>  Date: Fri, 19 Aug 2016 20:40:31 +0800
>  Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv
>  issue
> 
>  When Xen apicv is enabled, wall clock time is faster on Windows7-32
>  guest with high payload (with 2vCPU, captured from xentrace, in high
>  payload, the count of IPI interrupt increases rapidly between these
> vCPUs).
> 
>  If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
>  0xd1) are both pending (index of bit set in VIRR), unfortunately,
>  the IPI intrrupt is high priority than periodic timer interrupt. Xen
>  updates IPI interrupt bit set in VIRR to guest interrupt status
>  (RVI) as a high priority and apicv (Virtual-Interrupt Delivery)
>  delivers IPI interrupt within VMX non-root operation without a VM
>  exit. Within VMX non-root operation, if periodic timer interrupt
>  index of bit is set in VIRR and highest, the apicv delivers periodic
> timer
> >interrupt within VMX non-root operation as well.
> 
>  But in current code, if Xen doesn't update periodic timer interrupt
>  bit set in VIRR to guest interrupt status (RVI) directly, Xen is not
>  aware of this case to decrease the count (pending_intr_nr) of
>  pending periodic timer interrupt, then Xen will deliver a periodic
>  timer interrupt again. The guest receives more periodic timer
>  interrupt.
> 
>  If the periodic timer interrut is delivered and not the highest
>  priority, make Xen be aware of this case to decrease the count of
>  pending periodic timer interrupt.
> >>>
> >>>I can see the issue you're trying to address, but for one - doesn't
> >>>this lead to other double accounting, namely once the pt irq becomes
> >>>the highest priority one?
> >>>
> >>
> >> It is does NOT lead to other double accounting..
> >> As if the pt irq becomes the highest priority one, the intack is pt
> one..
> >> Then:
> >>
> >>  +else
> >>  +pt_intr_post(v, intack);
> >
> >As just said in reply to Yang: If this is still the same interrupt
> instance as in a
> >prior run through here which took the if() branch, this change looks like
> having
> >the potential of double accounting.
> >
>
> I very appreciate your detail review. It looks like, but actually it
> doesn't happen.
>
>  As the key parameter 'pt->irq_issued'..
>
> In pt_update_irq(), once the PT irq is issued, set the pt->irq_issued..
> In pt_intr_post(), clear the pt->irq_issued before touching the count
> 'pt->pending_intr_nr'..
>
> According to your assumption, at the second call to pt_intr_post(), As if
> 'pt->irq_issued' is clear, pt is NULL in is_pt_irq() check,
> then return, there is no chance to touch the count 'pt->pending_intr_nr'..
> --
> void pt_intr_post(struct vcpu *v, struct hvm_intack intack)
> {
> ...
> pt = is_pt_irq(v, intack);
> if ( pt == NULL )
> {
> spin_unlock(>arch.hvm_vcpu.tm_lock);
> return;
> }
> ...
>
>
> ...
> }
>
>
> static struct periodic_time *is_pt_irq()
> {
>  
> list_for_each_entry ( pt, head, list )
> {
> if ( pt->pending_intr_nr && pt->irq_issued___ &&
>  (intack.vector == pt_irq_vector(pt, intack.source)) )
> return pt;
> }
>
> return NULL;
> }
>
>
>
>
>
> __IIUC__, this question is based on the following pseudocode detail the
> behavior of virtual-interrupt delivery is __not__ atomic:
>
> Vector <- RVI;
> VISR[Vector] <- 1;
> SVI <- Vector;
> VPPR<- Vector & F0H;
> VIRR[Vector] <- 0;
> IF any bits set in VIRR
>Then RVI<-highest index of bit set in VIRR
>ELSE RVI <-0
> FI
> Deliver interrupt with Vector through IDT
> ...
>
>
> We'd better check this first, as Yang said, this is atomic..


i have said that this is ensured by hardware.


>
> Quan
>


-- 
best regards
yang
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Yang Zhang]

2016年8月22日星期一，Xuquan (Euler)  写道：

> On August 22, 2016 8:04 PM, > wrote:
>  On 22.08.16 at 13:41, > wrote:
> >> On August 22, 2016 6:36 PM, > wrote:
> >> On 19.08.16 at 14:58,  wrote:
>  From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
>  2001
>  From: Quan Xu 
>  Date: Fri, 19 Aug 2016 20:40:31 +0800
>  Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv
>  issue
> 
>  When Xen apicv is enabled, wall clock time is faster on Windows7-32
>  guest with high payload (with 2vCPU, captured from xentrace, in high
>  payload, the count of IPI interrupt increases rapidly between these
> vCPUs).
> 
>  If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
>  0xd1) are both pending (index of bit set in VIRR), unfortunately,
>  the IPI intrrupt is high priority than periodic timer interrupt. Xen
>  updates IPI interrupt bit set in VIRR to guest interrupt status
>  (RVI) as a high priority and apicv (Virtual-Interrupt Delivery)
>  delivers IPI interrupt within VMX non-root operation without a VM
>  exit. Within VMX non-root operation, if periodic timer interrupt
>  index of bit is set in VIRR and highest, the apicv delivers periodic
> timer
> >interrupt within VMX non-root operation as well.
> 
>  But in current code, if Xen doesn't update periodic timer interrupt
>  bit set in VIRR to guest interrupt status (RVI) directly, Xen is not
>  aware of this case to decrease the count (pending_intr_nr) of
>  pending periodic timer interrupt, then Xen will deliver a periodic
>  timer interrupt again. The guest receives more periodic timer
>  interrupt.
> 
>  If the periodic timer interrut is delivered and not the highest
>  priority, make Xen be aware of this case to decrease the count of
>  pending periodic timer interrupt.
> >>>
> >>>I can see the issue you're trying to address, but for one - doesn't
> >>>this lead to other double accounting, namely once the pt irq becomes
> >>>the highest priority one?
> >>>
> >>
> >> It is does NOT lead to other double accounting..
> >> As if the pt irq becomes the highest priority one, the intack is pt
> one..
> >> Then:
> >>
> >>  +else
> >>  +pt_intr_post(v, intack);
> >
> >As just said in reply to Yang: If this is still the same interrupt
> instance as in a
> >prior run through here which took the if() branch, this change looks like
> having
> >the potential of double accounting.
> >
>
> I very appreciate your detail review. It looks like, but actually it
> doesn't happen.
>
>  As the key parameter 'pt->irq_issued'..
>
> In pt_update_irq(), once the PT irq is issued, set the pt->irq_issued..
> In pt_intr_post(), clear the pt->irq_issued before touching the count
> 'pt->pending_intr_nr'..
>
> According to your assumption, at the second call to pt_intr_post(), As if
> 'pt->irq_issued' is clear, pt is NULL in is_pt_irq() check,
> then return, there is no chance to touch the count 'pt->pending_intr_nr'..
> --
> void pt_intr_post(struct vcpu *v, struct hvm_intack intack)
> {
> ...
> pt = is_pt_irq(v, intack);
> if ( pt == NULL )
> {
> spin_unlock(>arch.hvm_vcpu.tm_lock);
> return;
> }
> ...
>
>
> ...
> }
>
>
> static struct periodic_time *is_pt_irq()
> {
>  
> list_for_each_entry ( pt, head, list )
> {
> if ( pt->pending_intr_nr && pt->irq_issued___ &&
>  (intack.vector == pt_irq_vector(pt, intack.source)) )
> return pt;
> }
>
> return NULL;
> }
>
>
>
>
>
> __IIUC__, this question is based on the following pseudocode detail the
> behavior of virtual-interrupt delivery is __not__ atomic:
>
> Vector <- RVI;
> VISR[Vector] <- 1;
> SVI <- Vector;
> VPPR<- Vector & F0H;
> VIRR[Vector] <- 0;
> IF any bits set in VIRR
>Then RVI<-highest index of bit set in VIRR
>ELSE RVI <-0
> FI
> Deliver interrupt with Vector through IDT
> ...
>
>
> We'd better check this first, as Yang said, this is atomic..


i have said that this is ensured by hardware.


>
> Quan
>


-- 
best regards
yang
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

On August 22, 2016 8:04 PM,  wrote: 
 On 22.08.16 at 13:41,  wrote:
>> On August 22, 2016 6:36 PM,  wrote:
>> On 19.08.16 at 14:58,  wrote:
 From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
 2001
 From: Quan Xu 
 Date: Fri, 19 Aug 2016 20:40:31 +0800
 Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv
 issue

 When Xen apicv is enabled, wall clock time is faster on Windows7-32
 guest with high payload (with 2vCPU, captured from xentrace, in high
 payload, the count of IPI interrupt increases rapidly between these vCPUs).

 If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
 0xd1) are both pending (index of bit set in VIRR), unfortunately,
 the IPI intrrupt is high priority than periodic timer interrupt. Xen
 updates IPI interrupt bit set in VIRR to guest interrupt status
 (RVI) as a high priority and apicv (Virtual-Interrupt Delivery)
 delivers IPI interrupt within VMX non-root operation without a VM
 exit. Within VMX non-root operation, if periodic timer interrupt
 index of bit is set in VIRR and highest, the apicv delivers periodic timer
>interrupt within VMX non-root operation as well.

 But in current code, if Xen doesn't update periodic timer interrupt
 bit set in VIRR to guest interrupt status (RVI) directly, Xen is not
 aware of this case to decrease the count (pending_intr_nr) of
 pending periodic timer interrupt, then Xen will deliver a periodic
 timer interrupt again. The guest receives more periodic timer
 interrupt.

 If the periodic timer interrut is delivered and not the highest
 priority, make Xen be aware of this case to decrease the count of
 pending periodic timer interrupt.
>>>
>>>I can see the issue you're trying to address, but for one - doesn't
>>>this lead to other double accounting, namely once the pt irq becomes
>>>the highest priority one?
>>>
>>
>> It is does NOT lead to other double accounting..
>> As if the pt irq becomes the highest priority one, the intack is pt one..
>> Then:
>>
>>  +else
>>  +pt_intr_post(v, intack);
>
>As just said in reply to Yang: If this is still the same interrupt instance as 
>in a
>prior run through here which took the if() branch, this change looks like 
>having
>the potential of double accounting.
>

I very appreciate your detail review. It looks like, but actually it doesn't 
happen.

 As the key parameter 'pt->irq_issued'..

In pt_update_irq(), once the PT irq is issued, set the pt->irq_issued..
In pt_intr_post(), clear the pt->irq_issued before touching the count 
'pt->pending_intr_nr'..

According to your assumption, at the second call to pt_intr_post(), As if 
'pt->irq_issued' is clear, pt is NULL in is_pt_irq() check,
then return, there is no chance to touch the count 'pt->pending_intr_nr'..
--
void pt_intr_post(struct vcpu *v, struct hvm_intack intack)
{
...
pt = is_pt_irq(v, intack);
if ( pt == NULL )
{
spin_unlock(>arch.hvm_vcpu.tm_lock);
return;
}
...

 
...
}


static struct periodic_time *is_pt_irq()
{
 
list_for_each_entry ( pt, head, list )
{
if ( pt->pending_intr_nr && pt->irq_issued___ &&
 (intack.vector == pt_irq_vector(pt, intack.source)) )
return pt;
}

return NULL;
}





__IIUC__, this question is based on the following pseudocode detail the 
behavior of virtual-interrupt delivery is __not__ atomic:

Vector <- RVI;
VISR[Vector] <- 1;
SVI <- Vector;
VPPR<- Vector & F0H;
VIRR[Vector] <- 0;
IF any bits set in VIRR
   Then RVI<-highest index of bit set in VIRR
   ELSE RVI <-0
FI
Deliver interrupt with Vector through IDT
...


We'd better check this first, as Yang said, this is atomic..

Quan

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

Re: [Xen-devel] Regression in kernel 4.7 xenstore

[Christoph Moench-Tegeder]

## Jan Beulich (jbeul...@suse.com):

> See https://patchwork.kernel.org/patch/9281193/.

Yes, that's it. Thanks, fix confirmed.

Regards,
Christoph

-- 
Spare Space

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 72388f9c10126a718a7ac381dc6879d3337ccb8b
baseline version:
 ovmf 8866d337ea9eba258e942585b172d57d39376e70

Last test of basis   100580  2016-08-22 09:44:26 Z0 days
Testing same since   100582  2016-08-22 11:44:27 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Hao Wu 
  Vikas C Sajjan 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=72388f9c10126a718a7ac381dc6879d3337ccb8b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
72388f9c10126a718a7ac381dc6879d3337ccb8b
+ branch=ovmf
+ revision=72388f9c10126a718a7ac381dc6879d3337ccb8b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x72388f9c10126a718a7ac381dc6879d3337ccb8b = 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 

Re: [Xen-devel] [PATCH v8 05/13] libxl: Load guest BIOS from file

[Andrew Cooper]

On 22/08/16 14:13, Wei Liu wrote:
> On Fri, Aug 19, 2016 at 03:43:00PM +0100, Andrew Cooper wrote:
>> On 18/08/16 15:13, Wei Liu wrote:
>>> From: Anthony PERARD 
>>>
>>> The path to the BIOS blob can be overriden by the xl's
>>> bios_path_override option, or provided by u.hvm.bios_firmware in the
>>> domain_build_info struct by other libxl user.
>>>
>>> Signed-off-by: Anthony PERARD 
>>> Acked-by: Wei Liu 
>> This introduces a regression, but I am not sure how best to fix it.
>>
>> [root@xrtuk-09-12 xen-test-framework]# xl -vvv create -p
>> tests/selftest/test-hvm32-selftest.cfg
>> Parsing config from tests/selftest/test-hvm32-selftest.cfg
>> libxl: debug: libxl_create.c:1603:do_domain_create: ao 0xa6b9f0: create:
>> how=(nil) callback=(nil) poller=0xa6c120
>> libxl: debug: libxl_create.c:959:initiate_domain_create: running bootloader
>> libxl: debug: libxl_bootloader.c:324:libxl__bootloader_run: not a PV
>> domain, skipping bootloader
>> libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
>> w=0xa6cc30: deregister unregistered
>> libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA
>> placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=17,
>> free_memkb=30611
>> libxl: detail: libxl_dom.c:182:numa_place_domain: NUMA placement
>> candidate with 1 nodes, 12 cpus and 30611 KB free selected
>> domainbuilder: detail: xc_dom_allocate: cmdline="(null)", features="(null)"
>> domainbuilder: detail: xc_dom_kernel_file:
>> filename="/opt/xen-test-framework/tests/selftest/test-hvm32-selftest"
>> domainbuilder: detail: xc_dom_malloc_filemap: 1090 kB
>> libxl: debug: libxl_dom.c:874:libxl__load_hvm_firmware_module: Loading
>> BIOS: /usr/libexec/xen/boot/bios.bin
>> libxl: error: libxl_dom.c:882:libxl__load_hvm_firmware_module: failed to
>> read BIOS file: No such file or directory
>>
>> In this case, tools have been built with ./configure --disable-seabios
>>
>> As a result, /usr/libexec/xen/boot/bios.bin (name altered a patch sent
>> separately) isn't built or installed.
>>
>> I think libxl needs to logic to determine which firmware to use based on
>> the available CONFIG_* options it was built with.
> I don' quite follow here.
>
> Do you mean if user hasn't specified any bios= option, (s)he gets
> whatever available?
>
> I think we should stick with the seabios-default behaviour to avoid
> surprising breakage.
>
> If you don't want any bois, maybe we should provide a bios=none option?

XenServer is built with ./configure --disable-seabios because we don't
use it (yet).  This means that SeaBIOS is not built, installed, or
available.

Because of this change, libxl unconditionally assumes the presence of
SeaBIOS, and tries to use the installed seabios binary.

>
>>> @@ -914,6 +951,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.system_firmware) {
>>> +bios_filename = info->u.hvm.system_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;
>> At the very least, these need to be guarded by #ifdef
>> CONFIG_{SEABIOS,OVMF}, as it is explicitly permitted for them not to be
>> present in a build.
>>
>>> +case LIBXL_BIOS_TYPE_ROMBIOS:
>> ROMBIOS certainly does function correctly with QEMU_XEN, and is how
>> XenServer is planning to start the migration from a qemu-trad world to a
>> qemu-upstream world.  Even if libxl doesn't want to formally support
>> such a configuration, it shouldn't be excluded.
>>
> There is no written statement, but I would rather not support this
> configuration.

Rightly or wrongly, it is already available, usable and working (until
this changeset), via supported configuration options.

> I expect this is an impossible situation to get into, since verification
> should have been done a few steps before -- hence the abort(3) here is
> justified. But I would need to double-check if that's not the case and
> will do something about it either here or at the place I see
> appropriate.
>
>>> +default:
>>> +abort();
>> This is completely antisocial.  Under no circumstances is it ok for a
>> library to call abort(); fail an assertion if necessary, but this is a
>> configuration error and should pass an error back to its caller, not
>> take the entire process with it.
>>
> In general it is ok to call abort(3) in an internal function that only
> expects valid input.

No.  It very much is not.

>  And I don't see how switching to assert(3) help in
> those cases, that ends up calling abort(3) anyway.

Re: [Xen-devel] [PATCH v2 0/2] hvmloader: fix two issues spotted by Coverity

[Wei Liu]

On Mon, Aug 22, 2016 at 01:47:51PM +0100, Wei Liu wrote:
> Wei Liu (2):
>   hvmloader: correctly copy signature to info structures
>   hvmloader: use bound checking in get_module_entry
> 

Pushed.

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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

On August 22, 2016 9:10 PM, Yang Zhang wrote:
>On 2016/8/22 20:04, Jan Beulich wrote:
> On 22.08.16 at 13:41,  wrote:
>>> On August 22, 2016 6:36 PM,  wrote:
>>> On 19.08.16 at 14:58,  wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
> 2001
> From: Quan Xu 
> Date: Fri, 19 Aug 2016 20:40:31 +0800
> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv
> issue
>
> When Xen apicv is enabled, wall clock time is faster on Windows7-32
> guest with high payload (with 2vCPU, captured from xentrace, in
> high payload, the count of IPI interrupt increases rapidly between these
>vCPUs).
>
> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
> 0xd1) are both pending (index of bit set in VIRR), unfortunately,
> the IPI intrrupt is high priority than periodic timer interrupt.
> Xen updates IPI interrupt bit set in VIRR to guest interrupt status
> (RVI) as a high priority and apicv (Virtual-Interrupt Delivery)
> delivers IPI interrupt within VMX non-root operation without a VM
> exit. Within VMX non-root operation, if periodic timer interrupt
> index of bit is set in VIRR and highest, the apicv delivers periodic timer
>interrupt within VMX non-root operation as well.
>
> But in current code, if Xen doesn't update periodic timer interrupt
> bit set in VIRR to guest interrupt status (RVI) directly, Xen is
> not aware of this case to decrease the count (pending_intr_nr) of
> pending periodic timer interrupt, then Xen will deliver a periodic
> timer interrupt again. The guest receives more periodic timer
> interrupt.
>
> If the periodic timer interrut is delivered and not the highest
> priority, make Xen be aware of this case to decrease the count of
> pending periodic timer interrupt.

 I can see the issue you're trying to address, but for one - doesn't
 this lead to other double accounting, namely once the pt irq becomes
 the highest priority one?

>>>
>>> It is does NOT lead to other double accounting..
>>> As if the pt irq becomes the highest priority one, the intack is pt one..
>>> Then:
>>>
>>>  +else
>>>  +pt_intr_post(v, intack);
>>
>> As just said in reply to Yang: If this is still the same interrupt
>> instance as in a prior run through here which took the if() branch,
>> this change looks like having the potential of double accounting.
>
>This cannot happen: if pt intr is the second priority one, then corresponding 
>vIRR
>bit will be cleared by hardware while the highest priority intr is delivered to
>guest. And the next vmx_intr_assit cannot aware of it since the vIRR bit is 
>zero.
>

I am afraid that this may happen.. as I mentioned as 2nd RFC reason, 

Within VMX non-root operation, an Asynchronous Enclave Exit (including external
interrupts, non-maskable interrupt system-management interrrupts, exceptions 
and VM exit)
may occur before delivery of a periodic timer interrupt, the pt bit of VIRR is 
still there...

but I will explain more why it doesn't have the potential of double accounting 
in current code in next email.

Quan


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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Yang Zhang]

On 2016/8/22 20:04, Jan Beulich wrote:

On 22.08.16 at 13:41,  wrote:

On August 22, 2016 6:36 PM,  wrote:

On 19.08.16 at 14:58,  wrote:

From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
From: Quan Xu 
Date: Fri, 19 Aug 2016 20:40:31 +0800
Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
with high payload (with 2vCPU, captured from xentrace, in high payload, the
count of IPI interrupt increases rapidly between these vCPUs).

If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
are both pending (index of bit set in VIRR), unfortunately, the IPI intrrupt
is high priority than periodic timer interrupt. Xen updates IPI interrupt bit
set in VIRR to guest interrupt status (RVI) as a high priority and apicv
(Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
operation without a VM exit. Within VMX non-root operation, if periodic timer
interrupt index of bit is set in VIRR and highest, the apicv delivers periodic
timer interrupt within VMX non-root operation as well.

But in current code, if Xen doesn't update periodic timer interrupt bit set
in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
case to decrease the count (pending_intr_nr) of pending periodic timer
interrupt,
then Xen will deliver a periodic timer interrupt again. The guest receives
more
periodic timer interrupt.

If the periodic timer interrut is delivered and not the highest priority, make
Xen be aware of this case to decrease the count of pending periodic timer
interrupt.


I can see the issue you're trying to address, but for one - doesn't
this lead to other double accounting, namely once the pt irq becomes
the highest priority one?



It is does NOT lead to other double accounting..
As if the pt irq becomes the highest priority one, the intack is pt one..
Then:

 +else
 +pt_intr_post(v, intack);


As just said in reply to Yang: If this is still the same interrupt instance
as in a prior run through here which took the if() branch, this change
looks like having the potential of double accounting.


This cannot happen: if pt intr is the second priority one, then 
corresponding vIRR bit will be cleared by hardware while the highest 
priority intr is delivered to guest. And the next vmx_intr_assit cannot 
aware of it since the vIRR bit is zero.


--
Yang
Alibaba Cloud Computing

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

Re: [Xen-devel] [PATCH v2 1/2] hvmloader: correctly copy signature to info structures

[Jan Beulich]

>>> On 22.08.16 at 14:47,  wrote:
> The original code used sizeof(info->signature) as the size parameter for
> memcpy, which was wrong.
> 
> Fix that by using structure assignment.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2 2/2] hvmloader: use bound checking in get_module_entry

[Jan Beulich]

>>> On 22.08.16 at 14:47,  wrote:
> Coverity complains:
> 
> overflow_before_widen: Potentially overflowing expression
> info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is
> evaluated using 32-bit arithmetic, and then used in a context that
> expects an expression of type uint64_t (64 bits, unsigned).
> 
> The overflow is unlikely to happen in reality because we only expect a
> few modules.
> 
> Fix that by converting the check to use bound checking to placate
> Coverity.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

[Xen-devel] [PATCH v2 1/2] hvmloader: correctly copy signature to info structures

[Wei Liu]

The original code used sizeof(info->signature) as the size parameter for
memcpy, which was wrong.

Fix that by using structure assignment.

Signed-off-by: Wei Liu 
---
 tools/firmware/hvmloader/ovmf.c| 8 
 tools/firmware/hvmloader/seabios.c | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index b4bcc93..0ac3416 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -68,10 +68,10 @@ static void ovmf_setup_bios_info(void)
 {
 struct ovmf_info *info = (void *)OVMF_INFO_PHYSICAL_ADDRESS;
 
-memset(info, 0, sizeof(*info));
-
-memcpy(info->signature, "XenHVMOVMF", sizeof(info->signature));
-info->length = sizeof(*info);
+*info = (struct ovmf_info) {
+.signature = "XenHVMOVMF",
+.length = sizeof(*info)
+};
 }
 
 static void ovmf_finish_bios_info(void)
diff --git a/tools/firmware/hvmloader/seabios.c 
b/tools/firmware/hvmloader/seabios.c
index 5c9a351..44ff0d7 100644
--- a/tools/firmware/hvmloader/seabios.c
+++ b/tools/firmware/hvmloader/seabios.c
@@ -56,10 +56,10 @@ static void seabios_setup_bios_info(void)
 {
 struct seabios_info *info = (void *)BIOS_INFO_PHYSICAL_ADDRESS;
 
-memset(info, 0, sizeof(*info));
-
-memcpy(info->signature, "XenHVMSeaBIOS", sizeof(info->signature));
-info->length = sizeof(*info);
+*info = (struct seabios_info) {
+.signature = "XenHVMSeaBIOS",
+.length = sizeof(*info)
+};
 
 info->tables = (uint32_t)scratch_alloc(MAX_TABLES*sizeof(uint32_t), 0);
 }
-- 
2.1.4


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

[Xen-devel] [PATCH v2 2/2] hvmloader: use bound checking in get_module_entry

[Wei Liu]

Coverity complains:

overflow_before_widen: Potentially overflowing expression
info->nr_modules * 32U with type unsigned int (32 bits, unsigned) is
evaluated using 32-bit arithmetic, and then used in a context that
expects an expression of type uint64_t (64 bits, unsigned).

The overflow is unlikely to happen in reality because we only expect a
few modules.

Fix that by converting the check to use bound checking to placate
Coverity.

Signed-off-by: Wei Liu 
---
 tools/firmware/hvmloader/hvmloader.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/hvmloader/hvmloader.c 
b/tools/firmware/hvmloader/hvmloader.c
index 7b32d86..bbd4e34 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -272,8 +272,8 @@ const struct hvm_modlist_entry *get_module_entry(
 
 if ( !modlist ||
  info->modlist_paddr > UINTPTR_MAX ||
- (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
-> UINTPTR_MAX )
+ (UINTPTR_MAX - (uintptr_t)info->modlist_paddr) / sizeof(*modlist)
+ < info->nr_modules )
 return NULL;
 
 for ( i = 0; i < info->nr_modules; i++ )
-- 
2.1.4


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

[Xen-devel] [PATCH v2 0/2] hvmloader: fix two issues spotted by Coverity

[Wei Liu]

Wei Liu (2):
  hvmloader: correctly copy signature to info structures
  hvmloader: use bound checking in get_module_entry

 tools/firmware/hvmloader/hvmloader.c | 4 ++--
 tools/firmware/hvmloader/ovmf.c  | 8 
 tools/firmware/hvmloader/seabios.c   | 8 
 3 files changed, 10 insertions(+), 10 deletions(-)

-- 
2.1.4


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

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault

[Kevin.Mayer]

Hi

The reproduction should be pretty simple:

Apply the patch to enable altp2m unconditionally:
 d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
 d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_REASON] = SHUTDOWN_reboot;
+d->arch.hvm_domain.params[HVM_PARAM_ALTP2M] = 1;
+
 vpic_init(d);
 rc = vioapic_init(d);

For the guest we use one state file ( Windows 10 ) from which the guests are 
restored with libvirt.
Simply restore and destroy several guests (5-7 in our current setup) in fast 
succession (every guest has about 1-2minutes runtime).
The amount of guest-VMs seems to correlate with the time until the crash 
occurs, but other, random factors seem to be more important.
More VMs => the crash happens faster.


Is the following debug-setup possible?
L0: Xen / VMWare
L1: Xen with altp2m enabled
L2: Several guest-VMs being constantly restored / destroyed

Then periodically take snapshots until the hypervisor panics and try to debug 
from the latest snapshot on.

> -Ursprüngliche Nachricht-
> Von: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Gesendet: Montag, 22. August 2016 13:58
> An: Mayer, Kevin ; jbeul...@suse.com
> Cc: xen-devel@lists.xen.org
> Betreff: Re: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
> 
> On 19/08/16 11:01, kevin.ma...@gdata.de wrote:
> > Hi
> >
> > I took another look at Xen and a new crashdump.
> > The last successful __vmwrite should be in static void
> > vmx_vcpu_update_vmfunc_ve(struct vcpu *v) [...]
> > __vmwrite(SECONDARY_VM_EXEC_CONTROL,
> >   v->arch.hvm_vmx.secondary_exec_control);
> > [...]
> > After this the altp2m_vcpu_destroy wakes up the vcpu and is then
> finished.
> >
> > In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can
> overwritten (but is not reached in our case as far as I can see):
> > if ( nvcpu->nv_n1vmcx )
> > v->arch.hvm_vmx.vmcs = nvcpu->nv_n1vmcx;
> >
> > In conclusion:
> > When destroying a domain the altp2m_vcpu_destroy(v); path seems to
> mess up the vmcs which ( only ) sometimes leads to a failed __vmwrite in
> vmx_fpu_leave.
> > That is as far as I can get with my understanding of the Xen code.
> >
> > Do you guys have any additional ideas what I could test / analyse?
> 
> Do you have easy reproduction instructions you could share?  Sadly, this is
> looking like an issue which isn't viable to debug over email.
> 
> ~Andrew

Virus checked by G Data MailSecurity
Version: AVA 25.7981 dated 22.08.2016
Virus news: www.antiviruslab.com

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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Jan Beulich]

>>> On 22.08.16 at 13:41,  wrote:
> On August 22, 2016 6:36 PM,  wrote:
> On 19.08.16 at 14:58,  wrote:
>>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
>>> From: Quan Xu 
>>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
>>>
>>> When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
>>> with high payload (with 2vCPU, captured from xentrace, in high payload, the
>>> count of IPI interrupt increases rapidly between these vCPUs).
>>>
>>> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
>>> are both pending (index of bit set in VIRR), unfortunately, the IPI intrrupt
>>> is high priority than periodic timer interrupt. Xen updates IPI interrupt 
>>> bit
>>> set in VIRR to guest interrupt status (RVI) as a high priority and apicv
>>> (Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
>>> operation without a VM exit. Within VMX non-root operation, if periodic 
>>> timer
>>> interrupt index of bit is set in VIRR and highest, the apicv delivers 
>>> periodic
>>> timer interrupt within VMX non-root operation as well.
>>>
>>> But in current code, if Xen doesn't update periodic timer interrupt bit set
>>> in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
>>> case to decrease the count (pending_intr_nr) of pending periodic timer
>>> interrupt,
>>> then Xen will deliver a periodic timer interrupt again. The guest receives
>>> more
>>> periodic timer interrupt.
>>>
>>> If the periodic timer interrut is delivered and not the highest priority, 
>>> make
>>> Xen be aware of this case to decrease the count of pending periodic timer
>>> interrupt.
>>
>>I can see the issue you're trying to address, but for one - doesn't
>>this lead to other double accounting, namely once the pt irq becomes
>>the highest priority one?
>>
> 
> It is does NOT lead to other double accounting..
> As if the pt irq becomes the highest priority one, the intack is pt one..
> Then:
> 
>  +else
>  +pt_intr_post(v, intack);

As just said in reply to Yang: If this is still the same interrupt instance
as in a prior run through here which took the if() branch, this change
looks like having the potential of double accounting.

>>Plus the change above is in no way apicv specific, so I'd also like to
>>see clarification why this change is valid (i.e. at least not making
>>things worse) even without apicv in use.
>>
> 
> __iiuc__, it is apicv specific, as these change is under condition 
> 'cpu_has_vmx_virtual_intr_delivery' (Virtual Interrupt Delivery is one of 
> apicv features) as below:
> 
> if ( cpu_has_vmx_virtual_intr_delivery ...) {  ___change___ }

Indeed, as already said in reply to Yang, I apparently didn't look
closely enough. I'm sorry for the noise.

Jan


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

Re: [Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

[Jan Beulich]

>>> On 22.08.16 at 13:37,  wrote:
> On Fri, Aug 19, 2016 at 06:00:12AM -0600, Jan Beulich wrote:
>> >>> On 19.08.16 at 12:09,  wrote:
>> > On 19/08/16 09:31, Jan Beulich wrote:
>> > On 19.08.16 at 10:06,  wrote:
>> >>> --- a/tools/firmware/hvmloader/hvmloader.c
>> >>> +++ b/tools/firmware/hvmloader/hvmloader.c
>> >>> @@ -272,8 +272,8 @@ const struct hvm_modlist_entry *get_module_entry(
>> >>>  
>> >>>  if ( !modlist ||
>> >>>   info->modlist_paddr > UINTPTR_MAX ||
>> >>> - (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
>> >>> -> UINTPTR_MAX )
>> >>> + (info->modlist_paddr +
>> >>> +  (uint64_t)info->nr_modules * sizeof(*modlist) - 1) > 
>> >>> UINTPTR_MAX )
>> >>>  return NULL;
>> >> This can be had without resorting to 64-bit multiplication, by bounds
>> >> checking
>> >>
>> >>  (UINTPTR_MAX - (uintptr_t)info->modlist_paddr) / sizeof(*modlist)
>> >>
>> >> instead. While we would certainly hope that compilers don't resort
>> >> to a libgcc helper for 64-bit multiplication, I think we'd better avoid
>> >> that risk altogether.
>> > 
>> > In this case, using libgcc would cause a link error because of
>> > -fno-builtin, so I don't think it is too bad.
>> 
>> And it's this link error which I want to avoid.
> 
> What approach should I use? I would like to clear this minor issue as
> quick as possible.

Well, if Andrew wants to ack the patch with the above unchanged, I
won't object. I continue to prefer the suggested alternative though.

Jan


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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Jan Beulich]

>>> On 22.08.16 at 13:40,  wrote:
> On 2016/8/22 18:35, Jan Beulich wrote:
> On 19.08.16 at 14:58,  wrote:
>>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
>>> From: Quan Xu 
>>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
>>>
>>> When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
>>> with high payload (with 2vCPU, captured from xentrace, in high payload, the
>>> count of IPI interrupt increases rapidly between these vCPUs).
>>>
>>> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
>>> are both pending (index of bit set in VIRR), unfortunately, the IPI intrrupt
>>> is high priority than periodic timer interrupt. Xen updates IPI interrupt 
>>> bit
>>> set in VIRR to guest interrupt status (RVI) as a high priority and apicv
>>> (Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
>>> operation without a VM exit. Within VMX non-root operation, if periodic 
>>> timer
>>> interrupt index of bit is set in VIRR and highest, the apicv delivers 
>>> periodic
>>> timer interrupt within VMX non-root operation as well.
>>>
>>> But in current code, if Xen doesn't update periodic timer interrupt bit set
>>> in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
>>> case to decrease the count (pending_intr_nr) of pending periodic timer 
>>> interrupt,
>>> then Xen will deliver a periodic timer interrupt again. The guest receives 
>>> more
>>> periodic timer interrupt.
>>>
>>> If the periodic timer interrut is delivered and not the highest priority, 
>>> make
>>> Xen be aware of this case to decrease the count of pending periodic timer
>>> interrupt.
>>
>> I can see the issue you're trying to address, but for one - doesn't
>> this lead to other double accounting, namely once the pt irq becomes
>> the highest priority one?
> 
> "intack.vector > pt_vector"
> I think above check in code can avoid the double accounting problem. It 
> recalculate pending timer interrupt only when the highest priority 
> interrupt is not timer.

I don't understand: When the pt one is highest priority, surely
recalculation is also needed. I'm not talking about a problem in
the case where the conditional is true, but about a possible
subsequent run through vmx_intr_assist() when the previous
higher priority interrupt has got handled, but the pt one (now
being highest) is still pending. (Or similarly consider the case
where on the next run through vmx_intr_assist() another higher
priority interrupts appeared.)

I'm not saying the change is wrong, I'm merely asking for further
proof that it doesn't open up new issues.

>>> --- a/xen/arch/x86/hvm/vmx/intr.c
>>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>>> @@ -334,7 +334,21 @@ void vmx_intr_assist(void)
>>>  __vmwrite(EOI_EXIT_BITMAP(i), 
>>> v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>>>  }
>>>
>>> -pt_intr_post(v, intack);
>>> +   /*
>>> +* If the periodic timer interrut is delivered and not the highest 
>>> priority,
>>> +* make Xen be aware of this case to decrease the count of pending 
>>> periodic
>>> +* timer interrupt.
>>> +*/
>>> +if ( pt_vector != -1 && intack.vector > pt_vector )
>>> +{
>>> +struct hvm_intack pt_intack;
>>> +
>>> +pt_intack.vector = pt_vector;
>>> +pt_intack.source = hvm_intsrc_lapic;
>>> +pt_intr_post(v, pt_intack);
>>> +}
>>> +else
>>> +pt_intr_post(v, intack);
>>
>> And then I'm having two problems with this change: Processing other
>> than the highest priority irq here looks to be non-architectural. From
>> looking over pt_intr_post() there's only pt related accounting and no
>> actual interrupt handling there, but I'd like this to be (a) confirmed
>> and (b) called out in the comment.
>>
>> Plus the change above is in no way apicv specific, so I'd also like to
>> see clarification why this change is valid (i.e. at least not making
>> things worse) even without apicv in use.
> 
> It is apicv specific case. Above code will execute only when cpu has 
> virtual interrupt delivery which is part of apicv feature.

Ah, right, I didn't look closely enough what conditional this is
inside of.

Jan

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

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault

[Andrew Cooper]

On 19/08/16 11:01, kevin.ma...@gdata.de wrote:
> Hi
>
> I took another look at Xen and a new crashdump.
> The last successful __vmwrite should be in 
> static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
> [...]
> __vmwrite(SECONDARY_VM_EXEC_CONTROL,
>   v->arch.hvm_vmx.secondary_exec_control);
> [...]
> After this the altp2m_vcpu_destroy wakes up the vcpu and is then finished.
>
> In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can overwritten (but 
> is not reached in our case as far as I can see):
> if ( nvcpu->nv_n1vmcx )
> v->arch.hvm_vmx.vmcs = nvcpu->nv_n1vmcx;
>
> In conclusion:
> When destroying a domain the altp2m_vcpu_destroy(v); path seems to mess up 
> the vmcs which ( only ) sometimes leads to a failed __vmwrite in 
> vmx_fpu_leave.
> That is as far as I can get with my understanding of the Xen code.
>
> Do you guys have any additional ideas what I could test / analyse?

Do you have easy reproduction instructions you could share?  Sadly, this
is looking like an issue which isn't viable to debug over email.

~Andrew

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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

On August 22, 2016 7:40 PM, Yang Zhang wrote:
>On 2016/8/22 18:35, Jan Beulich wrote:
> On 19.08.16 at 14:58,  wrote:
>>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00
>>> 2001
>>> From: Quan Xu 
>>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv
>>> issue
>>>
>>> When Xen apicv is enabled, wall clock time is faster on Windows7-32
>>> guest with high payload (with 2vCPU, captured from xentrace, in high
>>> payload, the count of IPI interrupt increases rapidly between these vCPUs).
>>>
>>> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
>>> 0xd1) are both pending (index of bit set in VIRR), unfortunately, the
>>> IPI intrrupt is high priority than periodic timer interrupt. Xen
>>> updates IPI interrupt bit set in VIRR to guest interrupt status (RVI)
>>> as a high priority and apicv (Virtual-Interrupt Delivery) delivers
>>> IPI interrupt within VMX non-root operation without a VM exit. Within
>>> VMX non-root operation, if periodic timer interrupt index of bit is
>>> set in VIRR and highest, the apicv delivers periodic timer interrupt within
>VMX non-root operation as well.
>>>
>>> But in current code, if Xen doesn't update periodic timer interrupt
>>> bit set in VIRR to guest interrupt status (RVI) directly, Xen is not
>>> aware of this case to decrease the count (pending_intr_nr) of pending
>>> periodic timer interrupt, then Xen will deliver a periodic timer
>>> interrupt again. The guest receives more periodic timer interrupt.
>>>
>>> If the periodic timer interrut is delivered and not the highest
>>> priority, make Xen be aware of this case to decrease the count of
>>> pending periodic timer interrupt.
>>
>> I can see the issue you're trying to address, but for one - doesn't
>> this lead to other double accounting, namely once the pt irq becomes
>> the highest priority one?
>
>"intack.vector > pt_vector"
>I think above check in code can avoid the double accounting problem. It
>recalculate pending timer interrupt only when the highest priority interrupt is
>not timer.
>

Yes, 

>>
>>> --- a/xen/arch/x86/hvm/vmx/intr.c
>>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>>> @@ -334,7 +334,21 @@ void vmx_intr_assist(void)
>>>  __vmwrite(EOI_EXIT_BITMAP(i),
>v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>>>  }
>>>
>>> -pt_intr_post(v, intack);
>>> +   /*
>>> +* If the periodic timer interrut is delivered and not the highest
>priority,
>>> +* make Xen be aware of this case to decrease the count of
>pending periodic
>>> +* timer interrupt.
>>> +*/
>>> +if ( pt_vector != -1 && intack.vector > pt_vector )
>>> +{
>>> +struct hvm_intack pt_intack;
>>> +
>>> +pt_intack.vector = pt_vector;
>>> +pt_intack.source = hvm_intsrc_lapic;
>>> +pt_intr_post(v, pt_intack);
>>> +}
>>> +else
>>> +pt_intr_post(v, intack);
>>
>> And then I'm having two problems with this change: Processing other
>> than the highest priority irq here looks to be non-architectural. From
>> looking over pt_intr_post() there's only pt related accounting and no
>> actual interrupt handling there, but I'd like this to be (a) confirmed
>> and (b) called out in the comment.
>>
>> Plus the change above is in no way apicv specific, so I'd also like to
>> see clarification why this change is valid (i.e. at least not making
>> things worse) even without apicv in use.
>
>It is apicv specific case. Above code will execute only when cpu has
>virtual interrupt delivery which is part of apicv feature.
>

Yes, I think so too. Thanks for your clarification!!

Quan


>>
>> And of course in any event VMX maintainer feedback is going to be
>> needed here.
>>
>> Jan
>>
>
>
>--
>Yang
>Alibaba Cloud Computing

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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

On August 22, 2016 6:36 PM,  wrote:
 On 19.08.16 at 14:58,  wrote:
>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
>> From: Quan Xu 
>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
>>
>> When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
>> with high payload (with 2vCPU, captured from xentrace, in high payload, the
>> count of IPI interrupt increases rapidly between these vCPUs).
>>
>> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
>> are both pending (index of bit set in VIRR), unfortunately, the IPI intrrupt
>> is high priority than periodic timer interrupt. Xen updates IPI interrupt bit
>> set in VIRR to guest interrupt status (RVI) as a high priority and apicv
>> (Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
>> operation without a VM exit. Within VMX non-root operation, if periodic timer
>> interrupt index of bit is set in VIRR and highest, the apicv delivers 
>> periodic
>> timer interrupt within VMX non-root operation as well.
>>
>> But in current code, if Xen doesn't update periodic timer interrupt bit set
>> in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
>> case to decrease the count (pending_intr_nr) of pending periodic timer
>> interrupt,
>> then Xen will deliver a periodic timer interrupt again. The guest receives
>> more
>> periodic timer interrupt.
>>
>> If the periodic timer interrut is delivered and not the highest priority, 
>> make
>> Xen be aware of this case to decrease the count of pending periodic timer
>> interrupt.
>
>I can see the issue you're trying to address, but for one - doesn't
>this lead to other double accounting, namely once the pt irq becomes
>the highest priority one?
>

It is does NOT lead to other double accounting..
As if the pt irq becomes the highest priority one, the intack is pt one..
Then:

 +else
 +pt_intr_post(v, intack);


>> --- a/xen/arch/x86/hvm/vmx/intr.c
>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>> @@ -334,7 +334,21 @@ void vmx_intr_assist(void)
>>  __vmwrite(EOI_EXIT_BITMAP(i),
>> v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>>  }
>>
>> -pt_intr_post(v, intack);
>> +   /*
>> +* If the periodic timer interrut is delivered and not the highest
>> priority,
>> +* make Xen be aware of this case to decrease the count of pending
>> periodic
>> +* timer interrupt.
>> +*/
>> +if ( pt_vector != -1 && intack.vector > pt_vector )
>> +{
>> +struct hvm_intack pt_intack;
>> +
>> +pt_intack.vector = pt_vector;
>> +pt_intack.source = hvm_intsrc_lapic;
>> +pt_intr_post(v, pt_intack);
>> +}
>> +else
>> +pt_intr_post(v, intack);
>
>And then I'm having two problems with this change: Processing other
>than the highest priority irq here looks to be non-architectural. From
>looking over pt_intr_post() there's only pt related accounting and no
>actual interrupt handling there, but I'd like this to be
> (a) confirmed

To me, YES.. but I hope Kevin could confirm it again.

>and (b) called out in the comment.

Agreed. Good idea.

>
>Plus the change above is in no way apicv specific, so I'd also like to
>see clarification why this change is valid (i.e. at least not making
>things worse) even without apicv in use.
>

__iiuc__, it is apicv specific, as these change is under condition 
'cpu_has_vmx_virtual_intr_delivery' (Virtual Interrupt Delivery is one of apicv 
features) as below:

if ( cpu_has_vmx_virtual_intr_delivery ...) {  ___change___ }
 



>And of course in any event VMX maintainer feedback is going to be
>needed here.


Thanks for your comments!!
Quan

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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Yang Zhang]

On 2016/8/22 18:35, Jan Beulich wrote:

On 19.08.16 at 14:58,  wrote:

From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
From: Quan Xu 
Date: Fri, 19 Aug 2016 20:40:31 +0800
Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
with high payload (with 2vCPU, captured from xentrace, in high payload, the
count of IPI interrupt increases rapidly between these vCPUs).

If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
are both pending (index of bit set in VIRR), unfortunately, the IPI intrrupt
is high priority than periodic timer interrupt. Xen updates IPI interrupt bit
set in VIRR to guest interrupt status (RVI) as a high priority and apicv
(Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
operation without a VM exit. Within VMX non-root operation, if periodic timer
interrupt index of bit is set in VIRR and highest, the apicv delivers periodic
timer interrupt within VMX non-root operation as well.

But in current code, if Xen doesn't update periodic timer interrupt bit set
in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
case to decrease the count (pending_intr_nr) of pending periodic timer 
interrupt,
then Xen will deliver a periodic timer interrupt again. The guest receives more
periodic timer interrupt.

If the periodic timer interrut is delivered and not the highest priority, make
Xen be aware of this case to decrease the count of pending periodic timer
interrupt.


I can see the issue you're trying to address, but for one - doesn't
this lead to other double accounting, namely once the pt irq becomes
the highest priority one?


"intack.vector > pt_vector"
I think above check in code can avoid the double accounting problem. It 
recalculate pending timer interrupt only when the highest priority 
interrupt is not timer.





--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -334,7 +334,21 @@ void vmx_intr_assist(void)
 __vmwrite(EOI_EXIT_BITMAP(i), v->arch.hvm_vmx.eoi_exit_bitmap[i]);
 }

-pt_intr_post(v, intack);
+   /*
+* If the periodic timer interrut is delivered and not the highest 
priority,
+* make Xen be aware of this case to decrease the count of pending 
periodic
+* timer interrupt.
+*/
+if ( pt_vector != -1 && intack.vector > pt_vector )
+{
+struct hvm_intack pt_intack;
+
+pt_intack.vector = pt_vector;
+pt_intack.source = hvm_intsrc_lapic;
+pt_intr_post(v, pt_intack);
+}
+else
+pt_intr_post(v, intack);


And then I'm having two problems with this change: Processing other
than the highest priority irq here looks to be non-architectural. From
looking over pt_intr_post() there's only pt related accounting and no
actual interrupt handling there, but I'd like this to be (a) confirmed
and (b) called out in the comment.

Plus the change above is in no way apicv specific, so I'd also like to
see clarification why this change is valid (i.e. at least not making
things worse) even without apicv in use.


It is apicv specific case. Above code will execute only when cpu has 
virtual interrupt delivery which is part of apicv feature.




And of course in any event VMX maintainer feedback is going to be
needed here.

Jan




--
Yang
Alibaba Cloud Computing

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

Re: [Xen-devel] check if a page is modified

[sepanta s]

I use xen-access to trace the paegs which are accessed to be wrtitten but
when I print out the page content immediately after getting the event in
xen-access,
its content is unchanged .
What should I do??

On Sat, Aug 20, 2016 at 5:13 PM, sepanta s  wrote:

> Hi,
> How can I check if a page is dirty or not in xen source code?
> I am debugging the hvm_hap_nested_page_fault function in hvm.c and want to
> see when a page  fault occurs, see what is written on
> the page.
> Does the page_mark_dirty makes a page dirty or not?
>
> Regards,
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] hvmloader: cast to 64bit before multiplication in get_module_entry

[Wei Liu]

On Fri, Aug 19, 2016 at 06:00:12AM -0600, Jan Beulich wrote:
> >>> On 19.08.16 at 12:09,  wrote:
> > On 19/08/16 09:31, Jan Beulich wrote:
> > On 19.08.16 at 10:06,  wrote:
> >>> --- a/tools/firmware/hvmloader/hvmloader.c
> >>> +++ b/tools/firmware/hvmloader/hvmloader.c
> >>> @@ -272,8 +272,8 @@ const struct hvm_modlist_entry *get_module_entry(
> >>>  
> >>>  if ( !modlist ||
> >>>   info->modlist_paddr > UINTPTR_MAX ||
> >>> - (info->modlist_paddr + info->nr_modules * sizeof(*modlist) - 1)
> >>> -> UINTPTR_MAX )
> >>> + (info->modlist_paddr +
> >>> +  (uint64_t)info->nr_modules * sizeof(*modlist) - 1) > 
> >>> UINTPTR_MAX )
> >>>  return NULL;
> >> This can be had without resorting to 64-bit multiplication, by bounds
> >> checking
> >>
> >>  (UINTPTR_MAX - (uintptr_t)info->modlist_paddr) / sizeof(*modlist)
> >>
> >> instead. While we would certainly hope that compilers don't resort
> >> to a libgcc helper for 64-bit multiplication, I think we'd better avoid
> >> that risk altogether.
> > 
> > In this case, using libgcc would cause a link error because of
> > -fno-builtin, so I don't think it is too bad.
> 
> And it's this link error which I want to avoid.
> 

What approach should I use? I would like to clear this minor issue as
quick as possible.

Wei.

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

Re: [Xen-devel] [PATCH v4] x86/cpuid: AVX-512 Feature Detection

[Jan Beulich]

>>> On 22.08.16 at 13:22,  wrote:
>> > >> First of all - please don't top post.
>> > >>
>> > >>> What about remove the dependency between AVX2 and AVX512F
>> >  ( AVX2:
>> > >> [AVX512F], ) ?
>> > >>
>> > >> Yes, that's what I think we want, but we need Andrew's 
>> > >> agreement here.
>> > >>
>> > > Hi Andrew,  what is your opinion ?
>> >  You are in a better position to answer than me.
>> > 
>> >  For a specific instruction which may be VEX and EVEX encoded,
>> >  is the circuitry for a specific instruction shared, or
>> >  discrete?  Is there a plausible future where you might
>> >  support only the EVEX variant of an instruction, and not the VEX 
>> >  variant?
>> > 
>> >  These dependences are about what may be reasonably assumed
>> >  about the way the environment is structured.  It doesn't look
>> >  reasonable to advertise an AVX512 environment to guests while
>> >  at the same time stating that AVX2 is not present.  If this
>> >  is correct, then the dependency
>> > > should stay.
>> >  If Intel plausibly things it might release hardware with
>> >  !AVX2 but AVX512, then the dependency should be dropped.
>> > >>> Regarding the dependency between AVX2 and AVX512F, I have ask
>> > >>> some hardware
>> > > architecture engineer.
>> > >>> AVX512 is a superset of AVX2, the most important item being
>> > >>> the state. If
>> > > the state for AVX2 isn't enabled (in XCR0), then AVX512
>> > >> also can't function.
>> > >>> So if we want to use AVX512, AVX2 must be supported and enabled.
>> > >>> The
>> > > dependence between AVX512F and AVX2 may need be
>> > >> reserved.
>> > >>
>> > >> Ok, so AVX512 strictly depends on AVX2.
>> > >>
>> > >> In which case, the python code was correct.  The meaning of the
>> > >> key/value
>> > > relationship is "if the feature in the key is not present, all
>> > >> features in the value must also be disabled".
>> > > Hi jan, what is your opinion?
>> >  There's no opinion to be had here, according to your earlier reply.
>> >  I do,
>> > >>> however, continue to question that model: State and
>> >  instruction set are independent items. Of course YMM state is a
>> >  prereq to
>> > >>> ZMM state, but I do not buy AVX2 insn support being a
>> >  prereq to AVX-512 insns. Yet to me the AVX2 and AVX-512F feature
>> >  flags solely
>> > >>> represent the instructions, while the XSTATE leaf bits
>> >  represent the states.
>> > 
>> > >>> Hi jan,
>> > >>> I get some information from hardware colleague.  There is no
>> > >>> dependence about AVX512 instructions and AVX2 instructions. It is
>> > >>> also not states in
>> > > the
>> > >>> official document.
>> > >> As I had assumed.
>> > >>
>> > >>>But I want to know the meaning of the dependence "AVX2:
>> > >>> [AVX512F]"  in "gen-cpuid.py" file.
>> > >>>If it is the feature dependence, I think the dependence between
>> > >>> AVX512 and AVX2  may need to add. As we talk before, Zmm is part of 
>> > >>> AVX512 
> feature.
>> > >
>> > >>> If the state for AVX2 isn't enabled (in XCR0), then AVX512 also
>> > >>> can't function. Apart from that, there is no processors with
>> > >>> AVX512 without AVX2 currently and it is safe to treat AVX2 as part
>> > >>> of the thermometer leading to
>> > >
>> > >>> AVX512. Regarding if will have a cpu support avx512 without avx2
>> > >>> in future, it is really hard to say.
>> > >>> If it is the instructions dependence, I have no idea to delete
>> > >>> this dependence in "gen-cpuid.py" file.
>> > >>> So, I want to know your advice.
>> > >> Well, the main issue here is that we have no feature flag
>> > >> representation for the xstate bits. If we had, the relevant parts
>> > >> of the dependencies should look like
>> > >>
>> > >> XSTATE_YMM: [AVX, XSTATE_ZMM]
>> > >> AVX: [AVX2]
>> > >> XSTATE_ZMM: [AVX512F]
>> > >> AVX512F: [AVX512CD, ...]
>> > >>
>> > >> But in their absence I guess keeping the AVX2 dependency as you
>> > >> have it is the only reasonable approach. Just that I'd like it to
>> > >> be accompanied by a comment explaining that this isn't the actual
>> > >> dependency (so that if XSTATE feature flags got introduced later,
>> > >> it would be clear how to adjust those parts).
>> > >>
>> > >> Andrew - I keep forgetting why you think having such XSTATE_*
>> > >> feature flags is not appropriate.
>> > >
>> > > This is all about providing a plausible cpuid layout to a guest.
>> > >
>> > > It is not plausible that we will ever see a processor with e.g.
>> > > AVX512F but not XSTATE_ZMM.
>> >
>> > This is a somewhat bogus argument considering we have
>> >
>> > FXSR: [FFXSR, SSE],
>> >
>> > which, as you 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8866d337ea9eba258e942585b172d57d39376e70
baseline version:
 ovmf d36447418d32d82c4d1033ffcf5cb6244031ac9f

Last test of basis   100579  2016-08-22 07:14:26 Z0 days
Testing same since   100580  2016-08-22 09:44:26 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Liming 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 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=8866d337ea9eba258e942585b172d57d39376e70
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
8866d337ea9eba258e942585b172d57d39376e70
+ branch=ovmf
+ revision=8866d337ea9eba258e942585b172d57d39376e70
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x8866d337ea9eba258e942585b172d57d39376e70 = 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 

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Xuquan (Euler)]

On August 22, 2016 5:38 PM, Yang Zhang wrote:
>On 2016/8/19 20:58, Xuquan (Euler) wrote:
>> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
>> From: Quan Xu 
>> Date: Fri, 19 Aug 2016 20:40:31 +0800
>> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
>>
>> When Xen apicv is enabled, wall clock time is faster on Windows7-32
>> guest with high payload (with 2vCPU, captured from xentrace, in high
>> payload, the count of IPI interrupt increases rapidly between these vCPUs).
>>
>> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector
>> 0xd1) are both pending (index of bit set in VIRR), unfortunately, the
>> IPI intrrupt is high priority than periodic timer interrupt. Xen
>> updates IPI interrupt bit set in VIRR to guest interrupt status (RVI)
>> as a high priority and apicv (Virtual-Interrupt Delivery) delivers IPI
>> interrupt within VMX non-root operation without a VM exit. Within VMX
>> non-root operation, if periodic timer interrupt index of bit is set in
>> VIRR and highest, the apicv delivers periodic timer interrupt within VMX 
>> non-root operation as well.
>>
>> But in current code, if Xen doesn't update periodic timer interrupt
>> bit set in VIRR to guest interrupt status (RVI) directly, Xen is not
>> aware of this case to decrease the count (pending_intr_nr) of pending
>> periodic timer interrupt, then Xen will deliver a periodic timer
>> interrupt again. The guest receives more periodic timer interrupt.
>>
>> If the periodic timer interrut is delivered and not the highest
>> priority, make Xen be aware of this case to decrease the count of
>> pending periodic timer interrupt.
>
>Nice catch!
>
>>
>> Signed-off-by: Yifei Jiang 
>> Signed-off-by: Rongguang He 
>> Signed-off-by: Quan Xu 
>> ---
>> Why RFC:
>> 1. I am not quite sure for other cases, such as nested case.
>
>We don't support the nested APICv now. So it is ok for this patch.
>
>> 2. Within VMX non-root operation, an Asynchronous Enclave Exit (including 
>> external
>>interrupts, non-maskable interrupt system-management interrrupts, 
>> exceptions
>>and VM exit) may occur before delivery of a periodic timer interrupt, the 
>> periodic
>>timer interrupt may be lost when a coming periodic timer interrupt is 
>> delivered.
>>Actually, and so current code is.
>
>I think you mean the combination not interrupt lost. It should be ok since it 
>happens rarely and even native OS will encounter the same problem if it 
>disable the interrupt for too long.
>

Yes, it is 'combination'.

>> ---
>>  xen/arch/x86/hvm/vmx/intr.c | 16 +++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
>> index 8fca08c..d3a034e 100644
>> --- a/xen/arch/x86/hvm/vmx/intr.c
>> +++ b/xen/arch/x86/hvm/vmx/intr.c
>> @@ -334,7 +334,21 @@ void vmx_intr_assist(void)
>>  __vmwrite(EOI_EXIT_BITMAP(i), 
>> v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>>  }
>>
>> -pt_intr_post(v, intack);
>> +   /*
>> +* If the periodic timer interrut is delivered and not the highest 
>> priority,
>> +* make Xen be aware of this case to decrease the count of pending 
>> periodic
>> +* timer interrupt.
>> +*/
>> +if ( pt_vector != -1 && intack.vector > pt_vector )
>> +{
>> +struct hvm_intack pt_intack;
>> +
>> +pt_intack.vector = pt_vector;
>> +pt_intack.source = hvm_intsrc_lapic;
>> +pt_intr_post(v, pt_intack);
>> +}
>> +else
>> +pt_intr_post(v, intack);
>>  }
>>  else
>>  {
>> --
>> 1.7.12.4
>>
>
>Looks good to me.
>
>Reviewed-by: Yang Zhang 
>


Thanks for your comments!!
Quan


>--
>Yang
>Alibaba Cloud Computing

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

Re: [Xen-devel] [PATCH 1/2] xen/Kconfig: Drop redundant comments from Kconfig files

[Julien Grall]

Hi,

On 19/08/16 16:54, Andrew Cooper wrote:

Most of the comments are duplicated from the help text, and those without help
provide no useful additional input.

Signed-off-by: Andrew Cooper 
---
CC: Doug Goldstein 
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 


For ARM bits:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] unable start xen in hikey

[Julien Grall]

On 19/08/16 23:44, Kamenee Arumugam wrote:

Hi Julien/Chen,


Hello,


Thanks, it is working for me after setting CONFIG_ARCH_HISI = y in
config file. So, when i tried to boot linux thru startup.sh, it seems to
hangs and below are the traces of log:

Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell> FS0:
FS0:\> Image console=ttyAMA3,115200 root=/dev/mmcblk1p4 rootwait rw
efi=noruntime
EFI stub: Booting Linux Kernel...
EFI stub: Generating empty DTB
EFI stub: Exiting boot services and installing virtual address map...

Am I missing some configuration in my kernel or patches to handle
virtual address map?


I am not sure to follow. Did you ever try to boot Linux on hikey without 
Xen?


I would recommend you to get Linux working natively (i.e without Xen) 
first and then add Xen specific options in your config.


Regards,


--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] libs/gnttab: do not use alloca(3)

[Wei Liu]

On Mon, Aug 22, 2016 at 11:24:56AM +0100, David Vrabel wrote:
> On 22/08/16 11:10, Wei Liu wrote:
> > On Mon, Aug 22, 2016 at 10:46:50AM +0100, David Vrabel wrote:
> >> On 17/08/16 15:33, Wei Liu wrote:
> >>> The semantics of alloca(3) is not very nice. If the stack overflows,
> >>> program behaviour is undefined.
> >>>
> >>> Remove the use of alloca(3) and always use mmap.
> >>
> >> This is only using alloca() if the allocation is < PAGE_SIZE.  I think
> >> assuming there's this much extra stack is fine.
> >>
> > 
> > A library is not in a position assume how deep the stack is IMHO.
> 
> This suggests a library cannot use any stack, which is clearly silly.
> 

Of course not. Please don't take my words out of context and further
imply things I never said. This is not how a conversation should work
out. And name calling is toxic. Please just stop.

I care about the undefined behaviour aspect of alloca -- I believe you
dislike that as much as I do.

> But ok, in which case you should consider using malloc() instead of
> alloca()/mmap(), then small allocation might come out of some
> pre-existing or cached allocations.
> 

Ok, that seems sensible.

Wei.

> David

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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Jan Beulich]

>>> On 19.08.16 at 14:58,  wrote:
> From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
> From: Quan Xu 
> Date: Fri, 19 Aug 2016 20:40:31 +0800
> Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue
> 
> When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
> with high payload (with 2vCPU, captured from xentrace, in high payload, the
> count of IPI interrupt increases rapidly between these vCPUs).
> 
> If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
> are both pending (index of bit set in VIRR), unfortunately, the IPI intrrupt
> is high priority than periodic timer interrupt. Xen updates IPI interrupt bit
> set in VIRR to guest interrupt status (RVI) as a high priority and apicv
> (Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
> operation without a VM exit. Within VMX non-root operation, if periodic timer
> interrupt index of bit is set in VIRR and highest, the apicv delivers periodic
> timer interrupt within VMX non-root operation as well.
> 
> But in current code, if Xen doesn't update periodic timer interrupt bit set
> in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
> case to decrease the count (pending_intr_nr) of pending periodic timer 
> interrupt,
> then Xen will deliver a periodic timer interrupt again. The guest receives 
> more
> periodic timer interrupt.
> 
> If the periodic timer interrut is delivered and not the highest priority, make
> Xen be aware of this case to decrease the count of pending periodic timer
> interrupt.

I can see the issue you're trying to address, but for one - doesn't
this lead to other double accounting, namely once the pt irq becomes
the highest priority one?

> --- a/xen/arch/x86/hvm/vmx/intr.c
> +++ b/xen/arch/x86/hvm/vmx/intr.c
> @@ -334,7 +334,21 @@ void vmx_intr_assist(void)
>  __vmwrite(EOI_EXIT_BITMAP(i), 
> v->arch.hvm_vmx.eoi_exit_bitmap[i]);
>  }
> 
> -pt_intr_post(v, intack);
> +   /*
> +* If the periodic timer interrut is delivered and not the highest 
> priority,
> +* make Xen be aware of this case to decrease the count of pending 
> periodic
> +* timer interrupt.
> +*/
> +if ( pt_vector != -1 && intack.vector > pt_vector )
> +{
> +struct hvm_intack pt_intack;
> +
> +pt_intack.vector = pt_vector;
> +pt_intack.source = hvm_intsrc_lapic;
> +pt_intr_post(v, pt_intack);
> +}
> +else
> +pt_intr_post(v, intack);

And then I'm having two problems with this change: Processing other
than the highest priority irq here looks to be non-architectural. From
looking over pt_intr_post() there's only pt related accounting and no
actual interrupt handling there, but I'd like this to be (a) confirmed
and (b) called out in the comment.

Plus the change above is in no way apicv specific, so I'd also like to
see clarification why this change is valid (i.e. at least not making
things worse) even without apicv in use.

And of course in any event VMX maintainer feedback is going to be
needed here.

Jan


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

Re: [Xen-devel] [PATCH] tools/firmware: Rename bios.bin to seabios.bin

[Wei Liu]

On Fri, Aug 19, 2016 at 03:26:23PM +0100, Andrew Cooper wrote:
> bios.bin as a name is far too generic.  Rename it to seabios.bin.
> 
> Signed-off-by: Andrew Cooper 

Hmm... I remember the first few versions of that series had it named
seabios.bin and I acked that.

Anyway, I think I will give Anthony a chance to clarify why he changed
the name.

Wei.

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

Re: [Xen-devel] Regression in kernel 4.7 xenstore

[Jan Beulich]

>>> On 21.08.16 at 00:33,  wrote:
> Hi,
> 
> I'm running Xen 4.4.1 as packaged in Debian 8.5 (jessie) with home-baked
> kernels (that is, from kernel.org) (hardware is x86-64, in case that
> matters).
> 
> After upgrading to kernel 4.7, xenstore-write is not able to set
> the Dom0 name anymore (and no DomU can be started).
> The journal shows:
> 
> Aug 20 23:36:09 dhcp-31 xenstored[683]: Checking store ...
> Aug 20 23:36:09 dhcp-31 xenstored[683]: Checking store complete.
> Aug 20 23:36:09 dhcp-31 xen[578]: Starting Xen daemons: xenfs xenstored 
> xenconsoled init-dom0xenstore-write: could not write path 
> /local/domain/0/name
> Aug 20 23:36:09 dhcp-31 xen[578]: xenstore-write: could not write path 
> /local/domain/0/domid
> Aug 20 23:36:09 dhcp-31 xen[578]: .
> 
> (this is a test instance, therefore the hostname)
> This problem exists in 4.7 and 4.7.2 (I checked just in case) (and
> 4.6.6+ but not 4.6.5 - that's history now anyways).
> Backing out commit 0beef634b86a1350c31da5fcc2992f0d7c8a622b
>   "xenbus: don't BUG() on user mode induced condition"
>   
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=0be 
> ef634b86a1350c31da5fcc2992f0d7c8a622b
> fixes this problem for me (but I've no idea how to fix the original
> problem).
> 
> Am I looking at a bona fide regression, or did this change uncover
> some misbehaviour in the (arguably not that recent) Xen 4.4 or even
> in Debian's specific version?
> 
> In case you need more information or want a patch tested, I'll leave
> this test system around for some time.

See https://patchwork.kernel.org/patch/9281193/.

Jan


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

Re: [Xen-devel] [PATCH 1/2] libs/gnttab: do not use alloca(3)

[Wei Liu]

On Mon, Aug 22, 2016 at 10:46:50AM +0100, David Vrabel wrote:
> On 17/08/16 15:33, Wei Liu wrote:
> > The semantics of alloca(3) is not very nice. If the stack overflows,
> > program behaviour is undefined.
> > 
> > Remove the use of alloca(3) and always use mmap.
> 
> This is only using alloca() if the allocation is < PAGE_SIZE.  I think
> assuming there's this much extra stack is fine.
> 

A library is not in a position assume how deep the stack is IMHO.

Wei.

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

[Xen-devel] [distros-debian-sid test] 67575: regressions - FAIL

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail REGR. vs. 
66937

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-i386-sid-netboot-pvgrub  9 debian-di-install   fail like 66937
 test-amd64-i386-amd64-sid-netboot-pygrub  9 debian-di-install  fail like 66937
 test-amd64-amd64-i386-sid-netboot-pygrub  9 debian-di-install  fail like 66937
 test-amd64-amd64-amd64-sid-netboot-pvgrub  9 debian-di-install fail like 66937

baseline version:
 flight   66937

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v5 00/16] x86: multiboot2 protocol support

[Jan Beulich]

>>> On 20.08.16 at 00:43,  wrote:
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
> multiboot2 protocol. This way we will have:
>   - smaller Xen code base,
>   - one code base for xen.gz and xen.efi,
>   - one build method for xen.gz and xen.efi;
> xen.efi will be extracted from xen(-syms)
> file using objcopy or special custom tool,
>   - xen.efi build will not so strongly depend
> on a given GCC and binutils version.

Just in case you aren't aware: The partial revert done by
0b8a172444 ("x86: partially revert use of 2M mappings for
hypervisor image") now puts us a step further away from that
goal, compared to when you had started your work.

Jan


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

Re: [Xen-devel] [PATCH 1/2] libs/gnttab: do not use alloca(3)

[David Vrabel]

On 17/08/16 15:33, Wei Liu wrote:
> The semantics of alloca(3) is not very nice. If the stack overflows,
> program behaviour is undefined.
> 
> Remove the use of alloca(3) and always use mmap.

This is only using alloca() if the allocation is < PAGE_SIZE.  I think
assuming there's this much extra stack is fine.

Using alloca() avoids the (expensive) mmap() system call.

David

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

Re: [Xen-devel] [MINIOS PATCH 0/3] x86: use ELF notes and unified linker script

[Wei Liu]

On Thu, Aug 18, 2016 at 11:15:23AM +0100, Wei Liu wrote:
> Wei Liu (3):
>   Introduce asm_macros.h
>   x86: switch to use elfnote
>   x86: use unified linker script
> 

Series pushed.

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

Re: [Xen-devel] [PATCH] mini-os: fix coverity issues in printf.c

[Wei Liu]

On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote:
> Fix two issues discovered by coverity.
> 

Pushed with fixed up commit message.

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

Re: [Xen-devel] [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

[Yang Zhang]

On 2016/8/19 20:58, Xuquan (Euler) wrote:

From 9b2df963c13ad27e2cffbeddfa3267782ac3da2a Mon Sep 17 00:00:00 2001
From: Quan Xu 
Date: Fri, 19 Aug 2016 20:40:31 +0800
Subject: [RFC PATCH] x86/apicv: fix RTC periodic timer and apicv issue

When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest
with high payload (with 2vCPU, captured from xentrace, in high payload, the
count of IPI interrupt increases rapidly between these vCPUs).

If IPI intrrupt (vector 0xe1) and periodic timer interrupt (vector 0xd1)
are both pending (index of bit set in VIRR), unfortunately, the IPI intrrupt
is high priority than periodic timer interrupt. Xen updates IPI interrupt bit
set in VIRR to guest interrupt status (RVI) as a high priority and apicv
(Virtual-Interrupt Delivery) delivers IPI interrupt within VMX non-root
operation without a VM exit. Within VMX non-root operation, if periodic timer
interrupt index of bit is set in VIRR and highest, the apicv delivers periodic
timer interrupt within VMX non-root operation as well.

But in current code, if Xen doesn't update periodic timer interrupt bit set
in VIRR to guest interrupt status (RVI) directly, Xen is not aware of this
case to decrease the count (pending_intr_nr) of pending periodic timer 
interrupt,
then Xen will deliver a periodic timer interrupt again. The guest receives more
periodic timer interrupt.

If the periodic timer interrut is delivered and not the highest priority, make
Xen be aware of this case to decrease the count of pending periodic timer
interrupt.


Nice catch!



Signed-off-by: Yifei Jiang 
Signed-off-by: Rongguang He 
Signed-off-by: Quan Xu 
---
Why RFC:
1. I am not quite sure for other cases, such as nested case.


We don't support the nested APICv now. So it is ok for this patch.


2. Within VMX non-root operation, an Asynchronous Enclave Exit (including 
external
   interrupts, non-maskable interrupt system-management interrrupts, exceptions
   and VM exit) may occur before delivery of a periodic timer interrupt, the 
periodic
   timer interrupt may be lost when a coming periodic timer interrupt is 
delivered.
   Actually, and so current code is.


I think you mean the combination not interrupt lost. It should be ok 
since it happens rarely and even native OS will encounter the same 
problem if it disable the interrupt for too long.



---
 xen/arch/x86/hvm/vmx/intr.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c
index 8fca08c..d3a034e 100644
--- a/xen/arch/x86/hvm/vmx/intr.c
+++ b/xen/arch/x86/hvm/vmx/intr.c
@@ -334,7 +334,21 @@ void vmx_intr_assist(void)
 __vmwrite(EOI_EXIT_BITMAP(i), v->arch.hvm_vmx.eoi_exit_bitmap[i]);
 }

-pt_intr_post(v, intack);
+   /*
+* If the periodic timer interrut is delivered and not the highest 
priority,
+* make Xen be aware of this case to decrease the count of pending 
periodic
+* timer interrupt.
+*/
+if ( pt_vector != -1 && intack.vector > pt_vector )
+{
+struct hvm_intack pt_intack;
+
+pt_intack.vector = pt_vector;
+pt_intack.source = hvm_intsrc_lapic;
+pt_intr_post(v, pt_intack);
+}
+else
+pt_intr_post(v, intack);
 }
 else
 {
--
1.7.12.4



Looks good to me.

Reviewed-by: Yang Zhang 

--
Yang
Alibaba Cloud Computing

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

Re: [Xen-devel] [PATCH 14/24] libxl: allow to set the ratelimit value online for Credit2

[Ian Jackson]

Dario Faggioli writes ("[PATCH 14/24] libxl: allow to set the ratelimit value 
online for Credit2"):
...
> -rc = xc_sched_credit_params_set(ctx->xch, poolid, );
> -if ( rc < 0 ) {
> -LOGE(ERROR, "setting sched credit param");
> -GC_FREE;
> -return ERROR_FAIL;
> +r = xc_sched_credit_params_set(ctx->xch, poolid, );
> +if ( r < 0 ) {
> +LOGE(ERROR, "Setting Credit scheduler parameters");
> +rc = ERROR_FAIL;
> +goto out;

I had to read this three times to figure out what the change was.

It is good that you are fixing the coding style but can you please put
it in a separate patch ?

In general I was surprised at how large this patch, and the
corresponding xl one, was.  Perhaps after the coding style fixes are
split off the functional patches will be smaller.

But I wonder whether there will still be lots of rather formulaic code
that could profitably be generalised somehow.  I'd appreciate your
views on whether that would be possible, and whether it would be a
good idea..

For now I will stop my review here.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 14/24] libxl: allow to set the ratelimit value online for Credit2

[Ian Jackson]

Dario Faggioli writes ("[PATCH 14/24] libxl: allow to set the ratelimit value 
online for Credit2"):
> This is the remaining part of the plumbing (the libxl
> one) necessary to be able to change the value of the
> ratelimit_us parameter online, for Credit2 (like it is
> already for Credit1).

I think this should have a HAVE #define.

Ian.

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

Re: [Xen-devel] Xen Wiki Write permissions

[Wei Liu]

Hi Neil

On Sun, Aug 21, 2016 at 01:22:15PM -0400, Neil Sikka wrote:
> Hello, how can i get write permission to update documentation on the Xen
> Wiki?
> 

Please send me your account name for Xen wiki and I will grant you write
permission.

Wei.

> -- 
> My Blog: http://www.neilscomputerblog.blogspot.com/
> Twitter: @neilsikka

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


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100569
 build-amd64-rumpuserxen   6 xen-buildfail  like 100574
 build-i386-rumpuserxen6 xen-buildfail  like 100574
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100574
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100574
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100574
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100574
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100574

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

version targeted for testing:
 xen  2a99aa99fc84a45f505f84802af56b006d14c52e
baseline version:
 xen  2a99aa99fc84a45f505f84802af56b006d14c52e

Last test of basis   100578  2016-08-22 01:59:55 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17035 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   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev