>>> On 10.08.16 at 09:35, wrote:
> --- a/xen/common/vm_event.c
> +++ b/xen/common/vm_event.c
> @@ -388,6 +388,13 @@ void vm_event_resume(struct domain *d, struct
> vm_event_domain *ved)
> v = d->vcpu[rsp.vcpu_id];
>
> /*
> + * Make sure the vCPU state has been synchron
>>> On 10.08.16 at 11:53, wrote:
> c/s 2e426d6 "x86/traps: Drop use_error_code parameter from do_{,guest_}trap()"
> introduced an assertion which covered the correctness of shifting 1u by an
> input parameter.
>
> While all other inputs provide a constants vector, the `int $N` handling path
> fro
>>> On 10.08.16 at 10:57, wrote:
> On Wed, Aug 10, 2016 at 07:43:38AM +, osstest service owner wrote:
>> flight 100382 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/100382/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> incl
> >>> On 03.08.16 at 03:32, wrote:
> >> On 25/07/16 07:09, Kang, Luwei 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 wan
On 10/08/16 10:23, Jan Beulich wrote:
> --- a/xen/arch/x86/numa.c
> +++ b/xen/arch/x86/numa.c
> @@ -355,11 +355,21 @@ void __init init_cpu_to_node(void)
> }
> }
>
> -EXPORT_SYMBOL(cpu_to_node);
> -EXPORT_SYMBOL(node_to_cpumask);
> -EXPORT_SYMBOL(memnode_shift);
> -EXPORT_SYMBOL(memnodemap);
c/s 2e426d6 "x86/traps: Drop use_error_code parameter from do_{,guest_}trap()"
introduced an assertion which covered the correctness of shifting 1u by an
input parameter.
While all other inputs provide a constants vector, the `int $N` handling path
from do_general_protection() passes any vector.
Hello Tamas,
On 09/08/2016 21:16, Tamas K Lengyel wrote:
On Wed, Aug 3, 2016 at 10:54 AM, Julien Grall wrote:
Hello Sergej,
On 01/08/16 18:10, Sergej Proskurin wrote:
This commit moves the altp2m-related code from x86 to ARM. Functions
that are no yet supported notify the caller or print a
>>> On 09.08.16 at 20:01, wrote:
>> >> > @@ -70,7 +71,11 @@ struct payload {
>> >> > unsigned int nsyms; /* Nr of entries in .strtab
>> >> > and
>> >> > symbols. */
>> >> > struct livepatch_build_id id;/*
>> >> > ELFNOTE_DESC(.note.gnu.build-id) of the payload
Hi Julien,
>>> [...]
>>>
switch ( fsc )
{
+case FSC_FLT_TRANS:
+{
+if ( altp2m_active(d) )
+{
+const struct npfec npfec = {
+.insn_fetch = 1,
+.gla_valid = 1,
+
On Sun, Aug 7, 2016 at 4:21 PM, Cendrin Sa wrote:
> Hi,
> I was searching a way to clone a machine using both memory and disk
> approach.
> I checked xen save/restore but after restoring, I can only work some seconds
> with my machine and it will crash with the_kernel_task_hang_up.
> using an scri
On Di, 2016-08-09 at 16:55 +0100, Alex Bennée wrote:
> Hi,
>
> I'm proposing for the 2.8 cycle we officially drop supporting 64 bit
> guests on 32 bit hosts. For most of the KVM targets it doesn't make
> any sense anyway and for TCG it makes things harder (e.g. supporting
> 64 bit atomics on a 32
- drop the only left CONFIG_NUMA conditional (this is always true)
- drop struct node_data's node_id field (being always equal to the
node_data[] array index used)
- don't open code node_{start,end}_pfn() nor node_spanned_pages()
except when used as lvalues (those could be converted too, but th
When node zero has no memory, the DMA bit width will end up getting set
to 9, which is obviously not helpful to hold back a reasonable amount
of low enough memory for Dom0 to use for DMA purposes. Find the lowest
node with memory below 4Gb instead.
Introduce arch_get_dma_bitsize() to keep this arc
1: page-alloc/x86: don't restrict DMA heap to node 0
2: x86/NUMA: cleanup
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On Wed, Aug 10, 2016 at 07:43:38AM +, osstest service owner wrote:
> flight 100382 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/100382/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build
On Wed, Aug 10, Olaf Hering wrote:
This fails also with 4.4/4.5/4.6. Is 'xl dump-core' supposed to work
with HVM guests? I think at some point 'xm dump-core' used to work, just
crash(1) could not deal with the result.
> xc: info: j (63635) != nr_pages (65709)
> memory=256
> memory=1024
xc: info
On 8/8/2016 11:40 PM, Jan Beulich wrote:
On 12.07.16 at 11:02, wrote:
@@ -178,8 +179,34 @@ static int hvmemul_do_io(
break;
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_iore
Daniel Walker reported problems which happens when
crash_kexec_post_notifiers kernel option is enabled
(https://lkml.org/lkml/2015/6/24/44).
In that case, smp_send_stop() is called before entering kdump routines
which assume other CPUs are still online. This causes some issues
depending on archit
Daniel Walker reported problems which happens when
crash_kexec_post_notifiers kernel option is enabled
(https://lkml.org/lkml/2015/6/24/44).
In that case, smp_send_stop() is called before entering kdump routines
which assume other CPUs are still online. As the result, for x86,
kdump routines fail
Daniel Walker reported problems which happens when
crash_kexec_post_notifiers kernel option is enabled
(https://lkml.org/lkml/2015/6/24/44).
In that case, smp_send_stop() is called before entering kdump routines
which assume other CPUs are still online. As the result, kdump
routines fail to save
This run is configured for baseline tests only.
flight 66949 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66949/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-insta
flight 100382 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100382/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 100365
Tests which
flight 100376 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100376/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5aeafb3a254e7cd9e1fb69a0d391388a51c6e210
baseline version:
ovmf 1fbd0ca16a997b68ed320
With staging-4.7 'xl dump-core hvm.cfg file' fails:
root@macintyre-old:~ # xl - create -cdVf hvm.cfg
... wait ...
root@macintyre-old:~ # xl dump-core x x.dump
xc: info: j (63635) != nr_pages (65709)
hvm.cfg:
name="x"
description="y"
uuid="0529a09c-2430-48e5-8c09-085d4e2380a8"
memory=1024
memo
Vm_event_vcpu_pause() needs to use vcpu_pause_nosync() in order
for the current vCPU to not get stuck. A consequence of this is
that the custom vm_event response handlers will not always see
the real vCPU state in v->arch.user_regs. This patch makes sure
that the state is always synchronized in vm_
flight 100372 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100372/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 11 guest-start fail REGR. vs. 99832
Regressions which ar
From: Matt Wilson
Systems that support LBR formats that include TSX information but do
not support TSX require special handling when saving and restoring MSR
values. For example, see the Linux kernel quirks[1, 2] in the MSR
context switching code. As a wrmsr with certain values under these
condit
From: Matt Wilson
... as it is very helpful to diagnose VM entry failures due to MSR
loading.
Signed-off-by: Matt Wilson
---
xen/arch/x86/hvm/vmx/vmcs.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 1b
101 - 128 of 128 matches
Mail list logo