On 02/03/2017 02:33, Yu Zhang wrote:
> Hi Jan,
>
> Previously I saw your UMIP patches merged in xen, and we'd like to
> try some unit test here in Intel. And I wonder do you have any unit
> test code for this feature, or any suggestions? :)
There is support in the x86 emulator to handle UMIP cor
>>> On 01.03.17 at 20:56, wrote:
> On 01/03/17 14:19, Jan Beulich wrote:
> On 01.03.17 at 14:59, wrote:
>>> On 28/02/17 12:50, Jan Beulich wrote:
>> I also think avoiding two identical prefixes is (marginally) better
>> architecture-
>> wise.
>
> There is no specific advice in the AMD optim
>>> On 01.03.17 at 21:35, wrote:
> On 01/03/17 16:11, Jan Beulich wrote:
> On 01.03.17 at 16:49, wrote:
>>> On 28/02/17 12:54, Jan Beulich wrote:
@@ -2740,6 +2790,13 @@ x86_decode(
break;
case ext_0f3a:
+d = ext0f3a_table[b].to_memory ? DstMem
flight 106323 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106323/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 3 host-install(3) broken in 106018 pass in
106323
test-amd64-amd64-xl-q
>>> On 01.03.17 at 17:58, wrote:
> On 28/02/17 12:56, Jan Beulich wrote:
>> @@ -6951,6 +7040,97 @@ x86_emulate(
>> fic.insn_bytes = PFX_BYTES + 3;
>> break;
>>
>> +case X86EMUL_OPC_66(0x0f38, 0x20): /* pmovsxbw xmm/m64,xmm */
>> +case X86EMUL_OPC_66(0x0f38, 0x21): /* pm
>>> On 01.03.17 at 18:44, wrote:
> On 28/02/17 12:58, Jan Beulich wrote:
>> @@ -7434,6 +7436,14 @@ x86_emulate(
>> generate_exception_if(vex.l, EXC_UD);
>> goto simd_0f_imm8_avx;
>>
>> +case X86EMUL_OPC_66(0x0f3a, 0x44): /* pclmulqdq $imm8,xmm/m128,xmm
>> */
>> +ca
On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini wrote:
> Hi all,
>
> Edgar reported a data corruption on network packets in dom0 when the
> swiotlb-xen is in use. He also reported that the following patch "fixes"
> the problem for him:
>
> static void __xen_dma_page_cpu_to_dev(struc
Strangely there was already one cpu_has_umip defined, so there is no
need for one in this patch.
Signed-off-by: Wei Liu
---
include/arch/x86/processor.h | 1 +
include/xen/arch-x86/cpufeatureset.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/arch/x86/processor.h b/includ
Signed-off-by: Wei Liu
---
tests/umip/Makefile | 9 +
tests/umip/main.c | 102
2 files changed, 111 insertions(+)
create mode 100644 tests/umip/Makefile
create mode 100644 tests/umip/main.c
diff --git a/tests/umip/Makefile b/tests/um
I wrote this long time ago before UMIP was merged.
Yu, since you asked, I might as well post it for your reference on how to
do it with XTF.
This series is not yet tested in any way.
Wei Liu (2):
x86: add UMIP feature bit
Add UMIP test
include/arch/x86/processor.h | 1 +
include/
On Thu, Mar 02, 2017 at 07:42:33AM +, Xuquan (Quan Xu) wrote:
>On March 01, 2017 2:24 PM, wrote:
>>
>>Good point. I ignore v->processor maybe change. I have thought over
>> __vmx_deliver_posted_interrupt() again and want to share you my opinion.
>>First of all, __vmx_deliver_posted_interrupt()
__vmx_deliver_posted_interrupt() wrongly used a softirq bit to decide whether
to suppress an IPI. Its logic was: the first time an IPI was sent, we set
the softirq bit. Next time, we would check that softirq bit before sending
another IPI. If the 1st IPI arrived at the pCPU which was in
non-root mo
On Thu, Mar 02, 2017 at 09:38:37AM +0100, Edgar E. Iglesias wrote:
> On Wed, Mar 01, 2017 at 05:05:21PM -0800, Stefano Stabellini wrote:
> > Hi all,
> >
> > Edgar reported a data corruption on network packets in dom0 when the
> > swiotlb-xen is in use. He also reported that the following patch "fi
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 02 March 2017 02:06
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> Stabellini ; Anthony Perard
>
> Subject: Re: [PATCH 5/5] xen: use libxendevicemodel when av
>>> On 27.02.17 at 02:45, wrote:
> @@ -547,16 +548,116 @@ static int remap_entry_to_msi_msg(
> return 0;
> }
>
> +/*
> + * This function is a common interface to update irte for msi case.
> + *
> + * If @pi_desc != NULL and @gvec != 0, the IRTE will be updated to a posted
> + * format. In
>>> On 27.02.17 at 02:45, wrote:
> We used structure assignment to update irte which was not safe when a
> interrupt happend during update. It is better to update IRTE atomically
> through cmpxchg16b(). When cmpxchg16b is not supported, two 64-bit write
> operation can atomically update IRTE when
On 02/03/2017 08:42, Wei Liu wrote:
> I wrote this long time ago before UMIP was merged.
>
> Yu, since you asked, I might as well post it for your reference on how to
> do it with XTF.
>
> This series is not yet tested in any way.
Unfortunately, you execute all of the sensitive instructions in ker
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 01 March 2017 17:18
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> Stabellini
> Subject: Re: [PATCH 4/5] configure: detect presence of libxendevicemodel
>
> O
Hello,
Just pulled the latest staging and I get:
qemu successfuly configured for Xen qemu-dm build
=== PCI passthrough capability has been enabled ===
make[2]: Entering directory
`~/work/xen.git/tools/qemu-xen-traditional-dir-remote'
=== PCI passthrough capability has been enabled ===
=== PCI pas
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Razvan Cojocaru
> Sent: 02 March 2017 09:19
> To: Xen-devel
> Subject: [Xen-devel] Xen staging: libxendevicemodel.so.1 [...] not found
>
> Hello,
>
> Just pulled the latest staging and I get:
>
On 03/02/2017 11:23 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
>> Razvan Cojocaru
>> Sent: 02 March 2017 09:19
>> To: Xen-devel
>> Subject: [Xen-devel] Xen staging: libxendevicemodel.so.1 [...] not found
>>
>> Hell
> -Original Message-
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: 02 March 2017 09:27
> To: Paul Durrant ; Xen-devel de...@lists.xen.org>
> Subject: Re: [Xen-devel] Xen staging: libxendevicemodel.so.1 [...] not found
>
> On 03/02/2017 11:23 AM, Paul Durrant wrote:
>
>>> On 02.03.17 at 02:49, wrote:
The patch title, btw, makes it looks like this isn't a bug fix, which is
contrary to the understanding I've gained so far.
> __vmx_deliver_posted_interrupt() wrongly used a softirq bit to decide whether
> to suppress an IPI. Its logic was: the first time an IPI w
On Thu, Mar 02, 2017 at 11:19:23AM +0200, Razvan Cojocaru wrote:
> Hello,
>
> Just pulled the latest staging and I get:
>
Just nuke the working tree with git clean -fd and rebuild.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https:/
flight 106352 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106352/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106226
test-armhf-armhf-libvirt-xsm 13
During load balancing, we check the non idle pCPUs to
see if they have runnable but not running vCPUs that
can be stolen by and set to run on currently idle pCPUs.
If a pCPU has only one running (or runnable) vCPU,
though, we don't want to steal it from there, and
it's therefore pointless botherin
Including whether we actually tried stealing a vCPU from
a given pCPU, or we skipped that one, because of lock
contention.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Ian Jackson
Cc: Wei Liu
---
tools/xentrace/formats |1 +
tools/xentrace/xenalyze.c| 11 +++
Chacking whether or not a vCPU can be 'stolen'
from a peer pCPU's runqueue is relatively cheap.
Therefore, let's do that as early as possible,
avoiding potentially useless complex checks, and
cpumask manipulations.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credi
Right now, we use cpumask_first() for going through
the bus pCPUs in csched_load_balance(). This means
not all pCPUs have equal chances of seeing their
pending work stolen. It also means there is more
runqueue lock pressure on lower ID pCPUs.
To avoid all this, let's record and remember, for
each
Since we're holding the lock on the pCPU from which we
are trying to steal, it can't have disappeared, so we
can drop the check for that (and convert it in an
ASSERT()).
And since we try to steal only from busy pCPUs, it's
unlikely for such pCPU to be idle, so we mark it as
such (and bail early if
Hello,
This series aims at introducing some optimization and performance improvement
in Credit1 (in certain specific situations), but Credit2 is lightly touched as
well.
The core of the series is patches 3 and 4, which aim at both redistributing and
reducing spinlock contention during load balanc
cpumask_any() is costly (because of the randomization).
And since it does not really matter which exact CPU is
selected within a runqueue, as that will be overridden
shortly after, in runq_tickle(), spending too much time
and achieving true randomization is pretty pointless.
As the picked CPU, how
On Wed, Mar 01, 2017 at 11:53:52PM +, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> testid xen-boot
>
> Tree: linux git://xenbits.xen.org/linux-pvops.git
> Tree: linuxfirmware git://xenbits.xen.org/osstes
On 02/03/17 10:41, Daniel Kiper wrote:
> On Wed, Mar 01, 2017 at 11:53:52PM +, osstest service owner wrote:
>> branch xen-unstable
>> xenbranch xen-unstable
>> job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
>> testid xen-boot
>>
>> Tree: linux git://xenbits.xen.org/linux-pvops.git
>>
On Wed, Mar 01, 2017 at 04:16:32PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: 01 March 2017 16:14
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> > Stabellini ; Paolo
flight 106361 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106361/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 106320
Tests which
Allocation of new_hash, inside xenvif_new_hash(), always happen
in softirq context, so use GFP_ATOMIC instead of GFP_KERNEL for new
hash allocation.
Signed-off-by: Anoob Soman
---
drivers/net/xen-netback/hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/xen-n
> -Original Message-
> From: Anoob Soman [mailto:anoob.so...@citrix.com]
> Sent: 02 March 2017 10:50
> To: net...@vger.kernel.org; xen-de...@lists.xenproject.org
> Cc: Paul Durrant ; Wei Liu ;
> Anoob Soman
> Subject: [PATCH net] xen-netback: Use GFP_ATOMIC to allocate hash
>
> Allocation
On Thu, Mar 02, 2017 at 10:50:20AM +, Anoob Soman wrote:
> Allocation of new_hash, inside xenvif_new_hash(), always happen
> in softirq context, so use GFP_ATOMIC instead of GFP_KERNEL for new
> hash allocation.
>
> Signed-off-by: Anoob Soman
Acked-by: Wei Liu
_
On Thu, Mar 02, 2017 at 09:05:27AM +, Andrew Cooper wrote:
> On 02/03/2017 08:42, Wei Liu wrote:
> > I wrote this long time ago before UMIP was merged.
> >
> > Yu, since you asked, I might as well post it for your reference on how to
> > do it with XTF.
> >
> > This series is not yet tested in
On Thu, Mar 02, 2017 at 09:06:43AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > Sent: 01 March 2017 17:18
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> > Stabellini
> > Sub
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 02 March 2017 10:55
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> Stabellini
> Subject: Re: [PATCH 4/5] configure: detect presence of libxendevicemodel
>
> O
On Thu, 2017-03-02 at 11:37 +0100, Dario Faggioli wrote:
> ---
> Dario Faggioli (6):
> xen: credit1: simplify csched_runq_steal() a little bit.
> xen: credit: (micro) optimize csched_runq_steal().
> xen: credit1: increase efficiency and scalability of load balancing.
> xen:
On 02/03/17 11:54, Anthony PERARD wrote:
> On Thu, Mar 02, 2017 at 09:06:43AM +, Paul Durrant wrote:
>>> -Original Message-
>>> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
>>> Sent: 01 March 2017 17:18
>>> To: Paul Durrant
>>> Cc: xen-de...@lists.xenproject.org; qemu-de...@
On 02/03/17 10:38, Dario Faggioli wrote:
> During load balancing, we check the non idle pCPUs to
> see if they have runnable but not running vCPUs that
> can be stolen by and set to run on currently idle pCPUs.
>
> If a pCPU has only one running (or runnable) vCPU,
> though, we don't want to steal
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 02 March 2017 11:01
> To: Anthony Perard ; Paul Durrant
>
> Cc: xen-de...@lists.xenproject.org; Stefano Stabellini
> ; qemu-de...@nongnu.org
> Subject: Re: [Xen-devel] [PATCH 4/5] configure: detect presence of
> li
This patch creates inline wrapper functions in xen_common.h for all open
coded calls to xc_hvm_XXX() functions outside of xen_common.h so that use
of xen_xc can be made implicit. This again is in preparation for the move
to using libxendevicemodel.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony
My recent patches to Xen [1] introduced a new library to support
running device models for HVM guests.
This series ports QEMU onto the new library if it is available in the
build environment.
[1] Patches starting with
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=b108240265deea37601f1a60591
Doing this will make the transition to using the new libxendevicemodel
interface less intrusive on the callers of these functions, since using
the new library will require a change of handle.
NOTE: The patch also moves the 'externs' for xen_xc and xen_fmem from
xen_backend.h to xen_common.h,
This patch modifies the wrapper functions in xen_common.h to use the
new xendevicemodel interface if it is available along with compatibility
code to use the old libxenctrl interface if it is not.
Signed-off-by: Paul Durrant
---
Cc: Stefano Stabellini
Cc: Anthony Perard
v2:
- Add a compat defi
On Thu, Mar 02, 2017 at 10:42:57AM +, Andrew Cooper wrote:
> On 02/03/17 10:41, Daniel Kiper wrote:
> > On Wed, Mar 01, 2017 at 11:53:52PM +, osstest service owner wrote:
> >> branch xen-unstable
> >> xenbranch xen-unstable
> >> job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> >>
This patch adds code in configure to set CONFIG_XEN_CTRL_INTERFACE_VERSION
to a new value of 490 if libxendevicemodel is present in the build
environment.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
Cc: Stefano Stabellini
---
configure | 19 +++
1 file changed,
This patch is a purely cosmetic change that avoids a name collision in
a subsequent patch.
Signed-off-by: Paul Durrant
Reviewed-by: Anthony Perard
---
Cc: Paolo Bonzini
Cc: Stefano Stabellini
---
include/exec/ram_addr.h | 4 ++--
include/hw/xen/xen.h| 2 +-
xen-hvm-stub.c | 2 +-
Signed-off-by: Anthony PERARD
---
tools/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/Makefile b/tools/Makefile
index 68633a413d..3e15463567 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -269,6 +269,7 @@ subdir-all-qemu-xen-dir: qemu-xen-dir-find
-I$(X
On 02/03/17 12:06, Paul Durrant wrote:
>> -Original Message-
>> From: Juergen Gross [mailto:jgr...@suse.com]
>> Sent: 02 March 2017 11:01
>> To: Anthony Perard ; Paul Durrant
>>
>> Cc: xen-de...@lists.xenproject.org; Stefano Stabellini
>> ; qemu-de...@nongnu.org
>> Subject: Re: [Xen-devel]
On Thu, Mar 02, 2017 at 02:41:55AM -0700, Jan Beulich wrote:
On 02.03.17 at 02:49, wrote:
>
>The patch title, btw, makes it looks like this isn't a bug fix, which is
>contrary to the understanding I've gained so far.
Thanks to your patience and your changing so much description for me. Also
On Thu, Mar 02, 2017 at 11:22:35AM +, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Acked + applied.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Thu, 2017-03-02 at 11:06 +, Andrew Cooper wrote:
> On 02/03/17 10:38, Dario Faggioli wrote:
> > signed-off-by: Dario Faggioli
> > ---
> > Cc: George Dunlap
> > Cc: Andrew Cooper
>
> Malcolm’s solution to this problem is https://github.com/xenserver/xe
> n-4.7.pg/commit/0f830b9f229fa6472
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 02 March 2017 11:23
> To: xen-de...@lists.xenproject.org
> Cc: Paul Durrant ; Anthony Perard
> ; Ian Jackson ; Wei
> Liu
> Subject: [PATCH] tools: Fix build of QEMU with lib xendevicemodel support
>
> S
Juergen Gross writes ("[PATCH v2 1/4] stubdom: set xen interface version for
stubdom apps using xenctrl.h"):
> A stubdom app using xenctrl.h must use the latest interface version of
> Xen in order to avoid compatibility issues. Add the related config
> item to the stubdom config files where needed
Juergen Gross writes ("[PATCH v2 2/4] tools: add pkg-config file for libxc"):
> Instead of a try and error approach needing updates for nearly each
> new version of Xen just provide xencontrol.pc to be used via
> pkg-config.
Acked-by: Ian Jackson
Ian.
___
On 02/03/17 04:15, osstest service owner wrote:
> flight 106307 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106307/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-armhf-xl-cubietruck 15 gu
>>> On 27.02.17 at 15:03, wrote:
> @@ -91,12 +91,12 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
> #if GUEST_PAGING_LEVELS == 3
> top_map += (cr3 & ~(PAGE_MASK | 31));
> #endif
> -missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0], top_mfn, top_map);
> +walk_ok = guest
On Thu, Mar 02, 2017 at 11:47:27AM +, Andrew Cooper wrote:
> On 02/03/17 04:15, osstest service owner wrote:
> > flight 106307 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/106307/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> >
With commits f16f1df65 and 9a6cdf52b we get in our Xen testing:
[ 174.512861] switch: port 2(vif3.0) entered disabled state
[ 174.522735] BUG: sleeping function called from invalid context at
/home/build/linux-linus/mm/vmalloc.c:1441
[ 174.523451] in_atomic(): 1, irqs_disabled(): 0, pid: 28, na
On 02/03/17 11:52, Jan Beulich wrote:
On 27.02.17 at 15:03, wrote:
>> @@ -91,12 +91,12 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
>> #if GUEST_PAGING_LEVELS == 3
>> top_map += (cr3 & ~(PAGE_MASK | 31));
>> #endif
>> -missing = guest_walk_tables(v, p2m, ga, &gw, pfec[0
>>> On 02.03.17 at 05:28, wrote:
> On Thu, Mar 02, 2017 at 02:41:55AM -0700, Jan Beulich wrote:
> On 02.03.17 at 02:49, wrote:
>>
>>The patch title, btw, makes it looks like this isn't a bug fix, which is
>>contrary to the understanding I've gained so far.
>
> Thanks to your patience and you
On Thu, Mar 02, 2017 at 12:56:20PM +0100, Juergen Gross wrote:
> With commits f16f1df65 and 9a6cdf52b we get in our Xen testing:
>
> [ 174.512861] switch: port 2(vif3.0) entered disabled state
> [ 174.522735] BUG: sleeping function called from invalid context at
> /home/build/linux-linus/mm/vmal
On Thu, Mar 02, 2017 at 11:09:46AM +, Paul Durrant wrote:
> This patch modifies the wrapper functions in xen_common.h to use the
> new xendevicemodel interface if it is available along with compatibility
> code to use the old libxenctrl interface if it is not.
>
> Signed-off-by: Paul Durrant
On Wed, Feb 22, 2017 at 5:14 PM, Julien Grall wrote:
> Hello Vijay,
>
>
> On 22/02/17 11:38, Vijay Kilari wrote:
>>
>> On Mon, Feb 20, 2017 at 11:58 PM, Julien Grall
>> wrote:
>>>
>>> Hello Vijay,
>>>
>>> On 09/02/17 15:57, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K
>
On 02/03/17 13:06, Wei Liu wrote:
> On Thu, Mar 02, 2017 at 12:56:20PM +0100, Juergen Gross wrote:
>> With commits f16f1df65 and 9a6cdf52b we get in our Xen testing:
>>
>> [ 174.512861] switch: port 2(vif3.0) entered disabled state
>> [ 174.522735] BUG: sleeping function called from invalid conte
Hello Vijay,
On 02/03/17 12:10, Vijay Kilari wrote:
On Wed, Feb 22, 2017 at 5:14 PM, Julien Grall wrote:
On 22/02/17 11:38, Vijay Kilari wrote:
[...]
That is default distance value.
From where? Please give a link to the doc.
10/20 is used by x86 implementation as well.
https://git.ker
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 02 March 2017 12:13
> To: Wei Liu
> Cc: Igor Druzhinin ; xen-devel de...@lists.xenproject.org>; Linux Kernel Mailing List ker...@vger.kernel.org>; net...@vger.kernel.org; Boris Ostrovsky
> ; David Miller ; Paul
>
On 01/03/17 15:57, Jan Beulich wrote:
On 27.02.17 at 15:03, wrote:
>> -static inline int
>> -guest_supports_1G_superpages(struct vcpu *v)
>> +static inline bool guest_has_pse36(const struct vcpu *v)
>> +{
>> + /* No support for 2-level PV guests. */
>> +return is_pv_vcpu(v) ? 0 : pagi
On Mon, Feb 20, 2017 at 11:35 PM, Julien Grall wrote:
> Hello Vijay,
>
>
> On 09/02/17 15:56, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K
>>
>> Parse memory node and fetch numa-node-id information.
>> For each memory range, store in node_memblk_range[]
>> along with node id.
>>
>> Si
On 01/03/17 16:03, Jan Beulich wrote:
On 27.02.17 at 15:03, wrote:
>> The shadow logic should never create a shadow of a guest PTE which contains
>> reserved bits from the guests point of view. Such a shadowed entry might not
>> cause #PF[RSVD] when walked by hardware, thus won't behave arch
On Thu, Mar 02, 2017 at 06:13:16AM +0100, Juergen Gross wrote:
> When configuring the build of qemu the configure script is building
> various test programs to determine the exact version of libxencontrol.
>
> Instead of a try and error approach needing updates for nearly each
> new version of Xen
On Tue, Feb 21, 2017 at 12:06 AM, Julien Grall wrote:
> Hello Vijay,
>
> On 09/02/17 15:57, vijay.kil...@gmail.com wrote:
>>
>> From: Vijaya Kumar K
>>
>> Delete numa-node-id and distance map from Dom0 DT
>> so that NUMA information is not exposed to Dom0.
>>
>> This helps particularly to boot No
Wah. Thank you, Andrew & Wei. :-)
On 3/2/2017 5:05 PM, Andrew Cooper wrote:
On 02/03/2017 08:42, Wei Liu wrote:
I wrote this long time ago before UMIP was merged.
Yu, since you asked, I might as well post it for your reference on how to
do it with XTF.
This series is not yet tested in any wa
On 02/03/17 13:29, Wei Liu wrote:
> On Thu, Mar 02, 2017 at 06:13:16AM +0100, Juergen Gross wrote:
>> When configuring the build of qemu the configure script is building
>> various test programs to determine the exact version of libxencontrol.
>>
>> Instead of a try and error approach needing updat
On Thu, Mar 02, 2017 at 01:35:54PM +0100, Juergen Gross wrote:
> On 02/03/17 13:29, Wei Liu wrote:
> > On Thu, Mar 02, 2017 at 06:13:16AM +0100, Juergen Gross wrote:
> >> When configuring the build of qemu the configure script is building
> >> various test programs to determine the exact version of
On 02/03/17 12:30, Yu Zhang wrote:
> Wah. Thank you, Andrew & Wei. :-)
>
> On 3/2/2017 5:05 PM, Andrew Cooper wrote:
>> On 02/03/2017 08:42, Wei Liu wrote:
>>> I wrote this long time ago before UMIP was merged.
>>>
>>> Yu, since you asked, I might as well post it for your reference on
>>> how to
>
On Fri, Dec 16, 2016 at 3:48 PM, Dario Faggioli
wrote:
> On Fri, 2016-12-16 at 09:40 +, Julien Grall wrote:
>> Hi Vijay,
>> On 16/12/2016 07:39, Vijay Kilari wrote:
>> > If we drop numa-node-id from memory node generated to dom0, then
>> > dom0 will
>> > assume all the memory is from node0. So
flight 106366 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106366/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
>>> On 02.03.17 at 13:26, wrote:
> On 01/03/17 16:03, Jan Beulich wrote:
> On 27.02.17 at 15:03, wrote:
>>> The shadow logic should never create a shadow of a guest PTE which contains
>>> reserved bits from the guests point of view. Such a shadowed entry might
>>> not
>>> cause #PF[RSVD] wh
Hello Vijay,
On 02/03/17 12:39, Vijay Kilari wrote:
On Fri, Dec 16, 2016 at 3:48 PM, Dario Faggioli
wrote:
On Fri, 2016-12-16 at 09:40 +, Julien Grall wrote:
Hi Vijay,
On 16/12/2016 07:39, Vijay Kilari wrote:
If we drop numa-node-id from memory node generated to dom0, then
dom0 will
assu
>>> On 02.03.17 at 13:00, wrote:
> On 02/03/17 11:52, Jan Beulich wrote:
> On 27.02.17 at 15:03, wrote:
>>> @@ -91,12 +91,12 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
>>> #if GUEST_PAGING_LEVELS == 3
>>> top_map += (cr3 & ~(PAGE_MASK | 31));
>>> #endif
>>> -missing =
This leads to a BUG of the following form:
[ 174.512861] switch: port 2(vif3.0) entered disabled state
[ 174.522735] BUG: sleeping function called from invalid context at
/home/build/linux-linus/mm/vmalloc.c:1441
[ 174.523451] in_atomic(): 1, irqs_disabled(): 0, pid: 28, name: xenwatch
[ 174.5
This patch replaces use of 'be->vif' with 'vif' and hence generally
makes the function look tidier. No semantic change.
Signed-off-by: Paul Durrant
---
Cc: Wei Liu
---
drivers/net/xen-netback/xenbus.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff
Commit 9a6cdf52b85e "xen-netback: fix memory leaks on XenBus disconnect"
added missing code to fix a memory leak by calling vfree() in the
appropriate place.
Unfortunately subsequent commit f16f1df65f1c "xen-netback: protect
resource cleaning on XenBus disconnect" then wrapped this call to vfree()
On 02/03/17 12:51, Jan Beulich wrote:
On 02.03.17 at 13:26, wrote:
>> On 01/03/17 16:03, Jan Beulich wrote:
>> On 27.02.17 at 15:03, wrote:
The shadow logic should never create a shadow of a guest PTE which contains
reserved bits from the guests point of view. Such a shadowed
Wei Liu writes ("[PATCH 0/5] xl cleanup and docs"):
> Wei Liu (5):
> CONTRIBUTING: list xl in inbound license section
> xl: add CODING_STYLE
> xl: remove declaration of ctx in c files
> xl: lift common_domname declaration to xl.h
> xl: lift logfile declaration to xl.h
All five
Acked-by:
start_svm() already runs after cpu_data[] was set up, so it shouldn't
modify it anymore (at least not directly). Constify the involved
pointers.
Furthermore LMSLE feature detection was broken by 566ddbe833 ("x86:
Fail CPU bringup cleanly if it cannot initialise HVM"), as Andrew
Cooper has pointed
>>> On 02.03.17 at 13:56, wrote:
> On 02/03/17 12:51, Jan Beulich wrote:
> On 02.03.17 at 13:26, wrote:
>>> On 01/03/17 16:03, Jan Beulich wrote:
>>> On 27.02.17 at 15:03, wrote:
> The shadow logic should never create a shadow of a guest PTE which
> contains
> reserved bits
On 02/03/17 13:54, Paul Durrant wrote:
> This leads to a BUG of the following form:
>
> [ 174.512861] switch: port 2(vif3.0) entered disabled state
> [ 174.522735] BUG: sleeping function called from invalid context at
> /home/build/linux-linus/mm/vmalloc.c:1441
> [ 174.523451] in_atomic(): 1, i
On Thu, Mar 02, 2017 at 12:54:25PM +, Paul Durrant wrote:
> This patch replaces use of 'be->vif' with 'vif' and hence generally
> makes the function look tidier. No semantic change.
>
> Signed-off-by: Paul Durrant
Acked-by: Wei Liu
___
Xen-devel
On Thu, Mar 02, 2017 at 12:54:26PM +, Paul Durrant wrote:
> This leads to a BUG of the following form:
>
> [ 174.512861] switch: port 2(vif3.0) entered disabled state
> [ 174.522735] BUG: sleeping function called from invalid context at
> /home/build/linux-linus/mm/vmalloc.c:1441
> [ 174.52
flight 106351 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106351/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 105933
test-amd64-amd64-xl-qemut-w
flight 106365 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106365/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf f02259db8c737220b4e6ae5564a8f6da4fba2949
baseline version:
xtf b834586f982174aa0bc09d
On Mon 27-02-17 16:43:04, Michal Hocko wrote:
> On Mon 27-02-17 12:25:10, Heiko Carstens wrote:
> > On Mon, Feb 27, 2017 at 11:02:09AM +0100, Vitaly Kuznetsov wrote:
> > > A couple of other thoughts:
> > > 1) Having all newly added memory online ASAP is probably what people
> > > want for all vir
1 - 100 of 233 matches
Mail list logo
