Re: [Xen-devel] [PATCH 2/3] x86/xsaves: fix overwriting between non-lazy/lazy xsave[sc]

[Shuai Ruan]

On Wed, Feb 24, 2016 at 02:16:38AM -0700, Jan Beulich wrote:
> > I send the bugs-fix patch as whole. I just get the Cc lists using the
> > script based on the whole patchset. May be I will send the patch
> > seperately.
> 
> Thank you. Please also see
> http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
> and in particular also Konrad's recent suggested adjustments
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02877.html
> (perhaps including the other parts of the thread).
Thanks.
> 
> >> > --- a/xen/arch/x86/i387.c
> >> > +++ b/xen/arch/x86/i387.c
> >> > @@ -118,7 +118,7 @@ static inline uint64_t vcpu_xsave_mask(const struct 
> >> > vcpu *v)
> >> >  if ( v->fpu_dirtied )
> >> >  return v->arch.nonlazy_xstate_used ? XSTATE_ALL : XSTATE_LAZY;
> >> >  
> >> > -return v->arch.nonlazy_xstate_used ? XSTATE_NONLAZY : 0;
> >> > +return ( cpu_has_xsaves || cpu_has_xsavec ) ? XSTATE_ALL : 
> >> > XSTATE_NONLAZY;
> >> >  }
> >> 
> >> The description lacks any mention of the performance impact,
> >> and what investigation was done to find ways to perhaps
> >> overcome this. For example, regardless of cpu_has_xsaves,
> >> do we really always need to _use_ XSAVES?
> >> 
> > Currently no supervisor xstates is enabled in xen or even in
> > guest os. Using xsaves is a little ahead (xsavec may used).  
> > xsavec may also cause overwriting problem like xsaves.
> > I will add performance impact in the description. 
> > I am still thinking of a better way to overcome the overhead xsave
> > (But have not get a better solution yet).
> 
> I was thinking that taking into consideration the features a guest
> has ever used (i.e. v->arch.xcr0_accum) to decide which variant
> to use may be a worthwhile avenue to explore.
> 
Oh, Thanks for your suggestion.
You mean when (v->arch.xcr0_accum & (XSTATE_LAZY & ~XSTATE_FP_SSE)) return 
false,
we can return XSTATE_NONLAZY in vcpu_xsave_mask when using xsave[cs]
otherwise return XSTATE_ALL.
It means we can save the area safely, if the guest has ever use 
XSTATE_NONLAZY | XSTATE_FP_SSE only. 
> Jan
> 
> 
> ___
> 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 v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

[Xu, Quan]

On February 25, 2016 8:24pm,  wrote:
> >>> On 25.02.16 at 13:14,  wrote:
> > On February 25, 2016 4:59pm,  wrote:

> >> However, the same effect could be achieved by making the lock a
> >> recursive one, which would then seem to more conventional approach
> >> (but requiring as much code to be touched).

IMO, for v6, I'd better:
  (1). replace all of 'spin_lock(_lock)' with 
'spin_lock_recursive(_lock)',
  (2). replace all of 'spin_unlock(_lock)' with 
'spin_unlock_recursive(_lock)', 
  (3). _do_not_ touch 'spin_is_locked(_lock)'.
Then, ignore v5 [patch4/7], [patch5/7], [patch6/7],  *_locked() related code,  
and add a new patch for the above (1). (2). (3). Right?

BTW, .e.g. 'd->page_alloc_lock', I found the 'd->page_alloc_lock' is called by 
both spin_lock_recursive() and 'spin_lock()'.
_If_  both spin_lock_recursive(>page_alloc_lock) and 
'spin_lock(>page_alloc_lock)' are recursively called in same call tree as 
below, it might be a bug. Right?


{
...
spin_lock()
...
   spin_lock_recursive()
   ...
   spin_unlock_recursive()  <--- (lock might be now free)
...
spin_unlock()
...
}

-Quan



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

[Xen-devel] Xen 4.4, xenstored and WATCH requests

[Sergei Lebedev]

Hello list,

I’m working on a Python client library for XenStore [1]. The library implements 
two ways to access XenStore: via Unix socket and via /dev.  The /dev interface 
turned out to be a bit problematic, because it ignores the req_id field for 
WATCH requests.

The spec [2] requires all responses (except WATCH_EVENT) to copy req_id from 
request. So I wonder if it’s possible that the behaviour I observe is in fact a 
bug in xenstored?

Below is a Python script demonstrating the issue:

import os
import struct

WATCH = 4
WRITE = 11

def send_packet(fd, op, rq_id, tx_id, payload):
data = struct.pack(b"", op, rq_id, tx_id, len(payload)) + payload
os.write(fd, data)


def print_reply(fd):
op, rq_id, tx_id, size = struct.unpack(b"", os.read(fd, 16))
payload = os.read(fd, size) if size else b""
print(op, rq_id, tx_id, payload)


fd = os.open("/dev/xen/xenbus", os.O_RDWR)
try:
send_packet(fd, WRITE, 24, 0, b"/foo\x00bar\x00")
print_reply(fd)  # ACK for WRITE with rq_id = 24.
send_packet(fd, WATCH, 42, 0, b"/foo\x00token\x00")
print_reply(fd)  # Spurious (?) WATCH_EVENT.
print_reply(fd)  # ACK for WATCH with rq_id = 0.
finally:
os.close(fd)

Example output:

(11, 24, 0, 'OK\x00')
(15, 4294967295, 892960384, '/foo\x00token\x00')
(4, 0, 0, 'OK\x00')

I’m running Xen 4.4 on Ubuntu 14.04 inside VirtualBox.

$ uname -a
Linux xen-devel 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Regards,
Sergei

[1]: http://github.com/selectel/pyxs
[2]: http://xenbits.xen.org/docs/4.4-testing/misc/xenstore.txt


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

Re: [Xen-devel] [PATCH] docs/design: introduce HVMMEM_ioreq_serverX types

[Yu, Zhang]

Hi Paul,

  Thanks a lot for your help on this! And below are my questions.

On 2/25/2016 11:49 PM, Paul Durrant wrote:

This patch adds a new 'designs' subdirectory under docs as a repository
for this and future design proposals.

Signed-off-by: Paul Durrant 
---

For convenience this document can also be viewed in PDF at:

http://xenbits.xen.org/people/pauldu/hvmmem_ioreq_server.pdf
---
  docs/designs/hvmmem_ioreq_server.md | 63 +
  1 file changed, 63 insertions(+)
  create mode 100755 docs/designs/hvmmem_ioreq_server.md

diff --git a/docs/designs/hvmmem_ioreq_server.md 
b/docs/designs/hvmmem_ioreq_server.md
new file mode 100755
index 000..47fa715
--- /dev/null
+++ b/docs/designs/hvmmem_ioreq_server.md
@@ -0,0 +1,63 @@
+HVMMEM\_ioreq\_serverX
+--
+
+Background
+==
+
+The concept of the IOREQ server was introduced to allow multiple distinct
+device emulators to a single VM. The XenGT project uses an IOREQ server to
+provide mediated pass-through of Intel GPUs to guests and, as part of the
+mediation, needs to intercept accesses to GPU page-tables (or GTTs) that
+reside in guest RAM.
+
+The current implementation of this sets the type of GTT pages to type
+HVMMEM\_mmio\_write\_dm, which causes Xen to emulate writes to such pages,
+and then maps the guest physical addresses of those pages to the XenGT
+IOREQ server using the HVMOP\_map\_io\_range\_to\_ioreq\_server hypercall.
+However, because the number of GTTs is potentially large, using this
+approach does not scale well.
+
+Proposal
+
+
+Because the number of spare types available in the P2M type-space is
+currently very limited it is proposed that HVMMEM\_mmio\_write\_dm be
+replaced by a single new type HVMMEM\_ioreq\_server. In future, if the
+P2M type-space is increased, this can be renamed to HVMMEM\_ioreq\_server0
+and new HVMMEM\_ioreq\_server1, HVMMEM\_ioreq\_server2, etc. types
+can be added.
+
+Accesses to a page of type HVMMEM\_ioreq\_serverX should be the same as
+HVMMEM\_ram\_rw until the type is _claimed_ by an IOREQ server. Furthermore


Sorry, do you mean even when a gfn is set to HVMMEM_ioreq_serverX type,
its access rights in P2M still remains unchanged? So the new hypercall
pair, HVMOP_[un]map_mem_type_to_ioreq_server, are also responsible for
the PTE updates on the access bits?

If it is true, I'm afraid this would be time consuming, because the
map/unmap will have to traverse all P2M structures to detect the PTEs
with HVMMEM_ioreq_serverX flag set. Yet in XenGT, setting this flag is
triggered dynamically with the construction/destruction of shadow PPGTT.
But I'm not sure to which degree the performance casualties will be,
with frequent EPT table walk and EPT tlb flush.

If it is not, I guess we can(e.g. when trying to WP a gfn):
1> use HVMOP_set_mem_type to set the HVMMEM_ioreq_serverX flag, which
for the write protected case works the same as HVMMEM_mmio_write_dm;
If successful, accesses to a page of type HVMMEM_ioreq_serverX should
trigger the ioreq server selection path, but will be discarded.
2> after HVMOP_map_mem_type_to_ioreq_server is called, all accesses to
this pages of type HVMMEM_ioreq_serverX would be forwarded to a
specified ioreq server.

As to XenGT backend device model, we only need to use the map hypercall
once when trying to contruct the first shadow PPGTT, and use the unmap
hypercall when a VM is going to be torn down.

Any suggestions? :)

Thanks
Yu

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

[Xen-devel] [PATCH v5 12/22] arm/irq: Drop the DT prefix of the irq line type

[Shannon Zhao]

From: Shannon Zhao 

Make these types generic to DT and ACPI. So they are can be used in ACPI
codes.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain_build.c   | 10 -
 xen/arch/arm/gic-v2.c | 10 -
 xen/arch/arm/gic-v3.c |  8 +++
 xen/arch/arm/gic.c|  4 ++--
 xen/arch/arm/irq.c|  8 +++
 xen/arch/arm/time.c   |  2 +-
 xen/include/xen/device_tree.h | 50 +--
 7 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 0f0f53e..83676e4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -650,7 +650,7 @@ static int make_hypervisor_node(const struct kernel_info 
*kinfo,
  * Placeholder for the event channel interrupt.  The values will be
  * replaced later.
  */
-set_interrupt_ppi(intr, ~0, 0xf, DT_IRQ_TYPE_INVALID);
+set_interrupt_ppi(intr, ~0, 0xf, IRQ_TYPE_INVALID);
 res = fdt_property_interrupts(fdt, , 1);
 if ( res )
 return res;
@@ -923,15 +923,15 @@ static int make_timer_node(const struct domain *d, void 
*fdt,
 
 irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);
 DPRINT("  Secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt_ppi(intrs[0], irq, 0xf, IRQ_TYPE_LEVEL_LOW);
 
 irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);
 DPRINT("  Non secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt_ppi(intrs[1], irq, 0xf, IRQ_TYPE_LEVEL_LOW);
 
 irq = timer_get_irq(TIMER_VIRT_PPI);
 DPRINT("  Virt interrupt %u\n", irq);
-set_interrupt_ppi(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt_ppi(intrs[2], irq, 0xf, IRQ_TYPE_LEVEL_LOW);
 
 res = fdt_property_interrupts(fdt, intrs, 3);
 if ( res )
@@ -1463,7 +1463,7 @@ static void evtchn_fixup(struct domain *d, struct 
kernel_info *kinfo)
  *  TODO: Handle properly the cpumask
  */
 set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf,
-  DT_IRQ_TYPE_LEVEL_LOW);
+  IRQ_TYPE_LEVEL_LOW);
 res = fdt_setprop_inplace(kinfo->fdt, node, "interrupts",
   , sizeof(intr));
 if ( res )
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 3fb5823..668b863 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -209,16 +209,16 @@ static void gicv2_set_irq_properties(struct irq_desc 
*desc,
 unsigned int irq = desc->irq;
 unsigned int type = desc->arch.type;
 
-ASSERT(type != DT_IRQ_TYPE_INVALID);
+ASSERT(type != IRQ_TYPE_INVALID);
 ASSERT(spin_is_locked(>lock));
 
 spin_lock();
 /* Set edge / level */
 cfg = readl_gicd(GICD_ICFGR + (irq / 16) * 4);
 edgebit = 2u << (2 * (irq % 16));
-if ( type & DT_IRQ_TYPE_LEVEL_MASK )
+if ( type & IRQ_TYPE_LEVEL_MASK )
 cfg &= ~edgebit;
-else if ( type & DT_IRQ_TYPE_EDGE_BOTH )
+else if ( type & IRQ_TYPE_EDGE_BOTH )
 cfg |= edgebit;
 writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
 
@@ -232,8 +232,8 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
cfg & edgebit ? "Edge" : "Level",
actual & edgebit ? "Edge" : "Level");
 desc->arch.type = actual & edgebit ?
-DT_IRQ_TYPE_EDGE_RISING :
-DT_IRQ_TYPE_LEVEL_HIGH;
+IRQ_TYPE_EDGE_RISING :
+IRQ_TYPE_LEVEL_HIGH;
 }
 
 /* Set target CPU mask (RAZ/WI on uniprocessor) */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index fa61231..a42577b 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -491,9 +491,9 @@ static void gicv3_set_irq_properties(struct irq_desc *desc,
 cfg = readl_relaxed(base);
 
 edgebit = 2u << (2 * (irq % 16));
-if ( type & DT_IRQ_TYPE_LEVEL_MASK )
+if ( type & IRQ_TYPE_LEVEL_MASK )
 cfg &= ~edgebit;
-else if ( type & DT_IRQ_TYPE_EDGE_BOTH )
+else if ( type & IRQ_TYPE_EDGE_BOTH )
 cfg |= edgebit;
 
 writel_relaxed(cfg, base);
@@ -508,8 +508,8 @@ static void gicv3_set_irq_properties(struct irq_desc *desc,
cfg & edgebit ? "Edge" : "Level",
actual & edgebit ? "Edge" : "Level");
 desc->arch.type = actual & edgebit ?
-DT_IRQ_TYPE_EDGE_RISING :
-DT_IRQ_TYPE_LEVEL_HIGH;
+IRQ_TYPE_EDGE_RISING :
+IRQ_TYPE_LEVEL_HIGH;
 }
 
 affinity = gicv3_mpidr_to_affinity(cpu);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 0b3f634..43e6fa2 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -98,7 +98,7 @@ void gic_restore_state(struct vcpu *v)
  * needs to be called with a valid cpu_mask, ie each cpu in the mask has
  * already 

[Xen-devel] [PATCH v5 15/22] arm/gic: Add ACPI support for GIC preinit

[Shannon Zhao]

From: Shannon Zhao 

Since ACPI 6.0 defines that GIC Distributor Structure contains the GIC
version filed, it could get GIC version from that. Then call acpi device
initializing function to preinit GIC device.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
V5: fix coding style and simplify #else case
V4: use ACPI_MADT_GIC_VERSION_V* instead of GICv*
---
 xen/arch/arm/gic.c | 37 +
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 43e6fa2..fbbe37f 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void gic_restore_pending_irqs(struct vcpu *v);
 
@@ -228,10 +230,7 @@ int gic_irq_xlate(const u32 *intspec, unsigned int intsize,
 return 0;
 }
 
-/* Find the interrupt controller and set up the callback to translate
- * device tree IRQ.
- */
-void __init gic_preinit(void)
+static void __init gic_dt_preinit(void)
 {
 int rc;
 struct dt_device_node *node;
@@ -261,6 +260,36 @@ void __init gic_preinit(void)
 dt_device_set_used_by(node, DOMID_XEN);
 }
 
+#ifdef CONFIG_ACPI
+static void __init gic_acpi_preinit(void)
+{
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_distributor *dist;
+
+header = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR, 0);
+if ( !header )
+panic("No valid GICD entries exists");
+
+dist = container_of(header, struct acpi_madt_generic_distributor, header);
+
+if ( acpi_device_init(DEVICE_GIC, NULL, dist->version) )
+panic("Unable to find compatible GIC in the ACPI table");
+}
+#else
+static void __init gic_acpi_preinit(void) { }
+#endif
+
+/* Find the interrupt controller and set up the callback to translate
+ * device tree or ACPI IRQ.
+ */
+void __init gic_preinit(void)
+{
+if ( acpi_disabled )
+gic_dt_preinit();
+else
+gic_acpi_preinit();
+}
+
 /* Set up the GIC */
 void __init gic_init(void)
 {
-- 
2.0.4



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

[Xen-devel] [PATCH v5 04/22] arm/acpi: Add basic ACPI initialization

[Shannon Zhao]

From: Shannon Zhao 

acpi_boot_table_init() will be called in start_xen to get the RSDP and
all the table pointers. With this patch, we can get ACPI boot-time
tables from firmware on ARM64.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
 xen/arch/arm/acpi/Makefile |  1 +
 xen/arch/arm/acpi/boot.c   | 58 ++
 xen/arch/arm/setup.c   |  4 
 3 files changed, 63 insertions(+)
 create mode 100644 xen/arch/arm/acpi/boot.c

diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
index b5be22d..196c40a 100644
--- a/xen/arch/arm/acpi/Makefile
+++ b/xen/arch/arm/acpi/Makefile
@@ -1 +1,2 @@
 obj-y += lib.o
+obj-y += boot.o
diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
new file mode 100644
index 000..1570f7e
--- /dev/null
+++ b/xen/arch/arm/acpi/boot.c
@@ -0,0 +1,58 @@
+/*
+ *  ARM Specific Low-Level ACPI Boot Support
+ *
+ *  Copyright (C) 2001, 2002 Paul Diefenbaugh 
+ *  Copyright (C) 2001 Jun Nakajima 
+ *  Copyright (C) 2014, Naresh Bhat 
+ *  Copyright (C) 2015, Shannon Zhao 
+ *
+ * ~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~
+ */
+
+#include 
+#include 
+
+#include 
+
+/*
+ * acpi_boot_table_init() called from setup_arch(), always.
+ *  1. find RSDP and get its address, and then find XSDT
+ *  2. extract all tables and checksums them all
+ *
+ * return value: (currently ignored)
+ * 0: success
+ * !0: failure
+ *
+ * We can parse ACPI boot-time tables such as FADT, MADT after
+ * this function is called.
+ */
+int __init acpi_boot_table_init(void)
+{
+int error;
+
+/* Initialize the ACPI boot-time table parser. */
+error = acpi_table_init();
+if ( error )
+{
+disable_acpi();
+return error;
+}
+
+return 0;
+}
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e6b689e..fee5385 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -755,6 +756,9 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 setup_mm(fdt_paddr, fdt_size);
 
+/* Parse the ACPI tables for possible boot-time configuration */
+acpi_boot_table_init();
+
 vm_init();
 dt_unflatten_host_device_tree();
 
-- 
2.0.4



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

[Xen-devel] [PATCH v5 10/22] acpi/table: Introduce acpi_table_get_entry_madt to get specified entry

[Shannon Zhao]

From: Shannon Zhao 

This function could get the specified index entry of MADT table. This
would be useful when it needs to get the contens of the entry.

Cc: Jan Beulich 
Signed-off-by: Shannon Zhao 
---
V5: address Jan's comments
V4: Fix coding style and make the function only for MADT table
---
 xen/drivers/acpi/tables.c | 62 +++
 xen/include/xen/acpi.h|  2 ++
 2 files changed, 64 insertions(+)

diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index f81c369..fa4e666 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -221,6 +221,68 @@ void __init acpi_table_print_madt_entry(struct 
acpi_subtable_header *header)
}
 }
 
+static struct acpi_subtable_header * __init
+acpi_get_entry(const char *id, unsigned long table_size,
+  const struct acpi_table_header *table_header,
+  enum acpi_madt_type entry_id, unsigned int entry_index)
+{
+   struct acpi_subtable_header *entry;
+   int count = 0;
+   unsigned long table_end;
+
+   if (!table_size)
+   return NULL;
+
+   if (!table_header) {
+   printk(KERN_WARNING PREFIX "%4.4s not present\n", id);
+   return NULL;
+   }
+
+   table_end = (unsigned long)table_header + table_header->length;
+
+   /* Parse all entries looking for a match. */
+   entry = (struct acpi_subtable_header *)
+   ((unsigned long)table_header + table_size);
+
+   while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
+  table_end) {
+   if (entry->length < sizeof(*entry)) {
+   printk(KERN_ERR PREFIX "[%4.4s:%#x] Invalid length\n",
+  id, entry_id);
+   return NULL;
+   }
+
+   if (entry->type == entry_id) {
+   if (count == entry_index)
+   return entry;
+   count++;
+   }
+
+   entry = (struct acpi_subtable_header *)
+   ((unsigned long)entry + entry->length);
+   }
+
+   return NULL;
+}
+
+struct acpi_subtable_header * __init
+acpi_table_get_entry_madt(enum acpi_madt_type entry_id,
+ unsigned int entry_index)
+{
+   struct acpi_table_header *table_header = NULL;
+   acpi_status status;
+
+   status = acpi_get_table(ACPI_SIG_MADT, acpi_apic_instance,
+   _header);
+   if (ACPI_FAILURE(status)) {
+   printk(KERN_WARNING PREFIX "%4.4s not present\n",
+  ACPI_SIG_MADT);
+   return NULL;
+   }
+
+   return acpi_get_entry(ACPI_SIG_MADT, sizeof(struct acpi_table_madt),
+ table_header, entry_id, entry_index);
+}
 
 int __init
 acpi_parse_entries(char *id, unsigned long table_size,
diff --git a/xen/include/xen/acpi.h b/xen/include/xen/acpi.h
index 894917b..2c2d6ca 100644
--- a/xen/include/xen/acpi.h
+++ b/xen/include/xen/acpi.h
@@ -74,6 +74,8 @@ int acpi_parse_entries(char *id, unsigned long table_size,
   int entry_id, unsigned int max_entries);
 int acpi_table_parse_entries(char *id, unsigned long table_size,
int entry_id, acpi_table_entry_handler handler, unsigned int 
max_entries);
+struct acpi_subtable_header *acpi_table_get_entry_madt(enum acpi_madt_type id,
+ unsigned int entry_index);
 int acpi_table_parse_madt(enum acpi_madt_type id, acpi_table_entry_handler 
handler, unsigned int max_entries);
 int acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,
unsigned int max_entries);
-- 
2.0.4



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

[Xen-devel] [PATCH v5 07/22] ACPI / table: Print GIC information when MADT is parsed

[Shannon Zhao]

From: Hanjun Guo 

When MADT is parsed, print GIC information as debug message:

ACPI: GICC (acpi_id[0x] address[e112f000] MPIDR[0x0] enabled)
ACPI: GICC (acpi_id[0x0001] address[e112f000] MPIDR[0x1] enabled)
...
ACPI: GICC (acpi_id[0x0201] address[e112f000] MPIDR[0x201] enabled)

This debug information will be very helpful to bring up early systems to
see if acpi_id and MPIDR are matched or not as spec defined.

CC: Rafael J. Wysocki 
Tested-by: Suravee Suthikulpanit 
Tested-by: Yijing Wang 
Tested-by: Mark Langsdorf 
Tested-by: Jon Masters 
Tested-by: Timur Tabi 
Tested-by: Robert Richter 
Acked-by: Robert Richter 
Acked-by: Sudeep Holla 
Acked-by: Rafael J. Wysocki 
Acked-by: Lorenzo Pieralisi 
Acked-by: Grant Likely 
Signed-off-by: Hanjun Guo 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Will Deacon 
[Linux commit 4c1c8d7a7ebc8b909493a14b21b233e5377b69aa]
[Use container_of instead of cast and PRIx64 instead of %llx]
Signed-off-by: Shannon Zhao 
---
CC: Jan Beulich 
V5: port this change from Linux
---
 xen/drivers/acpi/tables.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
index 4e590de..f81c369 100644
--- a/xen/drivers/acpi/tables.c
+++ b/xen/drivers/acpi/tables.c
@@ -189,6 +189,30 @@ void __init acpi_table_print_madt_entry(struct 
acpi_subtable_header *header)
}
break;
 
+   case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
+   {
+   struct acpi_madt_generic_interrupt *p =
+   container_of(header, struct 
acpi_madt_generic_interrupt, header);
+   printk(KERN_DEBUG PREFIX
+  "GICC (acpi_id[0x%04x] address[0x%"PRIx64"] 
MPIDR[0x%"PRIx64"] %s)\n",
+  p->uid, p->base_address,
+  p->arm_mpidr,
+  (p->flags & ACPI_MADT_ENABLED) ? "enabled" : 
"disabled");
+
+   }
+   break;
+
+   case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
+   {
+   struct acpi_madt_generic_distributor *p =
+   container_of(header, struct 
acpi_madt_generic_distributor, header);
+   printk(KERN_DEBUG PREFIX
+  "GIC Distributor (gic_id[0x%04x] 
address[0x%"PRIx64"] gsi_base[%d])\n",
+  p->gic_id, p->base_address,
+  p->global_irq_base);
+   }
+   break;
+
default:
printk(KERN_WARNING PREFIX
   "Found unsupported MADT entry (type = %#x)\n",
-- 
2.0.4



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

[Xen-devel] [PATCH v5 09/22] arm/acpi: Add ACPI support for SMP initialization

[Shannon Zhao]

From: Shannon Zhao 

ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and Parking
protocol, but the Parking protocol is only specified for ARMv7 now, so
make PSCI as the only way for the SMP boot protocol before some updates
for the ACPI spec or the Parking protocol spec.

ACPI only supports PSCI 0.2+, since prior to PSCI 0.2 function IDs are
not well-defined.

Signed-off-by: Hanjun Guo 
Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
V4: explain why only support PSCI 0.2+ and print an error message for
PSCI 0.1 and SMC not present
---
 xen/arch/arm/arm64/smpboot.c |  7 ++-
 xen/arch/arm/psci.c  | 35 ---
 xen/arch/arm/smpboot.c   |  7 ++-
 3 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
index 7928f69..4fd0ac6 100644
--- a/xen/arch/arm/arm64/smpboot.c
+++ b/xen/arch/arm/arm64/smpboot.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct smp_enable_ops {
 int (*prepare_cpu)(int);
@@ -96,7 +97,11 @@ static int __init dt_arch_cpu_init(int cpu, struct 
dt_device_node *dn)
 
 int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
 {
-return dt_arch_cpu_init(cpu, dn);
+if ( acpi_disabled )
+return dt_arch_cpu_init(cpu, dn);
+else
+/* acpi only supports psci at present */
+return smp_psci_init(cpu);
 }
 
 int __init arch_cpu_up(int cpu)
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index d800cb6..7966b5e 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * While a 64-bit OS can make calls with SMC32 calling conventions, for
@@ -86,6 +87,12 @@ int __init psci_init_0_1(void)
 int ret;
 const struct dt_device_node *psci;
 
+if ( !acpi_disabled )
+{
+printk("PSCI 0.1 is not supported when using ACPI\n");
+return -EINVAL;
+}
+
 psci = dt_find_compatible_node(NULL, NULL, "arm,psci");
 if ( !psci )
 return -EOPNOTSUPP;
@@ -116,15 +123,26 @@ int __init psci_init_0_2(void)
 { /* sentinel */ },
 };
 int ret;
-const struct dt_device_node *psci;
 
-psci = dt_find_matching_node(NULL, psci_ids);
-if ( !psci )
-return -EOPNOTSUPP;
+if ( acpi_disabled )
+{
+const struct dt_device_node *psci;
 
-ret = psci_is_smc_method(psci);
-if ( ret )
-return -EINVAL;
+psci = dt_find_matching_node(NULL, psci_ids);
+if ( !psci )
+return -EOPNOTSUPP;
+
+ret = psci_is_smc_method(psci);
+if ( ret )
+return -EINVAL;
+}
+else
+{
+if ( acpi_psci_hvc_present() ) {
+printk("PSCI conduit must be SMC, but is HVC\n");
+return -EINVAL;
+}
+}
 
 psci_ver = call_smc(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
 
@@ -148,6 +166,9 @@ int __init psci_init(void)
 {
 int ret;
 
+if ( !acpi_disabled && !acpi_psci_present() )
+return -EOPNOTSUPP;
+
 ret = psci_init_0_2();
 if ( ret )
 ret = psci_init_0_1();
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index b6119d1..c5109bf 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 cpumask_t cpu_online_map;
 cpumask_t cpu_present_map;
@@ -247,7 +248,11 @@ void __init smp_init_cpus(void)
 return;
 }
 
-dt_smp_init_cpus();
+if ( acpi_disabled )
+dt_smp_init_cpus();
+else
+acpi_smp_init_cpus();
+
 }
 
 int __init
-- 
2.0.4



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

[Xen-devel] [PATCH v5 02/22] arm/acpi: Add arm specific acpi header file

[Shannon Zhao]

From: Shannon Zhao 

Add architecture specific definitions and calls required for acpi in new
header file.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 xen/arch/arm/setup.c   |  5 +
 xen/include/asm-arm/acpi.h | 51 ++
 2 files changed, 56 insertions(+)
 create mode 100644 xen/include/asm-arm/acpi.h

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index e95759d..e6b689e 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -45,11 +45,16 @@
 #include 
 #include 
 #include 
+#include 
 
 struct bootinfo __initdata bootinfo;
 
 struct cpuinfo_arm __read_mostly boot_cpu_data;
 
+#ifdef CONFIG_ACPI
+bool_t __read_mostly acpi_disabled;
+#endif
+
 #ifdef CONFIG_ARM_32
 static unsigned long opt_xenheap_megabytes __initdata;
 integer_param("xenheap_megabytes", opt_xenheap_megabytes);
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
new file mode 100644
index 000..10e02bd
--- /dev/null
+++ b/xen/include/asm-arm/acpi.h
@@ -0,0 +1,51 @@
+/*
+ *  Copyright (C) 2015, Shannon Zhao 
+ *
+ * ~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~
+ */
+
+#ifndef _ASM_ARM_ACPI_H
+#define _ASM_ARM_ACPI_H
+
+#include 
+#include 
+
+#define COMPILER_DEPENDENT_INT64   long long
+#define COMPILER_DEPENDENT_UINT64  unsigned long long
+#define ACPI_MAP_MEM_ATTR  PAGE_HYPERVISOR
+
+#ifdef CONFIG_ACPI
+extern bool_t acpi_disabled;
+/* Basic configuration for ACPI */
+static inline void disable_acpi(void)
+{
+acpi_disabled = 1;
+}
+
+static inline void enable_acpi(void)
+{
+acpi_disabled = 0;
+}
+#else
+#define acpi_disabled (1)
+#define disable_acpi()
+#define enable_acpi()
+#endif
+
+#endif /*_ASM_ARM_ACPI_H*/
-- 
2.0.4



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

[Xen-devel] [PATCH v5 18/22] arm/acpi: Add a new ACPI initialized function for UART

[Shannon Zhao]

From: Shannon Zhao 

This adds a new function to initialize UART for ACPI on ARM.

Signed-off-by: Shannon Zhao 
---
V5: fix coding style
---
 xen/arch/arm/setup.c|  2 +-
 xen/drivers/char/arm-uart.c | 37 +++--
 xen/include/xen/serial.h|  2 +-
 3 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d4261e8..6d205a9 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -768,7 +768,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 gic_preinit();
 
-dt_uart_init();
+arm_uart_init();
 console_init_preirq();
 console_init_ring();
 
diff --git a/xen/drivers/char/arm-uart.c b/xen/drivers/char/arm-uart.c
index 883e615..627746b 100644
--- a/xen/drivers/char/arm-uart.c
+++ b/xen/drivers/char/arm-uart.c
@@ -1,7 +1,7 @@
 /*
  * xen/drivers/char/arm-uart.c
  *
- * Generic uart retrieved via the device tree
+ * Generic uart retrieved via the device tree or ACPI
  *
  * Julien Grall 
  * Copyright (c) 2013 Linaro Limited.
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Configure UART port with a string:
@@ -35,7 +36,7 @@
 static char __initdata opt_dtuart[256] = "";
 string_param("dtuart", opt_dtuart);
 
-void __init dt_uart_init(void)
+static void __init dt_uart_init(void)
 {
 struct dt_device_node *dev;
 int ret;
@@ -96,6 +97,38 @@ void __init dt_uart_init(void)
 printk("Unable to initialize dtuart: %d\n", ret);
 }
 
+#ifdef CONFIG_ACPI
+static void __init acpi_uart_init(void)
+{
+struct acpi_table_spcr *spcr = NULL;
+int ret;
+
+acpi_get_table(ACPI_SIG_SPCR, 0, (struct acpi_table_header **));
+
+if ( spcr == NULL )
+{
+printk("Unable to get spcr table\n");
+}
+else
+{
+ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type);
+
+if ( ret )
+printk("Unable to initialize acpi uart: %d\n", ret);
+}
+}
+#else
+static void __init acpi_uart_init(void) { }
+#endif
+
+void __init arm_uart_init(void)
+{
+if ( acpi_disabled )
+dt_uart_init();
+else
+acpi_uart_init();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 71e6ade..1212a12 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -170,7 +170,7 @@ struct ns16550_defaults {
 void ns16550_init(int index, struct ns16550_defaults *defaults);
 void ehci_dbgp_init(void);
 
-void __init dt_uart_init(void);
+void arm_uart_init(void);
 
 struct physdev_dbgp_op;
 int dbgp_op(const struct physdev_dbgp_op *);
-- 
2.0.4



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

[Xen-devel] [PATCH v5 16/22] arm/irq: Add helper function for setting interrupt type

[Shannon Zhao]

From: Parth Dixit 

Add a helper function to set edge/level type information for an
interrupt.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 xen/arch/arm/irq.c| 27 ---
 xen/include/asm-arm/irq.h |  2 ++
 2 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 0ff5cbc..2f8af72 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -655,27 +655,32 @@ unlock:
 return ret;
 }
 
+int irq_set_type(unsigned int irq, unsigned int type)
+{
+int res;
+
+/* Setup the IRQ type */
+if ( irq < NR_LOCAL_IRQS )
+res = irq_local_set_type(irq, type);
+else
+res = irq_set_spi_type(irq, type);
+
+return res;
+}
+
 int platform_get_irq(const struct dt_device_node *device, int index)
 {
 struct dt_irq dt_irq;
 unsigned int type, irq;
-int res;
 
-res = dt_device_get_irq(device, index, _irq);
-if ( res )
+if ( dt_device_get_irq(device, index, _irq) )
 return -1;
 
 irq = dt_irq.irq;
 type = dt_irq.type;
 
-/* Setup the IRQ type */
-if ( irq < NR_LOCAL_IRQS )
-res = irq_local_set_type(irq, type);
-else
-res = irq_set_spi_type(irq, type);
-
-if ( res )
-return -1;
+if ( irq_set_type(irq, type) )
+return -1;
 
 return irq;
 }
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index f33c331..493773c 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -52,6 +52,8 @@ void arch_move_irqs(struct vcpu *v);
 /* Set IRQ type for an SPI */
 int irq_set_spi_type(unsigned int spi, unsigned int type);
 
+int irq_set_type(unsigned int irq, unsigned int type);
+
 int platform_get_irq(const struct dt_device_node *device, int index);
 
 void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask);
-- 
2.0.4



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

[Xen-devel] [PATCH v5 22/22] arm/acpi: Add acpi parameter to enable/disable acpi

[Shannon Zhao]

From: Shannon Zhao 

Define new command line parameter "acpi" to enable/disable acpi.
This implements the following policy to decide whether ACPI should be
used to boot the system:
- acpi=off: ACPI will not be used to boot the system, even if there is
  no alternative available (e.g., device tree is empty)
- acpi=force: only ACPI will be used to boot the system; if that fails,
  there will be no fallback to alternative methods (such as device tree)
- otherwise, ACPI will be used as a fallback if the device tree turns
  out to lack a platform description; the heuristic to decide this is
  whether /chosen is the only node present at depth 1

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/acpi/boot.c | 52 
 1 file changed, 52 insertions(+)

diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 066b590..345e568 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -30,9 +30,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
 
 /* Processors with enabled flag and sane MPIDR */
 static unsigned int enabled_cpus;
@@ -174,6 +176,36 @@ static int __init acpi_parse_fadt(struct acpi_table_header 
*table)
 return -EINVAL;
 }
 
+static bool_t __initdata param_acpi_off;
+static bool_t __initdata param_acpi_force;
+
+static void __init parse_acpi_param(char *arg)
+{
+if ( !arg )
+return;
+
+/* Interpret the parameter for use within Xen. */
+if ( !parse_bool(arg) )
+param_acpi_off = true;
+else if ( !strcmp(arg, "force") ) /* force ACPI to be enabled */
+param_acpi_force = true;
+}
+custom_param("acpi", parse_acpi_param);
+
+static int __init dt_scan_depth1_nodes(const void *fdt, int node,
+   const char *uname, int depth,
+   u32 address_cells, u32 size_cells,
+   void *data)
+{
+/*
+ * Return 1 as soon as we encounter a node at depth 1 that is
+ * not the /chosen node.
+ */
+if (depth == 1 && (strcmp(uname, "chosen") != 0))
+return 1;
+return 0;
+}
+
 /*
  * acpi_boot_table_init() called from setup_arch(), always.
  *  1. find RSDP and get its address, and then find XSDT
@@ -190,6 +222,26 @@ int __init acpi_boot_table_init(void)
 {
 int error;
 
+/*
+ * Enable ACPI instead of device tree unless
+ * - ACPI has been disabled explicitly (acpi=off), or
+ * - the device tree is not empty (it has more than just a /chosen node)
+ *   and ACPI has not been force enabled (acpi=force)
+ */
+if ( param_acpi_off || ( !param_acpi_force
+ && 
device_tree_for_each_node(device_tree_flattened,
+   dt_scan_depth1_nodes, 
NULL)))
+{
+disable_acpi();
+return 0;
+}
+
+/*
+ * ACPI is disabled at this point. Enable it in order to parse
+ * the ACPI tables.
+ */
+enable_acpi();
+
 /* Initialize the ACPI boot-time table parser. */
 error = acpi_table_init();
 if ( error )
-- 
2.0.4



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

[Xen-devel] [PATCH v5 20/22] arm/acpi: Initialize serial port from ACPI SPCR table

[Shannon Zhao]

From: Shannon Zhao 

Parse ACPI SPCR (Serial Port Console Redirection table) table and
initialize the serial port pl011.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
Cc: Jan Beulich 
---
 xen/drivers/char/pl011.c  | 37 +
 xen/include/acpi/actbl2.h |  5 +
 2 files changed, 42 insertions(+)

diff --git a/xen/drivers/char/pl011.c b/xen/drivers/char/pl011.c
index 7e16294..30a8551 100644
--- a/xen/drivers/char/pl011.c
+++ b/xen/drivers/char/pl011.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -308,6 +309,42 @@ DT_DEVICE_START(pl011, "PL011 UART", DEVICE_SERIAL)
 .init = pl011_dt_uart_init,
 DT_DEVICE_END
 
+#ifdef CONFIG_ACPI
+static int __init pl011_acpi_uart_init(const void *data)
+{
+acpi_status status;
+struct acpi_table_spcr *spcr = NULL;
+int res;
+
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **));
+
+if ( ACPI_FAILURE(status) )
+{
+printk("pl011: Failed to get SPCR table\n");
+return -EINVAL;
+}
+
+/* trigger/polarity information is not available in spcr */
+irq_set_type(spcr->interrupt, IRQ_TYPE_EDGE_BOTH);
+
+res = pl011_uart_init(spcr->interrupt, spcr->serial_port.address,
+  PAGE_SIZE);
+if ( res < 0 )
+{
+printk("pl011: Unable to initialize\n");
+return res;
+}
+
+return 0;
+}
+
+ACPI_DEVICE_START(apl011, "PL011 UART", DEVICE_SERIAL)
+.class_type = ACPI_DBG2_PL011,
+.init = pl011_acpi_uart_init,
+ACPI_DEVICE_END
+#endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 1ad67f8..4341a30 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -281,6 +281,11 @@ struct acpi_dbg2_device {
 
 #define ACPI_DBG2_16550_COMPATIBLE  0x
 #define ACPI_DBG2_16550_SUBSET  0x0001
+#define ACPI_DBG2_PL011 0x0003
+#define ACPI_DBG2_SBSA_32   0x000d
+#define ACPI_DBG2_SBSA  0x000e
+#define ACPI_DBG2_DCC   0x000f
+#define ACPI_DBG2_BCM2835   0x0010
 
 #define ACPI_DBG2_1394_STANDARD 0x
 
-- 
2.0.4



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

[Xen-devel] [PATCH v5 14/22] arm/gic-v3: Add ACPI boot support for GICv3

[Shannon Zhao]

From: Shannon Zhao 

Like GICv2, ACPI on Xen hypervisor uses MADT table for proper GICv3
initialization. Parse GIC distributor subtable, redistributor subtable
and interrupt subtable.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
V5: fix coding style and simplify #else case
V4: move ioremap to common init function and fix coding style
---
 xen/arch/arm/gic-v3.c | 171 +-
 1 file changed, 170 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a42577b..f83fd88 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -34,6 +34,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -41,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Global state */
 static struct {
@@ -1232,6 +1235,153 @@ static void __init gicv3_dt_init(void)
   , );
 }
 
+#ifdef CONFIG_ACPI
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+static int cpu_base_assigned = 0;
+struct acpi_madt_generic_interrupt *processor =
+   container_of(header, struct acpi_madt_generic_interrupt, 
header);
+
+if ( BAD_MADT_ENTRY(processor, end) )
+return -EINVAL;
+
+/* Read from APIC table and fill up the GIC variables */
+if ( !cpu_base_assigned )
+{
+cbase = processor->base_address;
+csize = SZ_8K;
+vbase = processor->gicv_base_address;
+gicv3_info.maintenance_irq = processor->vgic_interrupt;
+
+if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
+irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
+else
+irq_set_type(gicv3_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
+
+cpu_base_assigned = 1;
+}
+else
+{
+if ( cbase != processor->base_address
+ || vbase != processor->gicv_base_address
+ || gicv3_info.maintenance_irq != processor->vgic_interrupt )
+{
+printk("GICv3: GICC entries are not same in MADT table\n");
+return -EINVAL;
+}
+}
+
+return 0;
+}
+
+static int __init
+gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_distributor *dist =
+ container_of(header, struct acpi_madt_generic_distributor, 
header);
+
+if ( BAD_MADT_ENTRY(dist, end) )
+return -EINVAL;
+
+dbase = dist->base_address;
+
+return 0;
+}
+static int __init
+gic_acpi_get_madt_redistributor_num(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+/* Nothing to do here since it only wants to get the number of GIC
+ * redistributors.
+ */
+return 0;
+}
+
+static void __init gicv3_acpi_init(void)
+{
+struct acpi_table_header *table;
+struct rdist_region *rdist_regs;
+acpi_status status;
+int count, i;
+
+status = acpi_get_table(ACPI_SIG_MADT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+panic("GICv3: Failed to get MADT table, %s", msg);
+}
+
+/*
+ * Find distributor base address. We expect one distributor entry since
+ * ACPI 5.0 spec neither support multi-GIC instances nor GIC cascade.
+ */
+count = acpi_parse_entries(ACPI_SIG_MADT, sizeof(struct acpi_table_madt),
+   gic_acpi_parse_madt_distributor, table,
+   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR, 0);
+
+if ( count <= 0 )
+panic("GICv3: No valid GICD entries exists");
+
+if ( (dbase & ~PAGE_MASK) )
+panic("GICv3: Found unaligned distributor address %"PRIpaddr"",
+  dbase);
+
+/* Get number of redistributor */
+count = acpi_parse_entries(ACPI_SIG_MADT, sizeof(struct acpi_table_madt),
+   gic_acpi_get_madt_redistributor_num, table,
+   ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR, 0);
+if ( count <= 0 )
+panic("GICv3: No valid GICR entries exists");
+
+gicv3.rdist_count = count;
+
+if ( gicv3.rdist_count > MAX_RDIST_COUNT )
+panic("GICv3: Number of redistributor regions is more than"
+  "%d (Increase MAX_RDIST_COUNT!!)\n", MAX_RDIST_COUNT);
+
+rdist_regs = xzalloc_array(struct rdist_region, gicv3.rdist_count);
+if ( !rdist_regs )
+panic("GICv3: Failed to allocate memory for rdist regions\n");
+
+for ( i = 0; i < gicv3.rdist_count; i++ )
+{
+struct acpi_subtable_header *header;
+struct acpi_madt_generic_redistributor *gic_rdist;
+
+header = 
acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR,
+  

[Xen-devel] [PATCH v5 08/22] arm/acpi: Parse MADT to map logical cpu to MPIDR and get cpu_possible_map

[Shannon Zhao]

From: Parth Dixit 

MADT contains the information for MPIDR which is essential for SMP
initialization, parse the GIC cpu interface structures to get the MPIDR
value and map it to cpu_logical_map(), and add enabled cpu with valid
MPIDR into cpu_possible_map.

Move BAD_MADT_ENTRY to common place and parenthesize its parameters.

Cc: Jan Beulich 
Signed-off-by: Hanjun Guo 
Signed-off-by: Tomasz Nowicki 
Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
V5: drop bootcpu_valid and parenthesize parameters of BAD_MADT_ENTRY
V4: fix coding style and address some comments
---
 xen/arch/arm/acpi/boot.c   | 121 +
 xen/arch/x86/acpi/boot.c   |   4 --
 xen/include/asm-arm/acpi.h |   1 +
 xen/include/xen/acpi.h |   4 ++
 4 files changed, 126 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 6b33fbe..066b590 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -32,6 +32,127 @@
 #include 
 
 #include 
+#include 
+
+/* Processors with enabled flag and sane MPIDR */
+static unsigned int enabled_cpus;
+
+/* total number of cpus in this system */
+static unsigned int __initdata total_cpus;
+
+/*
+ * acpi_map_gic_cpu_interface - generates a logical cpu number
+ * and map to MPIDR represented by GICC structure
+ */
+static void __init
+acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
+{
+int i;
+u64 mpidr = processor->arm_mpidr & MPIDR_HWID_MASK;
+bool_t enabled = !!(processor->flags & ACPI_MADT_ENABLED);
+
+if ( mpidr == MPIDR_INVALID )
+{
+printk("Skip MADT cpu entry with invalid MPIDR\n");
+return;
+}
+
+total_cpus++;
+if ( !enabled )
+return;
+
+if ( enabled_cpus >=  NR_CPUS )
+{
+printk("NR_CPUS limit of %d reached, Processor %d/0x%"PRIx64" 
ignored.\n",
+   NR_CPUS, total_cpus, mpidr);
+return;
+}
+
+/* Check if GICC structure of boot CPU is available in the MADT */
+if ( (enabled_cpus == 0) && (cpu_logical_map(0) != mpidr) )
+{
+printk("Firmware bug, duplicate CPU MPIDR: 0x%"PRIx64" in MADT\n",
+   mpidr);
+return;
+}
+
+/*
+ * Duplicate MPIDRs are a recipe for disaster. Scan
+ * all initialized entries and check for
+ * duplicates. If any is found just ignore the CPU.
+ */
+for ( i = 0; i < enabled_cpus; i++ )
+{
+if ( cpu_logical_map(i) == mpidr )
+{
+printk("Firmware bug, duplicate CPU MPIDR: 0x%"PRIx64" in MADT\n",
+   mpidr);
+return;
+}
+}
+
+if ( !acpi_psci_present() )
+return;
+
+/* CPU 0 was already initialized */
+if ( enabled_cpus )
+{
+if ( arch_cpu_init(enabled_cpus, NULL) < 0 )
+return;
+
+/* map the logical cpu id to cpu MPIDR */
+cpu_logical_map(enabled_cpus) = mpidr;
+}
+
+enabled_cpus++;
+}
+
+static int __init
+acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *processor =
+   container_of(header, struct acpi_madt_generic_interrupt, 
header);
+
+if ( BAD_MADT_ENTRY(processor, end) )
+return -EINVAL;
+
+acpi_table_print_madt_entry(header);
+acpi_map_gic_cpu_interface(processor);
+return 0;
+}
+
+/* Parse GIC cpu interface entries in MADT for SMP init */
+void __init acpi_smp_init_cpus(void)
+{
+int count, i;
+
+/*
+ * do a partial walk of MADT to determine how many CPUs
+ * we have including disabled CPUs, and get information
+ * we need for SMP init
+ */
+count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+acpi_parse_gic_cpu_interface, 0);
+
+if ( count <= 0 )
+{
+printk("Error parsing GIC CPU interface entry\n");
+return;
+}
+
+if ( enabled_cpus > 1 )
+{
+printk("MADT missing boot CPU MPIDR, not enabling secondaries\n");
+return;
+}
+
+for ( i = 0; i < enabled_cpus; i++ )
+cpumask_set_cpu(i, _possible_map);
+
+/* Make boot-up look pretty */
+printk("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
+}
 
 static int __init acpi_parse_fadt(struct acpi_table_header *table)
 {
diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c
index fac36c6..385c0be 100644
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -43,10 +43,6 @@
 #include 
 #include 
 
-#define BAD_MADT_ENTRY(entry, end) (   \
-   (!entry) || (unsigned long)entry + sizeof(*entry) > end ||  \
-   ((struct acpi_subtable_header 

[Xen-devel] [PATCH v5 17/22] arm/acpi: Parse GTDT to initialize timer

[Shannon Zhao]

From: Shannon Zhao 

Parse GTDT (Generic Timer Descriptor Table) to initialize timer. Using
the information presented by GTDT to initialize the arch timer (not
memory-mapped).

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
V5: Move READ_SYSREG32(CNTFRQ_EL0) / 1000 to common place and simplify
#else case
V4: Factor dt parts
---
 xen/arch/arm/time.c | 86 +++--
 1 file changed, 70 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 73a1a3e..5f8f974 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -65,8 +66,51 @@ unsigned int timer_get_irq(enum timer_ppi ppi)
 
 static __initdata struct dt_device_node *timer;
 
+#ifdef CONFIG_ACPI
+static u32 __init acpi_get_timer_irq_type(u32 flags)
+{
+return (flags & ACPI_GTDT_INTERRUPT_MODE) ? IRQ_TYPE_EDGE_BOTH
+  : IRQ_TYPE_LEVEL_MASK;
+}
+
+/* Initialize per-processor generic timer */
+static int __init arch_timer_acpi_init(struct acpi_table_header *header)
+{
+u32 irq_type;
+struct acpi_table_gtdt *gtdt;
+
+gtdt = container_of(header, struct acpi_table_gtdt, header);
+
+/* Initialize all the generic timer IRQ variable from GTDT table */
+irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el1_flags);
+irq_set_type(gtdt->non_secure_el1_interrupt, irq_type);
+timer_irq[TIMER_PHYS_NONSECURE_PPI] = gtdt->non_secure_el1_interrupt;
+
+irq_type = acpi_get_timer_irq_type(gtdt->secure_el1_flags);
+irq_set_type(gtdt->secure_el1_interrupt, irq_type);
+timer_irq[TIMER_PHYS_SECURE_PPI] = gtdt->secure_el1_interrupt;
+
+irq_type = acpi_get_timer_irq_type(gtdt->virtual_timer_flags);
+irq_set_type(gtdt->virtual_timer_interrupt, irq_type);
+timer_irq[TIMER_VIRT_PPI] = gtdt->virtual_timer_interrupt;
+
+irq_type = acpi_get_timer_irq_type(gtdt->non_secure_el2_flags);
+irq_set_type(gtdt->non_secure_el2_interrupt, irq_type);
+timer_irq[TIMER_HYP_PPI] = gtdt->non_secure_el2_interrupt;
+
+return 0;
+}
+
+static void __init preinit_acpi_xen_time(void)
+{
+acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+}
+#else
+static void __init preinit_acpi_xen_time(void) { }
+#endif
+
 /* Set up the timer on the boot CPU (early init function) */
-void __init preinit_xen_time(void)
+static void __init preinit_dt_xen_time(void)
 {
 static const struct dt_device_match timer_ids[] __initconst =
 {
@@ -75,6 +119,7 @@ void __init preinit_xen_time(void)
 };
 int res;
 u32 rate;
+unsigned int i;
 
 timer = dt_find_matching_node(NULL, timer_ids);
 if ( !timer )
@@ -82,27 +127,12 @@ void __init preinit_xen_time(void)
 
 dt_device_set_used_by(timer, DOMID_XEN);
 
-res = platform_init_time();
-if ( res )
-panic("Timer: Cannot initialize platform timer");
-
 res = dt_property_read_u32(timer, "clock-frequency", );
 if ( res )
 {
 cpu_khz = rate / 1000;
 timer_dt_clock_frequency = rate;
 }
-else
-cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
-
-boot_count = READ_SYSREG64(CNTPCT_EL0);
-}
-
-/* Set up the timer on the boot CPU (late init function) */
-int __init init_xen_time(void)
-{
-int res;
-unsigned int i;
 
 /* Retrieve all IRQs for the timer */
 for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
@@ -113,7 +143,31 @@ int __init init_xen_time(void)
 panic("Timer: Unable to retrieve IRQ %u from the device tree", i);
 timer_irq[i] = res;
 }
+}
+
+void __init preinit_xen_time(void)
+{
+int res;
+
+/* Initialize all the generic timers presented in GTDT */
+if ( acpi_disabled )
+preinit_dt_xen_time();
+else
+preinit_acpi_xen_time();
+
+if ( !cpu_khz )
+cpu_khz = READ_SYSREG32(CNTFRQ_EL0) / 1000;
+
+res = platform_init_time();
+if ( res )
+panic("Timer: Cannot initialize platform timer");
 
+boot_count = READ_SYSREG64(CNTPCT_EL0);
+}
+
+/* Set up the timer on the boot CPU (late init function) */
+int __init init_xen_time(void)
+{
 /* Check that this CPU supports the Generic Timer interface */
 if ( !cpu_has_gentimer )
 panic("CPU does not support the Generic Timer v1 interface");
-- 
2.0.4



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

[Xen-devel] [PATCH v5 06/22] arm/acpi: Parse FADT table and get PSCI flags

[Shannon Zhao]

From: Shannon Zhao 

There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set, the
former signals to the OS that the hardware is PSCI compliant. The latter
selects the appropriate conduit for PSCI calls by toggling between
Hypervisor Calls (HVC) and Secure Monitor Calls (SMC). FADT table
contains such information, parse FADT to get the flags for furture
usage.

Since STAO table and the GIC version are introduced by ACPI 6.0, we will
check the version and only parse FADT table with version >= 6.0. If
firmware provides ACPI tables with ACPI version less than 6.0, OS will
be messed up with those information, so disable ACPI if we get an FADT
table with version less than 6.0.

Signed-off-by: Hanjun Guo 
Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
V5: only define acpi_psci_present and acpi_psci_hvc_present once 
V4: drop disable_acpi in acpi_parse_fadt
---
 xen/arch/arm/acpi/boot.c   | 30 ++
 xen/arch/arm/acpi/lib.c| 12 
 xen/include/asm-arm/acpi.h |  3 +++
 3 files changed, 45 insertions(+)

diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 1570f7e..6b33fbe 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -27,9 +27,32 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
+static int __init acpi_parse_fadt(struct acpi_table_header *table)
+{
+struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
+
+/*
+ * Revision in table header is the FADT Major revision, and there
+ * is a minor revision of FADT which was introduced by ACPI 6.0,
+ * we only deal with ACPI 6.0 or newer revision to get GIC and SMP
+ * boot protocol configuration data, or we will disable ACPI.
+ */
+if ( table->revision > 6
+ || (table->revision == 6 && fadt->minor_revision >= 0) )
+return 0;
+
+printk("Unsupported FADT revision %d.%d, should be 6.0+, will disable 
ACPI\n",
+table->revision, fadt->minor_revision);
+
+return -EINVAL;
+}
+
 /*
  * acpi_boot_table_init() called from setup_arch(), always.
  *  1. find RSDP and get its address, and then find XSDT
@@ -54,5 +77,12 @@ int __init acpi_boot_table_init(void)
 return error;
 }
 
+if ( acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt) )
+{
+/* disable ACPI if no FADT is found */
+disable_acpi();
+printk("Can't find FADT\n");
+}
+
 return 0;
 }
diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
index f817fe6..a30e4e6 100644
--- a/xen/arch/arm/acpi/lib.c
+++ b/xen/arch/arm/acpi/lib.c
@@ -50,3 +50,15 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
 
return ((char *) base + offset);
 }
+
+/* 1 to indicate PSCI 0.2+ is implemented */
+bool_t __init acpi_psci_present(void)
+{
+return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT;
+}
+
+/* 1 to indicate HVC is present instead of SMC as the PSCI conduit */
+bool_t __init acpi_psci_hvc_present(void)
+{
+return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
+}
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 10e02bd..f13072f 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -30,6 +30,9 @@
 #define COMPILER_DEPENDENT_UINT64  unsigned long long
 #define ACPI_MAP_MEM_ATTR  PAGE_HYPERVISOR
 
+bool_t __init acpi_psci_present(void);
+bool_t __init acpi_psci_hvc_present(void);
+
 #ifdef CONFIG_ACPI
 extern bool_t acpi_disabled;
 /* Basic configuration for ACPI */
-- 
2.0.4



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

[Xen-devel] [PATCH v5 19/22] ACPICA: Headers: Add support for CSRT and DBG2 ACPI tables.

[Shannon Zhao]

From: Bob Moore 

These tables are defined outside of the ACPI specification.

Signed-off-by: Bob Moore 
Signed-off-by: Feng Tang 
Signed-off-by: Len Brown 
[Linux commit 4e2f9c278ad84196991fcf6f6646a3e15967fe90]
[only port the DBG2 changes]
Signed-off-by: Shannon Zhao 
---
Cc: Jan Beulich 
V5: port from Linux
---
 xen/include/acpi/actbl2.h | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h
index 87bc6b3..1ad67f8 100644
--- a/xen/include/acpi/actbl2.h
+++ b/xen/include/acpi/actbl2.h
@@ -63,6 +63,7 @@
  */
 #define ACPI_SIG_ASF"ASF!" /* Alert Standard Format table */
 #define ACPI_SIG_BOOT   "BOOT" /* Simple Boot Flag Table */
+#define ACPI_SIG_DBG2   "DBG2" /* Debug Port table type 2 */
 #define ACPI_SIG_DBGP   "DBGP" /* Debug Port table */
 #define ACPI_SIG_DMAR   "DMAR" /* DMA Remapping table */
 #define ACPI_SIG_HPET   "HPET" /* High Precision Event Timer table */
@@ -232,6 +233,62 @@ struct acpi_table_boot {
 
 
/***
  *
+ * DBG2 - Debug Port Table 2
+ *Version 0 (Both main table and subtables)
+ *
+ * Conforms to "Microsoft Debug Port Table 2 (DBG2)", May 22 2012.
+ *
+ 
**/
+
+struct acpi_table_dbg2 {
+   struct acpi_table_header header;/* Common ACPI table header */
+   u32 info_offset;
+   u32 info_count;
+};
+
+/* Debug Device Information Subtable */
+
+struct acpi_dbg2_device {
+   u8 revision;
+   u16 length;
+   u8 register_count;  /* Number of base_address registers */
+   u16 namepath_length;
+   u16 namepath_offset;
+   u16 oem_data_length;
+   u16 oem_data_offset;
+   u16 port_type;
+   u16 port_subtype;
+   u16 reserved;
+   u16 base_address_offset;
+   u16 address_size_offset;
+   /*
+* Data that follows:
+*base_address (required) - Each in 12-byte Generic Address 
Structure format.
+*address_size (required) - Array of u32 sizes corresponding to 
each base_address register.
+*Namepath(required) - Null terminated string. Single dot if 
not supported.
+*oem_data(optional) - Length is oem_data_length.
+*/
+};
+
+/* Types for port_type field above */
+
+#define ACPI_DBG2_SERIAL_PORT   0x8000
+#define ACPI_DBG2_1394_PORT 0x8001
+#define ACPI_DBG2_USB_PORT  0x8002
+#define ACPI_DBG2_NET_PORT  0x8003
+
+/* Subtypes for port_subtype field above */
+
+#define ACPI_DBG2_16550_COMPATIBLE  0x
+#define ACPI_DBG2_16550_SUBSET  0x0001
+
+#define ACPI_DBG2_1394_STANDARD 0x
+
+#define ACPI_DBG2_USB_XHCI  0x
+#define ACPI_DBG2_USB_EHCI  0x0001
+
+/***
+ *
  * DBGP - Debug Port table
  *Version 1
  *
-- 
2.0.4



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

[Xen-devel] [PATCH v5 03/22] arm/acpi: Add __acpi_map_table function for ARM

[Shannon Zhao]

From: Shannon Zhao 

Implement __acpi_map_table function for ARM.

Signed-off-by: Shannon Zhao 
---
V4: add __acpi_map_table function
---
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/acpi/Makefile   |  1 +
 xen/arch/arm/acpi/lib.c  | 52 
 xen/include/asm-arm/config.h |  2 ++
 4 files changed, 56 insertions(+)
 create mode 100644 xen/arch/arm/acpi/Makefile
 create mode 100644 xen/arch/arm/acpi/lib.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1783912..6d51094 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -2,6 +2,7 @@ subdir-$(CONFIG_ARM_32) += arm32
 subdir-$(CONFIG_ARM_64) += arm64
 subdir-y += platforms
 subdir-$(CONFIG_ARM_64) += efi
+subdir-$(CONFIG_HAS_ACPI) += acpi
 
 obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += cpu.o
diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
new file mode 100644
index 000..b5be22d
--- /dev/null
+++ b/xen/arch/arm/acpi/Makefile
@@ -0,0 +1 @@
+obj-y += lib.o
diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
new file mode 100644
index 000..f817fe6
--- /dev/null
+++ b/xen/arch/arm/acpi/lib.c
@@ -0,0 +1,52 @@
+/*
+ *  lib.c - Architecture-Specific Low-Level ACPI Support
+ *
+ *  Copyright (C) 2015, Shannon Zhao 
+ *
+ * ~~
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ * ~~
+ */
+
+#include 
+#include 
+#include 
+
+char *__acpi_map_table(paddr_t phys, unsigned long size)
+{
+   unsigned long base, offset, mapped_size;
+   int idx;
+
+   offset = phys & (PAGE_SIZE - 1);
+   mapped_size = PAGE_SIZE - offset;
+   set_fixmap(FIX_ACPI_BEGIN, phys >> PAGE_SHIFT, PAGE_HYPERVISOR);
+   base = FIXMAP_ADDR(FIX_ACPI_BEGIN);
+
+   /*
+* Most cases can be covered by the below.
+*/
+   idx = FIX_ACPI_BEGIN;
+   while (mapped_size < size) {
+   if (++idx > FIX_ACPI_END)
+   return NULL;/* cannot handle this */
+   phys += PAGE_SIZE;
+   set_fixmap(idx, phys >> PAGE_SHIFT, PAGE_HYPERVISOR);
+   mapped_size += PAGE_SIZE;
+   }
+
+   return ((char *) base + offset);
+}
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index a1b968d..41dd860 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -180,6 +180,8 @@
 #define FIXMAP_GICC14  /* Interrupt controller: CPU registers (first page) 
*/
 #define FIXMAP_GICC25  /* Interrupt controller: CPU registers (second 
page) */
 #define FIXMAP_GICH 6  /* Interrupt controller: virtual interface control 
registers */
+#define FIX_ACPI_BEGIN  7  /* Start mappings of ACPI tables */
+#define FIX_ACPI_END10 /* End mappings of ACPI tables */
 
 #define PAGE_SHIFT  12
 
-- 
2.0.4



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

[Xen-devel] [PATCH v5 01/22] arm/acpi: Emulate io ports for arm

[Shannon Zhao]

From: Shannon Zhao 

Add macros to emulate x86 style ports for arm. This avoids modification in
common code for acpi. Here just print a warning on ARM.

Signed-off-by: Shannon Zhao 
---
V5: not write to the address, just print warning
V4: print warning
---
 xen/include/asm-arm/arm64/io.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/xen/include/asm-arm/arm64/io.h b/xen/include/asm-arm/arm64/io.h
index 37abc47..f80156f 100644
--- a/xen/include/asm-arm/arm64/io.h
+++ b/xen/include/asm-arm/arm64/io.h
@@ -20,6 +20,7 @@
 #ifndef _ARM_ARM64_IO_H
 #define _ARM_ARM64_IO_H
 
+#include 
 #include 
 
 /*
@@ -109,4 +110,26 @@ static inline u64 __raw_readq(const volatile void __iomem 
*addr)
 #define writel(v,c) ({ __iowmb(); writel_relaxed((v),(c)); })
 #define writeq(v,c) ({ __iowmb(); writeq_relaxed((v),(c)); })
 
+/*
+ * Emulate x86 io ports for ARM.
+ */
+static inline int emulate_read(u64 addr)
+{
+printk(XENLOG_G_WARNING "Can't access IO %lx\n", addr);
+return 0;
+}
+
+static inline void emulate_write(u64 addr)
+{
+printk(XENLOG_G_WARNING "Can't access IO %lx\n", addr);
+}
+
+#define inb(c) ( emulate_read(c) )
+#define inw(c) ( emulate_read(c) )
+#define inl(c) ( emulate_read(c) )
+
+#define outb(v, c) ( emulate_write(c) )
+#define outw(v, c) ( emulate_write(c) )
+#define outl(v, c) ( emulate_write(c) )
+
 #endif /* _ARM_ARM64_IO_H */
-- 
2.0.4



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

[Xen-devel] [PATCH v5 00/22] Add ACPI support for Xen itself on ARM64

[Shannon Zhao]

From: Shannon Zhao 

These patches are Part 3 of the previous patch set I sent which adds
ACPI support for arm64 on Xen[1]. Split them as an individual set for
convenient reviewing.

These patches mostly add ACPI support for Xen itself(not yet for Dom0)
on ARM64. It makes Xen could parse physical ACPI tables and initialize
hardwares it uses. But so far it doesn't enable ACPI since it doesn't
add support for Dom0.

See individual patch for changes.

Thanks,
Shannon
[1] http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg01831.html

Bob Moore (1):
  ACPICA: Headers: Add support for CSRT and DBG2 ACPI tables.

Hanjun Guo (1):
  ACPI / table: Print GIC information when MADT is parsed

Parth Dixit (4):
  arm/acpi: Parse MADT to map logical cpu to MPIDR and get
cpu_possible_map
  arm: Introduce a generic way to use a device from acpi
  arm/gic-v2: Add ACPI boot support for GICv2
  arm/irq: Add helper function for setting interrupt type

Shannon Zhao (16):
  arm/acpi: Emulate io ports for arm
  arm/acpi: Add arm specific acpi header file
  arm/acpi: Add __acpi_map_table function for ARM
  arm/acpi: Add basic ACPI initialization
  arm/acpi: Move end_boot_allocator after acpi_boot_table_init
  arm/acpi: Parse FADT table and get PSCI flags
  arm/acpi: Add ACPI support for SMP initialization
  acpi/table: Introduce acpi_table_get_entry_madt to get specified entry
  arm/irq: Drop the DT prefix of the irq line type
  arm/gic-v3: Add ACPI boot support for GICv3
  arm/gic: Add ACPI support for GIC preinit
  arm/acpi: Parse GTDT to initialize timer
  arm/acpi: Add a new ACPI initialized function for UART
  arm/acpi: Initialize serial port from ACPI SPCR table
  arm/fdt: Export device_tree_for_each_node
  arm/acpi: Add acpi parameter to enable/disable acpi

 xen/arch/arm/Makefile  |   1 +
 xen/arch/arm/acpi/Makefile |   2 +
 xen/arch/arm/acpi/boot.c   | 261 +
 xen/arch/arm/acpi/lib.c|  64 ++
 xen/arch/arm/arm64/smpboot.c   |   7 +-
 xen/arch/arm/bootfdt.c |   6 +-
 xen/arch/arm/device.c  |  18 +++
 xen/arch/arm/domain_build.c|  10 +-
 xen/arch/arm/gic-v2.c  | 127 +++-
 xen/arch/arm/gic-v3.c  | 179 +++-
 xen/arch/arm/gic.c |  41 ++-
 xen/arch/arm/irq.c |  35 +++---
 xen/arch/arm/psci.c|  35 --
 xen/arch/arm/setup.c   |  17 ++-
 xen/arch/arm/smpboot.c |   7 +-
 xen/arch/arm/time.c|  88 +++---
 xen/arch/arm/xen.lds.S |   7 ++
 xen/arch/x86/acpi/boot.c   |   4 -
 xen/drivers/acpi/tables.c  |  86 ++
 xen/drivers/char/arm-uart.c|  37 +-
 xen/drivers/char/pl011.c   |  37 ++
 xen/include/acpi/actbl2.h  |  62 ++
 xen/include/asm-arm/acpi.h |  55 +
 xen/include/asm-arm/arm64/io.h |  23 
 xen/include/asm-arm/config.h   |   2 +
 xen/include/asm-arm/device.h   |  30 +
 xen/include/asm-arm/irq.h  |   2 +
 xen/include/xen/acpi.h |   6 +
 xen/include/xen/device_tree.h  |  54 +
 xen/include/xen/serial.h   |   2 +-
 30 files changed, 1202 insertions(+), 103 deletions(-)
 create mode 100644 xen/arch/arm/acpi/Makefile
 create mode 100644 xen/arch/arm/acpi/boot.c
 create mode 100644 xen/arch/arm/acpi/lib.c
 create mode 100644 xen/include/asm-arm/acpi.h

-- 
2.0.4



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

[Xen-devel] [PATCH v5 13/22] arm/gic-v2: Add ACPI boot support for GICv2

[Shannon Zhao]

From: Parth Dixit 

ACPI on Xen hypervisor uses MADT table for proper GIC initialization.
First get the GIC version from GIC Distributor. Then parse GIC related
subtables, collect CPU interface and distributor addresses and call
driver initialization function (which is hardware abstraction agnostic).
In a similar way, FDT initialize GICv2.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
V5: fix coding style and simplify #else case
V4: use container_of and fix coding style
---
 xen/arch/arm/gic-v2.c | 117 +-
 1 file changed, 116 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 668b863..0fcb894 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -29,6 +29,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -36,6 +38,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * LR register definitions are GIC v2 specific.
@@ -681,11 +684,108 @@ static void __init gicv2_dt_init(void)
csize, vsize);
 }
 
+#ifdef CONFIG_ACPI
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+static int cpu_base_assigned = 0;
+struct acpi_madt_generic_interrupt *processor =
+   container_of(header, struct acpi_madt_generic_interrupt, 
header);
+
+if ( BAD_MADT_ENTRY(processor, end) )
+return -EINVAL;
+
+/* Read from APIC table and fill up the GIC variables */
+if ( cpu_base_assigned == 0 )
+{
+cbase = processor->base_address;
+csize = SZ_8K;
+hbase = processor->gich_base_address;
+vbase = processor->gicv_base_address;
+gicv2_info.maintenance_irq = processor->vgic_interrupt;
+
+if ( processor->flags & ACPI_MADT_VGIC_IRQ_MODE )
+irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_EDGE_BOTH);
+else
+irq_set_type(gicv2_info.maintenance_irq, IRQ_TYPE_LEVEL_MASK);
+
+cpu_base_assigned = 1;
+}
+else
+{
+if ( cbase != processor->base_address
+ || hbase != processor->gich_base_address
+ || vbase != processor->gicv_base_address
+ || gicv2_info.maintenance_irq != processor->vgic_interrupt )
+{
+printk("GICv2: GICC entries are not same in MADT table\n");
+return -EINVAL;
+}
+}
+
+return 0;
+}
+
+static int __init
+gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+struct acpi_madt_generic_distributor *dist =
+ container_of(header, struct acpi_madt_generic_distributor, 
header);
+
+if ( BAD_MADT_ENTRY(dist, end) )
+return -EINVAL;
+
+dbase = dist->base_address;
+
+return 0;
+}
+
+static void __init gicv2_acpi_init(void)
+{
+acpi_status status;
+struct acpi_table_header *table;
+int count;
+
+status = acpi_get_table(ACPI_SIG_MADT, 0, );
+
+if ( ACPI_FAILURE(status) )
+{
+const char *msg = acpi_format_exception(status);
+
+panic("GICv2: Failed to get MADT table, %s", msg);
+}
+
+/* Collect CPU base addresses */
+count = acpi_parse_entries(ACPI_SIG_MADT, sizeof(struct acpi_table_madt),
+   gic_acpi_parse_madt_cpu, table,
+   ACPI_MADT_TYPE_GENERIC_INTERRUPT, 0);
+if ( count <= 0 )
+panic("GICv2: No valid GICC entries exists");
+
+/*
+ * Find distributor base address. We expect one distributor entry since
+ * ACPI 5.0 spec neither support multi-GIC instances nor GIC cascade.
+ */
+count = acpi_parse_entries(ACPI_SIG_MADT, sizeof(struct acpi_table_madt),
+   gic_acpi_parse_madt_distributor, table,
+   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR, 0);
+if ( count <= 0 )
+panic("GICv2: No valid GICD entries exists");
+}
+#else
+static void __init gicv2_acpi_init(void) { }
+#endif
+
 static int __init gicv2_init(void)
 {
 uint32_t aliased_offset = 0;
 
-gicv2_dt_init();
+if ( acpi_disabled )
+gicv2_dt_init();
+else
+gicv2_acpi_init();
 
 printk("GICv2 initialization:\n"
   "gic_dist_addr=%"PRIpaddr"\n"
@@ -793,6 +893,21 @@ DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
 .init = gicv2_dt_preinit,
 DT_DEVICE_END
 
+#ifdef CONFIG_ACPI
+/* Set up the GIC */
+static int __init gicv2_acpi_preinit(const void *data)
+{
+gicv2_info.hw_version = GIC_V2;
+register_gic_ops(_ops);
+
+return 0;
+}
+
+ACPI_DEVICE_START(agicv2, "GICv2", DEVICE_GIC)
+.class_type = ACPI_MADT_GIC_VERSION_V2,
+.init = gicv2_acpi_preinit,
+ACPI_DEVICE_END
+#endif
 /*
  * 

[Xen-devel] [PATCH v5 11/22] arm: Introduce a generic way to use a device from acpi

[Shannon Zhao]

From: Parth Dixit 

Add generic way to use device from acpi similar to the way it is
supported in device tree.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Acked-by: Stefano Stabellini 
---
 xen/arch/arm/device.c| 18 ++
 xen/arch/arm/xen.lds.S   |  7 +++
 xen/include/asm-arm/device.h | 30 ++
 3 files changed, 55 insertions(+)

diff --git a/xen/arch/arm/device.c b/xen/arch/arm/device.c
index 0b53f6a..a0072c1 100644
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -22,6 +22,7 @@
 #include 
 
 extern const struct device_desc _sdevice[], _edevice[];
+extern const struct acpi_device_desc _asdevice[], _aedevice[];
 
 int __init device_init(struct dt_device_node *dev, enum device_class class,
const void *data)
@@ -50,6 +51,23 @@ int __init device_init(struct dt_device_node *dev, enum 
device_class class,
 return -EBADF;
 }
 
+int __init acpi_device_init(enum device_class class, const void *data, int 
class_type)
+{
+const struct acpi_device_desc *desc;
+
+for ( desc = _asdevice; desc != _aedevice; desc++ )
+{
+if ( ( desc->class != class ) || ( desc->class_type != class_type ) )
+continue;
+
+ASSERT(desc->init != NULL);
+
+return desc->init(data);
+}
+
+return -EBADF;
+}
+
 enum device_class device_get_class(const struct dt_device_node *dev)
 {
 const struct device_desc *desc;
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index f501a2f..1c315a9 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -104,6 +104,13 @@ SECTIONS
   _edevice = .;
   } :text
 
+  . = ALIGN(8);
+  .adev.info : {
+  _asdevice = .;
+  *(.adev.info)
+  _aedevice = .;
+  } :text
+
   . = ALIGN(PAGE_SIZE); /* Init code and data */
   __init_begin = .;
   .init.text : {
diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
index b455bdf..6734ae8 100644
--- a/xen/include/asm-arm/device.h
+++ b/xen/include/asm-arm/device.h
@@ -50,6 +50,27 @@ struct device_desc {
 int (*init)(struct dt_device_node *dev, const void *data);
 };
 
+struct acpi_device_desc {
+/* Device name */
+const char *name;
+/* Device class */
+enum device_class class;
+/* type of device supported by the driver */
+const int class_type;
+/* Device initialization */
+int (*init)(const void *data);
+};
+
+/**
+ *  acpi_device_init - Initialize a device
+ *  @class: class of the device (serial, network...)
+ *  @data: specific data for initializing the device
+ *
+ *  Return 0 on success.
+ */
+int __init acpi_device_init(enum device_class class,
+const void *data, int class_type);
+
 /**
  *  device_init - Initialize a device
  *  @dev: device to initialize
@@ -78,6 +99,15 @@ __section(".dev.info") = {   
   \
 #define DT_DEVICE_END   \
 };
 
+#define ACPI_DEVICE_START(_name, _namestr, _class)\
+static const struct acpi_device_desc __dev_desc_##_name __used   \
+__section(".adev.info") = {   \
+.name = _namestr,   \
+.class = _class,\
+
+#define ACPI_DEVICE_END   \
+};
+
 #endif /* __ASM_ARM_DEVICE_H */
 
 /*
-- 
2.0.4



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

[Xen-devel] [PATCH v5 05/22] arm/acpi: Move end_boot_allocator after acpi_boot_table_init

[Shannon Zhao]

From: Shannon Zhao 

To support ACPI NUMA, it needs to make the ACPI initialization done
before boot_end_allocator. Also, x86 does this by the same way.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
---
V5: fix the commit message
---
 xen/arch/arm/setup.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index fee5385..d4261e8 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -615,8 +615,6 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
allocator. */
 init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
pfn_to_paddr(boot_mfn_start));
-
-end_boot_allocator();
 }
 #else /* CONFIG_ARM_64 */
 static void __init setup_mm(unsigned long dtb_paddr, size_t dtb_size)
@@ -684,8 +682,6 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 
 setup_frametable_mappings(ram_start, ram_end);
 max_page = PFN_DOWN(ram_end);
-
-end_boot_allocator();
 }
 #endif
 
@@ -759,6 +755,8 @@ void __init start_xen(unsigned long boot_phys_offset,
 /* Parse the ACPI tables for possible boot-time configuration */
 acpi_boot_table_init();
 
+end_boot_allocator();
+
 vm_init();
 dt_unflatten_host_device_tree();
 
-- 
2.0.4



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

[Xen-devel] [PATCH v5 21/22] arm/fdt: Export device_tree_for_each_node

[Shannon Zhao]

From: Shannon Zhao 

This function will be used by ACPI booting. Export it so that it can be
used by other files.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
V5: remove __init from the declaration
---
 xen/arch/arm/bootfdt.c| 6 +++---
 xen/include/xen/device_tree.h | 4 
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 74d208b..8a14015 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -85,9 +85,9 @@ static u32 __init device_tree_get_u32(const void *fdt, int 
node,
  * Returns 0 if all nodes were iterated over successfully.  If @func
  * returns a value different from 0, that value is returned immediately.
  */
-static int __init device_tree_for_each_node(const void *fdt,
-device_tree_node_func func,
-void *data)
+int __init device_tree_for_each_node(const void *fdt,
+ device_tree_node_func func,
+ void *data)
 {
 int node;
 int depth;
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index cf31e50..e3fe77c 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -173,6 +173,10 @@ typedef int (*device_tree_node_func)(const void *fdt,
 
 extern const void *device_tree_flattened;
 
+int device_tree_for_each_node(const void *fdt,
+ device_tree_node_func func,
+ void *data);
+
 /**
  * dt_unflatten_host_device_tree - Unflatten the host device tree
  *
-- 
2.0.4



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

Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Fu Wei]

Hi Andrei

On 26 February 2016 at 13:24, Andrei Borzenkov  wrote:
>
>
> Отправлено с iPhone
>
>> 26 февр. 2016 г., в 7:48, Fu Wei  написал(а):
>>
>> Hi Andrei
>>
>>> On 26 February 2016 at 01:34, Andrei Borzenkov  wrote:
>>> 25.02.2016 09:39, fu@linaro.org пишет:
 From: Fu Wei 

 delete: xen_linux, xen_initrd, xen_xsm
 add: xen_module

 This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko 
Date:   Fri Jan 22 10:18:47 2016 +0100

xen_boot: Remove obsolete module type distinctions.

 Signed-off-by: Fu Wei 
 ---
 docs/grub.texi | 32 +---
 1 file changed, 9 insertions(+), 23 deletions(-)

 diff --git a/docs/grub.texi b/docs/grub.texi
 index 82f6fa4..0f99c50 100644
 --- a/docs/grub.texi
 +++ b/docs/grub.texi
 @@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
 @command{help}
 * videoinfo::   List available video modes
 @comment * xen_*::  Xen boot commands
 * xen_hypervisor::  Load xen hypervisor binary
 -* xen_linux::   Load dom0 kernel for xen hypervisor
 -* xen_initrd::  Load dom0 initrd for dom0 kernel
 -* xen_xsm:: Load xen security module for xen 
 hypervisor
 +* xen_module::  Load xen modules for xen hypervisor
 @end menu


 @@ -5141,30 +5139,18 @@ verbatim as the @dfn{kernel command-line}. Any 
 other binaries must be
 reloaded after using this command.
 @end deffn

 -@node xen_linux
 -@subsection xen_linux
 +@node xen_module
 +@subsection xen_module

 -@deffn Command xen_linux file [arguments]
 -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
 +@deffn Command xen_module [--nounzip] file [arguments]
 +Load a module for xen hypervisor at the booting process of xen.
 The rest of the line is passed verbatim as the module command line.
 +Each module will be identified by the order in which the modules are 
 added.
 +The 1st module: dom0 kernel image
 +The 2nd module: dom0 ramdisk
 +All subsequent modules: UNKNOW
 @end deffn
>>>
>>> Hmm ... from previous discussion I gathered that Xen can detect module
>>> type. What if there is no initrd for dom0? How can subsequent modules be
>>
>> Now , Xen detect module type by the order. (at least on ARM64).
>> I think i386 is using Multiboot(2) protocol, so maybe this order is
>> nothing to do with i386.
>>
>
> Then we have obvious problem with your XSM patch 
> (http://savannah.gnu.org/bugs/?43420) - XSM may land as the first module. 
> That's actually something to solve on Xen side I think. It's just that so far 
> we had just kernel and initrd, so that was non issue.

Oh, did you mean Wei Liu's patch?

I guess XSM may land as the third module (or the module after linux
kernel, if you don't have initrd)

Yes, agree. (That's actually something to solve on Xen side)

I guess xen can get xsm from a special initrd. so for now there is not
big problem on xsm.

Please correct me if I misunderstand something. :-)

Thanks!

Back to this patch, is that OK for you, or any suggestion?  Thanks !

>
>
>> so maybe we can say:
>> -
>> On ARM64, each module will be identified by the order in which the
>> modules are added.
>> The 1st module: dom0 kernel image
>> The 2nd module: dom0 ramdisk (optional)
>> All subsequent modules: UNKNOWN
>>
>> On i386,  the modules will be identified by Multiboot(2) protocol.
>> -
>>
>> Is that better?  please correct me if I miss something.
>>
>>> loaded then?
>>>
 -@node xen_initrd
 -@subsection xen_initrd
 -
 -@deffn Command xen_initrd file
 -Load a initrd image for dom0 kernel at the booting process of xen.
 -@end deffn
 -
 -@node xen_xsm
 -@subsection xen_xsm
 -
 -@deffn Command xen_xsm file
 -Load a xen security module for xen hypervisor at the booting process of 
 xen.
 -See @uref{http://wiki.xen.org/wiki/XSM} for more detail.
 -@end deffn
 -
 -
 @node Networking commands
 @section The list of networking commands
>>
>>
>>
>> --
>> Best regards,
>>
>> Fu Wei
>> Software Engineer
>> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
>> Ph: +86 21 61221326(direct)
>> Ph: +86 186 2020 4684 (mobile)
>> Room 1512, Regus One Corporate Avenue,Level 15,
>> One Corporate Avenue,222 Hubin Road,Huangpu District,
>> Shanghai,China 200021



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One 

Re: [Xen-devel] [PATCH V14 4/6] libxl: add pvusb API

[Chun Yan Liu]

>>> On 2/24/2016 at 01:10 AM, in message
, George
Dunlap  wrote: 
> On Fri, Feb 19, 2016 at 10:39 AM, Chunyan Liu  wrote: 
> > Add pvusb APIs, including: 
> > - attach/detach (create/destroy) virtual usb controller. 
> > - attach/detach usb device 
> > - list usb controller and usb devices 
> > - some other helper functions 
> > 
> > Signed-off-by: Simon Cao  
> > Signed-off-by: George Dunlap  
> > Signed-off-by: Chunyan Liu  
> > --- 
> > changes: 
> >   Address Olaf's comments: 
> >   * move DEFINE_DEVICE_REMOVE changes to a separate patch 
> >   Address Ian's comments: 
> >   * adjust order of removing xenstore and bind/unbind driver in usb_remove. 
> >   * reuse libxl_write_exactly in usbintf_bind/unbind 
> >   * several coding style fix 
>  
> [snip] 
>  
> > +/* Unbind USB device from "usbback" driver. 
> > + * 
> > + * If there are many interfaces under USB device, check each interface, 
> > + * unbind from "usbback" driver and rebind to its original driver. 
> > + */ 
> > +static int usbback_dev_unassign(libxl__gc *gc, const char *busid) 
> > +{ 
> > +char **intfs = NULL; 
> > +char *usbdev_encode = NULL; 
> > +char *path = NULL; 
> > +int i, num = 0; 
> > +int rc; 
> > + 
> > +rc = usbdev_get_all_interfaces(gc, busid, , ); 
> > +if (rc) goto out; 
> > + 
> > +usbdev_encode = usb_interface_xenstore_encode(gc, busid); 
> > + 
> > +for (i = 0; i < num; i++) { 
> > +char *intf = intfs[i]; 
> > +char *usbintf_encode = NULL; 
> > +const char *drvpath; 
> > + 
> > +/* check if the USB interface is already bound to "usbback" */ 
> > +if (usbintf_is_assigned(gc, intf) > 0) { 
> > +/* unbind interface from usbback driver */ 
> > +rc = unbind_usbintf(gc, intf); 
> > +if (rc) { 
> > +LOGE(ERROR, "Couldn't unbind %s from usbback", intf); 
> > +goto out; 
> > +} 
> > +} 
> > + 
> > +/* rebind USB interface to its originial driver */ 
> > +usbintf_encode = usb_interface_xenstore_encode(gc, intf); 
> > +path = GCSPRINTF(USBBACK_INFO_PATH "/%s/%s/driver_path", 
> > + usbdev_encode, usbintf_encode); 
> > +rc = libxl__xs_read_checked(gc, XBT_NULL, path, ); 
> > +if (rc) goto out; 
> > + 
> > +if (drvpath) { 
> > +rc = bind_usbintf(gc, intf, drvpath); 
> > +if (rc) { 
> > +LOGE(ERROR, "Couldn't rebind %s to %s", intf, drvpath); 
> > +goto out; 
> > +} 
> > +} 
> > +} 
>  
> So I see below that you're calling this before removing things from 
> xenstore, so that if any of these fail, the user can still call "xl 
> usb-remove" to retry. 
>  
> Unfortunately, since you reassign interfaces to the original driver 
> before all interfaces are de-assigned from usbback, you can end up in 
> a situation where the device is partially re-plugged into the original 
> drivers, partially still assigned to pciback. 
>  
> I think this whole process should be three steps: 
>  
> 1. Unassign all interfaces from usbback, stopping and returning an 
> error as soon as one attempt fails 
>  
> 2. Remove the pvusb xenstore nodes (stopping and returning an error if it  
> fails) 
>  
> 3. Attempt to re-assign all interfaces to the original drivers, 
> stopping and returning an error as soon as one attempt fails. 
>  
> And in the case of #3, the log message should give a suggestion as to 
> what might help; for instance, "Couldn't rebind USB device to driver 
> [driver name].  Reloading the module may help."  (I think you should 
> be able to get the driver name from the path, right?) 

Yes, that's right.

>  
> A couple of properties this gives us: 
>  
> * If the un-assign partially succeeds, the user can re-try the unassign 
>  
> * If one of the re-assignments fail, then the user will have to reload 
> the drivers, reboot, or mess around with sysfs to fix things. 
> *However*, this avoids a scenario where a user is completely unable to 
> remove a device from a domain because of a buggy driver. 

To guest or host, this situation that some interface is bound to pciback
but some is to original driver, is indeed a mess. But to toolstack, it can
still have chance to redo 'xl usbdev-remove' to retry the left work (unassign
interfaces those bound to pciback, and reassign to original interface).

>  
> What do you think? 

The 3 steps above are indeed more reasonable. Codes need to be
reorganized (previously doing unassingn_form_pciback and rebind to
original driver in a same cycle for each interface, now will be split into
two separate processes: walk through each interface to do
unassign_from_pciback, and walk through each interface to rebind to
original 

[Xen-devel] [xen-unstable test] 83979: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen3 host-install(3) broken REGR. vs. 83855
 test-amd64-amd64-libvirt-vhd  3 host-install(3) broken REGR. vs. 83855
 test-amd64-i386-xl3 host-install(3) broken REGR. vs. 83855
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 83855
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 83855

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 83855
 build-amd64-rumpuserxen   6 xen-buildfail   like 83855
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 83855
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 83855
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 83855
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 83855

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

version targeted for testing:
 xen  27b74b9283722dd71a7f0915efd4238f65f8f5c3
baseline version:
 xen  998110fe9b758b51173609fb033dbe03b8de0a01

Last test of basis83855  2016-02-24 13:26:39 Z1 days
Testing same since83979  2016-02-25 14:35:49 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  Doug Goldstein 
  George Dunlap 
  Huaitong Han 
  Jan Beulich 
  Juergen Gross 
  Konrad Rzeszutek Wilk 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Andrei Borzenkov]

Отправлено с iPhone

> 26 февр. 2016 г., в 7:48, Fu Wei  написал(а):
> 
> Hi Andrei
> 
>> On 26 February 2016 at 01:34, Andrei Borzenkov  wrote:
>> 25.02.2016 09:39, fu@linaro.org пишет:
>>> From: Fu Wei 
>>> 
>>> delete: xen_linux, xen_initrd, xen_xsm
>>> add: xen_module
>>> 
>>> This update bases on
>>>commit 0edd750e50698854068358ea53528100a9192902
>>>Author: Vladimir Serbinenko 
>>>Date:   Fri Jan 22 10:18:47 2016 +0100
>>> 
>>>xen_boot: Remove obsolete module type distinctions.
>>> 
>>> Signed-off-by: Fu Wei 
>>> ---
>>> docs/grub.texi | 32 +---
>>> 1 file changed, 9 insertions(+), 23 deletions(-)
>>> 
>>> diff --git a/docs/grub.texi b/docs/grub.texi
>>> index 82f6fa4..0f99c50 100644
>>> --- a/docs/grub.texi
>>> +++ b/docs/grub.texi
>>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
>>> @command{help}
>>> * videoinfo::   List available video modes
>>> @comment * xen_*::  Xen boot commands
>>> * xen_hypervisor::  Load xen hypervisor binary
>>> -* xen_linux::   Load dom0 kernel for xen hypervisor
>>> -* xen_initrd::  Load dom0 initrd for dom0 kernel
>>> -* xen_xsm:: Load xen security module for xen hypervisor
>>> +* xen_module::  Load xen modules for xen hypervisor
>>> @end menu
>>> 
>>> 
>>> @@ -5141,30 +5139,18 @@ verbatim as the @dfn{kernel command-line}. Any 
>>> other binaries must be
>>> reloaded after using this command.
>>> @end deffn
>>> 
>>> -@node xen_linux
>>> -@subsection xen_linux
>>> +@node xen_module
>>> +@subsection xen_module
>>> 
>>> -@deffn Command xen_linux file [arguments]
>>> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
>>> +@deffn Command xen_module [--nounzip] file [arguments]
>>> +Load a module for xen hypervisor at the booting process of xen.
>>> The rest of the line is passed verbatim as the module command line.
>>> +Each module will be identified by the order in which the modules are added.
>>> +The 1st module: dom0 kernel image
>>> +The 2nd module: dom0 ramdisk
>>> +All subsequent modules: UNKNOW
>>> @end deffn
>> 
>> Hmm ... from previous discussion I gathered that Xen can detect module
>> type. What if there is no initrd for dom0? How can subsequent modules be
> 
> Now , Xen detect module type by the order. (at least on ARM64).
> I think i386 is using Multiboot(2) protocol, so maybe this order is
> nothing to do with i386.
> 

Then we have obvious problem with your XSM patch 
(http://savannah.gnu.org/bugs/?43420) - XSM may land as the first module. 
That's actually something to solve on Xen side I think. It's just that so far 
we had just kernel and initrd, so that was non issue.


> so maybe we can say:
> -
> On ARM64, each module will be identified by the order in which the
> modules are added.
> The 1st module: dom0 kernel image
> The 2nd module: dom0 ramdisk (optional)
> All subsequent modules: UNKNOWN
> 
> On i386,  the modules will be identified by Multiboot(2) protocol.
> -
> 
> Is that better?  please correct me if I miss something.
> 
>> loaded then?
>> 
>>> -@node xen_initrd
>>> -@subsection xen_initrd
>>> -
>>> -@deffn Command xen_initrd file
>>> -Load a initrd image for dom0 kernel at the booting process of xen.
>>> -@end deffn
>>> -
>>> -@node xen_xsm
>>> -@subsection xen_xsm
>>> -
>>> -@deffn Command xen_xsm file
>>> -Load a xen security module for xen hypervisor at the booting process of 
>>> xen.
>>> -See @uref{http://wiki.xen.org/wiki/XSM} for more detail.
>>> -@end deffn
>>> -
>>> -
>>> @node Networking commands
>>> @section The list of networking commands
> 
> 
> 
> -- 
> Best regards,
> 
> Fu Wei
> Software Engineer
> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
> Ph: +86 21 61221326(direct)
> Ph: +86 186 2020 4684 (mobile)
> Room 1512, Regus One Corporate Avenue,Level 15,
> One Corporate Avenue,222 Hubin Road,Huangpu District,
> Shanghai,China 200021

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

Re: [Xen-devel] [PATCH v6][RFC]xen: sched: convert RTDS from time to event driven model

[Tianyang Chen]

On 2/25/2016 6:31 PM, Dario Faggioli wrote:

Hey again,

Thanks for turning up so quickly.

We are getting closer and closer, although (of course :-)) I have some
more comments.

However, is there a particular reason why you are keeping the RFC tag?
Until you do that, it's like saying that you are chasing feedback, but
you do not think yourself the patch should be considered for being
upstreamed. As far as my opinion goes, this patch is not ready to go in
right now (as I said, I've got questions and comments), but its status
is way past RFC.



Oh OK, I had the impression that RFC means request for comments and it 
should always be used because indeed, I'm asking for comments.



On Thu, 2016-02-25 at 15:05 -0500, Tianyang Chen wrote:

changes since v5:
 removed unnecessary vcpu_on_replq() checks
 deadline_queue_insert() returns a flag to indicate if it's
 needed to re-program the timer
 removed unnecessary timer checks
 added helper functions to remove vcpus from queues
 coding style

Changes since v4:
 removed unnecessary replenishment queue checks in vcpu_wake()
 extended replq_remove() to all cases in vcpu_sleep()
 used _deadline_queue_insert() helper function for both queues
 _replq_insert() and _replq_remove() program timer internally

Changes since v3:
 removed running queue.
 added repl queue to keep track of repl events.
 timer is now per scheduler.
 timer is init on a valid cpu in a cpupool.


So, this does not belong here. It is ok to have it in this part of the
email, but it should not land in the actual commit changelog, once the
patch will be committed into Xen's git tree.

The way to achieve the above is to put this summary of changes below
the actual changelog, and below the Signed-of-by lines, after a marker
that looks like this "---".


Budget replenishment and enforcement are separated by adding
a replenishment timer, which fires at the next most imminent
release time of all runnable vcpus.

A new runningq has been added to keep track of all vcpus that
are on pcpus.


Mmm.. Is this the proper changelog? runningq is something we discussed,
and that appeared in v2, but is certainly no longer here... :-O



oops...


Wait, maybe you misunderstood and/or I did not make myself clear enough
(in which case, sorry). I never meant to say "always stop the timer".
Atually, in one of my last email I said the opposite, and I think that
would be the best thing to do.

Do you think there is any specific reason why we need to always stop
and restart it? If not, I think we can:
  - have deadline_queue_remove() also return whether the element
removed was the first one (i.e., the one the timer was programmed
after);
  - if it was, re-program the timer after the new front of the queue;
  - if it wasn't, nothing to do.

Thoughts?



It was my thought originally that the timer needs to be re-programmed 
only when the top vcpu is taken off. So did you mean when I manipulated 
repl_timer->expires manually, the timer should be stopped using proper 
timer API? The manipulation is gone now. Also, set_timer internally 
disables the timer so I assume it's safe just to call set_timer() 
directly, right?



@@ -405,22 +500,38 @@ __runq_insert(const struct scheduler *ops,
struct rt_vcpu *svc)

  /* add svc to runq if svc still has budget */
  if ( svc->cur_budget > 0 )
-{
-list_for_each(iter, runq)
-{
-struct rt_vcpu * iter_svc = __q_elem(iter);
-if ( svc->cur_deadline <= iter_svc->cur_deadline )
-break;
- }
-list_add_tail(>q_elem, iter);
-}
+deadline_queue_insert(&__q_elem, svc, >q_elem, runq);
  else
  {
  list_add(>q_elem, >depletedq);
+ASSERT( __vcpu_on_replq(svc) );


So, by doing this, you're telling me that, if the vcpu is added to the
depleted queue, there must be a replenishment planned for it (or the
ASSERT() would fail).

But if we are adding it to the runq, there may or may not be a
replenishment planned for it.

Is this what we want? Why there must not be a replenishment planned
already for a vcpu going into the runq (to happen at its next
deadline)?



It looks like the current code doesn't add a vcpu to the replenishment 
queue when vcpu_insert() is called. When the scheduler is initialized, 
all the vcpus are added to the replenishment queue after waking up from 
sleep. This needs to be changed (add vcpu to replq in vcpu_insert()) to 
make it consistent in a sense that when rt_vcpu_insert() is called, it 
needs to have a corresponding replenishment event queued.


This way the ASSERT() is for both cases in __runq_insert() to enforce 
the fact that "when a vcpu is inserted to runq/depletedq, a 
replenishment event is waiting for it".



@@ -1087,10 +1193,6 @@ static void
  rt_context_saved(const struct scheduler *ops, struct vcpu *vc)
  {
  struct rt_vcpu *svc = rt_vcpu(vc);
-struct rt_vcpu *snext = NULL;
-  

Re: [Xen-devel] Patching error while setting up COLO

[Changlong Xie]

On 02/26/2016 12:55 PM, Yu-An(Victor) Chen wrote:

Hi Changlong,

Are you suggesting I should hold off on setting up COLO for now?



No, just following my steps.

Thanks
-Xie


Thanks!

Victor

On Thu, Feb 25, 2016 at 8:19 PM, Changlong Xie 
wrote:


On 02/26/2016 11:38 AM, Yu-An(Victor) Chen wrote:


Hi Changlong,

Thanks for the reply!

So I am trying to follow your new instructions, but when I am trying to do
this:

   cd ~/colo-proxy/; git checkout 405527cbfa9f

I got the following error:

"error: pathspec '405527cbfa9f' did not match any file(s) known to git."

I assume it is just a typo? Thank you!



Hi victor

Please git clone
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Pating_colo-2Dproxy_tree_changlox=CwICaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=pCAkg_8tEQmGEZZoUlyePZjK7z-6aEmp-n6UrQRLWo4=Ww-EAIszC-zQuVcDc4XpigwVbMG_4t2SpTg2PV6HTjM=
*Notice* that, currently we implement colo proxy as a kernel module what
is a temporary measure. But further more we'll intergrate it in qemu and
drop this one, so both qemu-colo and xen-colo will share the same proxy.
Please don't test this colo proxy now, there maybe some bugs, but it's
acceptable.

Thanks
 -Xie



Victor













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

[Xen-devel] [Question] PARSEC benchmark has smaller execution time in VM than in native?

[Meng Xu]

Hi,

We are measuring the execution time between native machine environment
and xen virtualization environment using PARSEC Benchmark [1].

In virtualiztion environment, we run a domU with three VCPUs, each of
them pinned to a core; we pin the dom0 to another core that is not
used by the domU.

Inside the Linux in domU in virtualization environment and in native
environment,  We used the cpuset to isolate a core (or VCPU) for the
system processors and to isolate a core for the benchmark processes.
We also configured the Linux boot command line with isocpus= option to
isolate the core for benchmark from other unnecessary processes.

We expect that execution time of benchmarks in xen virtualization
environment is larger than the execution time in native machine
environment. However, the evaluation gave us an opposite result.

Below is the evaluation data for the canneal and streamcluster benchmarks:

Benchmark: canneal, input=simlarge, conf=gcc-serial
Native: 6.387s
Virtualization: 5.890s

Benchmark: streamcluster, input=simlarge, conf=gcc-serial
Native: 5.276s
Virtualization: 5.240s

Is there anything wrong with our evaluation that lead to the abnormal
performance results?

Any suggestion or advice is really appreciated.

Thank you very much for your time on this question!

Best regards,

Meng

[1] http://parsec.cs.princeton.edu/


---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Fu Wei]

Hi Doug,

On 26 February 2016 at 06:26, Doug Goldstein  wrote:
> On 2/25/16 12:39 AM, fu@linaro.org wrote:
>> From: Fu Wei 
>> -@deffn Command xen_linux file [arguments]
>> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
>> +@deffn Command xen_module [--nounzip] file [arguments]
>> +Load a module for xen hypervisor at the booting process of xen.
>>  The rest of the line is passed verbatim as the module command line.
>> +Each module will be identified by the order in which the modules are added.
>> +The 1st module: dom0 kernel image
>> +The 2nd module: dom0 ramdisk
>> +All subsequent modules: UNKNOW
>
> Missing an 'N' at the end there. Probably worth mentioning that the
> ramdisk is optional as well.

Thanks for correction, will fix it.


>
> --
> Doug Goldstein
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Fu Wei]

Hi Andrei

On 26 February 2016 at 12:48, Fu Wei  wrote:
> Hi Andrei
>
> On 26 February 2016 at 01:34, Andrei Borzenkov  wrote:
>> 25.02.2016 09:39, fu@linaro.org пишет:
>>> From: Fu Wei 
>>>
>>> delete: xen_linux, xen_initrd, xen_xsm
>>> add: xen_module
>>>
>>> This update bases on
>>> commit 0edd750e50698854068358ea53528100a9192902
>>> Author: Vladimir Serbinenko 
>>> Date:   Fri Jan 22 10:18:47 2016 +0100
>>>
>>> xen_boot: Remove obsolete module type distinctions.
>>>
>>> Signed-off-by: Fu Wei 
>>> ---
>>>  docs/grub.texi | 32 +---
>>>  1 file changed, 9 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/docs/grub.texi b/docs/grub.texi
>>> index 82f6fa4..0f99c50 100644
>>> --- a/docs/grub.texi
>>> +++ b/docs/grub.texi
>>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
>>> @command{help}
>>>  * videoinfo::   List available video modes
>>>  @comment * xen_*::  Xen boot commands
>>>  * xen_hypervisor::  Load xen hypervisor binary
>>> -* xen_linux::   Load dom0 kernel for xen hypervisor
>>> -* xen_initrd::  Load dom0 initrd for dom0 kernel
>>> -* xen_xsm:: Load xen security module for xen hypervisor
>>> +* xen_module::  Load xen modules for xen hypervisor
>>>  @end menu
>>>
>>>
>>> @@ -5141,30 +5139,18 @@ verbatim as the @dfn{kernel command-line}. Any 
>>> other binaries must be
>>>  reloaded after using this command.
>>>  @end deffn
>>>
>>> -@node xen_linux
>>> -@subsection xen_linux
>>> +@node xen_module
>>> +@subsection xen_module
>>>
>>> -@deffn Command xen_linux file [arguments]
>>> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
>>> +@deffn Command xen_module [--nounzip] file [arguments]
>>> +Load a module for xen hypervisor at the booting process of xen.
>>>  The rest of the line is passed verbatim as the module command line.
>>> +Each module will be identified by the order in which the modules are added.
>>> +The 1st module: dom0 kernel image
>>> +The 2nd module: dom0 ramdisk
>>> +All subsequent modules: UNKNOW
>>>  @end deffn
>>>
>>
>> Hmm ... from previous discussion I gathered that Xen can detect module
>> type. What if there is no initrd for dom0? How can subsequent modules be

The problem is (on ARM64) if  there is no initrd for dom0, then the
second module loaded
will be treated as  ramdisk.  Maybe  we need to mention that?

>
> Now , Xen detect module type by the order. (at least on ARM64).
> I think i386 is using Multiboot(2) protocol, so maybe this order is
> nothing to do with i386.
>
> so maybe we can say:
> -
> On ARM64, each module will be identified by the order in which the
> modules are added.
> The 1st module: dom0 kernel image
> The 2nd module: dom0 ramdisk (optional)
> All subsequent modules: UNKNOWN
>
> On i386,  the modules will be identified by Multiboot(2) protocol.
> -
>
> Is that better?  please correct me if I miss something.
>
>> loaded then?
>>
>>> -@node xen_initrd
>>> -@subsection xen_initrd
>>> -
>>> -@deffn Command xen_initrd file
>>> -Load a initrd image for dom0 kernel at the booting process of xen.
>>> -@end deffn
>>> -
>>> -@node xen_xsm
>>> -@subsection xen_xsm
>>> -
>>> -@deffn Command xen_xsm file
>>> -Load a xen security module for xen hypervisor at the booting process of 
>>> xen.
>>> -See @uref{http://wiki.xen.org/wiki/XSM} for more detail.
>>> -@end deffn
>>> -
>>> -
>>>  @node Networking commands
>>>  @section The list of networking commands
>>>
>>>
>>
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
> Ph: +86 21 61221326(direct)
> Ph: +86 186 2020 4684 (mobile)
> Room 1512, Regus One Corporate Avenue,Level 15,
> One Corporate Avenue,222 Hubin Road,Huangpu District,
> Shanghai,China 200021



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

On 26 February 2016 at 12:48, Fu Wei  wrote:
> Hi Andrei
>
> On 26 February 2016 at 01:34, Andrei Borzenkov  wrote:
>> 25.02.2016 09:39, fu@linaro.org пишет:
>>> From: Fu Wei 
>>>
>>> delete: xen_linux, xen_initrd, xen_xsm
>>> add: xen_module
>>>
>>> This update bases on
>>> commit 0edd750e50698854068358ea53528100a9192902
>>> Author: Vladimir Serbinenko 
>>> Date:   Fri Jan 22 10:18:47 2016 +0100
>>>
>>> xen_boot: Remove obsolete module type distinctions.
>>>
>>> Signed-off-by: Fu Wei 
>>> ---
>>>  docs/grub.texi | 32 +---
>>>  1 

Re: [Xen-devel] Patching error while setting up COLO

[Yu-An(Victor) Chen]

Hi Changlong,

Are you suggesting I should hold off on setting up COLO for now?

Thanks!

Victor

On Thu, Feb 25, 2016 at 8:19 PM, Changlong Xie 
wrote:

> On 02/26/2016 11:38 AM, Yu-An(Victor) Chen wrote:
>
>> Hi Changlong,
>>
>> Thanks for the reply!
>>
>> So I am trying to follow your new instructions, but when I am trying to do
>> this:
>>
>>   cd ~/colo-proxy/; git checkout 405527cbfa9f
>>
>> I got the following error:
>>
>> "error: pathspec '405527cbfa9f' did not match any file(s) known to git."
>>
>> I assume it is just a typo? Thank you!
>>
>
> Hi victor
>
> Please git clone
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Pating_colo-2Dproxy_tree_changlox=CwICaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=pCAkg_8tEQmGEZZoUlyePZjK7z-6aEmp-n6UrQRLWo4=Ww-EAIszC-zQuVcDc4XpigwVbMG_4t2SpTg2PV6HTjM=
> *Notice* that, currently we implement colo proxy as a kernel module what
> is a temporary measure. But further more we'll intergrate it in qemu and
> drop this one, so both qemu-colo and xen-colo will share the same proxy.
> Please don't test this colo proxy now, there maybe some bugs, but it's
> acceptable.
>
> Thanks
> -Xie
>
>
>> Victor
>>
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Fu Wei]

Hi Andrei

On 26 February 2016 at 01:34, Andrei Borzenkov  wrote:
> 25.02.2016 09:39, fu@linaro.org пишет:
>> From: Fu Wei 
>>
>> delete: xen_linux, xen_initrd, xen_xsm
>> add: xen_module
>>
>> This update bases on
>> commit 0edd750e50698854068358ea53528100a9192902
>> Author: Vladimir Serbinenko 
>> Date:   Fri Jan 22 10:18:47 2016 +0100
>>
>> xen_boot: Remove obsolete module type distinctions.
>>
>> Signed-off-by: Fu Wei 
>> ---
>>  docs/grub.texi | 32 +---
>>  1 file changed, 9 insertions(+), 23 deletions(-)
>>
>> diff --git a/docs/grub.texi b/docs/grub.texi
>> index 82f6fa4..0f99c50 100644
>> --- a/docs/grub.texi
>> +++ b/docs/grub.texi
>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
>> @command{help}
>>  * videoinfo::   List available video modes
>>  @comment * xen_*::  Xen boot commands
>>  * xen_hypervisor::  Load xen hypervisor binary
>> -* xen_linux::   Load dom0 kernel for xen hypervisor
>> -* xen_initrd::  Load dom0 initrd for dom0 kernel
>> -* xen_xsm:: Load xen security module for xen hypervisor
>> +* xen_module::  Load xen modules for xen hypervisor
>>  @end menu
>>
>>
>> @@ -5141,30 +5139,18 @@ verbatim as the @dfn{kernel command-line}. Any other 
>> binaries must be
>>  reloaded after using this command.
>>  @end deffn
>>
>> -@node xen_linux
>> -@subsection xen_linux
>> +@node xen_module
>> +@subsection xen_module
>>
>> -@deffn Command xen_linux file [arguments]
>> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
>> +@deffn Command xen_module [--nounzip] file [arguments]
>> +Load a module for xen hypervisor at the booting process of xen.
>>  The rest of the line is passed verbatim as the module command line.
>> +Each module will be identified by the order in which the modules are added.
>> +The 1st module: dom0 kernel image
>> +The 2nd module: dom0 ramdisk
>> +All subsequent modules: UNKNOW
>>  @end deffn
>>
>
> Hmm ... from previous discussion I gathered that Xen can detect module
> type. What if there is no initrd for dom0? How can subsequent modules be

Now , Xen detect module type by the order. (at least on ARM64).
I think i386 is using Multiboot(2) protocol, so maybe this order is
nothing to do with i386.

so maybe we can say:
-
On ARM64, each module will be identified by the order in which the
modules are added.
The 1st module: dom0 kernel image
The 2nd module: dom0 ramdisk (optional)
All subsequent modules: UNKNOWN

On i386,  the modules will be identified by Multiboot(2) protocol.
-

Is that better?  please correct me if I miss something.

> loaded then?
>
>> -@node xen_initrd
>> -@subsection xen_initrd
>> -
>> -@deffn Command xen_initrd file
>> -Load a initrd image for dom0 kernel at the booting process of xen.
>> -@end deffn
>> -
>> -@node xen_xsm
>> -@subsection xen_xsm
>> -
>> -@deffn Command xen_xsm file
>> -Load a xen security module for xen hypervisor at the booting process of xen.
>> -See @uref{http://wiki.xen.org/wiki/XSM} for more detail.
>> -@end deffn
>> -
>> -
>>  @node Networking commands
>>  @section The list of networking commands
>>
>>
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

Re: [Xen-devel] [PATCH v5 6/6] docs: Add descriptions of TSC scaling in xl.cfg and tscmode.txt

[Zhang, Haozhong]

On 02/26/16 12:37, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Tuesday, February 23, 2016 10:05 AM
> > 
> > Signed-off-by: Haozhong Zhang 
> 
> Reviewed-by: Kevin Tian , except:
> 
> > +
> > +Hardware TSC Scaling
> > +
> > +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read
> > +by guest rdtsc/p increasing in a different frequency than the host
> > +TSC frequency.
> > +
> > +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode
> 
> 'HVM container' means something different. We usually use "HVM domain"
> as you may see in other places in this doc.
>

I'll change to 'HVM domain'.

Thanks,
Haozhong

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

Re: [Xen-devel] [PATCH v5 6/6] docs: Add descriptions of TSC scaling in xl.cfg and tscmode.txt

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Tuesday, February 23, 2016 10:05 AM
> 
> Signed-off-by: Haozhong Zhang 

Reviewed-by: Kevin Tian , except:

> +
> +Hardware TSC Scaling
> +
> +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read
> +by guest rdtsc/p increasing in a different frequency than the host
> +TSC frequency.
> +
> +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode

'HVM container' means something different. We usually use "HVM domain"
as you may see in other places in this doc.

Thanks
Kevin

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

Re: [Xen-devel] [PATCH v5 5/6] vmx: Add VMX RDTSC(P) scaling support

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Tuesday, February 23, 2016 10:05 AM
> 
> This patch adds the initialization and setup code for VMX TSC scaling.
> 
> Signed-off-by: Haozhong Zhang 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v5 3/6] x86/hvm: Replace architecture TSC scaling by a common function

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Tuesday, February 23, 2016 10:05 AM
> 
> This patch implements a common function hvm_scale_tsc() to scale TSC by
> using TSC scaling information collected by architecture code.
> 
> Signed-off-by: Haozhong Zhang 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v5 1/6] x86/hvm: Collect information of TSC scaling ratio

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Tuesday, February 23, 2016 10:05 AM
> 
> Both VMX TSC scaling and SVM TSC ratio use the 64-bit TSC scaling ratio,
> but the number of fractional bits of the ratio is different between VMX
> and SVM. This patch adds the architecture code to collect the number of
> fractional bits and other related information into fields of struct
> hvm_function_table so that they can be used in the common code.
> 
> Signed-off-by: Haozhong Zhang 

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH] docs/design: introduce HVMMEM_ioreq_serverX types

[Tian, Kevin]

> From: Paul Durrant
> Sent: Thursday, February 25, 2016 11:49 PM
> 
> This patch adds a new 'designs' subdirectory under docs as a repository
> for this and future design proposals.
> 
> Signed-off-by: Paul Durrant 
> ---
> 
> For convenience this document can also be viewed in PDF at:
> 
> http://xenbits.xen.org/people/pauldu/hvmmem_ioreq_server.pdf
> ---
>  docs/designs/hvmmem_ioreq_server.md | 63
> +
>  1 file changed, 63 insertions(+)
>  create mode 100755 docs/designs/hvmmem_ioreq_server.md
> 
> diff --git a/docs/designs/hvmmem_ioreq_server.md
> b/docs/designs/hvmmem_ioreq_server.md
> new file mode 100755
> index 000..47fa715
> --- /dev/null
> +++ b/docs/designs/hvmmem_ioreq_server.md
> @@ -0,0 +1,63 @@
> +HVMMEM\_ioreq\_serverX
> +--
> +
> +Background
> +==
> +
> +The concept of the IOREQ server was introduced to allow multiple distinct
> +device emulators to a single VM. The XenGT project uses an IOREQ server to
> +provide mediated pass-through of Intel GPUs to guests and, as part of the
> +mediation, needs to intercept accesses to GPU page-tables (or GTTs) that
> +reside in guest RAM.
> +
> +The current implementation of this sets the type of GTT pages to type
> +HVMMEM\_mmio\_write\_dm, which causes Xen to emulate writes to such pages,
> +and then maps the guest physical addresses of those pages to the XenGT
> +IOREQ server using the HVMOP\_map\_io\_range\_to\_ioreq\_server hypercall.
> +However, because the number of GTTs is potentially large, using this
> +approach does not scale well.
> +
> +Proposal
> +
> +
> +Because the number of spare types available in the P2M type-space is
> +currently very limited it is proposed that HVMMEM\_mmio\_write\_dm be
> +replaced by a single new type HVMMEM\_ioreq\_server. In future, if the
> +P2M type-space is increased, this can be renamed to HVMMEM\_ioreq\_server0
> +and new HVMMEM\_ioreq\_server1, HVMMEM\_ioreq\_server2, etc. types
> +can be added.
> +
> +Accesses to a page of type HVMMEM\_ioreq\_serverX should be the same as
> +HVMMEM\_ram\_rw until the type is _claimed_ by an IOREQ server. Furthermore
> +it should only be possible to set the type of a page to
> +HVMMEM\_ioreq\_serverX if that page is currently of type HVMMEM\_ram\_rw.

Is there similar assumption on the opposite change, i.e. from ioreq_serverX
only to ram_rw?

> +
> +To allow an IOREQ server to claim or release a claim to a type a new pair
> +of hypercalls will be introduced:
> +
> +- HVMOP\_map\_mem\_type\_to\_ioreq\_server
> +- HVMOP\_unmap\_mem\_type\_from\_ioreq\_server
> +
> +and an associated argument structure:
> +
> + struct hvm_ioreq_mem_type {
> + domid_t domid;  /* IN - domain to be serviced */
> + ioservid_t id;  /* IN - server id */
> + hvmmem_type_t type; /* IN - memory type */
> + uint32_t flags; /* IN - types of access to be
> + intercepted */
> +
> + #define _HVMOP_IOREQ_MEM_ACCESS_READ 0
> + #define HVMOP_IOREQ_MEM_ACCESS_READ \
> + (1 << _HVMOP_IOREQ_MEM_ACCESS_READ)
> +
> + #define _HVMOP_IOREQ_MEM_ACCESS_WRITE 1
> + #define HVMOP_IOREQ_MEM_ACCESS_WRITE \
> + (1 << _HVMOP_IOREQ_MEM_ACCESS_WRITE)
> +
> + };
> +
> +
> +Once the type has been claimed then the requested types of access to any
> +page of the claimed type will be passed to the IOREQ server for handling.
> +Only HVMMEM\_ioreq\_serverX types may be claimed.
> --

It'd good to also add how to handle multiple ioreq servers claiming
one same type for a given domain.

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

Re: [Xen-devel] Patching error while setting up COLO

[Changlong Xie]

On 02/26/2016 11:38 AM, Yu-An(Victor) Chen wrote:

Hi Changlong,

Thanks for the reply!

So I am trying to follow your new instructions, but when I am trying to do
this:

  cd ~/colo-proxy/; git checkout 405527cbfa9f

I got the following error:

"error: pathspec '405527cbfa9f' did not match any file(s) known to git."

I assume it is just a typo? Thank you!


Hi victor

Please git clone https://github.com/Pating/colo-proxy/tree/changlox

*Notice* that, currently we implement colo proxy as a kernel module what 
is a temporary measure. But further more we'll intergrate it in qemu and 
drop this one, so both qemu-colo and xen-colo will share the same proxy. 
Please don't test this colo proxy now, there maybe some bugs, but it's 
acceptable.


Thanks
-Xie



Victor




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

Re: [Xen-devel] [PATCH v2] vVMX: use latched VMCS machine address

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, February 25, 2016 7:58 PM
> 
> Instead of calling domain_page_map_to_mfn() over and over, latch the
> guest VMCS machine address unconditionally (i.e. independent of whether
> VMCS shadowing is supported by the hardware).
> 
> Since this requires altering the parameters of __[gs]et_vmcs{,_real}()
> (and hence all their callers) anyway, take the opportunity to also drop
> the bogus double underscores from their names (and from
> __[gs]et_vmcs_virtual() as well).
> 
> Signed-off-by: Jan Beulich 
> Tested-by: Liang Z Li 

Acked-by: Kevin Tian 

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

[Xen-devel] [PATCH 3/4] build: convert HAS_NUMA to Kconfig

[Doug Goldstein]

Convert HAS_NUMA to Kconfig as CONFIG_NUMA and let CONFIG_NUMA be
defined by Kconfig.

Signed-off-by: Doug Goldstein 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
---
 xen/arch/x86/Kconfig | 1 +
 xen/arch/x86/Rules.mk| 1 -
 xen/drivers/acpi/Kconfig | 3 +++
 xen/drivers/acpi/Makefile| 2 +-
 xen/include/asm-x86/config.h | 1 -
 5 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 6343b0b..1e663e3 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -18,6 +18,7 @@ config X86
select HAS_PASSTHROUGH
select HAS_PCI
select HAS_PDX
+select NUMA
select VGA
 
 config ARCH_DEFCONFIG
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 14519e3..c1fff66 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,7 +1,6 @@
 
 # x86-specific definitions
 
-HAS_NUMA := y
 HAS_CORE_PARKING := y
 
 CFLAGS += -I$(BASEDIR)/include 
diff --git a/xen/drivers/acpi/Kconfig b/xen/drivers/acpi/Kconfig
index 1edcca7..9688b97 100644
--- a/xen/drivers/acpi/Kconfig
+++ b/xen/drivers/acpi/Kconfig
@@ -5,3 +5,6 @@ config ACPI
 
 config ACPI_LEGACY_TABLES_LOOKUP
bool
+
+config NUMA
+bool
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
index fb6dfc3..444b11d 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -3,7 +3,7 @@ subdir-y += utilities
 subdir-$(CONFIG_X86) += apei
 
 obj-bin-y += tables.init.o
-obj-$(HAS_NUMA) += numa.o
+obj-$(CONFIG_NUMA) += numa.o
 obj-y += osl.o
 obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o
 
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 0fb9839..dd1d4aa 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -24,7 +24,6 @@
 #define CONFIG_HPET_TIMER 1
 #define CONFIG_X86_MCE_THERMAL 1
 #define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 1
-#define CONFIG_NUMA 1
 #define CONFIG_DISCONTIGMEM 1
 #define CONFIG_NUMA_EMU 1
 #define CONFIG_DOMAIN_PAGE 1
-- 
2.4.10


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

[Xen-devel] [PATCH 4/4] build: convert HAS_CORE_PARKING to Kconfig

[Doug Goldstein]

Convert HAS_CORE_PARKING to Kconfig as CONFIG_CORE_PARKING. While
removing HAS_CORE_PARKING, removed a trailing whitespace on a near by
line.

Signed-off-by: Doug Goldstein 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
---
 xen/arch/x86/Kconfig  | 1 +
 xen/arch/x86/Rules.mk | 4 +---
 xen/common/Kconfig| 3 +++
 xen/common/Makefile   | 2 +-
 4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 1e663e3..435587e 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -6,6 +6,7 @@ config X86
select ACPI
select ACPI_LEGACY_TABLES_LOOKUP
select COMPAT
+   select CORE_PARKING
select HAS_CPUFREQ
select HAS_EHCI
select HAS_GDBSX
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index c1fff66..3139886 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,9 +1,7 @@
 
 # x86-specific definitions
 
-HAS_CORE_PARKING := y
-
-CFLAGS += -I$(BASEDIR)/include 
+CFLAGS += -I$(BASEDIR)/include
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
 CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst 
$(BASEDIR)/,,$(CURDIR))/$@))'
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index a1097ef..d1e6359 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -8,6 +8,9 @@ config COMPAT
  HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective
  of the destination runmode of the guest.
 
+config CORE_PARKING
+bool
+
 config FLASK
bool "FLux Advanced Security Kernel support"
default y
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 57f4ed7..82625a5 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,5 +1,5 @@
 obj-y += bitmap.o
-obj-$(HAS_CORE_PARKING) += core_parking.o
+obj-$(CONFIG_CORE_PARKING) += core_parking.o
 obj-y += cpu.o
 obj-y += cpupool.o
 obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o
-- 
2.4.10


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

[Xen-devel] [PATCH 1/4] build: consolidate CONFIG_HAS_VIDEO and CONFIG_VIDEO

[Doug Goldstein]

No real advantage to keeping these separate. The use case of this from
Linux is when the platform or target board has support for something but
the user wants to be given the option to disable it.

Signed-off-by: Doug Goldstein 
---
CC: Ian Campbell 
CC: Stefano Stabellini 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
---
 xen/arch/arm/Kconfig | 2 +-
 xen/drivers/Makefile | 2 +-
 xen/drivers/video/Kconfig| 6 +++---
 xen/drivers/video/Makefile   | 8 
 xen/include/asm-arm/config.h | 2 --
 xen/include/asm-x86/config.h | 2 --
 6 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 60e923c..cb99df5 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -22,7 +22,7 @@ config ARM
select HAS_MEM_ACCESS
select HAS_PASSTHROUGH
select HAS_PDX
-   select HAS_VIDEO
+   select VIDEO
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index 7bbb654..ec2b8f2 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -3,4 +3,4 @@ subdir-$(CONFIG_HAS_CPUFREQ) += cpufreq
 subdir-$(CONFIG_HAS_PCI) += pci
 subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough
 subdir-$(CONFIG_HAS_ACPI) += acpi
-subdir-$(CONFIG_HAS_VIDEO) += video
+subdir-$(CONFIG_VIDEO) += video
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 03e1e18..739fe6f 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -1,12 +1,12 @@
 
-# Select HAS_VIDEO if video is supported
-config HAS_VIDEO
+# Select VIDEO if video is supported
+config VIDEO
bool
 
 # Select VGA if VGA is supported
 config VGA
bool
-   select HAS_VIDEO
+   select VIDEO
 
 # Select HAS_ARM_HDLCD if ARM HDLCD is supported
 config HAS_ARM_HDLCD
diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile
index fab7aba..2bb91d6 100644
--- a/xen/drivers/video/Makefile
+++ b/xen/drivers/video/Makefile
@@ -1,7 +1,7 @@
 obj-$(CONFIG_VGA) := vga.o
-obj-$(CONFIG_HAS_VIDEO) += font_8x14.o
-obj-$(CONFIG_HAS_VIDEO) += font_8x16.o
-obj-$(CONFIG_HAS_VIDEO) += font_8x8.o
-obj-$(CONFIG_HAS_VIDEO) += lfb.o
+obj-$(CONFIG_VIDEO) += font_8x14.o
+obj-$(CONFIG_VIDEO) += font_8x16.o
+obj-$(CONFIG_VIDEO) += font_8x8.o
+obj-$(CONFIG_VIDEO) += lfb.o
 obj-$(CONFIG_VGA) += vesa.o
 obj-$(CONFIG_HAS_ARM_HDLCD) += arm_hdlcd.o
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index c3a2c30..43ecfb4 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -32,8 +32,6 @@
 
 #define CONFIG_SMP 1
 
-#define CONFIG_VIDEO 1
-
 #define CONFIG_IRQ_HAS_MULTIPLE_ACTION 1
 
 #define CONFIG_PAGEALLOC_MAX_ORDER 18
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index 3274337..ca303b6 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -43,8 +43,6 @@
 #define CONFIG_ACPI_SRAT 1
 #define CONFIG_ACPI_CSTATE 1
 
-#define CONFIG_VIDEO 1
-
 #define CONFIG_WATCHDOG 1
 
 #define CONFIG_MULTIBOOT 1
-- 
2.4.10


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

[Xen-devel] [PATCH 2/4] build: consolidate CONFIG_HAS_ACPI and CONFIG_ACPI

[Doug Goldstein]

No real advantage to keeping these separate. The use case of this from
Linux is when the platform or target board has support for something but
the user wants to be given the option to disable it.

Signed-off-by: Doug Goldstein 
---
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
---
 xen/arch/x86/Kconfig | 2 +-
 xen/common/sysctl.c  | 2 +-
 xen/drivers/Makefile | 2 +-
 xen/drivers/acpi/Kconfig | 4 ++--
 xen/include/asm-x86/config.h | 1 -
 5 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index ce70794..6343b0b 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -3,9 +3,9 @@ config X86_64
 
 config X86
def_bool y
+   select ACPI
select ACPI_LEGACY_TABLES_LOOKUP
select COMPAT
-   select HAS_ACPI
select HAS_CPUFREQ
select HAS_EHCI
select HAS_GDBSX
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 1624024..58162f5 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -171,7 +171,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 op->u.availheap.avail_bytes <<= PAGE_SHIFT;
 break;
 
-#if defined (CONFIG_HAS_ACPI) && defined (CONFIG_HAS_CPUFREQ)
+#if defined (CONFIG_ACPI) && defined (CONFIG_HAS_CPUFREQ)
 case XEN_SYSCTL_get_pmstat:
 ret = do_get_pm_info(>u.get_pmstat);
 break;
diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
index ec2b8f2..1939180 100644
--- a/xen/drivers/Makefile
+++ b/xen/drivers/Makefile
@@ -2,5 +2,5 @@ subdir-y += char
 subdir-$(CONFIG_HAS_CPUFREQ) += cpufreq
 subdir-$(CONFIG_HAS_PCI) += pci
 subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough
-subdir-$(CONFIG_HAS_ACPI) += acpi
+subdir-$(CONFIG_ACPI) += acpi
 subdir-$(CONFIG_VIDEO) += video
diff --git a/xen/drivers/acpi/Kconfig b/xen/drivers/acpi/Kconfig
index 82d73ca..1edcca7 100644
--- a/xen/drivers/acpi/Kconfig
+++ b/xen/drivers/acpi/Kconfig
@@ -1,6 +1,6 @@
 
-# Select HAS_ACPI if ACPI is supported
-config HAS_ACPI
+# Select ACPI if ACPI is supported
+config ACPI
bool
 
 config ACPI_LEGACY_TABLES_LOOKUP
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index ca303b6..0fb9839 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -36,7 +36,6 @@
 /* Intel P4 currently has largest cache line (L2 line size is 128 bytes). */
 #define CONFIG_X86_L1_CACHE_SHIFT 7
 
-#define CONFIG_ACPI 1
 #define CONFIG_ACPI_BOOT 1
 #define CONFIG_ACPI_SLEEP 1
 #define CONFIG_ACPI_NUMA 1
-- 
2.4.10


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

[Xen-devel] [PATCH 0/4] handful of Kconfig changes

[Doug Goldstein]

Mostly just simplification, consolidation, and more conversion. The
last two were entries added while the original series was in the last
steps of review so they just needed to be finished up.

Doug Goldstein (4):
  build: consolidate CONFIG_HAS_VIDEO and CONFIG_VIDEO
  build: consolidate CONFIG_HAS_ACPI and CONFIG_ACPI
  build: convert HAS_NUMA to Kconfig
  build: convert HAS_CORE_PARKING to Kconfig

 xen/arch/arm/Kconfig | 2 +-
 xen/arch/x86/Kconfig | 4 +++-
 xen/arch/x86/Rules.mk| 5 +
 xen/common/Kconfig   | 3 +++
 xen/common/Makefile  | 2 +-
 xen/common/sysctl.c  | 2 +-
 xen/drivers/Makefile | 4 ++--
 xen/drivers/acpi/Kconfig | 7 +--
 xen/drivers/acpi/Makefile| 2 +-
 xen/drivers/video/Kconfig| 6 +++---
 xen/drivers/video/Makefile   | 8 
 xen/include/asm-arm/config.h | 2 --
 xen/include/asm-x86/config.h | 4 
 13 files changed, 25 insertions(+), 26 deletions(-)

-- 
2.4.10


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

Re: [Xen-devel] Patching error while setting up COLO

[Yu-An(Victor) Chen]

Hi Changlong,

Thanks for the reply!

So I am trying to follow your new instructions, but when I am trying to do
this:

 cd ~/colo-proxy/; git checkout 405527cbfa9f

I got the following error:

"error: pathspec '405527cbfa9f' did not match any file(s) known to git."

I assume it is just a typo? Thank you!

Victor

On Thu, Feb 25, 2016 at 2:31 AM, Ian Campbell 
wrote:

> On Thu, 2016-02-25 at 16:49 +0800, Changlong Xie wrote:
> > Sorry for this. Since we have no privilege to update the Wiki for a long
> > time so most contents of this page are dated : (
>
> Anyone can be granted access, it is only a manual process because of
> spammers. Please create an account and then fill in the form at:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__xenproject.org_component_content_article_100-2Dmisc_145-2Drequest-2Dto-2Dbe-2Dmade-2Da-2Dwiki-2Deditor.html=CwIFaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw=81rG3g_B23OhGxLWYNA7Hs6cFJy4VxE2Sdqhr0qe7Ds=
>
> >
> > Anyway i'll write down detail steps here for colo on XEN.
> >
> > [Requirements]
> > - Hardware
> > There is at least one directly connected nic to forward the network
> > requests from primary to secondary vm. The directly connected nic must
> > not be used by any other purpose. If your guest has more than one nic,
> > you should have directly connected nic for each guest nic. If you don't
> > have enouth directly connected nic, you can use vlan.
> >
> > - Dom0
> > 1. Kernel with dom0 support
> > 2. kernel module
> > nf_conntrack
> > nf_conntrack_ipv4
> > nf_nat
> > libnl-tools >= 3.0.
> > *Note*: If your host os has OEM-released xen tools, *MUST* uninstall it
> > first.
> >
> > - Guest
> > Only HVM guest(without pv extensions) is supported now. If you want to
> > use OEM released guest os, please use SUSE（we use "SUSE Linux
> > Enterprise Server 11" currently）. REDHAT and Ubuntu is not supported
> > now because I don't find any way to disable pv extensions. If you want
> > to use REDHAT or Ubuntu, you need to build the newest kernel which has
> > the parameter xen_nopv.
> >
> >
> > [SETUP]
> > - Network link topology
> > ref:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.xenproject.org_wiki_COLO-5F-2D-5FCoarse-5FGrain-5FLock-5FStepping=CwIFaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw=-vAQ55Sl3YGAa0EmRYKB2pvrRVa_D6nLQCNiOGz7IeI=
> >
> > -  Test environment prepare
> >
> > On both Primary/Secondary hosts:
> > 1.
> > cd ~
> > git clone
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wencongyang_colo-2Dproxy=CwIFaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw=uS-WmNmGEeeyytonbMxBCcbSHRzQJXUa6_pvkiGEPh4=
> > git clone
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_macrosheep_iptables.git=CwIFaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw=ZycjXRwwoyK_M8zU4CS8QsVaLWXzjx8mwtlEEIRlY_I=
> > git clone
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_torvalds_linux=CwIFaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw=TeB7X5i8Ua7jemThOaxH4oNER5ZMCcs1dyqUxZVIWPY=
> > git clone
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wencongyang_qemu-2Dcolo=CwIFaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw=2kSeFd9-e3hISEJ1QZB1uzfVs8TxQwFQ_Rt4EuySfu8=
> > git clone
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wencongyang_xen=CwIFaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw=ztSkYn_Z-t4_vnCdkHl09RzW8LaD9nnkeebyhac3a_0=
> >
> > 2. Prepare host kernel for Dom0
> > colo-proxy kernel module need cooperate with linux kernel. You should
> > patch kernel with ~/colo-proxy/colo-patch-for-kernel.patch
> > 1) cd ~/colo-proxy/; git checkout 405527cbfa9f
> > 2) cd ~/linux/; git checkout v4.0; git am
> > ~/colo-proxy/colo-patch-for-kernel.patch
> > 3) cp /boot/config-3.0.76-0.11-xen  .config; make menuconfig to config
> > your kernel support Dom0.
> > Ref:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.xenproject.org_wiki_Mainline-5FLinux-5FKernel-5FConfigs=CwIFaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=IitX1U91-NhsQt0q4MJOLQ=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw=3A6be8ZmUe1yTPFuGHZp3fD_LAtyo_5MW2jdVrBSDcs=
> > 4) make -j8; make modules_install; make install
> > 5) reboot
> >
> > 3. build colo-proxy
> > 1) cd ~/colo-proxy/; git checkout 405527cbfa9f; make; make install
> >
> > 4. build iptables
> > 1) cd iptables; ./autogen.sh; ./configure --prefix=/usr/
> > --libdir=/usr/lib64; make; make install
> >
> > 5. build qemu-colo
> > 1) cd ~/qemu-colo/; git checkout 

Re: [Xen-devel] [PATCH] docs: spell out limits of security support for qemu-xen

[Doug Goldstein]

On 2/25/16 9:43 AM, Stefano Stabellini wrote:

> +++ b/docs/misc/qemu-xen-security
> @@ -0,0 +1,20 @@
> +qemu-xen (git://xenbits.xen.org/qemu-xen.git) is only supported for
> +security fixes when used together with the Xen hypervisor and only with
> +a subset of all the possible QEMU emulators. Specifically:

So I'll get my comments on paper here rather than something just
mentioned on IRC. This is exactly why the Xen team should be pushing to
remove as many "in-tree" items as possible. The security surface area of
Xen is huge and statements like this help the CYA factor they don't
completely eliminate the problems of manpower of having to check against
different upstreams if a vulnerability affects you or downstreams doing
something bad causing a security issue for users which ultimately gets
blamed on Xen. There are then further complications where sometimes the
version shipped by Xen isn't an upstream release and so there may be
other vulnerabilities above and beyond what upstream announces.

I urge the Xen maintainers to make it a goal to remove external
libraries and applications (like qemu-xen) from the tree entirely and
recommend the use of the upstream release. I know the concern is testing
but it involves calling out your dependencies just like you do any other
dependency. (e.g. Xen X.Y requires QEMU A.B.C, no guarantees are made
about the compatibility of other versions)

I know Stefano is making an effort with this with Project Raisin and
really that should become the embraced way to stand up a "full" Xen
system from source rather than a hodge podge collection of packages that
are fetched by the Xen build system. This will bring the how developers
use the source packages closer with how many users of distros use Xen
(e.g. a number of distros use upstream QEMU releases instead of qemu-xen).

-- 
Doug Goldstein



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

Re: [Xen-devel] Patching error while setting up COLO

[Changlong Xie]

On 02/25/2016 06:31 PM, Ian Campbell wrote:

Sorry for this. Since we have no privilege to update the Wiki for a long
>time so most contents of this page are dated : (

Anyone can be granted access, it is only a manual process because of
spammers. Please create an account and then fill in the form at:
http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html



Sound good to me.

Thanks
-Xie

>
>Anyway i'll write down detail steps here for colo on XEN.
>




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

Re: [Xen-devel] [PATCH v10 21/31] libxc/save: support COLO save

[Wen Congyang]

On 02/25/2016 11:58 PM, Wei Liu wrote:
> On Mon, Feb 22, 2016 at 10:52:25AM +0800, Wen Congyang wrote:
> [...]
>>  /*
>>   * Suspend the domain and send dirty memory.
>>   * This is the last iteration of the live migration and the
>> @@ -558,6 +610,16 @@ static int suspend_and_send_dirty(struct xc_sr_context 
>> *ctx)
>>  
>>  bitmap_or(dirty_bitmap, ctx->save.deferred_pages, ctx->save.p2m_size);
>>  
>> +if ( !ctx->save.live && ctx->save.checkpointed == MIG_STREAM_COLO )
>> +{
>> +rc = merge_secondary_dirty_bitmap(ctx);
>> +if ( rc )
>> +{
>> +PERROR("Failed to get secondary vm's dirty pages");
>> +goto out;
>> +}
>> +}
>> +
>>  rc = send_dirty_pages(ctx, stats.dirty_count + 
>> ctx->save.nr_deferred_pages);
>>  if ( rc )
>>  goto out;
>> @@ -791,13 +853,42 @@ static int save(struct xc_sr_context *ctx, uint16_t 
>> guest_type)
>>  if ( rc )
>>  goto err;
>>  
>> -rc = ctx->save.callbacks->postcopy(ctx->save.callbacks->data);
>> -if ( rc <= 0 )
>> -goto err;
>> +if ( ctx->save.checkpointed == MIG_STREAM_COLO )
>> +{
>> +rc = 
>> ctx->save.callbacks->checkpoint(ctx->save.callbacks->data);
>> +if ( !rc )
>> +{
>> +rc = -1;
>> +goto err;
>> +}
>> +}
>>  
>> -rc = ctx->save.callbacks->checkpoint(ctx->save.callbacks->data);
>> -if ( rc <= 0 )
>> +rc = ctx->save.callbacks->postcopy(ctx->save.callbacks->data);
>> +if ( !rc )
> 
> This original code for checking postcopy return value is if ( rc <= 0 ).

OK, I will check it.

Thanks
Wen Congyang

> 
> Wei.
> 
> 
> .
> 




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

Re: [Xen-devel] [PATCH v10 18/31] libxc/restore: support COLO restore

[Wen Congyang]

On 02/25/2016 11:57 PM, Wei Liu wrote:
> On Mon, Feb 22, 2016 at 10:52:22AM +0800, Wen Congyang wrote:
> [...]
>> - * With Remus, we buffer the records sent by the primary at checkpoint,
>> + * With Remus/COLO, we buffer the records sent by the primary at checkpoint,
>>   * in case the primary will fail, we can recover from the last
>>   * checkpoint state.
>>   * This should be enough for most of the cases because primary only send
>> diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
>> index aef9bca..2ae8154 100644
>> --- a/tools/libxc/xc_sr_restore.c
>> +++ b/tools/libxc/xc_sr_restore.c
>> @@ -460,6 +460,49 @@ static int handle_checkpoint(struct xc_sr_context *ctx)
>>  else
>>  ctx->restore.buffer_all_records = true;
>>  
>> +if ( ctx->restore.checkpointed == MIG_STREAM_COLO )
>> +{
>> +#define HANDLE_CALLBACK_RETURN_VALUE(ret)   \
>> +do {\
>> +if ( ret == 1 ) \
>> +rc = 0; /* Success */   \
>> +else\
>> +{   \
>> +if ( ret == 2 ) \
>> +rc = BROKEN_CHANNEL;\
>> +else\
>> +rc = -1; /* Some unspecified error */   \
>> +goto err;   \
>> +}   \
>> +} while (0)
>> +
>> +/* COLO */
>> +
>> +/* We need to resume guest */
>> +rc = ctx->restore.ops.stream_complete(ctx);
>> +if ( rc )
>> +goto err;
>> +
>> +/* TODO: call restore_results */
>> +
>> +/* Resume secondary vm */
>> +ret = 
>> ctx->restore.callbacks->postcopy(ctx->restore.callbacks->data);
>> +HANDLE_CALLBACK_RETURN_VALUE(ret);
>> +
>> +/* Wait for a new checkpoint */
>> +ret = ctx->restore.callbacks->wait_checkpoint(
>> +
>> ctx->restore.callbacks->data);
>> +HANDLE_CALLBACK_RETURN_VALUE(ret);
>> +
>> +/* suspend secondary vm */
>> +ret = ctx->restore.callbacks->suspend(ctx->restore.callbacks->data);
>> +HANDLE_CALLBACK_RETURN_VALUE(ret);
>> +
>> +#undef HANDLE_CALLBACK_RETURN_VALUE
>> +
>> +/* TODO: send dirty pfn list to primary */
> 
> You replace the TODOs with actual code in the next two patches.
> 
> You can rearrange them a bit so that you don't need to add TODOs at all.

Yes, will fix it in the next version.

Thanks
Wen Congyang

> 
> 
> Wei.
> 
> 
> .
> 




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

Re: [Xen-devel] [PATCH v10 17/31] primary vm suspend/resume/checkpoint code

[Wen Congyang]

On 02/25/2016 11:57 PM, Wei Liu wrote:
> On Mon, Feb 22, 2016 at 10:52:21AM +0800, Wen Congyang wrote:
> [...]
>> +#include "libxl_osdeps.h" /* must come before any other headers */
>> +
>> +#include "libxl_internal.h"
>> +#include "libxl_colo.h"
>> +
>> +static const libxl__checkpoint_device_instance_ops *colo_ops[] = {
>> +NULL,
>> +};
>> +
>> +/* = helper functions = */
>> +static int init_device_subkind(libxl__checkpoint_devices_state *cds)
>> +{
>> +/* init device subkind-specific state in the libxl ctx */
>> +int rc;
>> +STATE_AO_GC(cds->ao);
>> +
>> +rc = 0;
>> +return rc;
>> +}
>> +
>> +static void cleanup_device_subkind(libxl__checkpoint_devices_state *cds)
>> +{
>> +/* cleanup device subkind-specific state in the libxl ctx */
>> +STATE_AO_GC(cds->ao);
>> +}
>> +
>> +/* = colo: setup save environment = */
>> +static void colo_save_setup_done(libxl__egc *egc,
>> + libxl__checkpoint_devices_state *cds,
>> + int rc);
>> +static void colo_save_setup_failed(libxl__egc *egc,
>> +   libxl__checkpoint_devices_state *cds,
>> +   int rc);
>> +static void libxl__colo_save_domain_suspend_callback(void *data);
>> +static void libxl__colo_save_domain_checkpoint_callback(void *data);
>> +static void libxl__colo_save_domain_resume_callback(void *data);
>> +static void libxl__colo_save_domain_wait_checkpoint_callback(void *data);
>> +
> 
> 
> An ordered list of callbacks is appreciated. This doesn't seem to cover
> all callbacks and I'm not sure if this is the order they are supposed to
> fire either.

OK, I will check it and fix it in the next version.

Thanks
Wen Congyang

> 
> Wei.
> 
> 
> .
> 




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

Re: [Xen-devel] [PATCH v10 16/31] secondary vm suspend/resume/checkpoint code

[Wen Congyang]

On 02/25/2016 11:56 PM, Wei Liu wrote:
> On Mon, Feb 22, 2016 at 10:52:20AM +0800, Wen Congyang wrote:
>> Secondary vm is running in colo mode. So we will do
>> the following things again and again:
>> 1. Resume secondary vm
>>a. Send CHECKPOINT_SVM_READY to master.
>>b. If it is not the first resume, call 
>> libxl__checkpoint_devices_preresume().
>>c. If it is the first resume(resume right after live migration),
>>   - call libxl__xc_domain_restore_done() to build the secondary vm.
>>   - enable secondary vm's logdirty.
>>   - call libxl__domain_resume() to resume secondary vm.
>>   - call libxl__checkpoint_devices_setup() to setup checkpoint devices.
>>d. Send CHECKPOINT_SVM_RESUMED to master.
>> 2. Wait a new checkpoint
>>a. Call libxl__checkpoint_devices_commit().
>>b. Read CHECKPOINT_NEW from master.
>> 3. Suspend secondary vm
>>a. Suspend secondary vm.
>>b. Call libxl__checkpoint_devices_postsuspend().
>>c. Send CHECKPOINT_SVM_SUSPENDED to master.
>>
>> Signed-off-by: Wen Congyang 
>> Signed-off-by: Yang Hongyang 
>> ---
>>  tools/libxc/xc_sr_common.h   |2 +
>>  tools/libxc/xc_sr_save.c |3 +-
>>  tools/libxl/Makefile |1 +
>>  tools/libxl/libxl_colo.h |   24 +
>>  tools/libxl/libxl_colo_restore.c | 1038 
>> ++
>>  tools/libxl/libxl_create.c   |   37 ++
>>  tools/libxl/libxl_internal.h |   19 +
>>  tools/libxl/libxl_save_callout.c |7 +-
>>  tools/libxl/libxl_stream_read.c  |   12 +
>>  tools/libxl/libxl_types.idl  |1 +
> 
> There is a bunch of TODOs in libxl_colo.c but I don't think you're in a
> better position to judge whether they should be blocker or not.
> 
>>  10 files changed, 1142 insertions(+), 2 deletions(-)
>>  create mode 100644 tools/libxl/libxl_colo.h
>>  create mode 100644 tools/libxl/libxl_colo_restore.c
>>
>> diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
>> index 5d9f497..2bfed64 100644
>> --- a/tools/libxc/xc_sr_common.h
>> +++ b/tools/libxc/xc_sr_common.h
>> @@ -184,10 +184,12 @@ struct xc_sr_context
>>   * migration stream
>>   * 0: Plain VM
>>   * 1: Remus
>> + * 2: COLO
>>   */
>>  enum {
>>  MIG_STREAM_NONE, /* plain stream */
>>  MIG_STREAM_REMUS,
>> +MIG_STREAM_COLO,
>>  } migration_stream;
>>  
>>  union /* Common save or restore data. */
>> diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
>> index fe210cc..7393355 100644
>> --- a/tools/libxc/xc_sr_save.c
>> +++ b/tools/libxc/xc_sr_save.c
>> @@ -846,7 +846,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, 
>> uint32_t dom,
>>  
>>  /* If altering migration_stream update this assert too. */
>>  assert(checkpointed_stream == MIG_STREAM_NONE ||
>> -   checkpointed_stream == MIG_STREAM_REMUS);
>> +   checkpointed_stream == MIG_STREAM_REMUS ||
>> +   checkpointed_stream == MIG_STREAM_COLO);
>>  
>>  /*
>>   * TODO: Find some time to better tweak the live migration algorithm.
> 
> [...]
> 
>> +
>> +#include "libxl_osdeps.h" /* must come before any other headers */
>> +
>> +#include "libxl_internal.h"
>> +#include "libxl_colo.h"
>> +#include "libxl_sr_stream_format.h"
>> +
>> +enum {
>> +LIBXL_COLO_SETUPED,
>> +LIBXL_COLO_SUSPENDED,
>> +LIBXL_COLO_RESUMED,
>> +};
>> +
>> +typedef struct libxl__colo_restore_checkpoint_state 
>> libxl__colo_restore_checkpoint_state;
>> +struct libxl__colo_restore_checkpoint_state {
>> +libxl__domain_suspend_state dsps;
>> +libxl__logdirty_switch lds;
>> +libxl__colo_restore_state *crs;
>> +libxl__stream_write_state sws;
>> +int status;
>> +bool preresume;
>> +/* used for teardown */
>> +int teardown_devices;
>> +int saved_rc;
>> +char *state_file;
>> +
>> +void (*callback)(libxl__egc *,
>> + libxl__colo_restore_checkpoint_state *,
>> + int);
>> +};
>> +
> 
> Shouldn't the enum and struct belong to libxl_colo.h ?

It only be used by restore side. I think it is OK to move them to libxl_colo.h.

> 
>> +
>> +static void libxl__colo_restore_domain_resume_callback(void *data);
>> +static void libxl__colo_restore_domain_checkpoint_callback(void *data);
>> +static void libxl__colo_restore_domain_wait_checkpoint_callback(void *data);
>> +static void libxl__colo_restore_domain_suspend_callback(void *data);
>> +
>> +static const libxl__checkpoint_device_instance_ops *colo_restore_ops[] = {
>> +NULL,
>> +};
>> +
> 
> It would be helpful to list the callbacks at the beginning of the time
> in the order they are supposed to occur.
> 
> See libxl_create.c for example. Search for "Event callbacks, in this
> order".

OK, will fix it in the next version.

> 
> I've tried to map the algorithm you described in commit message to all
> the callbacks, but without some references it is just 

Re: [Xen-devel] [PATCH v10 12/31] tools/libxl: add back channel support to read stream

[Wen Congyang]

On 02/25/2016 11:54 PM, Wei Liu wrote:
> On Mon, Feb 22, 2016 at 10:52:16AM +0800, Wen Congyang wrote:
>> This is used by primay to read records sent by secondary.
>>
>> Signed-off-by: Yang Hongyang 
>> Signed-off-by: Wen Congyang 
>> ---
>>  tools/libxl/libxl_create.c  |  1 +
>>  tools/libxl/libxl_internal.h|  1 +
>>  tools/libxl/libxl_stream_read.c | 27 +++
>>  3 files changed, 25 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
>> index 525bf85..fc746fb 100644
>> --- a/tools/libxl/libxl_create.c
>> +++ b/tools/libxl/libxl_create.c
>> @@ -1030,6 +1030,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
>>  dcs->srs.dcs = dcs;
>>  dcs->srs.fd = restore_fd;
>>  dcs->srs.legacy = (dcs->restore_params.stream_version == 1);
>> +dcs->srs.back_channel = false;
>>  dcs->srs.completion_callback = domcreate_stream_done;
>>  
>>  if (restore_fd >= 0) {
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index cdf6751..32957ca 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
>> @@ -3420,6 +3420,7 @@ struct libxl__stream_read_state {
>>  libxl__domain_create_state *dcs;
>>  int fd;
>>  bool legacy;
>> +bool back_channel;
>>  void (*completion_callback)(libxl__egc *egc,
>>  libxl__stream_read_state *srs,
>>  int rc);
>> diff --git a/tools/libxl/libxl_stream_read.c 
>> b/tools/libxl/libxl_stream_read.c
>> index f4781eb..02a2c46 100644
>> --- a/tools/libxl/libxl_stream_read.c
>> +++ b/tools/libxl/libxl_stream_read.c
>> @@ -118,6 +118,15 @@
>>   *record, and therefore the buffered state is inconsistent. In
>>   *libxl__xc_domain_restore_done(), we just complete the stream and
>>   *stream->completion_callback() will be called to resume the guest
>> + *
>> + * For back channel stream:
>> + * - libxl__stream_read_start()
>> + *- Set up the stream to running state
>> + *
>> + * - libxl__stream_read_continue()
>> + * - Set up reading the next record from a started stream.
>> + *   Add some codes to process_record() to handle the record.
>> + *   Then call stream->checkpoint_callback() to return.
>>   */
>>  
>>  /* Success/error/cleanup handling. */
>> @@ -221,6 +230,17 @@ void libxl__stream_read_start(libxl__egc *egc,
>>  stream->running = true;
>>  stream->phase   = SRS_PHASE_NORMAL;
>>  
>> +dc->ao   = stream->ao;
>> +dc->copywhat = "restore v2 stream";
>> +dc->writefd  = -1;
>> +
>> +if (stream->back_channel) {
>> +assert(!stream->legacy);
>> +
>> +dc->readfd = stream->fd;
> 
> Why is this needed? dc->readfd is set to stream->fd no matter it is back
> channel or not. This can be moved outside this if {}.

Yes, will fix it in the next version.

> 
>> +return;
>> +}
>> +
>>  if (stream->legacy) {
>>  /* Convert the legacy stream. */
>>  libxl__conversion_helper_state *chs = >chs;
>> @@ -243,10 +263,7 @@ void libxl__stream_read_start(libxl__egc *egc,
>>  }
>>  /* stream->fd is now a v2 stream. */
>>  
>> -dc->ao   = stream->ao;
>> -dc->copywhat = "restore v2 stream";
>>  dc->readfd   = stream->fd;
>> -dc->writefd  = -1;
>>  
>>  /* Start reading the stream header. */
>>  rc = setup_read(stream, "stream header",
>> @@ -762,7 +779,9 @@ static void stream_done(libxl__egc *egc,
>>  LIBXL_STAILQ_FOREACH_SAFE(rec, >record_queue, entry, trec)
>>  free_record(rec);
>>  
>> -check_all_finished(egc, stream, rc);
>> +if (!stream->back_channel)
>> +/* back channel stream doesn't have restore helper */
>> +check_all_finished(egc, stream, rc);
> 
> Even if it doesn't have restore helper, check_all_finished also checks
> if the stream and the conversion helper are till in use.  The
> explanation in the comment doesn't seem to justify this change.

In stream_done(), stream->running is set to false, so 
libxl__stream_read_in_use()
returns false.

Back channel stream doesn't support legacy stream, so there is no conversion 
helper.

I will update the comments in the next version.

Thanks
Wen Congyang

> 
> Wei.
> 
>>  }
>>  
>>  void libxl__xc_domain_restore_done(libxl__egc *egc, void *dcs_void,
>> -- 
>> 2.5.0
>>
>>
>>
>>
>> ___
>> 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 v10 10/31] tools/libxl: add back channel support to write stream

[Wen Congyang]

On 02/25/2016 11:54 PM, Wei Liu wrote:
> On Mon, Feb 22, 2016 at 10:52:14AM +0800, Wen Congyang wrote:
>> Add back channel support to write stream. If the write stream is
>> a back channel stream, this means the write stream is used by
>> Secondary to send some records back.
>>
>> Signed-off-by: Yang Hongyang 
>> Signed-off-by: Wen Congyang 
>> ---
>>  tools/libxl/libxl_dom_save.c |  1 +
>>  tools/libxl/libxl_internal.h |  1 +
>>  tools/libxl/libxl_stream_write.c | 26 --
>>  3 files changed, 22 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
>> index 72b61c7..18946c5 100644
>> --- a/tools/libxl/libxl_dom_save.c
>> +++ b/tools/libxl/libxl_dom_save.c
>> @@ -404,6 +404,7 @@ void libxl__domain_save(libxl__egc *egc, 
>> libxl__domain_save_state *dss)
>>  dss->sws.ao  = dss->ao;
>>  dss->sws.dss = dss;
>>  dss->sws.fd  = dss->fd;
>> +dss->sws.back_channel = false;
>>  dss->sws.completion_callback = stream_done;
>>  
>>  libxl__stream_write_start(egc, >sws);
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index 3d3e8e8..e02e554 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
>> @@ -3044,6 +3044,7 @@ struct libxl__stream_write_state {
>>  libxl__ao *ao;
>>  libxl__domain_save_state *dss;
>>  int fd;
>> +bool back_channel;
>>  void (*completion_callback)(libxl__egc *egc,
>>  libxl__stream_write_state *sws,
>>  int rc);
>> diff --git a/tools/libxl/libxl_stream_write.c 
>> b/tools/libxl/libxl_stream_write.c
>> index f6ea55d..5379126 100644
>> --- a/tools/libxl/libxl_stream_write.c
>> +++ b/tools/libxl/libxl_stream_write.c
>> @@ -49,6 +49,13 @@
>>   *  - if (hvm)
>>   *  - Emulator context record
>>   *  - Checkpoint end record
>> + *
>> + * For back channel stream:
>> + * - libxl__stream_write_start()
>> + *- Set up the stream to running state
>> + *
>> + * - Add a new API to write the record. When the record is written
>> + *   out, call stream->checkpoint_callback() to return.
> 
> What does this mean? Which new API?

The next patch introduces this API. The commits is very old.

I think I can merge these two patches into one patch.

> 
>>   */
>>  
>>  /* Success/error/cleanup handling. */
>> @@ -225,6 +232,15 @@ void libxl__stream_write_start(libxl__egc *egc,
>>  
>>  stream->running = true;
>>  
>> +dc->ao= ao;
>> +dc->readfd= -1;
>> +dc->copywhat  = "save v2 stream";
>> +dc->writefd   = stream->fd;
>> +dc->maxsz = -1;
>> +
>> +if (stream->back_channel)
>> +return;
>> +
> 
> There seems to be very subtle change of behaviour.
> 
> Before this patch, the dc->* are not set until the emulator check is
> done. With this path, it is possible in the normal case some of the
> fields are initialised in the error path.
> 
> I think this is OK given the callbacks in the upper layer and in
> the writer don't rely on those fields to clean up. Just one thing to
> note.
> 
> That said, I suggest you move all initialisation of dc->* in one place.

OK, I will do it.

> 
>>  if (dss->type == LIBXL_DOMAIN_TYPE_HVM) {
>>  stream->device_model_version =
>>  libxl__device_model_version_running(gc, dss->domid);
>> @@ -249,12 +265,7 @@ void libxl__stream_write_start(libxl__egc *egc,
>>  stream->emu_sub_hdr.index = 0;
>>  }
>>  
>> -dc->ao= ao;
>> -dc->readfd= -1;
>>  dc->writewhat = "stream header";
>> -dc->copywhat  = "save v2 stream";
>> -dc->writefd   = stream->fd;
>> -dc->maxsz = -1;
>>  dc->callback  = stream_header_done;
>>  
>>  rc = libxl__datacopier_start(dc);
>> @@ -279,6 +290,7 @@ void libxl__stream_write_start_checkpoint(libxl__egc 
>> *egc,
>>  {
>>  assert(stream->running);
>>  assert(!stream->in_checkpoint);
>> +assert(!stream->back_channel);
>>  stream->in_checkpoint = true;
>>  
>>  write_emulator_xenstore_record(egc, stream);
>> @@ -590,7 +602,9 @@ static void stream_done(libxl__egc *egc,
>>  libxl__carefd_close(stream->emu_carefd);
>>  free(stream->emu_body);
>>  
>> -check_all_finished(egc, stream, rc);
>> +if (!stream->back_channel)
>> +/* back channel stream doesn't have save helper */
>> +check_all_finished(egc, stream, rc);
> 
> Though it doesn't have helper, do you not need to check if the back
> channel stream itself is OK? The comment itself doesn't seem to justify
> this change.

What do you want to check? assert(!stream->shs) or 
assert(!libxl__stream_write_inuse(stream))?

Thanks
Wen Congyang

> 
> Wei.
> 
>>  }
>>  
>>  static void checkpoint_done(libxl__egc *egc,
>> -- 
>> 2.5.0
>>
>>
>>
>>
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> 

Re: [Xen-devel] [PATCH v10 07/31] docs/libxl: Introduce CHECKPOINT_CONTEXT to support migration v2 colo streams

[Wen Congyang]

On 02/25/2016 11:54 PM, Wei Liu wrote:
> On Mon, Feb 22, 2016 at 10:52:11AM +0800, Wen Congyang wrote:
>> It is the negotiation record for COLO.
>> Primary->Secondary:
>> control_id  0x: Secondary VM is out of sync, start a new 
>> checkpoint
>> Secondary->Primary:
>> 0x0001: Secondary VM is suspended
>> 0x0002: Secondary VM is ready
>> 0x0003: Secondary VM is resumed
>>
>> Signed-off-by: Wen Congyang 
>> Signed-off-by: Yang Hongyang 
>> ---
>>  docs/specs/libxl-migration-stream.pandoc | 25 +++--
>>  tools/libxl/libxl_sr_stream_format.h | 11 +++
>>  tools/python/xen/migration/libxl.py  |  9 +
>>  3 files changed, 43 insertions(+), 2 deletions(-)
>>
>> diff --git a/docs/specs/libxl-migration-stream.pandoc 
>> b/docs/specs/libxl-migration-stream.pandoc
>> index 2c97d86..5166d66 100644
>> --- a/docs/specs/libxl-migration-stream.pandoc
>> +++ b/docs/specs/libxl-migration-stream.pandoc
>> @@ -1,6 +1,6 @@
>>  % LibXenLight Domain Image Format
>>  % Andrew Cooper <>
> 
> You can add yours and Hongyang's name and email here as well.

OK

> 
>> -% Revision 1
>> +% Revision 2
>>  
>>  Introduction
>>  
>> @@ -119,7 +119,9 @@ type 0x: END
>>  
>>   0x0004: CHECKPOINT_END
>>  
>> - 0x0005 - 0x7FFF: Reserved for future _mandatory_
>> + 0x0005: CHECKPOINT_STATE
>> +
>> + 0x0006 - 0x7FFF: Reserved for future _mandatory_
>>   records.
>>  
>>   0x8000 - 0x: Reserved for future _optional_
>> @@ -249,6 +251,25 @@ A checkpoint end record marks the end of a checkpoint 
>> in the image.
>>  The end record contains no fields; its body_length is 0.
>>  
>>  
>> +CHECKPOINT\_STATE
>> +--
>> +
>> +A checkpoint state record contains the control information for checkpoint.
>> +
>> + 0 1 2 3 4 5 6 7 octet
>> ++++
>> +| control_id | padding|
>> ++++
>> +
>> +
>> +FieldDescription
>> + ---
>> +control_id   0x: Secondary VM is out of sync, start a new 
>> checkpoint
>> + 0x0001: Secondary VM is suspended
>> + 0x0002: Secondary VM is ready
>> + 0x0003: Secondary VM is resumed
> 
> You commit message seems to suggest 0 can only go from primary to
> secondary, while the other three only go from secondary to primary. You
> probably need to spell out the direction here (and later enforce this
> behaviour in code).

OK, will fix it in the next version.

Thanks
Wen Congyang

> 
> Wei.
> 
> 
> .
> 




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

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()

[Xu, Quan]

> On February 25, 2016 8:24pm,  wrote:
> >>> On 25.02.16 at 13:14,  wrote:
> > On February 25, 2016 4:59pm,  wrote:
> >> I'd
> >> really suggest investigating alternatives. One that comes to mind
> >> would be to move acquiring/releasing pcidevs_lock into a helper
> >> function, and setting a per-CPU flag indicating ownership.
> >
> > To me, this might be fine.
> > Does Per-CPU flag refer to this_cpu(iommu_dont_flush_iotlb) or variant?
> 
> Yes. But I'd prefer ...
> 
> >> However, the same effect could be achieved by making the lock a
> >> recursive one, which would then seem to more conventional approach
> >> (but requiring as much code to be touched).
> >> Both approached would eliminate the need to pass down "locked"
> >> flags.
> 
> ... this one (the more that the other won't mean less changes).
> 

Agreed, I am going to make the lock a recursive one. I will summarize the 
modification and send it out.

-Quan

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

Re: [Xen-devel] [PATCH v10 01/31] tools/libxl: introduce libxl__domain_restore_device_model to load qemu state

[Wen Congyang]

On 02/25/2016 11:53 PM, Wei Liu wrote:
> On Mon, Feb 22, 2016 at 10:52:05AM +0800, Wen Congyang wrote:
>> In normal migration, the qemu state is passed to qemu as a parameter.
>> With COLO, secondary vm is running. So we will do the following steps
>> at every checkpoint:
>> 1. suspend both primary vm and secondary vm
>> 2. sync the state
>> 3. resume both primary vm and secondary vm
>> Primary will send qemu's state in step2, and secondary's qemu should
>> read it and restore the state before it is resumed. We can not pass
>> the state to qemu as a parameter because secondary QEMU already started
> 
> is already started.
> 
>> at this point, so we introduce libxl__domain_restore_device_model() to
>> do it. This API MUST be called before resuming secondary vm.
>>
> 
> The last sentence is of no relevancy of this function itself, so I would
> just remove it if this patch will be resent in its current form.
> 
> And some comments below.
> 
>> Signed-off-by: Yang Hongyang 
>> Signed-off-by: Wen Congyang 
>> Cc: Anthony Perard 
>> Reviewed-by: Konrad Rzeszutek Wilk 
>> ---
>>  tools/libxl/libxl_dom_save.c | 20 
>>  tools/libxl/libxl_internal.h |  4 
>>  tools/libxl/libxl_qmp.c  | 10 ++
>>  3 files changed, 34 insertions(+)
>>
>> diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
>> index 4eb7960..7d345f9 100644
>> --- a/tools/libxl/libxl_dom_save.c
>> +++ b/tools/libxl/libxl_dom_save.c
>> @@ -512,6 +512,26 @@ int 
>> libxl__restore_emulator_xenstore_data(libxl__domain_create_state *dcs,
>>  return rc;
>>  }
>>  
>> +int libxl__domain_restore_device_model(libxl__gc *gc, uint32_t domid,
>> +   const char *restore_file)
>> +{
>> +int rc;
>> +
>> +switch (libxl__device_model_version_running(gc, domid)) {
>> +case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
>> +/* Will never be supported. */
>> +rc = ERROR_INVAL;
>> +break;
>> +case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
>> +rc = libxl__qmp_restore(gc, domid, restore_file);
>> +break;
>> +default:
>> +rc = ERROR_INVAL;
>> +}
>> +
>> +return rc;
>> +}
>> +
> 
> The function name suggests that it should be universally applied to all
> device model cases and all places that involves restoring device model.
> This is not the case in this series.  I search for this function in the
> rest of this series, it seems to be only used by COLO (in patch #10).
> 
> It's also unclear where the other half libxl__domain_save_device_model
> is.  I don't think this is your problem, though.
> 
> Based on the two reasons above, I would say let's not have this function
> at all.  You can call libxl__qmp_restore in COLO code directly.
> 
> Does this sound plausible?
> 
> If you agree, this patch can be turned into introduction of
> libxl__qmp_restore.

Yes, it is only used by COLO. I will update it in the next version.

Thanks
Wen Congyang

> 
>>  /*
>>   * Local variables:
>>   * mode: C
>> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
>> index a1aae97..5320e5e 100644
>> --- a/tools/libxl/libxl_internal.h
>> +++ b/tools/libxl/libxl_internal.h
>> @@ -1119,6 +1119,8 @@ _hidden int libxl__domain_rename(libxl__gc *gc, 
>> uint32_t domid,
>>   const char *old_name, const char *new_name,
>>   xs_transaction_t trans);
>>  
>> +_hidden int libxl__domain_restore_device_model(libxl__gc *gc, uint32_t 
>> domid,
>> +   const char *restore_file);
>>  _hidden int libxl__domain_resume_device_model(libxl__gc *gc, uint32_t 
>> domid);
>>  
>>  _hidden const char *libxl__userdata_path(libxl__gc *gc, uint32_t domid,
>> @@ -1762,6 +1764,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
>>  _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
>>  /* Save current QEMU state into fd. */
>>  _hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
>> +/* Load current QEMU state from file. */
>> +_hidden int libxl__qmp_restore(libxl__gc *gc, int domid, const char 
>> *filename);
>>  /* Set dirty bitmap logging status */
>>  _hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool 
>> enable);
>>  _hidden int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid, const 
>> libxl_device_disk *disk);
>> diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
>> index 714038b..eec8a44 100644
>> --- a/tools/libxl/libxl_qmp.c
>> +++ b/tools/libxl/libxl_qmp.c
>> @@ -905,6 +905,16 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const 
>> char *filename)
>> NULL, NULL);
>>  }
>>  
>> +int libxl__qmp_restore(libxl__gc *gc, int domid, const char *state_file)
>> +{
>> +libxl__json_object *args = NULL;
>> +
>> +

[Xen-devel] [qemu-mainline test] 83965: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  3 host-install(3) broken REGR. vs. 83845
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 83845
 build-armhf   4 host-build-prep   fail REGR. vs. 83845

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 83845

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

version targeted for testing:
 qemuu7bd57b515067b355ac997d29b0daf4fb8689e9be
baseline version:
 qemuu1b1624092d1f1f746adea6e1237a07f6788c2e3d

Last test of basis83845  2016-02-24 09:33:17 Z1 days
Testing same since83965  2016-02-25 10:12:47 Z0 days1 attempts


People who touched revisions under test:
  Mark Cave-Ayland 
  Peter Maydell 
  Richard Henderson  
  Richard Henderson 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   fail
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   

[Xen-devel] [PATCH v1 0/1] xen/arm: Re-add the Xilinx ZynqMP platform

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

We need to re-add the Xilinx ZynqMP platform with a blacklisted
zynqmp-pm power management firmware API device. Long term we'll
be looking at finding a way for this to work but this is likely
to take a while. In the meantime, in order to keep recent kernels
from panicing on boots we blacklist it (similar to what vexpress does).

Best regards,
Edgar

Edgar E. Iglesias (1):
  xen/arm: Re-add the Xilinx ZynqMP platform

 xen/arch/arm/platforms/Makefile|  1 +
 xen/arch/arm/platforms/xilinx-zynqmp.c | 47 ++
 2 files changed, 48 insertions(+)
 create mode 100644 xen/arch/arm/platforms/xilinx-zynqmp.c

-- 
2.5.0


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

[Xen-devel] [PATCH v1 1/1] xen/arm: Re-add the Xilinx ZynqMP platform

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Re-add the Xilinx ZynqMP platform. This time include a
blacklisted zynqmp-pm (Power Management) device that does
not yet play nicely with Xen.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/platforms/Makefile|  1 +
 xen/arch/arm/platforms/xilinx-zynqmp.c | 47 ++
 2 files changed, 48 insertions(+)
 create mode 100644 xen/arch/arm/platforms/xilinx-zynqmp.c

diff --git a/xen/arch/arm/platforms/Makefile b/xen/arch/arm/platforms/Makefile
index e173fec..3689eec 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_ARM_32) += sunxi.o
 obj-$(CONFIG_ARM_32) += rcar2.o
 obj-$(CONFIG_ARM_64) += seattle.o
 obj-$(CONFIG_ARM_64) += xgene-storm.o
+obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
diff --git a/xen/arch/arm/platforms/xilinx-zynqmp.c 
b/xen/arch/arm/platforms/xilinx-zynqmp.c
new file mode 100644
index 000..2adee91
--- /dev/null
+++ b/xen/arch/arm/platforms/xilinx-zynqmp.c
@@ -0,0 +1,47 @@
+/*
+ * xen/arch/arm/platforms/xilinx-zynqmp.c
+ *
+ * Xilinx ZynqMP setup
+ *
+ * Copyright (c) 2016 Xilinx Inc.
+ * Written by Edgar E. Iglesias 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+static const char * const zynqmp_dt_compat[] __initconst =
+{
+"xlnx,zynqmp",
+NULL
+};
+
+static const struct dt_device_match zynqmp_blacklist_dev[] __initconst =
+{
+/* Power management is not yet supported.  */
+DT_MATCH_COMPATIBLE("xlnx,zynqmp-pm"),
+{ /* sentinel */ },
+};
+
+PLATFORM_START(xgene_storm, "Xilinx ZynqMP")
+.compatible = zynqmp_dt_compat,
+.blacklist_dev = zynqmp_blacklist_dev,
+PLATFORM_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.5.0


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

Re: [Xen-devel] [PATCH v13 1/2] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, February 24, 2016 8:50 PM
> To: George Dunlap ; Wu, Feng
> 
> Cc: Doug Goldstein ; Andrew Cooper
> ; Dario Faggioli ;
> GeorgeDunlap ; Tian, Kevin
> ; xen-devel@lists.xen.org; Keir Fraser 
> Subject: Re: [Xen-devel] [PATCH v13 1/2] vmx: VT-d posted-interrupt core logic
> handling
> 
> >>> On 24.02.16 at 13:09,  wrote:
> > Another reason for such a comment is that it actually raises awareness
> > that the hook isn't properly structured: if you get such a compile
> > error, then it's either not defined in the right place, or it's not
> > using the right calling convention.
> 
> Well, why I generally agree with you here, I'm afraid there are
> many pre-existing instances in our headers. Cleaning that up is
> likely going to be a major work item.
> 
> > It also makes me realize that this code will no longer build on ARM,
> > since arch_do_block() is only defined in asm-x86 (and not asm-arm).
> 
> The patch has
> 
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -310,6 +310,8 @@ static inline void free_vcpu_guest_context(struct
> vcpu_guest_context *vgc)
>  xfree(vgc);
>  }
> 
> +static inline void arch_vcpu_block(struct vcpu *v) {}
> +
>  #endif /* __ASM_DOMAIN_H__ */
> 
>  /*
> 
> (and for the avoidance of doubt there's no arch_do_block() afaics).
> 
> > It seems like to do the callback properly, we should do something like
> > the attached.  Jan, what do you think?
> 
> Well, as per above that would address the particular issue here
> without addressing the many other existing ones, and it would
> cause out of line functions _plus_ another indirect call when the
> idea is to have such hooks inlined as far as possible.
> 
> But you indeed point out one important problem - the hook as it
> is right now lacks a has_hvm_container_vcpu(), and hence would
> break for PV guests.

Do you mean I need to add has_hvm_container_vcpu() check in
macro arch_vcpu_block()? But .vcpu_block is assigned in
vmx_pi_hooks_assign(). I am not clear how this hooks can affect
PV guests, could you please elaborate a bit more? Thanks a lot!

Thanks,
Feng

> 
> Jan


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

[Xen-devel] [linux-4.1 test] 83951: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   3 host-install(3) broken REGR. vs. 66399
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 
66399
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 66399
 test-armhf-armhf-xl-multivcpu 16 guest-start.2   fail in 82991 REGR. vs. 66399
 build-amd64-rumpuserxen   6 xen-buildfail in 83835 REGR. vs. 66399
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 83835 REGR. 
vs. 66399
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail in 83835 REGR. vs. 66399

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemuu-rhel6hvm-intel  3 host-install(3)   broken pass in 83835
 test-amd64-i386-xl-raw3 host-install(3)   broken pass in 83835
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 83835
 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken pass in 
83835
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 
83835
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 83835 pass 
in 82991
 test-armhf-armhf-xl-cubietruck 11 guest-start  fail in 83835 pass in 83951
 test-armhf-armhf-xl-xsm   6 xen-boot   fail in 83835 pass in 83951
 test-armhf-armhf-xl-rtds 11 guest-startfail in 83835 pass in 83951
 test-armhf-armhf-xl-credit2  11 guest-start fail pass in 83835
 test-armhf-armhf-xl  11 guest-start fail pass in 83835
 test-armhf-armhf-xl-multivcpu 11 guest-startfail pass in 83835

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66399
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399

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

Re: [Xen-devel] [PATCH v6][RFC]xen: sched: convert RTDS from time to event driven model

[Dario Faggioli]

Hey again,

Thanks for turning up so quickly.

We are getting closer and closer, although (of course :-)) I have some
more comments.

However, is there a particular reason why you are keeping the RFC tag?
Until you do that, it's like saying that you are chasing feedback, but
you do not think yourself the patch should be considered for being
upstreamed. As far as my opinion goes, this patch is not ready to go in
right now (as I said, I've got questions and comments), but its status
is way past RFC.

On Thu, 2016-02-25 at 15:05 -0500, Tianyang Chen wrote:
> changes since v5:
> removed unnecessary vcpu_on_replq() checks
> deadline_queue_insert() returns a flag to indicate if it's
> needed to re-program the timer
> removed unnecessary timer checks
> added helper functions to remove vcpus from queues
> coding style
> 
> Changes since v4:
> removed unnecessary replenishment queue checks in vcpu_wake()
> extended replq_remove() to all cases in vcpu_sleep()
> used _deadline_queue_insert() helper function for both queues
> _replq_insert() and _replq_remove() program timer internally
> 
> Changes since v3:
> removed running queue.
> added repl queue to keep track of repl events.
> timer is now per scheduler.
> timer is init on a valid cpu in a cpupool.
> 
So, this does not belong here. It is ok to have it in this part of the
email, but it should not land in the actual commit changelog, once the
patch will be committed into Xen's git tree.

The way to achieve the above is to put this summary of changes below
the actual changelog, and below the Signed-of-by lines, after a marker
that looks like this "---".

> Budget replenishment and enforcement are separated by adding
> a replenishment timer, which fires at the next most imminent
> release time of all runnable vcpus.
> 
> A new runningq has been added to keep track of all vcpus that
> are on pcpus.
> 
Mmm.. Is this the proper changelog? runningq is something we discussed,
and that appeared in v2, but is certainly no longer here... :-O

> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 2e5430f..16f77f9 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> 
> @@ -213,8 +220,14 @@ static inline struct list_head
> *rt_depletedq(const struct scheduler *ops)
>  return _priv(ops)->depletedq;
>  }
>  
> +static inline struct list_head *rt_replq(const struct scheduler
> *ops)
> +{
> +return _priv(ops)->replq;
> +}
> +
>  /*
> - * Queue helper functions for runq and depletedq
> + * Queue helper functions for runq, depletedq
> + * and replenishment event queue
>
Full stop. :-)

In any case, I'd change this in something like:
"Helper functions for manipulating the runqueue, the depleted queue,
and the replenishment events queue."

> @@ -228,6 +241,18 @@ __q_elem(struct list_head *elem)
>  return list_entry(elem, struct rt_vcpu, q_elem);
>  }
>  
> +static struct rt_vcpu *
> +__replq_elem(struct list_head *elem)
> +{
> +return list_entry(elem, struct rt_vcpu, replq_elem);
> +}
> +
> +static int
> +__vcpu_on_replq(const struct rt_vcpu *svc)
> +{
> +   return !list_empty(>replq_elem);
> +}
> +
>
Ok, sorry for changing my mind again, but I really can't stand seeing
these underscores. Please, rename these as replq_elem() and
vcpu_on_replq(). There is nor sensible reason why we should prefix
these with '__'.

I know, that will create some amount of inconsistency, but:
 - there is inconsistency already (here and in other sched_* file)
 - not introducing more __ prefixed function is a step in the right 
   direction; we'll convert the one that are already there with time.

> + * Removing a vcpu from the replenishment queue could
> + * re-program the timer for the next replenishment event
> + * if there is any on the list
> 
> + */
> +static inline void
> +__replq_remove(const struct scheduler *ops, struct rt_vcpu *svc)
> +{
> +struct rt_private *prv = rt_priv(ops);
> +struct list_head *replq = rt_replq(ops);
> +struct timer* repl_timer = prv->repl_timer;
> +
> +/*
> + * Disarm the timer before re-programming it.
> + * It doesn't matter if the vcpu to be removed
> + * is on top of the list or not because the timer
> + * is stopped and needs to be re-programmed anyways
> + */
> +stop_timer(repl_timer);
> +
> +deadline_queue_remove(>replq_elem);
> +
> +/* re-arm the timer for the next replenishment event */
> +if( !list_empty(replq) )
> +{
> +struct rt_vcpu *svc_next = __replq_elem(replq->next);
> +set_timer(repl_timer, svc_next->cur_deadline);
> +}
>
Wait, maybe you misunderstood and/or I did not make myself clear enough
(in which case, sorry). I never meant to say "always stop the timer".
Atually, in one of my last email I said the opposite, and I think that
would be the best thing to do.

Do you think there is any specific reason why we need to always stop
and restart it? If not, I think we can:
 - have 

Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Doug Goldstein]

On 2/25/16 12:39 AM, fu@linaro.org wrote:
> From: Fu Wei 
> -@deffn Command xen_linux file [arguments]
> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
> +@deffn Command xen_module [--nounzip] file [arguments]
> +Load a module for xen hypervisor at the booting process of xen.
>  The rest of the line is passed verbatim as the module command line.
> +Each module will be identified by the order in which the modules are added.
> +The 1st module: dom0 kernel image
> +The 2nd module: dom0 ramdisk
> +All subsequent modules: UNKNOW

Missing an 'N' at the end there. Probably worth mentioning that the
ramdisk is optional as well.

-- 
Doug Goldstein



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

[Xen-devel] [PATCH, RESEND] xen: allocate gntdev_copy_batch dynamically

[Arnd Bergmann]

struct gntdev_copy_batch is arguably too large to fit on the kernel stack,
and we get a warning about the stack usage in gntdev_ioctl_grant_copy:

drivers/xen/gntdev.c:949:1: error: the frame size of 1240 bytes is larger than 
1024 bytes

This changes the code to us a dynamic allocation instead.

Signed-off-by: Arnd Bergmann 
Fixes: a4cdb556cae0 ("xen/gntdev: add ioctl for grant copy")
---
 drivers/xen/gntdev.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

I sent this in January, Boris sent an almost identical patch
as http://www.gossamer-threads.com/lists/xen/devel/414056
but the bug remains present in mainline and linux-next as of
Feb 25.

Could you apply one of the patches before the bug makes it
into v4.5?

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index dc495383ad73..cc753b3a7154 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -915,15 +915,16 @@ static int gntdev_grant_copy_seg(struct gntdev_copy_batch 
*batch,
 static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u)
 {
struct ioctl_gntdev_grant_copy copy;
-   struct gntdev_copy_batch batch;
+   struct gntdev_copy_batch *batch;
unsigned int i;
int ret = 0;
 
if (copy_from_user(, u, sizeof(copy)))
return -EFAULT;
 
-   batch.nr_ops = 0;
-   batch.nr_pages = 0;
+   batch = kzalloc(sizeof(*batch), GFP_KERNEL);
+   if (!batch)
+   return -ENOMEM;
 
for (i = 0; i < copy.count; i++) {
struct gntdev_grant_copy_segment seg;
@@ -933,18 +934,20 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv 
*priv, void __user *u)
goto out;
}
 
-   ret = gntdev_grant_copy_seg(, , 
[i].status);
+   ret = gntdev_grant_copy_seg(batch, , 
[i].status);
if (ret < 0)
goto out;
 
cond_resched();
}
-   if (batch.nr_ops)
-   ret = gntdev_copy();
+   if (batch->nr_ops)
+   ret = gntdev_copy(batch);
+   kfree(batch);
return ret;
 
   out:
-   gntdev_put_pages();
+   gntdev_put_pages(batch);
+   kfree(batch);
return ret;
 }
 
-- 
2.7.0


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

[Xen-devel] [linux-linus test] 83936: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-xsm3 host-install(3) broken REGR. vs. 59254
 test-amd64-amd64-xl-credit2   3 host-install(3) broken REGR. vs. 59254
 test-amd64-i386-pair 3 host-install/src_host(3) broken REGR. vs. 59254
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10   fail REGR. vs. 59254
 test-amd64-amd64-pair23 guest-stop/src_host   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 
59254
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 59254
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 59254
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-qcow2  5 xen-install   fail baseline untested
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-amd64-qemuu-nested-intel 13 xen-boot/l1 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-qemuu-nested-amd 13 xen-boot/l1   fail 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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass

[Xen-devel] [PATCH v6][RFC]xen: sched: convert RTDS from time to event driven model

[Tianyang Chen]

changes since v5:
removed unnecessary vcpu_on_replq() checks
deadline_queue_insert() returns a flag to indicate if it's
needed to re-program the timer
removed unnecessary timer checks
added helper functions to remove vcpus from queues
coding style

Changes since v4:
removed unnecessary replenishment queue checks in vcpu_wake()
extended replq_remove() to all cases in vcpu_sleep()
used _deadline_queue_insert() helper function for both queues
_replq_insert() and _replq_remove() program timer internally

Changes since v3:
removed running queue.
added repl queue to keep track of repl events.
timer is now per scheduler.
timer is init on a valid cpu in a cpupool.

Budget replenishment and enforcement are separated by adding
a replenishment timer, which fires at the next most imminent
release time of all runnable vcpus.

A new runningq has been added to keep track of all vcpus that
are on pcpus.

The following functions have major changes to manage the runningq
and replenishment

repl_handler(): It is a timer handler which is re-programmed
to fire at the nearest vcpu deadline to replenish vcpus on runq,
depeletedq and runningq. When the replenishment is done, each
replenished vcpu should tickle a pcpu to see if it needs to
preempt any running vcpus.

rt_schedule(): picks the highest runnable vcpu based on cpu
affinity and ret.time will be passed to schedule(). If an idle
vcpu is picked, -1 is returned to avoid busy-waiting. repl_update()
has been removed.

rt_vcpu_wake(): when a vcpu is awake, it tickles instead of
picking one from runq. When a vcpu wakes up, it might reprogram
the timer if it has a more recent release time.

rt_context_saved(): when context switching is finished, the
preempted vcpu will be put back into the runq. Runningq is
updated and picking from runq and tickling are removed.

Simplified funtional graph:

schedule.c SCHEDULE_SOFTIRQ:
rt_schedule():
[spin_lock]
burn_budget(scurr)
snext = runq_pick()
[spin_unlock]

sched_rt.c TIMER_SOFTIRQ
replenishment_timer_handler()
[spin_lock]
 {
replenish(i)
runq_tickle(i)
}>
program_timer()
[spin_lock]

Signed-off-by: Tianyang Chen 
Signed-off-by: Meng Xu 
Signed-off-by: Dagaen Golomb 
---
 xen/common/sched_rt.c |  328 -
 1 file changed, 244 insertions(+), 84 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 2e5430f..16f77f9 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -87,7 +88,7 @@
 #define RTDS_DEFAULT_BUDGET (MICROSECS(4000))
 
 #define UPDATE_LIMIT_SHIFT  10
-#define MAX_SCHEDULE(MILLISECS(1))
+
 /*
  * Flags
  */
@@ -142,6 +143,9 @@ static cpumask_var_t *_cpumask_scratch;
  */
 static unsigned int nr_rt_ops;
 
+/* handler for the replenishment timer */
+static void repl_handler(void *data);
+
 /*
  * Systme-wide private data, include global RunQueue/DepletedQ
  * Global lock is referenced by schedule_data.schedule_lock from all
@@ -152,7 +156,9 @@ struct rt_private {
 struct list_head sdom;  /* list of availalbe domains, used for dump */
 struct list_head runq;  /* ordered list of runnable vcpus */
 struct list_head depletedq; /* unordered list of depleted vcpus */
+struct list_head replq; /* ordered list of vcpus that need 
replenishment */
 cpumask_t tickled;  /* cpus been tickled */
+struct timer *repl_timer;   /* replenishment timer */
 };
 
 /*
@@ -160,6 +166,7 @@ struct rt_private {
  */
 struct rt_vcpu {
 struct list_head q_elem;/* on the runq/depletedq list */
+struct list_head replq_elem;/* on the repl event list */
 
 /* Up-pointers */
 struct rt_dom *sdom;
@@ -213,8 +220,14 @@ static inline struct list_head *rt_depletedq(const struct 
scheduler *ops)
 return _priv(ops)->depletedq;
 }
 
+static inline struct list_head *rt_replq(const struct scheduler *ops)
+{
+return _priv(ops)->replq;
+}
+
 /*
- * Queue helper functions for runq and depletedq
+ * Queue helper functions for runq, depletedq
+ * and replenishment event queue
  */
 static int
 __vcpu_on_q(const struct rt_vcpu *svc)
@@ -228,6 +241,18 @@ __q_elem(struct list_head *elem)
 return list_entry(elem, struct rt_vcpu, q_elem);
 }
 
+static struct rt_vcpu *
+__replq_elem(struct list_head *elem)
+{
+return list_entry(elem, struct rt_vcpu, replq_elem);
+}
+
+static int
+__vcpu_on_replq(const struct rt_vcpu *svc)
+{
+   return !list_empty(>replq_elem);
+}
+
 /*
  * Debug related code, dump vcpu/cpu information
  */
@@ -288,7 +313,7 @@ rt_dump_pcpu(const struct scheduler *ops, int cpu)
 static void
 rt_dump(const struct scheduler *ops)
 {
-struct 

Re: [Xen-devel] AMD PVH: Status of patches

[Doug Goldstein]

On 2/25/16 1:17 PM, Sherry Hurwitz wrote:
> Last fall there were patches under discussion to add PVH support for AMD
> systems.
> The work was started by Mukesh Rathor of Oracle and then continued by
> Elena Ufimtseva.
> I don't see that those patches ever made it into xen unstable. Was the
> work discontinued
> because of a change of focus to HVMlite?  If not, I was looking into
> picking that work up if Elena
> had moved on to something else.  Would it make more sense to now let PVH
> go and focus on
> HVMlite?
> 
> Thanks for any suggestion or guidance.

Sherry,

I know that HVMlite is considered PVHv2 and the original PVH will
disappear once HVMlite has been complete so that would seem like the
wise place to focus on.

-- 
Doug Goldstein



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

Re: [Xen-devel] AMD PVH: Status of patches

[Boris Ostrovsky]

On 02/25/2016 02:17 PM, Sherry Hurwitz wrote:
Last fall there were patches under discussion to add PVH support for 
AMD systems.
The work was started by Mukesh Rathor of Oracle and then continued by 
Elena Ufimtseva.
I don't see that those patches ever made it into xen unstable. Was the 
work discontinued

because of a change of focus to HVMlite?


Yes, HVMlite (aka PVHv2) is replacement for what is now PVH.

-boris



If not, I was looking into picking that work up if Elena
had moved on to something else.  Would it make more sense to now let 
PVH go and focus on

HVMlite?

Thanks for any suggestion or guidance.



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

[Xen-devel] [PATCH v2 6/7] libxl: add a FreeBSD implementation of libxl__devid_to_localdev

[Roger Pau Monne]

This code is extracted from the FreeBSD blkfront implementation.

Signed-off-by: Roger Pau Monné 
---
 tools/libxl/libxl_freebsd.c | 54 +++--
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_freebsd.c b/tools/libxl/libxl_freebsd.c
index 8ad347e..551338b 100644
--- a/tools/libxl/libxl_freebsd.c
+++ b/tools/libxl/libxl_freebsd.c
@@ -27,8 +27,58 @@ int libxl__try_phy_backend(mode_t st_mode)
 
 char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
 {
-/* TODO */
-return NULL;
+/* This translation table has been copied from the FreeBSD blkfront code. 
*/
+const static struct vdev_info {
+int major;
+int shift;
+int base;
+const char *name;
+} info[] = {
+{3, 6,  0,  "ada"}, /* ide0 */
+{22,6,  2,  "ada"}, /* ide1 */
+{33,6,  4,  "ada"}, /* ide2 */
+{34,6,  6,  "ada"}, /* ide3 */
+{56,6,  8,  "ada"}, /* ide4 */
+{57,6,  10, "ada"}, /* ide5 */
+{88,6,  12, "ada"}, /* ide6 */
+{89,6,  14, "ada"}, /* ide7 */
+{90,6,  16, "ada"}, /* ide8 */
+{91,6,  18, "ada"}, /* ide9 */
+
+{8, 4,  0,  "da"},  /* scsi disk0 */
+{65,4,  16, "da"},  /* scsi disk1 */
+{66,4,  32, "da"},  /* scsi disk2 */
+{67,4,  48, "da"},  /* scsi disk3 */
+{68,4,  64, "da"},  /* scsi disk4 */
+{69,4,  80, "da"},  /* scsi disk5 */
+{70,4,  96, "da"},  /* scsi disk6 */
+{71,4,  112,"da"},  /* scsi disk7 */
+{128,   4,  128,"da"},  /* scsi disk8 */
+{129,   4,  144,"da"},  /* scsi disk9 */
+{130,   4,  160,"da"},  /* scsi disk10 */
+{131,   4,  176,"da"},  /* scsi disk11 */
+{132,   4,  192,"da"},  /* scsi disk12 */
+{133,   4,  208,"da"},  /* scsi disk13 */
+{134,   4,  224,"da"},  /* scsi disk14 */
+{135,   4,  240,"da"},  /* scsi disk15 */
+
+{202,   4,  0,  "xbd"}, /* xbd */
+
+{0, 0,  0,  NULL},
+};
+int major = devid >> 8;
+int minor = devid & 0xff;
+int i;
+
+if (devid & (1 << 28))
+return GCSPRINTF("%s%d", "xbd", (devid & ((1 << 28) - 1)) >> 8);
+
+for (i = 0; info[i].major; i++)
+if (info[i].major == major)
+return GCSPRINTF("%s%d", info[i].name,
+ info[i].base + (minor >> info[i].shift));
+
+return GCSPRINTF("%s%d", "xbd", minor >> 4);
 }
 
 /* Hotplug scripts caller functions */
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v2 3/7] hotplug/FreeBSD: add block hotplug script

[Roger Pau Monne]

This is the default hotplug script for block devices. Its only job is to
copy the "params" blkback xenstore node to "physical-device".

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/hotplug/FreeBSD/Makefile |  2 +-
 tools/hotplug/FreeBSD/block| 25 +
 2 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 tools/hotplug/FreeBSD/block

diff --git a/tools/hotplug/FreeBSD/Makefile b/tools/hotplug/FreeBSD/Makefile
index 10fce4f..bd7a86f 100644
--- a/tools/hotplug/FreeBSD/Makefile
+++ b/tools/hotplug/FreeBSD/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 # Xen script dir and scripts to go there.
-XEN_SCRIPTS = vif-bridge
+XEN_SCRIPTS = vif-bridge block
 
 XEN_SCRIPT_DATA =
 
diff --git a/tools/hotplug/FreeBSD/block b/tools/hotplug/FreeBSD/block
new file mode 100644
index 000..1f2a533
--- /dev/null
+++ b/tools/hotplug/FreeBSD/block
@@ -0,0 +1,25 @@
+#!/bin/sh -e
+#
+# FreeBSD hotplug script for attaching disks
+#
+# Parameters:
+#  $1: xenstore backend path of the vbd
+#  $2: action, either "add" or "remove"
+#
+# Environment variables:
+#  None
+#
+
+path=$1
+action=$2
+params=$(xenstore-read "$path/params")
+
+case $action in
+add)
+   xenstore-write $path/physical-device $params
+   exit 0
+   ;;
+*)
+   exit 0
+   ;;
+esac
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v2 1/7] blkif: document how FreeBSD uses the physical-device backend node

[Roger Pau Monne]

FreeBSD blkback uses the physical-device xenstore node in order to fetch the
path to the underlying backing storage (either a block device or raw image).
This node is set by the hotplug scripts.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Tim Deegan 
---
 xen/include/public/io/blkif.h | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index 99f0326..9a5baa4 100644
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -89,14 +89,18 @@
  *  Values: string
  *
  *  A free formatted string providing sufficient information for the
- *  backend driver to open the backing device.  (e.g. the path to the
- *  file or block device representing the backing store.)
+ *  hotplug script to attach the device and provide a suitable
+ *  handler (ie: a block device) for blkback to use.
  *
- * physical-device
- *  Values: "MAJOR:MINOR"
+ * physical-device:
+ *  Values: OS specific
  *
- *  MAJOR and MINOR are the major number and minor number of the
- *  backing device respectively.
+ *  A free formatted string that contains the OS specific path to the
+ *  backing device for this blkback instance.
+ *
+ *  Linux and NetBSD encode the block device major and minor numbers using
+ *  the following printf format: "%x:%x", while FreeBSD places the path to
+ *  the file or device in the filesystem.
  *
  * type
  *  Values: "file", "phy", "tap"
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v2 0/7] libxl: add support for FreeBSD block hotplug scripts

[Roger Pau Monne]

This series enables using hotplug scripts with the FreeBSD blkback 
implementation. Since FreeBSD blkback can use both block devices and regular 
RAW files as disks, the physical-device xenstore backend node is now 
OS-specific, Linux and NetBSD will encode the device major and minor numbers 
there, while FreeBSD simply puts an absolute path to a disk image.

The current blkback implementation in FreeBSD HEAD doesn't yet know about 
hotplug scripts, I plan to commit the FreeBSD side once this series is 
reviewed.

Thanks, Roger.

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

[Xen-devel] [PATCH v2 4/7] libxl/FreeBSD: add support for disk hotplug scripts

[Roger Pau Monne]

Allow FreeBSD to execute hotplug scripts when attaching disk devices.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl_freebsd.c | 114 
 1 file changed, 83 insertions(+), 31 deletions(-)

diff --git a/tools/libxl/libxl_freebsd.c b/tools/libxl/libxl_freebsd.c
index 483f36e..8ad347e 100644
--- a/tools/libxl/libxl_freebsd.c
+++ b/tools/libxl/libxl_freebsd.c
@@ -59,14 +59,36 @@ static int libxl__hotplug_env_nic(libxl__gc *gc, 
libxl__device *dev, char ***env
 return 0;
 }
 
-static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev, char ***args,
-  libxl__device_action action)
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+  char ***args, char ***env,
+  libxl__device_action action,
+  int num_exec)
 {
+libxl_nic_type nictype;
 char *be_path = libxl__device_backend_path(gc, dev);
 char *script;
-int nr = 0, rc = 0, arraysize = 4;
+int nr = 0, rc;
 
-assert(dev->backend_kind == LIBXL__DEVICE_KIND_VIF);
+rc = libxl__nic_type(gc, dev, );
+if (rc) {
+LOG(ERROR, "error when fetching nic type");
+rc = ERROR_FAIL;
+goto out;
+}
+
+/*
+ * For PV domains only one pass is needed (because there's no emulated
+ * interface). For HVM domains two passes are needed in order to add
+ * both the PV and the tap interfaces to the bridge.
+ */
+if (nictype == LIBXL_NIC_TYPE_VIF && num_exec != 0) {
+rc = 0;
+goto out;
+}
+
+rc = libxl__hotplug_env_nic(gc, dev, env, num_exec);
+if (rc)
+goto out;
 
 script = libxl__xs_read(gc, XBT_NULL,
 GCSPRINTF("%s/%s", be_path, "script"));
@@ -76,53 +98,83 @@ static int libxl__hotplug_nic(libxl__gc *gc, libxl__device 
*dev, char ***args,
 goto out;
 }
 
+const int arraysize = 4;
 GCNEW_ARRAY(*args, arraysize);
 (*args)[nr++] = script;
 (*args)[nr++] = be_path;
-(*args)[nr++] = GCSPRINTF("%s", action == LIBXL__DEVICE_ACTION_ADD ?
-"add" : "remove");
+(*args)[nr++] = (char *) libxl__device_action_to_string(action);
 (*args)[nr++] = NULL;
 assert(nr == arraysize);
 
+rc = 1;
+
 out:
 return rc;
 }
 
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+   char ***args, char ***env,
+   libxl__device_action action)
+{
+char *be_path = libxl__device_backend_path(gc, dev);
+char *script;
+int nr = 0, rc;
+
+script = libxl__xs_read(gc, XBT_NULL,
+GCSPRINTF("%s/%s", be_path, "script"));
+if (!script) {
+LOGEV(ERROR, errno, "unable to read script from %s", be_path);
+rc = ERROR_FAIL;
+goto error;
+}
+
+const int arraysize = 4;
+GCNEW_ARRAY(*args, arraysize);
+(*args)[nr++] = script;
+(*args)[nr++] = be_path;
+(*args)[nr++] = (char *) libxl__device_action_to_string(action);
+(*args)[nr++] = NULL;
+assert(nr == arraysize);
+
+rc = 1;
+
+error:
+return rc;
+}
+
 int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
char ***args, char ***env,
libxl__device_action action,
int num_exec)
 {
-libxl_nic_type nictype;
 int rc;
 
-if (dev->backend_kind != LIBXL__DEVICE_KIND_VIF || num_exec == 2)
-return 0;
-
-rc = libxl__nic_type(gc, dev, );
-if (rc) {
-LOG(ERROR, "error when fetching nic type");
-rc = ERROR_FAIL;
-goto out;
-}
-
-/*
- * For PV domains only one pass is needed (because there's no emulated
- * interface). For HVM domains two passes are needed in order to add
- * both the PV and the tap interfaces to the bridge.
- */
-if (nictype == LIBXL_NIC_TYPE_VIF && num_exec != 0) {
+switch (dev->backend_kind) {
+case LIBXL__DEVICE_KIND_VBD:
+if (num_exec != 0) {
+rc = 0;
+goto out;
+}
+rc = libxl__hotplug_disk(gc, dev, args, env, action);
+break;
+case LIBXL__DEVICE_KIND_VIF:
+/*
+ * If domain has a stubdom we don't have to execute hotplug scripts
+ * for emulated interfaces
+ */
+if ((num_exec > 1) ||
+(libxl_get_stubdom_id(CTX, dev->domid) && num_exec)) {
+rc = 0;
+goto out;
+}
+rc = libxl__hotplug_nic(gc, dev, args, env, action, num_exec);
+break;
+default:
+/* No need to execute any hotplug scripts */
 rc = 0;
-goto out;
+break;
 }
 
-rc = 

[Xen-devel] [PATCH v2 2/7] libxl: introduce an OS-specific function to get the physical-device

[Roger Pau Monne]

Linux and NetBSD will return the device major and minor numbers encoded in
hex and separated by a ":". FreeBSD on the other hand returns the path to
the block device or image file.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl.c  |  9 +
 tools/libxl/libxl_freebsd.c  |  6 ++
 tools/libxl/libxl_internal.h |  6 ++
 tools/libxl/libxl_linux.c| 10 ++
 tools/libxl/libxl_netbsd.c   | 10 ++
 5 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2d18b8d..6d719d7 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2515,10 +2515,11 @@ static void device_disk_add(libxl__egc *egc, uint32_t 
domid,
  */
 if (!disk->script &&
 disk->backend_domid == LIBXL_TOOLSTACK_DOMID) {
-int major, minor;
-if (!libxl__device_physdisk_major_minor(dev, , 
))
-flexarray_append_pair(back, "physical-device",
-  GCSPRINTF("%x:%x", major, 
minor));
+char *physdev;
+
+physdev = libxl__get_physical_device(dev);
+if (physdev != NULL)
+flexarray_append_pair(back, "physical-device", 
physdev);
 }
 
 assert(device->backend_kind == LIBXL__DEVICE_KIND_VBD);
diff --git a/tools/libxl/libxl_freebsd.c b/tools/libxl/libxl_freebsd.c
index 47c3391..483f36e 100644
--- a/tools/libxl/libxl_freebsd.c
+++ b/tools/libxl/libxl_freebsd.c
@@ -143,3 +143,9 @@ int libxl__pci_topology_init(libxl__gc *gc,
 {
 return ERROR_NI;
 }
+
+char *libxl__get_physical_device(char *dev)
+{
+
+return dev;
+}
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 650a958..1a3fa35 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1346,6 +1346,12 @@ void libxl__domaindeathcheck_stop(libxl__gc *gc, 
libxl__domaindeathcheck *dc);
  */
 _hidden int libxl__try_phy_backend(mode_t st_mode);
 
+/*
+ * Fetch the "physical-device" backend xenstore field for a local disk
+ * device. The implementation of this function is OS-specific.
+ */
+_hidden char *libxl__get_physical_device(char *dev);
+
 
 _hidden char *libxl__devid_to_localdev(libxl__gc *gc, int devid);
 
diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index be4afc6..7e6d7b9 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -347,3 +347,13 @@ int libxl__pci_topology_init(libxl__gc *gc,
 
 return err;
 }
+
+char *libxl__get_physical_device(char *dev)
+{
+int major, minor;
+
+if (libxl__device_physdisk_major_minor(dev, , ))
+return NULL;
+
+return GCSPRINTF("%x:%x", major, minor);
+}
diff --git a/tools/libxl/libxl_netbsd.c b/tools/libxl/libxl_netbsd.c
index 096c057..e12561f 100644
--- a/tools/libxl/libxl_netbsd.c
+++ b/tools/libxl/libxl_netbsd.c
@@ -100,3 +100,13 @@ int libxl__pci_topology_init(libxl__gc *gc,
 {
 return ERROR_NI;
 }
+
+char *libxl__get_physical_device(char *dev)
+{
+int major, minor;
+
+if (libxl__device_physdisk_major_minor(dev, , ))
+return NULL;
+
+return GCSPRINTF("%x:%x", major, minor);
+}
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v2 7/7] libxl: fix error message in local_device_attach_cb

[Roger Pau Monne]

The fields that are printed might not be set in the case of a failure, which
generates a segmentation fault.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d55c699..d5a0a01 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3144,10 +3144,7 @@ static void local_device_attach_cb(libxl__egc *egc, 
libxl__ao_device *aodev)
 
 rc = aodev->rc;
 if (rc) {
-LOGE(ERROR, "unable to %s %s with id %u",
-libxl__device_action_to_string(aodev->action),
-libxl__device_kind_to_string(aodev->dev->kind),
-aodev->dev->devid);
+LOGE(ERROR, "unable locally attach device: %s", disk->pdev_path);
 goto out;
 }
 
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH v2 5/7] libxl: properly use vdev vs local device

[Roger Pau Monne]

The current code in libxl assumed that vdev is equal to local device, but
this is only true for Linux systems. In other OSes the local device can use
a nomenclature completely different from the virtual device one.

Move the current libxl__devid_to_localdev Linux implementation out of the
OS-specific file and rename it to libxl__devid_to_vdev, and then make sure
local_device_attach_cb return the local device in the diskpath field.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Wei Liu 
---
 tools/libxl/libxl.c  | 12 --
 tools/libxl/libxl_device.c   | 57 
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_linux.c| 49 +
 4 files changed, 64 insertions(+), 55 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6d719d7..d55c699 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3071,7 +3071,7 @@ static char * libxl__alloc_vdev(libxl__gc *gc, void 
*get_vdev_user,
 GCSPRINTF("%s/device/vbd/%d/backend",
 dompath, devid)) == NULL) {
 if (errno == ENOENT)
-return libxl__devid_to_localdev(gc, devid);
+return libxl__devid_to_vdev(gc, devid);
 else
 return NULL;
 }
@@ -3137,7 +3137,7 @@ static void local_device_attach_cb(libxl__egc *egc, 
libxl__ao_device *aodev)
 {
 STATE_AO_GC(aodev->ao);
 libxl__disk_local_state *dls = CONTAINER_OF(aodev, *dls, aodev);
-char *dev = NULL, *be_path = NULL;
+char *be_path = NULL;
 int rc;
 libxl__device device;
 libxl_device_disk *disk = >disk;
@@ -3151,9 +3151,6 @@ static void local_device_attach_cb(libxl__egc *egc, 
libxl__ao_device *aodev)
 goto out;
 }
 
-dev = GCSPRINTF("/dev/%s", disk->vdev);
-LOG(DEBUG, "locally attaching disk %s", dev);
-
 rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, );
 if (rc < 0)
 goto out;
@@ -3162,8 +3159,9 @@ static void local_device_attach_cb(libxl__egc *egc, 
libxl__ao_device *aodev)
 if (rc < 0)
 goto out;
 
-if (dev != NULL)
-dls->diskpath = libxl__strdup(gc, dev);
+dls->diskpath = GCSPRINTF("/dev/%s",
+  libxl__devid_to_localdev(gc, device.devid));
+LOG(DEBUG, "locally attached disk %s", dls->diskpath);
 
 dls->callback(egc, dls, 0);
 return;
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8bb5e93..f5b8bf6 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -436,6 +436,63 @@ int libxl__device_disk_dev_number(const char *virtpath, 
int *pdisk,
 return -1;
 }
 
+static char *encode_disk_name(char *ptr, unsigned int n)
+{
+if (n >= 26)
+ptr = encode_disk_name(ptr, n / 26 - 1);
+*ptr = 'a' + n % 26;
+return ptr + 1;
+}
+
+char *libxl__devid_to_vdev(libxl__gc *gc, int devid)
+{
+unsigned int minor;
+int offset;
+int nr_parts;
+char *ptr = NULL;
+/* Same as in Linux.
+ * encode_disk_name might end up using up to 29 bytes (BUFFER_SIZE - 3)
+ * including the trailing \0.
+ *
+ * The code is safe because 26 raised to the power of 28 (that is the
+ * maximum offset that can be stored in the allocated buffer as a
+ * string) is far greater than UINT_MAX on 64 bits so offset cannot be
+ * big enough to exhaust the available bytes in ret. */
+#define BUFFER_SIZE 32
+char *ret = libxl__zalloc(gc, BUFFER_SIZE);
+
+#define EXT_SHIFT 28
+#define EXTENDED (1<

[Xen-devel] AMD PVH: Status of patches

[Sherry Hurwitz]

Last fall there were patches under discussion to add PVH support for AMD 
systems.
The work was started by Mukesh Rathor of Oracle and then continued by 
Elena Ufimtseva.
I don't see that those patches ever made it into xen unstable. Was the 
work discontinued
because of a change of focus to HVMlite?  If not, I was looking into 
picking that work up if Elena
had moved on to something else.  Would it make more sense to now let PVH 
go and focus on

HVMlite?

Thanks for any suggestion or guidance.

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

Re: [Xen-devel] [PATCH] docs: Update README to include Clang

[Doug Goldstein]

On 2/25/16 9:59 AM, Andrew Cooper wrote:
> Xen now builds on x86 with Clang 3.5 and 3.8.  Update README to reflect this.
> 
> Mark Clang as no longer a permitted failure in Travis, to prevent future
> regressions slipping back in.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Ian Campbell 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Doug Goldstein 
> 
> N.B. Older versions of Clang are expected to work, but I currently don't have
> an easy way of testing this.
> ---
>  .travis.yml |  2 --
>  README  | 15 +--
>  2 files changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 189d568..b84d38f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -2,8 +2,6 @@ language: c
>  dist: trusty
>  sudo: required
>  matrix:
> -allow_failures:
> -- compiler: clang
>  include:
>  - compiler: gcc
>env: XEN_TARGET_ARCH=x86_64
> diff --git a/README b/README
> index dd36ec8..fe2e7c6 100644
> --- a/README
> +++ b/README
> @@ -35,13 +35,16 @@ Second, there are a number of prerequisites for building 
> a Xen source
>  release. Make sure you have all the following installed, either by
>  visiting the project webpage or installing a pre-built package
>  provided by your OS distributor:
> -* GCC
> -  - For x86 4.1.2_20070115 or later
> -  - For ARM 4.8 or later
>  * GNU Make v3.80 or later
> -* GNU Binutils:
> -  - For x86 2.16.91.0.5 or later
> -  - For ARM 2.24 or later
> +* C compiler and linker:
> +  - For x86:
> +- GCC 4.1.2_20070115 or later
> +- GNU Binutils 2.16.91.0.5 or later
> +or
> +- Clang/LLVM 3.5 or later
> +  - For ARM:
> +- GCC 4.8 or later
> +- GNU Binutils 2.24 or later
>  * Development install of zlib (e.g., zlib-dev)
>  * Development install of Python v2.3 or later (e.g., python-dev)
>  * Development install of curses (e.g., libncurses-dev)
> 

Reviewed-by: Doug Goldstein  for the README
Acked-by: Doug Goldstein  for the .travis.yml

-- 
Doug Goldstein



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

[Xen-devel] [libvirt test] 83944: trouble: broken/fail/pass

[osstest service owner]

flight 83944 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/83944/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  3 host-install(3) broken REGR. vs. 83847

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  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-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass

version targeted for testing:
 libvirt  5ea3a690a28ed1d7ef1253a6e63e236541cceba2
baseline version:
 libvirt  5c79c445c2e15d72a00940cf628d3295cbcb9e58

Last test of basis83847  2016-02-24 09:32:03 Z1 days
Testing same since83944  2016-02-25 04:30:41 Z0 days1 attempts


People who touched revisions under test:
  Eric Blake 
  Joao Martins 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt broken  
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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

broken-step test-armhf-armhf-libvirt host-install(3)

Not pushing.


commit 5ea3a690a28ed1d7ef1253a6e63e236541cceba2
Author: Eric Blake 
Date:   Wed Feb 24 15:02:44 2016 -0700

build: accomodate selinux 2.5 header API change

Yet again, selinux has been adding const-correctness; this change
is ABI-compatible, but breaks API, which affects us when we try to
override things in our testsuite:

../../tests/securityselinuxhelper.c:307:24: error: conflicting types for 
'selabel_open'
 struct selabel_handle *selabel_open(unsigned int backend,
^~~~
In file included from 

Re: [Xen-devel] [PATCH v4 10/11] xen: modify page table construction

[Andrei Borzenkov]

22.02.2016 16:14, Juergen Gross пишет:
> On 22/02/16 13:48, Daniel Kiper wrote:
>> On Mon, Feb 22, 2016 at 01:30:30PM +0100, Juergen Gross wrote:
>>> On 22/02/16 13:18, Daniel Kiper wrote:
 On Mon, Feb 22, 2016 at 10:29:04AM +0100, Juergen Gross wrote:
> On 22/02/16 10:17, Daniel Kiper wrote:
>> On Mon, Feb 22, 2016 at 07:03:18AM +0100, Juergen Gross wrote:
>>> diff --git a/grub-core/lib/xen/relocator.c 
>>> b/grub-core/lib/xen/relocator.c
>>> index 8f427d3..a05b253 100644
>>> --- a/grub-core/lib/xen/relocator.c
>>> +++ b/grub-core/lib/xen/relocator.c
>>> @@ -29,6 +29,11 @@
>>>
>>>  typedef grub_addr_t grub_xen_reg_t;
>>>
>>> +struct grub_relocator_xen_paging_area {
>>> +  grub_xen_reg_t start;
>>> +  grub_xen_reg_t size;
>>> +};
>>> +
>>
>> ... this should have GRUB_PACKED because compiler may
>> add padding to align size member.
>
> Why would the compiler add padding to a structure containing two items
> of the same type? I don't think the C standard would allow this.
>
> grub_xen_reg_t is either unsigned (32 bit) or unsigned long (64 bit).
> There is no way this could require any padding.

 You are right but we should add this here just in case.
>>>
>>> Sorry, I don't think this makes any sense. The C standard is very clear
>>> in this case: a type requiring a special alignment has always a length
>>> being a multiple of that alignment. Otherwise arrays wouldn't work.
>>
>> Sorry, I am not sure what do you mean by that.
> 
> The size of any C type (no matter whether it is an integral type like
> "int" or a structure) has always the same alignment restriction as the
> type itself. So a type requiring 8 byte alignment will always have a
> size of a multiple of 8 bytes. This is mandatory for arrays to work, as
> otherwise either the elements wouldn't be placed consecutively in memory
> or the alignment restrictions wouldn't be obeyed for all elements.
> 

I too not follow how it is relevant to this case. We talk about internal
padding between structure members, not between array elements.

> For our case it means that two structure elements of the same type will
> never require a padding between them, thus the annotation with "packed"
> can't serve any purpose.
> 

Well, I am not aware of any requirement. Compiler may add arbitrary
padding between structure elements; it is only prohibited to add padding
at the beginning. Sure, it would be unusual, but never say "never" ...
also should Xen ever be ported to architecture where types are not
self-aligned it will become an issue.

>>
>>> Adding GRUB_PACKED would make the code less clear IMO. Finding such a
>>> qualifier in some code I want to modify would make me search for the
>>> reason for it which isn't existing.
>>
>> If maintainers do not object I am not going to insist on that any longer.
> 

It seems inconsistent through the code, really. But I think in this case
it should be packed. It does not look like it is performance critical
and it ensures we always match assembler code.


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

[Xen-devel] [PATCH] xen: Introduce separator modifiers for the %ph custom printk

[Andrew Cooper]

The printk formats %*ph{C,D,N} are chosen to be compatible with their Linux
counterparts.

Sample:

  (XEN) buf: 00 01 03 07 78 65 6e 00
  (XEN) buf: 00:01:03:07:78:65:6e:00
  (XEN) buf: 00-01-03-07-78-65-6e-00
  (XEN) buf: 0001030778656e00

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: Ian Campbell 
CC: Konrad Rzeszutek Wilk 
---
 docs/misc/printk-formats.txt |  9 +++--
 xen/common/vsprintf.c| 32 +---
 2 files changed, 36 insertions(+), 5 deletions(-)

diff --git a/docs/misc/printk-formats.txt b/docs/misc/printk-formats.txt
index dee0f3e..525108f 100644
--- a/docs/misc/printk-formats.txt
+++ b/docs/misc/printk-formats.txt
@@ -5,8 +5,13 @@ pointers are fine.  Numbers should make use of the _p() macro.
 
 Raw buffer as hex string:
 
-   %*phUp to 64 characters, printed as "00 01 02 ... ff".  Buffer 
length
-   expected via the field_width paramter. i.e. printk("%*ph", 8, 
buffer);
+   %*ph00 01 02  ...  3f
+   %*phC   00:01:02: ... :3f
+   %*phD   00-01-02- ... -3f
+   %*phN   000102 ... 3f
+
+   Up to 64 characters.  Buffer length expected via the field_width
+   paramter. i.e. printk("%*ph", 8, buffer);
 
 Symbol/Function pointers:
 
diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index 51b5e4e..18d2634 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -275,6 +275,7 @@ static char *pointer(char *str, char *end, const char 
**fmt_ptr,
 case 'h': /* Raw buffer as hex string. */
 {
 const uint8_t *hex_buffer = arg;
+char sep = ' '; /* Separator character. */
 unsigned int i;
 
 /* Consumed 'h' from the format string. */
@@ -286,6 +287,28 @@ static char *pointer(char *str, char *end, const char 
**fmt_ptr,
 if ( field_width > 64 )
 field_width = 64;
 
+/*
+ * Peek ahead in the format string to see if a recognised separator
+ * modifier is present.
+ */
+switch ( fmt[2] )
+{
+case 'C': /* Colons. */
+++*fmt_ptr;
+sep = ':';
+break;
+
+case 'D': /* Dashes. */
+++*fmt_ptr;
+sep = '-';
+break;
+
+case 'N': /* No separator. */
+++*fmt_ptr;
+sep = 0;
+break;
+}
+
 for ( i = 0; ; )
 {
 /* Each byte: 2 chars, 0-padded, base 16, no hex prefix. */
@@ -294,9 +317,12 @@ static char *pointer(char *str, char *end, const char 
**fmt_ptr,
 if ( ++i == field_width )
 return str;
 
-if ( str < end )
-*str = ' ';
-++str;
+if ( sep )
+{
+if ( str < end )
+*str = sep;
+++str;
+}
 }
 }
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v5][RFC]xen: sched: convert RTDS from time to event driven model

[Dario Faggioli]

On Thu, 2016-02-25 at 12:29 -0500, Tianyang Chen wrote:
> On 2/25/2016 5:34 AM, Dario Faggioli wrote:
> > > 
> > Which one ASSERT() fails?
> > 
> The replq_insert() fails because it's already on the replenishment
> queue 
> when rt_vcpu_wake() is trying to insert a vcpu again.
> 
> (XEN) Xen call trace:
> (XEN)[] sched_rt.c#rt_vcpu_wake+0xf0/0x17f
> (XEN)[] vcpu_wake+0x213/0x3d4
> (XEN)[] vcpu_unblock+0x4b/0x4d
> (XEN)[] vcpu_kick+0x20/0x6f
> (XEN)[] vcpu_mark_events_pending+0x2c/0x2f
> (XEN)[]
> event_2l.c#evtchn_2l_set_pending+0xa9/0xb9
> (XEN)[] evtchn_send+0x158/0x183
> (XEN)[] do_event_channel_op+0xe21/0x147d
> (XEN)[] lstar_enter+0xe2/0x13c
> (XEN)
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) Assertion '!__vcpu_on_replq(svc)' failed at sched_rt.c:527
> (XEN) 
>
Ok, makes sense.

> > > And like you
> > > said, mostly spurious sleep
> > > happens when a vcpu is running and it could happen in other
> > > cases,
> > > although rare.
> > > 
> > I think I said already there's no such thing as "spurious sleep".
> > Or at
> > least, I can't think of anything that I would define a spurious
> > sleep,
> > if you do, please, explain what situation you're referring to.
> > 
> I meant to say spurious wakeup... 
>
If, for spurious wakeup, we refer to wakeups happening when the vcpu is
either running or runnable (and hence in the runqueue already), which I
do, we don't even get to call __replq_insert() in those cases. I mean,
we leave rt_vcpu_wake() before that, don't we?

> If rt_vcpu_sleep() removes vcpus from 
> replenishment queue, it's perfectly safe for rt_vcpu_wake() to
> insert 
> them back. 
>
It's safe against sleeps, not against blockings. That's the point I'm
trying to make.

> So, I'm suspecting it's the spurious wakeup that's causing 
> troubles because vcpus are not removed prior to rt_vcpu_wake().
> However, 
> the two RETURNs at the beginning of rt_vcpu_wake() should catch that 
> shouldn't it?
>
Exactly!

> > In any case, one way of dealing with vcpus blocking/offlining/etc
> > could
> > be to, in context_saved(), in case we are not adding the vcpu back
> > to
> > the runq, cancel its replenishment event with __replq_remove().
> > 
> > (This may make it possible to avoid doing it in rt_vcpu_sleep()
> > too,
> > but you'll need to check and test.)
> > 
> > Can you give this a try.
> That makes sense. Doing it in context_saved() kinda implies that if
> a 
> vcpu is sleeping and taken off, its replenishment event should be 
> removed. On the other hand, the logic is the same as removing it in 
> rt_vcpu_sleep() but just at different times.
>
It is, but, if done properly, it catches more cases, or at least that's
what I'm after.

> Well, I have tried it and 
> the check still needs to be there in rt_vcpu_wake(). I will send the 
> next version so it's easier to look at.
> 
If you're still seeing assertion failures, perhaps context_saved() is
not the right place where to do that... I'll think more about this...

Anyway, yes, let's see the code. Please, also send again, as a follow
up email, the assertion failure log you get if you remove the check.

Thanks and Regards,
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 v4 02/11] xen: avoid memleaks on error

[Andrei Borzenkov]

22.02.2016 11:24, Daniel Kiper пишет:
> 
> Are you sure that grub_errno is always set to GRUB_ERR_NONE
> if any GRUB2 function finished successfully?

grub_errno is reset by command parser before command execution (or after
previous command finished actually). During command execution there is
no guarantee that this happens; sometimes grub_errno is explicitly reset
to suppress subsequent errors but in general errors are just passed through.

> Maybe you should
> set initialize grub_errno with GRUB_ERR_NONE at the beginning
> of parse_xen_guest()?
> 
> Daniel
> 
> ___
> Grub-devel mailing list
> grub-de...@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


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

Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Andrei Borzenkov]

25.02.2016 09:39, fu@linaro.org пишет:
> From: Fu Wei 
> 
> delete: xen_linux, xen_initrd, xen_xsm
> add: xen_module
> 
> This update bases on
> commit 0edd750e50698854068358ea53528100a9192902
> Author: Vladimir Serbinenko 
> Date:   Fri Jan 22 10:18:47 2016 +0100
> 
> xen_boot: Remove obsolete module type distinctions.
> 
> Signed-off-by: Fu Wei 
> ---
>  docs/grub.texi | 32 +---
>  1 file changed, 9 insertions(+), 23 deletions(-)
> 
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 82f6fa4..0f99c50 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
> @command{help}
>  * videoinfo::   List available video modes
>  @comment * xen_*::  Xen boot commands
>  * xen_hypervisor::  Load xen hypervisor binary
> -* xen_linux::   Load dom0 kernel for xen hypervisor
> -* xen_initrd::  Load dom0 initrd for dom0 kernel
> -* xen_xsm:: Load xen security module for xen hypervisor
> +* xen_module::  Load xen modules for xen hypervisor
>  @end menu
>  
>  
> @@ -5141,30 +5139,18 @@ verbatim as the @dfn{kernel command-line}. Any other 
> binaries must be
>  reloaded after using this command.
>  @end deffn
>  
> -@node xen_linux
> -@subsection xen_linux
> +@node xen_module
> +@subsection xen_module
>  
> -@deffn Command xen_linux file [arguments]
> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
> +@deffn Command xen_module [--nounzip] file [arguments]
> +Load a module for xen hypervisor at the booting process of xen.
>  The rest of the line is passed verbatim as the module command line.
> +Each module will be identified by the order in which the modules are added.
> +The 1st module: dom0 kernel image
> +The 2nd module: dom0 ramdisk
> +All subsequent modules: UNKNOW
>  @end deffn
>  

Hmm ... from previous discussion I gathered that Xen can detect module
type. What if there is no initrd for dom0? How can subsequent modules be
loaded then?

> -@node xen_initrd
> -@subsection xen_initrd
> -
> -@deffn Command xen_initrd file
> -Load a initrd image for dom0 kernel at the booting process of xen.
> -@end deffn
> -
> -@node xen_xsm
> -@subsection xen_xsm
> -
> -@deffn Command xen_xsm file
> -Load a xen security module for xen hypervisor at the booting process of xen.
> -See @uref{http://wiki.xen.org/wiki/XSM} for more detail.
> -@end deffn
> -
> -
>  @node Networking commands
>  @section The list of networking commands
>  
> 


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

Re: [Xen-devel] [PATCH v5][RFC]xen: sched: convert RTDS from time to event driven model

[Tianyang Chen]

On 2/25/2016 5:34 AM, Dario Faggioli wrote:

+ * it should be re-inserted back to the replenishment queue.
+ */
+if ( now >= svc->cur_deadline)
+{
+rt_update_deadline(now, svc);
+__replq_remove(ops, svc);
+}
+
+if( !__vcpu_on_replq(svc) )
+__replq_insert(ops, svc);
+

And here I am again: is it really necessary to check whether svc is
not
in the replenishment queue? It looks to me that it really should
not be
there... but maybe it can, because we remove the event from the
queue
when the vcpu sleeps, but *not* when the vcpu blocks?

Yeah. That is the case where I keep getting assertion failure if
it's
removed.


Which one ASSERT() fails?

The replq_insert() fails because it's already on the replenishment queue 
when rt_vcpu_wake() is trying to insert a vcpu again.


(XEN) Assertion '!__vcpu_on_replq(svc)' failed at sched_rt.c:527
(XEN) [ Xen-4.7-unstable  x86_64  debug=y  Tainted:C ]
(XEN) CPU:0
(XEN) RIP:e008:[] sched_rt.c#rt_vcpu_wake+0xf0/0x17f
(XEN) RFLAGS: 00010002   CONTEXT: hypervisor (d0v0)
(XEN) rax: 0001   rbx: 83023b522940   rcx: 0001
(XEN) rdx: 0031bb1b9980   rsi: 82d080342318   rdi: 83023b486ca0
(XEN) rbp: 8300bfcffd88   rsp: 8300bfcffd58   r8:  0004
(XEN) r9:  deadbeef   r10: 82d08025f5c0   r11: 0206
(XEN) r12: 83023b486ca0   r13: 8300bfd46000   r14: 82d080299b80
(XEN) r15: 83023b522d80   cr0: 80050033   cr4: 000406a0
(XEN) cr3: 000231c0d000   cr2: 880001e80ba8
(XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
(XEN) Xen stack trace from rsp=8300bfcffd58:
(XEN)8300bfcffd70 8300bfd46000 000216110572 83023b522940
(XEN)82d08032bc00 0282 8300bfcffdd8 82d08012be0c
(XEN)83023b4b5000 83023b4f1000 8300bfd47000 8300bfd46000
(XEN) 83023b4b4280 00014440 0001
(XEN)8300bfcffde8 82d08012c327 8300bfcffe08 82d080169cea
(XEN)83023b4b5000 000a 8300bfcffe18 82d080169d65
(XEN)8300bfcffe38 82d08010762a 83023b4b4280 83023b4b5000
(XEN)8300bfcffe68 82d08010822a 8300bfcffe68 fff2
(XEN)88022056dcb4 880230c34440 8300bfcffef8 82d0801096fc
(XEN)8300bfcffef8 8300bfcfff18 8300bfcffef8 82d080240e85
(XEN)88020001  0246 810013aa
(XEN)000a 810013aa e030 8300bfd47000
(XEN)8802206597f0 880230c34440 00014440 0001
(XEN)7cff403000c7 82d0802439e2 8100140a 0020
(XEN)88022063c7d0 88022063c7d0 0001 dca0
(XEN)88022056dcb8 880230c34440 0206 0004
(XEN)8802230001a0 880220619000 0020 8100140a
(XEN) 88022056dcb4 0004 00010100
(XEN)8100140a e033 0206 88022056dc90
(XEN)e02b   
(XEN) Xen call trace:
(XEN)[] sched_rt.c#rt_vcpu_wake+0xf0/0x17f
(XEN)[] vcpu_wake+0x213/0x3d4
(XEN)[] vcpu_unblock+0x4b/0x4d
(XEN)[] vcpu_kick+0x20/0x6f
(XEN)[] vcpu_mark_events_pending+0x2c/0x2f
(XEN)[] event_2l.c#evtchn_2l_set_pending+0xa9/0xb9
(XEN)[] evtchn_send+0x158/0x183
(XEN)[] do_event_channel_op+0xe21/0x147d
(XEN)[] lstar_enter+0xe2/0x13c
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Assertion '!__vcpu_on_replq(svc)' failed at sched_rt.c:527
(XEN) 

I'm thinking when
a vcpu unblocks, it could potentially fall through here.


Well, when unblocking, wake() is certainly called, yes.


And like you
said, mostly spurious sleep
happens when a vcpu is running and it could happen in other cases,
although rare.


I think I said already there's no such thing as "spurious sleep". Or at
least, I can't think of anything that I would define a spurious sleep,
if you do, please, explain what situation you're referring to.

I meant to say spurious wakeup... If rt_vcpu_sleep() removes vcpus from 
replenishment queue, it's perfectly safe for rt_vcpu_wake() to insert 
them back. So, I'm suspecting it's the spurious wakeup that's causing 
troubles because vcpus are not removed prior to rt_vcpu_wake(). However, 
the two RETURNs at the beginning of rt_vcpu_wake() should catch that 
shouldn't it?

In any case, one way of dealing with vcpus blocking/offlining/etc could
be to, in context_saved(), in case we are not adding the vcpu back to
the runq, cancel its replenishment event with __replq_remove().

(This may make it possible to avoid doing it in rt_vcpu_sleep() too,
but you'll need to check and test.)

Can 

Re: [Xen-devel] [PATCH RFC 0/8] x86/hvm, libxl: HVM SMT topology support

[Andrew Cooper]

On 22/02/16 21:02, Joao Martins wrote:
> Hey!
>
> This series are a follow-up on the thread about the performance
> of hard-pinned HVM guests. Here we propose allowing libxl to
> change how the CPU topology looks like for the HVM guest, which can 
> favor certain workloads as depicted by Elena on this thread [0]. 
> It shows around 22-23% gain on io bound workloads having the guest
> vCPUs hard pinned to the pCPUs with a matching core+thread.
>
> This series is divided as following:
> * Patch 1 : Sets initial apicid to be the vcpuid as opposed
> to vcpuid * 2 for each core;
> * Patch 2 : Whitespace cleanup
> * Patch 3 : Adds new leafs to describe Intel/AMD cache
> topology. Though it's only internal to libxl;
> * Patch 4 : Internal call to set per package CPUID values.
> * Patch 5 - 8 : Interfaces for xl and libxl for setting topology.
>
> I couldn't quite figure out which user interface was better so I
> included both our "smt" option and full description of the topology
> i.e. "sockets", "cores", "threads" option same as the "-smp"
> option on QEMU. Note that the latter could also be used on
> libvirt since topology is described in their XML configs.
>
> It's also an RFC as AMD support isn't implemented yet.
>
> Any comments are appreciated!

Hey.  Sorry I am late getting to this - I am currently swamped.  Some
general observations.

The cpuid policy code in Xen was never re-thought through after
multi-vcpu guests were introduced, which means they have no
understanding of per-package, per-core and per-thread values.

As part of my further cpuid work, I will need to fix this.  I was
planning to fix it by requiring full cpu topology information to be
passed as part of the domaincreate or max_vcpus hypercall  (not chosen
which yet).  This would include cores-per-package, threads-per-core etc,
and allow Xen to correctly fill in the per-core cpuid values in leaves
4, 0xB and 8008.

In particular, I am concerned about giving the toolstack the ability to
blindly control the APIC IDs.  Their layout is very closely linked to
topology, and in particular to the HTT flag.

Overall, I want to avoid any possibility of generating APIC layouts
(including the emulated IOAPIC with HVM guests) which don't conform to
the appropriate AMD/Intel manuals.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 1/8] x86/hvm: set initial apicid to vcpu_id

[Jan Beulich]

>>> On 22.02.16 at 22:02,  wrote:
> Currently the initial_apicid is set vcpu_id * 2 which makes it difficult
> for the toolstack to manage how is the topology seen by the guest.
> Instead of forcing procpkg and proccount to be VCPUID * 2, instead we
> set it to max vcpuid on proccount to max_vcpu_id + 1 (logical number of
> logical cores) and procpkg to max_vcpu_id (max cores minus 1)

I'm afraid it takes more than this to explain why the change is
needed or at least desirable. In particular I'd like to suggest that
you do some archeology to understand why things are the way
they are.

> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4633,7 +4633,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
> unsigned int *ebx,
>  case 0x1:
>  /* Fix up VLAPIC details. */
>  *ebx &= 0x00FFu;
> -*ebx |= (v->vcpu_id * 2) << 24;
> +*ebx |= (v->vcpu_id) << 24;
>  if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
>  __clear_bit(X86_FEATURE_APIC & 31, edx);

In no case is this sufficient as adjustment to the hypervisor side,
as it gets things out of sync with e.g. hvm/vlapic.c.

Jan


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

Re: [Xen-devel] [PATCH] docs/design: introduce HVMMEM_ioreq_serverX types

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 25 February 2016 16:48
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] docs/design: introduce
> HVMMEM_ioreq_serverX types
> 
> >>> On 25.02.16 at 16:49,  wrote:
> > +To allow an IOREQ server to claim or release a claim to a type a new pair
> > +of hypercalls will be introduced:
> > +
> > +- HVMOP\_map\_mem\_type\_to\_ioreq\_server
> > +- HVMOP\_unmap\_mem\_type\_from\_ioreq\_server
> > +
> > +and an associated argument structure:
> > +
> > +   struct hvm_ioreq_mem_type {
> > +   domid_t domid;  /* IN - domain to be serviced */
> > +   ioservid_t id;  /* IN - server id */
> > +   hvmmem_type_t type; /* IN - memory type */
> > +   uint32_t flags; /* IN - types of access to be
> > +   intercepted */
> > +
> > +   #define _HVMOP_IOREQ_MEM_ACCESS_READ 0
> > +   #define HVMOP_IOREQ_MEM_ACCESS_READ \
> > +   (1 << _HVMOP_IOREQ_MEM_ACCESS_READ)
> > +
> > +   #define _HVMOP_IOREQ_MEM_ACCESS_WRITE 1
> > +   #define HVMOP_IOREQ_MEM_ACCESS_WRITE \
> > +   (1 << _HVMOP_IOREQ_MEM_ACCESS_WRITE)
> > +
> > +   };
> 
> How about having just one new hypercall, with flags being zero
> meaning "unmap"?

Hmm, yes we could do it that way. I saves an op code so I'll re-spin the doc.

Thanks,

  Paul

> 
> Jan
> 
> 
> ___
> 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] docs/design: introduce HVMMEM_ioreq_serverX types

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 25 February 2016 16:28
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH] docs/design: introduce
> HVMMEM_ioreq_serverX types
> 
> On 25/02/16 15:49, Paul Durrant wrote:
> > This patch adds a new 'designs' subdirectory under docs as a repository
> > for this and future design proposals.
> >
> > Signed-off-by: Paul Durrant 
> > ---
> >
> > For convenience this document can also be viewed in PDF at:
> >
> > http://xenbits.xen.org/people/pauldu/hvmmem_ioreq_server.pdf
> > ---
> >  docs/designs/hvmmem_ioreq_server.md | 63
> +
> >  1 file changed, 63 insertions(+)
> >  create mode 100755 docs/designs/hvmmem_ioreq_server.md
> 
> If you name it .markdown, the docs buildsystem will be able to publish
> it automatically.  Alternatively, teach the build system about .md.
> 
> On the other hand, .pandoc tends to end up making nicer PDFs.
> 

Ok. Good idea. I'll look at doing that.

> >
> > diff --git a/docs/designs/hvmmem_ioreq_server.md
> b/docs/designs/hvmmem_ioreq_server.md
> > new file mode 100755
> > index 000..47fa715
> > --- /dev/null
> > +++ b/docs/designs/hvmmem_ioreq_server.md
> > @@ -0,0 +1,63 @@
> > +HVMMEM\_ioreq\_serverX
> > +--
> > +
> > +Background
> > +==
> > +
> > +The concept of the IOREQ server was introduced to allow multiple distinct
> > +device emulators to a single VM. The XenGT project uses an IOREQ server
> to
> > +provide mediated pass-through of Intel GPUs to guests and, as part of the
> > +mediation, needs to intercept accesses to GPU page-tables (or GTTs) that
> > +reside in guest RAM.
> > +
> > +The current implementation of this sets the type of GTT pages to type
> > +HVMMEM\_mmio\_write\_dm, which causes Xen to emulate writes to
> such pages,
> > +and then maps the guest physical addresses of those pages to the XenGT
> 
> "then sends the guest physical" surely?
> 
> > +IOREQ server using the HVMOP\_map\_io\_range\_to\_ioreq\_server
> hypercall.
> > +However, because the number of GTTs is potentially large, using this
> > +approach does not scale well.
> > +
> > +Proposal
> > +
> > +
> > +Because the number of spare types available in the P2M type-space is
> > +currently very limited it is proposed that HVMMEM\_mmio\_write\_dm
> be
> > +replaced by a single new type HVMMEM\_ioreq\_server. In future, if the
> > +P2M type-space is increased, this can be renamed to
> HVMMEM\_ioreq\_server0
> > +and new HVMMEM\_ioreq\_server1, HVMMEM\_ioreq\_server2, etc.
> types
> > +can be added.
> > +
> > +Accesses to a page of type HVMMEM\_ioreq\_serverX should be the
> same as
> > +HVMMEM\_ram\_rw until the type is _claimed_ by an IOREQ server.
> Furthermore
> > +it should only be possible to set the type of a page to
> > +HVMMEM\_ioreq\_serverX if that page is currently of type
> HVMMEM\_ram\_rw.
> > +
> > +To allow an IOREQ server to claim or release a claim to a type a new pair
> > +of hypercalls will be introduced:
> > +
> > +- HVMOP\_map\_mem\_type\_to\_ioreq\_server
> > +- HVMOP\_unmap\_mem\_type\_from\_ioreq\_server
> > +
> > +and an associated argument structure:
> > +
> > +   struct hvm_ioreq_mem_type {
> > +   domid_t domid;  /* IN - domain to be serviced */
> > +   ioservid_t id;  /* IN - server id */
> > +   hvmmem_type_t type; /* IN - memory type */
> > +   uint32_t flags; /* IN - types of access to be
> > +   intercepted */
> > +
> > +   #define _HVMOP_IOREQ_MEM_ACCESS_READ 0
> > +   #define HVMOP_IOREQ_MEM_ACCESS_READ \
> > +   (1 << _HVMOP_IOREQ_MEM_ACCESS_READ)
> 
> (1U << ...)
> 

Yep. Should be.

> > +
> > +   #define _HVMOP_IOREQ_MEM_ACCESS_WRITE 1
> > +   #define HVMOP_IOREQ_MEM_ACCESS_WRITE \
> > +   (1 << _HVMOP_IOREQ_MEM_ACCESS_WRITE)
> > +
> > +   };
> > +
> > +
> > +Once the type has been claimed then the requested types of access to
> any
> > +page of the claimed type will be passed to the IOREQ server for handling.
> > +Only HVMMEM\_ioreq\_serverX types may be claimed.
> 
> LGTM.

Thanks :-)

  Paul

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

[Xen-devel] [ovmf test] 83932: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 65543

version targeted for testing:
 ovmf fed5f4475948fd09cb71ba4c9f3918af1c3a7ba6
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   79 days
Failing since 65593  2015-12-08 23:44:51 Z   78 days   80 attempts
Testing same since83932  2016-02-25 02:13:00 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  Jordan Justen 
  Karyne Mayer 
  Larry Hauch 
  Laszlo Ersek 
  Leekha Shaveta 
  Leif Lindholm 
  Liming Gao 
  Mark Rutland 
  Marvin Haeuser 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Ni, Ruiyu 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Qin Long 
  Qiu Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Chao B 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

(No revision log; it would be 9685 lines long.)

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

[Xen-devel] [PATCH] xen: add hypercall option to temporarily pin a vcpu

[Juergen Gross]

Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
to achieve this by pinning the running thread to cpu 0, but in Dom0
this is not enough: the vcpu must be pinned to physical cpu 0 via
Xen, too.

Add a stable hypercall option SCHEDOP_pin_temp to the sched_op
hypercall to achieve this. It is taking a physical cpu number as
parameter. If pinning is possible (the calling domain has the
privilege to make the call and the cpu is available in the domain's
cpupool) the calling vcpu is pinned to the specified cpu. The old
cpu affinity is saved. To undo the temporary pinning a cpu -1 is
specified. This will restore the original cpu affinity for the vcpu.

Signed-off-by: Juergen Gross 
---
 xen/common/schedule.c  | 98 +++---
 xen/include/public/sched.h | 15 +++
 xen/include/xsm/dummy.h|  6 +++
 xen/include/xsm/xsm.h  |  6 +++
 xen/xsm/dummy.c|  1 +
 xen/xsm/flask/hooks.c  |  7 
 6 files changed, 127 insertions(+), 6 deletions(-)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 434dcfc..ddb5989 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -271,6 +271,12 @@ int sched_move_domain(struct domain *d, struct cpupool *c)
 struct scheduler *old_ops;
 void *old_domdata;
 
+for_each_vcpu ( d, v )
+{
+if ( v->affinity_broken )
+return -EBUSY;
+}
+
 domdata = SCHED_OP(c->sched, alloc_domdata, d);
 if ( domdata == NULL )
 return -ENOMEM;
@@ -670,7 +676,13 @@ int cpu_disable_scheduler(unsigned int cpu)
 if ( cpumask_empty(_affinity) &&
  cpumask_test_cpu(cpu, v->cpu_hard_affinity) )
 {
-printk(XENLOG_DEBUG "Breaking affinity for %pv\n", v);
+if ( v->affinity_broken )
+{
+/* The vcpu is temporarily pinned, can't move it. */
+vcpu_schedule_unlock_irqrestore(lock, flags, v);
+ret = -EBUSY;
+continue;
+}
 
 if (system_state == SYS_STATE_suspend)
 {
@@ -679,6 +691,8 @@ int cpu_disable_scheduler(unsigned int cpu)
 v->affinity_broken = 1;
 }
 
+printk(XENLOG_DEBUG "Breaking affinity for %pv\n", v);
+
 cpumask_setall(v->cpu_hard_affinity);
 }
 
@@ -753,14 +767,22 @@ static int vcpu_set_affinity(
 struct vcpu *v, const cpumask_t *affinity, cpumask_t *which)
 {
 spinlock_t *lock;
+int ret = 0;
 
 lock = vcpu_schedule_lock_irq(v);
 
-cpumask_copy(which, affinity);
+if ( v->affinity_broken )
+{
+ret = -EBUSY;
+}
+else
+{
+cpumask_copy(which, affinity);
 
-/* Always ask the scheduler to re-evaluate placement
- * when changing the affinity */
-set_bit(_VPF_migrating, >pause_flags);
+/* Always ask the scheduler to re-evaluate placement
+ * when changing the affinity */
+set_bit(_VPF_migrating, >pause_flags);
+}
 
 vcpu_schedule_unlock_irq(lock, v);
 
@@ -772,7 +794,7 @@ static int vcpu_set_affinity(
 vcpu_migrate(v);
 }
 
-return 0;
+return ret;
 }
 
 int vcpu_set_hard_affinity(struct vcpu *v, const cpumask_t *affinity)
@@ -979,6 +1001,53 @@ void watchdog_domain_destroy(struct domain *d)
 kill_timer(>watchdog_timer[i]);
 }
 
+static long do_pin_temp(int cpu)
+{
+struct vcpu *v = current;
+spinlock_t *lock;
+long ret = -EINVAL;
+
+lock = vcpu_schedule_lock_irq(v);
+
+if ( cpu == -1 )
+{
+if ( v->affinity_broken )
+{
+cpumask_copy(v->cpu_hard_affinity, v->cpu_hard_affinity_saved);
+v->affinity_broken = 0;
+set_bit(_VPF_migrating, >pause_flags);
+ret = 0;
+}
+}
+else if ( cpu < nr_cpu_ids && cpu >= 0 )
+{
+if ( v->affinity_broken )
+{
+ret = -EBUSY;
+}
+else if ( cpumask_test_cpu(cpu, VCPU2ONLINE(v)) )
+{
+cpumask_copy(v->cpu_hard_affinity_saved, v->cpu_hard_affinity);
+v->affinity_broken = 1;
+cpumask_copy(v->cpu_hard_affinity, cpumask_of(cpu));
+set_bit(_VPF_migrating, >pause_flags);
+ret = 0;
+}
+}
+
+vcpu_schedule_unlock_irq(lock, v);
+
+domain_update_node_affinity(v->domain);
+
+if ( v->pause_flags & VPF_migrating )
+{
+vcpu_sleep_nosync(v);
+vcpu_migrate(v);
+}
+
+return ret;
+}
+
 typedef long ret_t;
 
 #endif /* !COMPAT */
@@ -1088,6 +1157,23 @@ ret_t do_sched_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 break;
 }
 
+case SCHEDOP_pin_temp:
+{
+struct sched_pin_temp sched_pin_temp;
+
+ret = -EFAULT;
+if ( copy_from_guest(_pin_temp, arg, 1) )
+  

Re: [Xen-devel] [PATCH] docs/design: introduce HVMMEM_ioreq_serverX types

[Jan Beulich]

>>> On 25.02.16 at 16:49,  wrote:
> +To allow an IOREQ server to claim or release a claim to a type a new pair
> +of hypercalls will be introduced:
> +
> +- HVMOP\_map\_mem\_type\_to\_ioreq\_server
> +- HVMOP\_unmap\_mem\_type\_from\_ioreq\_server
> +
> +and an associated argument structure:
> +
> + struct hvm_ioreq_mem_type {
> + domid_t domid;  /* IN - domain to be serviced */
> + ioservid_t id;  /* IN - server id */
> + hvmmem_type_t type; /* IN - memory type */
> + uint32_t flags; /* IN - types of access to be
> + intercepted */
> +
> + #define _HVMOP_IOREQ_MEM_ACCESS_READ 0
> + #define HVMOP_IOREQ_MEM_ACCESS_READ \
> + (1 << _HVMOP_IOREQ_MEM_ACCESS_READ)
> +
> + #define _HVMOP_IOREQ_MEM_ACCESS_WRITE 1
> + #define HVMOP_IOREQ_MEM_ACCESS_WRITE \
> + (1 << _HVMOP_IOREQ_MEM_ACCESS_WRITE)
> +
> + };

How about having just one new hypercall, with flags being zero
meaning "unmap"?

Jan


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

Re: [Xen-devel] [PATCH v3 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.

[Anthony PERARD]

On Thu, Feb 25, 2016 at 11:16:18AM -0500, Boris Ostrovsky wrote:
> On 02/25/2016 09:55 AM, Anthony PERARD wrote:
> >Hi all,
> >
> >Many changes in V3:
> >   no more cmdline, but use each modules' cmdline to provide a name for it.
> >   in libxc:
> > - use xc_dom_alloc_segment() to load modules. see patch #1.
> > - avoid duplication of code between PVHv2 and hvmloader for the
> >   initialisation of hvm_start_info.
> >   in xl/libxl:
> > - only one new option, bios_firmware. acpi_firmware is reused, see
> >   patch #6.
> >   in hvmloader:
> > - handle rombios as separate case.
> >   more detail in each patches.
> >
> >I've look at loading the BIOS and the ACPI tables via the toolstack instead
> >of having them embedded in the hvmloader binary.
> 
> This is what I've been trying to do for HVMlite/PVHv2 guests. Roger and I
> have a PoC toolstack code that loads limited ACPI data into the guest but I
> wonder whether these patches already do this.
> 
> I haven't gone over the series in detail yet. Does this allow toolstack to
> load RSDP and then R/XSDT, FADT etc. directly to guest memory or are they
> passed to hvmloader to do so via hvm_start_info? (I think it's the latter
> based on how I read patch 13 but I am not sure).

Those patches only allow to load the DSDT table from a file, rather than
having it embedded in the hvmloader binary.

hvmloader take care of building the RSDT XSDT FADT etc.

And yes, the DSDT table is passed to hvmloader via the hvm_start_info.

-- 
Anthony PERARD

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