Re: [Xen-devel] [PATCH 2/3] x86/xsaves: fix overwriting between non-lazy/lazy xsave[sc]
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()
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(&pcidevs_lock)' with
'spin_lock_recursive(&pcidevs_lock)',
(2). replace all of 'spin_unlock(&pcidevs_lock)' with
'spin_unlock_recursive(&pcidevs_lock)',
(3). _do_not_ touch 'spin_is_locked(&pcidevs_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(&d->page_alloc_lock) and
'spin_lock(&d->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
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
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
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, &intr, 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",
&intr, 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(&desc->lock));
spin_lock(&gicv2.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 called gic_cpu_init
* - desc.lock must be held
- * - arch.t
[Xen-devel] [PATCH v5 15/22] arm/gic: Add ACPI support for GIC preinit
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 02/22] arm/acpi: Add arm specific acpi header file
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 10/22] acpi/table: Introduce acpi_table_get_entry_madt to get specified entry
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,
+ &table_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
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
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 04/22] arm/acpi: Add basic ACPI initialization
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 18/22] arm/acpi: Add a new ACPI initialized function for UART
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 **)&spcr);
+
+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
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, &dt_irq);
-if ( res )
+if ( dt_device_get_irq(device, index, &dt_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
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
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 **)&spcr);
+
+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
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)
&vbase, &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 )
+{
+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, &table);
+
+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,
+ i);
+if ( !header )
+
[Xen-devel] [PATCH v5 08/22] arm/acpi: Parse MADT to map logical cpu to MPIDR and get cpu_possible_map
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, &cpu_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 *)entry)->length !=
sizeof(*entry))
-
#define PREFIX "ACPI: "
bool_t __initdata acpi_noirq; /* skip ACPI IRQ initialization */
diff --git a/
[Xen-devel] [PATCH v5 17/22] arm/acpi: Parse GTDT to initialize timer
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", &rate);
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
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.
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
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
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
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
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, &table);
+
+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(&gicv2_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
/*
* Local variables:
* mode: C
--
2.0.4
___
Xen-devel
[Xen-devel] [PATCH v5 11/22] arm: Introduce a generic way to use a device from acpi
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
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
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
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 Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
___
Xen-de
Re: [Xen-devel] [PATCH V14 4/6] libxl: add pvusb API
>>> 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, &intfs, &num);
> > +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, &drvpath);
> > +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 driver).
But now that if error happens in rebinding to original driver, user will
have to manually deal with driver things, user can do the same when
error ha
[Xen-devel] [xen-unstable test] 83979: regressions - trouble: blocked/broken/fail/pass
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 pass build-i386 pass build-amd64-libvirt
Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Отправлено с 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
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(&svc->q_elem, iter);
-}
+deadline_queue_insert(&__q_elem, svc, &svc->q_elem, runq);
else
{
list_add(&svc->q_elem, &prv->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_vcp
Re: [Xen-devel] Patching error while setting up COLO
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&d=CwICaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=pCAkg_8tEQmGEZZoUlyePZjK7z-6aEmp-n6UrQRLWo4&s=Ww-EAIszC-zQuVcDc4XpigwVbMG_4t2SpTg2PV6HTjM&e= *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?
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
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
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 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
>>> @@ -386
Re: [Xen-devel] Patching error while setting up COLO
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&d=CwICaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=pCAkg_8tEQmGEZZoUlyePZjK7z-6aEmp-n6UrQRLWo4&s=Ww-EAIszC-zQuVcDc4XpigwVbMG_4t2SpTg2PV6HTjM&e= > *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
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
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
> 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
> 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
> 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
> 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
> 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
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
> 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
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
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
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
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(&op->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
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
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&d=CwIFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw&s=81rG3g_B23OhGxLWYNA7Hs6cFJy4VxE2Sdqhr0qe7Ds&e= > > > > > 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&d=CwIFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw&s=-vAQ55Sl3YGAa0EmRYKB2pvrRVa_D6nLQCNiOGz7IeI&e= > > > > - 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&d=CwIFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw&s=uS-WmNmGEeeyytonbMxBCcbSHRzQJXUa6_pvkiGEPh4&e= > > git clone > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_macrosheep_iptables.git&d=CwIFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw&s=ZycjXRwwoyK_M8zU4CS8QsVaLWXzjx8mwtlEEIRlY_I&e= > > git clone > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_torvalds_linux&d=CwIFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw&s=TeB7X5i8Ua7jemThOaxH4oNER5ZMCcs1dyqUxZVIWPY&e= > > git clone > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wencongyang_qemu-2Dcolo&d=CwIFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw&s=2kSeFd9-e3hISEJ1QZB1uzfVs8TxQwFQ_Rt4EuySfu8&e= > > git clone > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_wencongyang_xen&d=CwIFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw&s=ztSkYn_Z-t4_vnCdkHl09RzW8LaD9nnkeebyhac3a_0&e= > > > > 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&d=CwIFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=IitX1U91-NhsQt0q4MJOLQ&m=Vnnj3Mx_nu951rfkiPcsuwuboBSLRcYYu30Uho1r7kw&s=3A6be8ZmUe1yTPFuGHZp3fD_LAtyo_5MW2jdVrBSDcs&e= > > 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 instal
Re: [Xen-devel] [PATCH] docs: spell out limits of security support for qemu-xen
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
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
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
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
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
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 too time consuming
> from my end.
>
> I think what
Re: [Xen-devel] [PATCH v10 12/31] tools/libxl: add back channel support to read stream
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 = &stream->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, &stream->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
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, &dss->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
>> http://lists.xen.org/xen-devel
>
>
> .
>
Re: [Xen-devel] [PATCH v10 07/31] docs/libxl: Introduce CHECKPOINT_CONTEXT to support migration v2 colo streams
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()
> 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
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;
>> +
>> +qmp_parameters_add_string(gc, &args, "filename", state_file);
>> +
>> +return qmp_run_command(gc, domid, "xen-load-
[Xen-devel] [qemu-mainline test] 83965: regressions - trouble: blocked/broken/fail/pass
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 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pa
[Xen-devel] [PATCH v1 0/1] xen/arm: Re-add the Xilinx ZynqMP platform
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
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
> -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
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 p
Re: [Xen-devel] [PATCH v6][RFC]xen: sched: convert RTDS from time to event driven model
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 &rt_priv(ops)->depletedq;
> }
>
> +static inline struct list_head *rt_replq(const struct scheduler
> *ops)
> +{
> +return &rt_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(&svc->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(&svc->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 c
Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
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
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(&batch, &seg,
©.segments[i].status);
+ ret = gntdev_grant_copy_seg(batch, &seg,
©.segments[i].status);
if (ret < 0)
goto out;
cond_resched();
}
- if (batch.nr_ops)
- ret = gntdev_copy(&batch);
+ if (batch->nr_ops)
+ ret = gntdev_copy(batch);
+ kfree(batch);
return ret;
out:
- gntdev_put_pages(&batch);
+ 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
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
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 &rt_priv(ops)->depletedq;
}
+static inline struct list_head *rt_replq(const struct scheduler *ops)
+{
+return &rt_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(&svc->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 list_head *runq, *depletedq, *iter;
+struct list_head *runq, *depletedq, *replq, *
Re: [Xen-devel] AMD PVH: Status of patches
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
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
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
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
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
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
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, &nictype);
+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, &nictype);
-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 = libxl__hotplug_env_nic(gc, dev, env, num_exec);
-if (rc)
-goto out;
-
-rc
[Xen-devel] [PATCH v2 2/7] libxl: introduce an OS-specific function to get the physical-device
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, &major,
&minor))
-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, &major, &minor))
+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, &major, &minor))
+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
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
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 = &dls->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, &device);
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<= 26)
-ptr = encode_disk_name(ptr, n / 26 - 1);
-*ptr = 'a' + n % 26;
-return ptr + 1;
-}
-
char *libxl__devid_to_localdev(libxl__gc *gc, int devid)
{
-unsigned int minor;
-int offset;
-int nr_parts;
-char *ptr = NULL;
-char *ret = libxl__zalloc(gc, BUFFER_SIZE);
-
-if (!VDEV_IS_EXTENDED(devid)) {
-minor = devid & 0xff;
-nr_parts = 16;
-} else {
-minor = BLKIF_MINOR_EXT(devid);
-nr_parts = 256;
-}
-offset = minor / nr_parts;
-
-strcpy(ret, "xvd");
-ptr = encode_disk_name(ret + 3, offset);
-if (minor % nr_parts == 0)
-*ptr = 0;
-else
-/* overflow cannot happen, thanks to the upper bound */
-snprintf(ptr, ret + 32 - ptr,
-"%d", minor & (nr_parts - 1));
-return ret;
+return libxl__devid_to_vdev(gc, devid);
}
/* Hotplug scripts helpers */
--
2.5.4 (Apple Git-61)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] AMD PVH: Status of patches
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
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
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 ../../tests/securityselinuxhelper.c:32:0: /usr/include/selinux/label.h:73:24: not
Re: [Xen-devel] [PATCH v4 10/11] xen: modify page table construction
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
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
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&D 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
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
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
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
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
>>> 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
> -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
> -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
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
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(&online_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, &v->pause_flags);
+/* Always ask the scheduler to re-evaluate placement
+ * when changing the affinity */
+set_bit(_VPF_migrating, &v->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(&d->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, &v->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, &v->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(&sched_pin_temp, arg, 1
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"?
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.
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
