Re: [Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()
>>> 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 synchronized for the custom > + * handlers. > + */ > +if ( atomic_read(&v->vm_event_pause_count) ) > +sync_vcpu_execstate(v); It seems to me that the latest with this change using a simple atomic_t won't suffice anymore - you'd now really need to make sure the user mode tools can't resume that vCPU behind your back, which aiui can only be achieved by using a suitable lock (perhaps a read/write one if reading the pause count is more common than updating it). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/traps: Fix failed ASSERT() in do_guest_trap()
>>> 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
> from do_general_protection() passes any vector.
>
> This path is triggered by XTF, which uses `int 0x20` to facilitate returning
> to kernel mode after running specific tests in user mode.
>
> No vectors above 32 have an error code, so adjust the logic to cope.
>
> Reported-by: Wei Liu
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> RFC:
>
> 1) Should we start making use of Linux's "Fixes:" tag?
It wouldn't hurt if someone did, but mentioning the offending commit
in the description would seem enough (and often better) to me. In no
case would I like seeing just a commit ID, without also the title being
quoted, as that will always mean one has to consult the repo for
understanding what exact change was broken (that is, of course,
only for those of us who can't memorize all the commit ID-s and their
respective titles of the last few years).
> 2) I considered using TRAP_nr instead of 32, but "(trapnr < TRAP_nr)" is odd,
> and it hides the visual correctness of seeing that 1u is never shifted out of
> range.
Either variant is fine with me.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable-smoke test] 100382: regressions - FAIL
>>> 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, >> including tests which could not be run: >> build-amd64 5 xen-buildfail REGR. vs. > 100365 > > The patch: > >acpi/hvmloader: Initialize vm_gid data outside ACPI code > > broke Xen build, I think. I've pushed Boris' fixes, and I realize I'm guilty of one of the two issues that needed fixing. Jan ___ 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
> >>> 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 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. 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. Thanks, Luwei Kang ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0
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);
> -EXPORT_SYMBOL(node_data);
> +unsigned int __init arch_get_dma_bitsize(void)
> +{
> +unsigned int node;
> +
> +for_each_online_node(node)
> +if ( node_spanned_pages(node) &&
> + !(node_start_pfn(node) >> (32 - PAGE_SHIFT)) )
> +break;
> +if ( node >= MAX_NUMNODES )
> +panic("No node with memory below 4Gb");
> +
> +return min_t(unsigned int,
> + flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 -
> 1)
> + + PAGE_SHIFT, 32);
You have moved the -1 and -2 inside the flsl() call, which alters its
behaviour quite a bit. Is this intentional or accidental?
~Andrew
> +}
>
> static void dump_numa(unsigned char key)
> {
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1368,16 +1368,7 @@ void __init end_boot_allocator(void)
> init_heap_pages(virt_to_page(bootmem_region_list), 1);
>
> if ( !dma_bitsize && (num_online_nodes() > 1) )
> -{
> -#ifdef CONFIG_X86
> -dma_bitsize = min_t(unsigned int,
> -flsl(NODE_DATA(0)->node_spanned_pages) - 1
> -+ PAGE_SHIFT - 2,
> -32);
> -#else
> -dma_bitsize = 32;
> -#endif
> -}
> +dma_bitsize = arch_get_dma_bitsize();
>
> printk("Domain heap initialised");
> if ( dma_bitsize )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/traps: Fix failed ASSERT() in do_guest_trap()
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.
This path is triggered by XTF, which uses `int 0x20` to facilitate returning
to kernel mode after running specific tests in user mode.
No vectors above 32 have an error code, so adjust the logic to cope.
Reported-by: Wei Liu
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
RFC:
1) Should we start making use of Linux's "Fixes:" tag?
2) I considered using TRAP_nr instead of 32, but "(trapnr < TRAP_nr)" is odd,
and it hides the visual correctness of seeing that 1u is never shifted out of
range.
---
xen/arch/x86/traps.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index c228b45..e822719 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -631,11 +631,8 @@ static void do_guest_trap(unsigned int trapnr,
struct vcpu *v = current;
struct trap_bounce *tb;
const struct trap_info *ti;
-bool_t use_error_code;
-
-ASSERT(trapnr < 32);
-
-use_error_code = (TRAP_HAVE_EC & (1u << trapnr));
+const bool use_error_code =
+((trapnr < 32) && (TRAP_HAVE_EC & (1u << trapnr)));
trace_pv_trap(trapnr, regs->eip, use_error_code, regs->error_code);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.
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 BUG message
stating their absence.
Also, the struct arch_domain is extended with the altp2m_active
attribute, representing the current altp2m activity configuration of the
domain.
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v2: Removed altp2m command-line option: Guard through HVM_PARAM_ALTP2M.
Removed not used altp2m helper stubs in altp2m.h.
---
xen/arch/arm/hvm.c | 79
xen/include/asm-arm/altp2m.h | 4 +--
xen/include/asm-arm/domain.h | 3 ++
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index d999bde..eb524ae 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -32,6 +32,81 @@
#include
+#include
+
+static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
+{
+struct xen_hvm_altp2m_op a;
+struct domain *d = NULL;
+int rc = 0;
+
+if ( copy_from_guest(&a, arg, 1) )
+return -EFAULT;
+
+if ( a.pad1 || a.pad2 ||
+ (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
+ (a.cmd < HVMOP_altp2m_get_domain_state) ||
+ (a.cmd > HVMOP_altp2m_change_gfn) )
+return -EINVAL;
+
+d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
+
+if ( d == NULL )
+return -ESRCH;
+
+if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
+ (a.cmd != HVMOP_altp2m_set_domain_state) &&
+ !d->arch.altp2m_active )
Why not using altp2m_active(d) here?
Also this check looks quite racy. What does prevent another CPU to disable
altp2m at the same time? How the code would behave?
There is a rcu_lock_domain_by_any_id before we get to this check here,
so any other CPU looking to disable altp2m would be waiting there for
the current op to finish up, so there is no race condition AFAICT.
No, rcu_lock_domain_by_any_id only prevents the domain to be fully
destroyed by "locking" the rcu. It does not prevent multiple concurrent
access. You can look at the code if you are not convinced.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/3] livepach: Add .livepatch.hooks functions and test-case
>>> 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. */
>> >> > struct livepatch_build_id dep; /*
>> >> > ELFNOTE_DESC(.livepatch.depends). */
>> >> > -char name[XEN_LIVEPATCH_NAME_SIZE]; /* Name of it. */
>> >> > +livepatch_loadcall_t **load_funcs; /* The array of funcs to call
>> >> > after */
>> >> > +livepatch_unloadcall_t **unload_funcs;/* load and unload of the
>> >> > payload. */
>> >>
>> >> These both seem like they want a const in the middle.
>> >
>> > I did that initially and found out that the calling ->load_funcs[i]
>> > resulted
>> > in _no_ code being called.
>> >
>> > I did not dig in the assembler output to figure out what happend, let me
>> > do that now.
>>
>> Indeed - I can't see how a const modifier here could alter whether
>> or not the pointed to function gets called.
>
> I did a diff on the pre-assemble part (-S) with and without const on the above
> structs. With 'const' we get:
>
> callspin_debug_disable
> .LVL163:
> - .loc 1 1093 0
> - cmpl$0, 324(%rbx)
> - je .L112
> - movl$0, %r12d
> -.LVL164:
> -.L113:
> - .loc 1 1094 0
> - mov %r12d, %edx
> - movq312(%rbx), %rax
> - call*(%rax,%rdx,8)
> - .loc 1 1093 0
> - addl$1, %r12d
> -.LVL165:
> - cmpl%r12d, 324(%rbx)
> - ja .L113
> -.LVL166:
> -.L112:
>
> being removed.
>
> I thought it may have to do with the function not returning anything. But
> even after making the typedef return it still omitted the call
> data->load_funcs[i]();
Odd. I've tried this simple example:
typedef int fn_t(void);
struct s {
unsigned n;
fn_t**fn;
fn_t*const*fnc;
const fn_t**cfn;
};
int test1(const struct s*ps) {
unsigned i;
int rc = 0;
for(i = 0; !rc && i < ps->n; ++i)
rc = ps->fn[i]();
return rc;
}
int test2(const struct s*ps) {
unsigned i;
int rc = 0;
for(i = 0; !rc && i < ps->n; ++i)
rc = ps->fnc[i]();
return rc;
}
int test3(const struct s*ps) {
unsigned i;
int rc = 0;
for(i = 0; !rc && i < ps->n; ++i)
rc = ps->cfn[i]();
return rc;
}
test1() and test2() get compiled identically. test3(), using the field
with the misplaced const, oddly enough gets compiled slightly
differently (and without a warning despite one would seem
warranted), yet the call doesn't get omitted. If, however, I change
the return type of fn_t to void, the function body of test3() ends
up empty, which is a compiler bug afaict, but which also suggests
that you've tried the variant with the misplaced const.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 20/25] arm/altp2m: Add altp2m paging mechanism.
Hi Julien,
>>> [...]
>>>
switch ( fsc )
{
+case FSC_FLT_TRANS:
+{
+if ( altp2m_active(d) )
+{
+const struct npfec npfec = {
+.insn_fetch = 1,
+.gla_valid = 1,
+.kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt :
npfec_kind_with_gla
+};
+
+/*
+ * Copy the entire page of the failing instruction
into the
+ * currently active altp2m view.
+ */
+if ( altp2m_lazy_copy(v, gpa, gva, npfec, &p2m) )
+return;
>>>
>>> I forgot to mention that I think there is a race condition here. If
>>> multiple vCPU (let say A and B) use the same altp2m, they may fault
>>> here.
>>>
>>> If vCPU A already fixed the fault, this function will return false and
>>> continue. So this will lead to inject an instruction abort to the
>>> guest.
>>>
I have solved this issue as well:
In altp2m_lazy_copy, we check whether the faulting address is already
mapped in the current altp2m view. The only reason why the current
altp2m should have a valid entry for the apparently faulting address is
that it was previously (almost simultaneously) mapped by another vcpu.
That is, if the mapping for the faulting address is valid in the altp2m,
we return true and hence let the guest retry (without injecting an
instruction/data abort exception) to access the address in question.
Best regards,
~Sergej
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Save/Restore is not working properly
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 script* to clone a machine is not working either.
> so is it a bug or something or I'm cloning the wrong way?
Thanks for the bug report -- but you're missing a lot of important
information to help us figure out what's going wrong. You need to let
us know what version of Xen you're running, attach all the relevant
config files, and include the relevant console output.
So to begin with -- just to understand -- if you do a simple save /
restore, does that work?
Also, if you just do a save (without pausing), and then restore with
the alternate VM config, does that work?
Thanks,
-George
>
>
>
> *
> #!/bin/bash
>
> : ${2? "Usage: $0 "}
> echo "$1 is source domain id";
> echo "$2 is the destination file to store the image";
> xl save -p $1 $2 ;
> lvremove -f /dev/vg0/vm-clone-lv;
> lvcreate -L10G -s -n vm-clone-lv /dev/vg0/orig-vm ;
> xl restore -e -p /etc/xen/vm-clone.cfg $2;
> xl unpause $1;
>
> --
> Regards
>
>
> ___
> 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] [Qemu-devel] [RFC for 2.8 0/3] Drop support for 64 bit guests on 32 bit hosts
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 bit platform). I'm not actually convinced > things actually work if built or that anyone relies on these > combinations. Consider these patches a way of flushing any such users > out ;-) Adding xen-devel to Cc. 64bit xen hypervisor with 32bit dom0 running 32bit qemu, providing device emulation for 64bit dumUs at least used to be a common setup years ago. I have my doubts this is still the case in recent xen versions, but I guess we better ask the Xen guys ... Can anyone clarify? thanks, Gerd ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] x86/NUMA: cleanup
- 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 this
seems a little awkward)
- no longer open code pfn_to_paddr() in an expression being modified
anyway
- make dump less verbose by logging actual vs intended node IDs only
when they don't match
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -179,7 +179,6 @@ void __init setup_node_bootmem(nodeid_t
start_pfn = start >> PAGE_SHIFT;
end_pfn = end >> PAGE_SHIFT;
-NODE_DATA(nodeid)->node_id = nodeid;
NODE_DATA(nodeid)->node_start_pfn = start_pfn;
NODE_DATA(nodeid)->node_spanned_pages = end_pfn - start_pfn;
@@ -386,16 +385,15 @@ static void dump_numa(unsigned char key)
for_each_online_node ( i )
{
-paddr_t pa = (paddr_t)(NODE_DATA(i)->node_start_pfn + 1)<< PAGE_SHIFT;
-printk("idx%d -> NODE%d start->%lu size->%lu free->%lu\n",
- i, NODE_DATA(i)->node_id,
- NODE_DATA(i)->node_start_pfn,
- NODE_DATA(i)->node_spanned_pages,
+paddr_t pa = pfn_to_paddr(node_start_pfn(i) + 1);
+
+printk("NODE%u start->%lu size->%lu free->%lu\n",
+ i, node_start_pfn(i), node_spanned_pages(i),
avail_node_heap_pages(i));
/* sanity check phys_to_nid() */
-printk("phys_to_nid(%"PRIpaddr") -> %d should be %d\n", pa,
- phys_to_nid(pa),
- NODE_DATA(i)->node_id);
+if ( phys_to_nid(pa) != i )
+printk("phys_to_nid(%"PRIpaddr") -> %d should be %u\n",
+ pa, phys_to_nid(pa), i);
}
j = cpumask_first(&cpu_online_map);
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -1386,21 +1386,21 @@ int memory_add(unsigned long spfn, unsig
goto destroy_directmap;
}
-old_node_start = NODE_DATA(node)->node_start_pfn;
-old_node_span = NODE_DATA(node)->node_spanned_pages;
+old_node_start = node_start_pfn(node);
+old_node_span = node_spanned_pages(node);
orig_online = node_online(node);
if ( !orig_online )
{
dprintk(XENLOG_WARNING, "node %x pxm %x is not online\n",node, pxm);
-NODE_DATA(node)->node_id = node;
NODE_DATA(node)->node_start_pfn = spfn;
NODE_DATA(node)->node_spanned_pages =
epfn - node_start_pfn(node);
node_set_online(node);
-}else
+}
+else
{
-if (NODE_DATA(node)->node_start_pfn > spfn)
+if (node_start_pfn(node) > spfn)
NODE_DATA(node)->node_start_pfn = spfn;
if (node_end_pfn(node) < epfn)
NODE_DATA(node)->node_spanned_pages = epfn - node_start_pfn(node);
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -40,7 +40,6 @@ extern void srat_detect_node(int cpu);
extern void setup_node_bootmem(nodeid_t nodeid, u64 start, u64 end);
extern nodeid_t apicid_to_node[];
-#ifdef CONFIG_NUMA
extern void init_cpu_to_node(void);
static inline void clear_node_cpumask(int cpu)
@@ -56,7 +55,6 @@ extern u8 *memnodemap;
struct node_data {
unsigned long node_start_pfn;
unsigned long node_spanned_pages;
-nodeid_t node_id;
};
extern struct node_data node_data[];
@@ -78,11 +76,6 @@ static inline __attribute__((pure)) node
NODE_DATA(nid)->node_spanned_pages)
extern int valid_numa_range(u64 start, u64 end, nodeid_t node);
-#else
-#define init_cpu_to_node() do {} while (0)
-#define clear_node_cpumask(cpu) do {} while (0)
-#define valid_numa_range(start, end, node) 1
-#endif
void srat_parse_regions(u64 addr);
extern u8 __node_distance(nodeid_t a, nodeid_t b);
x86/NUMA: cleanup
- 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 this
seems a little awkward)
- no longer open code pfn_to_paddr() in an expression being modified
anyway
- make dump less verbose by logging actual vs intended node IDs only
when they don't match
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -179,7 +179,6 @@ void __init setup_node_bootmem(nodeid_t
start_pfn = start >> PAGE_SHIFT;
end_pfn = end >> PAGE_SHIFT;
-NODE_DATA(nodeid)->node_id = nodeid;
NODE_DATA(nodeid)->node_start_pfn = start_pfn;
NODE_DATA(nodeid)->node_spanned_pages = end_pfn - start_pfn;
@@ -386,16 +385,15 @@ static void dump_numa(unsigned char key)
for_each_online_node ( i )
{
-paddr_t pa = (paddr_t)(NODE_DATA(i)->node_start_pfn + 1)<< PAGE_SHIFT;
-p
[Xen-devel] [PATCH 1/2] page-alloc/x86: don't restrict DMA heap to node 0
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 arch-specific logic out
of common code.
Signed-off-by: Jan Beulich
--- 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);
-EXPORT_SYMBOL(node_data);
+unsigned int __init arch_get_dma_bitsize(void)
+{
+unsigned int node;
+
+for_each_online_node(node)
+if ( node_spanned_pages(node) &&
+ !(node_start_pfn(node) >> (32 - PAGE_SHIFT)) )
+break;
+if ( node >= MAX_NUMNODES )
+panic("No node with memory below 4Gb");
+
+return min_t(unsigned int,
+ flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 - 1)
+ + PAGE_SHIFT, 32);
+}
static void dump_numa(unsigned char key)
{
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1368,16 +1368,7 @@ void __init end_boot_allocator(void)
init_heap_pages(virt_to_page(bootmem_region_list), 1);
if ( !dma_bitsize && (num_online_nodes() > 1) )
-{
-#ifdef CONFIG_X86
-dma_bitsize = min_t(unsigned int,
-flsl(NODE_DATA(0)->node_spanned_pages) - 1
-+ PAGE_SHIFT - 2,
-32);
-#else
-dma_bitsize = 32;
-#endif
-}
+dma_bitsize = arch_get_dma_bitsize();
printk("Domain heap initialised");
if ( dma_bitsize )
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -17,6 +17,11 @@ static inline __attribute__((pure)) node
#define node_start_pfn(nid) (pdx_to_pfn(frametable_base_pdx))
#define __node_distance(a, b) (20)
+static inline unsigned int arch_get_dma_bitsize(void)
+{
+return 32;
+}
+
#endif /* __ARCH_ARM_NUMA_H */
/*
* Local variables:
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -86,5 +86,6 @@ extern int valid_numa_range(u64 start, u
void srat_parse_regions(u64 addr);
extern u8 __node_distance(nodeid_t a, nodeid_t b);
+unsigned int arch_get_dma_bitsize(void);
#endif
page-alloc/x86: don't restrict DMA heap to node 0
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 arch-specific logic out
of common code.
Signed-off-by: Jan Beulich
--- 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);
-EXPORT_SYMBOL(node_data);
+unsigned int __init arch_get_dma_bitsize(void)
+{
+unsigned int node;
+
+for_each_online_node(node)
+if ( node_spanned_pages(node) &&
+ !(node_start_pfn(node) >> (32 - PAGE_SHIFT)) )
+break;
+if ( node >= MAX_NUMNODES )
+panic("No node with memory below 4Gb");
+
+return min_t(unsigned int,
+ flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 - 1)
+ + PAGE_SHIFT, 32);
+}
static void dump_numa(unsigned char key)
{
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1368,16 +1368,7 @@ void __init end_boot_allocator(void)
init_heap_pages(virt_to_page(bootmem_region_list), 1);
if ( !dma_bitsize && (num_online_nodes() > 1) )
-{
-#ifdef CONFIG_X86
-dma_bitsize = min_t(unsigned int,
-flsl(NODE_DATA(0)->node_spanned_pages) - 1
-+ PAGE_SHIFT - 2,
-32);
-#else
-dma_bitsize = 32;
-#endif
-}
+dma_bitsize = arch_get_dma_bitsize();
printk("Domain heap initialised");
if ( dma_bitsize )
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -17,6 +17,11 @@ static inline __attribute__((pure)) node
#define node_start_pfn(nid) (pdx_to_pfn(frametable_base_pdx))
#define __node_distance(a, b) (20)
+static inline unsigned int arch_get_dma_bitsize(void)
+{
+return 32;
+}
+
#endif /* __ARCH_ARM_NUMA_H */
/*
* Local variables:
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -86,5 +86,6 @@ extern int valid_numa_range(u64 start, u
void srat_parse_regions(u64 addr);
extern u8 __node_distance(nodeid_t a, nodeid_t b);
+unsigned int arch_get_dma_bitsize(void);
#endif
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] NUMA/x86 related adjustments
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
Re: [Xen-devel] [xen-unstable-smoke test] 100382: regressions - FAIL
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-amd64 5 xen-buildfail REGR. vs. > 100365 The patch: acpi/hvmloader: Initialize vm_gid data outside ACPI code broke Xen build, I think. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] xl dump-core fails, j!=nr_pages
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: j (260243) != nr_pages (262309) What are those missing 2066 pages? Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.
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_ioreq_server *s;
+
+if ( is_mmio )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+p2m_type_t p2mt;
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+if ( dir != IOREQ_WRITE )
+s = NULL;
+else
+{
+s = p2m_get_ioreq_server(currd, &flags);
+
+if ( !(flags & P2M_IOREQ_HANDLE_WRITE_ACCESS) )
+s = NULL;
+}
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
+}
+else
+s = hvm_select_ioreq_server(currd, &p);
Wouldn't it both be more natural and make the logic even easier
to follow if s got set to NULL up front, all the "else"-s dropped,
and a simple
if ( !s )
s = hvm_select_ioreq_server(currd, &p);
be done in the end?
Sorry, Jan. I tried to simplify above code, but found the new code is
still not very
clean, because in some cases the s is supposed to return NULL instead
of to be
set from the hvm_select_ioreq_server().
To keep the same logic, the simplified code looks like this:
case X86EMUL_UNHANDLEABLE:
{
-struct hvm_ioreq_server *s =
-hvm_select_ioreq_server(curr->domain, &p);
+struct hvm_ioreq_server *s = NULL;
+p2m_type_t p2mt = p2m_invalid;
+
+if ( is_mmio && dir == IOREQ_WRITE )
+{
+unsigned long gmfn = paddr_to_pfn(addr);
+
+(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
+
+if ( p2mt == p2m_ioreq_server )
+{
+unsigned int flags;
+
+s = p2m_get_ioreq_server(currd, &flags);
+if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
+s = NULL;
+}
+}
+
+if ( !s && p2mt != p2m_ioreq_server )
+s = hvm_select_ioreq_server(currd, &p);
/* If there is no suitable backing DM, just ignore accesses */
if ( !s )
As you can see, definition of p2mt is moved outside the if ( is_mmio )
judgement,
and is checked against p2m_ioreq_server before we search the ioreq
server's rangeset
in hvm_select_ioreq_server(). So I am not quite satisfied with this
simplification.
Any suggestions?
[snip]
Yu
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [V4 PATCH 0/2] kexec: crash_kexec_post_notifiers boot option related fixes
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 architectures. For example, for x86, kdump routines fail to save other CPUs' registers and disable virtualization extensions. For MIPS OCTEON, it fails to stop the watchdog timer. To fix this problem, call a new kdump friendly function, crash_smp_send_stop(), instead of the smp_send_stop() when crash_kexec_post_notifiers is enabled. crash_smp_send_stop() is a weak function, and it just call smp_send_stop(). Architecture codes should override it so that kdump can work appropriately. This patch set supports only x86 and MIPS. NOTE: - Right solution would be to place crash_smp_send_stop() before __crash_kexec() invocation in all cases and remove smp_send_stop(), but we can't do that until all architectures implement own crash_smp_send_stop() - crash_smp_send_stop()-like work is still needed by machine_crash_shutdown() because crash_kexec() can be called without entering panic() Changes in V4: - Keep to use smp_send_stop if crash_kexec_post_notifiers is not set - Rename panic_smp_send_stop to crash_smp_send_stop - Don't change the behavior for Xen's PV kernel - Support MIPS Changes in V3: https://lkml.org/lkml/2016/7/5/221 - Revise comments, description, and symbol names (the logic doesn't change) - Make crash_kexec_post_notifiers boot option modifiable after boot Changes in V2: https://lkml.org/lkml/2015/7/23/864 - Replace smp_send_stop() call with crash_kexec version which saves cpu states and does cleanups instead of changing execution flow - Drop a fix for Problem 1 - Drop other patches because they aren't needed anymore V1: https://lkml.org/lkml/2015/7/10/316 --- Hidehiro Kawai (2): x86/panic: Replace smp_send_stop() with kdump friendly version in panic path mips/panic: Replace smp_send_stop() with kdump friendly version in panic path arch/mips/cavium-octeon/setup.c | 14 +++ arch/mips/include/asm/kexec.h|1 + arch/mips/kernel/crash.c | 18 ++- arch/mips/kernel/machine_kexec.c |1 + arch/x86/include/asm/kexec.h |1 + arch/x86/include/asm/smp.h |1 + arch/x86/kernel/crash.c | 22 +++--- arch/x86/kernel/smp.c|5 kernel/panic.c | 47 -- 9 files changed, 99 insertions(+), 11 deletions(-) -- Hidehiro Kawai Hitachi, Ltd. Research & Development Group ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path
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 to save other CPUs' registers and disable
virtualization extensions.
To fix this problem, call a new kdump friendly function,
crash_smp_send_stop(), instead of the smp_send_stop() when
crash_kexec_post_notifiers is enabled. crash_smp_send_stop() is a
weak function, and it just call smp_send_stop(). Architecture
codes should override it so that kdump can work appropriately.
This patch only provides x86-specific version.
For Xen's PV kernel, just keep the current behavior.
Changes in V4:
- Keep to use smp_send_stop if crash_kexec_post_notifiers is not set
- Rename panic_smp_send_stop to crash_smp_send_stop
- Don't change the behavior for Xen's PV kernel
Changes in V3:
- Revise comments, description, and symbol names
Changes in V2:
- Replace smp_send_stop() call with crash_kexec version which
saves cpu states and cleans up VMX/SVM
- Drop a fix for Problem 1 at this moment
Reported-by: Daniel Walker
Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
Signed-off-by: Hidehiro Kawai
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc: Eric Biederman
Cc: Masami Hiramatsu
Cc: Daniel Walker
Cc: Xunlei Pang
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Borislav Petkov
Cc: David Vrabel
Cc: Toshi Kani
Cc: Andrew Morton
---
arch/x86/include/asm/kexec.h |1 +
arch/x86/include/asm/smp.h |1 +
arch/x86/kernel/crash.c | 22 +---
arch/x86/kernel/smp.c|5
kernel/panic.c | 47 --
5 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index d2434c1..282630e 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -210,6 +210,7 @@ struct kexec_entry64_regs {
typedef void crash_vmclear_fn(void);
extern crash_vmclear_fn __rcu *crash_vmclear_loaded_vmcss;
+extern void kdump_nmi_shootdown_cpus(void);
#endif /* __ASSEMBLY__ */
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index ebd0c16..f70989c 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -50,6 +50,7 @@ struct smp_ops {
void (*smp_cpus_done)(unsigned max_cpus);
void (*stop_other_cpus)(int wait);
+ void (*crash_stop_other_cpus)(void);
void (*smp_send_reschedule)(int cpu);
int (*cpu_up)(unsigned cpu, struct task_struct *tidle);
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 9616cf7..650830e 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -133,15 +133,31 @@ static void kdump_nmi_callback(int cpu, struct pt_regs
*regs)
disable_local_APIC();
}
-static void kdump_nmi_shootdown_cpus(void)
+void kdump_nmi_shootdown_cpus(void)
{
nmi_shootdown_cpus(kdump_nmi_callback);
disable_local_APIC();
}
+/* Override the weak function in kernel/panic.c */
+void crash_smp_send_stop(void)
+{
+ static int cpus_stopped;
+
+ if (cpus_stopped)
+ return;
+
+ if (smp_ops.crash_stop_other_cpus)
+ smp_ops.crash_stop_other_cpus();
+ else
+ smp_send_stop();
+
+ cpus_stopped = 1;
+}
+
#else
-static void kdump_nmi_shootdown_cpus(void)
+void crash_smp_send_stop(void)
{
/* There are no cpus to shootdown */
}
@@ -160,7 +176,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
/* The kernel is broken so disable interrupts */
local_irq_disable();
- kdump_nmi_shootdown_cpus();
+ crash_smp_send_stop();
/*
* VMCLEAR VMCSs loaded on this cpu if needed.
diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c
index 658777c..68f8cc2 100644
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -32,6 +32,8 @@
#include
#include
#include
+#include
+
/*
* Some notes on x86 processor bugs affecting SMP operation:
*
@@ -342,6 +344,9 @@ struct smp_ops smp_ops = {
.smp_cpus_done = native_smp_cpus_done,
.stop_other_cpus= native_stop_other_cpus,
+#if defined(CONFIG_KEXEC_CORE)
+ .crash_stop_other_cpus = kdump_nmi_shootdown_cpus,
+#endif
.smp_send_reschedule= native_smp_send_reschedule,
.cpu_up = native_cpu_up,
diff --git a/kernel/panic.c b/kernel/panic.c
index ca8cea1..e6480e2 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -71,6 +71,32 @@ void __weak nmi_panic_self_stop(struct pt_regs *regs)
panic_smp_self_stop();
}
+/*
+ * Stop other CPUs in panic. Architecture dependent code may override this
+ * with more suitable version. For example, if the arch
[Xen-devel] [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path
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 other CPUs' registers. Additionally for MIPS
OCTEON, it misses to stop the watchdog timer.
To fix this problem, call a new kdump friendly function,
crash_smp_send_stop(), instead of the smp_send_stop() when
crash_kexec_post_notifiers is enabled. crash_smp_send_stop() is a
weak function, and it just call smp_send_stop(). Architecture
codes should override it so that kdump can work appropriately.
This patch provides MIPS version.
Reported-by: Daniel Walker
Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
Signed-off-by: Hidehiro Kawai
Cc: Ralf Baechle
Cc: David Daney
Cc: Aaro Koskinen
Cc: "Steven J. Hill"
Cc: Corey Minyard
---
I'm not familiar with MIPS, and I don't have a test environment and
just did build tests only. Please don't apply this patch until
someone does enough tests, otherwise simply drop this patch.
---
arch/mips/cavium-octeon/setup.c | 14 ++
arch/mips/include/asm/kexec.h|1 +
arch/mips/kernel/crash.c | 18 +-
arch/mips/kernel/machine_kexec.c |1 +
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index cb16fcc..5537f95 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -267,6 +267,17 @@ static void octeon_crash_shutdown(struct pt_regs *regs)
default_machine_crash_shutdown(regs);
}
+#ifdef CONFIG_SMP
+void octeon_crash_smp_send_stop(void)
+{
+ int cpu;
+
+ /* disable watchdogs */
+ for_each_online_cpu(cpu)
+ cvmx_write_csr(CVMX_CIU_WDOGX(cpu_logical_map(cpu)), 0);
+}
+#endif
+
#endif /* CONFIG_KEXEC */
#ifdef CONFIG_CAVIUM_RESERVE32
@@ -911,6 +922,9 @@ void __init prom_init(void)
_machine_kexec_shutdown = octeon_shutdown;
_machine_crash_shutdown = octeon_crash_shutdown;
_machine_kexec_prepare = octeon_kexec_prepare;
+#ifdef CONFIG_SMP
+ _crash_smp_send_stop = octeon_crash_smp_send_stop;
+#endif
#endif
octeon_user_io_init();
diff --git a/arch/mips/include/asm/kexec.h b/arch/mips/include/asm/kexec.h
index ee25ebb..493a3cc 100644
--- a/arch/mips/include/asm/kexec.h
+++ b/arch/mips/include/asm/kexec.h
@@ -45,6 +45,7 @@ extern const unsigned char kexec_smp_wait[];
extern unsigned long secondary_kexec_args[4];
extern void (*relocated_kexec_smp_wait) (void *);
extern atomic_t kexec_ready_to_reboot;
+extern void (*_crash_smp_send_stop)(void);
#endif
#endif
diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c
index 610f0f3..1723b17 100644
--- a/arch/mips/kernel/crash.c
+++ b/arch/mips/kernel/crash.c
@@ -47,9 +47,14 @@ static void crash_shutdown_secondary(void *passed_regs)
static void crash_kexec_prepare_cpus(void)
{
+ static int cpus_stopped;
unsigned int msecs;
+ unsigned int ncpus;
- unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
+ if (cpus_stopped)
+ return;
+
+ ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
dump_send_ipi(crash_shutdown_secondary);
smp_wmb();
@@ -64,6 +69,17 @@ static void crash_kexec_prepare_cpus(void)
cpu_relax();
mdelay(1);
}
+
+ cpus_stopped = 1;
+}
+
+/* Override the weak function in kernel/panic.c */
+void crash_smp_send_stop(void)
+{
+ if (_crash_smp_send_stop)
+ _crash_smp_send_stop();
+
+ crash_kexec_prepare_cpus();
}
#else /* !defined(CONFIG_SMP) */
diff --git a/arch/mips/kernel/machine_kexec.c b/arch/mips/kernel/machine_kexec.c
index 50980bf3..5972520 100644
--- a/arch/mips/kernel/machine_kexec.c
+++ b/arch/mips/kernel/machine_kexec.c
@@ -25,6 +25,7 @@ void (*_machine_crash_shutdown)(struct pt_regs *regs) = NULL;
#ifdef CONFIG_SMP
void (*relocated_kexec_smp_wait) (void *);
atomic_t kexec_ready_to_reboot = ATOMIC_INIT(0);
+void (*_crash_smp_send_stop)(void) = NULL;
#endif
int
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline baseline-only test] 66949: tolerable FAIL
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-install/l1/l2 fail like 66941 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass version targeted for testing: qemuu53279c76cf071fed07a336948d37c72e3613e0b7 baseline version: qemuu51009170d8fc263cfdcd5a60fe3ba213daa3d15b Last test of basis66941 2016-08-08 21:46:46 Z1 days Testing same since66949 2016-08-09 10:47:08 Z0 days1 attempts People who touched revisions under test: Alberto Garcia Cornelia Huck David Gibson John Snow Kevin Wolf Marc-André Lureau Mark Cave-Ayland Markus Armbruster Peter Maydell Richard Henderson Vladimir Sementsov-Ogievskiy Yi Min Zhao 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 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-xl-
[Xen-devel] [xen-unstable-smoke test] 100382: regressions - FAIL
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 did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386 1 build-check(1) blocked n/a 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 3efeb60c8c78f7113254df6622c2dc1dcf91e7b7 baseline version: xen 7f5c8075364776eb139bbd421ad443ae9e4465dc Last test of basis 100365 2016-08-09 15:01:57 Z0 days Testing same since 100368 2016-08-09 17:01:23 Z0 days7 attempts People who touched revisions under test: Boris Ostrovsky George Dunlap Jan Beulich jobs: build-amd64 fail build-armhf pass build-amd64-libvirt blocked test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked test-amd64-amd64-libvirt blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 3efeb60c8c78f7113254df6622c2dc1dcf91e7b7 Author: Jan Beulich Date: Tue Aug 9 17:31:46 2016 +0200 common: clean up taint logic Drop unused UNSAFE_SMP and BAD_PAGE flags. Style adjstments. Signed-off-by: Jan Beulich Acked-by: George Dunlap commit bea437908b27c751012abe14c4312dd4d159ff23 Author: Boris Ostrovsky Date: Tue Aug 9 17:31:15 2016 +0200 hvmloader: move passthrough initialization from ACPI code Initialize it in hvmloader, avoiding ACPI code's use of xenstore_read() Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit 653d8fb95adc81dc2fbc3594bd63519f68271dc2 Author: Boris Ostrovsky Date: Tue Aug 9 17:30:56 2016 +0200 hvmloader: decide which SSDTs to install in hvmloader With that, xenstore_read() won't need to be done in ACPI code Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit 3bb36fe2aa2c590e52578a6ea65ba992178ef82b Author: Boris Ostrovsky Date: Tue Aug 9 17:30:39 2016 +0200 hvmloader: initialize vm_gid data outside ACPI code This way ACPI code won't use xenstore-read() and hvm_param_set() which are private to hvmloader. Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit c15eea2a1e719577af83bddf793a3a5329ce395d Author: Boris Ostrovsky Date: Tue Aug 9 17:28:59 2016 +0200 acpi/hvmloader: allow acpi_build_tables() callers specify acpi_info values By doing this we can move hvmloader-private interfaces (such as uart_exists(), lpt_exists() etc.) out of the ACPI builder. This will help us with allowing to call the builder from places other than hvmloader. Signed-off-by: Boris Ostrovsky Reviewed-by: Jan Beulich commit edd0028206d14c25ddee2357dca08441ff13cea1 Author: Boris Ostrovsky Date: Tue Aug 9 17:27:39 2016 +0200 hvmloader: provide hvmloader_acpi_build_tables() In preparation for moving out ACPI builder make all BIOSes call hvmloader_acpi_build_tables() instead of calling ACPI code directly. No functional changes. Signed-off-by: Boris Ostrovsky Acked-by: Jan Beulich (qemu changes not included) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 100376: all pass - PUSHED
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 1fbd0ca16a997b68ed320340aef18645e71e8a73
Last test of basis 100364 2016-08-09 10:43:23 Z0 days
Testing same since 100376 2016-08-10 02:45:14 Z0 days1 attempts
People who touched revisions under test:
Ruiyu Ni
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=5aeafb3a254e7cd9e1fb69a0d391388a51c6e210
+ . ./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
5aeafb3a254e7cd9e1fb69a0d391388a51c6e210
+ branch=ovmf
+ revision=5aeafb3a254e7cd9e1fb69a0d391388a51c6e210
+ . ./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
+ '[' x5aeafb3a254e7cd9e1fb69a0d391388a51c6e210 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419
[Xen-devel] xl dump-core fails, j!=nr_pages
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 memory=256 serial="pty" builder="hvm" boot="cd" disk=[ 'file:/disk0.raw,hda,w', 'file:/Media1.iso,hdc:cdrom,r', ] vif=[ 'bridge=br0' ] keymap="de" vfb = [ 'type=vnc,vncunused=1,keymap=de' ] usb=1 usbdevice='tablet' root@macintyre-old:~ # xl info host : macintyre-old release: 3.12.59-60.45-xen version: #1 SMP Sat Jun 25 06:19:03 UTC 2016 (396c69d) machine: x86_64 nr_cpus: 4 max_cpu_id : 15 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz: 2000 hw_caps: b7ebfbff:009ce3bd:28100800:0001::::0100 virt_caps : hvm total_memory : 6135 free_memory: 0 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 7 xen_extra : .20160726T13082 xen_version: 4.7.20160726T13082 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : 2016-07-26 14:08:29 +0100 git:899495b xen_commandline: console=com1 com1=57600 loglvl=all guest_loglvl=all cc_compiler: gcc (SUSE Linux) 4.8.5 cc_compile_by : abuild cc_compile_domain : cc_compile_date: Tue Jul 26 14:08:29 UTC 2016 build_id : b8d2712feab8b81a845316485f986da952d44f73 xend_config_format : 4 Olaf signature.asc Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH V2] common/vm_event: synchronize vCPU state in vm_event_resume()
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_event_resume, before any handlers have been called. This problem especially affects vm_event_set_registers(). Signed-off-by: Razvan Cojocaru --- Changes since V1: - Only call sync_vcpu_execstate() when the vCPU is paused. --- xen/common/vm_event.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c index 941345b..53cab90 100644 --- 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 synchronized for the custom + * handlers. + */ +if ( atomic_read(&v->vm_event_pause_count) ) +sync_vcpu_execstate(v); + +/* * In some cases the response type needs extra handling, so here * we call the appropriate handlers. */ -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [linux-3.18 test] 100372: regressions - FAIL
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 are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 99832 build-amd64-rumpuserxen 6 xen-buildfail like 99832 build-i386-rumpuserxen6 xen-buildfail like 99832 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 99832 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 99832 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 99832 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 14 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 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-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass version targeted for testing: linux6e0f6268e3d1095a1800da36261d40ac53a7100c baseline version: linux0d1097ae44c2566bb8c9eacccd795c456d08c8a5 Last test of basis99832 2016-07-30 16:32:07 Z 10 days Testing same since 100372 2016-08-09 19:20:24 Z0 days1 attempts People who touched revisions under test: Alexey Dobriyan Andrew Morton Andrew Worsley # [MacBookPro10,1] Andrey Ryabinin Awais Belal Bryan Paradis# [MacBookPro9,2] Cameron Gutman Chris Bainbridge # [MacBookPro10,2] David S. Miller Dmitri Epshtein Dmitry Torokhov Florian Westphal Gregory CLEMENT Hui Wang Ilya Dryomov Ingo Molnar James Patrick-Evans Jeff Wu Jiri Slaby Konstantin Khlebnikov Konstantin Simanov # [MacBookPro8,1] Linus Torvalds Lukas Wunner Lukas Wunner # [MacBookPro9,1] Marcin Wojtas Maruthi Bayyavarapu Maruthi Srinivas Bayyavarapu Matt Fleming Maxim Patlasov Miklos Szeredi Pablo Neira Ayuso Peter Wu RafaÅ MiÅecki Rodolfo Giometti Romain Perier Sasha Levin Sinclair Yeh Takashi Iwai Taras Kondratiuk Terry Stockert Thomas Gleixner Thomas Petazzoni Ulf Hansson Vivek Goyal Willy Tarreau Yan, Zheng jobs: build
[Xen-devel] [PATCH 2/2] x86/vmx: conditionally disable LBR support due to TSX format quirk
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
conditions causes a #GP, VM entry will fail due to MSR loading (see
last bullet of SDM 26.4 "Loading MSRS").
This failure can be triggered on a Haswell-EP system with the
following test Linux kernel module:
In domU:
$ cat > lbr.c << EOF
static int __init
lbr_init(void)
{
u64 val;
rdmsrl(MSR_IA32_DEBUGCTLMSR, val);
val |= DEBUGCTLMSR_LBR;
wrmsrl(MSR_IA32_DEBUGCTLMSR, val);
return 0;
}
static void __exit
lbr_cleanup(void)
{
}
module_init(lbr_init);
module_exit(lbr_cleanup);
MODULE_DESCRIPTION("lbr test");
MODULE_LICENSE("GPL");
EOF
$ echo "obj-m += lbr.o" > Makefile
$ make -C /lib/modules/`uname -r`/build M=`pwd` modules
make: Entering directory `/home/ec2-user/linux'
CC [M] /home/ec2-user/lbr.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/ec2-user/lbr.mod.o
LD [M] /home/ec2-user/lbr.ko
make: Leaving directory `/home/ec2-user/linux'
$ sudo insmod lbr.ko
$ Timeout, server not responding.
In dom0:
[...]
(XEN) Failed vm entry (exit reason 0x8022) caused by MSR entry 1 loading.
[...]
(XEN) EXIT MSR load count = 0x0001
(XEN) EXIT MSR store count = 0x0023
(XEN) ENTRY MSR load count = 0x0023
(XEN) msr_count = 35
(XEN) msr_area[0].index=0x01dd .data=0x1fff811911db
...
This change dynamically disables LBR save/load on systems in the
problematic configuration.
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=71adae99ed18
[2]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19fc9ddd61e0
Signed-off-by: Matt Wilson
---
xen/arch/x86/hvm/vmx/vmx.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 3d330b6..c51cefc 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2576,8 +2576,22 @@ static const struct lbr_info *last_branch_msr_get(void)
/* Haswell */
case 60: case 63: case 69: case 70:
/* Broadwell */
-case 61: case 71: case 79: case 86:
+case 61: case 71: case 79: case 86: {
+u64 caps;
+bool_t tsx_support = boot_cpu_has(X86_FEATURE_HLE) ||
+ boot_cpu_has(X86_FEATURE_RTM);
+
+rdmsrl(MSR_IA32_PERF_CAPABILITIES, caps);
+/*
+ * Unimplemented fixups are required if the processor
+ * supports an LBR format that includes TSX information,
+ * but not TSX. Disable LBR save/load on such platforms.
+ */
+if ( !tsx_support && (caps & 4) )
+return NULL;
+
return nh_lbr;
+}
/* Skylake */
case 78: case 94:
/* future */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] x86/vmx: dump MSR load area
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 1bd875a..a540d4e 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1740,6 +1740,20 @@ static void vmx_dump_sel2(char *name, uint32_t lim)
printk("%s:%08x %016"PRIx64"\n", name, limit, base);
}
+static void vmx_dump_vcpu_msr_area(struct vcpu *v)
+{
+const struct vmx_msr_entry *msr_area = v->arch.hvm_vmx.msr_area;
+unsigned int i, msr_count = v->arch.hvm_vmx.msr_count;
+
+printk(" msr_count = %d\n", v->arch.hvm_vmx.msr_count);
+for ( i = 0; i < msr_count; i++ )
+{
+printk(" msr_area[%d].index=0x%08x .data=0x%016lx\n",
+ i, msr_area[i].index, msr_area[i].data);
+}
+}
+
+
void vmcs_dump_vcpu(struct vcpu *v)
{
struct cpu_user_regs *regs = &v->arch.user_regs;
@@ -1879,6 +1893,13 @@ void vmcs_dump_vcpu(struct vcpu *v)
(SECONDARY_EXEC_ENABLE_VPID | SECONDARY_EXEC_ENABLE_VM_FUNCTIONS) )
printk("Virtual processor ID = 0x%04x VMfunc controls = %016lx\n",
vmr16(VIRTUAL_PROCESSOR_ID), vmr(VM_FUNCTION_CONTROL));
+printk("EXIT MSR load count = 0x%04x\n",
+ (uint32_t)vmr(VM_EXIT_MSR_LOAD_COUNT));
+printk("EXIT MSR store count = 0x%04x\n",
+ (uint32_t)vmr(VM_EXIT_MSR_STORE_COUNT));
+printk("ENTRY MSR load count = 0x%04x\n",
+ (uint32_t)vmr(VM_ENTRY_MSR_LOAD_COUNT));
+vmx_dump_vcpu_msr_area(v);
vmx_vmcs_exit(v);
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
