Re: [Xen-devel] falha para instalar VM

[Julio Cesar Begalli]

Mai algumas informações:

soemrjoc:/backup/SOEM # rpm -qa | grep xen
xen-libs-4.2.2_06-0.7.1
xen-tools-4.2.2_06-0.7.1
kernel-xen-base-3.0.101-0.47.52.1
kernel-xen-3.0.101-0.47.52.1
xen-4.2.5_06-0.7.1
soemrjoc:/backup/SOEM #
soemrjoc:/backup/SOEM #
soemrjoc:/backup/SOEM # uname -r
3.0.101-0.47.52-xen
soemrjoc:/backup/SOEM #

From: Julio Cesar Begalli
Sent: terça-feira, 22 de setembro de 2015 11:53
To: 'xen-devel@lists.xen.org'
Subject: falha para instalar VM

Olá,

Estou tentando instalar um windons 7 dendro de uma VM no Linux,só que já tentei 
e não consigo,aparece a falha abaixo,voces podem me ajudar por favor ?

Grato,Júlio


[cid:image001.png@01D0F52D.92514F00]
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH for-4.6 0/2] libxl: devd fixes

[Roger Pau Monne]

The following patches fix an error when reconnecting a device that's handled 
by a driver domain and a possible race when doing the cleanup of the backend 
path.

I think both should be included in 4.6, since this a regression as compared 
to using udev inside of the driver domain.

Roger.

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

[Xen-devel] [PATCH for-4.6 1/2] libxl: fix devd removal path

[Roger Pau Monne]

The current flow of the devd helper (in charge of launching hotplug scripts
inside of driver domains) is to wait for the device backend to switch to
state 6 (XenbusStateClosed) and then remove it. This is not correct, since
a domain can reconnect it's PV devices as many times as it wants.

In order to fix this, introduce the following logic: the control domain will
set the "online" backend node to 0 when it wants the driver domain to
disconnect the device, so now the condition applied in devd is that "state"
must be 6 and "online" 0 in order to proceed with the disconnection.

Signed-off-by: Roger Pau Monné 
Reported-by: Alex Velazquez 
Cc: Alex Velazquez 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl.c| 38 --
 tools/libxl/libxl_device.c | 11 ++-
 2 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 10d1909..1d1917e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4410,32 +4410,42 @@ static void backend_watch_callback(libxl__egc *egc, 
libxl__ev_xswatch *watch,
 libxl__ao *nested_ao = libxl__nested_ao_create(ddomain->ao);
 STATE_AO_GC(nested_ao);
 char *p, *path;
-const char *sstate;
-int state, rc, num_devs;
+const char *sstate, *sonline;
+int state, online, rc, num_devs;
 libxl__device *dev = NULL;
 libxl__ddomain_device *ddev = NULL;
 libxl__ddomain_guest *dguest = NULL;
 bool free_ao = false;
 
-/* Check if event_path ends with "state" and truncate it */
-if (strlen(event_path) < strlen("state"))
+/* Check if event_path ends with "state" or "online" and truncate it. */
+if (strlen(event_path) < strlen("state") ||
+strlen(event_path) < strlen("online"))
 goto skip;
 
 path = libxl__strdup(gc, event_path);
-p = path + strlen(path) - strlen("state") - 1;
-if (*p != '/')
-goto skip;
-*p = '\0';
-p++;
-if (strcmp(p, "state") != 0)
-goto skip;
+p = strstr(path, "/state");
+if (p != NULL) {
+*p = '\0';
+} else {
+p = strstr(path, "/online");
+if (p == NULL)
+goto skip;
+*p = '\0';
+}
 
-/* Check if the state is 1 (XenbusStateInitialising) or greater */
-rc = libxl__xs_read_checked(gc, XBT_NULL, event_path, );
+/* Fetch the value of the state and online nodes. */
+rc = libxl__xs_read_checked(gc, XBT_NULL, GCSPRINTF("%s/state", path),
+);
 if (rc || !sstate)
 goto skip;
 state = atoi(sstate);
 
+rc = libxl__xs_read_checked(gc, XBT_NULL, GCSPRINTF("%s/online", path),
+);
+if (rc || !sonline)
+goto skip;
+online = atoi(sonline);
+
 dev = libxl__zalloc(NOGC, sizeof(*dev));
 rc = libxl__parse_backend_path(gc, path, dev);
 if (rc)
@@ -4477,7 +4487,7 @@ static void backend_watch_callback(libxl__egc *egc, 
libxl__ev_xswatch *watch,
 rc = add_device(egc, nested_ao, dguest, ddev);
 if (rc > 0)
 free_ao = true;
-} else if (state == XenbusStateClosed) {
+} else if (state == XenbusStateClosed && online == 0) {
 /*
  * Removal of an active device, remove it from the list and
  * free it's data structures if they are no longer needed.
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index bee5ed5..51da10e 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -837,16 +837,17 @@ void libxl__initiate_device_remove(libxl__egc *egc,
 goto out;
 }
 
+rc = libxl__xs_write_checked(gc, t, online_path, "0");
+if (rc) {
+LOG(ERROR, "unable to write to xenstore path %s", online_path);
+goto out;
+}
+
 /*
  * Check if device is already in "closed" state, in which case
  * it should not be changed.
  */
  if (state && atoi(state) != XenbusStateClosed) {
-rc = libxl__xs_write_checked(gc, t, online_path, "0");
-if (rc) {
-LOG(ERROR, "unable to write to xenstore path %s", online_path);
-goto out;
-}
 rc = libxl__xs_write_checked(gc, t, state_path, GCSPRINTF("%d", 
XenbusStateClosing));
 if (rc) {
 LOG(ERROR, "unable to write to xenstore path %s", state_path);
-- 
1.9.5 (Apple Git-50.3)


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

Re: [Xen-devel] Is: Make XENVER_* use XSM, seperate the different ops in smaller security domains. Was:Re: [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

[Daniel De Graaf]

On 17/09/15 14:45, Konrad Rzeszutek Wilk wrote:

. snip..

The build id of the current running hypervisor should belong in the
xeninfo hypercall.  It is not specific to xsplice.

However in the previous reviews it was pointed out that it should only be 
accessible to dom0.

Or to any domains as long as the XSM allows (and is turned on) - so not the 
default dummy one.

That is a bit of 'if' extra complexity which I am not sure is worth it?

DomU can already read the build information such as changeset, compile
time, etc.  Build-id is no more special or revealing.

I would take this as an argument *against* giving DomU access to those
pieces of information in details and not as an argument for
*additionally* giving it access to build-id.

With build-id we have the chance to shape a not-yet-established API and
I would like to follow the Principle of least privilege wherever it
makes sense.

To reach a similar security level with the existing API, it might make
sense to limit DomU access to compile date, compile time, compiled by,
compiled domain, compiler version and command line details, xen extra
version, and xen changeset.  Basically anything that might help DomUs to
uniquely identify a Xen build.

The approach can not directly drop access to those fields, as that would
break an existing API, but it could restrict the detail level handed out
to DomU.


These are all valid arguments to be made, but please lets fix the issue
properly rather than hacking build-id on the side of an unrelated component.

 From my point of view, the correct course of action is this:

* Split the current XSM model to contain separate attributes for general
and privileged information.
** For current compatibility, all existing XENVER_* subops fall into general
* Apply an XSM check at the very start of the hypercall.
* Extend do_xen_version() to take 3 parameters.  (It is curious that it
didn't take a length parameter before)
** This is still ABI compatible, as existing subops simply ignore the
parameter.


Or we can just use 1024 bytes space the XENVER_* use.


* Introduce new XENVER_build_id subop which is documented to require the
3-parameter version of the hypercall.
** This subop falls into straight into privileged information.

This will introduce build-id in its correct location, with appropriate
restrictions.

Moving forwards, we really should have an audit of the existing XENVER_*
subops.  Some are clearly safe/required for domU to read, but some such
as XENVER_commandline have no business being accessible.  A separate
argument, from the repeatable build point of view, says that compilation
information isn't useful at all.

Depending on how we wish to fix the issue, we could either do a blanket
move of the subops into the privileged XSM catagory, or introduce a 3rd
"legacy privileged" category to allow the admin to control access on a
per-vm basis.


CC-ing Daniel. Changing title.


With XSM enabled, I think the correct thing to do is to have a distinct
permission so that an admin can do per-VM controls.  Without XSM enabled,
how common is the case where some VMs need to get this information and
some need it hidden?  A global (command line controlled?) enable of the
feature for domUs seems like a reasonable solution if this is uncommon.

As far as the xsm_default_t value, this is really what XSM_OTHER is for,
but if there are going to be many instances of this type of data, a new
value like XSM_PRIV_INFOLEAK could be introduced.

--
Daniel De Graaf
National Security Agency

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

[Xen-devel] [PATCH 3.19.y-ckt 002/102] x86/ldt: Make modify_ldt synchronous

[Kamal Mostafa]

3.19.8-ckt7 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Andy Lutomirski 

commit 37868fe113ff2ba814b3b4eb12df214df555f8dc upstream.

modify_ldt() has questionable locking and does not synchronize
threads.  Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.

This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.

This fixes some fallout from the CVE-2015-5157 fixes.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Borislav Petkov 
Cc: Andrew Cooper 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Sasha Levin 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: secur...@kernel.org 
Cc: xen-devel 
Link: 
http://lkml.kernel.org/r/4c6978476782160600471bd865b318db34c7b628.1438291540.git.l...@kernel.org
Signed-off-by: Ingo Molnar 
[ kamal: backport to 3.13-stable: dropped comment changes in switch_mm();
  included asm/mmu_context.h in perf_event.c; context ]
Signed-off-by: Kamal Mostafa 
---
 arch/x86/include/asm/desc.h|  15 ---
 arch/x86/include/asm/mmu.h |   3 +-
 arch/x86/include/asm/mmu_context.h |  48 ++-
 arch/x86/kernel/cpu/common.c   |   4 +-
 arch/x86/kernel/cpu/perf_event.c   |  13 +-
 arch/x86/kernel/ldt.c  | 262 -
 arch/x86/kernel/process_64.c   |   4 +-
 arch/x86/kernel/step.c |   6 +-
 arch/x86/power/cpu.c   |   3 +-
 9 files changed, 208 insertions(+), 150 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index a94b82e..6912618 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -280,21 +280,6 @@ static inline void clear_LDT(void)
set_ldt(NULL, 0);
 }
 
-/*
- * load one particular LDT into the current CPU
- */
-static inline void load_LDT_nolock(mm_context_t *pc)
-{
-   set_ldt(pc->ldt, pc->size);
-}
-
-static inline void load_LDT(mm_context_t *pc)
-{
-   preempt_disable();
-   load_LDT_nolock(pc);
-   preempt_enable();
-}
-
 static inline unsigned long get_desc_base(const struct desc_struct *desc)
 {
return (unsigned)(desc->base0 | ((desc->base1) << 16) | ((desc->base2) 
<< 24));
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 876e74e..b6b7bc3 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
  * we put the segment information here.
  */
 typedef struct {
-   void *ldt;
-   int size;
+   struct ldt_struct *ldt;
 
 #ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index 4b75d59..1ab38a4 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -19,6 +19,50 @@ static inline void paravirt_activate_mm(struct mm_struct 
*prev,
 #endif /* !CONFIG_PARAVIRT */
 
 /*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+   /*
+* Xen requires page-aligned LDTs with special permissions.  This is
+* needed to prevent us from installing evil descriptors such as
+* call gates.  On native, we could merge the ldt_struct and LDT
+* allocations, but it's not worth trying to optimize.
+*/
+   struct desc_struct *entries;
+   int size;
+};
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+   struct ldt_struct *ldt;
+
+   /* lockless_dereference synchronizes with smp_store_release */
+   ldt = lockless_dereference(mm->context.ldt);
+
+   /*
+* Any change to mm->context.ldt is followed by an IPI to all
+* CPUs with the mm active.  The LDT will not be freed until
+* after the IPI is handled by all such CPUs.  This means that,
+* if the ldt_struct changes before we return, the values we see
+* will be safe, and the new values will be loaded before we run
+* any user code.
+*
+* NB: don't try to convert this to use RCU without extreme care.
+* We would still need IRQs off, because we don't want to change
+* the local LDT after an IPI loaded a newer value 

Re: [Xen-devel] rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

[Andy Lutomirski]

On Tue, Sep 22, 2015 at 11:23 AM, Konrad Rzeszutek Wilk
 wrote:
> On Sun, Sep 20, 2015 at 09:49:04PM -0700, Andy Lutomirski wrote:
>> On Fri, Sep 18, 2015 at 12:04 PM, Borislav Petkov  wrote:
>> > On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote:
>> >> In any event, Borislav, you must have typed rdmsr_safe for a reason :)
>> >
>> > Wasn't me:
>> >
>> > 6c62aa4a3c12 ("x86: make amd.c have 64bit support code")
>> >
>> > I think the error handling of rdmsrl_safe() was needed to do the pfn
>> > games which are done in the if-clause.
>>
>> I just tried it.  rdmsrl_safe and friends definitely work fine in that
>> code.  I think that Linux's Xen startup code is buggy and fails to set
>> up early exception handling.
>>
>> Try this (horribly whitespace damaged):
>>
>>  static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>>  {
>> +   u64 tmp;
>>  #ifdef CONFIG_X86_64
>> c->x86_clflush_size = 64;
>> c->x86_phys_bits = 36;
>> @@ -752,6 +753,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
>> *c)
>> c->cpu_index = 0;
>> filter_cpuid_features(c, false);
>>
>> +   pr_err("trying to crash\n");
>> +   rdmsrl_safe(0x12345678, );
>> +
>>
>> It works fine.  I bet it crashes on a Xen guest, though.  I assume
>> that Xen just works in most cases by luck.
>
> (d31) mapping kernel into physical memory
> (d31) about to get started...
> (XEN) traps.c:3151: GPF (): 82d0801a31ed -> 82d08023c77b
> (XEN) traps.c:459:d31v0 Unhandled general protection fault fault/trap [#13] 
> on VCPU 0 [ec=]
> (XEN) domain_crash_sync called from entry.S: fault at 82d080238213 
> create_bounce_frame+0x12b/0x13a
> (XEN) Domain 31 (vcpu#0) crashed on cpu#35:
> (XEN) [ Xen-4.5.0  x86_64  debug=n  Not tainted ]
> (XEN) CPU:35
> (XEN) RIP:e033:[]
> (XEN) RFLAGS: 0246   EM: 1   CONTEXT: pv guest
> (XEN) rax:    rbx: 81c03e64   rcx: 12345678
> (XEN) rdx: 81c03de8   rsi: 81c03dec   rdi: 12345278
> (XEN) rbp: 81c03e48   rsp: 81c03dd0   r8:  7420676e69797274
> (XEN) r9:  6873617263206f74   r10:    r11: 
> (XEN) r12: 12345678   r13: 81c03f00   r14: 
> (XEN) r15:    cr0: 8005003b   cr4: 001526f0
> (XEN) cr3: 0014e8c97000   cr2: 
> (XEN) ds:    es:    fs:    gs:    ss: e02b   cs: e033
> (XEN) Guest stack trace from rsp=81c03dd0:
> (XEN)12345678   81041b64
> (XEN)0001e030 00010046 81c03e18 e02b
> (XEN)81041b5d 81c03e48 00811809 
> (XEN)01a0 0100 82009000 81c03e68
> (XEN)81d211ea   81c03ed8
> (XEN)81d1be59 81c03ed8 811892ab 0010
> (XEN)81c03ee8 81c03ea8 697a696c61697469 81f15442
> (XEN) 81db3900  
> (XEN) 81c03f28 81d10f0a 
> (XEN)   
> (XEN)   81c03f38
> (XEN)81d10603 81c03ff8 81d15f5c 
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN) ffd83a031f898b75 22400800 0001
> (XEN)  00010102464c457f 
> (XEN)0001003e0003 0940 0040 12a0
> (XEN)00380040 001100120044 00050001 
> [root@ovs107 ~]#
>
> (gdb) x/20i 0x81041b64
>0x81041b64:  rdmsr
>

Exactly.  I think that Xen is missing code to wire up early_fixup_exception.

--Andy

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

[Xen-devel] Page Table Entry Modifications

[Gohar Irfan]

Hi All,

I want to know if, in the case of HVM (shadow page tables), we can change
the machine frame number pointed to by a page table entry?
An overly simplified example would be: let's say I have page number 10 that
is pointing to machine frame number 10, but I would like it to point to
machine frame number 1? Can this be achieved inside the "sh_page_fault"
function inside "xen/arch/x86/mm/shadow/multi.c" as this seems like a
relevant place for this modification to me.

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

Re: [Xen-devel] rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

[Konrad Rzeszutek Wilk]

On Sun, Sep 20, 2015 at 09:49:04PM -0700, Andy Lutomirski wrote:
> On Fri, Sep 18, 2015 at 12:04 PM, Borislav Petkov  wrote:
> > On Fri, Sep 18, 2015 at 08:20:46AM -0700, Andy Lutomirski wrote:
> >> In any event, Borislav, you must have typed rdmsr_safe for a reason :)
> >
> > Wasn't me:
> >
> > 6c62aa4a3c12 ("x86: make amd.c have 64bit support code")
> >
> > I think the error handling of rdmsrl_safe() was needed to do the pfn
> > games which are done in the if-clause.
> 
> I just tried it.  rdmsrl_safe and friends definitely work fine in that
> code.  I think that Linux's Xen startup code is buggy and fails to set
> up early exception handling.
> 
> Try this (horribly whitespace damaged):
> 
>  static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>  {
> +   u64 tmp;
>  #ifdef CONFIG_X86_64
> c->x86_clflush_size = 64;
> c->x86_phys_bits = 36;
> @@ -752,6 +753,9 @@ static void __init early_identify_cpu(struct cpuinfo_x86 
> *c)
> c->cpu_index = 0;
> filter_cpuid_features(c, false);
> 
> +   pr_err("trying to crash\n");
> +   rdmsrl_safe(0x12345678, );
> +
> 
> It works fine.  I bet it crashes on a Xen guest, though.  I assume
> that Xen just works in most cases by luck.

(d31) mapping kernel into physical memory
(d31) about to get started...
(XEN) traps.c:3151: GPF (): 82d0801a31ed -> 82d08023c77b
(XEN) traps.c:459:d31v0 Unhandled general protection fault fault/trap [#13] on 
VCPU 0 [ec=]
(XEN) domain_crash_sync called from entry.S: fault at 82d080238213 
create_bounce_frame+0x12b/0x13a
(XEN) Domain 31 (vcpu#0) crashed on cpu#35:
(XEN) [ Xen-4.5.0  x86_64  debug=n  Not tainted ]
(XEN) CPU:35
(XEN) RIP:e033:[]
(XEN) RFLAGS: 0246   EM: 1   CONTEXT: pv guest
(XEN) rax:    rbx: 81c03e64   rcx: 12345678
(XEN) rdx: 81c03de8   rsi: 81c03dec   rdi: 12345278
(XEN) rbp: 81c03e48   rsp: 81c03dd0   r8:  7420676e69797274
(XEN) r9:  6873617263206f74   r10:    r11: 
(XEN) r12: 12345678   r13: 81c03f00   r14: 
(XEN) r15:    cr0: 8005003b   cr4: 001526f0
(XEN) cr3: 0014e8c97000   cr2: 
(XEN) ds:    es:    fs:    gs:    ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=81c03dd0:
(XEN)12345678   81041b64
(XEN)0001e030 00010046 81c03e18 e02b
(XEN)81041b5d 81c03e48 00811809 
(XEN)01a0 0100 82009000 81c03e68
(XEN)81d211ea   81c03ed8
(XEN)81d1be59 81c03ed8 811892ab 0010
(XEN)81c03ee8 81c03ea8 697a696c61697469 81f15442
(XEN) 81db3900  
(XEN) 81c03f28 81d10f0a 
(XEN)   
(XEN)   81c03f38
(XEN)81d10603 81c03ff8 81d15f5c 
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN) ffd83a031f898b75 22400800 0001
(XEN)  00010102464c457f 
(XEN)0001003e0003 0940 0040 12a0
(XEN)00380040 001100120044 00050001 
[root@ovs107 ~]# 

(gdb) x/20i 0x81041b64
   0x81041b64:  rdmsr  

> 
> --Andy

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf 9a470dae60ed0c57afdf61342616dd1768ba5ec8
baseline version:
 ovmf 2f667c5488c81924861901d4d7c6f4bb170ffb69

Last test of basis37992  2015-09-19 08:51:15 Z3 days
Testing same since38001  2015-09-21 14:24:02 Z1 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Eric Dong 
  Jeff Fan 
  Laszlo Ersek 
  Qiu Shumin 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Yang Jadis 

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



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

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

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


Push not applicable.


commit 9a470dae60ed0c57afdf61342616dd1768ba5ec8
Author: Laszlo Ersek 
Date:   Fri Sep 18 13:58:35 2015 +

ArmVirtPkg: PlatformIntelBdsLib: signal ReadyToBoot on direct kernel boot

According to the UEFI spec, EFI_EVENT_GROUP_READY_TO_BOOT "is notified by
the system when the Boot Manager is about to load and execute a boot
option". ArmVirtPkg doesn't do this currently when launching a kernel from
the QEMU command line. OvmfPkg does (see git commit 28a34033ee).

At least two edk2-wide callbacks are worth mentioning:

- OnReadyToBoot() in
  "MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c" performs
  variable reclaim and (optionally) installs variable usage statistics as
  a vendor config table;

- OnReadyToBoot() in
  "SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c"
  installs the image execution info table if it doesn't exist yet, in
  SecureBoot-enabled builds.

Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Ard Biesheuvel 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18513 
6f19259b-4bc3-4df7-8a09-765794883524

commit 7b577b246d34ace481041ad1599507121d5d7eed
Author: Qiu Shumin 
Date:   Fri Sep 18 05:51:14 2015 +

ShellBinPkg: Ia32/X64 Shell binary update.

The binaries of ShellBinPkg are generated with ShellPkg project 18507. The 
binaries are built with no debug information by building with "RELEASE" target.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18511 
6f19259b-4bc3-4df7-8a09-765794883524

commit 09d1c9e6939af68bfbe545dba1b1c053b96712b4
Author: Samer El-Haj-Mahmoud 
Date:   Fri Sep 18 02:58:31 2015 +

ShellPkg: Added SMBIOS 2.8 Type 17 changes to smbiosview

Updated smbiosview to decode SMBIOS Type 17 MinimumVoltage, MaximumVoltage, 
and ConfiguredVoltage

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud 
Reviewed-by: Jaben Carsey 

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18507 
6f19259b-4bc3-4df7-8a09-765794883524

commit 08b822e56dc43666d586468a8b6fba69beda5eeb
Author: Samer El-Haj-Mahmoud 
Date:   Fri Sep 18 02:53:06 2015 +

ShellPkg: Added SMBIOS 3.0 support in dmem.

Added SMBIOS 3.0 support in dmdem Shell command since SMBIOS 3.0 uses a 
different GUID in the System Configuration Table.

Contributed-under: TianoCore Contribution Agreement 1.0

[Xen-devel] [xen-4.6-testing test] 62163: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   5 xen-install   fail REGR. vs. 62015
 test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail 
REGR. vs. 62015
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 19 
guest-start/debianhvm.repeat fail REGR. vs. 62015

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 62015
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
62015
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 62015
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 62015
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail blocked in 62015

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   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-xl-vhd   9 debian-di-installfail   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 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-vhd  11 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-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  63e3edcc6c5f4ffcee7f0f63a161ba6f58ac99ed
baseline version:
 xen  70d63e48077f8fee8eda6d8d95eeda52a34d9077

Last test of basis62015  2015-09-14 22:22:30 Z7 days
Failing since 62089  2015-09-17 06:48:20 Z4 days2 attempts
Testing same since62163  2015-09-19 12:37:10 Z2 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chunyan Liu 
  Ian Campbell 
  Jan Beulich 

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

[Xen-devel] [PATCH] IOMMU: complete/correct comment explaining "iommu=" sub-options

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -31,13 +31,19 @@ static void iommu_dump_p2m_table(unsigne
  *
  *   off|no|false|disable   Disable IOMMU (default)
  *   force|required Don't boot unless IOMMU is enabled
+ *   no-intremapDisable interrupt remapping
+ *   verboseBe more verbose
+ *   debug  Enable debugging messages and checks
  *   workaround_bios_bugWorkaround some bios issue to still enable
-VT-d, don't guarantee security
+ *  VT-d, don't guarantee security
  *   dom0-passthrough   No DMA translation at all for Dom0
  *   dom0-strictNo 1:1 memory mapping for Dom0
+ *   no-sharept Don't share VT-d and EPT page tables
  *   no-snoop   Disable VT-d Snoop Control
  *   no-qinval  Disable VT-d Queued Invalidation
- *   no-intremapDisable VT-d Interrupt Remapping
+ *   no-igfxDisable VT-d for IGD devices (insecure)
+ *   no-amd-iommu-perdev-intremap Don't use per-device interrupt remapping
+ *  tables (insecure)
  */
 custom_param("iommu", parse_iommu_param);
 bool_t __initdata iommu_enable = 1;



IOMMU: complete/correct comment explaining "iommu=" sub-options

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -31,13 +31,19 @@ static void iommu_dump_p2m_table(unsigne
  *
  *   off|no|false|disable   Disable IOMMU (default)
  *   force|required Don't boot unless IOMMU is enabled
+ *   no-intremapDisable interrupt remapping
+ *   verboseBe more verbose
+ *   debug  Enable debugging messages and checks
  *   workaround_bios_bugWorkaround some bios issue to still enable
-VT-d, don't guarantee security
+ *  VT-d, don't guarantee security
  *   dom0-passthrough   No DMA translation at all for Dom0
  *   dom0-strictNo 1:1 memory mapping for Dom0
+ *   no-sharept Don't share VT-d and EPT page tables
  *   no-snoop   Disable VT-d Snoop Control
  *   no-qinval  Disable VT-d Queued Invalidation
- *   no-intremapDisable VT-d Interrupt Remapping
+ *   no-igfxDisable VT-d for IGD devices (insecure)
+ *   no-amd-iommu-perdev-intremap Don't use per-device interrupt remapping
+ *  tables (insecure)
  */
 custom_param("iommu", parse_iommu_param);
 bool_t __initdata iommu_enable = 1;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar  wrote:
> >
> > Linus, what's your preference?
> 
> So quite frankly, is there any reason we don't just implement
> native_read_msr() as just
> 
>unsigned long long native_read_msr(unsigned int msr)
>{
>   int err;
>   unsigned long long val;
> 
>   val = native_read_msr_safe(msr, );
>   WARN_ON_ONCE(err);
>   return val;
>}
> 
> Note: no inline, no nothing. Just put it in arch/x86/lib/msr.c, and be
> done with it. I don't see the downside.

Absolutely!

> How many msr reads are so critical that the function call overhead 
> would 
> matter? Get rid of the inline version of the _safe() thing too, and put that 
> thing there too.

Only a very low number of them is performance critical (because even 
hw-accelerated MSR accesses are generally slow so we try to avoid MSR accesses 
in 
fast paths as much as possible, via shadowing, etc.) - and in the few cases 
where 
we have to access an MSR in a fast path we can do those separately.

I'm only worried about the 'default' APIs, i.e. rdmsr() that is used throughout 
arch/x86/ over a hundred times, not about performance critical code paths that 
get 
enough testing and enough attention in general.

Thanks,

Ingo

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

Re: [Xen-devel] [PATCH] IOMMU: complete/correct comment explaining "iommu=" sub-options

[Andrew Cooper]

On 22/09/2015 08:04, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

Some of these are overly Intel-specific, but while AMD has no
implementation, this isn't much of a problem.

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

[Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Andreas Sundstrom]

This is using Debian Jessie and grub 2.02~beta2-22 (with Debian patches
applied) and Xen 4.4.1

I originally posted a bug report with Debian but got the suggestion to
file bugs with upstream as well.
Debian bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799480

Note that my original thought was that this bug probably is within GRUB.
But Ian asked me to file a bug with Xen as well, you have to live with the
fact that it is centered around GRUB though.

Here's the information from my original bug report:

Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
fail when chainloading the domU's grub. 64-bit domU seem to work 100%
of the time.

My understanding of the process:

 * dom0 launches domU with grub that is loaded from dom0's disk.
 * Grub reads config file from memdisk, and then looks for grub binary in
domU filesystem.
 * If grub is found in domU it then chainloads (multiboot) that grub binary
and the domU grub reads grub.cfg and continue booting.
 * If grub is not found in domU it reads grub.cfg and continues with boot.

It fails at step 3 in my list of the boot process, but sometimes it
does work so it may be something like a race condition that causes the
problem?

A workaround is to not install or rename /boot/xen in domU so that the
first grub that is loaded from dom0's disk will not find the grub
binary in the domU filesystem and hence continues to read grub.cfg and
boot. The drawback of this is of course that the two versions can't
differ too much as there are different setups creating grub.cfg and
then reading/parsing it at boot time.

I am not sure at this point whether this is a problem in XEN or a
problem in grub but I compiled the legacy pvgrub that uses some minios
from XEN (don't really know much more about it) and when that legacy
pvgrub chainloads the domU grub it seems to work 100% of the time. Now
the legace pvgrub is not a real alternative as it's not packaged for
Debian though.

When it fails "xl create vm -c" outputs this:
Parsing config from /etc/xen/vm
libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain
type for domid=16
Unable to attach console
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console
child [0] exited with error status 1

And "xl dmesg" shows errors like this:
(XEN) traps.c:2514:d15 Domain attempted WRMSR c0010201 from
0x to 0x.
(XEN) d16:v0: unhandled page fault (ec=0010)
(XEN) Pagetable walk from :
(XEN) L4[0x000] = 000200256027 049c
(XEN) L3[0x000] = 000200255027 049d
(XEN) L2[0x000] = 000200251023 04a1
(XEN) L1[0x000] =  
(XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0
compat_create_bounce_frame+0xc6/0xde
(XEN) Domain 16 (vcpu#0) crashed on cpu#0:
(XEN) [ Xen-4.4.1 x86_64 debug=n Not tainted ]
(XEN) CPU: 0
(XEN) RIP: e019:[<>]
(XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest
(XEN) rax:  rbx:  rcx: 
(XEN) rdx:  rsi: 00499000 rdi: 0080
(XEN) rbp: 000a rsp: 005a5ff0 r8: 
(XEN) r9:  r10: 83023e9b9000 r11: 83023e9b9000
(XEN) r12: 033f3d335bfb r13: 82d080300800 r14: 82d0802ea940
(XEN) r15: 83005e819000 cr0: 8005003b cr4: 000506f0
(XEN) cr3: 000200b7a000 cr2: 
(XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019
(XEN) Guest stack trace from esp=005a5ff0:
(XEN) 0010  0001e019 00010046 0016b38b 0016b38a 0016b389
0016b388
(XEN) 0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 0016b381
0016b380
(XEN) 0016b37f 0016b37e 0016b37d 0016b37c 0016b37b 0016b37a 0016b379
0016b378
(XEN) 0016b377 0016b376 0016b375 0016b374 0016b373 0016b372 0016b371
0016b370
(XEN) 0016b36f 0016b36e 0016b36d 0016b36c 0016b36b 0016b36a 0016b369
0016b368
(XEN) 0016b367 0016b366 0016b365 0016b364 0016b363 0016b362 0016b361
0016b360
(XEN) 0016b35f 0016b35e 0016b35d 0016b35c 0016b35b 0016b35a 0016b359
0016b358
(XEN) 0016b357 0016b356 0016b355 0016b354 0016b353 0016b352 0016b351
0016b350
(XEN) 0016b34f 0016b34e 0016b34d 0016b34c 0016b34b 0016b34a 0016b349
0016b348
(XEN) 0016b347 0016b346 0016b345 0016b344 0016b343 0016b342 0016b341
0016b340
(XEN) 0016b33f 0016b33e 0016b33d 0016b33c 0016b33b 0016b33a 0016b339
0016b338
(XEN) 0016b337 0016b336 0016b335 0016b334 0016b333 0016b332 0016b331
0016b330
(XEN) 0016b32f 0016b32e 0016b32d 0016b32c 0016b32b 0016b32a 0016b329
0016b328
(XEN) 0016b327 0016b326 0016b325 0016b324 0016b323 0016b322 0016b321
0016b320
(XEN) 0016b31f 0016b31e 0016b31d 0016b31c 0016b31b 0016b31a 0016b319
0016b318
(XEN) 0016b317 0016b316 0016b315 0016b314 0016b313 0016b312 0016b311
0016b310
(XEN) 0016b30f 0016b30e 0016b30d 0016b30c 0016b30b 0016b30a 0016b309
0016b308
(XEN) 0016b307 0016b306 0016b305 0016b304 0016b303 

Re: [Xen-devel] [PATCH for-4.6 1/2] libxl: fix devd removal path

[Ian Jackson]

Roger Pau Monne writes ("[PATCH for-4.6 1/2] libxl: fix devd removal path"):
> The current flow of the devd helper (in charge of launching hotplug scripts
> inside of driver domains) is to wait for the device backend to switch to
> state 6 (XenbusStateClosed) and then remove it. This is not correct, since
> a domain can reconnect it's PV devices as many times as it wants.

Oops.  Thanks for investigating.

> +p = strstr(path, "/state");
> +if (p != NULL) {
> +*p = '\0';
> +} else {
> +p = strstr(path, "/online");
> +if (p == NULL)
> +goto skip;
> +*p = '\0';
> +}

I don't think this is correct.  You could use strrstr, I guess.  But
it would probably be better to strrchr '/' and then strcmp the result
with /online and/or /state ?

> +rc = libxl__xs_write_checked(gc, t, online_path, "0");
> +if (rc) {
> +LOG(ERROR, "unable to write to xenstore path %s", online_path);
> +goto out;

libxl__xs_write_checked logs on error so this is redundant (I
appreciate that it was there before...)

Ian.

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

Re: [Xen-devel] [PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr as well as /usr/local

[Ian Jackson]

(CCing Stefano)

Ian Campbell writes ("Re: [PATCH OSSTEST] make_qcow2: Look for qemu-img under 
/usr as well as /usr/local"):
> On Tue, 2015-09-22 at 16:41 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH OSSTEST] make_qcow2: Look for qemu-img under
> > /usr as well as /usr/local"):
> > > Older Xen's installed in /usr by default, so we need to check where
> > > qemu-img if we want these tests to work on those versions.
> > 
> > Acked-by: Ian Jackson 
> > 
> > But, why are we executing a utility from /usr/lib/xen/bin ?  If this
> > utility is useful to osstest it is presumably useful to users too, and
> > in that case it should be on PATH (under some suitable name).
> 
> We install qemu-upstream under our own prefix, I think to avoid conficting
> with the users own qemu installations?
> 
> qemu-img comes from there. We do install qemu-xen-img (from trad) into
> $PATH, but when I wrote this test I thought it preferable to use qemu-img.

Maybe we should be installing qemu-img from our qemu upstream build
instead ?

We evidently don't think that there is anything in the qcow block
system in trad that we like, because we are only using upstream for
qdisk vbd backends now.

Ian.

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

Re: [Xen-devel] Is: Make XENVER_* use XSM, seperate the different ops in smaller security domains. Was:Re: [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

[Daniel De Graaf]

On 22/09/15 09:45, Konrad Rzeszutek Wilk wrote:

On Tue, Sep 22, 2015 at 02:33:23PM +0100, Andrew Cooper wrote:

On 22/09/15 14:22, Konrad Rzeszutek Wilk wrote:

On Fri, Sep 18, 2015 at 12:40:46PM +0100, Andrew Cooper wrote:

On 17/09/15 19:45, Konrad Rzeszutek Wilk wrote:

. snip..

The build id of the current running hypervisor should belong in the
xeninfo hypercall.  It is not specific to xsplice.

However in the previous reviews it was pointed out that it should only be 
accessible to dom0.

Or to any domains as long as the XSM allows (and is turned on) - so not the 
default dummy one.

That is a bit of 'if' extra complexity which I am not sure is worth it?

DomU can already read the build information such as changeset, compile
time, etc.  Build-id is no more special or revealing.

I would take this as an argument *against* giving DomU access to those
pieces of information in details and not as an argument for
*additionally* giving it access to build-id.

With build-id we have the chance to shape a not-yet-established API and
I would like to follow the Principle of least privilege wherever it
makes sense.

To reach a similar security level with the existing API, it might make
sense to limit DomU access to compile date, compile time, compiled by,
compiled domain, compiler version and command line details, xen extra
version, and xen changeset.  Basically anything that might help DomUs to
uniquely identify a Xen build.

The approach can not directly drop access to those fields, as that would
break an existing API, but it could restrict the detail level handed out
to DomU.

These are all valid arguments to be made, but please lets fix the issue
properly rather than hacking build-id on the side of an unrelated component.

 From my point of view, the correct course of action is this:

* Split the current XSM model to contain separate attributes for general
and privileged information.
** For current compatibility, all existing XENVER_* subops fall into general
* Apply an XSM check at the very start of the hypercall.

That would introduce a performance regression I fear. Linux pvops does this:

/*
  * Force a proper event-channel callback from Xen after clearing the
  * callback mask. We do this in a very simple manner, by making a call
  * down into Xen. The pending flag will be checked by Xen on return.
  */
void xen_force_evtchn_callback(void)
{
 (void)HYPERVISOR_xen_version(0, NULL);
}

quite often, which now will have to do the XSM check which is extra code.


I would say that the XENVER_compile_info (/sys/hypervisor/compilation),
XENVER_changeset (/sys/hypervisor/compilation) should go over
the XSM check.

While:XENVER_version, XENVER_extraversion,XENVER_capabilities,
XENVER_platform_parameters, XENVER_get_features,XENVER_pagesize

should have no XSM check.


The XSM check will fall into the noise, performance wise, compared to the
context switch to make the hypercall in the first place.  It is just another
switch statement.  Also, selectively applying XSM checks will incur even
more overhead than doing a blanket XSM check.


I would be surprised if placing the XSM check inside the individual case
statement is more expensive than a single XSM check outside the switch:
in either case, it's either a single call or a single if statement, and
since there's only 10 cases (6 of which were identified as not needing a
check) it's not much code added either.

You could also define a bitmask of operations that require an XSM check
and do "if ((1 << cmd) & NEEDS_XSM_CHECK_BITMASK) { do_xsm_check() }".


I am worried about some spinlock in the depths of XSM code.

But then I haven't looked in detail so perhaps this is not an issue after all.


The XSM code tries to use read locks where possible to avoid this type of
performance hit, and if the call is being made as often as it sounds like,
the check will almost always hit the AVC cache (avoiding the more expensive
parts of the FLASK security server).  However, it's always faster to return
success right away (and no less secure if you were going to do so anyway).


Also, I really don't care if you can measure a performance hit (not that I
reckon you could).  How Linux chooses to behave itself has absolutely no
bearing on how we go about securing the hypercall.


But making something slower is surely not something we strive for.



~Andrew





--
Daniel De Graaf
National Security Agency

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

[Xen-devel] [PATCH v2] xen/x86: Record xsave features in c->x86_capabilities

[Andrew Cooper]

Convert existing cpu_has_x??? to being functions of boot_cpu_data (matching
the prevailing style), and mask out unsupported features.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Shuai Ruan 

v2:
 * Reuse word 2 rather than introducing word 8
 * Remove bsp check when validating homogeneity

This is another patch from my feature levelling series which is being posted
early because of interactions with other code.

Shuai: This patch will interact with your xsaves series, although I hope it
will make your series easier.
---
 xen/arch/x86/cpu/common.c|2 +-
 xen/arch/x86/traps.c |5 +
 xen/arch/x86/xstate.c|   30 ++
 xen/include/asm-x86/cpufeature.h |   11 ++-
 xen/include/asm-x86/xstate.h |8 ++--
 5 files changed, 24 insertions(+), 32 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 35ef21b..0be0656 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -311,7 +311,7 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
clear_bit(X86_FEATURE_XSAVE, boot_cpu_data.x86_capability);
 
if ( cpu_has_xsave )
-   xstate_init(c == _cpu_data);
+   xstate_init(c);
 
/*
 * The vendor-specific functions might have changed features.  Now
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 9f5a6c6..07feb6d 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -935,10 +935,7 @@ void pv_cpuid(struct cpu_user_regs *regs)
 goto unsupported;
 if ( regs->_ecx == 1 )
 {
-a &= XSTATE_FEATURE_XSAVEOPT |
- XSTATE_FEATURE_XSAVEC |
- (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
- (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0);
+a &= boot_cpu_data.x86_capability[X86_FEATURE_XSAVEOPT / 32];
 if ( !cpu_has_xsaves )
 b = c = d = 0;
 }
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index d5f5e3b..9ddff90 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -14,11 +14,6 @@
 #include 
 #include 
 
-static bool_t __read_mostly cpu_has_xsaveopt;
-static bool_t __read_mostly cpu_has_xsavec;
-bool_t __read_mostly cpu_has_xgetbv1;
-bool_t __read_mostly cpu_has_xsaves;
-
 /*
  * Maximum size (in byte) of the XSAVE/XRSTOR save area required by all
  * the supported and enabled features on the processor, including the
@@ -281,8 +276,9 @@ unsigned int xstate_ctxt_size(u64 xcr0)
 }
 
 /* Collect the information of processor's extended state */
-void xstate_init(bool_t bsp)
+void xstate_init(struct cpuinfo_x86 *c)
 {
+bool_t bsp = c == _cpu_data;
 u32 eax, ebx, ecx, edx;
 u64 feature_mask;
 
@@ -325,20 +321,14 @@ void xstate_init(bool_t bsp)
 
 /* Check extended XSAVE features. */
 cpuid_count(XSTATE_CPUID, 1, , , , );
-if ( bsp )
-{
-cpu_has_xsaveopt = !!(eax & XSTATE_FEATURE_XSAVEOPT);
-cpu_has_xsavec = !!(eax & XSTATE_FEATURE_XSAVEC);
-/* XXX cpu_has_xgetbv1 = !!(eax & XSTATE_FEATURE_XGETBV1); */
-/* XXX cpu_has_xsaves = !!(eax & XSTATE_FEATURE_XSAVES); */
-}
-else
-{
-BUG_ON(!cpu_has_xsaveopt != !(eax & XSTATE_FEATURE_XSAVEOPT));
-BUG_ON(!cpu_has_xsavec != !(eax & XSTATE_FEATURE_XSAVEC));
-/* XXX BUG_ON(!cpu_has_xgetbv1 != !(eax & XSTATE_FEATURE_XGETBV1)); */
-/* XXX BUG_ON(!cpu_has_xsaves != !(eax & XSTATE_FEATURE_XSAVES)); */
-}
+
+/* Mask out features not currently understood by Xen. */
+eax &= (cpufeat_mask(X86_FEATURE_XSAVEOPT) |
+cpufeat_mask(X86_FEATURE_XSAVEC));
+
+c->x86_capability[X86_FEATURE_XSAVEOPT / 32] = eax;
+
+BUG_ON(eax != boot_cpu_data.x86_capability[X86_FEATURE_XSAVEOPT / 32]);
 }
 
 static bool_t valid_xcr0(u64 xcr0)
diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h
index 9a01563..6a94724 100644
--- a/xen/include/asm-x86/cpufeature.h
+++ b/xen/include/asm-x86/cpufeature.h
@@ -57,7 +57,11 @@
 #define X86_FEATURE_3DNOWEXT   (1*32+30) /* AMD 3DNow! extensions */
 #define X86_FEATURE_3DNOW  (1*32+31) /* 3DNow! */
 
-/* *** Available for re-use ***, word 2 */
+/* Intel-defined CPU features, CPUID level 0x000D:1 (eax), word 2 */
+#define X86_FEATURE_XSAVEOPT   (2*32+ 0) /* XSAVEOPT instruction. */
+#define X86_FEATURE_XSAVEC (2*32+ 1) /* XSAVEC/XRSTORC instructions. */
+#define X86_FEATURE_XGETBV1(2*32+ 2) /* XGETBV with %ecx=1. */
+#define X86_FEATURE_XSAVES (2*32+ 3) /* XSAVES/XRSTORS instructions. */
 
 /* Other features, Linux-defined mapping, word 3 */
 /* This range is used for feature bits which conflict or are synthesized */
@@ -219,6 +223,11 @@
 
 #define cpu_has_cx16boot_cpu_has(X86_FEATURE_CX16)
 
+#define cpu_has_xsaveopt   

[Xen-devel] [PATCH 3/8] xen/arm: Fix comment coding style in handle_node in domain_build.c

[Julien Grall]

Only coding style changes. No functional changes.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index f7ea240..651d75e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1226,8 +1226,10 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return 0;
 }
 
-/* Replace these nodes with our own. Note that the original may be
- * used_by DOMID_XEN so this check comes first. */
+/*
+ * Replace these nodes with our own. Note that the original may be
+ * used_by DOMID_XEN so this check comes first.
+ */
 if ( device_get_class(node) == DEVICE_GIC )
 return make_gic_node(d, kinfo->fdt, node);
 if ( dt_match_node(timer_matches, node) )
@@ -1240,7 +1242,8 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return 0;
 }
 
-/* Even if the IOMMU device is not used by Xen, it should not be
+/*
+ * Even if the IOMMU device is not used by Xen, it should not be
  * passthrough to DOM0
  */
 if ( device_get_class(node) == DEVICE_IOMMU )
-- 
2.1.4


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

[Xen-devel] [PATCH 6/8] xen/arm: gic: Check the size of the CPU and vCPU interface retrieved from DT

[Julien Grall]

The size of the CPU interface will used in a follow-up patch to map the
region in Xen memory.

Based on GICv2 spec, the CPU interface should at least be 8KB, although
most of the platform we are supporting use the GICv1 size (i.e 4KB) in
their DT. Only warn and update the size to avoid any breakage on these
platforms.

Furthermore, Xen is relying on the Virtual CPU interface been at least
8KB. As in reality the Virtual CPU interface match the CPU interface,
check that the 2 interfaces have the same size. Also only warn, to avoid
any breakage with buggy DT.

For GICv3, only allow GICv2 compatibility when the Virtual CPU interface
and CPU interface are 8KB.

Signed-off-by: Julien Grall 
---
Cc: Zoltan Kiss 

I haven't done any change in the gic-hip04 driver. I will let the
maintainers doing it if they feel it's necessary.
---
 xen/arch/arm/gic-v2.c | 34 ++
 xen/arch/arm/gic-v3.c | 22 +++---
 2 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 5841e59..62583e7 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -617,14 +617,16 @@ static hw_irq_controller gicv2_guest_irq_type = {
 static int __init gicv2_init(void)
 {
 int res;
-paddr_t hbase, dbase, cbase, vbase;
+paddr_t hbase, dbase;
+paddr_t cbase, csize;
+paddr_t vbase, vsize;
 const struct dt_device_node *node = gicv2_info.node;
 
 res = dt_device_get_address(node, 0, , NULL);
 if ( res )
 panic("GICv2: Cannot find a valid address for the distributor");
 
-res = dt_device_get_address(node, 1, , NULL);
+res = dt_device_get_address(node, 1, , );
 if ( res )
 panic("GICv2: Cannot find a valid address for the CPU");
 
@@ -632,7 +634,7 @@ static int __init gicv2_init(void)
 if ( res )
 panic("GICv2: Cannot find a valid address for the hypervisor");
 
-res = dt_device_get_address(node, 3, , NULL);
+res = dt_device_get_address(node, 3, , );
 if ( res )
 panic("GICv2: Cannot find a valid address for the virtual CPU");
 
@@ -641,7 +643,31 @@ static int __init gicv2_init(void)
 panic("GICv2: Cannot find the maintenance IRQ");
 gicv2_info.maintenance_irq = res;
 
-/* TODO: Add check on distributor, cpu size */
+/* TODO: Add check on distributor */
+
+/*
+ * The GICv2 CPU interface should at least be 8KB. Although, most of the DT
+ * doesn't correctly set it and use the GICv1 CPU interface size (i.e 4KB).
+ * Warn and then fixup.
+ */
+if ( csize < SZ_8K )
+{
+printk(XENLOG_WARNING "GICv2: WARNING: "
+   "The CPU interface size is wrong: %#"PRIx64
+   " expected %#x\n",
+   csize, SZ_8K);
+csize = SZ_8K;
+}
+
+/*
+ * Check if the CPU interface and virtual CPU interface have the
+ * same size.
+ */
+if ( csize != vbase )
+printk(XENLOG_WARNING "GICv2: WARNING: "
+   "The size of the CPU interface (%#"PRIpaddr") and the vCPU"
+   " interface (%#"PRIpaddr") doesn't match\n",
+   csize, vsize);
 
 printk("GICv2 initialization:\n"
   "gic_dist_addr=%"PRIpaddr"\n"
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 957e491..4c58baf 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1143,22 +1143,38 @@ static void __init gicv3_init_v2(const struct 
dt_device_node *node,
  paddr_t dbase)
 {
 int res;
-paddr_t cbase, vbase;
+paddr_t cbase, csize;
+paddr_t vbase, vsize;
 
 /*
  * For GICv3 supporting GICv2, GICC and GICV base address will be
  * provided.
  */
 res = dt_device_get_address(node, 1 + gicv3.rdist_count,
-, NULL);
+, );
 if ( res )
 return;
 
 res = dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
-, NULL);
+, );
 if ( res )
 return;
 
+/*
+ * Only allow support of GICv2 compatible when the CPU interface
+ * and virtual CPU interface are 8KB
+ * XXX: Handle other size?
+ */
+if ( csize != SZ_8K && vsize != SZ_8K )
+{
+printk(XENLOG_WARNING
+   "GICv3: WARNING: Don't enable support of GICv2.\n"
+   "The size of the CPU interface (%#"PRIpaddr") and the vCPU"
+   " interface (%#"PRIpaddr") should be 8KB.\n",
+   csize, vsize);
+return;
+}
+
 printk("GICv3 compatible with GICv2 cbase %#"PRIpaddr" vbase 
%#"PRIpaddr"\n",
cbase, vbase);
 
-- 
2.1.4


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

[Xen-devel] [PATCH 2/8] xen/arm: Retrieve the correct number of cells when building dom0 DT

[Julien Grall]

The function dt_n_*_cells will retrieve the number of cells for a given
node. Those numbers may not be correct to use for the child "reg"
property if the parent is passed.

This is fine today because the parent is always the root node which
means there is no upper parent.

Introduce new helpers dt_child_n_*_cells to retrieve the number of
cells for the address and size that can be used to create the "reg"
property of a child of a given parent.

Use the new helpers when creating the hypervisor and memory node where
we only have the parent in hand. This is because those nodes are
recreated from scratch by Xen and therefore we don't have a
dt_device_node for them. The only thing we have is a pointer to there
future parent.

We also have to modify dt_set_range to take a parent in parameter rather
than an HW DT node that we will replicated in the DOM0 DT.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain_build.c   |  6 +++---
 xen/arch/arm/gic-v3.c |  4 ++--
 xen/common/device_tree.c  | 38 +++---
 xen/include/xen/device_tree.h | 23 +--
 4 files changed, 57 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index a059de6..f7ea240 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -569,7 +569,7 @@ static int make_memory_node(const struct domain *d,
 const struct kernel_info *kinfo)
 {
 int res, i;
-int reg_size = dt_n_addr_cells(parent) + dt_n_size_cells(parent);
+int reg_size = dt_child_n_addr_cells(parent) + 
dt_child_n_size_cells(parent);
 int nr_cells = reg_size*kinfo->mem.nr_banks;
 __be32 reg[nr_cells];
 __be32 *cells;
@@ -617,8 +617,8 @@ static int make_hypervisor_node(const struct kernel_info 
*kinfo,
 __be32 *cells;
 int res;
 /* Convenience alias */
-int addrcells = dt_n_addr_cells(parent);
-int sizecells = dt_n_size_cells(parent);
+int addrcells = dt_child_n_addr_cells(parent);
+int sizecells = dt_child_n_size_cells(parent);
 void *fdt = kinfo->fdt;
 
 DPRINT("Create hypervisor node\n");
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 0df4baf..957e491 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1096,10 +1096,10 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 
 tmp = new_cells;
 
-dt_set_range(, gic, d->arch.vgic.dbase, SZ_64K);
+dt_set_range(, gic->parent, d->arch.vgic.dbase, SZ_64K);
 
 for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
-dt_set_range(, gic, d->arch.vgic.rdist_regions[i].base,
+dt_set_range(, gic->parent, d->arch.vgic.rdist_regions[i].base,
  d->arch.vgic.rdist_regions[i].size);
 
 res = fdt_property(fdt, "reg", new_cells, len);
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 18cdb6f..845cc77 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -110,11 +110,11 @@ void dt_set_cell(__be32 **cellp, int size, u64 val)
 (*cellp) += cells;
 }
 
-void dt_set_range(__be32 **cellp, const struct dt_device_node *np,
+void dt_set_range(__be32 **cellp, const struct dt_device_node *parent,
   u64 address, u64 size)
 {
-dt_set_cell(cellp, dt_n_addr_cells(np), address);
-dt_set_cell(cellp, dt_n_size_cells(np), size);
+dt_set_cell(cellp, dt_child_n_addr_cells(parent), address);
+dt_set_cell(cellp, dt_child_n_size_cells(parent), size);
 }
 
 static void __init *unflatten_dt_alloc(unsigned long *mem, unsigned long size,
@@ -386,13 +386,15 @@ dt_find_matching_node(struct dt_device_node *from,
 return NULL;
 }
 
-int dt_n_addr_cells(const struct dt_device_node *np)
+static int __dt_n_addr_cells(const struct dt_device_node *np, bool_t parent)
 {
 const __be32 *ip;
 
 do {
-if ( np->parent )
+if ( np->parent && !parent )
 np = np->parent;
+parent = false;
+
 ip = dt_get_property(np, "#address-cells", NULL);
 if ( ip )
 return be32_to_cpup(ip);
@@ -401,13 +403,15 @@ int dt_n_addr_cells(const struct dt_device_node *np)
 return DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
 }
 
-int dt_n_size_cells(const struct dt_device_node *np)
+int __dt_n_size_cells(const struct dt_device_node *np, bool_t parent)
 {
 const __be32 *ip;
 
 do {
-if ( np->parent )
+if ( np->parent && !parent )
 np = np->parent;
+parent = false;
+
 ip = dt_get_property(np, "#size-cells", NULL);
 if ( ip )
 return be32_to_cpup(ip);
@@ -416,6 +420,26 @@ int dt_n_size_cells(const struct dt_device_node *np)
 return DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
 }
 
+int dt_n_addr_cells(const struct dt_device_node *np)
+{
+return __dt_n_addr_cells(np, false);
+}
+
+int dt_n_size_cells(const struct dt_device_node *np)
+{
+return __dt_n_size_cells(np, false);
+}
+
+int 

[Xen-devel] [xen-4.5-testing test] 62168: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qcow2 14 guest-saverestore.2  fail REGR. vs. 61513
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 61513
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail REGR. vs. 61513
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 61513
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail blocked in 61513
 test-amd64-i386-xl-qemuu-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
like 61309
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 61513
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 61513

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-raw  13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  bbbd29a25d090f1180d14210358c6d7ccdebef85
baseline version:
 xen  ef89dc8c00087c8c1819e60bdad5527db70425e1

Last test of basis61513  2015-09-07 11:42:18 Z   15 days
Failing since 61751  2015-09-10 14:07:54 Z   12 days5 attempts
Testing same since62168  2015-09-19 17:21:29 Z3 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anshul Makkar 
  Anthony PERARD 
  Aravind Gopalakrishnan 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Julien Grall 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 

[Xen-devel] [PATCH 2/2] x86/hvm: Fold opt_hap_{2mb, 1gb} into hap_capabilities

[Andrew Cooper]

This allows all runtime users to simply check hap_has_{2mb,1gb} rather than
having to check opt_hap_{2mb,1gb} as well.

As a result, opt_hap_{2mb,1gb} can move into __initdata.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
---
 xen/arch/x86/hvm/hvm.c |8 
 xen/arch/x86/mm/p2m.c  |   10 --
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f082b86..6afc344 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -158,9 +158,17 @@ static int __init hvm_enable(void)
 printk("HVM: Hardware Assisted Paging (HAP) detected\n");
 printk("HVM: HAP page sizes: 4kB");
 if ( fns->hap_capabilities & HVM_HAP_SUPERPAGE_2MB )
+{
 printk(", 2MB%s", opt_hap_2mb ? "" : " [disabled]");
+if ( !opt_hap_2mb )
+hvm_funcs.hap_capabilities &= ~HVM_HAP_SUPERPAGE_2MB;
+}
 if ( fns->hap_capabilities & HVM_HAP_SUPERPAGE_1GB )
+{
 printk(", 1GB%s", opt_hap_1gb ? "" : " [disabled]");
+if ( !opt_hap_1gb )
+hvm_funcs.hap_capabilities &= ~HVM_HAP_SUPERPAGE_1GB;
+}
 printk("\n");
 }
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 9cf7a71..5d2a532 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -41,11 +41,9 @@
 
 #include "mm-locks.h"
 
-/* turn on/off 1GB host page table support for hap, default on */
-bool_t __read_mostly opt_hap_1gb = 1;
+/* turn on/off host superpage page table support for hap, default on */
+bool_t __initdata opt_hap_1gb = 1, __initdata opt_hap_2mb = 1;
 boolean_param("hap_1gb", opt_hap_1gb);
-
-bool_t __read_mostly opt_hap_2mb = 1;
 boolean_param("hap_2mb", opt_hap_2mb);
 
 
@@ -452,9 +450,9 @@ int p2m_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 {
 if ( hap_enabled(d) )
 order = ( (((gfn | mfn_x(mfn) | todo) & ((1ul << PAGE_ORDER_1G) - 
1)) == 0) &&
-  hap_has_1gb && opt_hap_1gb) ? PAGE_ORDER_1G :
+  hap_has_1gb) ? PAGE_ORDER_1G :
   gfn | mfn_x(mfn) | todo) & ((1ul << PAGE_ORDER_2M) - 
1)) == 0) &&
-  hap_has_2mb && opt_hap_2mb) ? PAGE_ORDER_2M : 
PAGE_ORDER_4K;
+  hap_has_2mb) ? PAGE_ORDER_2M : PAGE_ORDER_4K;
 else
 order = 0;
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH 0/2] x86/hvm: Improvements to HAP superpage feature detection

[Andrew Cooper]

Two small patches which reduce the runtime overhead of detecting HAP
superpages by moving more initialisation into __init.

Noticed while reviewing "x86/p2m: use large pages for MMIO mappings".

Andrew Cooper (2):
  x86/hvm: Refine hap_has_{2mb,1gb} checks
  x86/hvm: Fold opt_hap_{2mb,1gb} into hap_capabilities

 xen/arch/x86/hvm/hvm.c|8 
 xen/arch/x86/mm/p2m-ept.c |4 ++--
 xen/arch/x86/mm/p2m.c |   10 --
 xen/include/asm-x86/hvm/hvm.h |6 ++
 4 files changed, 16 insertions(+), 12 deletions(-)

-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v2 21/23] x86/boot: implement early command line parser in C

[Daniel Kiper]

On Thu, Aug 27, 2015 at 06:43:39AM -0600, Jan Beulich wrote:
> >>> On 20.07.15 at 16:29,  wrote:
> > Current early command line parser implementation in assembler
> > is very difficult to change to relocatable stuff using segment
> > registers. This requires a lot of changes in very weird and
> > fragile code. So, reimplement this functionality in C. This
> > way code will be relocatable out of the box and much easier
> > to maintain.
>
> All appreciated and nice, but the goal of making the code
> relocatable by playing with segment registers sounds fragile:
> This breaks assumptions the compiler may validly make.

Well, it looks that this sentence is not precise. I should fix this.
Anyway, I am not playing with segment registers in C code because
it is not needed and as you pointed out it is dangerous.

> >  xen/arch/x86/boot/cmdline.S|  367 -
> >  xen/arch/x86/boot/cmdline.c|  396 
> > 
>
> A fundamental expectation I would have had is for the C file to be
> noticeably smaller than the assembly file.
>
> > --- /dev/null
> > +++ b/xen/arch/x86/boot/cmdline.c
> >[...]
> > +#define VESA_WIDTH 0
> > +#define VESA_HEIGHT1
> > +#define VESA_DEPTH 2
> > +
> > +#define VESA_SIZE  3
>
> These should go away in favor of using individual (sub)structure fields.
>
> > +#define __cdecl__attribute__((__cdecl__))
>
> ???

Please look below.

> > +#define __packed   __attribute__((__packed__))
> > +#define __text __attribute__((__section__(".text")))
> > +#define __used __attribute__((__used__))
>
> Likely better to include compiler.h instead.

As I know you do not like to include such headers in early C files
because it makes code fragile and it looks strange. I agree with you
to some extent. So, I decided to define needed constants ourselves.
Whatever we do we should be consistent. Hence, if we include compiler.h
here we should do the same in reloc.c too if it is required.

> > +#define max(x,y) ({ \
> > +const typeof(x) _x = (x);   \
> > +const typeof(y) _y = (y);   \
> > +(void) (&_x == &_y);\
> > +_x > _y ? _x : _y; })
>
> I also wonder whether -imacros .../xen/kernel.h wouldn't be a better
> approach here. Please really think hard on how to avoid duplications
> like these.

Ditto. So, what is your decision? Include or define? If include then
we should think how to generate relevant dependencies automatically.

> > +#define strlen_static(s) (sizeof(s) - 1)
>
> What is this good for? A decent compiler should be able to deal with
> strlen("..."). Plus your macro is longer that what it tries to "abbreviate".

I thought that it is true but it is not. Sadly, without this binary is 
bigger... :-(((
However, you are right that the name could be better.

> > +static const char empty_chars[] __text = " \n\r\t";
>
> What is empty about them? DYM blank or (white) space or separator
> or delimiter? I also wonder whether \n and \r are actually usefully here,

Yep, delimiter or something like that looks better.

> as they should (if at all) only end the line.

Yes, I included them just in case and they should not appear in command line.

> > +static const char *find_opt(const char *cmdline, const char *opt, int arg)
> > +{
> > +size_t lc, lo;
> > +static const char mm[] __text = "--";
>
> I'd be surprised if there weren't compiler/assembler versions
> complaining about a section type conflict here. I can see why you
> want everything in one section, but I'd rather suggest achieving
> this at the linking step (which I would suppose to already be taking
> care of this).

Nope, it does not work in that way. However, I discovered that newer GCC
versions generate .rodata for switch/case. So, anyway we must cope with
at least two different sections and link them properly.

> > +static u8 skip_realmode(const char *cmdline)
> > +{
> > +static const char nrm[] __text = "no-real-mode";
> > +static const char tboot[] __text = "tboot=";
> > +
> > +if ( find_opt(cmdline, nrm, 0) || find_opt(cmdline, tboot, 1) )
> > +return 1;
> > +
> > +return 0;
>
> return find_opt(cmdline, nrm, 0) || find_opt(cmdline, tboot, 1);
>
> > +static u8 edd_parse(const char *cmdline)
> > +{
> > +const char *c;
> > +size_t la;
> > +static const char edd[] __text = "edd=";
> > +static const char edd_off[] __text = "off";
> > +static const char edd_skipmbr[] __text = "skipmbr";
> > +
> > +c = find_opt(cmdline, edd, 1);
> > +
> > +if ( !c )
> > +return 0;
> > +
> > +c += strlen_static(edd);
> > +la = strcspn(c, empty_chars);
> > +
> > +if ( !strncmp(c, edd_off, max(la, strlen_static(edd_off))) )
> > +return 2;
> > +else if ( !strncmp(c, edd_skipmbr, max(la, 
> > strlen_static(edd_skipmbr))) )
>
> Pointless else.
>
> > +return 1;
> > +
> > +return 0;
>
> And the 

[Xen-devel] [PATCH 1/2] x86/hvm: Refine hap_has_{2mb,1gb} checks

[Andrew Cooper]

HAP superpages are a host property and not dependent on domain configuration.
Drop the domain paramter (which was only used in one of the two callsites),
and drop the redundant hvm_ prefix to mirror the cpu_has_* style of feature
detection.

Finally, convert the checks to being proper booleans rather than just non-zero
integers.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: George Dunlap 
---
 xen/arch/x86/mm/p2m-ept.c |4 ++--
 xen/arch/x86/mm/p2m.c |4 ++--
 xen/include/asm-x86/hvm/hvm.h |6 ++
 3 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 58db34e..dde242e 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -696,8 +696,8 @@ bool_t ept_handle_misconfig(uint64_t gpa)
 if ( ret > 0 )
 needs_sync = sync_on;
 
-ASSERT((target == 2 && hvm_hap_has_1gb()) ||
-   (target == 1 && hvm_hap_has_2mb()) ||
+ASSERT((target == 2 && hap_has_1gb) ||
+   (target == 1 && hap_has_2mb) ||
(target == 0));
 ASSERT(!p2m_is_foreign(p2mt) || target == 0);
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e1d930a..9cf7a71 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -452,9 +452,9 @@ int p2m_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 {
 if ( hap_enabled(d) )
 order = ( (((gfn | mfn_x(mfn) | todo) & ((1ul << PAGE_ORDER_1G) - 
1)) == 0) &&
-  hvm_hap_has_1gb(d) && opt_hap_1gb ) ? PAGE_ORDER_1G :
+  hap_has_1gb && opt_hap_1gb) ? PAGE_ORDER_1G :
   gfn | mfn_x(mfn) | todo) & ((1ul << PAGE_ORDER_2M) - 
1)) == 0) &&
-  hvm_hap_has_2mb(d) && opt_hap_2mb) ? PAGE_ORDER_2M : 
PAGE_ORDER_4K;
+  hap_has_2mb && opt_hap_2mb) ? PAGE_ORDER_2M : 
PAGE_ORDER_4K;
 else
 order = 0;
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 9f49e6d..2c3192c 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -278,10 +278,8 @@ int vmsi_deliver(
 (!!((v)->arch.hvm_vcpu.guest_efer & EFER_NX))
 
 /* Can we use superpages in the HAP p2m table? */
-#define hvm_hap_has_1gb(d) \
-(hvm_funcs.hap_capabilities & HVM_HAP_SUPERPAGE_1GB)
-#define hvm_hap_has_2mb(d) \
-(hvm_funcs.hap_capabilities & HVM_HAP_SUPERPAGE_2MB)
+#define hap_has_1gb !!(hvm_funcs.hap_capabilities & HVM_HAP_SUPERPAGE_1GB)
+#define hap_has_2mb !!(hvm_funcs.hap_capabilities & HVM_HAP_SUPERPAGE_2MB)
 
 /* Can the guest use 1GB superpages in its own pagetables? */
 #define hvm_pse1gb_supported(d) \
-- 
1.7.10.4


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

[Xen-devel] [PATCH 7/8] xen/arm: gic-v2: Detect automatically aliased GIC400

[Julien Grall]

We are currently using a per-platform quirk to know if the 2 4KB region of
the GIC CPU interface are each aligned to 64KB. Although, it may be
possible to have different layout on a same platform (depending on the
firmware version).

Rather than having a quirk it's possible to detect by reading the GIC
memory. This patch is based from the Linux commit "irqchip/GIC: Add workaround
for aliased GIC400" [1].

Take the opportunity to clean up the GICv2 of code which was only
required because of the quirk.

Note that none of the platform using the gic-hip04 where actually using
the quirk, so the code has been dropped. I will let the maintainers
decide whether it's relevant or not to add proper detection for aliased
GIC for this hardware.

[1] commit 12e14066f4835f5ee1ca795f0309415b54c067a9
Author: Marc Zyngier 
Date:   Sun Sep 13 12:14:31 2015 +0100

irqchip/GIC: Add workaround for aliased GIC400

The GICv2 architecture mandates that the two 4kB GIC regions are
contiguous, and on two separate physical pages (so that access to
the second page can be trapped by a hypervisor). This doesn't work
very well when PAGE_SIZE is 64kB.

A relatively common hack^Wway to work around this is to alias each
4kB region over its own 64kB page. Of course in this case, the base
address you want to use is not really the begining of the region,
but base + 60kB (so that you get a contiguous 8kB region over two
distinct pages).

Normally, this would be described in DT with a new property, but
some HW is already out there, and the firmware makes sure that
it will override whatever you put in the GIC node. Duh. And of course,
said firmware source code is not available, despite being based
on u-boot.

The workaround is to detect the case where the CPU interface size
is set to 128kB, and verify the aliasing by checking that the ID
register for GIC400 (which is the only GIC wired this way so far)
is the same at base and base + 0xF000. In this case, we update
the GIC base address and let it roll.

And if you feel slightly sick by looking at this, rest assured that
I do too...

Reported-by: Julien Grall 
Signed-off-by: Marc Zyngier 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Stuart Yoder 
Cc: Pavel Fedin 
Cc: Jason Cooper 
Link: 
http://lkml.kernel.org/r/1442142873-20213-2-git-send-email-marc.zyng...@arm.com
Signed-off-by: Thomas Gleixner 

Signed-off-by: Julien Grall 
---
Cc: Zoltan Kiss 
---
 xen/arch/arm/gic-hip04.c | 13 +++-
 xen/arch/arm/gic-v2.c| 59 ++--
 xen/arch/arm/gic-v3.c|  3 +-
 xen/arch/arm/platforms/xgene-storm.c |  6 
 xen/arch/arm/vgic-v2.c   | 48 ++---
 xen/include/asm-arm/gic.h|  1 +
 xen/include/asm-arm/platform.h   |  6 
 xen/include/asm-arm/vgic.h   |  3 +-
 8 files changed, 83 insertions(+), 56 deletions(-)

diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index e8cdcd4..ac2912a 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -631,14 +631,14 @@ static hw_irq_controller hip04gic_guest_irq_type = {
 static int __init hip04gic_init(void)
 {
 int res;
-paddr_t hbase, dbase, cbase, vbase;
+paddr_t hbase, dbase, cbase, csize, vbase;
 const struct dt_device_node *node = gicv2_info.node;
 
 res = dt_device_get_address(node, 0, , NULL);
 if ( res )
 panic("GIC-HIP04: Cannot find a valid address for the distributor");
 
-res = dt_device_get_address(node, 1, , NULL);
+res = dt_device_get_address(node, 1, , );
 if ( res )
 panic("GIC-HIP04: Cannot find a valid address for the CPU");
 
@@ -675,11 +675,7 @@ static int __init hip04gic_init(void)
 panic("GIC-HIP04: Failed to ioremap for GIC distributor\n");
 
 gicv2.map_cbase[0] = ioremap_nocache(cbase, PAGE_SIZE);
-
-if ( platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
-gicv2.map_cbase[1] = ioremap_nocache(cbase + SZ_64K, PAGE_SIZE);
-else
-gicv2.map_cbase[1] = ioremap_nocache(cbase + PAGE_SIZE, PAGE_SIZE);
+gicv2.map_cbase[1] = ioremap_nocache(cbase + PAGE_SIZE, PAGE_SIZE);
 
 if ( !gicv2.map_cbase[0] || !gicv2.map_cbase[1] )
 panic("GIC-HIP04: Failed to ioremap for GIC CPU interface\n");
@@ -688,7 +684,8 @@ static int __init hip04gic_init(void)
 if ( !gicv2.map_hbase )
 panic("GIC-HIP04: Failed to ioremap for GIC Virtual interface\n");
 
-vgic_v2_setup_hw(dbase, cbase, vbase);
+/* XXX: Support aliased HIP04 GIC? */
+vgic_v2_setup_hw(dbase, cbase, csize, vbase, 0);
 
 /* Global settings: interrupt distributor */
 

[Xen-devel] [PATCH 0/8] xen/arm: gic-v2: Detect automatically aliased GIC400

[Julien Grall]

Hi all,

Only patch #7 is related to subject. The others are clean up of code I looked
while I was working on this series.

Regards,

Julien Grall (8):
  xen/arm: gic: Make clear the GIC node is passed to make_hwdom_dt_node
  xen/arm: Retrieve the correct number of cells when building dom0 DT
  xen/arm: Fix comment coding style in handle_node in domain_build.c
  xen/arm: Warn when a device tree path will be re-used by Xen
  xen/arm: vgic-v2: Drop cbase from arch_domain
  xen/arm: gic: Check the size of the CPU and vCPU interface retrieved
from DT
  xen/arm: gic-v2: Detect automatically aliased GIC400
  xen/arm: platform: Drop the quirks callback

 xen/arch/arm/domain_build.c  | 30 ---
 xen/arch/arm/gic-hip04.c | 18 +++
 xen/arch/arm/gic-v2.c| 98 +++-
 xen/arch/arm/gic-v3.c| 34 +
 xen/arch/arm/gic.c   |  6 ++-
 xen/arch/arm/platform.c  | 10 
 xen/arch/arm/platforms/xgene-storm.c |  6 ---
 xen/arch/arm/vgic-v2.c   | 51 ---
 xen/common/device_tree.c | 38 +++---
 xen/include/asm-arm/domain.h |  1 -
 xen/include/asm-arm/gic.h|  6 ++-
 xen/include/asm-arm/platform.h   | 14 --
 xen/include/asm-arm/vgic.h   |  3 +-
 xen/include/xen/device_tree.h| 23 -
 14 files changed, 225 insertions(+), 113 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 4/8] xen/arm: Warn when a device tree path will be re-used by Xen

[Julien Grall]

Xen is using unconditionnally some device tree path to create DOM0
specific node (for instance /psci, /memory and /hypervisor).

Rather than blindly add new nodes with the same, print a warning message
on the console to let know the user that something may go wrong.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 651d75e..2670431 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1205,6 +1205,13 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 DT_MATCH_TIMER,
 { /* sentinel */ },
 };
+static const struct dt_device_match reserved_matches[] __initconst =
+{
+DT_MATCH_PATH("/psci"),
+DT_MATCH_PATH("/memory"),
+DT_MATCH_PATH("/hypervisor"),
+{ /* sentinel */ },
+};
 struct dt_device_node *child;
 int res;
 const char *name;
@@ -1252,6 +1259,14 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 return 0;
 }
 
+/*
+ * Xen is using some path for its own purpose. Warn if a node
+ * already exists with the same path.
+ */
+if ( dt_match_node(reserved_matches, node) )
+printk(XENLOG_WARNING "WARNING: Path %s is reserved, skip the node\n",
+   path);
+
 res = handle_device(d, node);
 if ( res)
 return res;
-- 
2.1.4


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

[Xen-devel] [PATCH 1/8] xen/arm: gic: Make clear the GIC node is passed to make_hwdom_dt_node

[Julien Grall]

The callback make_hwdom_dt_node already have the gic node in parameter.

Rather than using a weird mix between "dt_interrupt_controller" (aliased
to "gic") and "node", rename the callback parameter "node" to "gic".

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-hip04.c  | 5 ++---
 xen/arch/arm/gic-v2.c | 5 ++---
 xen/arch/arm/gic-v3.c | 9 -
 xen/arch/arm/gic.c| 6 --
 xen/include/asm-arm/gic.h | 5 +++--
 5 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index c5ed545..e8cdcd4 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -562,10 +562,9 @@ static void hip04gic_irq_set_affinity(struct irq_desc 
*desc, const cpumask_t *cp
 }
 
 static int hip04gic_make_hwdom_dt_node(const struct domain *d,
-   const struct dt_device_node *node,
+   const struct dt_device_node *gic,
void *fdt)
 {
-const struct dt_device_node *gic = dt_interrupt_controller;
 const void *compatible;
 u32 len;
 const __be32 *regs;
@@ -598,7 +597,7 @@ static int hip04gic_make_hwdom_dt_node(const struct domain 
*d,
 return -FDT_ERR_XEN(ENOENT);
 }
 
-len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
 len *= 2;
 
 res = fdt_property(fdt, "reg", regs, len);
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 596126d..5841e59 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -552,10 +552,9 @@ static void gicv2_irq_set_affinity(struct irq_desc *desc, 
const cpumask_t *cpu_m
 }
 
 static int gicv2_make_hwdom_dt_node(const struct domain *d,
-const struct dt_device_node *node,
+const struct dt_device_node *gic,
 void *fdt)
 {
-const struct dt_device_node *gic = dt_interrupt_controller;
 const void *compatible = NULL;
 u32 len;
 const __be32 *regs;
@@ -584,7 +583,7 @@ static int gicv2_make_hwdom_dt_node(const struct domain *d,
 return -FDT_ERR_XEN(ENOENT);
 }
 
-len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
 len *= 2;
 
 res = fdt_property(fdt, "reg", regs, len);
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d1db1ce..0df4baf 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1054,10 +1054,9 @@ static void gicv3_irq_set_affinity(struct irq_desc 
*desc, const cpumask_t *mask)
 }
 
 static int gicv3_make_hwdom_dt_node(const struct domain *d,
-const struct dt_device_node *node,
+const struct dt_device_node *gic,
 void *fdt)
 {
-const struct dt_device_node *gic = dt_interrupt_controller;
 const void *compatible = NULL;
 uint32_t len;
 __be32 *new_cells, *tmp;
@@ -1084,7 +1083,7 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 if ( res )
 return res;
 
-len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+len = dt_cells_to_size(dt_n_addr_cells(gic) + dt_n_size_cells(gic));
 /*
  * GIC has two memory regions: Distributor + rdist regions
  * CPU interface and virtual cpu interfaces accessesed as System registers
@@ -1097,10 +1096,10 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 
 tmp = new_cells;
 
-dt_set_range(, node, d->arch.vgic.dbase, SZ_64K);
+dt_set_range(, gic, d->arch.vgic.dbase, SZ_64K);
 
 for ( i = 0; i < d->arch.vgic.nr_regions; i++ )
-dt_set_range(, node, d->arch.vgic.rdist_regions[i].base,
+dt_set_range(, gic, d->arch.vgic.rdist_regions[i].base,
  d->arch.vgic.rdist_regions[i].size);
 
 res = fdt_property(fdt, "reg", new_cells, len);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 1757193..1e1e5ba 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -702,10 +702,12 @@ void __cpuinit init_maintenance_interrupt(void)
 }
 
 int gic_make_hwdom_dt_node(const struct domain *d,
-   const struct dt_device_node *node,
+   const struct dt_device_node *gic,
void *fdt)
 {
-return gic_hw_ops->make_hwdom_dt_node(d, node, fdt);
+ASSERT(gic == dt_interrupt_controller);
+
+return gic_hw_ops->make_hwdom_dt_node(d, gic, fdt);
 }
 
 /*
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index d343abf..6d53f97 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -350,13 +350,14 @@ struct gic_hw_operations {
 unsigned int (*read_apr)(int apr_reg);
 /* Secondary CPU 

[Xen-devel] [PATCH 8/8] xen/arm: platform: Drop the quirks callback

[Julien Grall]

All the quirks has been replaced by proper detection. Lets drop the
callback and hope that no one will need new quirks.

At the same time, remove the definition platform_dom0_evtchn_ppi with is
not used any more.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/platform.c| 10 --
 xen/include/asm-arm/platform.h |  8 
 2 files changed, 18 deletions(-)

diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index 0af6d57..b0bfaa9 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -127,16 +127,6 @@ void platform_poweroff(void)
 platform->poweroff();
 }
 
-bool_t platform_has_quirk(uint32_t quirk)
-{
-uint32_t quirks = 0;
-
-if ( platform && platform->quirks )
-quirks = platform->quirks();
-
-return !!(quirks & quirk);
-}
-
 bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
 {
 const struct dt_device_match *blacklist = NULL;
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index 5e462ac..f97315d 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -27,12 +27,6 @@ struct platform_desc {
 /* Platform power-off */
 void (*poweroff)(void);
 /*
- * Platform quirks
- * Defined has a function because a platform can support multiple
- * board with different quirk on each
- */
-uint32_t (*quirks)(void);
-/*
  * Platform blacklist devices
  * List of devices which must not pass-through to a guest
  */
@@ -48,9 +42,7 @@ int platform_cpu_up(int cpu);
 #endif
 void platform_reset(void);
 void platform_poweroff(void);
-bool_t platform_has_quirk(uint32_t quirk);
 bool_t platform_device_is_blacklisted(const struct dt_device_node *node);
-unsigned int platform_dom0_evtchn_ppi(void);
 
 #define PLATFORM_START(_name, _namestr) \
 static const struct platform_desc  __plat_desc_##_name __used   \
-- 
2.1.4


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

[Xen-devel] [PATCH 5/8] xen/arm: vgic-v2: Drop cbase from arch_domain

[Julien Grall]

The field value is only used within a single function in the vgic-v2
emulation. So it's not necessary to store the value in the domain
structure.

This is also saving 8 bytes on a structure which begin to be constrained
(the maximum size of struct domain is 4KB).

Signed-off-by: Julien Grall 
---
 xen/arch/arm/vgic-v2.c   | 11 ++-
 xen/include/asm-arm/domain.h |  1 -
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index fa71598..ecd6bf3 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -546,6 +546,7 @@ static int vgic_v2_vcpu_init(struct vcpu *v)
 static int vgic_v2_domain_init(struct domain *d)
 {
 int i, ret;
+paddr_t cbase;
 
 /*
  * The hardware domain gets the hardware address.
@@ -554,12 +555,12 @@ static int vgic_v2_domain_init(struct domain *d)
 if ( is_hardware_domain(d) )
 {
 d->arch.vgic.dbase = vgic_v2_hw.dbase;
-d->arch.vgic.cbase = vgic_v2_hw.cbase;
+cbase = vgic_v2_hw.cbase;
 }
 else
 {
 d->arch.vgic.dbase = GUEST_GICD_BASE;
-d->arch.vgic.cbase = GUEST_GICC_BASE;
+cbase = GUEST_GICC_BASE;
 }
 
 /*
@@ -569,16 +570,16 @@ static int vgic_v2_domain_init(struct domain *d)
  * The second page is always mapped at +4K irrespective of the
  * GIC_64K_STRIDE quirk. The DTB passed to the guest reflects this.
  */
-ret = map_mmio_regions(d, paddr_to_pfn(d->arch.vgic.cbase), 1,
+ret = map_mmio_regions(d, paddr_to_pfn(cbase), 1,
paddr_to_pfn(vgic_v2_hw.vbase));
 if ( ret )
 return ret;
 
 if ( !platform_has_quirk(PLATFORM_QUIRK_GIC_64K_STRIDE) )
-ret = map_mmio_regions(d, paddr_to_pfn(d->arch.vgic.cbase + PAGE_SIZE),
+ret = map_mmio_regions(d, paddr_to_pfn(cbase + PAGE_SIZE),
1, paddr_to_pfn(vgic_v2_hw.vbase + PAGE_SIZE));
 else
-ret = map_mmio_regions(d, paddr_to_pfn(d->arch.vgic.cbase + PAGE_SIZE),
+ret = map_mmio_regions(d, paddr_to_pfn(cbase + PAGE_SIZE),
1, paddr_to_pfn(vgic_v2_hw.vbase + SZ_64K));
 
 if ( ret )
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index c3f5a95..ba430a7 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -101,7 +101,6 @@ struct arch_domain
 struct pending_irq *pending_irqs;
 /* Base address for guest GIC */
 paddr_t dbase; /* Distributor base address */
-paddr_t cbase; /* CPU base address */
 #ifdef HAS_GICV3
 /* GIC V3 addressing */
 /* List of contiguous occupied by the redistributors */
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] x86/p2m: add PoD accounting to set_typed_p2m_entry()

[George Dunlap]

On 09/22/2015 02:01 PM, Jan Beulich wrote:
> While neither PoD together with pass-through nor PVH are currently
> supported we still shouldn't leave in place such latent issues.
> 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Tim Deegan 

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

[George Dunlap]

On 09/22/2015 05:42 AM, Juergen Gross wrote:
> One other thing I just discovered: there are other consumers of the
> topology sibling masks (e.g. topology_sibling_cpumask()) as well.
> 
> I think we would want to avoid any optimizations based on those in
> drivers as well, not only in the scheduler.

I'm beginning to lose the thread of the discussion here a bit.

Juergen / Dario, could one of you summarize your two approaches, and the
(alleged) advantages and disadvantages of each one?

Thanks,
 -George

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

Re: [Xen-devel] [PATCH for-4.6 2/2] libxl: fix the cleanup of the backend path when using driver domains

[Ian Jackson]

Roger Pau Monne writes ("[PATCH for-4.6 2/2] libxl: fix the cleanup of the 
backend path when using driver domains"):
> With the current libxl implementation the control domain will remove both
> the frontend and the backend xenstore paths of a device that's handled by a
> driver domain. This is incorrect, since the driver domain possibly needs to
> access the backend path in order to perform the disconnection and cleanup of
> the device.
> 
> Fix this by making sure the control domain only cleans the frontend path,
> leaving the backend path to be cleaned by the driver domain. Note that if
> the device is not handled by a driver domain the control domain will perform
> the removal of both the frontend and the backend paths.
> 
> Signed-off-by: Roger Pau Monné 
> Reported-by: Alex Velazquez 

Acked-by: Ian Jackson 

I would like to have a second review before committing, and also we
should wait for a release ack from Wei.

Thanks,
Ian.

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

[Xen-devel] Xen, ACPI and Linux

[Stefano Stabellini]

Hi all,

Mark, Ard and I have just had a discussion on ACPI, EFI and booting
interfaces for Xen and kexec.

We all agree that the most important thing to do is to document
precisely what this interface looks like. Not just the device tree
nodes, but also who calls ExitBootServices, SetVirtualAddressMap, etc.
We need to make clear that it is an external interface and will be
maintained for backward compatibility going forward.  The proposed
renaming of the device tree nodes is OK, and can be part of it.



Regarding Runtime Services, the EFI spec doesn't allow a NULL pointer to
the Runtime Services table, so Mark would like to see a proper pointer
being passed there.  The function table could be populated with
hypercall wrappers in assembly, keeping the same interface to Xen that
we have today in drivers/xen/efi.c. It should be part of the initial
patch series.

If that turns out to be very hard to do (which is unlikely), or if that
approach has any unforeseen problems, we could specify in the external ABI
document that the Runtime Services table pointer can be NULL. Mark
would be less happy with this solution, let's try the other one first.


Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v7 05/17] vmx: Extend struct pi_desc to support VT-d Posted-Interrupts

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 22, 2015 10:20 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Tian, Kevin; xen-devel@lists.xen.org; Keir Fraser
> Subject: Re: [PATCH v7 05/17] vmx: Extend struct pi_desc to support VT-d
> Posted-Interrupts
> 
> >>> On 11.09.15 at 10:28,  wrote:
> > Extend struct pi_desc according to VT-d Posted-Interrupts Spec.
> >
> > Signed-off-by: Feng Wu 
> > Reviewed-by: Andrew Cooper 
> > Acked-by: Kevin Tian 
> > Reviewed-by: Konrad Rzeszutek Wilk 
> > ---
> > v7:
> > - Coding style.
> 
> Are you sure?
> 
> > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> > @@ -80,8 +80,18 @@ struct vmx_domain {
> >
> >  struct pi_desc {
> >  DECLARE_BITMAP(pir, NR_VECTORS);
> > -u32 control;
> > -u32 rsvd[7];
> > +union {
> > +struct {
> > +u16 on : 1,  /* bit 256 - Outstanding Notification */
> > +sn : 1,  /* bit 257 - Suppress Notification */
> > +rsvd_1 : 14; /* bit 271:258 - Reserved */
> > +u8  nv;  /* bit 279:272 - Notification Vector */
> > +u8  rsvd_2;  /* bit 287:280 - Reserved */
> > +u32 ndst;/* bit 319:288 - Notification Destination
> */
> > +};
> 
> Clearly the body of the structure is still mis-indented.

Seeing from the code, this structure is well indented. where do you
think it has problem?

Thanks,
Feng

> 
> Jan


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

[Xen-devel] [qemu-upstream-4.2-testing baseline-only test] 38010: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38010 qemu-upstream-4.2-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38010/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail baseline 
untested
 test-i386-i386-xl-qemuu-winxpsp3 13 guest-localmigrate  fail baseline untested
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 21 leak-check/check   fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xend-qemuu-winxpsp3 21 leak-check/checkfail never pass


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
 test-amd64-i386-xend-qemuu-winxpsp3  fail
 test-amd64-amd64-xl-qemuu-winxpsp3   fail
 test-i386-i386-xl-qemuu-winxpsp3 fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Konrad Rzeszutek Wilk]

On Tue, Sep 22, 2015 at 01:17:03PM -0700, Ed Swierk wrote:
> RFC. Tested with 3.14.51 and Xen 4.5.1. I'll make a proper patch against a
> more current kernel if we decide this is heading in the right direction.

CC-ing David as well
> 
> 
> xen/mcfg: Notify Xen of PCI MMCONFIG area before adding device
> 
> On systems where the ACPI DSDT advertises a PCI MMCONFIG area but the
> E820
> table does not reserve it, it's up to Dom0 to inform Xen of MMCONFIG
> areas
> via PHYSDEVOP_pci_mmcfg_reserved.  This needs to happen before Xen
> tries to
> access extended capabilities like SRIOV in pci_add_device(), which is
> triggered by PHYSDEVOP_pci_device_add et al.
> 
> Since both MMCONFIG discovery and PCI bus enumeration occur in
> acpi_init(),
> calling PHYSDEVOP_pci_mmcfg_reserved cannot be delegated to a separate
> initcall.  Instead, it can be done in xen_pci_notifier() immediately
> before
> calling PHYSDEVOP_pci_device_add.
> 
> Without this change, Xen 4.4 and 4.5 emit WARN messsages from
> msix_capability_init() when setting up Intel 82599 VFs, since vf_rlen
> has
> not been initialized by pci_add_device().  And on Xen 4.5, Xen nukes the
> DomU due to "Potentially insecure use of MSI-X" when the VF driver
> loads in
> the DomU.  Both problems are fixed by this change.
> 
> Signed-off-by: Ed Swierk 
> 
> diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> index dd9c249..47f6b45 100644
> --- a/drivers/xen/pci.c
> +++ b/drivers/xen/pci.c
> @@ -26,8 +26,57 @@
>  #include 
>  #include 
>  #include "../pci/pci.h"
> +
>  #ifdef CONFIG_PCI_MMCONFIG
>  #include 
> +#include 
> +
> +/* pci_mmcfg_list entries that have already been reported to xen */
> +LIST_HEAD(xen_pci_mmcfg_list);
> +
> +static void xen_report_pci_mmcfg_region(u16 segment, u8 bus)
> +{
> + struct pci_mmcfg_region *cfg, *new;
> + struct physdev_pci_mmcfg_reserved r;
> + int rc;
> +
> + if ((pci_probe & PCI_PROBE_MMCONF) == 0)
> + return;
> +
> + cfg = pci_mmconfig_lookup(segment, bus);
> + if (!cfg)
> + return;
> +
> + list_for_each_entry_rcu(new, _pci_mmcfg_list, list) {
> + if (new->segment == cfg->segment &&
> +new->start_bus == cfg->start_bus &&
> +new->end_bus == cfg->end_bus)
> + return;
> + }
> +
> + r.address = cfg->address;
> + r.segment = cfg->segment;
> + r.start_bus = cfg->start_bus;
> + r.end_bus = cfg->end_bus;
> + r.flags = XEN_PCI_MMCFG_RESERVED;
> + rc = HYPERVISOR_physdev_op(PHYSDEVOP_pci_mmcfg_reserved, );
> + if (rc != 0 && rc != -ENOSYS) {
> + pr_warn("Failed to report MMCONFIG reservation state for %s"
> + " to hypervisor (%d)\n", cfg->name, rc);
> + }
> +
> + new = kmemdup(cfg, sizeof(*new), GFP_KERNEL);
> + if (new) {
> + list_add_tail_rcu(>list, _pci_mmcfg_list);
> + } else {
> + pr_warn("Failed to allocate xen_pci_mmcfg_list entry\n");
> + }
> +}
> +
> +#else
> +
> +static void xen_report_pci_mmcfg_region(u16 segment, u8 bus) { }
> +
>  #endif
> 
>  static bool __read_mostly pci_seg_supported = true;
> @@ -86,6 +135,7 @@ static int xen_add_device(struct device *dev)
>   }
>  #endif /* CONFIG_ACPI */
> 
> + xen_report_pci_mmcfg_region(add.seg, add.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_add, );
>   if (r != -ENOSYS)
>   return r;
> @@ -104,6 +154,7 @@ static int xen_add_device(struct device *dev)
>   .physfn.devfn = physfn->devfn,
>   };
> 
> + xen_report_pci_mmcfg_region(0, manage_pci_ext.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add_ext,
>   _pci_ext);
>   }
> @@ -115,6 +166,7 @@ static int xen_add_device(struct device *dev)
>   .is_extfn = 1,
>   };
> 
> + xen_report_pci_mmcfg_region(0, manage_pci_ext.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add_ext,
>   _pci_ext);
>   } else {
> @@ -123,6 +175,7 @@ static int xen_add_device(struct device *dev)
>   .devfn = pci_dev->devfn,
>   };
> 
> + xen_report_pci_mmcfg_region(0, manage_pci.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_add,
>   _pci);
>   }
> @@ -142,6 +195,7 @@ static int xen_remove_device(struct device *dev)
>   .devfn = pci_dev->devfn
>   };
> 
> + xen_report_pci_mmcfg_region(device.seg, device.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_remove,
>);
>   } else if (pci_domain_nr(pci_dev->bus))
> @@ -152,6 +206,7 @@ static int xen_remove_device(struct device *dev)
>   .devfn = pci_dev->devfn
>   };
> 
> + xen_report_pci_mmcfg_region(0, manage_pci.bus);
>   r = HYPERVISOR_physdev_op(PHYSDEVOP_manage_pci_remove,
>_pci);
>   }
> @@ -195,49 +250,3 @@ static int __init register_xen_pci_notifier(void)
>  }
> 
>  arch_initcall(register_xen_pci_notifier);
> -
> -#ifdef CONFIG_PCI_MMCONFIG
> -static int __init xen_mcfg_late(void)
> -{
> - struct pci_mmcfg_region *cfg;
> - int rc;
> -
> - if (!xen_initial_domain())
> - return 0;
> -
> - if ((pci_probe & PCI_PROBE_MMCONF) == 0)
> - return 0;
> -
> - if (list_empty(_mmcfg_list))
> - return 0;
> -
> - /* Check whether they are in the right area. */
> 

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Stefano Stabellini]

On Tue, 22 Sep 2015, Ian Campbell wrote:
> (dropping minios-devel)
> 
> Stefano,
> 
> On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> > 
> > There are 3 series, against xen.git (15 patches), mini-os.git (5
> > patches) and qemu-xen-trad.git (5 patches). The patches against xen.git
> > point to the patches in the other two trees via instructions to update
> > the relevant Config.mk field. The perils of changing unstable
> > interfaces!
> 
> I started looking into making the appropriate changes to QEMU upstream to
> use the new libraries directly.
> 
> QEMU (in include/hw/xen/xen_common.h) includes compat shims for libxenctrl
> versions back as far as 3.3.0.
> 
> The main distinction is between pre-4.1.0 and 4.1.0 and later, since
> various handles switching from int's to opaque pointers at that point,
> meaning there are some typedefs and wrappers for things.
> 
> My plan was to rework the QEMU code to use only the new library function
> names for everything such that this becomes the default case (which makes
> sense given these libraries are intended to be long term stable) and to
> update the code in xen_common.h to bridge the gap to 4.6 and earlier.
> 
> But I'm having to jump through some hoops in order to support the pre-4.1.0
> version of things. It's not impossible to support it, I'm sure, but things
> would be a lot easier if we could just drop that support code.
> 
> Can we consider dropping support for Xen 4.0 and earlier from upstream QEMU
> at this point?
> 
> Some data: Xen 4.0.0 was released in April 2010, the last point release was
> 4.0.4 in August 2012 and we no longer do security support for it (for a
> year or two now, I think).
 
The oldest Xen version I build-test for every pull request is Xen 4.0.0,
I think it is very reasonable to remove anything older than that.
I am OK with removing Xen 4.0.0 too, but I would like a warning to be
sent ahead of time to qemu-devel to see if anybody complains.

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

[Xen-devel] [linux-3.18 test] 62178: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 58581

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 58581
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail baseline untested
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail baseline untested
 test-armhf-armhf-xl-rtds 15 guest-start.2   fail baseline untested
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   like 58581
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 58581
 test-armhf-armhf-xl   6 xen-boot fail   like 58581
 test-armhf-armhf-xl-xsm   6 xen-boot fail   like 58581
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 58581
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 58581
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 58581
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 58581

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   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-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxfcd9bfdb9d884f1aab89124dee894e7d821bb5dc
baseline version:
 linuxd048c068d00da7d4cfa5ea7651933b99026958cf

Last test of basis58581  2015-06-15 09:42:22 Z   99 days
Failing since 58976  2015-06-29 19:43:23 Z   85 days   61 attempts
Testing same since61524  2015-09-07 11:48:03 Z   15 days7 attempts


462 people touched revisions under test,
not listing them all

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
 

Re: [Xen-devel] [PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr as well as /usr/local

[Stefano Stabellini]

On Tue, 22 Sep 2015, Ian Jackson wrote:
> (CCing Stefano)
> 
> Ian Campbell writes ("Re: [PATCH OSSTEST] make_qcow2: Look for qemu-img under 
> /usr as well as /usr/local"):
> > On Tue, 2015-09-22 at 16:41 +0100, Ian Jackson wrote:
> > > Ian Campbell writes ("[PATCH OSSTEST] make_qcow2: Look for qemu-img under
> > > /usr as well as /usr/local"):
> > > > Older Xen's installed in /usr by default, so we need to check where
> > > > qemu-img if we want these tests to work on those versions.
> > > 
> > > Acked-by: Ian Jackson 
> > > 
> > > But, why are we executing a utility from /usr/lib/xen/bin ?  If this
> > > utility is useful to osstest it is presumably useful to users too, and
> > > in that case it should be on PATH (under some suitable name).
> > 
> > We install qemu-upstream under our own prefix, I think to avoid conficting
> > with the users own qemu installations?
> > 
> > qemu-img comes from there. We do install qemu-xen-img (from trad) into
> > $PATH, but when I wrote this test I thought it preferable to use qemu-img.
> 
> Maybe we should be installing qemu-img from our qemu upstream build
> instead ?
> 
> We evidently don't think that there is anything in the qcow block
> system in trad that we like, because we are only using upstream for
> qdisk vbd backends now.

Yes, this is a good idea. Qcow support is much better in upstream QEMU
compared to qemu-trad.

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

Re: [Xen-devel] [PATCH] Remove a set operation for VCPU_KICK_SOFTIRQ when post interrupt to vm.

[Zhang, Yang Z]

Zhang, Yang Z wrote on 2015-09-08:
> Liuqiming (John) wrote on 2015-09-08:
>> Ok, I will try to explain, correct me if I got anything wrong:
>> 
>> The problem here is not interrupts lost but interrupts not delivered
>> in time.
>> 
>> there are basically two path to inject an interrupt into VM  (or
>> vCPU to another vCPU):
>> Path 1, the traditional way:
>>1) set bit  in vlapic IRR field which represent an interrupt,
>>then kick vcpu 2) a VCPU_KICK_SOFTIRQ softirq raised 3) if
>>VCPU_KICK_SOFTIRQ bit not set, then set it, otherwise return and
>>do nothing 4) send an EVENT_CHECK_VECTOR IPI  to target vcpu 5)
>>target vcpu will VMEXIT due to EXIT_REASON_EXTERNAL_INTERRUPT 6)
>>the interrupt handler basically do nothing 7) interrupt in IRR
>>will be evaluated 8) VCPU_KICK_SOFTIRQ will be cleared when
>>do_softirq 9) there will be an interrupt inject into vcpu when
>>VMENTRY Path 2, the Posted-interrupt way (current logic): 1) set
>>bit in posted-interrupt descriptor which represent an interrupt
>>2) if VCPU_KICK_SOFTIRQ bit not set, then set it, otherwise
>>return and do nothing 3) send an POSTED_INTR_NOTIFICATION_VECTOR
>>IPI to target vcpu 4) if target vcpu in non-ROOT mode it will
>>receive the interrupt
>> immediately otherwise interrupt will be injected when VMENTRY
>> 
>> As the first operation in both path is setting a interrupt represent
>> bit, so no interrupts will lost.
>> 
>> The issue is:
>> in path 2, the first interrupt will cause VCPU_KICK_SOFTIRQ set to
>> 1, and unless a VMEXIT occured or somewhere called do_softirq
>> directly, VCPU_KICK_SOFTIRQ will not cleared, that will make the
>> later interrupts injection  ignored at step 2), which will delay irq
>> handler process in VM.
>> 
>> And because path 2 set VCPU_KICK_SOFTIRQ to 1, the kick vcpu logic
>> in path 1 will also return in step 3), which make this vcpu only can
>> handle interrupt when some other reason cause VMEXIT.
> 
> Nice catch! But without set the softirq, the interrupt delivery also will be 
> delay.
> Look at the code in vmx_do_vmentry:
> 
> cli
> <---the virtual interrupt occurs here will be
> delay. Because there is no softirq pending and the following posted
> interrupt may consumed by another running VCPU, so the target VCPU
> will not aware there is pending virtual interrupt before next vmexit.
> cmp  %ecx,(%rdx,%rax,1)
> jnz  .Lvmx_process_softirqs
> 
> I need more time to think it.

Hi Qiming,

Can you help to take a look at this patch? Also, if possible, please help to do 
a testing since I don't have machine to test it. Thanks very much.

diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index 664ed83..1ebb5d0 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -77,6 +77,9 @@ UNLIKELY_START(ne, realmode)
 call vmx_enter_realmode
 UNLIKELY_END(realmode)
 
+bt   $0,VCPU_vmx_pi_ctrl(%rbx)
+jc   .Lvmx_do_vmentry
+
 mov  %rsp,%rdi
 call vmx_vmenter_helper
 mov  VCPU_hvm_guest_cr2(%rbx),%rax
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index e0e9e75..315ce65 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1678,8 +1678,9 @@ static void __vmx_deliver_posted_interrupt(struct vcpu *v)
 {
 unsigned int cpu = v->processor;
 
-if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))
- && (cpu != smp_processor_id()) )
+if ( !test_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))
+ && pi_test_on(>arch.hvm_vmx.pi_desc)
+ && (cpu != smp_processor_id()))
 send_IPI_mask(cpumask_of(cpu), posted_intr_vector);
 }
 }
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 447c650..985725f 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -108,6 +108,7 @@ void __dummy__(void)
 OFFSET(VCPU_vmx_emulate, struct vcpu, arch.hvm_vmx.vmx_emulate);
 OFFSET(VCPU_vm86_seg_mask, struct vcpu, arch.hvm_vmx.vm86_segment_mask);
 OFFSET(VCPU_hvm_guest_cr2, struct vcpu, arch.hvm_vcpu.guest_cr[2]);
+OFFSET(VCPU_vmx_pi_ctrl, struct vcpu, arch.hvm_vmx.pi_desc.control);
 BLANK();
 
 OFFSET(VCPU_nhvm_guestmode, struct vcpu, arch.hvm_vcpu.nvcpu.nv_guestmode);
diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 35f804a..157a4fe 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -116,6 +116,11 @@ static inline void pi_set_on(struct pi_desc *pi_desc)
 set_bit(POSTED_INTR_ON, _desc->control);
 }
 
+static inline int pi_test_on(struct pi_desc *pi_desc)
+{
+return test_bit(POSTED_INTR_ON, _desc->control);
+}
+
 static inline int pi_test_and_clear_on(struct pi_desc *pi_desc)
 {
 return test_and_clear_bit(POSTED_INTR_ON, 

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Tuesday, September 22, 2015 10:28 PM
> To: Wu, Feng; Dario Faggioli
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On 09/22/2015 02:25 PM, Wu, Feng wrote:
> >>> But if we want to avoid spurious PI interrupts when running idle, then
> >>> yes, we need *some* kind of a hook on the lazy context switch path.
> >>>
> >>> /me does some more thinking...
> >>
> >> To be honest, since we'll be get spurious PI interrupts in the
> >> hypervisor all the time anyway, I'm inclined at the moment not to worry
> >> to much about this case.
> >
> > Why do you say "we'll be get spurious PI interrupts in the  hypervisor all 
> > the
> time"?
> >
> > And could you please share what is your concern to handle this case to avoid
> > such spurious PI interrupts? Thanks!
> 
> So please correct me if I'm wrong in my understanding:
> 
> * When a vcpu is in runstate "running", with PI enabled, you have the PI
> vector set to "posted_interrupt_vector", SN=0.
> 
> * When in this state in non-root mode, PI interrupts result in an
> interrupt being delivered directly to the guest.
> 
> * When in this state in root mode, PI interrupts result in a
> posted_interrupt_vector interrupt being delivered to Xen.
> 
> Is that the case?

Exactly, it is how PI works today.

Thanks,
Feng

> 
> So basically, if the PI happens to come in when the guest is making a
> hypercall, or the guest is doing any other number of things that involve
> the hypervisor, then Xen will get a "spurious" PI interrupt -- spurious
> because there's nothing Xen actually needs to do about it; the guest
> interrupt will be delivered the next time we do a VMENTER.
> 
> So spurious PI interrupts are already going to happen from time to time
> -- they're not really that big of a deal.  Having them happen when a VM
> is running a tasklet or idle waiting for qemu isn't such a big deal either.



> 
>  -George

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

Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

[Juergen Gross]

On 09/22/2015 06:22 PM, George Dunlap wrote:

On 09/22/2015 05:42 AM, Juergen Gross wrote:

One other thing I just discovered: there are other consumers of the
topology sibling masks (e.g. topology_sibling_cpumask()) as well.

I think we would want to avoid any optimizations based on those in
drivers as well, not only in the scheduler.


I'm beginning to lose the thread of the discussion here a bit.

Juergen / Dario, could one of you summarize your two approaches, and the
(alleged) advantages and disadvantages of each one?


Okay, I'll have a try:

The problem we want to solve:
-

The Linux kernel is gathering cpu topology data during boot via the
CPUID instruction on each processor coming online. This data is
primarily used in the scheduler to decide to which cpu a thread should
be migrated when this seems to be necessary. There are other users of
the topology information in the kernel (e.g. some drivers try to do
optimizations like core-specific queues/lists).

When started in a virtualized environment the obtained data is next to
useless or even wrong, as it is reflecting only the status of the time
of booting the system. Scheduling of the (v)cpus done by the hypervisor
is changing the topology beneath the feet of the Linux kernel without
reflecting this in the gathered topology information. So any decisions
taken based on that data will be clueless and possibly just wrong.

The minimal solution is to change the topology data in the kernel in a
way that all cpus are regarded as equal regarding their relation to each
other (e.g. when migrating a thread to another cpu no cpu is preferred
as a target).

The topology information of the CPUID instruction is, however, even
accessible form user mode and might be used for licensing purposes of
any user program (e.g. by limiting the software to run on a specific
number of cores or sockets). So just mangling the data returned by
CPUID in the hypervisor seems not to be a general solution, while we
might want to do it at least optionally in the future.

In the future we might want to support either dynamic topology updates
or be able to tell the kernel to use some of the topology data, e.g.
when pinning vcpus.


Solution 1 (Dario):
---

Don't use the CPUID derived topology information in the Linux scheduler,
but let it use a simple "flat" topology by setting own scheduler domain
data under Xen.

Advantages:
+ very clean solution regarding the scheduler interface
+ scheduler decisions are based on a minimal data set
+ small patch

Disadvantages:
- covers the scheduler only, drivers still use the "wrong" data
- a little bit hacky regarding some NUMA architectures (needs either a
  hook in the code dealing with that architecture or multiple scheduler
  domain data overwrites)
- future enhancements will make the solution less clean (either need
  duplicating scheduler domain data or some new hooks in scheduler
  domain interface)


Solution 2 (Juergen):
-

When booted as a Xen guest modify the topology data built during boot
resulting in the same simple "flat" topology as in Dario's solution.

Advantages:
+ the simple topology is seen by all consumers of topology data as the
  data itself is modified accordingly
+ small patch
+ future enhancements rather easy by selecting which data to modify

Disadvantages:
- interface to scheduler not as clean as in Dario's approach
- scheduler decisions are based on multiple layers of topology data
  where one layer would be enough to describe the topology


Dario, are you okay with this summary?

Juergen

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat 
fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-qcow2  6 xen-boot  fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux99bc7215bc60f6cd414cf1b85cd9d52cc596cccb
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z   75 days
Failing since 59348  2015-07-10 04:24:05 Z   74 days   43 attempts
Testing same since62197  2015-09-20 10:42:19 Z2 days1 attempts


2307 people touched revisions under test,
not listing them all

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
 

Re: [Xen-devel] [PATCH v6 2/2] xen/arm: support gzip compressed kernels

[Stefano Stabellini]

On Tue, 22 Sep 2015, Julien Grall wrote:
> On 21/09/2015 23:51, Stefano Stabellini wrote:
> > +/*
> > + * Need to free pages after output_size here because they won't be
> > + * freed by discard_initial_modules
> > + */
> > +i = (output_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> > +for ( ; i < (1 << kernel_order_out); i++ )
> > +free_domheap_page(pages + i);
> > +
> > +vunmap(output);
> > +
> 
> I forgot to mention that vunmap should be called before free_domheap_pages to
> avoid mapping on unallocated pages.
 
You are right, thanks

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

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Samuel Thibault]

Andreas Sundstrom, le Mon 21 Sep 2015 22:03:22 +0200, a écrit :
> Note that my original thought was that this bug probably is within GRUB.

It's probably in the GRUB implementation of loading the domU GRUB, since
you say that pvgrub1 loads it fine.

> (XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0
> compat_create_bounce_frame+0xc6/0xde

So it's inside xen entry code...

> (XEN) Guest stack trace from esp=005a5ff0:

This looks like the end of the stack

> (XEN) 0010  0001e019 00010046 0016b38b 0016b38a 0016b389
> 0016b388
> (XEN) 0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 0016b381
> 0016b380
[...]

and this looks like a lot of consecutive numbers.  Perhaps we simply
somehow overflow?  Did you try giving less memory to the domU?

> I see no output from the domU grub (except when it works as it should
> of course).

Yes, as explained in another mail domU has to get to connect to the
console before getting messages from there.  Another way is to make
console_io hypercalls, which should end up into xl dmesg.

You may also want to enable grub debugging prints, by setting the debug
variable to "all".

Samuel

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

Re: [Xen-devel] vTPM ownership problem

[Zhenyang Feng]

I cleared TPM hardware, resetted it and upgraded xen to 4.5.0. But the same
problem still exists.
~# tpm_takeownership
Enter owner password:
Confirm password:
Enter SRK password:
Confirm password:
Tspi_TPM_TakeOwnership failed: 0x2004 - layer=tcs, code=0004 (4),
Internal software error


Here is my vtpmmgr / vtpm instance log.


*vtpmmgr:*
Xen Minimal OS!
  start_info: 0xea000(VA)
nr_pages: 0x8000
  shared_inf: 0xdb49c000(MA)
 pt_base: 0xed000(VA)
nr_pt_frames: 0x5
mfn_list: 0xaa000(VA)
   mod_start: 0x0(VA)
 mod_len: 0
   flags: 0x0
cmd_line:
   stack: 0x68d00-0x88d00
MM: Init
  _text: 0x0(VA)
 _etext: 0x44133(VA)
   _erodata: 0x5(VA)
 _edata: 0x53380(VA)
stack start: 0x68d00(VA)
   _end: 0xa9340(VA)
  start_pfn: f5
max_pfn: 8000
Mapping memory range 0x40 - 0x800
setting 0x0-0x5 readonly
skipped 0x1000
MM: Initialise page allocator for 133000(133000)-800(800)
MM: done
Demand map pfns at 8001000-2008001000.
Heap resides at 2008002000-4008002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x8001000.
Initialising scheduler
Thread "Idle": pointer: 0x2008002050, stack: 0x18
Thread "xenstore": pointer: 0x2008002800, stack: 0x19
xenbus initialised on irq 1 mfn 0x122f20
Thread "shutdown": pointer: 0x2008002fb0, stack: 0x1a
main.c: dummy main: start_info=0x88e00
Thread "main": pointer: 0x2008003760, stack: 0x1b
"main"
INFO[VTPM]: Starting vTPM manager domain
INFO[VTPM]: Option: Using tpm_tis driver
*** BLKFRONT for device/vbd/768 **


backend at /local/domain/0/backend/qdisk/1/768
Failed to read /local/domain/0/backend/qdisk/1/768/feature-barrier.
524288 sectors of 512 bytes
**
blk_open(device/vbd/768) -> 3
= Init TPM BACK 
Thread "tpmback-listener": pointer: 0x20080044b0, stack: 0x1c
= Init TPM TIS Driver ==
IOMEM Machine Base Address: FED4
Enabled Localities: 0
1.2 TPM (device-id=0x0 vendor-id = 104A rev-id = 4E)
TPM interface capabilities (0x15):
Interrupt Level Low
Locality Change Int Support
Data Avail Int Support
Timeout b was adjusted to standard value.
tpm_tis_open() -> 4
INFO[TPM]: TPM_GetCapability
INFO[VTPM]: Hardware TPM:
INFO[VTPM]:  version: 1 2 8 8
INFO[VTPM]:  specLevel: 2
INFO[VTPM]:  errataRev: 2
INFO[VTPM]:  vendorID: STM
INFO[VTPM]:  vendorSpecificSize: 0
INFO[VTPM]:  vendorSpecific:
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[VTPM]: Flushing 1 handle(s) of type 2
INFO[TPM]: TPM_FlushSpecific
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetCapability
INFO[TPM]: TPM_GetRandom
INFO[TPM]: TPM_GetRandom
INFO[TPM]: TPM_OIAP
INFO[TPM]: Auth Session: 0x44c0f7 opened by TPM_OIAP.
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
INFO[TPM]: TPM_PCR_Read
TPM Manager - disk format 0
 root seal: 84; sector of 13: 3924
 root: 3200 v=528
 itree: 36; sector of 112: 4032
 group: 3560 v=3472 id=816 md=280
 group seal: 72; 5 in parent: 1860; sector of 13: 3904
 vtpm: 20+64; sector of 48: 4048
INFO[VTPM]: disk_read_sector 0
INFO[VTPM]: disk_read_sector 1
load_root_pre: n/n
INFO[VTPM]: Failed to read manager file. Assuming first time initialization.
INFO[TPM]: TPM_ReadPubek
INFO[TPM]: TPM_TakeOwnership
INFO[TPM]: TPM_DisablePubekRead
INFO[TPM]: TPM_OSAP
INFO[TPM]: Auth Session: 0xabc128 opened by TPM_OSAP.
INFO[TPM]: TPM_SaveState
INFO[VTPM]: Finished initialized new VTPM manager
INFO[TPM]: TPM_TerminateHandle
INFO[TPM]: Auth Session: 0xabc128 closed by TPM_TerminateHandle
INFO[VTPM]: Waiting for commands from vTPM's:
Tpmback:Info Frontend 2/0 connected
INFO[VTPM]: Passthrough: TPM_GetRandom
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: Passthrough: TPM_GetRandom
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_LoadHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
SaveHashKey with unknown UUID=7740b63c-f6e3-4db2-a94c-9c5332609ad6 -
creating in auth0 (f=1)
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey
INFO[VTPM]: Waiting for commands from vTPM's:
INFO[VTPM]: vtpmmgr_SaveHashKey

[Xen-devel] [distros-debian-snapshot test] 38009: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 37991
 build-armhf   5 xen-build fail REGR. vs. 37991
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail REGR. 
vs. 37991
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail REGR. vs. 
37991

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-weekly-netinst-pygrub 13 guest-saverestore fail like 
37991
 test-amd64-i386-amd64-current-netinst-pygrub 9 debian-di-install fail like 
37991
 test-amd64-amd64-i386-current-netinst-pygrub 9 debian-di-install fail like 
37991
 test-amd64-i386-i386-current-netinst-pygrub 9 debian-di-install fail like 37991
 test-amd64-amd64-amd64-current-netinst-pygrub 9 debian-di-install fail like 
37991

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-daily-netboot-pvgrub 13 guest-saverestore fail never 
pass

baseline version:
 flight   37991

jobs:
 build-amd64  pass
 build-armhf  fail
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubpass
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  blocked 
 test-amd64-amd64-i386-daily-netboot-pygrub   pass
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  pass
 test-amd64-i386-i386-weekly-netinst-pygrub   pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Tuesday, September 22, 2015 10:39 PM
> To: George Dunlap; Wu, Feng
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On Tue, 2015-09-22 at 15:15 +0100, George Dunlap wrote:
> > On 09/22/2015 02:52 PM, Wu, Feng wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> 
> > > > Yes, the idle to vCPUB switch is covered by __context_switch(),
> > > > but
> > > it cannot change the PI state of vCPUA at that point. Like
> > > mentioned
> > > above, in this case, spurious PI interrupts happens.
> >
> > On the contrary, when __context_switch() is called for the idle ->
> > vcpuB
> > transition in the above scenario, it is *actually* context switching
> > from vcpuA to vcpuB, since vcpuA is still actually on the cpu.
> >  Which
> > means that if you add PI code into arch->ctxt_switch_from(), the case
> > you describe above will be handled automatically.
> >
> Yep, that's exactly what I was also writing... luckily, I've seen
> George's email before getting too far with that! :-P
> 
> That's the point of lazy context switch. The context of vCPUA is still
> on pCPUA during the time idle executes. If, at the next transition
> point, we switch from idle to vCPUA again, then nothing is needed, and
> we just saved one context saving and one context restoring operation.
> If it is something else, like in your case, we need to save vCPUA's
> context, which is actually what we have on pCPUA, despite idle (and not
> vCPUA itself) was what was running.

George & Dario, thanks much for sharing so many scheduler knowledge
to me, it is very useful. I think I was making a mistake about how
__context_switch() work when I wrote the emails above. Now it is
clear, the scenario I mentioned above can be covered in __context_switch().

> 
> > So the only downside to doing everything in block(), wake(), and
> > __context_switch() is that if a VM is offline, or preempted by a
> > tasklet, and an interrupt comes in, we will get a spurious PI (i.e.,
> > one
> > which interrupts us but we can't do anything useful about).
> >
> Indeed. And that also seems bearable to me. Feng, are there reasons why
> you think it's not?

I cannot think the bad effect of the spurious PI as well. I was just a little
confused about we can do this and why we don't do this. Maybe
context_switch() is a critical path, if we can bear those spurious PI,
it is not worth adding those logic in it at the cost of some performance
lost during scheduling. Is this your concern?

Thanks,
Feng

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

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

Re: [Xen-devel] [OSSTest Nested v12 20/21] Don't lvextend if actually no more space to extend

[Ian Campbell]

On Wed, 2015-09-16 at 15:27 +0100, Ian Jackson wrote:
> Robert Ho writes ("[OSSTest Nested v12 20/21] Don't lvextend if actually
> no more space to extend"):
> > Though passes if judgement, the
> > overall_limit_pe(\$vg_more_free_pe);
> > may final judge no more free_pe to extend.
> > So, check if $vg_more_free_pe is 0, if so, we don't lvextend,
> > otherwise lvextend will report error on nonsense operation.
> 
> I think this should be done by moving the start of the if block to
> after overall_limit_pe.  That would avoid a tested if (and various
> other slight anomalies).

IOW move the overall_limit_pe outside the if? 

Like so:

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 03ad35c..b35e91b 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -151,9 +151,9 @@ sub lvextend1 ($$$) {
 
 $do_limit_pe->(\$vg_more_free_pe, 'unstriped');
 
+overall_limit_pe(\$vg_more_free_pe);
 if ($vg_more_free_pe) {
 logm("$what: unstriped $vg_more_free_pe PEs");
-overall_limit_pe(\$vg_more_free_pe);
 $more_pe += $vg_more_free_pe;
 target_cmd_root($ho, "lvextend -i1 -l +$vg_more_free_pe $lv");
 }

(untested, but I've just tripped over this in a standalone run myself).

Ian.

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

Re: [Xen-devel] [PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr as well as /usr/local

[Ian Campbell]

On Tue, 2015-09-22 at 16:41 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST] make_qcow2: Look for qemu-img under
> /usr as well as /usr/local"):
> > Older Xen's installed in /usr by default, so we need to check where
> > qemu-img if we want these tests to work on those versions.
> 
> Acked-by: Ian Jackson 
> 
> But, why are we executing a utility from /usr/lib/xen/bin ?  If this
> utility is useful to osstest it is presumably useful to users too, and
> in that case it should be on PATH (under some suitable name).

We install qemu-upstream under our own prefix, I think to avoid conficting
with the users own qemu installations?

qemu-img comes from there. We do install qemu-xen-img (from trad) into
$PATH, but when I wrote this test I thought it preferable to use qemu-img.

Ian.

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

Re: [Xen-devel] [PATCH v2 20/23] x86: add multiboot2 protocol support for EFI platforms

[Jan Beulich]

>>> On 22.09.15 at 17:21,  wrote:
> On Thu, Aug 27, 2015 at 06:01:26AM -0600, Jan Beulich wrote:
>> >>> On 20.07.15 at 16:29,  wrote:
>> > @@ -130,6 +146,119 @@ print_err:
>> >  .Lhalt: hlt
>> >  jmp .Lhalt
>> >
>> > +.code64
>> > +
>> > +__efi64_start:
>> > +cld
>> > +
>> > +/* Check for Multiboot2 bootloader. */
>> > +cmp $MULTIBOOT2_BOOTLOADER_MAGIC,%eax
>> > +je  efi_multiboot2_proto
>> > +
>> > +/* Jump to not_multiboot after switching CPU to x86_32 mode. */
>> > +lea not_multiboot(%rip),%rdi
>> > +jmp x86_32_switch
>> > +
>> > +efi_multiboot2_proto:
>>
>> .L
> 
> Why do you want to hide labels which could be useful during debugging?

With a few exceptions, assembly code should follow C and other
high level languages: Symbol table entries only at function
boundaries (or whatever their suitable counterparts in assembly
are).

>> > +x86_32_switch:
>> > +cli
>> > +
>> > +/* Initialise GDT. */
>> > +lgdtgdt_boot_descr(%rip)
>> > +
>> > +/* Reload code selector. */
>> > +ljmpl   *cs32_switch_addr(%rip)
>> > +
>> > +.code32
>> > +
>> > +cs32_switch:
>> > +/* Initialise basic data segments. */
>> > +mov $BOOT_DS,%edx
>> > +mov %edx,%ds
>> > +mov %edx,%es
>> > +mov %edx,%fs
>> > +mov %edx,%gs
>> > +mov %edx,%ss
>>
>> I see no point in loading %fs and %gs with other than nul selectors.
>> I also think %ss should be loaded first. Which reminds me - what
>> about %rsp? Is it guaranteed to have its upper 32 bits clear, so you
>> can re-use the stack in 32-bit mode? (If it is, saying so in a comment
>> would be very desirable.)
> 
> I am not reusing %rsp value. %esp is initialized later in 32-bit code.
> Stack is not used until %esp is not initialized.

If you load %ss without loading the stack pointer, you should imo
at least add a comment saying when/where the other half will be
done.

>> > --- a/xen/common/efi/boot.c
>> > +++ b/xen/common/efi/boot.c
>> > @@ -79,6 +79,17 @@ static size_t wstrlen(const CHAR16 * s);
>> >  static int set_color(u32 mask, int bpp, u8 *pos, u8 *sz);
>> >  static bool_t match_guid(const EFI_GUID *guid1, const EFI_GUID *guid2);
>> >
>> > +static void efi_init(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
>> > *SystemTable);
>> > +static void efi_console_set_mode(void);
>> > +static EFI_GRAPHICS_OUTPUT_PROTOCOL *efi_get_gop(void);
>> > +static UINTN efi_find_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
>> > +   UINTN cols, UINTN rows, UINTN depth);
>> > +static void efi_tables(void);
>> > +static void setup_efi_pci(void);
>> > +static void efi_variables(void);
>> > +static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN 
>> > gop_mode);
>> > +static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
>> > *SystemTable);
>>
>> This is ugly; I'm sure there is a way to avoid these declarations.
> 
> This probably requires play with '#include "efi-boot.h"' and move
> somewhere before efi_start(). Maybe something else. If it is not
> a problem for you I can do that.

Indeed moving an #include would seem far better than adding almost
a dozen declarations (any of which will need to get touched if the
respective definition changes, i.e. arranging for future churn).

Jan


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

Re: [Xen-devel] [PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr as well as /usr/local

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST] make_qcow2: Look for qemu-img under /usr 
as well as /usr/local"):
> Older Xen's installed in /usr by default, so we need to check where
> qemu-img if we want these tests to work on those versions.

Acked-by: Ian Jackson 

But, why are we executing a utility from /usr/lib/xen/bin ?  If this
utility is useful to osstest it is presumably useful to users too, and
in that case it should be on PATH (under some suitable name).

Ian.

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

Re: [Xen-devel] [PATCH v3] xen/xsm: Make p->policyvers be a local variable (ver) to shut up GCC 5.1.1 warnings.

[Daniel De Graaf]

On 16/09/15 15:57, Konrad Rzeszutek Wilk wrote:

policydb.c: In function ‘user_read’:
policydb.c:1443:26: error: ‘buf[2]’ may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
  usrdatum->bounds = le32_to_cpu(buf[2]);
   ^
cc1: all warnings being treated as errors

Which (as Andrew mentioned) is because GCC cannot assume
that 'p->policyvers' has the same value between checks.

We make it local, optimize the name to 'ver' and the warnings go away.
We also update another call site with this modification to
make it more inline with the rest of the functions.

Signed-off-by: Konrad Rzeszutek Wilk 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH V2 1/2] xen, libxc: Fine grained control of REP emulation optimizations

[Razvan Cojocaru]

On 09/22/2015 06:39 PM, Jan Beulich wrote:
 On 22.09.15 at 17:28,  wrote:
>> On 09/22/2015 06:17 PM, Jan Beulich wrote:
>> On 21.09.15 at 15:31,  wrote:
 --- a/xen/arch/x86/hvm/emulate.c
 +++ b/xen/arch/x86/hvm/emulate.c
 @@ -514,7 +514,8 @@ static int hvmemul_virtual_to_linear(
   * being triggered for repeated writes to a whole page.
   */
  *reps = min_t(unsigned long, *reps,
 -  
 unlikely(current->domain->arch.mem_access_emulate_enabled)
 +  
 unlikely(current->domain->arch.mem_access_emulate_enabled &&
 +   
 current->domain->arch.mem_access_emulate_each_rep)
 ? 1 : 4096);
>>>
>>> unlikely() should not wrap compound conditions, or else its effect of
>>> eliminating mis-predicted branches from the fast path won't be
>>> achieved. In the case here I wonder though whether you couldn't
>>> simply test only ->arch.mem_access_emulate_each_rep.
>>
>> I'll unfold the unlikely().
>>
>> Testing only ->arch.mem_access_emulate_each_rep is what I had done in
>> the original patch, however on Andrew Cooper's suggestion I've now gated
>> this on ->domain->arch.mem_access_emulate_enabled as well.
>>
>> Otherwise, somebody might set mem_access_emulate_each_rep via its
>> xc_monitor_*() call, but then after calling xc_monitor_disable() it
>> would still be in effect, even if the guest is no longer being monitored.
>>
>> If this is not a problem, I'm happy to check just
>> ->arch.mem_access_emulate_each_rep.
> 
> Or perhaps "disabled" should just clear that flag, also to not surprise
> the next one to "enable"?

Fair point, I'll do that.


Thanks,
Razvan

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

Re: [Xen-devel] [OSSTest Nested v12 20/21] Don't lvextend if actually no more space to extend

[Ian Jackson]

Ian Campbell writes ("Re: [OSSTest Nested v12 20/21] Don't lvextend if actually 
no more space to extend"):
> On Wed, 2015-09-16 at 15:27 +0100, Ian Jackson wrote:
> > I think this should be done by moving the start of the if block to
> > after overall_limit_pe.  That would avoid a tested if (and various
> > other slight anomalies).
> 
> IOW move the overall_limit_pe outside the if? 
> 
> Like so:
> 
> diff --git a/ts-xen-build-prep b/ts-xen-build-prep
> index 03ad35c..b35e91b 100755
> --- a/ts-xen-build-prep
> +++ b/ts-xen-build-prep
> @@ -151,9 +151,9 @@ sub lvextend1 ($$$) {
>  
>  $do_limit_pe->(\$vg_more_free_pe, 'unstriped');
>  
> +overall_limit_pe(\$vg_more_free_pe);
>  if ($vg_more_free_pe) {
>  logm("$what: unstriped $vg_more_free_pe PEs");
> -overall_limit_pe(\$vg_more_free_pe);
>  $more_pe += $vg_more_free_pe;
>  target_cmd_root($ho, "lvextend -i1 -l +$vg_more_free_pe $lv");
>  }
> 
> (untested, but I've just tripped over this in a standalone run myself).

Yes.  With a suitable commit message:

Acked-by: Ian Jackson 

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

[Xen-devel] OutreachY round 11 - Please add new sensible projects

[Lars Kurth]

Hi everyone,

most of http://wiki.xenproject.org/wiki/Outreach_Program_Projects has been 
scrubbed and out-of-date projects removed. 

I also restructured http://wiki.xenproject.org/wiki/Outreachy/Round11 to make 
it easier to
a) Navigate the right mailing list, IRC channel
b) Make it easier to identify "SMALL CODE CONTRIBUTIONS" projects prior to 
application 

However, now we do have very few Hypervisor projects and NO XAPI projects. 

I think we are fine on Mirage OS projects and I added links to 
https://github.com/mirage/mirage-www/wiki/Pioneer-Projects (although I don't 
know how up-to-date these are).

Best Regards
Lars

> On 17 Sep 2015, at 14:00, Lars Kurth  wrote:
> 
> Hi all,
> 
> the AB is sponsoring 2 interns again for the winter round
> 
> This means we need to update the following pages by September 28
> * All: http://wiki.xenproject.org/wiki/Outreach_Program_Projects - aka add 
> new projects/remove old ones
> * MirageOS: http://wiki.xenproject.org/wiki/Outreach_Program_Projects has 
> projects in it - are these still valid, or are they replaced by 
> https://github.com/mirage/mirage-www/wiki/Pioneer-Projects ?
> 
> Everyone who has a project on that list is on the TO list. Please update the 
> "Verified" line and add the current date to each project with your name 
> against it. Feel free to add new projects.
> 
> {{project
> ...
> |Verified=02/13/2015
> ...
> }}
> 
> I will purge *all* projects which have not been verified.
> 
> = Timeline =
> September 28 organizations' landing pages need to be ready with project ideas
> September 29 application process opens
> November 2 application deadline
> November 17 accepted applicants announced
> December 7 - March 7 internship dates
> 
> = Xen Resources =
> http://wiki.xenproject.org/wiki/Outreachy/Round11
> 
> Regards
> Lars
> 


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

[Xen-devel] [PATCH for-4.6 2/2] libxl: fix the cleanup of the backend path when using driver domains

[Roger Pau Monne]

With the current libxl implementation the control domain will remove both
the frontend and the backend xenstore paths of a device that's handled by a
driver domain. This is incorrect, since the driver domain possibly needs to
access the backend path in order to perform the disconnection and cleanup of
the device.

Fix this by making sure the control domain only cleans the frontend path,
leaving the backend path to be cleaned by the driver domain. Note that if
the device is not handled by a driver domain the control domain will perform
the removal of both the frontend and the backend paths.

Signed-off-by: Roger Pau Monné 
Reported-by: Alex Velazquez 
Cc: Alex Velazquez 
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl_device.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 51da10e..6035c6e 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -595,8 +595,8 @@ int libxl__device_destroy(libxl__gc *gc, libxl__device *dev)
  * frontend and the backend path
  */
 libxl__xs_path_cleanup(gc, t, fe_path);
-libxl__xs_path_cleanup(gc, t, be_path);
-} else if (dev->backend_domid == domid) {
+}
+if (dev->backend_domid == domid) {
 /*
  * The driver domain is in charge for removing what it can
  * from the backend path
-- 
1.9.5 (Apple Git-50.3)


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

Re: [Xen-devel] [PATCH v6 2/2] xen/arm: support gzip compressed kernels

[Julien Grall]

Hi Stefano,

On 22/09/2015 02:35, Stefano Stabellini wrote:

You may want to use vmap here which is a wrapper to __vmap and will setup the
granularity, align, and flags automatically for you.


The arguments are different.


Yes, sorry I inverted nr with granularity.


I meant to say that it makes more sense to pass one region of higher 
granularity,
than to map pages one by one.


Well, the page will still be mapped one by one in map_pages_to_xen one 
by one because we don't support super-page mapping.


TBH if you care about performance, you would only map the strict 
necessary because the smallest granularity to fit all the kernel may be 
big compare to the real size.


For instance, if the decompress size is 65M, you would have to map 128M.

Anyway, it's only used during boot, so I don't much care if you use 
__vmap. My suggestion was only for simplifying the code.


Regards,

--
Julien Grall

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

[Xen-devel] Fwd: Fwd: LibXL

[kumara rathnavel]

>
>
> Hello All,
>
> I am not able to use the library functions provided by the LibXenlight
> though I am able to use it through XL. I am in need to develop my own CLI
> . I am able to perform few basic operations like listing the VM, reboot
> and all. But the calls that require a structure to be filled is not
> functioning . I am getting a segmentation fault.
>
> I have attached my code. I have also attached the system call traces file
> which was generated by the command truss for the command that was
> successful through XL and the other one that failed where I used the call
> directly.
>
> Thank you
>
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#define INVALID_DOMID 0
#define LIBXL__DEFBOOL_FALSE (-1)
#define LIBXL__DEFBOOL_TRUE (1)

int
main(
 int argc,
 char **argv
  )
{
   libxl_ctx *ctx;

   int rc = 0;

   libxl_device_nic nic;
   int domid = 0;
   char *bridge = NULL;

   bridge = "bridge0";


   libxl_device_nic_init();


   domid = 2; //Have a domain running with ID 2.

   rc = libxl_ctx_alloc(, LIBXL_VERSION, 0, NULL);
   if (rc < 0) {
  perror("ctx alloc failed.");
  return rc;
   }

   nic.devid = -1;
   nic.bridge = bridge;
   nic.nictype = LIBXL_NIC_TYPE_VIF;

   rc = libxl_device_nic_add(ctx, domid, , 0);
   if(rc != 0 ) {
  printf("Attach Failed\n");
   }

   libxl_ctx_free(ctx);
   return rc;
}

xlout
Description: Binary data


eout
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH RFC tools 1/6] tools: Refactor "xentoollog" into its own library

[Ian Campbell]

On Mon, 2015-09-21 at 18:30 +0100, Andrew Cooper wrote:
> On 21/09/15 18:13, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [Xen-devel] [PATCH RFC tools 1/6] tools:
> > Refactor "xentoollog" into its own library"):
> > > On 21/09/15 17:17, Ian Jackson wrote:
> > > > Do you mean that statement expressions (originally a GNU extension)
> > > > should be avoided in tools code ?  A quick git-grep discovered that
> > > > xenctrl already contains numerous statement expressions.
> > > It is fine (in principle) to be used internally.  Not in a public
> > > header
> > > for what is supposed to be a clean API.
> > I don't understand why this distinction is relevant.  Either the
> > compiler supports it, or it doesn't.
> 
> There shouldn't be items in a public header which can't be used by all
> compilers which might want to compile it.
> 
> GCC is not the only compiler liable to encounter this new header file.
> 
[...]
> Please explain why you believe it to be unsuitable?  It is not perfect,
> but is far better than nothing.

It's a #define, so unless the including application actually uses it the
compiler proper (as opposed to cpp) will never see it.

Ian.


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

Re: [Xen-devel] [PATCH v7 09/28] xen/arm: ITS: Introduce gic_is_lpi helper function

[Vijay Kilari]

On Mon, Sep 21, 2015 at 7:50 PM, Julien Grall  wrote:
> Hi Vijay,
>
> On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K 
>>
>> Helper function gic_is_lpi() is used to find
>> if irq is lpi or not. For GICv2 platforms this function
>> returns number of irq ids which represents only number of line irqs.
>> For GICv3 platform irq ids are calculated from nr_lpis if
>> HW supports LPIs
>>
[...]

>>  static void __init gicv3_dist_init(void)
>>  {
>>  uint32_t type;
>> @@ -578,6 +583,21 @@ static void __init gicv3_dist_init(void)
>>
>>  /* Only 1020 interrupts are supported */
>>  gicv3_info.nr_lines = min(1020U, nr_lines);
>> +
>> +/*
>> + * Number of IRQ ids supported.
>> + * Here we override HW supported number of LPIs and
>> + * limit to to LPIs specified in nr_lpis.
>> + */
>
> You still have to check that the number of LPIs requesting by the user
> is supported by the hardware.
>
> The user parameter can be seen as a restriction rather than a blind
> overriding.
>
>> +if ( gicv3_dist_supports_lpis() )
>
> I'm sure we already speak about it in a previous series. The GICv3 may
> support LPIs even without an ITS. Here you would claim that Xen is
> supporting LPIs which is clearly not true.
>
> When the ITS is not present, this value should be the number of
> interrupt line supported.
>
> I haven't checked if you fixed it later, but all the patch should be
> bisectable. I.e I shouldn't see any unwanted modification on supported
> platform with GICv3 (for instance the foundation model).
>
>> +gicv3_info.nr_irq_ids = nr_lpis + FIRST_GIC_LPI;
>> +else
>> +{
>> +gicv3_info.nr_irq_ids = gicv3_info.nr_lines;
>> +/* LPIs are not supported by HW. Reset to 0 */
>> +nr_lpis = 0;
>
> That's really ugly and you still let GICv2 hardware with nr_lpis != 0.
> As said on v6 I don't want to see any usage of nr_lpis in code except
> for letting the user restricting the number of LPIs supported.
>
> That means that all the code should use gic_nr_irq_ids to know the
> number of LPIs supported. Mixing the 2 usage will lead to big trouble
> latter.

Here nr_lpis is used to update nr_irq_ids which is used by gic_nr_irq_ids().
>
> So please move nr_lpis in gic-v3 as a parameter and don't export it.

nr_lpis is user defined/initialized in irq.c . How can we pass this to gic-v3 as
parameter?. You mean to have helper function to read/update nr_lpis?

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

Re: [Xen-devel] [PATCH v7 14/28] xen/arm: ITS: Initialize physical ITS and export lpi support

[Vijay Kilari]

On Mon, Sep 21, 2015 at 8:50 PM, Julien Grall  wrote:
> Hi Vijay,
>
> On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K 
>>
>> Initialize physical ITS if HW supports LPIs.
>>
>> Signed-off-by: Vijaya Kumar K 
>> ---
>> v7: - Export lpi support information to vgic-v3 driver from gic-v3.
>> - Drop gic_lpi_supported() helper function
>> - Add boot param to enable or disable physical ITS
>> v6: - Updated lpi_supported gic_info member for GICv2 and GICv3
>> - Introduced helper gic_lpi_supported() and exported
>> v5: - Made check of its dt node availability before
>>   setting lpi_supported flag
>> ---
>>  xen/arch/arm/gic-v3.c |   38 
>> ++---
>>  xen/arch/arm/vgic-v3.c|5 -
>>  xen/include/asm-arm/gic_v3_defs.h |4 +++-
>>  xen/include/asm-arm/vgic.h|2 +-
>>  4 files changed, 43 insertions(+), 6 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index c4c77a7..ac8a0ea 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -55,6 +55,18 @@ static struct {
>>  } gicv3;
>>
>>  static struct gic_info gicv3_info;
>> +/* Enable/Disable ITS support */
>> +static bool_t its_enable  = 1;
>> +/* Availability of ITS support after successful ITS initialization */
>> +static bool_t its_enabled = 0;
>> +
>> +static void __init parse_its_param(char *s)
>> +{
>> +if ( !parse_bool(s) )
>> +its_enable = 0;
>> +}
>> +
>> +custom_param("its", parse_its_param);
>
> Why do you need a command line option to enable/disable the physical ITS?

I have added this to remove ITS support?.
Did I misunderstood it. May be I have to avoid generating its dt node
to disable its for dom0?

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

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Andrew Cooper]

On 21/09/2015 21:03, Andreas Sundstrom wrote:
> This is using Debian Jessie and grub 2.02~beta2-22 (with Debian patches
> applied) and Xen 4.4.1
>
> I originally posted a bug report with Debian but got the suggestion to
> file bugs with upstream as well.
> Debian bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799480
>
> Note that my original thought was that this bug probably is within GRUB.
> But Ian asked me to file a bug with Xen as well, you have to live with the
> fact that it is centered around GRUB though.
>
> Here's the information from my original bug report:
>
> Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
> fail when chainloading the domU's grub. 64-bit domU seem to work 100%
> of the time.

You say sometimes.  Do you mean that repeated attempts to boot a 32bit
domU causes it to ether boot correctly, or die in the below manor?

>
> My understanding of the process:
>
>  * dom0 launches domU with grub that is loaded from dom0's disk.
>  * Grub reads config file from memdisk, and then looks for grub binary in
> domU filesystem.
>  * If grub is found in domU it then chainloads (multiboot) that grub binary
> and the domU grub reads grub.cfg and continue booting.
>  * If grub is not found in domU it reads grub.cfg and continues with boot.
>
> It fails at step 3 in my list of the boot process, but sometimes it
> does work so it may be something like a race condition that causes the
> problem?
>
> A workaround is to not install or rename /boot/xen in domU so that the
> first grub that is loaded from dom0's disk will not find the grub
> binary in the domU filesystem and hence continues to read grub.cfg and
> boot. The drawback of this is of course that the two versions can't
> differ too much as there are different setups creating grub.cfg and
> then reading/parsing it at boot time.
>
> I am not sure at this point whether this is a problem in XEN or a
> problem in grub but I compiled the legacy pvgrub that uses some minios
> from XEN (don't really know much more about it) and when that legacy
> pvgrub chainloads the domU grub it seems to work 100% of the time. Now
> the legace pvgrub is not a real alternative as it's not packaged for
> Debian though.
>
> When it fails "xl create vm -c" outputs this:
> Parsing config from /etc/xen/vm
> libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain
> type for domid=16
> Unable to attach console
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console
> child [0] exited with error status 1

These error messages are just because the domain crashes sufficiently
early that libxl can't find the console information.  Running `xl
create` without '-c' would remove the libxl errors.

>
> And "xl dmesg" shows errors like this:
> (XEN) traps.c:2514:d15 Domain attempted WRMSR c0010201 from
> 0x to 0x.
> (XEN) d16:v0: unhandled page fault (ec=0010)
> (XEN) Pagetable walk from :
> (XEN) L4[0x000] = 000200256027 049c
> (XEN) L3[0x000] = 000200255027 049d
> (XEN) L2[0x000] = 000200251023 04a1
> (XEN) L1[0x000] =  
> (XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0
> compat_create_bounce_frame+0xc6/0xde
> (XEN) Domain 16 (vcpu#0) crashed on cpu#0:
> (XEN) [ Xen-4.4.1 x86_64 debug=n Not tainted ]
> (XEN) CPU: 0
> (XEN) RIP: e019:[<>]
> (XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest
> (XEN) rax:  rbx:  rcx: 
> (XEN) rdx:  rsi: 00499000 rdi: 0080
> (XEN) rbp: 000a rsp: 005a5ff0 r8: 
> (XEN) r9:  r10: 83023e9b9000 r11: 83023e9b9000
> (XEN) r12: 033f3d335bfb r13: 82d080300800 r14: 82d0802ea940
> (XEN) r15: 83005e819000 cr0: 8005003b cr4: 000506f0
> (XEN) cr3: 000200b7a000 cr2: 
> (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019
> (XEN) Guest stack trace from esp=005a5ff0:
> (XEN) 0010  0001e019 00010046 0016b38b 0016b38a 0016b389
> 0016b388
> (XEN) 0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 0016b381
> 0016b380
> (XEN) 0016b37f 0016b37e 0016b37d 0016b37c 0016b37b 0016b37a 0016b379
> 0016b378
> (XEN) 0016b377 0016b376 0016b375 0016b374 0016b373 0016b372 0016b371
> 0016b370
> (XEN) 0016b36f 0016b36e 0016b36d 0016b36c 0016b36b 0016b36a 0016b369
> 0016b368
> (XEN) 0016b367 0016b366 0016b365 0016b364 0016b363 0016b362 0016b361
> 0016b360
> (XEN) 0016b35f 0016b35e 0016b35d 0016b35c 0016b35b 0016b35a 0016b359
> 0016b358
> (XEN) 0016b357 0016b356 0016b355 0016b354 0016b353 0016b352 0016b351
> 0016b350
> (XEN) 0016b34f 0016b34e 0016b34d 0016b34c 0016b34b 0016b34a 0016b349
> 0016b348
> (XEN) 0016b347 0016b346 0016b345 0016b344 0016b343 0016b342 0016b341
> 0016b340
> (XEN) 0016b33f 0016b33e 0016b33d 

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Ian Campbell]

On Tue, 2015-09-22 at 08:22 +0100, Andrew Cooper wrote:
> 
> The segment registers indicate that the domU is executing in ring1 which
> makes it a 32bit guest (also why 32bit words are used for the stack
> dump), but r10 through r14 have 64bit values in.

r10..r14 are not visible to 32-bit guests but it appears that this dumping
function in Xen doesn't check for that and omit printing them.

I suspect that if these were zeroed or poisoned upon domain creation you
would see those values unmodified here.

> It does appear to be an intermittent bug in 32bit grub-xen in the
> eventual domU, but I have no help to offer with respect to debugging
> grub-xen further.

Me neither. I did suggest to Andreas that he also took it to grub-devel.
I'll reply to the original with a full quote and copy that list.

Ian.


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

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Ian Campbell]

Hi Vladimir & grub-devel,

Do you have any thoughts on this issue with i386 pv-grub2?

Thanks, Ian.

On Mon, 2015-09-21 at 22:03 +0200, Andreas Sundstrom wrote:
> This is using Debian Jessie and grub 2.02~beta2-22 (with Debian patches
> applied) and Xen 4.4.1
> 
> I originally posted a bug report with Debian but got the suggestion to
> file bugs with upstream as well.
> Debian bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799480
> 
> Note that my original thought was that this bug probably is within GRUB.
> But Ian asked me to file a bug with Xen as well, you have to live with
> the
> fact that it is centered around GRUB though.
> 
> Here's the information from my original bug report:
> 
> Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
> fail when chainloading the domU's grub. 64-bit domU seem to work 100%
> of the time.
> 
> My understanding of the process:
> 
>  * dom0 launches domU with grub that is loaded from dom0's disk.
>  * Grub reads config file from memdisk, and then looks for grub binary in
> domU filesystem.
>  * If grub is found in domU it then chainloads (multiboot) that grub
> binary
> and the domU grub reads grub.cfg and continue booting.
>  * If grub is not found in domU it reads grub.cfg and continues with
> boot.
> 
> It fails at step 3 in my list of the boot process, but sometimes it
> does work so it may be something like a race condition that causes the
> problem?
> 
> A workaround is to not install or rename /boot/xen in domU so that the
> first grub that is loaded from dom0's disk will not find the grub
> binary in the domU filesystem and hence continues to read grub.cfg and
> boot. The drawback of this is of course that the two versions can't
> differ too much as there are different setups creating grub.cfg and
> then reading/parsing it at boot time.
> 
> I am not sure at this point whether this is a problem in XEN or a
> problem in grub but I compiled the legacy pvgrub that uses some minios
> from XEN (don't really know much more about it) and when that legacy
> pvgrub chainloads the domU grub it seems to work 100% of the time. Now
> the legace pvgrub is not a real alternative as it's not packaged for
> Debian though.
> 
> When it fails "xl create vm -c" outputs this:
> Parsing config from /etc/xen/vm
> libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain
> type for domid=16
> Unable to attach console
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console
> child [0] exited with error status 1
> 
> And "xl dmesg" shows errors like this:
> (XEN) traps.c:2514:d15 Domain attempted WRMSR c0010201 from
> 0x to 0x.
> (XEN) d16:v0: unhandled page fault (ec=0010)
> (XEN) Pagetable walk from :
> (XEN) L4[0x000] = 000200256027 049c
> (XEN) L3[0x000] = 000200255027 049d
> (XEN) L2[0x000] = 000200251023 04a1
> (XEN) L1[0x000] =  
> (XEN) domain_crash_sync called from entry.S: fault at 82d08021feb0
> compat_create_bounce_frame+0xc6/0xde
> (XEN) Domain 16 (vcpu#0) crashed on cpu#0:
> (XEN) [ Xen-4.4.1 x86_64 debug=n Not tainted ]
> (XEN) CPU: 0
> (XEN) RIP: e019:[<>]
> (XEN) RFLAGS: 0246 EM: 1 CONTEXT: pv guest
> (XEN) rax:  rbx:  rcx: 
> (XEN) rdx:  rsi: 00499000 rdi: 0080
> (XEN) rbp: 000a rsp: 005a5ff0 r8: 
> (XEN) r9:  r10: 83023e9b9000 r11: 83023e9b9000
> (XEN) r12: 033f3d335bfb r13: 82d080300800 r14: 82d0802ea940
> (XEN) r15: 83005e819000 cr0: 8005003b cr4: 000506f0
> (XEN) cr3: 000200b7a000 cr2: 
> (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019
> (XEN) Guest stack trace from esp=005a5ff0:
> (XEN) 0010  0001e019 00010046 0016b38b 0016b38a 0016b389
> 0016b388
> (XEN) 0016b387 0016b386 0016b385 0016b384 0016b383 0016b382 0016b381
> 0016b380
> (XEN) 0016b37f 0016b37e 0016b37d 0016b37c 0016b37b 0016b37a 0016b379
> 0016b378
> (XEN) 0016b377 0016b376 0016b375 0016b374 0016b373 0016b372 0016b371
> 0016b370
> (XEN) 0016b36f 0016b36e 0016b36d 0016b36c 0016b36b 0016b36a 0016b369
> 0016b368
> (XEN) 0016b367 0016b366 0016b365 0016b364 0016b363 0016b362 0016b361
> 0016b360
> (XEN) 0016b35f 0016b35e 0016b35d 0016b35c 0016b35b 0016b35a 0016b359
> 0016b358
> (XEN) 0016b357 0016b356 0016b355 0016b354 0016b353 0016b352 0016b351
> 0016b350
> (XEN) 0016b34f 0016b34e 0016b34d 0016b34c 0016b34b 0016b34a 0016b349
> 0016b348
> (XEN) 0016b347 0016b346 0016b345 0016b344 0016b343 0016b342 0016b341
> 0016b340
> (XEN) 0016b33f 0016b33e 0016b33d 0016b33c 0016b33b 0016b33a 0016b339
> 0016b338
> (XEN) 0016b337 0016b336 0016b335 0016b334 0016b333 0016b332 0016b331
> 0016b330
> (XEN) 0016b32f 0016b32e 0016b32d 0016b32c 0016b32b 0016b32a 0016b329
> 

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Jan Beulich]

>>> On 22.09.15 at 09:19,  wrote:
> However, I do find some issues with my proposal above, see below:
> 
> 1. Set _VPF_blocked
> 2. ret = arch_block()
> 3. if ( ret || local_events_need_delivery() )
>   clear_bit(_VPF_blocked, >pause_flags);
> 
> After step #2, if ret == false, that means, we successfully changed the PI
> descriptor in arch_block(), if local_events_need_delivery() returns true,
> _VPF_blocked is cleared. After that, external interrupt come in, hence
> pi_wakeup_interrupt() --> vcpu_unblock(), but _VPF_blocked is cleared,
> so vcpu_unblock() does nothing, so the vCPU's PI state is incorrect.
> 
> One possible solution for it is:
> - Disable the interrupts before the check in step #3 above
> - if local_events_need_delivery() returns true, undo all the operations
>  done in arch_block()
> - Enable interrupts after _VPF_blocked gets cleared.

Couldn't this be taken care of by, if necessary, adjusting PI state
in vmx_do_resume()?

Jan


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

Re: [Xen-devel] [xen-unstable test] 62156: regressions - FAIL

[Ian Campbell]

On Tue, 2015-09-22 at 00:23 +, osstest service owner wrote:
> flight 62156 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62156/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
> fail REGR. vs. 61627

http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html

shows that this is intermittently failing either guest-localmigrate or
guest-localmigrate.2 (and also that it appears host specific to merlot*)

I think we should force push.

> version targeted for testing:
>  xen  4600d7560425f89b32cd90ecf6084bae9293dfab
> baseline version:
>  xen  a7b39c8bd6cba3fe1c8012987b9e28bdbac7e92d
> 
> Last test of basis61627  2015-09-08 14:33:27 Z   13 days
> Failing since 61739  2015-09-10 06:45:52 Z   11 days5 attempts
> Testing same since62156  2015-09-19 05:43:02 Z2 days1 attempts

Ian.

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

Re: [Xen-devel] [PATCH v7 08/28] xen/arm: ITS: Add APIs to add and assign device

[Vijay Kilari]

On Mon, Sep 21, 2015 at 7:17 PM, Julien Grall  wrote:
> Hi Vijay,
>
> On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K 
>>
>> Add APIs to add devices to RB-tree, assign and remove
>> devices to domain.
>>
[...]
>> +
>> +static void its_free_device(struct its_device *dev)
>> +{
>> +xfree(dev->itt);
>> +its_lpi_free(dev);
>>  xfree(dev->event_map.lpi_map);
>
> Why did you move this call from its_lpi_free to here?

its_lpi_free() is called along with its_free_device. So moved into
this code instead of calling it separately. This helps to avoid
chances of missing it out.

>
>> +xfree(dev->event_map.col_map);
>
> This line should have been added in its_lpi_free in patch #5.
>
>> +xfree(dev);
>> +}
>> +
>> +static struct its_device *its_alloc_device(u32 devid, u32 nr_ites,
>> +   struct dt_device_node *dt_its)
>
> Can you explain why you weren't able to re-use its_create_device from Linux?
>
> AFAICT there is nothing different and you miss key code such as rounding
> to a power of 2 the number of event IDs.
>

  It is almost re-used with following changes
1) Rounding of nr_ites, which is missing. However nr_ites is passed
from platform
file.
2) Freeing of memory on failure. Here I re-used its_free_device() which does
the same

>> +{
>> +struct its_device *dev;
>> +unsigned long *lpi_map;
>> +int lpi_base, sz;
>> +u16 *col_map = NULL;
>> +
>> +dev = xzalloc(struct its_device);
>> +if ( dev == NULL )
>> +return NULL;
>> +
>> +dev->its = its_get_phys_node(dt_its);
>
> You can re-order the code to get the ITS before allocate the memory. And
> then you can drop one goto.
>
>> +if (dev->its == NULL)
>> +{
>> +printk(XENLOG_G_ERR
>
> As already asked on v6, why XENLOG_G_ERR? Any call to this function will
> be done via privileged guest.
>
>> +   "ITS: Failed to find ITS node for devid 0x%"PRIx32"\n", 
>> devid);
>> +goto err;
>> +}
>> +
>> +sz = nr_ites * dev->its->ite_size;
>> +sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
>> +dev->itt = xzalloc_bytes(sz);
>> +if ( !dev->itt )
>> +goto err;
>> +
>> +lpi_map = its_lpi_alloc_chunks(nr_ites, _base);
>> +if ( !lpi_map )
>> +goto lpi_err;
>> +
>> +col_map = xzalloc_bytes(sizeof(*col_map) * nr_ites);
>> +if ( !col_map )
>> +goto col_err;
>> +dev->event_map.lpi_map = lpi_map;
>> +dev->event_map.lpi_base = lpi_base;
>> +dev->event_map.col_map = col_map;
>> +dev->event_map.nr_lpis = nr_ites;
>> +dev->device_id = devid;
>> +
>> +return dev;
>> +
>> +col_err:
>> +its_free_device(dev);
>> +return NULL;
>> +lpi_err:
>> +xfree(dev->itt);
>> +err:
>> +xfree(dev);
>> +
>> +return NULL;
>> +}
>> +
>> +/* Device assignment */
>> +int its_add_device(u32 devid, u32 nr_ites, struct dt_device_node *dt_its)
>> +{
>> +struct its_device *dev;
>> +u32 i, plpi = 0;
>> +struct its_collection *col;
>> +struct irq_desc *desc;
>> +struct msi_desc *msi = NULL;
>> +int res = 0;
>> +
>> +spin_lock(_its_dev_lock);
>> +dev = its_find_device(devid);
>> +if ( dev )
>> +{
>> +printk(XENLOG_G_ERR "ITS: Device already exists 0x%"PRIx32"\n",
>
> Same question as before for XENLOG_G_ERR.

I should have used XENLOG_ERR?

>
>> +   dev->device_id);
>> +res = -EEXIST;
>> +goto err_unlock;
>> +}
>> +
>> +dev = its_alloc_device(devid, nr_ites, dt_its);
>> +if ( !dev )
>> +{
>> +res = -ENOMEM;
>> +goto err_unlock;
>> +}
>> +
>> +if ( its_insert_device(dev) )
>
> The only way that this call can fail is because the device already
> exists in the RB-tree. Although, this can never happen because you have
> the lock taken and check beforehand if someone has inserted a device
> with this devID.
>
> So I would turn this if into an BUG_ON(its_insert_device(dev)) and save
> 6 lines.

With below code it prints message, free's up memory and return error.
The caller can handle as required.

>
>> +{
>> +its_free_device(dev);
>> +printk(XENLOG_G_ERR "ITS: Failed to insert device 0x%"PRIx32"\n", 
>> devid);
>> +res = -EINVAL;
>> +goto err_unlock;
>> +}
>> +/* Assign device to dom0 by default */
>
[...]
>
>> +
>> +/*
>> + * TODO: For pass-through following has to be implemented
>> + * 1) Allow device to be assigned to other domains (Dom0 -> DomU).
>> + * 2) Allow device to be re-assigned to Dom0 (DomU -> Dom0).
>> + * Implement separate function to handle this or rework this function.
>> + * For now do not allow assigning devices other than Dom0.
>> + *
>> + * By default all devices are assigned to Dom0.
>
> See my question above about the "why?".

AIUI, by default all devices are assigned to Dom0.
By updating 

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

[Paolo Bonzini]

On 21/09/2015 19:43, Andy Lutomirski wrote:
> And maybe the KVM user return notifier.

No, not really.  If anything, the place in KVM where it makes a
difference is vmx_save_host_state, which is also only using
always-present MSRs.  But don't care about KVM.

First clean it up, then we can add back inline versions like __rdmsr or
rdmsr_fault or rdmsr_unsafe or whatever.

Paolo

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

Re: [Xen-devel] [PATCH 3/4 RFC] x86/p2m: use large pages for MMIO mappings

[Jan Beulich]

>>> On 17.09.15 at 18:37,  wrote:
> On 15/09/15 08:34, Jan Beulich wrote:
>> @@ -2044,22 +2078,45 @@ int map_mmio_regions(struct domain *d,
>>  {
>>  int ret = 0;
>>  unsigned long i;
>> +unsigned int iter, order;
>>  
>>  if ( !paging_mode_translate(d) )
>>  return 0;
>>  
>> -for ( i = 0; !ret && i < nr; i++ )
>> +for ( iter = i = 0; i < nr && iter < MAP_MMIO_MAX_ITER;
>> +  i += 1UL << order, ++iter )
>>  {
>> -ret = set_mmio_p2m_entry(d, start_gfn + i, _mfn(mfn + i),
>> - p2m_get_hostp2m(d)->default_access);
>> -if ( ret )
>> +for ( order = mmio_order(d, (start_gfn + i) | (mfn + i), nr - i); ;
>> +  order = ret - 1 )
> 
> It is hard to reason as to whether this loop will terminate.  All it
> would take is a bug in set_mmio_p2m_entry() which causes it to
> unilaterally return 1 and this loop would never terminate.
> 
> Is there any other condition which can be used as a safety check?

I'm adding ASSERT()s as a minimal measure.

Jan


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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Monday, September 21, 2015 10:25 PM
> To: Wu, Feng; George Dunlap; George Dunlap
> Cc: Jan Beulich; Tian, Kevin; Keir Fraser; Andrew Cooper;
> xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On Mon, 2015-09-21 at 12:22 +, Wu, Feng wrote:
> >
> > > -Original Message-
> > > From: George Dunlap [mailto:george.dun...@citrix.com]
> 
> > > You also need to check that local_events_need_delivery() will
> > > return
> > > "true" if you get an interrupt between that time and entering the
> > > hypervisor.  Will that happen automatically from
> > > hvm_local_events_need_delivery() -> hvm_vcpu_has_pending_irq() ->
> > > vlapic_has_pending_irq()?  Or will you need to add a hook in
> > > hvm_vcpu_has_pending_irq()?
> >
> > I think I don't need to add hook in hvm_vcpu_has_pending_irq(), what
> > I need
> > to do in vcpu_block() and do_poll() is as below:
> >
> > 1. set_bit(_VPF_blocked, >pause_flags);
> >
> > 2. ret = v->arch.arch_block(), in this hook, we can re-use the same
> > logic in
> > vmx_pre_ctx_switch_pi(), and check whether ON bit is set during
> > updating
> > posted-interrupt descriptor, can return 1 when ON is set
> >
> It think it would be ok for an hook to return a value (maybe, if doing
> that, let's pick variable names and use comments to explain what goes
> on as good as we can).
> 
> I think I also see why you seem to prefer doing it that way, rather
> than hacking local_events_need_delivery(), but can you please elaborate
> on that? (My feeling is that you want to avoid having to update the
> data structures in between _VPF_blocked and the check
> local_events_need_delivery(), and then having to roll such update back
> if local_events_need_delivery() ends up being false, is that the
> case?).

In the arch_block() hook, we actually need to
- Put vCPU to the blocking list
- Set the NV to wakeup vector
- Set NDST to the right pCPU
- Clear SN

During we are updating the posted-interrupt descriptor, the VT-d
hardware can issue notification event and hence ON is set. If that is the
case, it is straightforward to return directly, and it doesn't make sense
we continue to do the above operations since we don't need to actually.

> 
> Code would look better, IMO, if we manage to fold that somehow inside
> local_events_need_delivery(), but that:

As mentioned above, during updating the PI descriptor for blocking, we
need to check whether ON is set, and return if it is set. This logic cannot
be included in local_events_need_delivery(), since the update itself
has not much relationship with local_events_need_delivery().

However, I do find some issues with my proposal above, see below:

1. Set _VPF_blocked
2. ret = arch_block()
3. if ( ret || local_events_need_delivery() )
clear_bit(_VPF_blocked, >pause_flags);

After step #2, if ret == false, that means, we successfully changed the PI
descriptor in arch_block(), if local_events_need_delivery() returns true,
_VPF_blocked is cleared. After that, external interrupt come in, hence
pi_wakeup_interrupt() --> vcpu_unblock(), but _VPF_blocked is cleared,
so vcpu_unblock() does nothing, so the vCPU's PI state is incorrect.

One possible solution for it is:
- Disable the interrupts before the check in step #3 above
- if local_events_need_delivery() returns true, undo all the operations
 done in arch_block()
- Enable interrupts after _VPF_blocked gets cleared.

It is a little annoying.

Thanks,
Feng


>  1. is hard to tell without actually seeing how the code will end up
> being
>  2. might be my opinion only, so let's see what others think.
> 
> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH v6 2/2] xen/arm: support gzip compressed kernels

[Julien Grall]

On 21/09/2015 23:51, Stefano Stabellini wrote:

+/*
+ * Need to free pages after output_size here because they won't be
+ * freed by discard_initial_modules
+ */
+i = (output_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
+for ( ; i < (1 << kernel_order_out); i++ )
+free_domheap_page(pages + i);
+
+vunmap(output);
+


I forgot to mention that vunmap should be called before 
free_domheap_pages to avoid mapping on unallocated pages.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] IOMMU: complete/correct comment explaining "iommu=" sub-options

[Julien Grall]

Hi,

On 22/09/2015 08:15, Andrew Cooper wrote:

On 22/09/2015 08:04, Jan Beulich wrote:

Signed-off-by: Jan Beulich 


Reviewed-by: Andrew Cooper 

Some of these are overly Intel-specific, but while AMD has no
implementation, this isn't much of a problem.


Note that on ARM, we are only using off|no|false|disable.

We may want to use dom0-strict at some point.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Ed Swierk]

On Tue, Sep 22, 2015 at 5:35 AM, Ed Swierk  wrote:
> So if the contract is that Dom0 tells Xen about mmcfgs before the
> devices they cover, then Linux ought to call pci_mmcfg_reserved from
> (or immediately after) both pci_mmcfg_early_init() and
> pci_mmcfg_late_init().

Brainstorming possible approaches:

I don't see an obvious way to hook into those functions (or their
callers) without injecting Xen-specific code. Is there a precedent to
follow?

Alternatively, we could just call the equivalent of xen_mcfg_late()
from the existing xen_{add,remove}_device() notifiers. This would
generate a lot of useless pci_mmcfg_reserved hypercalls (number of
devices times number of mmcfg areas), but pci_mmcfg_arch_enable() in
Xen should happily ignore the redundant ones. The advantage of this
approach other than simplicity is that it makes the mmcfg -> device
setup ordering very explicit.

Any other ideas?

--Ed

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

Re: [Xen-devel] [PATCH v2] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

[Jan Beulich]

>>> On 22.09.15 at 15:02,  wrote:
> On 22/09/15 13:53, Jan Beulich wrote:
>> Rather than dirtying a page when establishing a (permanent) mapping,
>> dirty it when the page gets unmapped, or - if still mapped - on the
>> final iteration of a save operation (or in other cases where the guest
>> is paused or already shut down). (Transient mappings continue to get
>> dirtied upon getting mapped, to avoid the overhead of tracking.)
>>
>> Signed-off-by: Jan Beulich 
>> ---
>> v2: Refine predicate for calling hvm_mapped_guest_frames_mark_dirty()
>>  (now including all shut down domains as well as tool stack paused
>>  ones).
> 
> I am still convinced that it is wrong for Xen to second-guess what libxc 
> is actually doing.
> 
> libxc should explicitly ask for the permanent mappings (or not) via 
> another bit in a shadow op.  Anything else risks not getting the bits 
> set (so memory corruption), or having too many bits set in 
> non-interested cases (unwanted overhead).

Well, okay. Looking around what this would mean on the tools side,
this doesn't even seem to be too bad to implement: We could use the
(so far unused) mode field of the interface structure. While the two
uses of XEN_DOMCTL_SHADOW_OP_CLEAN seem straightforward to
adjust, it's not immediately clear to me which variant the single
XEN_DOMCTL_SHADOW_OP_PEEK would want. Could you advise?

Jan


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

Re: [Xen-devel] Is: Make XENVER_* use XSM, seperate the different ops in smaller security domains. Was:Re: [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

[Andrew Cooper]

On 22/09/15 14:22, Konrad Rzeszutek Wilk wrote:

On Fri, Sep 18, 2015 at 12:40:46PM +0100, Andrew Cooper wrote:

On 17/09/15 19:45, Konrad Rzeszutek Wilk wrote:

. snip..

The build id of the current running hypervisor should belong in the
xeninfo hypercall.  It is not specific to xsplice.

However in the previous reviews it was pointed out that it should only be 
accessible to dom0.

Or to any domains as long as the XSM allows (and is turned on) - so not the 
default dummy one.

That is a bit of 'if' extra complexity which I am not sure is worth it?

DomU can already read the build information such as changeset, compile
time, etc.  Build-id is no more special or revealing.

I would take this as an argument *against* giving DomU access to those
pieces of information in details and not as an argument for
*additionally* giving it access to build-id.

With build-id we have the chance to shape a not-yet-established API and
I would like to follow the Principle of least privilege wherever it
makes sense.

To reach a similar security level with the existing API, it might make
sense to limit DomU access to compile date, compile time, compiled by,
compiled domain, compiler version and command line details, xen extra
version, and xen changeset.  Basically anything that might help DomUs to
uniquely identify a Xen build.

The approach can not directly drop access to those fields, as that would
break an existing API, but it could restrict the detail level handed out
to DomU.

These are all valid arguments to be made, but please lets fix the issue
properly rather than hacking build-id on the side of an unrelated component.

 From my point of view, the correct course of action is this:

* Split the current XSM model to contain separate attributes for general
and privileged information.
** For current compatibility, all existing XENVER_* subops fall into general
* Apply an XSM check at the very start of the hypercall.

That would introduce a performance regression I fear. Linux pvops does this:

   
/*

  * Force a proper event-channel callback from Xen after clearing the
  * callback mask. We do this in a very simple manner, by making a call
  * down into Xen. The pending flag will be checked by Xen on return.
  */
void xen_force_evtchn_callback(void)
{
 (void)HYPERVISOR_xen_version(0, NULL);
}

quite often, which now will have to do the XSM check which is extra code.


I would say that the XENVER_compile_info (/sys/hypervisor/compilation),
XENVER_changeset (/sys/hypervisor/compilation) should go over
the XSM check.

While:XENVER_version, XENVER_extraversion,XENVER_capabilities,
XENVER_platform_parameters, XENVER_get_features,XENVER_pagesize

should have no XSM check.


The XSM check will fall into the noise, performance wise, compared to 
the context switch to make the hypercall in the first place.  It is just 
another switch statement.  Also, selectively applying XSM checks will 
incur even more overhead than doing a blanket XSM check.


Also, I really don't care if you can measure a performance hit (not that 
I reckon you could).  How Linux chooses to behave itself has absolutely 
no bearing on how we go about securing the hypercall.


~Andrew

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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Konrad Rzeszutek Wilk]

On Tue, Sep 22, 2015 at 06:26:11AM -0700, Ed Swierk wrote:
> On Tue, Sep 22, 2015 at 5:35 AM, Ed Swierk  wrote:
> > So if the contract is that Dom0 tells Xen about mmcfgs before the
> > devices they cover, then Linux ought to call pci_mmcfg_reserved from
> > (or immediately after) both pci_mmcfg_early_init() and
> > pci_mmcfg_late_init().
> 
> Brainstorming possible approaches:
> 
> I don't see an obvious way to hook into those functions (or their
> callers) without injecting Xen-specific code. Is there a precedent to
> follow?

No.
> 
> Alternatively, we could just call the equivalent of xen_mcfg_late()
> from the existing xen_{add,remove}_device() notifiers. This would
> generate a lot of useless pci_mmcfg_reserved hypercalls (number of
> devices times number of mmcfg areas), but pci_mmcfg_arch_enable() in
> Xen should happily ignore the redundant ones. The advantage of this
> approach other than simplicity is that it makes the mmcfg -> device
> setup ordering very explicit.

While that will update the Xen's view of MMCFG it won't update the
existing configuration that Xen has slurped up during bootup.

As in, you will still get warnings.
> 
> Any other ideas?

I like it - as it will update it right away. However we would need some
extra smarts in Xen to reconfigure its view of the PCI device now that the
extended configuration space has become available.

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

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

Re: [Xen-devel] [PATCH v7 16/28] xen/arm: ITS: Add virtual ITS commands support

[Julien Grall]

Hi Vijay,

On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Add Virtual ITS command processing support to Virtual ITS driver
> 
> Signed-off-by: Vijaya Kumar K 

I've got minor comments in vits_get_max_collections. With that addressed:

Reviewed-by: Julien Grall 


[...]

> +static inline uint16_t vits_get_max_collections(struct domain *d)
> +{
> +/*
> + * ITS only supports up to 256 collections without
> + * provisioning external memory. As per vITS design, number of
> + * vCPUS should not exceed max number of collections.
> + */
> +ASSERT(d->max_vcpus < 256);
> +
> +/* Each collection corresponds to one CPU(vCPU). collections are

NIT: The coding style for comment is

/*
 * My comments
 * ...
 */

s/collections are/Collections/

> + * used to move interrupts from one CPU to another. The ITS
> + * mandated to implement N + 1 collections where N is the number of

s/mandated/mandates/

> + * processor on the platform (i.e max number of VCPUs for a given
> + * guest).

I was about to suggestion mention the section in the spec. Although I'm
not able to find a related section in the Public doc (IHI0069A).

Might still be worth to mention the PRD03-GENC-010745 24 section 4.9.15?

> + */
> +return (d->max_vcpus + 1);
> +}

Regards,


-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v7 02/17] Add cmpxchg16b support for x86-64

[Jan Beulich]

>>> On 11.09.15 at 10:28,  wrote:

> --- a/xen/include/asm-x86/x86_64/system.h
> +++ b/xen/include/asm-x86/x86_64/system.h
> @@ -6,6 +6,37 @@
> (unsigned long)(n),sizeof(*(ptr
>  
>  /*
> + * Atomic 16 bytes compare and exchange.  Compare OLD with MEM, if
> + * identical, store NEW in MEM.  Return the initial value in MEM.
> + * Success is indicated by comparing RETURN with OLD.
> + *
> + * This function can only be called when cpu_has_cx16 is true.
> + */
> +
> +static always_inline __uint128_t __cmpxchg16b(
> +volatile void *ptr, const __uint128_t *old, const __uint128_t *new)
> +{
> +__uint128_t prev;
> +uint64_t new_high = *new >> 64;
> +uint64_t new_low = (uint64_t)*new;

Pointless cast.

> +ASSERT(cpu_has_cx16);
> +
> +asm volatile ( "lock; cmpxchg16b %3"
> +   : "=A" (prev)
> +   : "c" (new_high), "b" (new_low), "m" (*__xg(ptr)), "0" 
> (*old)
> + );

The closing parenthesis belongs on the previous line.

> +return prev;
> +}
> +
> +#define cmpxchg16b(ptr,o,n)\
> +( ({ ASSERT(((unsigned long)ptr & 0xF) == 0); }),  \
> +  (BUILD_BUG_ON(sizeof(*o) != sizeof(__uint128_t))),   \
> +  (BUILD_BUG_ON(sizeof(*n) != sizeof(__uint128_t))),   \
> +  (__cmpxchg16b((ptr), (void *)(o), (void *)(n))) )

Sigh - this is _still_ not properly parenthesized, and evaluates ptr
twice:

#define cmpxchg16b(ptr, o, n) ({   \
volatile void *_p = (ptr); \
ASSERT(!((unsigned long)_p & 0xf));\
BUILD_BUG_ON(sizeof(*(o)) != sizeof(__uint128_t)); \
BUILD_BUG_ON(sizeof(*(n)) != sizeof(__uint128_t)); \
__cmpxchg16b(_p, (void *)(o), (void *)(n));\
})

Jan


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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Tuesday, September 22, 2015 9:40 PM
> To: Wu, Feng; George Dunlap
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On Tue, 2015-09-22 at 13:25 +, Wu, Feng wrote:
> >
> 
> > > -Original Message-
> > > From: George Dunlap [mailto:george.dun...@citrix.com]
> 
> > Specifically, consider the following scheduling case happened on
> > pCPUA:
> > vCPUA --> idle --> vCPUB
> >
> > 1. First, vCPUA is running on pCPUA, so the NDST filed in PI
> > descriptor is pCPUA
> > 2. Then vCPUA is switched out and idle is switched in running in
> > pCPUA
> > 3. Sometime later, vCPUB is switched in on pCPUA. However, the NDST
> > field
> > for vCPUA is still pCPUA, and currently, vCPUB is running on it. That
> > means
> > the spurious PI interrupts for vCPUA can disturb vCPUB (because the
> > NDST
> > field is pCPUA), it seems not so good to me.
> >
> Mmm... Ok, but you're not saying what caused the transition from vCPUA
> to idle, and from idle to vCPUB. That matters because, if this all
> happened because blockings and wakeups, it's nothing to do with lazy
> context switch, which is what we are discussing here (in the sense that
> PI data structures would, in those cases, be updated appropriately in
> block and wake hooks).

Like George mentioned before, Let's assume it is because of tasklets or
vCPU is going to offline to wait device model's IO operations, so idle
is switched in.

> 
> Also, if we're going from vCPUA to vCPUB, even if there's idle in
> between, that can't be done via lazy context switch.

Yes, in the above scenario, vCPUB to idle transition has nothing to
do with lazy context switch, however, the point here is vCPUA to
idle is related to lazy context switch, and if we don't set the SN
for vCPUA here, it will remain clear and the NDST field of vCPUA
will remain pCPUA, even some time later vCPUB is running on it.
In that case, the spurious Pi interrupts for vCPUA can disturb vCPUB.

> In fact, in this
> case, __context_switch() must be called at some point (during the idle-
> ->vCPUB switch, if my understanding is correct), and the hook will
> actually get called!

Yes, the idle to vCPUB switch is covered by __context_switch(), but
it cannot change the PI state of vCPUA at that point. Like mentioned
above, in this case, spurious PI interrupts happens.

Thanks,
Feng

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

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

Re: [Xen-devel] Is: Make XENVER_* use XSM, seperate the different ops in smaller security domains. Was:Re: [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

[Konrad Rzeszutek Wilk]

On Fri, Sep 18, 2015 at 12:40:46PM +0100, Andrew Cooper wrote:
> On 17/09/15 19:45, Konrad Rzeszutek Wilk wrote:
> > . snip..
> >> The build id of the current running hypervisor should belong in the
> >> xeninfo hypercall.  It is not specific to xsplice.
> > However in the previous reviews it was pointed out that it should only 
> > be accessible to dom0.
> >
> > Or to any domains as long as the XSM allows (and is turned on) - so not 
> > the default dummy one.
> >
> > That is a bit of 'if' extra complexity which I am not sure is worth it?
>  DomU can already read the build information such as changeset, compile
>  time, etc.  Build-id is no more special or revealing.
> >>> I would take this as an argument *against* giving DomU access to those
> >>> pieces of information in details and not as an argument for
> >>> *additionally* giving it access to build-id.
> >>>
> >>> With build-id we have the chance to shape a not-yet-established API and
> >>> I would like to follow the Principle of least privilege wherever it
> >>> makes sense.
> >>>
> >>> To reach a similar security level with the existing API, it might make
> >>> sense to limit DomU access to compile date, compile time, compiled by,
> >>> compiled domain, compiler version and command line details, xen extra
> >>> version, and xen changeset.  Basically anything that might help DomUs to
> >>> uniquely identify a Xen build.
> >>>
> >>> The approach can not directly drop access to those fields, as that would
> >>> break an existing API, but it could restrict the detail level handed out
> >>> to DomU.
> >> These are all valid arguments to be made, but please lets fix the issue
> >> properly rather than hacking build-id on the side of an unrelated 
> >> component.
> >>
> >> From my point of view, the correct course of action is this:
> >>
> >> * Split the current XSM model to contain separate attributes for general
> >> and privileged information.
> >> ** For current compatibility, all existing XENVER_* subops fall into 
> >> general
> >> * Apply an XSM check at the very start of the hypercall.

That would introduce a performance regression I fear. Linux pvops does this:

  
/*  
 * Force a proper event-channel callback from Xen after clearing the
 * callback mask. We do this in a very simple manner, by making a call  
 * down into Xen. The pending flag will be checked by Xen on return.
 */ 
void xen_force_evtchn_callback(void)
{   
(void)HYPERVISOR_xen_version(0, NULL);  
}  

quite often, which now will have to do the XSM check which is extra code.


I would say that the XENVER_compile_info (/sys/hypervisor/compilation),
XENVER_changeset (/sys/hypervisor/compilation) should go over
the XSM check.

While:XENVER_version, XENVER_extraversion,XENVER_capabilities,
XENVER_platform_parameters, XENVER_get_features,XENVER_pagesize

should have no XSM check.

> >> * Extend do_xen_version() to take 3 parameters.  (It is curious that it
> >> didn't take a length parameter before)
> >> ** This is still ABI compatible, as existing subops simply ignore the
> >> parameter.
> > Or we can just use 1024 bytes space the XENVER_* use.
> 
> What 1024 bytes?
> 
> Each subop currently assumes the guest handle is a pointer to an
> appropriately typed structure, which puts arbitrary and unnecessary
> length restrictions on items.
> 
> ~Andrew
> 
> >
> >> * Introduce new XENVER_build_id subop which is documented to require the
> >> 3-parameter version of the hypercall.
> >> ** This subop falls into straight into privileged information.
> >>
> >> This will introduce build-id in its correct location, with appropriate
> >> restrictions.
> >>
> >> Moving forwards, we really should have an audit of the existing XENVER_*
> >> subops.  Some are clearly safe/required for domU to read, but some such
> >> as XENVER_commandline have no business being accessible.  A separate
> >> argument, from the repeatable build point of view, says that compilation
> >> information isn't useful at all.
> >>
> >> Depending on how we wish to fix the issue, we could either do a blanket
> >> move of the subops into the privileged XSM catagory, or introduce a 3rd
> >> "legacy privileged" category to allow the admin to control access on a
> >> per-vm basis.
> > CC-ing Daniel. Changing title.
> >> ~Andrew
> 

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

Re: [Xen-devel] [PATCH] console: allow log level threshold adjustments from serial console

[Jan Beulich]

>>> On 22.09.15 at 15:17,  wrote:
> On 22/09/15 13:45, Jan Beulich wrote:
>> +static void do_adj_thresh(unsigned char key)
>> +{
>> +if ( *upper_thresh_adj < *lower_thresh_adj )
>> +*upper_thresh_adj = *lower_thresh_adj;
>> +printk("'%c' pressed -> %s log level: %s (rate limited %s)\n",
>> +   key, thresh_adj, loglvl_str(*lower_thresh_adj),
>> +   loglvl_str(*upper_thresh_adj));
> 
> It might be useful for this printk() to indicate whether it was the 
> standard or the guest log level which was adjusted.

It does, by printing the string thresh_adj currently points to.

>> +static struct keyhandler inc_thresh_keyhandler = {
>> +.irq_callback = 1,
>> +.u.irq_fn = do_inc_thresh,
>> +.desc = "increase log level threshold"
>> +};
>> +static struct keyhandler dec_thresh_keyhandler = {
>> +.irq_callback = 1,
>> +.u.irq_fn = do_dec_thresh,
>> +.desc = "decrease log level threshold"
>> +};
>> +static struct keyhandler toggle_guest_keyhandler = {
>> +.irq_callback = 1,
>> +.u.irq_fn = do_toggle_guest,
>> +.desc = "toggle host/guest log level adjustment"
>> +};
>> +
> 
> I am guessing from the looks of these that I should augment my 
> keyhandler cleanup to also be able to register irq handlers from outside 
> of common/keyhandler.c

Yeah, I was actually surprised you got away without (i.e. that all of
them lived in this one file so far).

Jan


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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Tuesday, September 22, 2015 6:46 PM
> To: Wu, Feng; Dario Faggioli
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> On 09/22/2015 11:43 AM, George Dunlap wrote:
> > On 09/22/2015 06:10 AM, Wu, Feng wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> >>> Sent: Monday, September 21, 2015 10:12 PM
> >>> To: Wu, Feng; George Dunlap
> >>> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap;
> Andrew
> >>> Cooper; Jan Beulich
> >>> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core
> logic
> >>> handling
> >>>
> >>> On Mon, 2015-09-21 at 13:50 +, Wu, Feng wrote:
> 
> > -Original Message-
> > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> >>>
> > Note that, in case of preemptions, we are switching from a non-idle
> > vcpu to another, non-idle, vcpu, so lazy context switching to the
> > idle
> > vcpu should not have much to do with this case...
> 
>  So do you mean in preemptions, we cannot switch from non-idle to idle
>  or
>  Idle to non-idle, i.e, we can only switch from non-idle to non-idle?
> 
> >>> That's what I meant. It's the definition of 'preemption' and of 'idle
> >>> task/vcpu', AFICT. I mean, the idle vcpu has the lowest possible
> >>> priority ever, so it can't really preempt anyone.
> >>>
> >>> OTOH, if the idle vcpu is running, that means there weren't any active
> >>> vcpus because, e.g., all were blocked; therefore, any active vcpu
> >>> wanting to run would have to wake up (and hence go throught the proper
> >>> wake up logic) before trying to preempt idle.
> >>>
> >>> There is one possible caveat: tasklets. In fact (as you can check
> >>> yourself by looking, in the code, for tasklet_work_scheduled), it is
> >>> possible that we force the idle vcpu to execute, even when we have
> >>> active and runnable vcpus, to let it process tasklets. I'm not really
> >>> sure whether this could be a problem for you or not, can you have a
> >>> look (and/or, a try) and report back?
> >>
> >> Thanks for your information about the tasklets part, it is very important,
> >> consider the following scenario:
> >>
> >> non-idle vCPUA --> idle (tasklet) --> non-idle vCPUA
> >>
> >> The above context switch will use the lazy context switch and cannot be
> >> covered in __context_switch(), we need to change SN's state during the
> >> "non-idle to idle" and "idle to non-idle" transition, so that means we need
> >> add the PI related logic in context_switch() instead of only in
> __context_switch().
> >>
> >> Besides that, it is more robust to do the PI switch in context_switch() 
> >> which
> >> can cover lazy context switch. Maybe in future, there are some other
> >> feature needing execute task _inside_ an idle context, and it may introduce
> >> some issues due to no PI state transition, and it is a little hard to 
> >> debug.
> >
> > So a transition like the above could happen in the case of a cpu that's
> > gone offline (e.g., to allow the devicemodel to handle an IO); or, as
> > you say, if we're doing urgent work in a tasklet such that it preempts a
> > running task.
> >
> > One option would be to just ignore this -- in which case we would get
> > spurious PI interrupts, but no other major issues, right?

Specifically, consider the following scheduling case happened on pCPUA:
vCPUA --> idle --> vCPUB

1. First, vCPUA is running on pCPUA, so the NDST filed in PI descriptor is pCPUA
2. Then vCPUA is switched out and idle is switched in running in pCPUA
3. Sometime later, vCPUB is switched in on pCPUA. However, the NDST field
for vCPUA is still pCPUA, and currently, vCPUB is running on it. That means
the spurious PI interrupts for vCPUA can disturb vCPUB (because the NDST
field is pCPUA), it seems not so good to me.

> >
> > But if we want to avoid spurious PI interrupts when running idle, then
> > yes, we need *some* kind of a hook on the lazy context switch path.
> >
> > /me does some more thinking...
> 
> To be honest, since we'll be get spurious PI interrupts in the
> hypervisor all the time anyway, I'm inclined at the moment not to worry
> to much about this case.

Why do you say "we'll be get spurious PI interrupts in the  hypervisor all the 
time"?

And could you please share what is your concern to handle this case to avoid
such spurious PI interrupts? Thanks!

Thanks,
Feng

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

Re: [Xen-devel] [PATCH v7 09/28] xen/arm: ITS: Introduce gic_is_lpi helper function

[Julien Grall]

On 22/09/15 10:10, Vijay Kilari wrote:
> On Mon, Sep 21, 2015 at 7:50 PM, Julien Grall  wrote:
>> That's really ugly and you still let GICv2 hardware with nr_lpis != 0.
>> As said on v6 I don't want to see any usage of nr_lpis in code except
>> for letting the user restricting the number of LPIs supported.
>>
>> That means that all the code should use gic_nr_irq_ids to know the
>> number of LPIs supported. Mixing the 2 usage will lead to big trouble
>> latter.
> 
> Here nr_lpis is used to update nr_irq_ids which is used by gic_nr_irq_ids().

That not the only usage of nr_lpis within this series. You are using it
to create the IRQ desc for LPIs.

We should have only one way to get the number of LPIs (i.e
gic_nr_irq_ids()). Any attempt to have 2 different to retrieve the
number of LPIs will be a problem later.

>>
>> So please move nr_lpis in gic-v3 as a parameter and don't export it.
> 
> nr_lpis is user defined/initialized in irq.c . How can we pass this to gic-v3 
> as
> parameter?. You mean to have helper function to read/update nr_lpis?

I meant moving the parameter in gic-v3 (i.e moving integer_param(...)).

We can speak about moving the parameter in another place when we will
have the need to.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [BUG] XEN domU crash when PV grub chainloads 32-bit domU grub

[Andreas Sundstrom]

Citerar Andrew Cooper :


On 21/09/2015 21:03, Andreas Sundstrom wrote:

Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
fail when chainloading the domU's grub. 64-bit domU seem to work 100%
of the time.


You say sometimes.  Do you mean that repeated attempts to boot a 32bit
domU causes it to ether boot correctly, or die in the below manor?


Yes that is correct, it may or may not be able to complete the booting.


When it fails "xl create vm -c" outputs this:
Parsing config from /etc/xen/vm
libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain
type for domid=16
Unable to attach console
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console
child [0] exited with error status 1


These error messages are just because the domain crashes sufficiently
early that libxl can't find the console information.  Running `xl
create` without '-c' would remove the libxl errors.


Correct, they only appear due to the failed connecting of the console
so not really relevant to the actual issue.


I am unable to understand how to debug grub further on my own, I have
printed out text from grub so that I understood that it is the
chainload that fails. I see no output from the domU grub (except when
it works as it should of course). I can help with further testing if
needed.


It does appear to be an intermittent bug in 32bit grub-xen in the
eventual domU, but I have no help to offer with respect to debugging
grub-xen further.

~Andrew


As Ian Campbell suggested I have also filed a bug with upstream grub:
http://savannah.gnu.org/bugs/?46014

/Andreas



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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Jan Beulich]

>>> On 22.09.15 at 15:26,  wrote:
> On Tue, Sep 22, 2015 at 5:35 AM, Ed Swierk  wrote:
>> So if the contract is that Dom0 tells Xen about mmcfgs before the
>> devices they cover, then Linux ought to call pci_mmcfg_reserved from
>> (or immediately after) both pci_mmcfg_early_init() and
>> pci_mmcfg_late_init().
> 
> Brainstorming possible approaches:
> 
> I don't see an obvious way to hook into those functions (or their
> callers) without injecting Xen-specific code. Is there a precedent to
> follow?
> 
> Alternatively, we could just call the equivalent of xen_mcfg_late()
> from the existing xen_{add,remove}_device() notifiers. This would
> generate a lot of useless pci_mmcfg_reserved hypercalls (number of
> devices times number of mmcfg areas), but pci_mmcfg_arch_enable() in
> Xen should happily ignore the redundant ones. The advantage of this
> approach other than simplicity is that it makes the mmcfg -> device
> setup ordering very explicit.

Well, I can see this as a reasonable approach to avoid adding Xen-
specific code to generic x86 code, but I don't like such redundancy.
Note however that the redundancy could be brought down: For one
you'd only need to report the MMCFG area covering the device in
question. And then the kernel could track which ones it reported
already.

Jan


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

Re: [Xen-devel] Fwd: Fwd: LibXL

[kumara rathnavel]

Hello Ian,

As requested I have attached the gdb output of the code.

On 22 September 2015 at 15:21, Ian Campbell  wrote:

> On Tue, 2015-09-22 at 14:50 +0530, kumara rathnavel wrote:
>
> > > I have attached my code. I have also attached the system call traces
> file
> > > which was generated by the command truss for the command that was
> > > successful through XL and the other one that failed where I used the
> call
> > > directly.
>
> I'm afraid that truss is of very little use for debugging these sorts of
> issues.
>
> What you need is to run the program under a debugger (such as gdb) and to
> get a stack trace from the point of the segfault.
>
> Ian.
>
>
>
[root@snw-xen ~/test]# gdb exec exec.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `exec'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libxenlight.so.4.5...Error while reading 
shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxenlight.so.4.5]
Reading symbols from /usr/local/lib/libxlutil.so.4.3...Error while reading 
shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxlutil.so.4.3]
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/libxenctrl.so.4.5...Error while reading 
shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxenctrl.so.4.5]
Reading symbols from /usr/local/lib/libxenguest.so.4.5...Error while reading 
shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxenguest.so.4.5]
Reading symbols from /usr/local/lib/libxenstore.so.3.0...Error while reading 
shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxenstore.so.3.0]
Reading symbols from /lib/libutil.so.9...done.
Loaded symbols for /lib/libutil.so.9
Reading symbols from /usr/local/lib/libyajl.so.2...done.
Loaded symbols for /usr/local/lib/libyajl.so.2
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /usr/lib/libbz2.so.4...done.
Loaded symbols for /usr/lib/libbz2.so.4
Reading symbols from /usr/lib/liblzma.so.5...done.
Loaded symbols for /usr/lib/liblzma.so.5
Reading symbols from /usr/local/lib/liblzo2.so.2...done.
Loaded symbols for /usr/local/lib/liblzo2.so.2
Reading symbols from /lib/libz.so.6...done.
Loaded symbols for /lib/libz.so.6
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000801060679 in ?? () from /usr/local/lib/libxenctrl.so.4.5
[New Thread 802c06400 (LWP 100075/)]
(gdb) bt
#0  0x000801060679 in ?? () from /usr/local/lib/libxenctrl.so.4.5
#1  0x0008008816cf in ?? () from /usr/local/lib/libxenlight.so.4.5
#2  0x0001 in ?? ()
#3  0x0008008816cf in ?? () from /usr/local/lib/libxenlight.so.4.5
#4  0x00080087e03e in ?? () from /usr/local/lib/libxenlight.so.4.5
#5  0x000800880c90 in ?? () from /usr/local/lib/libxenlight.so.4.5
#6  0x in ?? ()
(gdb) run
Starting program: /root/test/exec
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxenlight.so.4.5]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxlutil.so.4.3]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxenctrl.so.4.5]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxenguest.so.4.5]
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/local/lib/libxenstore.so.3.0]

Program received signal SIGSEGV, Segmentation fault.
0x000801060679 in ?? () from /usr/local/lib/libxenctrl.so.4.5
(gdb)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Add missing license and copyright statements to public interface headers.

[Mike Belopuhov]

On Fri, Sep 18, 2015 at 10:13 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 18, 2015 at 08:00:28AM -0400, Boris Ostrovsky wrote:
> > 
> > 
> > On 09/18/2015 04:44 AM, Ian Campbell wrote:
> > >On Thu, 2015-09-17 at 13:53 +0200, Mike Belopuhov wrote:
> > >
> > >A few words here about the methodology you used to determine the names to
> > >use would be useful to people looking back on this stuff in the future.
> > >
> > >Also it would be sensible to CC everyone whose name you are adding. I've
> > >added Keir since you already Ccd Boris and I didn't see any other names
> > >after a quick glance.
> > 
> > For changes that include my name (pmu files)
> > Reviewed-by: Boris Ostrovsky 
> 
> Nack. Sorry Boris.
> 
> Let me send an email to legal to make sure I am not spouting
> nonsense. But in the meantime my understanding is that:
> 
>  Copyright (c) 2015 X,Y
> 
> means that the copyright (ownership of intellectual property)
> is owned by both X and Y.
> 
> However we (Boris, and me) both signed this fancy document saying
> that any work we do is owned by Oracle. It is OK to state
> the authorship, but the ownership is Oracle's.
> 
> If it was
> 
>  Copyright (c) 2015 X
> 
>  Author: Y
> 
> Then that is OK.

Hi Konrad,

Any luck getting this sorted out?

Regards,
Mike

> > 
> > Not sure about format --- files in public directory largely use the same
> > format as what Mike is suggesting here but most of newer files do what
> > Konrad said (i.e. "Author" on a separate line).
> > 
> > We will also want to apply similar patch to Linux tree (once this is done).
> > Mike, do you mind doing it too?
> > 
> > -boris
> > 

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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Konrad Rzeszutek Wilk]

On Mon, Sep 21, 2015 at 11:23:03PM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk  09/21/15 8:06 PM >>>
> >- Never figured out how much data we should save in the Xen's
> >struct pci_device to see if we are 'stale'. Looking back I think
> >we just need to do the interogation of the PCI capabilities and see
> >if they have somehow changed (the ones we care about).
> 
> Didn't we settle on no data to be needed here at all, instead requiring Dom0
> to report devices removed on buses about to be re-numbered, adding them
> back after the re-numbering?

Perhaps?

The Linux code constructs the structs for bus and pci devices (and dispatches
the hypercalls) as it walks the ACPI PCI bus. And if the reassign parameter was 
used
it then during this walk (buses first) alters the PCI_PRIMARY_BUS. Once it has
done that it restarts the walk and scans for the PCI devices.

What that means is that all the internal Linux PCI devices structure
devices are not available before this ACPI bus scan is done (while
the Xen PCI deviecs structures are available).

The best I could come up with is to do two loops:
 1) for 0:0:0 -> ff:ff:ff call PHYSDEVOP_pci_device_remove
(so blow away what Xen has for its PCI devices.. except for the AMD IOMMU)
 2) list_for_each_pci_device PHYSDEVOP_pci_device_add (or other variants
if VF).

But that is just a hack working around the Linux code.

My thinking was that why don't we just make PHYSDEVOP_pci_device_add be
capable of dealing with changes like these.

However, you  have also added the code to trap on PCI configuation access
we could also do some smarts when PCI_PRIMARY_BUS is modified (see
a88b72fddd046a0978242411276861039ec99ad0 x86/PCI: add config space abstract
write intercept logic). That would take care of it much easier I think?

> 
> Jan
> 

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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Dario Faggioli]

On Tue, 2015-09-22 at 13:25 +, Wu, Feng wrote:
> 

> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@citrix.com]

> Specifically, consider the following scheduling case happened on
> pCPUA:
> vCPUA --> idle --> vCPUB
> 
> 1. First, vCPUA is running on pCPUA, so the NDST filed in PI
> descriptor is pCPUA
> 2. Then vCPUA is switched out and idle is switched in running in
> pCPUA
> 3. Sometime later, vCPUB is switched in on pCPUA. However, the NDST
> field
> for vCPUA is still pCPUA, and currently, vCPUB is running on it. That
> means
> the spurious PI interrupts for vCPUA can disturb vCPUB (because the
> NDST
> field is pCPUA), it seems not so good to me.
> 
Mmm... Ok, but you're not saying what caused the transition from vCPUA
to idle, and from idle to vCPUB. That matters because, if this all
happened because blockings and wakeups, it's nothing to do with lazy
context switch, which is what we are discussing here (in the sense that
PI data structures would, in those cases, be updated appropriately in
block and wake hooks).

Also, if we're going from vCPUA to vCPUB, even if there's idle in
between, that can't be done via lazy context switch. In fact, in this
case, __context_switch() must be called at some point (during the idle-
->vCPUB switch, if my understanding is correct), and the hook will
actually get called!

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



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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 22, 2015 5:00 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Dario Faggioli; George Dunlap; George Dunlap; Tian, Kevin;
> xen-devel@lists.xen.org; Keir Fraser
> Subject: RE: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
> logic
> handling
> 
> >>> On 22.09.15 at 09:19,  wrote:
> > However, I do find some issues with my proposal above, see below:
> >
> > 1. Set _VPF_blocked
> > 2. ret = arch_block()
> > 3. if ( ret || local_events_need_delivery() )
> > clear_bit(_VPF_blocked, >pause_flags);
> >
> > After step #2, if ret == false, that means, we successfully changed the PI
> > descriptor in arch_block(), if local_events_need_delivery() returns true,
> > _VPF_blocked is cleared. After that, external interrupt come in, hence
> > pi_wakeup_interrupt() --> vcpu_unblock(), but _VPF_blocked is cleared,
> > so vcpu_unblock() does nothing, so the vCPU's PI state is incorrect.
> >
> > One possible solution for it is:
> > - Disable the interrupts before the check in step #3 above
> > - if local_events_need_delivery() returns true, undo all the operations
> >  done in arch_block()
> > - Enable interrupts after _VPF_blocked gets cleared.
> 
> Couldn't this be taken care of by, if necessary, adjusting PI state
> in vmx_do_resume()?

What do you mean here? Could you please elaborate? Thanks!

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [PATCH] console: allow log level threshold adjustments from serial console

[Andrew Cooper]

On 22/09/15 14:24, Jan Beulich wrote:

On 22.09.15 at 15:17,  wrote:

On 22/09/15 13:45, Jan Beulich wrote:

+static void do_adj_thresh(unsigned char key)
+{
+if ( *upper_thresh_adj < *lower_thresh_adj )
+*upper_thresh_adj = *lower_thresh_adj;
+printk("'%c' pressed -> %s log level: %s (rate limited %s)\n",
+   key, thresh_adj, loglvl_str(*lower_thresh_adj),
+   loglvl_str(*upper_thresh_adj));

It might be useful for this printk() to indicate whether it was the
standard or the guest log level which was adjusted.

It does, by printing the string thresh_adj currently points to.


Ah - so it does.  Sorry for the noise.




+static struct keyhandler inc_thresh_keyhandler = {
+.irq_callback = 1,
+.u.irq_fn = do_inc_thresh,
+.desc = "increase log level threshold"
+};
+static struct keyhandler dec_thresh_keyhandler = {
+.irq_callback = 1,
+.u.irq_fn = do_dec_thresh,
+.desc = "decrease log level threshold"
+};
+static struct keyhandler toggle_guest_keyhandler = {
+.irq_callback = 1,
+.u.irq_fn = do_toggle_guest,
+.desc = "toggle host/guest log level adjustment"
+};
+

I am guessing from the looks of these that I should augment my
keyhandler cleanup to also be able to register irq handlers from outside
of common/keyhandler.c

Yeah, I was actually surprised you got away without (i.e. that all of
them lived in this one file so far).


It surprised me as well, but I didn't fancy adding it simply for the 
sake of adding it.


~Andrew

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

Re: [Xen-devel] Is: Make XENVER_* use XSM, seperate the different ops in smaller security domains. Was:Re: [PATCH v1 5/5] xsplice: Use ld-embedded build-ids

[Konrad Rzeszutek Wilk]

On Tue, Sep 22, 2015 at 02:33:23PM +0100, Andrew Cooper wrote:
> On 22/09/15 14:22, Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 18, 2015 at 12:40:46PM +0100, Andrew Cooper wrote:
> >>On 17/09/15 19:45, Konrad Rzeszutek Wilk wrote:
> >>>. snip..
> The build id of the current running hypervisor should belong in the
> xeninfo hypercall.  It is not specific to xsplice.
> >>>However in the previous reviews it was pointed out that it should only 
> >>>be accessible to dom0.
> >>>
> >>>Or to any domains as long as the XSM allows (and is turned on) - so 
> >>>not the default dummy one.
> >>>
> >>>That is a bit of 'if' extra complexity which I am not sure is worth it?
> >>DomU can already read the build information such as changeset, compile
> >>time, etc.  Build-id is no more special or revealing.
> >I would take this as an argument *against* giving DomU access to those
> >pieces of information in details and not as an argument for
> >*additionally* giving it access to build-id.
> >
> >With build-id we have the chance to shape a not-yet-established API and
> >I would like to follow the Principle of least privilege wherever it
> >makes sense.
> >
> >To reach a similar security level with the existing API, it might make
> >sense to limit DomU access to compile date, compile time, compiled by,
> >compiled domain, compiler version and command line details, xen extra
> >version, and xen changeset.  Basically anything that might help DomUs to
> >uniquely identify a Xen build.
> >
> >The approach can not directly drop access to those fields, as that would
> >break an existing API, but it could restrict the detail level handed out
> >to DomU.
> These are all valid arguments to be made, but please lets fix the issue
> properly rather than hacking build-id on the side of an unrelated 
> component.
> 
>  From my point of view, the correct course of action is this:
> 
> * Split the current XSM model to contain separate attributes for general
> and privileged information.
> ** For current compatibility, all existing XENVER_* subops fall into 
> general
> * Apply an XSM check at the very start of the hypercall.
> >That would introduce a performance regression I fear. Linux pvops does this:
> >
> >/*
> >  * Force a proper event-channel callback from Xen after clearing the
> >  * callback mask. We do this in a very simple manner, by making a call
> >  * down into Xen. The pending flag will be checked by Xen on return.
> >  */
> >void xen_force_evtchn_callback(void)
> >{
> > (void)HYPERVISOR_xen_version(0, NULL);
> >}
> >
> >quite often, which now will have to do the XSM check which is extra code.
> >
> >
> >I would say that the XENVER_compile_info (/sys/hypervisor/compilation),
> >XENVER_changeset (/sys/hypervisor/compilation) should go over
> >the XSM check.
> >
> >While:XENVER_version, XENVER_extraversion,XENVER_capabilities,
> >XENVER_platform_parameters, XENVER_get_features,XENVER_pagesize
> >
> >should have no XSM check.
> 
> The XSM check will fall into the noise, performance wise, compared to the
> context switch to make the hypercall in the first place.  It is just another
> switch statement.  Also, selectively applying XSM checks will incur even
> more overhead than doing a blanket XSM check.

I am worried about some spinlock in the depths of XSM code.

But then I haven't looked in detail so perhaps this is not an issue after all.

> 
> Also, I really don't care if you can measure a performance hit (not that I
> reckon you could).  How Linux chooses to behave itself has absolutely no
> bearing on how we go about securing the hypercall.

But making something slower is surely not something we strive for.

> 
> ~Andrew

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

Re: [Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Jan Beulich]

>>> On 22.09.15 at 15:39,  wrote:
> On Tue, Sep 22, 2015 at 06:26:11AM -0700, Ed Swierk wrote:
>> Any other ideas?
> 
> I like it - as it will update it right away. However we would need some
> extra smarts in Xen to reconfigure its view of the PCI device now that the
> extended configuration space has become available.

What parts are you thinking of that would need updating (and
aren't getting updated already)?

Jan


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

Re: [Xen-devel] [linux-3.4 test] 62189: trouble: pass/preparing/queued

[Ian Campbell]

On Tue, 2015-09-22 at 10:34 +, osstest service owner wrote:
> flight 62189 linux-3.4 running [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62189/
> 
> Failures and problems with tests :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-i386-pvgrub  queued

This was running with a version of the test harness which didn't yet
understand about the minimum kernel requirements for some machines and
hence wasn't going to be any more successful than the last 219 attempts...

The next flight will pick up that new code and should therefore have some s
ort of chance of passing...

Ian.

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

Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling

[George Dunlap]

On 09/22/2015 06:10 AM, Wu, Feng wrote:
> 
> 
>> -Original Message-
>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>> Sent: Monday, September 21, 2015 10:12 PM
>> To: Wu, Feng; George Dunlap
>> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
>> Cooper; Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH v7 15/17] vmx: VT-d posted-interrupt core 
>> logic
>> handling
>>
>> On Mon, 2015-09-21 at 13:50 +, Wu, Feng wrote:
>>>
 -Original Message-
 From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>>
 Note that, in case of preemptions, we are switching from a non-idle
 vcpu to another, non-idle, vcpu, so lazy context switching to the
 idle
 vcpu should not have much to do with this case...
>>>
>>> So do you mean in preemptions, we cannot switch from non-idle to idle
>>> or
>>> Idle to non-idle, i.e, we can only switch from non-idle to non-idle?
>>>
>> That's what I meant. It's the definition of 'preemption' and of 'idle
>> task/vcpu', AFICT. I mean, the idle vcpu has the lowest possible
>> priority ever, so it can't really preempt anyone.
>>
>> OTOH, if the idle vcpu is running, that means there weren't any active
>> vcpus because, e.g., all were blocked; therefore, any active vcpu
>> wanting to run would have to wake up (and hence go throught the proper
>> wake up logic) before trying to preempt idle.
>>
>> There is one possible caveat: tasklets. In fact (as you can check
>> yourself by looking, in the code, for tasklet_work_scheduled), it is
>> possible that we force the idle vcpu to execute, even when we have
>> active and runnable vcpus, to let it process tasklets. I'm not really
>> sure whether this could be a problem for you or not, can you have a
>> look (and/or, a try) and report back?
> 
> Thanks for your information about the tasklets part, it is very important,
> consider the following scenario:
> 
> non-idle vCPUA --> idle (tasklet) --> non-idle vCPUA
> 
> The above context switch will use the lazy context switch and cannot be
> covered in __context_switch(), we need to change SN's state during the
> "non-idle to idle" and "idle to non-idle" transition, so that means we need
> add the PI related logic in context_switch() instead of only in 
> __context_switch().
> 
> Besides that, it is more robust to do the PI switch in context_switch() which
> can cover lazy context switch. Maybe in future, there are some other
> feature needing execute task _inside_ an idle context, and it may introduce
> some issues due to no PI state transition, and it is a little hard to debug.

So a transition like the above could happen in the case of a cpu that's
gone offline (e.g., to allow the devicemodel to handle an IO); or, as
you say, if we're doing urgent work in a tasklet such that it preempts a
running task.

One option would be to just ignore this -- in which case we would get
spurious PI interrupts, but no other major issues, right?

But if we want to avoid spurious PI interrupts when running idle, then
yes, we need *some* kind of a hook on the lazy context switch path.

/me does some more thinking...

 -George

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

Re: [Xen-devel] [PATCH v4 00/20] xen/arm64: Add support for 64KB page in Linux

[Ian Campbell]

On Mon, 2015-09-14 at 17:23 +0200, Roger Pau Monné wrote:
> I'm not saying that we shouldn't take those patches, I'm just saying
> that IMHO this is a workaround, and I would like to see a plan and
> somebody committed to have it fixed in a proper way, by introducing a
> 64KB PV block protocol.

In my view the basic unit of operation for all Xen interfaces (on x86 and
arm at least[0]) is 4K. The peer at either end of a PV protocol should
therefore be entitled to assume that at a minimum the other end supports
operation in 4K mode (i.e. 4K is the baseline).

Operations in larger sizes (which would necessarily be multiples of 4K) are
then an extension which is subject to a negotiation between the two ends,
it doesn't really matter if those larger sizes arise because of the use of
superpages or because the guest is internally using some larger basic page
size (which ARM calls a "granule", and where 64K comes from here).

I think this line of reasoning applies just as strongly to the hypercall
ABI as well BTW, they all use 4K as their basic unit, but might support
extensions to operation on multiples of that (negotiated either via a
specific error return and fallback or via the use of XENFEAT).

Ian.

[0] It's not implausible that some other architecture may exsit which
doesn't use 4K as the basic page szie)

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