[Xen-devel] [linux-4.19 baseline test] 129313: tolerable FAIL
"Old" tested version had not actually been tested; therefore in this flight we test it, rather than a new candidate. The baseline, if any, is the most recent actually tested revision. flight 129313 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/129313/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail never pass test-amd64-i386-freebsd10-amd64 11 guest-start fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-freebsd10-i386 11 guest-start fail never pass test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail never pass test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
[Xen-devel] [linux-linus test] 129304: regressions - FAIL
flight 129304 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/129304/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-bootfail REGR. vs. 125898 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-amd64-pvgrub 7 xen-bootfail REGR. vs. 125898 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-qemuu-nested-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 125898 test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-i386-pvgrub 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win10-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-qemuu-nested-amd 7 xen-bootfail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-pvhv2-amd 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 125898 test-amd64-amd64-pygrub 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-examine 8 reboot fail REGR. vs. 125898 test-amd64-amd64-rumprun-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host fail REGR. vs. 125898 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 125898 test-amd64-amd64-xl-qemuu-win7-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-amd64-libvirt-xsm 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-rumprun-i386 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl7 xen-boot fail REGR. vs. 125898 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 125898 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 125898 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 125898 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 125898 test-amd64-i386-pair
[Xen-devel] [PATCH v6 23/26] xen/arm: Allow vpl011 to be used by DomU
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU if vpl011 is enabled.
Introduce a new ring struct with only the ring array to avoid a waste of
memory. Introduce separate read_data and write_data functions for
initial domains: vpl011_write_data_xen is very simple and just writes
to the console, while vpl011_read_data_xen is a duplicate of
vpl011_read_data. Although textually almost identical, we are forced to
duplicate the functions because the struct layout is different.
Output characters are printed one by one, potentially leading to
intermixed output of different domains on the console. A follow-up patch
will solve the issue by introducing buffering.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- renable call to vpl011_rx_char_xen from console.c
Changes in v4:
- code style
Changes in v3:
- add in-code comments
- improve existing comments
- remove ifdef around domain_vpl011_init in construct_domU
- add ASSERT
- use SBSA_UART_FIFO_SIZE for in buffer size
- rename ring_enable to backend_in_domain
- rename struct xencons_in to struct vpl011_xen_backend
- rename inring field to xen
- rename helper functions accordingly
- remove unnecessary stub implementation of vpl011_rx_char
- move vpl011_rx_char_xen within the file to avoid the need of a forward
declaration of vpl011_data_avail
- fix small bug in vpl011_rx_char_xen: increment in_prod before using it
to check xencons_queued.
Changes in v2:
- only init if vpl011
- rename vpl011_read_char to vpl011_rx_char
- remove spurious change
- fix coding style
- use different ring struct
- move the write_data changes to their own function
(vpl011_write_data_noring)
- duplicate vpl011_read_data
---
xen/arch/arm/domain_build.c | 9 +-
xen/arch/arm/vpl011.c| 200 +--
xen/drivers/char/console.c | 2 +-
xen/include/asm-arm/vpl011.h | 8 ++
4 files changed, 193 insertions(+), 26 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d81ec53..761accb 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2632,7 +2632,14 @@ static int __init construct_domU(struct domain *d,
if ( rc < 0 )
return rc;
-return construct_domain(d, );
+rc = construct_domain(d, );
+if ( rc < 0 )
+return rc;
+
+if ( kinfo.vpl011 )
+rc = domain_vpl011_init(d, NULL);
+
+return rc;
}
void __init create_domUs(void)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 68452a8..131507e 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -77,6 +77,91 @@ static void vpl011_update_interrupt_status(struct domain *d)
#endif
}
+/*
+ * vpl011_write_data_xen writes chars from the vpl011 out buffer to the
+ * console. Only to be used when the backend is Xen.
+ */
+static void vpl011_write_data_xen(struct domain *d, uint8_t data)
+{
+unsigned long flags;
+struct vpl011 *vpl011 = >arch.vpl011;
+
+VPL011_LOCK(d, flags);
+
+printk("%c", data);
+if (data == '\n')
+printk("DOM%u: ", d->domain_id);
+
+vpl011->uartris |= TXI;
+vpl011->uartfr &= ~TXFE;
+vpl011_update_interrupt_status(d);
+
+VPL011_UNLOCK(d, flags);
+}
+
+/*
+ * vpl011_read_data_xen reads data when the backend is xen. Characters
+ * are added to the vpl011 receive buffer by vpl011_rx_char_xen.
+ */
+static uint8_t vpl011_read_data_xen(struct domain *d)
+{
+unsigned long flags;
+uint8_t data = 0;
+struct vpl011 *vpl011 = >arch.vpl011;
+struct vpl011_xen_backend *intf = vpl011->backend.xen;
+XENCONS_RING_IDX in_cons, in_prod;
+
+VPL011_LOCK(d, flags);
+
+in_cons = intf->in_cons;
+in_prod = intf->in_prod;
+
+smp_rmb();
+
+/*
+ * It is expected that there will be data in the ring buffer when this
+ * function is called since the guest is expected to read the data register
+ * only if the TXFE flag is not set.
+ * If the guest still does read when TXFE bit is set then 0 will be
returned.
+ */
+if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) > 0 )
+{
+unsigned int fifo_level;
+
+data = intf->in[xencons_mask(in_cons, sizeof(intf->in))];
+in_cons += 1;
+smp_mb();
+intf->in_cons = in_cons;
+
+fifo_level = xencons_queued(in_prod, in_cons, sizeof(intf->in));
+
+/* If the FIFO is now empty, we clear the receive timeout interrupt. */
+if ( fifo_level == 0 )
+{
+vpl011->uartfr |= RXFE;
+vpl011->uartris &= ~RTI;
+}
+
+/* If the FIFO is more than half empty, we clear the RX interrupt. */
+if ( fifo_level < sizeof(intf->in) - SBSA_UART_FIFO_LEVEL )
+vpl011->uartris &= ~RXI;
+
+
[Xen-devel] [PATCH v6 15/26] xen/arm: introduce create_domUs
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domain" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domain". Call construct_domU for each domain.
Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids. It holds the max domid among the initial
domains.
Move the discard_initial_modules after DomUs have been built.
First create domUs, then start dom0 -- no point in trying to start dom0
when the cpu is busy.
Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
Reviewed-by: Julien Grall
CC: andrew.coop...@citrix.com
CC: jbeul...@suse.com
---
Changes in v5:
- use dt_property_read_bool
- improve commit message
- code style
- use dt_find_node_by_path instead of dt_find_node_by_name
- use true with is_console
Changes in v4:
- constify parameters
- nr_spis to 0 or GUEST_VPL011_SPI - 32 + 1 depending on vpl011
- remove pointless initializer
- remove change to domain_create for dom0 (useless)
- make construct_domU return error
Changes in v3:
- move patch earlier and introduce empty construct_domU to fix bisection
builds
- fix max_init_domid to actually hold the max domid among initial
domains (instead of max_domid + 1)
- move domain_unpause_by_systemcontroller(dom0) after creating domUs
Changes in v2:
- coding style
- set nr_spis to 32
- introduce create_domUs
---
xen/arch/arm/domain_build.c | 50 +
xen/arch/arm/setup.c| 5 +
xen/include/asm-arm/setup.h | 3 +++
xen/include/asm-x86/setup.h | 2 ++
4 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 3a9c989..d94540e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2307,6 +2308,50 @@ static int __init construct_domain(struct domain *d,
struct kernel_info *kinfo)
return 0;
}
+static int __init construct_domU(struct domain *d,
+ const struct dt_device_node *node)
+{
+return -ENOSYS;
+}
+
+void __init create_domUs(void)
+{
+struct dt_device_node *node;
+const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+
+BUG_ON(chosen == NULL);
+dt_for_each_child_node(chosen, node)
+{
+struct domain *d;
+struct xen_domctl_createdomain d_cfg = {
+.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE,
+.arch.nr_spis = 0,
+.max_vcpus = 1,
+.max_evtchn_port = -1,
+.max_grant_frames = 64,
+.max_maptrack_frames = 1024,
+};
+
+if ( !dt_device_is_compatible(node, "xen,domain") )
+continue;
+
+if ( dt_property_read_bool(node, "vpl011") )
+d_cfg.arch.nr_spis = GUEST_VPL011_SPI - 32 + 1;
+dt_property_read_u32(node, "cpus", _cfg.max_vcpus);
+
+d = domain_create(++max_init_domid, _cfg, false);
+if ( IS_ERR(d) )
+panic("Error creating domain %s", dt_node_name(node));
+
+d->is_console = true;
+
+if ( construct_domU(d, node) != 0 )
+panic("Could not set up domain %s", dt_node_name(node));
+
+domain_unpause_by_systemcontroller(d);
+}
+}
+
int __init construct_dom0(struct domain *d)
{
struct kernel_info kinfo = {};
@@ -2357,10 +2402,7 @@ int __init construct_dom0(struct domain *d)
if ( rc < 0 )
return rc;
-rc = construct_domain(d, );
-discard_initial_modules();
-
-return rc;
+return construct_domain(d, );
}
/*
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b0a5e35..3940982 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -64,11 +64,14 @@ static unsigned long opt_xenheap_megabytes __initdata;
integer_param("xenheap_megabytes", opt_xenheap_megabytes);
#endif
+domid_t __read_mostly max_init_domid;
+
static __used void init_done(void)
{
/* Must be done past setting system_state. */
unregister_init_virtual_region();
+discard_initial_modules();
free_init_memory();
startup_cpu_idle_loop();
}
@@ -963,6 +966,8 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
+create_domUs();
+
domain_unpause_by_systemcontroller(dom0);
/* Switch on to the dynamically allocated stack for the idle vcpu
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 0d787e6..eb0c95f 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -75,6 +75,8 @@ struct bootinfo {
extern struct bootinfo bootinfo;
+extern domid_t max_init_domid;
+
void arch_init_memory(void);
void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
@@ -91,6 +93,7 @@ void acpi_create_efi_mmap_table(struct domain *d,
[Xen-devel] [PATCH v6 18/26] xen/arm: make set_interrupt_ppi able to handle non-PPI
also rename it to set_interrupt.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/domain_build.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index aee92d3..44c7861 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -595,19 +595,20 @@ static int __init write_properties(struct domain *d,
struct kernel_info *kinfo,
typedef __be32 gic_interrupt_t[3];
-static void __init set_interrupt_ppi(gic_interrupt_t interrupt,
- unsigned int irq,
- unsigned int cpumask,
- unsigned int level)
+static void __init set_interrupt(gic_interrupt_t interrupt,
+ unsigned int irq,
+ unsigned int cpumask,
+ unsigned int level)
{
__be32 *cells = interrupt;
+bool is_ppi = !!(irq < 32);
BUG_ON(irq < 16);
-BUG_ON(irq >= 32);
+irq -= (is_ppi) ? 16: 32; /* PPIs start at 16, SPIs at 32 */
/* See linux
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */
-dt_set_cell(, 1, 1); /* is a PPI */
-dt_set_cell(, 1, irq - 16); /* PPIs start at 16 */
+dt_set_cell(, 1, is_ppi); /* is a PPI? */
+dt_set_cell(, 1, irq);
dt_set_cell(, 1, (cpumask << 8) | level);
}
@@ -730,7 +731,7 @@ static int __init make_hypervisor_node(struct domain *d,
* - All CPUs
* TODO: Handle properly the cpumask;
*/
-set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property_interrupts(fdt, , 1);
if ( res )
return res;
@@ -1007,15 +1008,15 @@ static int __init make_timer_node(const struct domain
*d, void *fdt,
irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);
dt_dprintk(" Secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);
dt_dprintk(" Non secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
irq = timer_get_irq(TIMER_VIRT_PPI);
dt_dprintk(" Virt interrupt %u\n", irq);
-set_interrupt_ppi(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property_interrupts(fdt, intrs, 3);
if ( res )
@@ -1604,9 +1605,9 @@ static int __init make_timer_domU_node(const struct
domain *d, void *fdt)
return res;
}
-set_interrupt_ppi(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf,
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
res = fdt_property(fdt, "interrupts", intrs, sizeof (intrs[0]) * 3);
if ( res )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 26/26] xen/arm: split domain_build.c
domain_build.c is too large.
Move all the ACPI specific device tree generating functions from
domain_build.c to acpi/domain_build.c.
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- fix license
Changes in v4:
- rename acpi_dt_build to domain_build.c
- add copyright header
- remove useless #include
- remove acpi_dt_build.h, add domain_build.h
---
xen/arch/arm/acpi/Makefile | 1 +
xen/arch/arm/acpi/domain_build.c | 591 +
xen/arch/arm/domain_build.c| 585 +---
xen/include/asm-arm/domain_build.h | 31 ++
4 files changed, 628 insertions(+), 580 deletions(-)
create mode 100644 xen/arch/arm/acpi/domain_build.c
create mode 100644 xen/include/asm-arm/domain_build.h
diff --git a/xen/arch/arm/acpi/Makefile b/xen/arch/arm/acpi/Makefile
index 23963f8..94ae249 100644
--- a/xen/arch/arm/acpi/Makefile
+++ b/xen/arch/arm/acpi/Makefile
@@ -1,2 +1,3 @@
obj-y += lib.o
+obj-y += domain_build.o
obj-y += boot.init.o
diff --git a/xen/arch/arm/acpi/domain_build.c b/xen/arch/arm/acpi/domain_build.c
new file mode 100644
index 000..ed097d5
--- /dev/null
+++ b/xen/arch/arm/acpi/domain_build.c
@@ -0,0 +1,591 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+
+#define ACPI_DOM0_FDT_MIN_SIZE 4096
+
+static int __init acpi_iomem_deny_access(struct domain *d)
+{
+acpi_status status;
+struct acpi_table_spcr *spcr = NULL;
+unsigned long mfn;
+int rc;
+
+/* Firstly permit full MMIO capabilities. */
+rc = iomem_permit_access(d, 0UL, ~0UL);
+if ( rc )
+return rc;
+
+/* TODO: Deny MMIO access for SMMU, GIC ITS */
+status = acpi_get_table(ACPI_SIG_SPCR, 0,
+(struct acpi_table_header **));
+
+if ( ACPI_FAILURE(status) )
+{
+printk("Failed to get SPCR table\n");
+return -EINVAL;
+}
+
+mfn = spcr->serial_port.address >> PAGE_SHIFT;
+/* Deny MMIO access for UART */
+rc = iomem_deny_access(d, mfn, mfn + 1);
+if ( rc )
+return rc;
+
+/* Deny MMIO access for GIC regions */
+return gic_iomem_deny_access(d);
+}
+
+static int __init acpi_route_spis(struct domain *d)
+{
+int i, res;
+struct irq_desc *desc;
+
+/*
+ * Route the IRQ to hardware domain and permit the access.
+ * The interrupt type will be set by set by the hardware domain.
+ */
+for( i = NR_LOCAL_IRQS; i < vgic_num_irqs(d); i++ )
+{
+/*
+ * TODO: Exclude the SPIs SMMU uses which should not be routed to
+ * the hardware domain.
+ */
+desc = irq_to_desc(i);
+if ( desc->action != NULL)
+continue;
+
+/* XXX: Shall we use a proper devname? */
+res = map_irq_to_domain(d, i, true, "ACPI");
+if ( res )
+return res;
+}
+
+return 0;
+}
+
+static int __init acpi_make_hypervisor_node(const struct kernel_info *kinfo,
+struct membank tbl_add[])
+{
+const char compat[] =
+"xen,xen-"__stringify(XEN_VERSION)"."__stringify(XEN_SUBVERSION)"\0"
+"xen,xen";
+int res;
+/* Convenience alias */
+void *fdt = kinfo->fdt;
+
+dt_dprintk("Create hypervisor node\n");
+
+/* See linux Documentation/devicetree/bindings/arm/xen.txt */
+res = fdt_begin_node(fdt, "hypervisor");
+if ( res )
+return res;
+
+/* Cannot use fdt_property_string due to embedded nulls */
+res = fdt_property(fdt, "compatible", compat, sizeof(compat));
+if ( res )
+return res;
+
+res = acpi_make_efi_nodes(fdt, tbl_add);
+if ( res )
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+/*
+ * Prepare a minimal DTB for Dom0 which contains bootargs, initrd, memory
+ * information, EFI table.
+ */
+static int __init create_acpi_dtb(struct kernel_info *kinfo,
+ struct membank tbl_add[])
+{
+int new_size;
+int ret;
+
+dt_dprintk("Prepare a min DTB for DOM0\n");
+
+/* Allocate min size for DT */
+new_size = ACPI_DOM0_FDT_MIN_SIZE;
+kinfo->fdt = xmalloc_bytes(new_size);
+
+if ( kinfo->fdt == NULL )
+return -ENOMEM;
+
+/* Create a new empty DT for DOM0 */
+ret = fdt_create(kinfo->fdt, new_size);
+if ( ret < 0 )
+
[Xen-devel] [PATCH v6 04/26] xen/arm: increase MAX_MODULES
Xen boot modules need to account not just for Dom0 but also for a few
potential DomUs, each of them coming with their own kernel and initrd.
Increase MAX_MODULES to 32 to allow for more DomUs.
Signed-off-by: Stefano Stabellini
Reviewed-by: Doug Goldstein
---
xen/include/asm-arm/setup.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 0cc3330..f1e4a3f 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -8,7 +8,7 @@
#define NR_MEM_BANKS 128
-#define MAX_MODULES 5 /* Current maximum useful modules */
+#define MAX_MODULES 32 /* Current maximum useful modules */
typedef enum {
BOOTMOD_XEN,
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 24/26] xen/vpl011: buffer out chars when the backend is xen
To avoid mixing the output of different domains on the console, buffer
the output chars and print line by line. Unless the domain has input
from the serial, in which case we want to print char by char for a
smooth user experience.
The size of SBSA_UART_OUT_BUF_SIZE is arbitrary, choose the same size
as VUART_BUF_SIZE used in vuart.c.
Export a function named console_input_domain() to allow others to know
which domains has input at a given time.
Signed-off-by: Stefano Stabellini
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
---
XXX: merge this patch with "xen/arm: Allow vpl011 to be used by DomU" on
commit
Changes in v6:
- fix typo
- add input != NULL check
Changes in v5:
- use rcu_lock in console_input_domain
- rcu_unlock at the end of vpl011_write_data_xen
- add a comment on top of console_input_domain as a reminder that the
caller needs to rcu_unlock
Changes in v4:
- make SBSA_UART_OUT_BUF_SIZE the same size of VUART_BUF_SIZE
- rearrange the code to be clearer input and != input cases
- code style
- add \n when printing the out buffer because is full
- don't print prefix for input domain
---
xen/arch/arm/vpl011.c| 37 ++---
xen/drivers/char/console.c | 8
xen/include/asm-arm/vpl011.h | 4
xen/include/xen/console.h| 2 ++
4 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index 131507e..719a339 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -85,18 +86,48 @@ static void vpl011_write_data_xen(struct domain *d, uint8_t
data)
{
unsigned long flags;
struct vpl011 *vpl011 = >arch.vpl011;
+struct vpl011_xen_backend *intf = vpl011->backend.xen;
+struct domain *input = console_input_domain();
VPL011_LOCK(d, flags);
-printk("%c", data);
-if (data == '\n')
-printk("DOM%u: ", d->domain_id);
+intf->out[intf->out_prod++] = data;
+if ( d == input )
+{
+if ( intf->out_prod == 1 )
+{
+printk("%c", data);
+intf->out_prod = 0;
+}
+else
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("%s", intf->out);
+intf->out_prod = 0;
+}
+}
+else
+{
+if ( intf->out_prod == SBSA_UART_OUT_BUF_SIZE - 2 ||
+ data == '\n' )
+{
+if ( data != '\n' )
+intf->out[intf->out_prod++] = '\n';
+intf->out[intf->out_prod++] = '\0';
+printk("DOM%u: %s", d->domain_id, intf->out);
+intf->out_prod = 0;
+}
+}
vpl011->uartris |= TXI;
vpl011->uartfr &= ~TXFE;
vpl011_update_interrupt_status(d);
VPL011_UNLOCK(d, flags);
+if ( input != NULL )
+rcu_unlock_domain(input);
}
/*
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 65fd406..fa6569d 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -406,6 +406,14 @@ static void dump_console_ring_key(unsigned char key)
*/
static unsigned int __read_mostly console_rx = 0;
+/* Make sure to rcu_unlock_domain after use */
+struct domain *console_input_domain(void)
+{
+if ( console_rx == 0 )
+return NULL;
+return rcu_lock_domain_by_id(console_rx - 1);
+}
+
static void switch_serial_input(void)
{
if ( console_rx == max_init_domid + 1 )
diff --git a/xen/include/asm-arm/vpl011.h b/xen/include/asm-arm/vpl011.h
index 5eb6d25..12576a4 100644
--- a/xen/include/asm-arm/vpl011.h
+++ b/xen/include/asm-arm/vpl011.h
@@ -30,9 +30,13 @@
#define VPL011_UNLOCK(d,flags) spin_unlock_irqrestore(&(d)->arch.vpl011.lock,
flags)
#define SBSA_UART_FIFO_SIZE 32
+/* Same size as VUART_BUF_SIZE, used in vuart.c */
+#define SBSA_UART_OUT_BUF_SIZE 128
struct vpl011_xen_backend {
char in[SBSA_UART_FIFO_SIZE];
+char out[SBSA_UART_OUT_BUF_SIZE];
XENCONS_RING_IDX in_cons, in_prod;
+XENCONS_RING_IDX out_prod;
};
struct vpl011 {
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index 70c9911..c5a85c8 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -31,6 +31,8 @@ void console_end_sync(void);
void console_start_log_everything(void);
void console_end_log_everything(void);
+struct domain *console_input_domain(void);
+
/*
* Steal output from the console. Returns +ve identifier, else -ve error.
* Takes the handle of the serial line to steal, and steal callback function.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
[Xen-devel] [PATCH v6 22/26] xen: support console_switching between Dom0 and DomUs on ARM
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for switching between Xen, Dom0, and any of the
initial DomU created from Xen alongside Dom0 out of information provided
via device tree.
Rename xen_rx to console_rx to match the new behavior.
Clarify existing comment about "notify the guest", making it clear that
it is only about the hardware domain.
Switching the console input to domUs started from Xen at boot is
#ifdef'ed to 0 in this patch. The code will be enabled when
vpl011_rx_char_xen is introduced. For now it is disabled for
bisectability.
Signed-off-by: Stefano Stabellini
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
---
Changes in v6:
- improve in-code comment
- improve commit messahe
- code style
Changes in v5:
- move patch earlier and disable code that calls vpl011_rx_char_xen (not
defined yet)
- improve comments
- replace ifs with a switch
- code style
Changes in v4:
- handle console_rx == 0 in console_input_domain
- use rcu_lock_by_domain instead of get_domain_by_id
- handle the case where the returned domain is NULL
- send_global_virq(VIRQ_CONSOLE) only when chars are for Dom0
- make console_rx unsigned int
- fix comment
- code readability improvement
- fix opt_conswitch[1] == 'x' case
- move console_input_domain to next patch
Changes in v3:
- only call vpl011 functions ifdef CONFIG_SBSA_VUART_CONSOLE
- add blank line and spaces
- remove xen_rx from print messages
- rename xen_rx to console_rx
- keep switch_serial_input() at boot
- add better comments
- fix existing comment
- add warning if no guests console/uart is available
- add console_input_domain function
Changes in v2:
- only call vpl011_rx_char if the vpl011 has been initialized
---
xen/drivers/char/console.c | 82 ++
1 file changed, 68 insertions(+), 14 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 3b75f7a..8a01a43 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -31,10 +31,13 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86
#include
#include
+#else
+#include
#endif
/* console: comma-separated list of console outputs. */
@@ -391,31 +394,82 @@ static void dump_console_ring_key(unsigned char key)
free_xenheap_pages(buf, order);
}
-/* CTRL- switches input direction between Xen and DOM0. */
+/*
+ * CTRL- changes input direction, rotating among Xen, Dom0,
+ * and the DomUs started from Xen at boot.
+ */
#define switch_code (opt_conswitch[0]-'a'+1)
-static int __read_mostly xen_rx = 1; /* FALSE => input passed to domain 0. */
+/*
+ * console_rx=0 => input to xen
+ * console_rx=1 => input to dom0
+ * console_rx=N => input to dom(N-1)
+ */
+static unsigned int __read_mostly console_rx = 0;
static void switch_serial_input(void)
{
-static char *input_str[2] = { "DOM0", "Xen" };
-xen_rx = !xen_rx;
-printk("*** Serial input -> %s", input_str[xen_rx]);
+if ( console_rx == max_init_domid + 1 )
+{
+console_rx = 0;
+printk("*** Serial input to Xen");
+}
+else
+{
+console_rx++;
+printk("*** Serial input to DOM%d", console_rx - 1);
+}
+
if ( switch_code )
-printk(" (type 'CTRL-%c' three times to switch input to %s)",
- opt_conswitch[0], input_str[!xen_rx]);
+printk(" (type 'CTRL-%c' three times to switch input)",
+ opt_conswitch[0]);
printk("\n");
}
static void __serial_rx(char c, struct cpu_user_regs *regs)
{
-if ( xen_rx )
+switch ( console_rx )
+{
+case 0:
return handle_keypress(c, regs);
-/* Deliver input to guest buffer, unless it is already full. */
-if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
-serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
-/* Always notify the guest: prevents receive path from getting stuck. */
-send_global_virq(VIRQ_CONSOLE);
+case 1:
+/*
+ * Deliver input to the hardware domain buffer, unless it is
+ * already full.
+ */
+if ( (serial_rx_prod - serial_rx_cons) != SERIAL_RX_SIZE )
+serial_rx_ring[SERIAL_RX_MASK(serial_rx_prod++)] = c;
+
+/*
+ * Always notify the hardware domain: prevents receive path from
+ * getting stuck.
+ */
+send_global_virq(VIRQ_CONSOLE);
+break;
+
+#if 0
+default:
+{
+struct domain *d = rcu_lock_domain_by_any_id(console_rx - 1);
+
+/*
+ * If we have a properly initialized vpl011 console for the
+ * domain, without a full PV ring to Dom0 (in that case input
+ * comes from the PV ring), then send the character to it.
+ */
+if ( d != NULL &&
+ !d->arch.vpl011.backend_in_domain &&
+
[Xen-devel] [PATCH v6 07/26] xen/arm: don't add duplicate boot modules, introduce domU flag
Don't add duplicate boot modules (same kind and same start address),
they are freed later, we don't want to introduce double-free errors.
Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
it for kernels and ramdisks of "xen,domain" nodes to avoid getting
confused in kernel_probe, where we try to guess which is the dom0 kernel
and initrd to be compatible with all versions of the multiboot spec.
boot_module_find_by_kind and boot_cmdline_find_by_kind automatically
check for !domU entries (they are only used for non-domU modules).
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- update comments
Changes in v5:
- improve commit message
- add in-code comments
Changes in v4:
- use unsigned int
- better commit message
- introduce domU flag and usage
Changes in v2:
- new patch
---
xen/arch/arm/bootfdt.c | 11 +++
xen/arch/arm/setup.c| 34 +-
xen/include/asm-arm/setup.h | 12 ++--
3 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 07a9037..8d9ba47 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -175,6 +175,7 @@ static void __init process_multiboot_node(const void *fdt,
int node,
int len = 8; /* sizeof "/chosen" */
char path[8];
int parent_node, ret;
+bool domU;
parent_node = fdt_parent_offset(fdt, node);
ASSERT(parent_node >= 0);
@@ -230,12 +231,14 @@ static void __init process_multiboot_node(const void
*fdt, int node,
kind = BOOTMOD_XSM;
}
-add_boot_module(kind, start, size);
+domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
+add_boot_module(kind, start, size, domU);
prop = fdt_get_property(fdt, node, "bootargs", );
if ( !prop )
return;
-add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data, kind);
+add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data,
+ kind, domU);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -281,7 +284,7 @@ static void __init process_chosen_node(const void *fdt, int
node,
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
-add_boot_module(BOOTMOD_RAMDISK, start, end-start);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
}
static int __init early_scan_node(const void *fdt,
@@ -352,7 +355,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
if ( ret < 0 )
panic("No valid device tree\n");
-add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt));
+add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
early_print_info();
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2098591..c69e872 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -201,10 +201,12 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t e,
}
struct bootmodule __init *add_boot_module(bootmodule_kind kind,
- paddr_t start, paddr_t size)
+ paddr_t start, paddr_t size,
+ bool domU)
{
struct bootmodules *mods =
struct bootmodule *mod;
+unsigned int i;
if ( mods->nr_mods == MAX_MODULES )
{
@@ -212,15 +214,31 @@ struct bootmodule __init *add_boot_module(bootmodule_kind
kind,
boot_module_kind_as_string(kind), start, start + size);
return NULL;
}
+for ( i = 0 ; i < mods->nr_mods ; i++ )
+{
+mod = >module[i];
+if ( mod->kind == kind && mod->start == start )
+{
+if ( !domU )
+mod->domU = false;
+return mod;
+}
+}
mod = >module[mods->nr_mods++];
mod->kind = kind;
mod->start = start;
mod->size = size;
+mod->domU = domU;
return mod;
}
+/*
+ * boot_module_find_by_kind can only be used to return Xen modules (e.g
+ * XSM, DTB) or Dom0 modules. This is not suitable for looking up guest
+ * modules.
+ */
struct bootmodule * __init boot_module_find_by_kind(bootmodule_kind kind)
{
struct bootmodules *mods =
@@ -229,14 +247,14 @@ struct bootmodule * __init
boot_module_find_by_kind(bootmodule_kind kind)
for (i = 0 ; i < mods->nr_mods ; i++ )
{
mod = >module[i];
-if ( mod->kind == kind )
+if ( mod->kind == kind && !mod->domU )
return mod;
}
return NULL;
}
void __init add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind)
+ bootmodule_kind kind, bool domU)
{
struct bootcmdlines *cmds =
struct bootcmdline *cmd;
@@ -249,6 +267,7 @@ void __init add_boot_cmdline(const char *name, const char
*cmdline,
cmd = >cmdline[cmds->nr_mods++];
[Xen-devel] [PATCH v6 25/26] xen/arm: move kernel.h to asm-arm/
It will be #included by a file in a xen/arch/arm subdirectory.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/domain_build.c | 2 +-
xen/arch/arm/kernel.c| 3 +-
xen/arch/arm/kernel.h| 86
xen/include/asm-arm/kernel.h | 86
4 files changed, 88 insertions(+), 89 deletions(-)
delete mode 100644 xen/arch/arm/kernel.h
create mode 100644 xen/include/asm-arm/kernel.h
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 761accb..32ed5aa 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,7 +26,6 @@
#include
#include
-#include "kernel.h"
static unsigned int __initdata opt_dom0_max_vcpus;
integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index d6c810b..6dd9901 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -16,8 +16,7 @@
#include
#include
-
-#include "kernel.h"
+#include
#define UIMAGE_MAGIC 0x27051956
#define UIMAGE_NMLEN 32
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
deleted file mode 100644
index 33f3e72..000
--- a/xen/arch/arm/kernel.h
+++ /dev/null
@@ -1,86 +0,0 @@
-/*
- * Kernel image loading.
- *
- * Copyright (C) 2011 Citrix Systems, Inc.
- */
-#ifndef __ARCH_ARM_KERNEL_H__
-#define __ARCH_ARM_KERNEL_H__
-
-#include
-#include
-
-struct kernel_info {
-#ifdef CONFIG_ARM_64
-enum domain_type type;
-#endif
-
-struct domain *d;
-
-void *fdt; /* flat device tree */
-paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
-struct meminfo mem;
-
-/* kernel entry point */
-paddr_t entry;
-
-/* grant table region */
-paddr_t gnttab_start;
-paddr_t gnttab_size;
-
-/* boot blob load addresses */
-const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
-const char* cmdline;
-paddr_t dtb_paddr;
-paddr_t initrd_paddr;
-
-/* Enable pl011 emulation */
-bool vpl011;
-
-/* loader to use for this kernel */
-void (*load)(struct kernel_info *info);
-/* loader specific state */
-union {
-struct {
-paddr_t kernel_addr;
-paddr_t len;
-#ifdef CONFIG_ARM_64
-paddr_t text_offset; /* 64-bit Image only */
-#endif
-paddr_t start; /* 32-bit zImage only */
-} zimage;
-};
-};
-
-/*
- * Probe the kernel to detemine its type and select a loader.
- *
- * Sets in info:
- * ->type
- * ->load hook, and sets loader specific variables ->zimage
- */
-int kernel_probe(struct kernel_info *info, const struct dt_device_node
*domain);
-
-/*
- * Loads the kernel into guest RAM.
- *
- * Expects to be set in info when called:
- * ->mem
- * ->fdt
- *
- * Sets in info:
- * ->entry
- * ->dtb_paddr
- * ->initrd_paddr
- */
-void kernel_load(struct kernel_info *info);
-
-#endif /* #ifdef __ARCH_ARM_KERNEL_H__ */
-
-/*
- * Local variables:
- * mode: C
- * c-file-style: "BSD"
- * c-basic-offset: 4
- * indent-tabs-mode: nil
- * End:
- */
diff --git a/xen/include/asm-arm/kernel.h b/xen/include/asm-arm/kernel.h
new file mode 100644
index 000..33f3e72
--- /dev/null
+++ b/xen/include/asm-arm/kernel.h
@@ -0,0 +1,86 @@
+/*
+ * Kernel image loading.
+ *
+ * Copyright (C) 2011 Citrix Systems, Inc.
+ */
+#ifndef __ARCH_ARM_KERNEL_H__
+#define __ARCH_ARM_KERNEL_H__
+
+#include
+#include
+
+struct kernel_info {
+#ifdef CONFIG_ARM_64
+enum domain_type type;
+#endif
+
+struct domain *d;
+
+void *fdt; /* flat device tree */
+paddr_t unassigned_mem; /* RAM not (yet) assigned to a bank */
+struct meminfo mem;
+
+/* kernel entry point */
+paddr_t entry;
+
+/* grant table region */
+paddr_t gnttab_start;
+paddr_t gnttab_size;
+
+/* boot blob load addresses */
+const struct bootmodule *kernel_bootmodule, *initrd_bootmodule;
+const char* cmdline;
+paddr_t dtb_paddr;
+paddr_t initrd_paddr;
+
+/* Enable pl011 emulation */
+bool vpl011;
+
+/* loader to use for this kernel */
+void (*load)(struct kernel_info *info);
+/* loader specific state */
+union {
+struct {
+paddr_t kernel_addr;
+paddr_t len;
+#ifdef CONFIG_ARM_64
+paddr_t text_offset; /* 64-bit Image only */
+#endif
+paddr_t start; /* 32-bit zImage only */
+} zimage;
+};
+};
+
+/*
+ * Probe the kernel to detemine its type and select a loader.
+ *
+ * Sets in info:
+ * ->type
+ * ->load hook, and sets loader specific variables ->zimage
+ */
+int kernel_probe(struct kernel_info *info, const struct dt_device_node
*domain);
+
+/*
+ * Loads the kernel into guest RAM.
+ *
+ * Expects to be set in info when called:
+ * ->mem
+ * ->fdt
+ *
+ * Sets in info:
+ * ->entry
+ *
[Xen-devel] [PATCH v6 06/26] xen/arm: introduce bootcmdlines
Introduce a new array to store the cmdline of each boot module. It is
separate from struct bootmodules. Remove the cmdline field from struct
boot_module. This way, kernels and initrds with the same address in
memory can share struct bootmodule (important because we want them to be
free'd only once), but they can still have their separate bootcmdline
entries.
Add a dt_name field to struct bootcmdline to make it easier to find the
correct entry. Store the name of the "xen,domain" compatible node (for
example "Dom1"). This is a better choice compared to the name of the
"multiboot,kernel" compatible node, because their names are not unique.
For instance there can be more than one "module@0x4c00" in the
system, but there can only be one "/chosen/Dom1".
Add a pointer to struct kernel_info to point to the cmdline for a given
kernel.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v6:
- code style
- add ack
Changes in v5:
- remove leftover DEBUG message
- improve commit message
- use kinfo->cmdline when possible
- move add_bood_cmdline to setup.c
Changes in v4:
- check that the multiboot node is under /chosen
- use cmd and cmds as variable names for struct bootcmdline and struct
bootcmdline*
- fix printk
- use ASSERT instea of panic
- do not add empty cmdline entries
- add more debug printks to early_print_info
- code style fixes
- add comment on DT_MAX_NAME
- increase DT_MAX_NAME to 41
- make nr_mods unsigned int
Changes in v3:
- introduce bootcmdlines
- do not modify boot_fdt_cmdline
- add comments
Changes in v2:
- new patch
---
xen/arch/arm/bootfdt.c | 43 ++---
xen/arch/arm/domain_build.c | 12 ++--
xen/arch/arm/kernel.h | 1 +
xen/arch/arm/setup.c| 47 ++---
xen/include/asm-arm/setup.h | 19 --
5 files changed, 87 insertions(+), 35 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index a42fe87..07a9037 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -172,10 +172,12 @@ static void __init process_multiboot_node(const void
*fdt, int node,
const __be32 *cell;
bootmodule_kind kind;
paddr_t start, size;
-const char *cmdline;
int len = 8; /* sizeof "/chosen" */
char path[8];
-int ret;
+int parent_node, ret;
+
+parent_node = fdt_parent_offset(fdt, node);
+ASSERT(parent_node >= 0);
/* Check that the node is under "chosen" */
ret = fdt_get_path(fdt, node, path, len);
@@ -228,17 +230,12 @@ static void __init process_multiboot_node(const void
*fdt, int node,
kind = BOOTMOD_XSM;
}
-prop = fdt_get_property(fdt, node, "bootargs", );
-if ( prop )
-{
-if ( len > BOOTMOD_MAX_CMDLINE )
-panic("module %s command line too long\n", name);
-cmdline = prop->data;
-}
-else
-cmdline = NULL;
+add_boot_module(kind, start, size);
-add_boot_module(kind, start, size, cmdline);
+prop = fdt_get_property(fdt, node, "bootargs", );
+if ( !prop )
+return;
+add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data, kind);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -284,7 +281,7 @@ static void __init process_chosen_node(const void *fdt, int
node,
printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
-add_boot_module(BOOTMOD_RAMDISK, start, end-start, NULL);
+add_boot_module(BOOTMOD_RAMDISK, start, end-start);
}
static int __init early_scan_node(const void *fdt,
@@ -307,6 +304,7 @@ static void __init early_print_info(void)
{
struct meminfo *mi =
struct bootmodules *mods =
+struct bootcmdlines *cmds =
int i, nr_rsvd;
for ( i = 0; i < mi->nr_banks; i++ )
@@ -315,12 +313,12 @@ static void __init early_print_info(void)
mi->bank[i].start + mi->bank[i].size - 1);
printk("\n");
for ( i = 0 ; i < mods->nr_mods; i++ )
-printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s %s\n",
+printk("MODULE[%d]: %"PRIpaddr" - %"PRIpaddr" %-12s\n",
i,
mods->module[i].start,
mods->module[i].start + mods->module[i].size,
- boot_module_kind_as_string(mods->module[i].kind),
- mods->module[i].cmdline);
+ boot_module_kind_as_string(mods->module[i].kind));
+
nr_rsvd = fdt_num_mem_rsv(device_tree_flattened);
for ( i = 0; i < nr_rsvd; i++ )
{
@@ -333,6 +331,11 @@ static void __init early_print_info(void)
i, s, e);
}
printk("\n");
+for ( i = 0 ; i < cmds->nr_mods; i++ )
+printk("CMDLINE[%d]:%s %s\n", i,
+ cmds->cmdline[i].dt_name,
+ >cmdline[i].cmdline[0]);
+printk("\n");
}
/**
@@ -349,7 +352,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t paddr)
if (
[Xen-devel] [PATCH v6 10/26] xen/arm: rename get_11_allocation_size to get_allocation_size
No functional changes.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- no change in print messages
- do not remove BUG_ON
Changes in v2:
- new patch
---
xen/arch/arm/domain_build.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 59c9f34..ca0c4f7 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -77,7 +77,7 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
return vcpu_create(dom0, 0, 0);
}
-static unsigned int __init get_11_allocation_size(paddr_t size)
+static unsigned int __init get_allocation_size(paddr_t size)
{
/*
* get_order_from_bytes returns the order greater than or equal to
@@ -249,7 +249,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
const unsigned int min_order = get_order_from_bytes(MB(4));
struct page_info *pg;
-unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
+unsigned int order = get_allocation_size(kinfo->unassigned_mem);
int i;
bool lowmem = true;
@@ -301,7 +301,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
* If we failed to allocate bank0 under 4GB, continue allocating
* memory from above 4GB and fill in banks.
*/
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
while ( kinfo->unassigned_mem && kinfo->mem.nr_banks < NR_MEM_BANKS )
{
pg = alloc_domheap_pages(d, order, lowmem ? MEMF_bits(32) : 0);
@@ -312,7 +312,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
if ( lowmem && order < min_low_order)
{
D11PRINT("Failed at min_low_order, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
lowmem = false;
continue;
}
@@ -332,7 +332,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
if ( lowmem )
{
D11PRINT("Allocation below bank 0, allow high allocations\n");
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
lowmem = false;
continue;
}
@@ -347,7 +347,7 @@ static void __init allocate_memory(struct domain *d, struct
kernel_info *kinfo)
* Success, next time around try again to get the largest order
* allocation possible.
*/
-order = get_11_allocation_size(kinfo->unassigned_mem);
+order = get_allocation_size(kinfo->unassigned_mem);
}
if ( kinfo->unassigned_mem )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 01/26] xen: allow console_io hypercalls from certain DomUs
Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.
Signed-off-by: Stefano Stabellini
Acked-by: Daniel De Graaf
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
CC: dgde...@tycho.nsa.gov
---
Changes in v3:
- remove changes to hooks.c
Changes in v2:
- introduce is_console
- remove #ifdefs
---
xen/include/xen/sched.h | 2 ++
xen/include/xsm/dummy.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 0ba80cb..abcc74e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -379,6 +379,8 @@ struct domain
bool auto_node_affinity;
/* Is this guest fully privileged (aka dom0)? */
bool is_privileged;
+/* Can this guest access the Xen console? */
+bool is_console;
/* Is this a xenstore domain (not dom0)? */
bool is_xenstore;
/* Domain's VCPUs are pinned 1:1 to physical CPUs? */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b0ac1f6..29d7b50 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -230,6 +230,8 @@ static XSM_INLINE int
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int cmd)
{
XSM_ASSERT_ACTION(XSM_OTHER);
+if ( d->is_console )
+return xsm_default_action(XSM_HOOK, d, NULL);
#ifdef CONFIG_VERBOSE_DEBUG
if ( cmd == CONSOLEIO_write )
return xsm_default_action(XSM_HOOK, d, NULL);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 17/26] xen/arm: generate a simple device tree for domUs
Introduce functions to generate a basic domU device tree, similar to the
existing functions in tools/libxl/libxl_arm.c.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- use d->arch.vgic.version
Changes in v4:
- code style
- two separate functions for gicv2 and gicv3
- remove useless local variables
- fix typos
- do not use host address and size cells for the guest DT
- use #define for addrcells and sizecells
Changes in v3:
- remove CONFIG_ACPI for make_chosen_node
- remove make_hypervisor_node until all Xen related functionalities
(evtchns, grant table, etc.) work correctly
Changes in v2:
- move prepare_dtb rename to previous patch
- use switch for the gic version
- use arm,gic-400 instead of arm,cortex-a15-gic
- add @unit-address in the gic node name
- add comment on DOMU_DTB_SIZE
---
xen/arch/arm/domain_build.c | 235 +++-
1 file changed, 233 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 7b4e34e..aee92d3 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1035,7 +1035,6 @@ static int __init make_timer_node(const struct domain *d,
void *fdt,
return res;
}
-#ifdef CONFIG_ACPI
/*
* This function is used as part of the device tree generation for Dom0
* on ACPI systems, and DomUs started directly from Xen based on device
@@ -1081,7 +1080,6 @@ static int __init make_chosen_node(const struct
kernel_info *kinfo)
return res;
}
-#endif
static int __init map_irq_to_domain(struct domain *d, unsigned int irq,
bool need_mapping, const char *devname)
@@ -1473,6 +1471,235 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
+static int __init make_gicv2_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-400");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICD_BASE, GUEST_GICD_SIZE);
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICC_BASE, GUEST_GICC_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gicv3_domU_node(const struct domain *d, void *fdt)
+{
+int res = 0;
+__be32 reg[(GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS) * 2];
+__be32 *cells;
+
+res = fdt_begin_node(fdt,
"interrupt-controller@"__stringify(GUEST_GICV3_GICD_BASE));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#address-cells", 0);
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "#interrupt-cells", 3);
+if ( res )
+return res;
+
+res = fdt_property(fdt, "interrupt-controller", NULL, 0);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-v3");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICV3_GICD_BASE, GUEST_GICV3_GICD_SIZE);
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS, GUEST_ROOT_SIZE_CELLS,
+ GUEST_GICV3_GICR0_BASE, GUEST_GICV3_GICR0_SIZE);
+
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "linux,phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_property_cell(fdt, "phandle", GUEST_PHANDLE_GIC);
+if (res)
+return res;
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+static int __init make_gic_domU_node(const struct domain *d, void *fdt)
+{
+switch ( d->arch.vgic.version )
+{
+case GIC_V3:
+return make_gicv3_domU_node(d, fdt);
+case GIC_V2:
+return make_gicv2_domU_node(d, fdt);
+default:
+panic("Unsupported GIC version");
+}
+}
+
+static int __init make_timer_domU_node(const struct domain *d, void *fdt)
+{
+int res;
+gic_interrupt_t
[Xen-devel] [PATCH v6 21/26] xen/arm: refactor vpl011_data_avail
Move the code to calculate in_fifo_level and out_fifo_level out of
vpl011_data_avail, to the caller.
This change will make it possible to reuse vpl011_data_avail with
different ring structures in a later patch.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- remove forward declaration of vpl011_data_avail
Changes in v2:
- new patch
---
xen/arch/arm/vpl011.c | 64 +--
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
index ebc045e..68452a8 100644
--- a/xen/arch/arm/vpl011.c
+++ b/xen/arch/arm/vpl011.c
@@ -378,30 +378,13 @@ static const struct mmio_handler_ops vpl011_mmio_handler
= {
.write = vpl011_mmio_write,
};
-static void vpl011_data_avail(struct domain *d)
+static void vpl011_data_avail(struct domain *d,
+ XENCONS_RING_IDX in_fifo_level,
+ XENCONS_RING_IDX in_size,
+ XENCONS_RING_IDX out_fifo_level,
+ XENCONS_RING_IDX out_size)
{
-unsigned long flags;
struct vpl011 *vpl011 = >arch.vpl011;
-struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
-XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
-XENCONS_RING_IDX in_fifo_level, out_fifo_level;
-
-VPL011_LOCK(d, flags);
-
-in_cons = intf->in_cons;
-in_prod = intf->in_prod;
-out_cons = intf->out_cons;
-out_prod = intf->out_prod;
-
-smp_rmb();
-
-in_fifo_level = xencons_queued(in_prod,
- in_cons,
- sizeof(intf->in));
-
-out_fifo_level = xencons_queued(out_prod,
-out_cons,
-sizeof(intf->out));
/ Update the UART RX state /
@@ -410,11 +393,11 @@ static void vpl011_data_avail(struct domain *d)
vpl011->uartfr &= ~RXFE;
/* Set the FIFO_FULL bit if the Xen buffer is full. */
-if ( in_fifo_level == sizeof(intf->in) )
+if ( in_fifo_level == in_size )
vpl011->uartfr |= RXFF;
/* Assert the RX interrupt if the FIFO is more than half way filled. */
-if ( in_fifo_level >= sizeof(intf->in) - SBSA_UART_FIFO_LEVEL )
+if ( in_fifo_level >= in_size - SBSA_UART_FIFO_LEVEL )
vpl011->uartris |= RXI;
/*
@@ -427,7 +410,7 @@ static void vpl011_data_avail(struct domain *d)
/ Update the UART TX state /
-if ( out_fifo_level != sizeof(intf->out) )
+if ( out_fifo_level != out_size )
{
vpl011->uartfr &= ~TXFF;
@@ -445,13 +428,38 @@ static void vpl011_data_avail(struct domain *d)
if ( out_fifo_level == 0 )
vpl011->uartfr |= TXFE;
-
-VPL011_UNLOCK(d, flags);
}
static void vpl011_notification(struct vcpu *v, unsigned int port)
{
-vpl011_data_avail(v->domain);
+unsigned long flags;
+struct domain *d = v->domain;
+struct vpl011 *vpl011 = >arch.vpl011;
+struct xencons_interface *intf = vpl011->backend.dom.ring_buf;
+XENCONS_RING_IDX in_cons, in_prod, out_cons, out_prod;
+XENCONS_RING_IDX in_fifo_level, out_fifo_level;
+
+VPL011_LOCK(d, flags);
+
+in_cons = intf->in_cons;
+in_prod = intf->in_prod;
+out_cons = intf->out_cons;
+out_prod = intf->out_prod;
+
+smp_rmb();
+
+in_fifo_level = xencons_queued(in_prod,
+ in_cons,
+ sizeof(intf->in));
+
+out_fifo_level = xencons_queued(out_prod,
+out_cons,
+sizeof(intf->out));
+
+vpl011_data_avail(v->domain, in_fifo_level, sizeof(intf->in),
+ out_fifo_level, sizeof(intf->out));
+
+VPL011_UNLOCK(d, flags);
}
int domain_vpl011_init(struct domain *d, struct vpl011_init_info *info)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 02/26] xen/arm: extend device tree based multiboot protocol
Extend the existing device tree based multiboot protocol to include
information regarding multiple domains to boot.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- memory is 64bit
Changes in v3:
- remove "xen,initial-domain" for now
- make vpl011 an empty property
- memory in KBs
Changes in v2:
- lower case kernel
- rename mem to memory
- mandate cpus and memory
- replace domU-kernel with kernel and domU-ramdisk with ramdisk
- rename xen,domU with xen,domain
- add info about dom0
- switch memory and cpus to integers
- remove defaults
- add vpl011
---
docs/misc/arm/device-tree/booting.txt | 107 ++
1 file changed, 107 insertions(+)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index ce2d0dc..317a9e9 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -119,3 +119,110 @@ For those you would hardcode the Xen commandline in the
DTB under
line by writing bootargs (as for native Linux).
A Xen-aware bootloader would set xen,xen-bootargs for Xen, xen,dom0-bootargs
for Dom0 and bootargs for native Linux.
+
+
+Creating Multiple Domains directly from Xen
+===
+
+It is possible to have Xen create other domains, in addition to dom0,
+out of the information provided via device tree. A kernel and initrd
+(optional) need to be specified for each guest.
+
+For each domain to be created there needs to be one node under /chosen
+with the following properties:
+
+- compatible
+
+For domUs: "xen,domain"
+
+- memory
+
+ A 64-bit integer specifying the amount of kilobytes of RAM to
+allocate to the guest.
+
+- cpus
+
+An integer specifying the number of vcpus to allocate to the guest.
+
+- vpl011
+
+An empty property to enable/disable a virtual pl011 for the guest to use.
+
+- #address-cells and #size-cells
+
+Both #address-cells and #size-cells need to be specified because
+both sub-nodes (described shortly) have reg properties.
+
+Under the "xen,domain" compatible node, one or more sub-nodes are present
+for the DomU kernel and ramdisk.
+
+The kernel sub-node has the following properties:
+
+- compatible
+
+"multiboot,kernel"
+
+- reg
+
+Specifies the physical address of the kernel in RAM and its
+length.
+
+- bootargs (optional)
+
+Command line parameters for the guest kernel.
+
+The ramdisk sub-node has the following properties:
+
+- compatible
+
+"multiboot,ramdisk"
+
+- reg
+
+Specifies the physical address of the ramdisk in RAM and its
+length.
+
+
+Example
+===
+
+chosen {
+domU1 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 131072>;
+cpus = <2>;
+vpl011;
+
+module@0x4a00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4a00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4b00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4b00 0xff>;
+};
+};
+
+domU2 {
+compatible = "xen,domain";
+#address-cells = <0x2>;
+#size-cells = <0x1>;
+memory = <0 65536>;
+cpus = <1>;
+
+module@0x4c00 {
+compatible = "multiboot,kernel";
+reg = <0x0 0x4c00 0xff>;
+bootargs = "console=ttyAMA0 init=/bin/sh";
+};
+
+module@0x4d00 {
+compatible = "multiboot,ramdisk";
+reg = <0x0 0x4d00 0xff>;
+};
+};
+};
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 08/26] xen/arm: probe domU kernels and initrds
Find addresses, sizes on device tree from kernel_probe.
Find the cmdline from the bootcmdlines array.
Introduce a new boot_module_find_by_addr_and_kind function to match not
just on boot module kind, but also by address so that we can support
multiple domains.
Introduce a boot_cmdline_find_by_name function to find the right struct
cmdline based on the device tree node name of the "xen,domain"
compatible node.
Set command line for dom0 in kernel_probe for consistency.
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- style improvement in comment
- remove redundant cmdline assignment in construct_dom0
Changes in v5:
- constify kernel_probe
- add ASSERT and comment in kernel_probe
- limit variable scope
- fix printk message
- int/unsigned int
- set cmdline for dom0 too
- improve code readability
Changes in v3:
- retrieve cmdline from bootcmdlines array
Changes in v2:
- fix indentation
- unify kernel_probe with kernel_probe_domU
- find cmdline on device_tree from kernel_probe
---
xen/arch/arm/domain_build.c | 4 +--
xen/arch/arm/kernel.c | 64 -
xen/arch/arm/kernel.h | 2 +-
xen/arch/arm/setup.c| 31 ++
xen/include/asm-arm/setup.h | 3 +++
5 files changed, 93 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 6b15bc7..59c9f34 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2107,7 +2107,6 @@ static void __init find_gnttab_region(struct domain *d,
int __init construct_dom0(struct domain *d)
{
-const struct bootcmdline *kernel =
boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
struct kernel_info kinfo = {};
struct vcpu *saved_current;
int rc, i, cpu;
@@ -2135,7 +2134,7 @@ int __init construct_dom0(struct domain *d)
kinfo.unassigned_mem = dom0_mem;
kinfo.d = d;
-rc = kernel_probe();
+rc = kernel_probe(, NULL);
if ( rc < 0 )
return rc;
@@ -2153,7 +2152,6 @@ int __init construct_dom0(struct domain *d)
#endif
-kinfo.cmdline = (kernel != NULL) ? >cmdline[0] : NULL;
allocate_memory(d, );
find_gnttab_region(d, );
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index da8410e..d6c810b 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -421,22 +421,72 @@ static int __init kernel_zimage32_probe(struct
kernel_info *info,
return 0;
}
-int __init kernel_probe(struct kernel_info *info)
+int __init kernel_probe(struct kernel_info *info,
+const struct dt_device_node *domain)
{
-struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+struct bootmodule *mod = NULL;
+struct bootcmdline *cmd = NULL;
+struct dt_device_node *node;
+u64 kernel_addr, initrd_addr, size;
int rc;
+/* domain is NULL only for the hardware domain */
+if ( domain == NULL )
+{
+ASSERT(is_hardware_domain(info->d));
+
+mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
+
+info->kernel_bootmodule = mod;
+info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+
+cmd = boot_cmdline_find_by_kind(BOOTMOD_KERNEL);
+if ( cmd )
+info->cmdline = >cmdline[0];
+}
+else
+{
+const char *name = NULL;
+
+dt_for_each_child_node(domain, node)
+{
+if ( dt_device_is_compatible(node, "multiboot,kernel") )
+{
+u32 len;
+const __be32 *val;
+
+val = dt_get_property(node, "reg", );
+dt_get_range(, node, _addr, );
+mod = boot_module_find_by_addr_and_kind(
+BOOTMOD_KERNEL, kernel_addr);
+info->kernel_bootmodule = mod;
+}
+else if ( dt_device_is_compatible(node, "multiboot,ramdisk") )
+{
+u32 len;
+const __be32 *val;
+
+val = dt_get_property(node, "reg", );
+dt_get_range(, node, _addr, );
+info->initrd_bootmodule = boot_module_find_by_addr_and_kind(
+BOOTMOD_RAMDISK, initrd_addr);
+}
+else
+continue;
+}
+name = dt_node_name(domain);
+cmd = boot_cmdline_find_by_name(name);
+if ( cmd )
+info->cmdline = >cmdline[0];
+}
if ( !mod || !mod->size )
{
printk(XENLOG_ERR "Missing kernel boot module?\n");
return -ENOENT;
}
-info->kernel_bootmodule = mod;
-
-printk("Loading kernel from boot module @ %"PRIpaddr"\n", mod->start);
-
-info->initrd_bootmodule = boot_module_find_by_kind(BOOTMOD_RAMDISK);
+printk("Loading Dom%d kernel from boot module @ %"PRIpaddr"\n",
+ info->d->domain_id, info->kernel_bootmodule->start);
if ( info->initrd_bootmodule )
printk("Loading ramdisk from boot module @
[Xen-devel] [PATCH v6 05/26] xen/arm: check for multiboot nodes only under /chosen
Make sure to only look for multiboot compatible nodes only under
/chosen, not under any other paths (depth <= 3).
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- do not proceed if fdt_get_path returns error != -FDT_ERR_NOSPACE
- remove sizeof, use hardcoded value
Changes in v5:
- add patch
- add check on return value of fdt_get_path
---
xen/arch/arm/bootfdt.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8eba42c..a42fe87 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -173,7 +173,15 @@ static void __init process_multiboot_node(const void *fdt,
int node,
bootmodule_kind kind;
paddr_t start, size;
const char *cmdline;
-int len;
+int len = 8; /* sizeof "/chosen" */
+char path[8];
+int ret;
+
+/* Check that the node is under "chosen" */
+ret = fdt_get_path(fdt, node, path, len);
+if ( (ret != 0 && ret != -FDT_ERR_NOSPACE) ||
+ strncmp(path, "/chosen", len - 1) )
+return;
prop = fdt_get_property(fdt, node, "reg", );
if ( !prop )
@@ -286,8 +294,8 @@ static int __init early_scan_node(const void *fdt,
{
if ( device_tree_node_matches(fdt, node, "memory") )
process_memory_node(fdt, node, name, address_cells, size_cells);
-else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" )
||
- device_tree_node_compatible(fdt, node, "multiboot,module" ))
+else if ( depth <= 3 && (device_tree_node_compatible(fdt, node,
"xen,multiboot-module" ) ||
+ device_tree_node_compatible(fdt, node, "multiboot,module" )))
process_multiboot_node(fdt, node, name, address_cells, size_cells);
else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
process_chosen_node(fdt, node, name, address_cells, size_cells);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 19/26] xen/arm: generate vpl011 node on device tree for domU
Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.
The UART exposed to the guest is a SBSA compatible UART and not a PL011.
SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
would just be too difficult, so guests may require some drivers changes.
Enable vpl011 conditionally if the user requested it.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- use dt_property_read_bool
Changes in v4:
- move rename set_interrupt_ppi and making set_interrupt_ppi generic to
a separate patch
- properly name the vpl011 device node name
- code style
- use #define for addrcells and sizecells
Changes in v3:
- use bool
- retain BUG_ON(irq < 16)
- add vpl011 bool to kinfo
- return error of vpl011 is required but CONFIG_SBSA_VUART_CONSOLE is
missing
Changes in v2:
- code style fixes
- make set_interrupt_ppi generic
- rename set_interrupt_ppi to set_interrupt
- only make the vpl011 node if the option was enabled
---
xen/arch/arm/domain_build.c | 60 +
xen/arch/arm/kernel.h | 3 +++
2 files changed, 63 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 44c7861..d81ec53 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1623,6 +1623,54 @@ static int __init make_timer_domU_node(const struct
domain *d, void *fdt)
return res;
}
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+static int __init make_vpl011_uart_node(const struct domain *d, void *fdt)
+{
+int res;
+gic_interrupt_t intr;
+__be32 reg[GUEST_ROOT_ADDRESS_CELLS + GUEST_ROOT_SIZE_CELLS];
+__be32 *cells;
+
+res = fdt_begin_node(fdt, "sbsa-uart@"__stringify(GUEST_PL011_BASE));
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,sbsa-uart");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS,
+ GUEST_ROOT_SIZE_CELLS, GUEST_PL011_BASE,
+ GUEST_PL011_SIZE);
+if ( res )
+return res;
+res = fdt_property(fdt, "reg", reg, sizeof(reg));
+if ( res )
+return res;
+
+set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+
+res = fdt_property(fdt, "interrupts", intr, sizeof (intr));
+if ( res )
+return res;
+
+res = fdt_property_cell(fdt, "interrupt-parent",
+GUEST_PHANDLE_GIC);
+if ( res )
+return res;
+
+/* Use a default baud rate of 115200. */
+fdt_property_u32(fdt, "current-speed", 115200);
+
+res = fdt_end_node(fdt);
+if ( res )
+return res;
+
+return 0;
+}
+#endif
+
/*
* The max size for DT is 2MB. However, the generated DT is small, 4KB
* are enough for now, but we might have to increase it in the future.
@@ -1684,6 +1732,16 @@ static int __init prepare_dtb_domU(struct domain *d,
struct kernel_info *kinfo)
if ( ret )
goto err;
+if ( kinfo->vpl011 )
+{
+ret = -EINVAL;
+#ifdef CONFIG_SBSA_VUART_CONSOLE
+ret = make_vpl011_uart_node(d, kinfo->fdt);
+#endif
+if ( ret )
+goto err;
+}
+
ret = fdt_end_node(kinfo->fdt);
if ( ret < 0 )
goto err;
@@ -2552,6 +2610,8 @@ static int __init construct_domU(struct domain *d,
printk("*** LOADING DOMU cpus=%u memory=%luKB ***\n", d->max_vcpus, mem);
+kinfo.vpl011 = dt_property_read_bool(node, "vpl011");
+
if ( vcpu_create(d, 0, 0) == NULL )
return -ENOMEM;
d->max_pages = ~0U;
diff --git a/xen/arch/arm/kernel.h b/xen/arch/arm/kernel.h
index 4320f72..33f3e72 100644
--- a/xen/arch/arm/kernel.h
+++ b/xen/arch/arm/kernel.h
@@ -33,6 +33,9 @@ struct kernel_info {
paddr_t dtb_paddr;
paddr_t initrd_paddr;
+/* Enable pl011 emulation */
+bool vpl011;
+
/* loader to use for this kernel */
void (*load)(struct kernel_info *info);
/* loader specific state */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 03/26] xen/arm: document dom0less
Add a new document to provide information on how to use dom0less related
features and their current limitations.
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- convert to markdown
- move to docs/features
- add entry to docs/INDEX
Changes in v4:
- rename to .txt
- improve wording
Changes in v3:
- add patch
---
docs/INDEX | 1 +
docs/features/dom0less.markdown | 49 +
2 files changed, 50 insertions(+)
create mode 100644 docs/features/dom0less.markdown
diff --git a/docs/INDEX b/docs/INDEX
index 868ab1f..e673edd 100644
--- a/docs/INDEX
+++ b/docs/INDEX
@@ -25,3 +25,4 @@ misc/arm/early-printk Enabling early printk on ARM
misc/arm/passthrough Passthrough a device described in the Device
Tree to a guest
misc/arm/device-tree/booting Device tree bindings to boot Xen
misc/arm/device-tree/passthrough Device tree binding to passthrough a
device
+features/dom0less.markdown Boot multiple domains from Xen in parallel
diff --git a/docs/features/dom0less.markdown b/docs/features/dom0less.markdown
new file mode 100644
index 000..4e342b7
--- /dev/null
+++ b/docs/features/dom0less.markdown
@@ -0,0 +1,49 @@
+Dom0less
+
+
+"Dom0less" is a set of Xen features that enable the deployment of a Xen
+system without an control domain (often referred to as "dom0"). Each
+feature can be used independently from the others, unless otherwise
+stated.
+
+Booting Multiple Domains from Device Tree
+-
+
+This feature enables Xen to create a set of DomUs at boot time.
+Information about the DomUs to be created by Xen is passed to the
+hypervisor via Device Tree. Specifically, the existing Device Tree based
+Multiboot specification has been extended to allow for multiple domains
+to be passed to Xen. See docs/misc/arm/device-tree/booting.txt for more
+information about the Multiboot specification and how to use it.
+
+Currently, a control domain ("dom0") is still required, but in the
+future it will become unnecessary when all domains are created
+directly from Xen. Instead of waiting for the control domain to be fully
+booted and the Xen tools to become available, domains created by Xen
+this way are started right away in parallel. Hence, their boot time is
+typically much shorter.
+
+Domains started by Xen at boot time currently have the following
+limitations:
+
+- They cannot be properly shutdown or rebooted using xl. If one of them
+ crashes, the whole platform should be rebooted.
+
+- Some xl operations might not work as expected. xl is meant to be used
+ with domains that have been created by it. Using xl with domains
+ started by Xen at boot might not work as expected.
+
+- The GIC version is the native version. In absence of other
+ information, the GIC version exposed to the domains started by Xen at
+ boot is the same as the native GIC version.
+
+- No PV drivers. There is no support for PV devices at the moment. All
+ devices need to be statically assigned to guests.
+
+- Pinning vCPUs of domains started by Xen at boot can be
+ done from the control domain, using `xl vcpu-pin` as usual. It is not
+ currently possible to configure vCPU pinning without a control domain.
+ However, the NULL scheduler can be selected by passing `sched=null` to
+ the Xen command line. The NULL scheduler automatically assigns and
+ pins vCPUs to pCPUs, but the vCPU-pCPU assignments cannot be
+ configured.
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 14/26] xen/arm: move unregister_init_virtual_region to init_done
Move unregister_init_virtual_region to init_done. Follow the same path
as x86. It is also useful to move it later so that create_domUs can be
called before that in following patches.
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
xen/arch/arm/setup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index a819953..b0a5e35 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -66,6 +66,9 @@ integer_param("xenheap_megabytes", opt_xenheap_megabytes);
static __used void init_done(void)
{
+/* Must be done past setting system_state. */
+unregister_init_virtual_region();
+
free_init_memory();
startup_cpu_idle_loop();
}
@@ -960,9 +963,6 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
-/* Must be done past setting system_state. */
-unregister_init_virtual_region();
-
domain_unpause_by_systemcontroller(dom0);
/* Switch on to the dynamically allocated stack for the idle vcpu
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 16/26] xen/arm: implement construct_domU
Similar to construct_dom0, construct_domU creates a barebone DomU guest.
The device tree node passed as argument is compatible "xen,domain", see
docs/misc/arm/device-tree/booting.txt.
Remove #if 0 from allocate_memory as this patch will start using it.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- move changes to kernel_probe prototype to previous patch
- improve commit message
- remove superflous allocation of d->vcpu
- use mem * SZ_1K
Changes in v4:
- constify kernel_probe
- change title
- better error messages and printed info
- 64bit memory
Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment
Changes in v2:
- rename mem to memory
- make cpus and memory mandatory
- remove wront comment from commit message
- cpus and memory are read as integers
- read the vpl011 option
---
xen/arch/arm/domain_build.c | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d94540e..7b4e34e 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -369,7 +370,6 @@ static void __init allocate_memory_11(struct domain *d,
}
}
-#if 0
static bool __init allocate_bank_memory(struct domain *d,
struct kernel_info *kinfo,
gfn_t sgfn,
@@ -469,7 +469,6 @@ fail:
" %ldKB unallocated. Fix the VMs configurations.\n",
(unsigned long)kinfo->unassigned_mem >> 10);
}
-#endif
static int __init write_properties(struct domain *d, struct kernel_info *kinfo,
const struct dt_device_node *node)
@@ -2311,7 +2310,37 @@ static int __init construct_domain(struct domain *d,
struct kernel_info *kinfo)
static int __init construct_domU(struct domain *d,
const struct dt_device_node *node)
{
-return -ENOSYS;
+struct kernel_info kinfo = {};
+int rc;
+u64 mem;
+
+rc = dt_property_read_u64(node, "memory", );
+if ( !rc )
+{
+printk("Error building DomU: cannot read \"memory\" property\n");
+return -EINVAL;
+}
+kinfo.unassigned_mem = (paddr_t)mem * SZ_1K;
+
+printk("*** LOADING DOMU cpus=%u memory=%luKB ***\n", d->max_vcpus, mem);
+
+if ( vcpu_create(d, 0, 0) == NULL )
+return -ENOMEM;
+d->max_pages = ~0U;
+
+kinfo.d = d;
+
+rc = kernel_probe(, node);
+if ( rc < 0 )
+return rc;
+
+#ifdef CONFIG_ARM_64
+/* type must be set before allocate memory */
+d->arch.type = kinfo.type;
+#endif
+allocate_memory(d, );
+
+return construct_domain(d, );
}
void __init create_domUs(void)
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 11/26] xen/arm: rename allocate_memory to allocate_memory_11
allocate_memory only deals with directly mapped memory. Rename it to
allocate_memory_11.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v3:
- add patch
---
xen/arch/arm/domain_build.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ca0c4f7..66a258a 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -243,7 +243,8 @@ fail:
* (as described above) we allow higher allocations and continue until
* that runs out (or we have allocated sufficient dom0 memory).
*/
-static void __init allocate_memory(struct domain *d, struct kernel_info *kinfo)
+static void __init allocate_memory_11(struct domain *d,
+ struct kernel_info *kinfo)
{
const unsigned int min_low_order =
get_order_from_bytes(min_t(paddr_t, dom0_mem, MB(128)));
@@ -2152,7 +2153,7 @@ int __init construct_dom0(struct domain *d)
#endif
-allocate_memory(d, );
+allocate_memory_11(d, );
find_gnttab_region(d, );
/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 00/25] dom0less step1: boot multiple domains from device tree
Hi all,
This is first step toward "dom0less" as discussed in the various
certifications related threads and discussions.
The goal of this series is to enable Xen to boot multiple domains in
parallel, in addition to dom0, out of information found on device tree.
The device tree based boot protocol is extended to carry information
about DomUs. Based on that information, Xen creates and starts one or
more DomUs. DomUs created this way don't have access to xenstore for the
moment. This is actually OK, because this is meant for mission critical
applications that typically only access directly assigned devices. They
cannot tolerate interference or increased IRQ latency due to PV
protocols. Device assignment is not actually covered by this series, it
will be added later.
DomUs can print to the Xen serial using the CONSOLEIO hypercalls. A
virtual PL011 is also emulated for them so that they can use their
regular PL011 driver. This allows unmodified guests to run as Xen on ARM
guests -- no Xen support needed at all. Console input also comes from
the Xen serial: the Ctrl-AAA switching mechanism is extended to switch
among domUs, dom0, and Xen.
In this version of the series, I reordered the patches to make sure they
are all bisectable.
Cheers,
Stefano
The following changes since commit 359970fd8b781fac2ddcbc84dd5b890075fa08ef:
tools/libxl: Switch Arm guest type to PVH (2018-10-03 15:58:02 +0100)
are available in the git repository at:
http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git
dom0less-v6
for you to fetch changes up to 403ae582e24b30e4e78b015ce2ddba8de07686a9:
xen/arm: split domain_build.c (2018-11-02 15:21:46 -0700)
Stefano Stabellini (26):
xen: allow console_io hypercalls from certain DomUs
xen/arm: extend device tree based multiboot protocol
xen/arm: document dom0less
xen/arm: increase MAX_MODULES
xen/arm: check for multiboot nodes only under /chosen
xen/arm: introduce bootcmdlines
xen/arm: don't add duplicate boot modules, introduce domU flag
xen/arm: probe domU kernels and initrds
xen/arm: add start to struct bootcmdline
xen/arm: rename get_11_allocation_size to get_allocation_size
xen/arm: rename allocate_memory to allocate_memory_11
xen/arm: introduce allocate_memory
xen/arm: refactor construct_dom0
xen/arm: move unregister_init_virtual_region to init_done
xen/arm: introduce create_domUs
xen/arm: implement construct_domU
xen/arm: generate a simple device tree for domUs
xen/arm: make set_interrupt_ppi able to handle non-PPI
xen/arm: generate vpl011 node on device tree for domU
xen/arm: introduce a union in vpl011
xen/arm: refactor vpl011_data_avail
xen: support console_switching between Dom0 and DomUs on ARM
xen/arm: Allow vpl011 to be used by DomU
xen/vpl011: buffer out chars when the backend is xen
xen/arm: move kernel.h to asm-arm/
xen/arm: split domain_build.c
docs/INDEX |1 +
docs/features/dom0less.markdown| 49 ++
docs/misc/arm/device-tree/booting.txt | 107 +++
xen/arch/arm/acpi/Makefile |1 +
xen/arch/arm/acpi/domain_build.c | 591 +++
xen/arch/arm/bootfdt.c | 58 +-
xen/arch/arm/domain_build.c| 1092 +---
xen/arch/arm/kernel.c | 67 +-
xen/arch/arm/setup.c | 112 ++-
xen/arch/arm/vpl011.c | 297 ++--
xen/drivers/char/console.c | 90 ++-
xen/include/asm-arm/domain_build.h | 31 +
xen/{arch/arm => include/asm-arm}/kernel.h |6 +-
xen/include/asm-arm/setup.h| 36 +-
xen/include/asm-arm/vpl011.h | 20 +-
xen/include/asm-x86/setup.h|2 +
xen/include/xen/console.h |2 +
xen/include/xen/sched.h|2 +
xen/include/xsm/dummy.h|2 +
19 files changed, 1861 insertions(+), 705 deletions(-)
create mode 100644 docs/features/dom0less.markdown
create mode 100644 xen/arch/arm/acpi/domain_build.c
create mode 100644 xen/include/asm-arm/domain_build.h
rename xen/{arch/arm => include/asm-arm}/kernel.h (91%)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [qemu-mainline test] 129305: tolerable FAIL - PUSHED
flight 129305 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/129305/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 129266 test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 129266 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 129266 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 129266 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 129266 test-amd64-i386-xl-pvshim12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-amd64-i386-libvirt 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 13 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-checkfail never pass test-arm64-arm64-xl 14 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 13 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-checkfail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass version targeted for testing: qemuuf96a3165ab1c36dbf4cb63e8761fa45457381aca baseline version: qemuua2e002ff7913ce93aa0f7dbedd2123dce5f1a9cd Last test of basis 129266 2018-11-01 00:49:34 Z1 days Testing same since 129305 2018-11-02 00:41:06 Z0 days1 attempts People who touched revisions under test: Bishara AbuHattoum Chen Hanxiao Cleber Rosa Cornelia Huck Daniel P. Berrangé Eduardo Habkost Emilio G. Cota Igor Mammedov Jonathon Reinhart Li Qiang Marc-André Lureau Max Filippov Max Reitz Michael Roth Peter Maydell Philippe Mathieu-Daudé Richard Henderson Robert Hoo Sameeh Jubran Sameeh Jubran Sebastian Andrzej Siewior Stefan Berger Stefan Berger Stefan Hajnoczi Tao Xu Thomas Huth Tomáš Golembiovský Wainer dos Santos Moschetta jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64
[Xen-devel] [PATCH v6 09/26] xen/arm: add start to struct bootcmdline
Add a new start address field to struct bootcmdline to easily match a
cmdline to the corresponding bootmodule. This is useful for debugging
(not actually needed for functionalities today, but could be.)
Instead of printing the index in the cmdline array, print the start
address of the corresponding bootmodule for each cmdline in
early_print_info.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/bootfdt.c | 4 ++--
xen/arch/arm/setup.c| 3 ++-
xen/include/asm-arm/setup.h | 3 ++-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8d9ba47..4f0712a 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -238,7 +238,7 @@ static void __init process_multiboot_node(const void *fdt,
int node,
if ( !prop )
return;
add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data,
- kind, domU);
+ kind, start, domU);
}
static void __init process_chosen_node(const void *fdt, int node,
@@ -335,7 +335,7 @@ static void __init early_print_info(void)
}
printk("\n");
for ( i = 0 ; i < cmds->nr_mods; i++ )
-printk("CMDLINE[%d]:%s %s\n", i,
+printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,
cmds->cmdline[i].dt_name,
>cmdline[i].cmdline[0]);
printk("\n");
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index dbba8f3..a819953 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -254,7 +254,7 @@ struct bootmodule * __init
boot_module_find_by_kind(bootmodule_kind kind)
}
void __init add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind, bool domU)
+ bootmodule_kind kind, paddr_t start, bool domU)
{
struct bootcmdlines *cmds =
struct bootcmdline *cmd;
@@ -268,6 +268,7 @@ void __init add_boot_cmdline(const char *name, const char
*cmdline,
cmd = >cmdline[cmds->nr_mods++];
cmd->kind = kind;
cmd->domU = domU;
+cmd->start = start;
ASSERT(strlen(name) <= DT_MAX_NAME);
safe_strcpy(cmd->dt_name, name);
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 33fb04e..0d787e6 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -49,6 +49,7 @@ struct bootmodule {
struct bootcmdline {
bootmodule_kind kind;
bool domU;
+paddr_t start;
char dt_name[DT_MAX_NAME];
char cmdline[BOOTMOD_MAX_CMDLINE];
};
@@ -104,7 +105,7 @@ struct bootmodule *boot_module_find_by_kind(bootmodule_kind
kind);
struct bootmodule * __init boot_module_find_by_addr_and_kind(bootmodule_kind
kind,
paddr_t start);
void add_boot_cmdline(const char *name, const char *cmdline,
- bootmodule_kind kind, bool domU);
+ bootmodule_kind kind, paddr_t start, bool domU);
struct bootcmdline *boot_cmdline_find_by_kind(bootmodule_kind kind);
struct bootcmdline * __init boot_cmdline_find_by_name(const char *name);
const char * __init boot_module_kind_as_string(bootmodule_kind kind);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 13/26] xen/arm: refactor construct_dom0
Move generic initializations out of construct_dom0 so that they can be
reused.
Rename prepare_dtb to prepare_dtb_hwdom to avoid confusion.
No functional changes in this patch.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Changes in v5:
- rename __construct_domain to construct_domain
Changes in v4:
- newline and style changes
Changes in v3:
- move setting type before allocate_memory
- add ifdef around it and a comment
Changes in v2:
- move discard_initial_modules() after __construct_domain()
- remove useless blank line
- leave safety BUG_ONs in __construct_domain
- rename prepare_dtb to prepare_dtb_hwdom
---
xen/arch/arm/domain_build.c | 122
1 file changed, 66 insertions(+), 56 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 86abcc6..3a9c989 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1473,7 +1473,7 @@ static int __init handle_node(struct domain *d, struct
kernel_info *kinfo,
return res;
}
-static int __init prepare_dtb(struct domain *d, struct kernel_info *kinfo)
+static int __init prepare_dtb_hwdom(struct domain *d, struct kernel_info
*kinfo)
{
const p2m_type_t default_p2mt = p2m_mmio_direct_c;
const void *fdt;
@@ -2208,73 +2208,29 @@ static void __init find_gnttab_region(struct domain *d,
kinfo->gnttab_start, kinfo->gnttab_start + kinfo->gnttab_size);
}
-int __init construct_dom0(struct domain *d)
+static int __init construct_domain(struct domain *d, struct kernel_info *kinfo)
{
-struct kernel_info kinfo = {};
struct vcpu *saved_current;
-int rc, i, cpu;
-
+int i, cpu;
struct vcpu *v = d->vcpu[0];
struct cpu_user_regs *regs = >arch.cpu_info->guest_cpu_user_regs;
-/* Sanity! */
-BUG_ON(d->domain_id != 0);
BUG_ON(d->vcpu[0] == NULL);
BUG_ON(v->is_initialised);
-printk("*** LOADING DOMAIN 0 ***\n");
-if ( dom0_mem <= 0 )
-{
-warning_add("PLEASE SPECIFY dom0_mem PARAMETER - USING 512M FOR
NOW\n");
-dom0_mem = MB(512);
-}
-
-
-iommu_hwdom_init(d);
-
-d->max_pages = ~0U;
-
-kinfo.unassigned_mem = dom0_mem;
-kinfo.d = d;
-
-rc = kernel_probe(, NULL);
-if ( rc < 0 )
-return rc;
-
#ifdef CONFIG_ARM_64
/* if aarch32 mode is not supported at EL1 do not allow 32-bit domain */
-if ( !(cpu_has_el1_32) && kinfo.type == DOMAIN_32BIT )
+if ( !(cpu_has_el1_32) && kinfo->type == DOMAIN_32BIT )
{
printk("Platform does not support 32-bit domain\n");
return -EINVAL;
}
-d->arch.type = kinfo.type;
if ( is_64bit_domain(d) )
vcpu_switch_to_aarch64_mode(v);
#endif
-allocate_memory_11(d, );
-find_gnttab_region(d, );
-
-/* Map extra GIC MMIO, irqs and other hw stuffs to dom0. */
-rc = gic_map_hwdom_extra_mappings(d);
-if ( rc < 0 )
-return rc;
-
-rc = platform_specific_mapping(d);
-if ( rc < 0 )
-return rc;
-
-if ( acpi_disabled )
-rc = prepare_dtb(d, );
-else
-rc = prepare_acpi(d, );
-
-if ( rc < 0 )
-return rc;
-
/*
* The following loads use the domain's p2m and require current to
* be a vcpu of the domain, temporarily switch
@@ -2287,20 +2243,18 @@ int __init construct_dom0(struct domain *d)
* kernel_load will determine the placement of the kernel as well
* as the initrd & fdt in RAM, so call it first.
*/
-kernel_load();
+kernel_load(kinfo);
/* initrd_load will fix up the fdt, so call it before dtb_load */
-initrd_load();
-dtb_load();
+initrd_load(kinfo);
+dtb_load(kinfo);
/* Now that we are done restore the original p2m and current. */
set_current(saved_current);
p2m_restore_state(saved_current);
-discard_initial_modules();
-
memset(regs, 0, sizeof(*regs));
-regs->pc = (register_t)kinfo.entry;
+regs->pc = (register_t)kinfo->entry;
if ( is_32bit_domain(d) )
{
@@ -2318,14 +2272,14 @@ int __init construct_dom0(struct domain *d)
*/
regs->r0 = 0; /* SBZ */
regs->r1 = 0x; /* We use DTB therefore no machine id */
-regs->r2 = kinfo.dtb_paddr;
+regs->r2 = kinfo->dtb_paddr;
}
#ifdef CONFIG_ARM_64
else
{
regs->cpsr = PSR_GUEST64_INIT;
/* From linux/Documentation/arm64/booting.txt */
-regs->x0 = kinfo.dtb_paddr;
+regs->x0 = kinfo->dtb_paddr;
regs->x1 = 0; /* Reserved for future use */
regs->x2 = 0; /* Reserved for future use */
regs->x3 = 0; /* Reserved for future use */
@@ -2353,6 +2307,62 @@ int __init construct_dom0(struct domain *d)
return 0;
}
+int __init construct_dom0(struct domain *d)
+{
+struct kernel_info kinfo = {};
+int rc;
+
+/* Sanity! */
+BUG_ON(d->domain_id != 0);
+
+printk("*** LOADING DOMAIN 0 ***\n");
+if (
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
On Fri, 2 Nov 2018, Julien Grall wrote: > On 02/11/2018 17:56, Stefano Stabellini wrote: > > On Fri, 2 Nov 2018, Ian Jackson wrote: > > > Ie the biggest work here of all kinds is is glue. Adding more > > > entities to the problem will increase rather than reduce the amount of > > > glue code that needs to be written. > > > > Basically, you are saying that even if had a well maintained deb > > repository of kernel packages for OSSTest to use, doesn't matter how we > > achieve this goal, it would still require a non trivial amount of work > > to do the integration with OSSTest. > > This is not how I understood the thread. I believe this was related to use an > external CI loop. > > In our case, once we have a deb package. Then this is not much different than > using a backport kernel. We already have such support in Osstest, so it should > not be too difficult to adapt it for a different repo. OK, I misunderstood Ian, thanks for stepping in. If that is the case, then: 1) We already have a Xen ARM Linux tree which we have to maintain for Dom0 The maintenance model and testing of this tree doesn't change regardless. 2) We already have Dockerfiles and scripts by Doug and ViryaOS to build kernels on gitlab We could improve them to build a full deb repository. What's stopping us from using (2) to setup up a Xen Project deb repo? Does it really matter who executes scripts (2) and whether they are run on your laptop or in the cloud as long as the build is fully reproducible? We are not talking about hacking config files around and using who knows what compiler to build something. docker build will give you the same output no matter the host. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 14/16] xen/arm: p2m: Extend p2m_get_entry to return the value of bit[0] (valid bit)
On Mon, 8 Oct 2018, Julien Grall wrote:
> With the recent changes, a P2M entry may be populated but may as not
> valid. In some situation, it would be useful to know whether the entry
> has been marked available to guest in order to perform a specific
> action. So extend p2m_get_entry to return the value of bit[0] (valid bit).
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/mem_access.c | 6 +++---
> xen/arch/arm/p2m.c| 20
> xen/include/asm-arm/p2m.h | 3 ++-
> 3 files changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> index 9239bdf323..f434510b2a 100644
> --- a/xen/arch/arm/mem_access.c
> +++ b/xen/arch/arm/mem_access.c
> @@ -70,7 +70,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
> * No setting was found in the Radix tree. Check if the
> * entry exists in the page-tables.
> */
> -mfn_t mfn = p2m_get_entry(p2m, gfn, NULL, NULL, NULL);
> +mfn_t mfn = p2m_get_entry(p2m, gfn, NULL, NULL, NULL, NULL);
>
> if ( mfn_eq(mfn, INVALID_MFN) )
> return -ESRCH;
> @@ -199,7 +199,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned
> long flag,
> * We had a mem_access permission limiting the access, but the page type
> * could also be limiting, so we need to check that as well.
> */
> -mfn = p2m_get_entry(p2m, gfn, , NULL, NULL);
> +mfn = p2m_get_entry(p2m, gfn, , NULL, NULL, NULL);
> if ( mfn_eq(mfn, INVALID_MFN) )
> goto err;
>
> @@ -405,7 +405,7 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn,
> uint32_t nr,
>gfn = gfn_next_boundary(gfn, order) )
> {
> p2m_type_t t;
> -mfn_t mfn = p2m_get_entry(p2m, gfn, , NULL, );
> +mfn_t mfn = p2m_get_entry(p2m, gfn, , NULL, , NULL);
>
>
> if ( !mfn_eq(mfn, INVALID_MFN) )
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 12b459924b..df6b48d73b 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -306,10 +306,14 @@ static int p2m_next_level(struct p2m_domain *p2m, bool
> read_only,
> *
> * If the entry is not present, INVALID_MFN will be returned and the
> * page_order will be set according to the order of the invalid range.
> + *
> + * valid will contain the value of bit[0] (e.g valid bit) of the
> + * entry.
> */
> mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
> p2m_type_t *t, p2m_access_t *a,
> -unsigned int *page_order)
> +unsigned int *page_order,
> +bool *valid)
> {
> paddr_t addr = gfn_to_gaddr(gfn);
> unsigned int level = 0;
> @@ -317,6 +321,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
> int rc;
> mfn_t mfn = INVALID_MFN;
> p2m_type_t _t;
> +bool _valid;
>
> /* Convenience aliases */
> const unsigned int offsets[4] = {
> @@ -334,6 +339,10 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
>
> *t = p2m_invalid;
>
> +/* Allow valid to be NULL */
> +valid = valid?: &_valid;
> +*valid = false;
Why not a simple:
if ( valid )
*valid = false;
especially given that you do the same if ( valid ) check below.
In fact, it doesn' look like we need _valid?
> /* XXX: Check if the mapping is lower than the mapped gfn */
>
> /* This gfn is higher than the highest the p2m map currently holds */
> @@ -379,6 +388,9 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
> * to the GFN.
> */
> mfn = mfn_add(mfn, gfn_x(gfn) & ((1UL << level_orders[level]) - 1));
> +
> +if ( valid )
> +*valid = lpae_is_valid(entry);
> }
>
> out_unmap:
> @@ -397,7 +409,7 @@ mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t
> *t)
> struct p2m_domain *p2m = p2m_get_hostp2m(d);
>
> p2m_read_lock(p2m);
> -mfn = p2m_get_entry(p2m, gfn, t, NULL, NULL);
> +mfn = p2m_get_entry(p2m, gfn, t, NULL, NULL, NULL);
> p2m_read_unlock(p2m);
>
> return mfn;
> @@ -1464,7 +1476,7 @@ int relinquish_p2m_mapping(struct domain *d)
> for ( ; gfn_x(start) < gfn_x(end);
>start = gfn_next_boundary(start, order) )
> {
> -mfn_t mfn = p2m_get_entry(p2m, start, , NULL, );
> +mfn_t mfn = p2m_get_entry(p2m, start, , NULL, , NULL);
>
> count++;
> /*
> @@ -1527,7 +1539,7 @@ int p2m_cache_flush_range(struct domain *d, gfn_t
> start, gfn_t end)
>
> for ( ; gfn_x(start) < gfn_x(end); start = next_gfn )
> {
> -mfn_t mfn = p2m_get_entry(p2m, start, , NULL, );
> +mfn_t mfn = p2m_get_entry(p2m, start, , NULL, , NULL);
>
> next_gfn = gfn_next_boundary(start, order);
>
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index d7afa2bbe8..92213dd1ab 100644
> --- a/xen/include/asm-arm/p2m.h
> +++
Re: [Xen-devel] [RFC 13/16] xen/arm: p2m: Allow to flush cache on any RAM region
On Mon, 8 Oct 2018, Julien Grall wrote:
> Currently, we only allow to flush cache on region mapped as p2m_ram_{rw,ro}.
^ regions
> There are no real problem to flush cache on any RAM region such as grants
^ problems in cache flushing any RAM regions
> and foreign mapping. Therefore, relax the cache to allow flushing the
^ check
> cache on any RAM region.
>
> Signed-off-by: Julien Grall
Aside from grammar:
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/p2m.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 8537b7bab1..12b459924b 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1532,7 +1532,7 @@ int p2m_cache_flush_range(struct domain *d, gfn_t
> start, gfn_t end)
> next_gfn = gfn_next_boundary(start, order);
>
> /* Skip hole and non-RAM page */
> -if ( mfn_eq(mfn, INVALID_MFN) || !p2m_is_ram(t) )
> +if ( mfn_eq(mfn, INVALID_MFN) || !p2m_is_any_ram(t) )
> continue;
>
> /* XXX: Implement preemption */
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 12/16] xen/arm: Rework p2m_cache_flush to take a range [begin, end)
On Mon, 8 Oct 2018, Julien Grall wrote:
> The function will be easier to re-use in a follow-up patch if you have
> only the begin and end.
>
> At the same time, rename the function to reflect the change in the
> prototype.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/arch/arm/domctl.c | 2 +-
> xen/arch/arm/p2m.c| 3 +--
> xen/include/asm-arm/p2m.h | 7 +--
> 3 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
> index 4587c75826..c10f568aad 100644
> --- a/xen/arch/arm/domctl.c
> +++ b/xen/arch/arm/domctl.c
> @@ -61,7 +61,7 @@ long arch_do_domctl(struct xen_domctl *domctl, struct
> domain *d,
> if ( e < s )
> return -EINVAL;
>
> -return p2m_cache_flush(d, _gfn(s), domctl->u.cacheflush.nr_pfns);
> +return p2m_cache_flush_range(d, _gfn(s), _gfn(e));
> }
> case XEN_DOMCTL_bind_pt_irq:
> {
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index af445d3313..8537b7bab1 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1507,10 +1507,9 @@ int relinquish_p2m_mapping(struct domain *d)
> return rc;
> }
>
> -int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr)
> +int p2m_cache_flush_range(struct domain *d, gfn_t start, gfn_t end)
> {
> struct p2m_domain *p2m = p2m_get_hostp2m(d);
> -gfn_t end = gfn_add(start, nr);
> gfn_t next_gfn;
> p2m_type_t t;
> unsigned int order;
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index c03557544a..d7afa2bbe8 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -224,8 +224,11 @@ int p2m_set_entry(struct p2m_domain *p2m,
>p2m_type_t t,
>p2m_access_t a);
>
> -/* Clean & invalidate caches corresponding to a region of guest address
> space */
> -int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr);
> +/*
> + * Clean & invalidate caches corresponding to a region [start,end) of guest
> + * address space.
> + */
> +int p2m_cache_flush_range(struct domain *d, gfn_t start, gfn_t end);
>
> /*
> * Map a region in the guest p2m with a specific p2m type.
> --
> 2.11.0
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 09/16] xen/arm: p2m: Introduce a function to resolve translation fault
On Mon, 8 Oct 2018, Julien Grall wrote:
> Currently a Stage-2 translation fault could happen:
> 1) MMIO emulation
> 2) When the page-tables is been updated using Break-Before-Make
^ have
> 3) Page not mapped
>
> A follow-up patch will re-purpose the valid bit in an entry to generate
> translation fault. This would be used to do an action on each entries to
^entry
> track page used for a given period.
^pages
>
> A new function is introduced to try to resolve a translation fault. This
> will include 2) and the new way to generate fault explained above.
I can see the code does what you describe, but I don't understand why we
are doing this. What is missing in the commit message is the explanation
of the relationship between the future goal of repurposing the valid bit
and the introduction of a function to handle Break-Before-Make stage2
faults. Does it fix an issue with Break-Before-Make that we currently
have? Or it becomes needed due to the repurposing of valid? If so, why?
> To avoid invalidating all the page-tables entries in one go. It is
> possible to invalidate the top-level table and then on trap invalidate
> the table one-level down. This will be repeated until a block/page entry
> has been reached.
>
> At the moment, there are no action done when reaching a block/page entry
> but setting the valid bit to 1.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/p2m.c | 127
> +++
> xen/arch/arm/traps.c | 7 +--
> 2 files changed, 131 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index ec956bc151..af445d3313 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1043,6 +1043,133 @@ int p2m_set_entry(struct p2m_domain *p2m,
> return rc;
> }
>
> +/* Invalidate all entries in the table. The p2m should be write locked. */
> +static void p2m_invalidate_table(struct p2m_domain *p2m, mfn_t mfn)
> +{
> +lpae_t *table;
> +unsigned int i;
> +
> +ASSERT(p2m_is_write_locked(p2m));
> +
> +table = map_domain_page(mfn);
> +
> +for ( i = 0; i < LPAE_ENTRIES; i++ )
> +{
> +lpae_t pte = table[i];
> +
> +pte.p2m.valid = 0;
> +
> +p2m_write_pte([i], pte, p2m->clean_pte);
> +}
> +
> +unmap_domain_page(table);
> +
> +p2m->need_flush = true;
> +}
> +
> +bool p2m_resolve_translation_fault(struct domain *d, gfn_t gfn)
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +unsigned int level = 0;
> +bool resolved = false;
> +lpae_t entry, *table;
> +paddr_t addr = gfn_to_gaddr(gfn);
> +
> +/* Convenience aliases */
> +const unsigned int offsets[4] = {
> +zeroeth_table_offset(addr),
> +first_table_offset(addr),
> +second_table_offset(addr),
> +third_table_offset(addr)
> +};
> +
> +p2m_write_lock(p2m);
> +
> +/* This gfn is higher than the highest the p2m map currently holds */
> +if ( gfn_x(gfn) > gfn_x(p2m->max_mapped_gfn) )
> +goto out;
> +
> +table = p2m_get_root_pointer(p2m, gfn);
> +/*
> + * The table should always be non-NULL because the gfn is below
> + * p2m->max_mapped_gfn and the root table pages are always present.
> + */
> +BUG_ON(table == NULL);
> +
> +/*
> + * Go down the page-tables until an entry has the valid bit unset or
> + * a block/page entry has been hit.
> + */
> +for ( level = P2M_ROOT_LEVEL; level <= 3; level++ )
> +{
> +int rc;
> +
> +entry = table[offsets[level]];
> +
> +if ( level == 3 )
> +break;
> +
> +/* Stop as soon as we hit an entry with the valid bit unset. */
> +if ( !lpae_is_valid(entry) )
> +break;
> +
> +rc = p2m_next_level(p2m, true, level, , offsets[level]);
> +if ( rc == GUEST_TABLE_MAP_FAILED )
> +goto out_unmap;
> +else if ( rc != GUEST_TABLE_NORMAL_PAGE )
why not rc == GUEST_TABLE_SUPER_PAGE?
> +break;
> +}
> +
> +/*
> + * If the valid bit of the entry is set, it means someone was playing
> with
> + * the Stage-2 page table. Nothing to do and mark the fault as resolved.
> + */
> +if ( lpae_is_valid(entry) )
> +{
> +resolved = true;
> +goto out_unmap;
> +}
> +
> +/*
> + * The valid bit is unset. If the entry is still not valid then the fault
> + * cannot be resolved, exit and report it.
> + */
> +if ( !p2m_is_valid(entry) )
> +goto out_unmap;
> +
> +/*
> + * Now we have an entry with valid bit unset, but still valid from
> + * the P2M point of view.
> + *
> + * For entry pointing to a table, the table will be invalidated.
^ entries
> + * For entry pointing to a block/page, no work to do for now.
^ entries
> +
[Xen-devel] [ovmf baseline-only test] 75561: tolerable FAIL
This run is configured for baseline tests only. flight 75561 ovmf real [real] http://osstest.xensource.com/osstest/logs/75561/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: build-amd64-libvirt 6 libvirt-buildfail like 75558 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75558 build-i386-libvirt6 libvirt-buildfail like 75558 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75558 version targeted for testing: ovmf c4f4984c69ab1057a5d297b4557fe6cf733f8584 baseline version: ovmf d3d97b378fe4d0bfbcbdb296d06bcf1d09165480 Last test of basis75558 2018-11-01 14:32:17 Z1 days Testing same since75561 2018-11-02 06:51:57 Z0 days1 attempts People who touched revisions under test: Hess Chen jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt fail build-i386-libvirt fail 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.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit c4f4984c69ab1057a5d297b4557fe6cf733f8584 Author: Hess Chen Date: Wed Oct 31 13:53:27 2018 +0800 BaseTools/Eot: Remove a duplication code in EotMain class Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hess Chen Reviewed-by: Yonghong Zhu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC 07/16] xen/arm: p2m: Introduce p2m_is_valid and use it
On Tue, 30 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 30/10/2018 00:21, Stefano Stabellini wrote:
> > On Mon, 8 Oct 2018, Julien Grall wrote:
> > > The LPAE format allows to store information in an entry even with the
> > > valid bit unset. In a follow-up patch, we will take advantage of this
> > > feature to re-purpose the valid bit for generating a translation fault
> > > even if an entry contains valid information.
> > >
> > > So we need a different way to know whether an entry contains valid
> > > information. It is possible to use the information hold in the p2m_type
> > > to know for that purpose. Indeed all entries containing valid
> > > information will have a valid p2m type (i.e p2m_type != p2m_invalid).
> > >
> > > This patch introduces a new helper p2m_is_valid, which implements that
> > > idea, and replace most of lpae_is_valid call with the new helper. The ones
> > > remaining are for TLBs handling and entries accounting.
> > >
> > > With the renaming there are 2 others changes required:
> > > - Generate table entry with a valid p2m type
> > > - Detect new mapping for proper stats accounting
> > >
> > > Signed-off-by: Julien Grall
> > > ---
> > > xen/arch/arm/p2m.c | 34 +++---
> > > 1 file changed, 23 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > index 6c76298ebc..2a1e7e9be2 100644
> > > --- a/xen/arch/arm/p2m.c
> > > +++ b/xen/arch/arm/p2m.c
> > > @@ -220,17 +220,26 @@ static p2m_access_t p2m_mem_access_radix_get(struct
> > > p2m_domain *p2m, gfn_t gfn)
> > > }
> > > /*
> > > + * In the case of the P2M, the valid bit is used for other purpose. Use
> > > + * the type to check whether an entry is valid.
> > > + */
> > > +static inline bool p2m_is_valid(lpae_t pte)
> > > +{
> > > +return pte.p2m.type != p2m_invalid;
> > > +}
> > > +
> > > +/*
> > >* lpae_is_* helpers don't check whether the valid bit is set in the
> > >* PTE. Provide our own overlay to check the valid bit.
> > >*/
> > > static inline bool p2m_is_mapping(lpae_t pte, unsigned int level)
> > > {
> > > -return lpae_is_valid(pte) && lpae_is_mapping(pte, level);
> > > +return p2m_is_valid(pte) && lpae_is_mapping(pte, level);
> > > }
> > > static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
> > > {
> > > -return lpae_is_valid(pte) && lpae_is_superpage(pte, level);
> > > +return p2m_is_valid(pte) && lpae_is_superpage(pte, level);
> > > }
> > > #define GUEST_TABLE_MAP_FAILED 0
> > > @@ -264,7 +273,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool
> > > read_only,
> > > entry = *table + offset;
> > > -if ( !lpae_is_valid(*entry) )
> > > +if ( !p2m_is_valid(*entry) )
> > > {
> > > if ( read_only )
> > > return GUEST_TABLE_MAP_FAILED;
> > > @@ -356,7 +365,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
> > > entry = table[offsets[level]];
> > > -if ( lpae_is_valid(entry) )
> > > +if ( p2m_is_valid(entry) )
> > > {
> > > *t = entry.p2m.type;
> > > @@ -544,8 +553,11 @@ static lpae_t page_to_p2m_table(struct page_info
> > > *page)
> > > /*
> > >* The access value does not matter because the hardware will ignore
> > >* the permission fields for table entry.
> > > + *
> > > + * We use p2m_ram_rw so the entry has a valid type. This is important
> > > + * for p2m_is_valid() to return valid on table entries.
> > >*/
> > > -return mfn_to_p2m_entry(page_to_mfn(page), p2m_invalid,
> > > p2m_access_rwx);
> > > +return mfn_to_p2m_entry(page_to_mfn(page), p2m_ram_rw,
> > > p2m_access_rwx);
> > > }
> > > static inline void p2m_write_pte(lpae_t *p, lpae_t pte, bool
> > > clean_pte)
> > > @@ -569,7 +581,7 @@ static int p2m_create_table(struct p2m_domain *p2m,
> > > lpae_t *entry)
> > > struct page_info *page;
> > > lpae_t *p;
> > > -ASSERT(!lpae_is_valid(*entry));
> > > +ASSERT(!p2m_is_valid(*entry));
> > > page = alloc_domheap_page(NULL, 0);
> > > if ( page == NULL )
> > > @@ -626,7 +638,7 @@ static int p2m_mem_access_radix_set(struct p2m_domain
> > > *p2m, gfn_t gfn,
> > >*/
> > > static void p2m_put_l3_page(const lpae_t pte)
> > > {
> > > -ASSERT(lpae_is_valid(pte));
> > > +ASSERT(p2m_is_valid(pte));
> > > /*
> > >* TODO: Handle other p2m types
> > > @@ -654,11 +666,11 @@ static void p2m_free_entry(struct p2m_domain *p2m,
> > > struct page_info *pg;
> > > /* Nothing to do if the entry is invalid. */
> > > -if ( !lpae_is_valid(entry) )
> > > +if ( !p2m_is_valid(entry) )
> > > return;
> > > /* Nothing to do but updating the stats if the entry is a
> > > super-page. */
> > > -if ( p2m_is_superpage(entry, level) )
> > > +if ( level == 3 && entry.p2m.table )
> >
> > Why?
>
> Because p2m_is_superpage(...)
Re: [Xen-devel] [PATCH v5 11/25] xen/arm: introduce allocate_memory
On Tue, 30 Oct 2018, Julien Grall wrote:
> Hi,
>
> On 23/10/2018 03:02, Stefano Stabellini wrote:
> > Introduce an allocate_memory function able to allocate memory for DomUs
> > and map it at the right guest addresses, according to the guest memory
> > map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
> >
> > This is under #if 0 as not used for now.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v5:
> > - improve commit message
> > - code style
> > - remove unneeded local var
> > - while loop in allocate_bank_memory to allocate memory so that it
> >doesn't have to be contiguos
> > - combile while loops in allocate_memory
> >
> > Changes in v4:
> > - move earlier, add #if 0
> > - introduce allocate_bank_memory, remove insert_bank
> > - allocate_bank_memory allocate memory and inserts the bank, while
> >allocate_memory specifies where to do that
> >
> > Changes in v3:
> > - new patch
> > ---
> > xen/arch/arm/domain_build.c | 99
> > +
> > 1 file changed, 99 insertions(+)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index c61a27f..146d81e 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -368,6 +368,105 @@ static void __init allocate_memory_11(struct domain
> > *d,
> > }
> > }
> > +#if 0
> > +static bool __init allocate_bank_memory(struct domain *d,
> > +struct kernel_info *kinfo,
> > +gfn_t sgfn,
> > +unsigned int order)
>
> I don't think your implementation below is equivalent to the one I suggested
> earlier on ([1]). While you handled the contiguous problem, you didn't address
> the 2 others points:
>1) The memory specify by the user may not be in power of 2 pages. For
> instance, a user can specify 40KB. With your algo, we will end to
> allocate 32KB in the first bank and 8KB in the second bank. However what
> we want is allocate 40KB in a single bank.
>2) You don't check whether the leftover memory is bigger than the size
> of the second bank.
>
> Because of 1), you can't reason in term of order here. You have to reason in
> bytes or number of pages.
>
> > +{
> > +int res;
> > +struct page_info *pg;
> > +struct membank *bank;
> > +paddr_t size = pfn_to_paddr(1UL << order);
> > +gfn_t _sgfn = sgfn;
> > +gfn_t _egfn = gfn_add(sgfn, 1UL << order);
> > +
> > +while ( gfn_x(_sgfn) < gfn_x(_egfn) )
> > +{
> > +pg = alloc_domheap_pages(d, order, 0);
> > +if ( pg != NULL )
> > +{
> > +res = guest_physmap_add_page(d, _sgfn, page_to_mfn(pg), order);
> > +if ( res )
> > +{
> > +dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
> > +goto fail;
> > +}
> > +_sgfn = gfn_add(_sgfn, 1UL << order);
> > +}
> > +else
> > +{
> > +order--;
>
> order may be equal to 0. So here you will underflow.
>
> Overall, it would be best if you re-use the code I sent. While not tested, it
> addresses all the problems. Fixing the potential bug in that patch so be quite
> easily.
OK, I'll add your Signed-off-by to the patch.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 11/25] xen/arm: introduce allocate_memory
On Tue, 30 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> More comments on it :).
>
> On 10/23/18 3:02 AM, Stefano Stabellini wrote:
> > Introduce an allocate_memory function able to allocate memory for DomUs
> > and map it at the right guest addresses, according to the guest memory
> > map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
> >
> > This is under #if 0 as not used for now.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> > Changes in v5:
> > - improve commit message
> > - code style
> > - remove unneeded local var
> > - while loop in allocate_bank_memory to allocate memory so that it
> >doesn't have to be contiguos
> > - combile while loops in allocate_memory
> >
> > Changes in v4:
> > - move earlier, add #if 0
> > - introduce allocate_bank_memory, remove insert_bank
> > - allocate_bank_memory allocate memory and inserts the bank, while
> >allocate_memory specifies where to do that
> >
> > Changes in v3:
> > - new patch
> > ---
> > xen/arch/arm/domain_build.c | 99
> > +
> > 1 file changed, 99 insertions(+)
> >
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index c61a27f..146d81e 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -368,6 +368,105 @@ static void __init allocate_memory_11(struct domain
> > *d,
> > }
> > }
> > +#if 0
> > +static bool __init allocate_bank_memory(struct domain *d,
> > +struct kernel_info *kinfo,
> > +gfn_t sgfn,
> > +unsigned int order)
> > +{
> > +int res;
> > +struct page_info *pg;
> > +struct membank *bank;
> > +paddr_t size = pfn_to_paddr(1UL << order);
> > +gfn_t _sgfn = sgfn;
> > +gfn_t _egfn = gfn_add(sgfn, 1UL << order);
> > +
> > +while ( gfn_x(_sgfn) < gfn_x(_egfn) )
> > +{
> > +pg = alloc_domheap_pages(d, order, 0);
> > +if ( pg != NULL )
> > +{
> > +res = guest_physmap_add_page(d, _sgfn, page_to_mfn(pg), order);
> > +if ( res )
> > +{
> > +dprintk(XENLOG_ERR, "Failed map pages to DOMU: %d", res);
> > +goto fail;
> > +}
> > +_sgfn = gfn_add(_sgfn, 1UL << order);
> > +}
> > +else
> > +{
> > +order--;
> > +if ( order == 0 )
> > +{
> > +dprintk(XENLOG_ERR, "Failed to allocated DOMU memory");
> > +goto fail;
> > +}
> > +}
> > +}
> > +
> > +bank = >mem.bank[kinfo->mem.nr_banks];
> > +bank->start = gfn_to_gaddr(sgfn);
> > +bank->size = size;
> > +kinfo->mem.nr_banks++;
> > +kinfo->unassigned_mem -= size;
> > +
> > +return true;
> > +
> > +fail:
> > +/*
> > + * Fatal failure, don't attempt to free memory.
> > + */
> > +return false;
> > +}
> > +
> > +static void __init allocate_memory(struct domain *d, struct kernel_info
> > *kinfo)
> > +{
> > +unsigned int order = get_allocation_size(kinfo->unassigned_mem);
> > +unsigned int order_req;
> > +unsigned int i;
> > +
> > +dprintk(XENLOG_INFO, "Allocating mappings totalling %ldMB for
> > dom%d:\n",
> > +/* Don't want format this as PRIpaddr (16 digit hex) */
> > +(unsigned long)(kinfo->unassigned_mem >> 20), d->domain_id);
>
> While you are re-spinning this series. I would turn all the dprintk to printk
> as those messages are useful in non-debug build.
OK
> > +
> > +kinfo->mem.nr_banks = 0;
> > +
> > +order = get_allocation_size(kinfo->unassigned_mem);
> > +if ( order > get_order_from_bytes(GUEST_RAM0_SIZE) )
> > +order_req = get_order_from_bytes(GUEST_RAM0_SIZE);
> > +else
> > +order_req = order;
> > +if ( !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM0_BASE),
> > order_req) )
> > +goto fail;
> > +
> > +order -= order_req;
> > +if ( order > 0 &&
> > + !allocate_bank_memory(d, kinfo, gaddr_to_gfn(GUEST_RAM1_BASE),
> > order) )
> > +goto fail;
> > +
> > +for( i = 0; i < kinfo->mem.nr_banks; i++ )
> > +{
> > +dprintk(XENLOG_INFO, "Dom%d BANK[%d] %#"PRIpaddr"-%#"PRIpaddr"
> > (%ldMB)\n",
> > +d->domain_id,
> > +i,
> > +kinfo->mem.bank[i].start,
> > +kinfo->mem.bank[i].start + kinfo->mem.bank[i].size,
> > +/* Don't want format this as PRIpaddr (16 digit hex) */
> > +(unsigned long)(kinfo->mem.bank[i].size >> 20));
> > +}
> > +
> > +return;
> > +
> > +fail:
> > +dprintk(XENLOG_ERR, "Failed to allocate requested domain memory."
> > +/* Don't want format this as PRIpaddr (16 digit hex) */
> > +" %ldKB unallocated. Fix the VMs configurations.\n",
> > +(unsigned long)kinfo->unassigned_mem >> 10);
>
Re: [Xen-devel] [PATCH v5 08/25] xen/arm: probe domU kernels and initrds
On Tue, 30 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 23/10/2018 03:02, Stefano Stabellini wrote:
> > Find addresses, sizes on device tree from kernel_probe.
> > Find the cmdline from the bootcmdlines array.
> >
> > Introduce a new boot_module_find_by_addr_and_kind function to match not
> > just on boot module kind, but also by address so that we can support
> > multiple domains.
> >
> > Introduce a boot_cmdline_find_by_name function to find the right struct
> > cmdline based on the device tree node name of the "xen,domain"
> > compatible node.
> >
> > Set command line for dom0 too for consistency.
>
> I was expecting you to remove the assignment in construct_dom0 to avoid the
> duplication.
Yes, that would be nicer. I'll do that in this patch.
> > diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> > index da8410e..d56f776 100644
> > --- a/xen/arch/arm/kernel.c
> > +++ b/xen/arch/arm/kernel.c
> > @@ -421,22 +421,72 @@ static int __init kernel_zimage32_probe(struct
> > kernel_info *info,
> > return 0;
> > }
> > -int __init kernel_probe(struct kernel_info *info)
> > +int __init kernel_probe(struct kernel_info *info,
> > +const struct dt_device_node *domain)
> > {
> > -struct bootmodule *mod = boot_module_find_by_kind(BOOTMOD_KERNEL);
> > +struct bootmodule *mod = NULL;
> > +struct bootcmdline *cmd = NULL;
> > +struct dt_device_node *node;
> > +u64 kernel_addr, initrd_addr, size;
> > int rc;
> > +/* domain is NULL only for the hardware_domain */
>
> NIT: No need to the _.
>
> The rest of the code looks good to me.
OK
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v5 07/25] xen/arm: don't add duplicate boot modules, introduce domU flag
On Tue, 30 Oct 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 23/10/2018 03:02, Stefano Stabellini wrote:
> > Don't add duplicate boot modules (same kind and same start address),
> > they are freed later, we don't want to introduce double-free errors.
> >
> > Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
> > it for kernels and ramdisks of "xen,domain" nodes to avoid getting
> > confused in kernel_probe, where we try to guess which is the dom0 kernel
> > and initrd to be compatible with all versions of the multiboot spec.
> >
> > boot_module_find_by_kind and boot_cmdline_find_by_kind automatically
> > check for !domU entries (they are only used for non-domU modules).
> >
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> > Changes in v5:
> > - improve commit message
> > - add in-code comments
> >
> > Changes in v4:
> > - use unsigned int
> > - better commit message
> > - introduce domU flag and usage
> >
> > Changes in v2:
> > - new patch
> > ---
> > xen/arch/arm/bootfdt.c | 11 +++
> > xen/arch/arm/setup.c| 30 +-
> > xen/include/asm-arm/setup.h | 12 ++--
> > 3 files changed, 42 insertions(+), 11 deletions(-)
> >
> > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > index cb6f77d..c325b6e 100644
> > --- a/xen/arch/arm/bootfdt.c
> > +++ b/xen/arch/arm/bootfdt.c
> > @@ -175,6 +175,7 @@ static void __init process_multiboot_node(const void
> > *fdt, int node,
> > int len = sizeof("/chosen");
> > char path[8]; /* sizeof "/chosen" */
> > int parent_node, ret;
> > +bool domU;
> > parent_node = fdt_parent_offset(fdt, node);
> > ASSERT(parent_node >= 0);
> > @@ -229,12 +230,14 @@ static void __init process_multiboot_node(const void
> > *fdt, int node,
> > kind = BOOTMOD_XSM;
> > }
> > -add_boot_module(kind, start, size);
> > +domU = fdt_node_check_compatible(fdt, parent_node, "xen,domain") == 0;
> > +add_boot_module(kind, start, size, domU);
> > prop = fdt_get_property(fdt, node, "bootargs", );
> > if ( !prop )
> > return;
> > -add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data,
> > kind);
> > +add_boot_cmdline(fdt_get_name(fdt, parent_node, ), prop->data,
> > + kind, domU);
> > }
> > static void __init process_chosen_node(const void *fdt, int node,
> > @@ -280,7 +283,7 @@ static void __init process_chosen_node(const void *fdt,
> > int node,
> > printk("Initrd %"PRIpaddr"-%"PRIpaddr"\n", start, end);
> > -add_boot_module(BOOTMOD_RAMDISK, start, end-start);
> > +add_boot_module(BOOTMOD_RAMDISK, start, end-start, false);
> > }
> > static int __init early_scan_node(const void *fdt,
> > @@ -351,7 +354,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t
> > paddr)
> > if ( ret < 0 )
> > panic("No valid device tree\n");
> > -add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt));
> > +add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
> > device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
> > early_print_info();
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 2098591..72b12f9 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -201,10 +201,12 @@ void __init dt_unreserved_regions(paddr_t s, paddr_t
> > e,
> > }
> > struct bootmodule __init *add_boot_module(bootmodule_kind kind,
> > - paddr_t start, paddr_t size)
> > + paddr_t start, paddr_t size,
> > + bool domU)
> > {
> > struct bootmodules *mods =
> > struct bootmodule *mod;
> > +unsigned int i;
> > if ( mods->nr_mods == MAX_MODULES )
> > {
> > @@ -212,15 +214,29 @@ struct bootmodule __init
> > *add_boot_module(bootmodule_kind kind,
> > boot_module_kind_as_string(kind), start, start + size);
> > return NULL;
> > }
> > +for ( i = 0 ; i < mods->nr_mods ; i++ )
> > +{
> > +mod = >module[i];
> > +if ( mod->kind == kind && mod->start == start )
> > +{
> > +if ( !domU )
> > +mod->domU = false;
> > +return mod;
> > +}
> > +}
> > mod = >module[mods->nr_mods++];
> > mod->kind = kind;
> > mod->start = start;
> > mod->size = size;
> > +mod->domU = domU;
> > return mod;
> > }
> > +/*
> > + * This function is only used to find dom0 modules, so check for !mod->domU
>
> This comment is misleading. The function is used not only to find Dom0 Modules
> but also XSM & co.
>
> How about:
>
> "boot_module_find_by_kind can only be used to return Xen modules (e.g XSM,
> DTB) or Dom0 modules. This is not suitable for looking up for guest modules."
Sure, that's clearer
> > + */
> >
[Xen-devel] [PATCH] automation: build some customised configs
Introduce a new directory to put in configs we care about. Modify
build script to build with those configs.
While we only introduce x86 configs initially, provision for non-x86
configs.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Jan, feel free to put configs here.
---
automation/configs/x86/hvm_only_config | 2 ++
automation/configs/x86/no_hvm_pv_config | 2 ++
automation/configs/x86/pv_only_config | 2 ++
automation/scripts/build| 15 +++
4 files changed, 21 insertions(+)
create mode 100644 automation/configs/x86/hvm_only_config
create mode 100644 automation/configs/x86/no_hvm_pv_config
create mode 100644 automation/configs/x86/pv_only_config
diff --git a/automation/configs/x86/hvm_only_config
b/automation/configs/x86/hvm_only_config
new file mode 100644
index 00..e82cc04d69
--- /dev/null
+++ b/automation/configs/x86/hvm_only_config
@@ -0,0 +1,2 @@
+CONFIG_HVM=y
+# CONFIG_PV is not set
diff --git a/automation/configs/x86/no_hvm_pv_config
b/automation/configs/x86/no_hvm_pv_config
new file mode 100644
index 00..ed853cd358
--- /dev/null
+++ b/automation/configs/x86/no_hvm_pv_config
@@ -0,0 +1,2 @@
+# CONFIG_HVM is not set
+# CONFIG_PV is not set
diff --git a/automation/configs/x86/pv_only_config
b/automation/configs/x86/pv_only_config
new file mode 100644
index 00..aca77b64d4
--- /dev/null
+++ b/automation/configs/x86/pv_only_config
@@ -0,0 +1,2 @@
+CONFIG_PV=y
+# CONFIG_HVM is not set
diff --git a/automation/scripts/build b/automation/scripts/build
index c463b060d4..0cde1c7794 100755
--- a/automation/scripts/build
+++ b/automation/scripts/build
@@ -31,3 +31,18 @@ fi
./configure "${cfgargs[@]}"
make -j$(nproc) dist
+
+# Build all the configs we care about
+case ${XEN_TARGET_ARCH} in
+x86_64) arch=x86 ;;
+*) exit 0 ;;
+esac
+
+cfg_dir="automation/configs/${arch}"
+for cfg in `ls ${cfg_dir}`; do
+echo "Building $cfg"
+rm -f xen/.config
+make -C xen KBUILD_DEFCONFIG=../../../../${cfg_dir}/${cfg}
XEN_CONFIG_EXPERT=y defconfig
+make -j$(nproc) -C xen XEN_CONFIG_EXPERT=y
+done
+
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86: put vcpumask_to_pcpumask under CONFIG_PV
On 02/11/18 19:28, Wei Liu wrote:
> This function is used by PV code only. This issue is discovered by
> clang build.
Indeed. It is only used by two PV hypercalls.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/mm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index f96678f46d..01ec6aa2bf 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3057,6 +3057,7 @@ int new_guest_cr3(mfn_t mfn)
> #endif
> }
>
> +#ifdef CONFIG_PV
> static inline int vcpumask_to_pcpumask(
Mind dropping this spurious inline while you're at it?
Reviewed-by: Andrew Cooper
> struct domain *d, XEN_GUEST_HANDLE_PARAM(const_void) bmap, cpumask_t
> *pmask)
> {
> @@ -3099,7 +3100,6 @@ static inline int vcpumask_to_pcpumask(
> }
> }
>
> -#ifdef CONFIG_PV
> static struct domain *get_pg_owner(domid_t domid)
> {
> struct domain *pg_owner = NULL, *curr = current->domain;
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86: put vcpumask_to_pcpumask under CONFIG_PV
This function is used by PV code only. This issue is discovered by
clang build.
Signed-off-by: Wei Liu
---
xen/arch/x86/mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f96678f46d..01ec6aa2bf 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3057,6 +3057,7 @@ int new_guest_cr3(mfn_t mfn)
#endif
}
+#ifdef CONFIG_PV
static inline int vcpumask_to_pcpumask(
struct domain *d, XEN_GUEST_HANDLE_PARAM(const_void) bmap, cpumask_t
*pmask)
{
@@ -3099,7 +3100,6 @@ static inline int vcpumask_to_pcpumask(
}
}
-#ifdef CONFIG_PV
static struct domain *get_pg_owner(domid_t domid)
{
struct domain *pg_owner = NULL, *curr = current->domain;
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [ovmf test] 129328: all pass - PUSHED
flight 129328 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/129328/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 93f98985826a6eba30584e9b2ada754b3da17990 baseline version: ovmf c4f4984c69ab1057a5d297b4557fe6cf733f8584 Last test of basis 129310 2018-11-02 03:40:59 Z0 days Testing same since 129328 2018-11-02 14:41:27 Z0 days1 attempts People who touched revisions under test: Bob Feng Feng, Bob C Liming Gao Marvin Haeuser marvin.haeu...@outlook.com Zhao, ZhiqiangX ZhiqiangX Zhao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git c4f4984c69..93f9898582 93f98985826a6eba30584e9b2ada754b3da17990 -> xen-tested-master ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86: deal with firmware setting bogus TSC_ADJUST values
On 02/11/18 16:40, Jan Beulich wrote:
> The system Intel have handed me for AVX512 emulator work ("Gigabyte
> Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3
> Pro-CF, BIOS F3 12/28/2017") would not come up under Xen - it hung in
> the middle of Dom0 PCI initialization. As it turned out, Xen's time
> management did not work because of the firmware setting (only) the boot
> CPU's TSC_ADJUST MSR to a large negative value (on the order of -2^50).
>
> Follow Linux (also shamelessly stealing their comments) in
> - clearing the register for the boot CPU (we don't have a need for
> exceptions here yet, as the only exception in Linux is a class of
> systems Xen doesn't work on anyway as far as I'm aware),
> - forcing non-negative values uniformly (commit 855615eee9 ["x86/tsc:
> Remove the TSC_ADJUST clamp"] dropped this, but without this my
> Haswell box won't boot anymore),
> - syncing the registers within sockets.
> Linux, prior to aforementioned commit, capped at 0x7fff as well, but as
> the
> description there says this issue has been addressed with a microcode
> update. Hence until someone runs into such a system without being able
> to update its microcode, I think we should leave out that specific part.
>
> In order to avoid making init_percpu_time() depend on running _before_
> set_cpu_sibling_map() (and hence the booting CPU _not_ being accounted
> in socket_cpumask[] yet), move that call slightly earlier in
> start_secondary().
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86/TSC: don't allow deadline timer to be used with unfixed errata
On 02/11/18 16:40, Jan Beulich wrote:
> In preparation of writes to the TSC_ADJUST MSR, avoid the bad
> interaction of writes to it and the TSC_DEADLINE one. Presumably the
> original Linux commit bd9240a18e ("x86/apic: Add TSC_DEADLINE quirk due
> to errata") refers to e.g. KBW092. (Of course this is an issue also
> without us writing the TSC_ADJUST MSR, if instead firmware did already.
>
> The errata checking can't be put in init_apic_mappings() as Linux does,
> as that runs before we update microcode on the boot CPU. It needs to
> happen before consumers of tdt_enabled, i.e.
> - __setup_APIC_LVTT() <- setup_APIC_timer() <- setup_boot_APIC_clock()
> - <- calibrate_APIC_clock() <- setup_boot_APIC_clock()
> - setup_boot_APIC_clock()
> setup_boot_APIC_clock() gets called from smp_prepare_cpus(), which sits
> after microcode loading (note that calibrate_APIC_clock() gets called
> before setting tdt_enabled).
>
> Also add an MFENCE as per Linux commit 5d7c631d92 ("x86/apic: Serialize
> LVTT and TSC_DEADLINE writes"), but I see no reason to put a conditional
> around it.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved
On 02/11/18 17:46, Daniel De Graaf wrote: > Reported-by: Andrew Cooper > Signed-off-by: Daniel De Graaf Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 3/3] x86emul: consolidate CR4 handling
On 02/11/18 16:46, Jan Beulich wrote: > Now that there's an almost unconditional CR4 read right at the beginning > of x86_emulate(), centralize its reading there and use result and value > everywhere else without further invoking the hook. > > Subsequently we may want to consider having the callers provide > whichever value they deem appropriate in their contexts, to avoid > invoking the hook altogether for this purpose. > > Signed-off-by: Jan Beulich I've got most of a series doing this for cpuid, which drops ~4k of .text volume from x86_emulate() alone. My plan was to get all the architectural state in a directly readable form, to reduce the complexity and boilerplate. On that subject... > @@ -3247,6 +3245,8 @@ x86_emulate( > > ASSERT(ops->read); > > +cr4_rc = ops->read_cr ? ops->read_cr(4, , ctxt) : X86EMUL_OKAY; ... why not make read_cr() mandatory, or put cr4 into ctxt? Plumbing cr4_rc around still feels like a lot of boilerplate. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH 2/3] x86emul: raise #GP(0) in VME mode for POPF with TF set in new value
On 02/11/18 16:45, Jan Beulich wrote:
> This is a check explicitly listed by the instruction page in the SDM.
>
> Signed-off-by: Jan Beulich
Hmm - looking at the listing, I think we've got an IOPL mismatch. This
behaviour, as well as the VIP adjustment in context, only apply at IOPL < 3.
~Andrew
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -4049,6 +4049,7 @@ x86_emulate(
> dst.val = (uint16_t)dst.val | (_regs.eflags & 0xu);
> if ( cr4 & X86_CR4_VME )
> {
> +generate_exception_if(dst.val & X86_EFLAGS_TF, EXC_GP, 0);
> if ( dst.val & X86_EFLAGS_IF )
> {
> generate_exception_if(_regs.eflags & X86_EFLAGS_VIP,
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
On 02/11/2018 17:56, Stefano Stabellini wrote: On Fri, 2 Nov 2018, Ian Jackson wrote: Ie the biggest work here of all kinds is is glue. Adding more entities to the problem will increase rather than reduce the amount of glue code that needs to be written. Basically, you are saying that even if had a well maintained deb repository of kernel packages for OSSTest to use, doesn't matter how we achieve this goal, it would still require a non trivial amount of work to do the integration with OSSTest. This is not how I understood the thread. I believe this was related to use an external CI loop. In our case, once we have a deb package. Then this is not much different than using a backport kernel. We already have such support in Osstest, so it should not be too difficult to adapt it for a different repo. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] x86/vcpu: Remove struct vcpu allocation restriction for !CONFIG_SHADOW_PAGING
On Fri, Nov 02, 2018 at 05:54:00PM +, Andrew Cooper wrote: > There is no need for struct vcpu to live below the 4G boundary if shadow > paging is compiled out. > > Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] x86/vcpu: Remove struct vcpu allocation restriction for !CONFIG_SHADOW_PAGING
There is no need for struct vcpu to live below the 4G boundary if shadow paging is compiled out. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: George Dunlap CC: Tim Deegan --- xen/arch/x86/domain.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 943f95b..35cfa24 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -311,8 +311,11 @@ struct vcpu *alloc_vcpu_struct(void) * may require that the shadow CR3 points below 4GB, and hence the whole * structure must satisfy this restriction. Thus we specify MEMF_bits(32). */ +unsigned int memflags = +IS_ENABLED(CONFIG_SHADOW_PAGING) ? MEMF_bits(32) : 0; + BUILD_BUG_ON(sizeof(*v) > PAGE_SIZE); -v = alloc_xenheap_pages(0, MEMF_bits(32)); +v = alloc_xenheap_pages(0, memflags); if ( v != NULL ) clear_page(v); return v; -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH v2 13/17] xenconsoled: add support for up to 3 secondary consoles [and 1 more messages]
Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 13/17] xenconsoled: add
support for up to 3 secondary consoles"):
> On Thu, Nov 01, 2018 at 05:31:18PM +, Ian Jackson wrote:
> > I'm confused. I thought we already had support for multiple PV
> > consoles. Is the problem that the backend is in qemu rather than
> > xenconsoled ?
>
> One of main reasons for this whole thing is to get rid of qemu from dom0
> at all. Regardless if it's handling only console, only disk or other
> stuff. This is a lot of code and I don't consider asking it nicely
> "please don't let rogue domain let attack any other qemu component" to
> be enough.
That makes perfect sense.
I'm sorry my responses on this console stuff were so confused
yesterday. I think I need to go back and read this lot again.
Stefano Stabellini writes ("Re: [RFC PATCH v2 13/17] xenconsoled: add support
for up to 3 secondary consoles"):
> I haven't read this patch, but yes, it is as you wrote. Multiple PV
> consoles are only suppored by QEMU, with the interface described in
> docs/misc/console.txt. It could be nice to be able to support them with
> xenconsoled, but we need to be careful they don't conflict. There is a
> way to specify the desired console backend, either QEMU or xenconsoled,
> so it shouldn't be a problem to have both backends being able to do
> multiple consoles. But we wouldn't want to have a different interface
> from the one described in docs/misc/console.txt, otherwise we'll break
> existing guests (Linux for instance.)
Right.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved
Reported-by: Andrew Cooper
Signed-off-by: Daniel De Graaf
---
tools/flask/policy/modules/dom0.te | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/flask/policy/modules/dom0.te
b/tools/flask/policy/modules/dom0.te
index dfdcdcd128..a0566671d6 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -66,6 +66,9 @@ allow dom0_t security_t:security { load_policy setenforce
setbool };
# Audit policy change events even when they are allowed
auditallow dom0_t security_t:security { load_policy setenforce setbool };
+# Allow dom0 to report platform configuration changes back to the hypervisor
+allow dom0_t xen_t:resource setup;
+
admin_device(dom0_t, device_t)
admin_device(dom0_t, irq_t)
admin_device(dom0_t, ioport_t)
--
2.14.5
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 129330: tolerable all pass - PUSHED
flight 129330 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/129330/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass test-armhf-armhf-xl 13 migrate-support-checkfail never pass test-armhf-armhf-xl 14 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass version targeted for testing: xen 2cf113891a38cc05434bc9876ffc107a990887be baseline version: xen 87e89bd112e16503f37d219a525a5b5d470e08f9 Last test of basis 129286 2018-11-01 14:00:25 Z1 days Failing since129322 2018-11-02 12:01:12 Z0 days2 attempts Testing same since 129330 2018-11-02 15:00:29 Z0 days1 attempts People who touched revisions under test: Alexandru Isaila Andrew Cooper Brian Woods Ian Jackson Jan Beulich Kevin Tian Paul Durrant Razvan Cojocaru Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 87e89bd112..2cf113891a 2cf113891a38cc05434bc9876ffc107a990887be -> smoke ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/8] tools/libvchan: init_xs_srv: Simplify error handling (1)
* Use xs_close instead of the deprecated xs_daemon_close.
* Initialise xs to NULL.That means xs_close can now be called in
all cases. Move it to the fail clause.
* free(domid_str) is already safe in all cases since domid_str is
initialised to NULL. Move it to the fail clause.
No overall functional change: xs_close is the same as xs_daemon_close;
and it and free are now sometimes called on NULL, but those are no-ops.
Signed-off-by: Ian Jackson
---
tools/libvchan/init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
index 180833dc2f..9c61c720d1 100644
--- a/tools/libvchan/init.c
+++ b/tools/libvchan/init.c
@@ -245,7 +245,7 @@ fail:
static int init_xs_srv(struct libxenvchan *ctrl, int domain, const char*
xs_base, int ring_ref)
{
int ret = -1;
- struct xs_handle *xs;
+ struct xs_handle *xs = NULL;
struct xs_permissions perms[2];
char buf[64];
char ref[16];
@@ -292,9 +292,9 @@ retry_transaction:
ret = 0;
}
fail_xs_open:
- free(domid_str);
- xs_daemon_close(xs);
fail:
+ free(domid_str);
+ xs_close(xs);
return ret;
}
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 8/8] tools/libvchan: libxenvchan_client_init: use ENOENT for no server
* Promise that we will set errno to ENOENT if the server is not
yet set up.
* Arrange that all ENOENT returns other than from the read of ring-ref
are turned into EIO, logging when we do so.
Signed-off-by: Ian Jackson
---
tools/libvchan/init.c| 11 ++-
tools/libvchan/libxenvchan.h | 4
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
index d987acd338..e58f6bf9ac 100644
--- a/tools/libvchan/init.c
+++ b/tools/libvchan/init.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#ifndef PAGE_SHIFT
#define PAGE_SHIFT 12
@@ -419,7 +420,7 @@ struct libxenvchan *libxenvchan_client_init(struct
xentoollog_logger *logger,
snprintf(buf, sizeof buf, "%s/ring-ref", xs_path);
ref = xs_read(xs, 0, buf, );
if (!ref)
- goto fail;
+ goto fail_allow_enoent;
ring_ref = atoi(ref);
free(ref);
if (!ring_ref)
@@ -452,7 +453,15 @@ struct libxenvchan *libxenvchan_client_init(struct
xentoollog_logger *logger,
if (xs)
xs_daemon_close(xs);
return ctrl;
+
fail:
+ if (errno == ENOENT) {
+ xtl_log(logger, XTL_ERROR, errno, "vchan",
+ "error talking to server `%s', returning EIO",
+ xs_path);
+ errno = EIO;
+ }
+ fail_allow_enoent:
libxenvchan_close(ctrl);
ctrl = NULL;
goto out;
diff --git a/tools/libvchan/libxenvchan.h b/tools/libvchan/libxenvchan.h
index e4ccca1ff0..8a4ec2ce4c 100644
--- a/tools/libvchan/libxenvchan.h
+++ b/tools/libvchan/libxenvchan.h
@@ -105,6 +105,10 @@ struct libxenvchan *libxenvchan_server_init(struct
xentoollog_logger *logger,
* safely, however no locking is performed, so you must prevent multiple
clients
* from connecting to a single server.
*
+ * Failing with ENOENT means the server has not yet called
+ * libxenvchan_server_init, You may wait for a server to appear by
+ * setting a xenstore watch on xs_path.
+ *
* @param logger Logger for libxc errors
* @param domain The peer domain to connect to
* @param xs_path Base xenstore path for storing ring/event data
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 2/8] tools/xenstore: Document that xs_close(0) is OK.
Signed-off-by: Ian Jackson --- tools/xenstore/include/xenstore.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/xenstore/include/xenstore.h b/tools/xenstore/include/xenstore.h index 064b62c455..889dc23863 100644 --- a/tools/xenstore/include/xenstore.h +++ b/tools/xenstore/include/xenstore.h @@ -77,7 +77,7 @@ typedef uint32_t xs_transaction_t; struct xs_handle *xs_open(unsigned long flags); /* Close the connection to the xs daemon. */ -void xs_close(struct xs_handle *xsh); +void xs_close(struct xs_handle *xsh /* NULL ok */); /* Connect to the xs daemon. * Returns a handle or NULL. -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 6/8] tools/libvchan: Add xentoollog to direct dependencies
We are going to add a call to xtl_log.
Signed-off-by: Ian Jackson
---
tools/libvchan/Makefile | 6 +++---
tools/libvchan/xenvchan.pc.in | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
index de9b44978f..c236a0f9e6 100644
--- a/tools/libvchan/Makefile
+++ b/tools/libvchan/Makefile
@@ -10,9 +10,9 @@ NODE_OBJS = node.o
NODE2_OBJS = node-select.o
LIBVCHAN_PIC_OBJS = $(patsubst %.o,%.opic,$(LIBVCHAN_OBJS))
-LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxengnttab)
$(LDLIBS_libxenevtchn)
-$(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore)
$(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn)
-$(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxengnttab)
$(CFLAGS_libxenevtchn)
+LIBVCHAN_LIBS = $(LDLIBS_libxenstore) $(LDLIBS_libxengnttab)
$(LDLIBS_libxenevtchn) $(LDLIBS_libxentoollog)
+$(LIBVCHAN_OBJS) $(LIBVCHAN_PIC_OBJS): CFLAGS += $(CFLAGS_libxenstore)
$(CFLAGS_libxengnttab) $(CFLAGS_libxenevtchn) $(CFLAGS_libxentoollog)
+$(NODE_OBJS) $(NODE2_OBJS): CFLAGS += $(CFLAGS_libxengnttab)
$(CFLAGS_libxenevtchn) $(CFLAGS_libxentoollog)
MAJOR = 4.12
MINOR = 0
diff --git a/tools/libvchan/xenvchan.pc.in b/tools/libvchan/xenvchan.pc.in
index 6fd13108d2..4b055c6c8f 100644
--- a/tools/libvchan/xenvchan.pc.in
+++ b/tools/libvchan/xenvchan.pc.in
@@ -7,4 +7,4 @@ Description: The Xenvchan library for Xen hypervisor
Version: @@version@@
Cflags: -I${includedir} @@cflagslocal@@
Libs: @@libsflag@@${libdir} -lxenvchan
-Requires.private: xentoollog,xenstore,xenevtchn,xengnttab
+Requires.private: xentoollog,xenstore,xenevtchn,xengnttab,xentoollog
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 4/8] tools/libvchan: init_xs_srv: Simplify error handling (2)
* Abolish fail_xs_open which is now exactly the same as fail.
* Change all gotos to refer to fail instead.
No functional change.
Signed-off-by: Ian Jackson
---
tools/libvchan/init.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
index 9c61c720d1..f099765a38 100644
--- a/tools/libvchan/init.c
+++ b/tools/libvchan/init.c
@@ -256,7 +256,7 @@ static int init_xs_srv(struct libxenvchan *ctrl, int
domain, const char* xs_base
goto fail;
domid_str = xs_read(xs, 0, "domid", NULL);
if (!domid_str)
- goto fail_xs_open;
+ goto fail;
// owner domain is us
perms[0].id = atoi(domid_str);
@@ -269,21 +269,21 @@ static int init_xs_srv(struct libxenvchan *ctrl, int
domain, const char* xs_base
retry_transaction:
xs_trans = xs_transaction_start(xs);
if (!xs_trans)
- goto fail_xs_open;
+ goto fail;
snprintf(ref, sizeof ref, "%d", ring_ref);
snprintf(buf, sizeof buf, "%s/ring-ref", xs_base);
if (!xs_write(xs, xs_trans, buf, ref, strlen(ref)))
- goto fail_xs_open;
+ goto fail;
if (!xs_set_permissions(xs, xs_trans, buf, perms, 2))
- goto fail_xs_open;
+ goto fail;
snprintf(ref, sizeof ref, "%d", ctrl->event_port);
snprintf(buf, sizeof buf, "%s/event-channel", xs_base);
if (!xs_write(xs, xs_trans, buf, ref, strlen(ref)))
- goto fail_xs_open;
+ goto fail;
if (!xs_set_permissions(xs, xs_trans, buf, perms, 2))
- goto fail_xs_open;
+ goto fail;
if (!xs_transaction_end(xs, xs_trans, 0)) {
if (errno == EAGAIN)
@@ -291,7 +291,6 @@ retry_transaction:
} else {
ret = 0;
}
- fail_xs_open:
fail:
free(domid_str);
xs_close(xs);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 5/8] tools/libvchan: init_xs_srv: Turn xs retry from goto into for (; ; )
No functional change.
Signed-off-by: Ian Jackson
---
tools/libvchan/init.c | 50 ++
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c
index f099765a38..d987acd338 100644
--- a/tools/libvchan/init.c
+++ b/tools/libvchan/init.c
@@ -266,31 +266,33 @@ static int init_xs_srv(struct libxenvchan *ctrl, int
domain, const char* xs_base
perms[1].id = domain;
perms[1].perms = XS_PERM_READ;
-retry_transaction:
- xs_trans = xs_transaction_start(xs);
- if (!xs_trans)
- goto fail;
-
- snprintf(ref, sizeof ref, "%d", ring_ref);
- snprintf(buf, sizeof buf, "%s/ring-ref", xs_base);
- if (!xs_write(xs, xs_trans, buf, ref, strlen(ref)))
- goto fail;
- if (!xs_set_permissions(xs, xs_trans, buf, perms, 2))
- goto fail;
-
- snprintf(ref, sizeof ref, "%d", ctrl->event_port);
- snprintf(buf, sizeof buf, "%s/event-channel", xs_base);
- if (!xs_write(xs, xs_trans, buf, ref, strlen(ref)))
- goto fail;
- if (!xs_set_permissions(xs, xs_trans, buf, perms, 2))
- goto fail;
-
- if (!xs_transaction_end(xs, xs_trans, 0)) {
- if (errno == EAGAIN)
- goto retry_transaction;
- } else {
- ret = 0;
+ for (;;) {
+ xs_trans = xs_transaction_start(xs);
+ if (!xs_trans)
+ goto fail;
+
+ snprintf(ref, sizeof ref, "%d", ring_ref);
+ snprintf(buf, sizeof buf, "%s/ring-ref", xs_base);
+ if (!xs_write(xs, xs_trans, buf, ref, strlen(ref)))
+ goto fail;
+ if (!xs_set_permissions(xs, xs_trans, buf, perms, 2))
+ goto fail;
+
+ snprintf(ref, sizeof ref, "%d", ctrl->event_port);
+ snprintf(buf, sizeof buf, "%s/event-channel", xs_base);
+ if (!xs_write(xs, xs_trans, buf, ref, strlen(ref)))
+ goto fail;
+ if (!xs_set_permissions(xs, xs_trans, buf, perms, 2))
+ goto fail;
+
+ if (xs_transaction_end(xs, xs_trans, 0))
+ break;
+ else if (errno != EAGAIN)
+ goto fail;
+ /* EAGAIN, retry */
}
+ ret = 0;
+
fail:
free(domid_str);
xs_close(xs);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 7/8] tools/libvchan: libxenvchan_*_init: Promise an errno
Thse functiosn do in fact leave errno set. We are going to want to
use this.
Signed-off-by: Ian Jackson
---
tools/libvchan/libxenvchan.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libvchan/libxenvchan.h b/tools/libvchan/libxenvchan.h
index d6010b145d..e4ccca1ff0 100644
--- a/tools/libvchan/libxenvchan.h
+++ b/tools/libvchan/libxenvchan.h
@@ -95,7 +95,7 @@ struct libxenvchan {
* @param xs_path Base xenstore path for storing ring/event data
* @param send_min The minimum size (in bytes) of the send ring (left)
* @param recv_min The minimum size (in bytes) of the receive ring (right)
- * @return The structure, or NULL in case of an error
+ * @return The structure, or NULL in case of an error (setting errno)
*/
struct libxenvchan *libxenvchan_server_init(struct xentoollog_logger *logger,
int domain, const char* xs_path,
@@ -108,7 +108,7 @@ struct libxenvchan *libxenvchan_server_init(struct
xentoollog_logger *logger,
* @param logger Logger for libxc errors
* @param domain The peer domain to connect to
* @param xs_path Base xenstore path for storing ring/event data
- * @return The structure, or NULL in case of an error
+ * @return The structure, or NULL in case of an error (setting errno)
*/
struct libxenvchan *libxenvchan_client_init(struct xentoollog_logger *logger,
int domain, const char* xs_path);
--
2.11.0
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/8] tools/libvchan: Initialise xs_transaction_t to XBT_NULL, not NULL
This is an integer type, not a pointer. Signed-off-by: Ian Jackson --- tools/libvchan/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libvchan/init.c b/tools/libvchan/init.c index ba5a6eb29e..180833dc2f 100644 --- a/tools/libvchan/init.c +++ b/tools/libvchan/init.c @@ -250,7 +250,7 @@ static int init_xs_srv(struct libxenvchan *ctrl, int domain, const char* xs_base char buf[64]; char ref[16]; char* domid_str = NULL; - xs_transaction_t xs_trans = NULL; + xs_transaction_t xs_trans = XBT_NULL; xs = xs_domain_open(); if (!xs) goto fail; -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/8] libvchan: Minor improvements
Mostly internal tidying, but also an API promise about what ENOENT means from libxenvchan_client_init. Ian Jackson (8): tools/libvchan: Initialise xs_transaction_t to XBT_NULL, not NULL tools/xenstore: Document that xs_close(0) is OK. tools/libvchan: init_xs_srv: Simplify error handling (1) tools/libvchan: init_xs_srv: Simplify error handling (2) tools/libvchan: init_xs_srv: Turn xs retry from goto into for (;;) tools/libvchan: Add xentoollog to direct dependencies tools/libvchan: libxenvchan_*_init: Promise an errno tools/libvchan: libxenvchan_client_init: use ENOENT for no server tools/libvchan/Makefile | 6 ++-- tools/libvchan/init.c | 72 ++- tools/libvchan/libxenvchan.h | 8 +++-- tools/libvchan/xenvchan.pc.in | 2 +- tools/xenstore/include/xenstore.h | 2 +- 5 files changed, 52 insertions(+), 38 deletions(-) -- 2.11.0 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [distros-debian-jessie test] 75562: tolerable FAIL
flight 75562 distros-debian-jessie real [real] http://osstest.xensource.com/osstest/logs/75562/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-i386-jessie-netboot-pvgrub 19 guest-start/debian.repeat fail blocked in 75509 test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail blocked in 75509 baseline version: flight 75509 jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-amd64-jessie-netboot-pvgrub pass test-amd64-i386-i386-jessie-netboot-pvgrub fail test-amd64-i386-amd64-jessie-netboot-pygrub pass test-armhf-armhf-armhf-jessie-netboot-pygrub fail test-amd64-amd64-i386-jessie-netboot-pygrub pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [RFC PATCH v2 00/17] Add support for qemu-xen runnning in a Linux-based stubdomain.
Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for
qemu-xen runnning in a Linux-based stubdomain."):
> Doing it in this order would be susceptible to a race condition -
> server appearing after libxenvchan_client_init check, but before libxl
> register the watch.
I see the race you mean but happily xenstore already has a general
mechanism for avoiding it: after setting up a watch, it always fires
once immediately. (Obviously we could have done the equivalent thing
open-coded in the caller of my proposed new init function variant.)
> Also, right now libxenvchan_client_init have only
> one possible error code: NULL (instead of struct libxenvchan *). Adding
> more elaborate error reporting would require API change.
I think libxenvchan_client_init sets errno. All of the functions it
calls do so, so the errno value is passed through. So we would just
need to reserve a specific errno value for this.
> As the xs path is provided by libxenvchan_client_init caller anyway,
> libxl can register watch before calling libxenvchan_client_init and wait
> on it
Yes. (Sorry I didn't see that parameter yesterday. I was really
being quite dim.)
Although because of the xswatch behaviour I describe above, libxl can
simply set up the watch unconditionally, and call
libxenvchan_client_init in the xswatch event handler function.
> if libxenvchan_client_init fails.
I'm not a fan of this. I tend to be quite picky about error
handling. I think we should define a specific errno value for `server
not set up'. ENOENT is what it currently returns, so if we use that
we won't break existing clients.
As belt and braces we should probably have libxenvchan_client_init
turn any ENOENT other than from the xs_read of ring-ref into EIO with
a log error message.
I worked up a patch to do that, which I will post in a moment. It
turned into a series...
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 3/3] x86emul: consolidate CR4 handling
Now that there's an almost unconditional CR4 read right at the beginning
of x86_emulate(), centralize its reading there and use result and value
everywhere else without further invoking the hook.
Subsequently we may want to consider having the callers provide
whichever value they deem appropriate in their contexts, to avoid
invoking the hook altogether for this purpose.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1163,10 +1163,19 @@ do {
ops->write_segment(x86_seg_cs, cs, ctxt); \
})
+#define check_cr4() ({ \
+if ( unlikely(cr4_rc != X86EMUL_OKAY) ) \
+{ \
+rc = cr4_rc;\
+goto done; \
+} \
+})
+
static int _get_fpu(
enum x86_emulate_fpu_type type,
struct x86_emulate_ctxt *ctxt,
-const struct x86_emulate_ops *ops)
+const struct x86_emulate_ops *ops,
+unsigned long cr4, int cr4_rc)
{
uint64_t xcr0;
int rc;
@@ -1208,11 +1217,7 @@ static int _get_fpu(
fail_if(!ops->read_cr);
if ( type >= X86EMUL_FPU_xmm )
{
-unsigned long cr4;
-
-rc = ops->read_cr(4, , ctxt);
-if ( rc != X86EMUL_OKAY )
-return rc;
+check_cr4();
generate_exception_if(!(cr4 & ((type == X86EMUL_FPU_xmm)
? X86_CR4_OSFXSR :
X86_CR4_OSXSAVE)),
EXC_UD);
@@ -1243,7 +1248,7 @@ static int _get_fpu(
#define get_fpu(type) \
do {\
-rc = _get_fpu(fpu_type = (type), ctxt, ops);\
+rc = _get_fpu(fpu_type = (type), ctxt, ops, cr4, cr4_rc); \
if ( rc ) goto done;\
} while (0)
@@ -1603,13 +1608,9 @@ _mode_iopl(
_iopl; \
})
#define mode_vif() ({\
-cr4 = 0; \
-if ( ops->read_cr && get_cpl(ctxt, ops) == 3 ) \
-{\
-rc = ops->read_cr(4, , ctxt);\
-if ( rc != X86EMUL_OKAY ) goto done; \
-}\
-!!(cr4 & (_regs.eflags & X86_EFLAGS_VM ? X86_CR4_VME : X86_CR4_PVI)); \
+check_cr4(); \
+get_cpl(ctxt, ops) == 3 && \
+(cr4 & (_regs.eflags & X86_EFLAGS_VM ? X86_CR4_VME : X86_CR4_PVI)); \
})
static int ioport_access_check(
@@ -2185,14 +2186,11 @@ static bool is_branch_step(struct x86_em
}
static bool umip_active(struct x86_emulate_ctxt *ctxt,
-const struct x86_emulate_ops *ops)
+const struct x86_emulate_ops *ops,
+unsigned long cr4)
{
-unsigned long cr4;
-
/* Intentionally not using mode_ring0() here to avoid its fail_if(). */
-return get_cpl(ctxt, ops) > 0 &&
- ops->read_cr && ops->read_cr(4, , ctxt) == X86EMUL_OKAY &&
- (cr4 & X86_CR4_UMIP);
+return get_cpl(ctxt, ops) > 0 && (cr4 & X86_CR4_UMIP);
}
static void adjust_bnd(struct x86_emulate_ctxt *ctxt,
@@ -3226,7 +3224,7 @@ x86_emulate(
/* Shadow copy of register state. Committed on successful emulation. */
struct cpu_user_regs _regs = *ctxt->regs;
struct x86_emulate_state state;
-int rc;
+int rc, cr4_rc;
uint8_t b, d, *opc = NULL;
unsigned int first_byte = 0, insn_bytes = 0;
bool singlestep = (_regs.eflags & X86_EFLAGS_TF) &&
@@ -3234,7 +3232,7 @@ x86_emulate(
bool sfence = false;
struct operand src = { .reg = PTR_POISON };
struct operand dst = { .reg = PTR_POISON };
-unsigned long cr4;
+unsigned long cr4 = 0;
enum x86_emulate_fpu_type fpu_type = X86EMUL_FPU_none;
struct x86_emulate_stub stub = {};
DECLARE_ALIGNED(mmval_t, mmval);
@@ -3247,6 +3245,8 @@ x86_emulate(
ASSERT(ops->read);
+cr4_rc = ops->read_cr ? ops->read_cr(4, , ctxt) : X86EMUL_OKAY;
+
generate_exception_if((mode_vif() &&
(_regs.eflags & X86_EFLAGS_VIF) &&
(_regs.eflags & X86_EFLAGS_VIP)),
@@ -4000,13 +4000,8 @@ x86_emulate(
if ( (_regs.eflags & X86_EFLAGS_VM) &&
MASK_EXTR(_regs.eflags, X86_EFLAGS_IOPL) != 3 )
{
-cr4 = 0;
-if ( op_bytes == 2 && ops->read_cr )
-{
-rc = ops->read_cr(4, , ctxt);
-if ( rc != X86EMUL_OKAY )
-goto done;
-}
+if ( op_bytes == 2 )
+
[Xen-devel] [PATCH 2/3] x86emul: raise #GP(0) in VME mode for POPF with TF set in new value
This is a check explicitly listed by the instruction page in the SDM.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4049,6 +4049,7 @@ x86_emulate(
dst.val = (uint16_t)dst.val | (_regs.eflags & 0xu);
if ( cr4 & X86_CR4_VME )
{
+generate_exception_if(dst.val & X86_EFLAGS_TF, EXC_GP, 0);
if ( dst.val & X86_EFLAGS_IF )
{
generate_exception_if(_regs.eflags & X86_EFLAGS_VIP,
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 1/3] x86emul: VME and PVI modes require a #GP(0) check first thing
As explicitly spelled out by the SDM, EFLAGS.VIF and EFLAGS.VIP both set at the start of an instruction trigger #GP(0) independent of actual instruction. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -3247,6 +3247,11 @@ x86_emulate( ASSERT(ops->read); +generate_exception_if((mode_vif() && + (_regs.eflags & X86_EFLAGS_VIF) && + (_regs.eflags & X86_EFLAGS_VIP)), + EXC_GP, 0); + rc = x86_decode(, ctxt, ops); if ( rc != X86EMUL_OKAY ) return rc; ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH 0/3] x86emul: VME/PVI mode fixes
1: VME and PVI modes require a #GP(0) check first thing 2: raise #GP(0) in VME mode for POPF with TF set in new value 3: consolidate CR4 handling Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 2/2] x86: deal with firmware setting bogus TSC_ADJUST values
The system Intel have handed me for AVX512 emulator work ("Gigabyte
Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3
Pro-CF, BIOS F3 12/28/2017") would not come up under Xen - it hung in
the middle of Dom0 PCI initialization. As it turned out, Xen's time
management did not work because of the firmware setting (only) the boot
CPU's TSC_ADJUST MSR to a large negative value (on the order of -2^50).
Follow Linux (also shamelessly stealing their comments) in
- clearing the register for the boot CPU (we don't have a need for
exceptions here yet, as the only exception in Linux is a class of
systems Xen doesn't work on anyway as far as I'm aware),
- forcing non-negative values uniformly (commit 855615eee9 ["x86/tsc:
Remove the TSC_ADJUST clamp"] dropped this, but without this my
Haswell box won't boot anymore),
- syncing the registers within sockets.
Linux, prior to aforementioned commit, capped at 0x7fff as well, but as the
description there says this issue has been addressed with a microcode
update. Hence until someone runs into such a system without being able
to update its microcode, I think we should leave out that specific part.
In order to avoid making init_percpu_time() depend on running _before_
set_cpu_sibling_map() (and hence the booting CPU _not_ being accounted
in socket_cpumask[] yet), move that call slightly earlier in
start_secondary().
Signed-off-by: Jan Beulich
---
v2: Make description match up-to-date Linux, rather than 4.12, and
adjust a code comment accordingly.
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -381,6 +381,8 @@ void start_secondary(void *unused)
smp_callin();
+set_cpu_sibling_map(cpu);
+
init_percpu_time();
setup_secondary_APIC_clock();
@@ -393,7 +395,6 @@ void start_secondary(void *unused)
/* This must be done before setting cpu_online_map */
spin_debug_enable();
-set_cpu_sibling_map(cpu);
notify_cpu_starting(cpu);
/*
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -88,6 +88,9 @@ static bool __read_mostly using_pit;
/* Boot timestamp, filled in head.S */
u64 __initdata boot_tsc_stamp;
+/* Per-socket TSC_ADJUST values, for secondary cores/threads to sync to. */
+static uint64_t *__read_mostly tsc_adjust;
+
/*
* 32-bit division of integer dividend and integer divisor yielding
* 32-bit fractional quotient.
@@ -1602,6 +1605,56 @@ void init_percpu_time(void)
/* Initial estimate for TSC rate. */
t->tsc_scale = per_cpu(cpu_time, 0).tsc_scale;
+if ( tsc_adjust )
+{
+unsigned int socket = cpu_to_socket(smp_processor_id());
+int64_t adj;
+
+/* For now we don't want to come here for the BSP. */
+ASSERT(system_state >= SYS_STATE_smp_boot);
+
+rdmsrl(MSR_IA32_TSC_ADJUST, adj);
+
+/*
+ * Check whether this CPU is the first in a package to come up. In
+ * this case do not check the boot value against another package
+ * because the new package might have been physically hotplugged,
+ * where TSC_ADJUST is expected to be different.
+ */
+if ( cpumask_weight(socket_cpumask[socket]) == 1 )
+{
+/*
+ * On the boot CPU we just force the ADJUST value to 0 if it's non-
+ * zero (in early_time_init()). We don't do that on non-boot CPUs
+ * because physical hotplug should have set the ADJUST register to
a
+ * value > 0, so the TSC is in sync with the already running CPUs.
+ *
+ * But we always force non-negative ADJUST values for now.
+ */
+if ( adj < 0 )
+{
+printk(XENLOG_WARNING
+ "TSC ADJUST set to -%lx on CPU%u - clearing\n",
+ -adj, smp_processor_id());
+wrmsrl(MSR_IA32_TSC_ADJUST, 0);
+adj = 0;
+}
+tsc_adjust[socket] = adj;
+}
+else if ( adj != tsc_adjust[socket] )
+{
+static bool __read_mostly warned;
+
+if ( !warned )
+{
+warned = true;
+printk(XENLOG_WARNING
+ "Differing TSC ADJUST values within socket(s) - fixing
all\n");
+}
+wrmsrl(MSR_IA32_TSC_ADJUST, tsc_adjust[socket]);
+}
+}
+
local_irq_save(flags);
now = read_platform_stime(NULL);
tsc = rdtsc_ordered();
@@ -1788,6 +1841,15 @@ int __init init_xen_time(void)
/* Finish platform timer initialization. */
try_platform_timer_tail(false);
+/*
+ * Setup space to track per-socket TSC_ADJUST values. Don't fiddle with
+ * values if the TSC is not reported as invariant. Ignore allocation
+ * failure here - most systems won't need any adjustment anyway.
+ */
+if ( boot_cpu_has(X86_FEATURE_TSC_ADJUST) &&
+ boot_cpu_has(X86_FEATURE_ITSC) )
+tsc_adjust =
[Xen-devel] [PATCH v2 1/2] x86/TSC: don't allow deadline timer to be used with unfixed errata
In preparation of writes to the TSC_ADJUST MSR, avoid the bad
interaction of writes to it and the TSC_DEADLINE one. Presumably the
original Linux commit bd9240a18e ("x86/apic: Add TSC_DEADLINE quirk due
to errata") refers to e.g. KBW092. (Of course this is an issue also
without us writing the TSC_ADJUST MSR, if instead firmware did already.
The errata checking can't be put in init_apic_mappings() as Linux does,
as that runs before we update microcode on the boot CPU. It needs to
happen before consumers of tdt_enabled, i.e.
- __setup_APIC_LVTT() <- setup_APIC_timer() <- setup_boot_APIC_clock()
- <- calibrate_APIC_clock() <- setup_boot_APIC_clock()
- setup_boot_APIC_clock()
setup_boot_APIC_clock() gets called from smp_prepare_cpus(), which sits
after microcode loading (note that calibrate_APIC_clock() gets called
before setting tdt_enabled).
Also add an MFENCE as per Linux commit 5d7c631d92 ("x86/apic: Serialize
LVTT and TSC_DEADLINE writes"), but I see no reason to put a conditional
around it.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1078,6 +1079,13 @@ static void __setup_APIC_LVTT(unsigned i
apic_write(APIC_LVTT, lvtt_value);
+/*
+ * See Intel SDM: TSC-Deadline Mode chapter. In xAPIC mode,
+ * writing to the APIC LVTT and TSC_DEADLINE MSR isn't serialized.
+ * According to Intel, MFENCE can do the serialization here.
+ */
+asm volatile( "mfence" : : : "memory" );
+
tmp_value = apic_read(APIC_TDCR);
apic_write(APIC_TDCR, tmp_value | APIC_TDR_DIV_1);
@@ -1092,6 +1100,97 @@ static void setup_APIC_timer(void)
local_irq_restore(flags);
}
+#define DEADLINE_MODEL_MATCH(m, fr) \
+{ .vendor = X86_VENDOR_INTEL, .family = 6, .model = (m), \
+ .feature = X86_FEATURE_TSC_DEADLINE, \
+ .driver_data = (void *)(unsigned long)(fr) }
+
+static unsigned int __init hsx_deadline_rev(void)
+{
+switch ( boot_cpu_data.x86_mask )
+{
+case 0x02: return 0x3a; /* EP */
+case 0x04: return 0x0f; /* EX */
+}
+
+return ~0U;
+}
+
+static unsigned int __init bdx_deadline_rev(void)
+{
+switch ( boot_cpu_data.x86_mask )
+{
+case 0x02: return 0x0011;
+case 0x03: return 0x070e;
+case 0x04: return 0x0f0c;
+case 0x05: return 0x0e03;
+}
+
+return ~0U;
+}
+
+static unsigned int __init skx_deadline_rev(void)
+{
+switch ( boot_cpu_data.x86_mask )
+{
+case 0x00 ... 0x02: return ~0U;
+case 0x03: return 0x01000136;
+case 0x04: return 0x0214;
+}
+
+return 0;
+}
+
+static const struct x86_cpu_id __initconstrel deadline_match[] = {
+DEADLINE_MODEL_MATCH(0x3c, 0x22), /* Haswell */
+DEADLINE_MODEL_MATCH(0x3f, hsx_deadline_rev), /* Haswell EP/EX */
+DEADLINE_MODEL_MATCH(0x45, 0x20), /* Haswell D */
+DEADLINE_MODEL_MATCH(0x46, 0x17), /* Haswell H */
+
+DEADLINE_MODEL_MATCH(0x3d, 0x25), /* Broadwell */
+DEADLINE_MODEL_MATCH(0x47, 0x17), /* Broadwell H */
+DEADLINE_MODEL_MATCH(0x4f, 0x0b20), /* Broadwell EP/EX */
+DEADLINE_MODEL_MATCH(0x56, bdx_deadline_rev), /* Broadwell D */
+
+DEADLINE_MODEL_MATCH(0x4e, 0xb2), /* Skylake M */
+DEADLINE_MODEL_MATCH(0x55, skx_deadline_rev), /* Skylake X */
+DEADLINE_MODEL_MATCH(0x5e, 0xb2), /* Skylake D */
+
+DEADLINE_MODEL_MATCH(0x8e, 0x52), /* Kabylake M */
+DEADLINE_MODEL_MATCH(0x9e, 0x52), /* Kabylake D */
+
+{}
+};
+
+static void __init check_deadline_errata(void)
+{
+const struct x86_cpu_id *m;
+unsigned int rev;
+
+if ( boot_cpu_has(X86_FEATURE_HYPERVISOR) )
+return;
+
+m = x86_match_cpu(deadline_match);
+if ( !m )
+return;
+
+/*
+ * Function pointers will have the MSB set due to address layout,
+ * immediate revisions will not.
+ */
+if ( (long)m->driver_data < 0 )
+rev = ((unsigned int (*)(void))(m->driver_data))();
+else
+rev = (unsigned long)m->driver_data;
+
+if ( this_cpu(ucode_cpu_info).cpu_sig.rev >= rev )
+return;
+
+setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE);
+printk(XENLOG_WARNING "TSC_DEADLINE disabled due to Errata; "
+ "please update microcode to version %#x (or later)\n", rev);
+}
+
static void wait_tick_pvh(void)
{
u64 lapse_ns = 10ULL / HZ;
@@ -1201,6 +1300,8 @@ void __init setup_boot_APIC_clock(void)
apic_printk(APIC_VERBOSE, "Using local APIC timer interrupts.\n");
using_apic_timer = true;
+check_deadline_errata();
+
local_irq_save(flags);
calibrate_APIC_clock();
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages] [and 2 more messages] [and 2 more messages]"):
> On 02/11/2018 15:44, Ian Jackson wrote:
> > We have more x86 capacity and are deploying some dedicated build
> > hosts. But cross-compilation is more complex (particularly the
> > compiler conflict...)
>
> Do you mean the multilib problem? This issue is only when cross-compiling
> tools
> (which I would not recommend anyway...). For things like kernel and
> hypervisor,
> you don't need multilib.
Yes, that problem.
I think by `cross-compiling' here you mean to include running gcc -m32
on an amd64 host or vice versa, which is not quite real
cross-compiling in my view. But it does require gcc-multilib.
But, as it turns out, you are right that this is not a problem for
osstest. When osstest does builds for an i386 dom0, it does the
hypervisor build on an amd64 host and the tools build separately on an
i386 host.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v2 0/2] x86: deal with firmware setting bogus TSC_ADJUST values
1: x86/TSC: don't allow deadline timer to be used with unfixed errata 2: x86: deal with firmware setting bogus TSC_ADJUST values v2: New patch 1, only cosmetic changes to patch 2. Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages]
On Fri, 2 Nov 2018, Lars Kurth wrote: > I thought that we could have provided a deb repository with alternative > kernels for OSSTests to use. We would have scripts to generate those deb > packages from the Xen ARM Linux tree in a repository on xenbits, but we > wouldn't necessarily have OSSTest run the script. Initially, we could > run the scripts by hand, then, we could run them automatically in > OSSTest or elsewhere. Is that a possibility? I already have Dockerfiles > (AKA bash scripts) to build an ARM kernel on a few distros, that's > something I could make available. > > This morning Julien had one more different suggestion: building the > kernel with OSSTest on SoftIron, that we know it works, it would be a > native compilation. Then we could use the built kernel together with the > Debian installer on the other boards (Xilinx, Renesas, etc.) > > Either way, the kernel to be used with the embedded boards doesn't need > to be rebuilt often, only once a month or so. > > That would fit with the https://gitlab.com/xen-project/xen/container_registry > model > where we store Dom0 baselines as containers for builds via the Gitlab CI > > This may be a stupid idea, but I wanted to make sure that we consider all > options This is not a stupid idea -- it is exactly the kind of thing I had in mind too ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] CONFIG_XEN_PV breaks xen_create_contiguous_region on ARM
On 01/11/2018 00:11, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> xen_create_contiguous_region has now only an implementation if
> CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
> we do have an implementation of xen_create_contiguous_region which is
> required for swiotlb-xen to work correctly (although it just sets
> *dma_handle).
>
> Fixes: 16624390816c ("xen: create xen_create/destroy_contiguous_region()
> stubs for PVHVM only builds")
> Signed-off-by: Stefano Stabellini
> CC: jeff.kubas...@dornerworks.com
> CC: jarvis.ro...@dornerworks.com
> CC: nathan.stu...@dornerworks.com
> CC: vkuzn...@redhat.com
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> CC: julien.gr...@arm.com
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Hi,
On 02/11/2018 15:44, Ian Jackson wrote:
Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more
messages] [and 2 more messages] [and 2 more messages]"):
On 02/11/2018 15:05, Ian Jackson wrote:
I guess that's probably tolerable. We'd have to think about whether
we should snapshot them, or install them directly from upstream. The
latter is less coding effort in osstest (just add an apt source and
run the install rune I guess) but it would imply tracking these in an
uncontrolled way, so we would want to be confident that they are
maintained to a high standard, since problems with the compiler would
break everything for us. Also I would ask: how reliable is their apt
repository hosting ? If it goes down, likewise, everything would
break for us.
Linaro hosting is pretty reliable. But AFAIK, they don't have an apt repo for
the toolchains. We would need to download a tarball and unpack it.
That would be doable. If the tarballs have versions we could put the
version number in the osstest config and then it would be push gated.
Perhaps Julien has time to do that.
Arm64 cross-compiler in Debian should be suitable enough for building the
kernel. If there are any issue with them, then a bug report should be filled.
OK, that's definitely going to be easier then.
My preference is to avoid cross-compiling if we can. This would avoid to use x86
resource for building kernel that could be re-used for testing Xen itself.
We have more x86 capacity and are deploying some dedicated build
hosts. But cross-compilation is more complex (particularly the
compiler conflict...)
Do you mean the multilib problem? This issue is only when cross-compiling tools
(which I would not recommend anyway...). For things like kernel and hypervisor,
you don't need multilib.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 1/7] x86: make traps.c build with !CONFIG_PV
Provide a stub for pv_inject_event, put code that accesses PV fields
and GDT / LDT fault handling code under CONFIG_PV.
Signed-off-by: Wei Liu
---
v3:
1. don't skip updating dr_masks in activate_debugregs.
2. remove ASSERT_UNREACHABLE in fixup_page_fault.
v2: reduce the amount of ifdefs
---
xen/arch/x86/traps.c | 16
xen/include/asm-x86/domain.h | 7 +++
2 files changed, 23 insertions(+)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index c60c8f5..69449e0 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1115,6 +1115,7 @@ static void reserved_bit_page_fault(unsigned long addr,
show_execution_state(regs);
}
+#ifdef CONFIG_PV
static int handle_ldt_mapping_fault(unsigned int offset,
struct cpu_user_regs *regs)
{
@@ -1185,6 +1186,7 @@ static int handle_gdt_ldt_mapping_fault(unsigned long
offset,
return EXCRET_fault_fixed;
}
+#endif
#define IN_HYPERVISOR_RANGE(va) \
(((va) >= HYPERVISOR_VIRT_START) && ((va) < HYPERVISOR_VIRT_END))
@@ -1335,10 +1337,12 @@ static int fixup_page_fault(unsigned long addr, struct
cpu_user_regs *regs)
if ( unlikely(IN_HYPERVISOR_RANGE(addr)) )
{
+#ifdef CONFIG_PV
if ( !(regs->error_code & (PFEC_user_mode | PFEC_reserved_bit)) &&
(addr >= GDT_LDT_VIRT_START) && (addr < GDT_LDT_VIRT_END) )
return handle_gdt_ldt_mapping_fault(
addr - GDT_LDT_VIRT_START, regs);
+#endif
return 0;
}
@@ -1494,7 +1498,9 @@ void __init do_early_page_fault(struct cpu_user_regs
*regs)
void do_general_protection(struct cpu_user_regs *regs)
{
+#ifdef CONFIG_PV
struct vcpu *v = current;
+#endif
unsigned long fixup;
if ( debugger_trap_entry(TRAP_gp_fault, regs) )
@@ -1506,6 +1512,7 @@ void do_general_protection(struct cpu_user_regs *regs)
if ( !guest_mode(regs) )
goto gp_in_kernel;
+#ifdef CONFIG_PV
/*
* Cunning trick to allow arbitrary "INT n" handling.
*
@@ -1557,6 +1564,7 @@ void do_general_protection(struct cpu_user_regs *regs)
/* Pass on GPF as is. */
pv_inject_hw_exception(TRAP_gp_fault, regs->error_code);
return;
+#endif
gp_in_kernel:
@@ -1744,7 +1752,9 @@ void unset_nmi_callback(void)
void do_device_not_available(struct cpu_user_regs *regs)
{
+#ifdef CONFIG_PV
struct vcpu *curr = current;
+#endif
if ( !guest_mode(regs) )
{
@@ -1762,6 +1772,7 @@ void do_device_not_available(struct cpu_user_regs *regs)
return;
}
+#ifdef CONFIG_PV
vcpu_restore_fpu_lazy(curr);
if ( curr->arch.pv.ctrlreg[0] & X86_CR0_TS )
@@ -1771,6 +1782,9 @@ void do_device_not_available(struct cpu_user_regs *regs)
}
else
TRACE_0D(TRC_PV_MATH_STATE_RESTORE);
+#else
+ASSERT_UNREACHABLE();
+#endif
return;
}
@@ -2078,6 +2092,7 @@ void activate_debugregs(const struct vcpu *curr)
}
}
+#ifdef CONFIG_PV
/*
* Used by hypercalls and the emulator.
* -ENODEV => #UD
@@ -2193,6 +2208,7 @@ long set_debugreg(struct vcpu *v, unsigned int reg,
unsigned long value)
return 0;
}
+#endif /* CONFIG_PV */
void asm_domain_crash_synchronous(unsigned long addr)
{
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 7214037..643e69a 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -681,7 +681,14 @@ void arch_vcpu_regs_init(struct vcpu *v);
struct vcpu_hvm_context;
int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context
*ctx);
+#ifdef CONFIG_PV
void pv_inject_event(const struct x86_event *event);
+#else
+static inline void pv_inject_event(const struct x86_event *event)
+{
+ASSERT_UNREACHABLE();
+}
+#endif
static inline void pv_inject_hw_exception(unsigned int vector, int errcode)
{
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 3/7] x86: make PV hypercall entry points work with !CONFIG_PV
We want Xen to crash if we hit these paths when PV is disabled.
For syscall, we provide stubs for {l,c}star_enter which end up calling
panic. For sysenter, we initialise CS to 0 so that #GP can be raised.
Signed-off-by: Wei Liu
---
v3: rewrite
---
xen/arch/x86/hvm/vmx/vmcs.c | 5 +++--
xen/arch/x86/x86_64/traps.c | 19 +--
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index d9747b4..dec21d1 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1160,8 +1160,9 @@ static int construct_vmcs(struct vcpu *v)
__vmwrite(HOST_RIP, (unsigned long)vmx_asm_vmexit_handler);
/* Host SYSENTER CS:RIP. */
-__vmwrite(HOST_SYSENTER_CS, __HYPERVISOR_CS);
-__vmwrite(HOST_SYSENTER_EIP, (unsigned long)sysenter_entry);
+__vmwrite(HOST_SYSENTER_CS, IS_ENABLED(CONFIG_PV) ? __HYPERVISOR_CS : 0);
+__vmwrite(HOST_SYSENTER_EIP,
+ IS_ENABLED(CONFIG_PV) ? (unsigned long)sysenter_entry : 0);
/* MSR intercepts. */
__vmwrite(VM_EXIT_MSR_LOAD_COUNT, 0);
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 27154f2..35a60d4 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -298,8 +298,21 @@ static unsigned int write_stub_trampoline(
}
DEFINE_PER_CPU(struct stubs, stubs);
+
+#ifdef CONFIG_PV
void lstar_enter(void);
void cstar_enter(void);
+#else
+static inline void lstar_enter(void)
+{
+panic("%s called", __func__);
+}
+
+static inline void cstar_enter(void)
+{
+panic("%s called", __func__);
+}
+#endif /* CONFIG_PV */
void subarch_percpu_traps_init(void)
{
@@ -329,8 +342,10 @@ void subarch_percpu_traps_init(void)
{
/* SYSENTER entry. */
wrmsrl(MSR_IA32_SYSENTER_ESP, stack_bottom);
-wrmsrl(MSR_IA32_SYSENTER_EIP, (unsigned long)sysenter_entry);
-wrmsr(MSR_IA32_SYSENTER_CS, __HYPERVISOR_CS, 0);
+wrmsrl(MSR_IA32_SYSENTER_EIP,
+ IS_ENABLED(CONFIG_PV) ? (unsigned long)sysenter_entry : 0);
+wrmsr(MSR_IA32_SYSENTER_CS,
+ IS_ENABLED(CONFIG_PV) ? __HYPERVISOR_CS : 0, 0);
}
/* Trampoline for SYSCALL entry from compatibility mode. */
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 5/7] x86: make entry point code build when !CONFIG_PV
Skip building x86_64/compat/entry.S and put CONFIG_PV in
x86_64/entry.S.
Signed-off-by: Wei Liu
---
v3:
1. make CR4_PV32_RESTORE expand to nothing when !PV
2. use unconditional jmp and add assertions
v2: new
---
xen/arch/x86/x86_64/Makefile| 2 +-
xen/arch/x86/x86_64/entry.S | 39 +-
xen/include/asm-x86/asm_defns.h | 4 +++-
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile
index f336a6a..4bfa148 100644
--- a/xen/arch/x86/x86_64/Makefile
+++ b/xen/arch/x86/x86_64/Makefile
@@ -1,4 +1,4 @@
-subdir-y += compat
+subdir-$(CONFIG_PV) += compat
obj-bin-y += entry.o
obj-y += traps.o
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 9b02899..975ed6a 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -15,6 +15,18 @@
#include
#include
+#ifndef NDEBUG
+/* %rsp: struct cpu_user_regs */
+#define ASSERT_INTERRUPTED_XEN_CONTEXT\
+testb $3, UREGS_cs(%rsp); \
+jz1f; \
+ASSERT_FAILED("INTERRUPTED XEN CONTEXT"); \
+1:
+#else
+#define ASSERT_INTERRUPTED_XEN_CONTEXT
+#endif
+
+#ifdef CONFIG_PV
/* %rbx: struct vcpu */
ENTRY(switch_to_kernel)
leaq VCPU_trap_bounce(%rbx),%rdx
@@ -522,6 +534,7 @@ ENTRY(dom_crash_sync_extable)
xorl %edi,%edi
jmp asm_domain_crash_synchronous /* Does not return */
.popsection
+#endif /* CONFIG_PV */
/* --- CODE BELOW THIS LINE (MOSTLY) NOT GUEST RELATED --- */
@@ -530,6 +543,7 @@ ENTRY(dom_crash_sync_extable)
ALIGN
/* No special register assumptions. */
ENTRY(ret_from_intr)
+#ifdef CONFIG_PV
GET_CURRENT(bx)
testb $3, UREGS_cs(%rsp)
jzrestore_all_xen
@@ -537,6 +551,10 @@ ENTRY(ret_from_intr)
cmpb $0, DOMAIN_is_32bit_pv(%rax)
jetest_all_events
jmp compat_test_all_events
+#else
+ASSERT_INTERRUPTED_XEN_CONTEXT
+jmp restore_all_xen
+#endif
.section .text.entry, "ax", @progbits
@@ -619,6 +637,7 @@ handle_exception_saved:
testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
jzexception_with_ints_disabled
+#ifdef CONFIG_PV
ALTERNATIVE_2 "jmp .Lcr4_pv32_done", \
__stringify(mov VCPU_domain(%rbx), %rax), X86_FEATURE_XEN_SMEP, \
__stringify(mov VCPU_domain(%rbx), %rax), X86_FEATURE_XEN_SMAP
@@ -658,6 +677,9 @@ handle_exception_saved:
test $~(PFEC_write_access|PFEC_insn_fetch),%eax
jzcompat_test_all_events
.Lcr4_pv32_done:
+#else
+ASSERT_INTERRUPTED_XEN_CONTEXT
+#endif /* CONFIG_PV */
sti
1: movq %rsp,%rdi
movzbl UREGS_entry_vector(%rsp),%eax
@@ -667,12 +689,17 @@ handle_exception_saved:
INDIRECT_CALL %rdx
mov %r15, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
mov %r13b, STACK_CPUINFO_FIELD(use_pv_cr3)(%r14)
+#ifdef CONFIG_PV
testb $3,UREGS_cs(%rsp)
jzrestore_all_xen
movq VCPU_domain(%rbx),%rax
cmpb $0, DOMAIN_is_32bit_pv(%rax)
jne compat_test_all_events
jmp test_all_events
+#else
+ASSERT_INTERRUPTED_XEN_CONTEXT
+jmp restore_all_xen
+#endif
/* No special register assumptions. */
exception_with_ints_disabled:
@@ -823,6 +850,7 @@ handle_ist_exception:
mov %r12, STACK_CPUINFO_FIELD(xen_cr3)(%r14)
.List_cr3_okay:
+#ifdef CONFIG_PV
CR4_PV32_RESTORE
testb $3,UREGS_cs(%rsp)
jz1f
@@ -837,7 +865,11 @@ handle_ist_exception:
movl $UREGS_kernel_sizeof/8,%ecx
movq %rdi,%rsp
rep movsq
-1: movq %rsp,%rdi
+1:
+#else
+ASSERT_INTERRUPTED_XEN_CONTEXT
+#endif
+movq %rsp,%rdi
movzbl UREGS_entry_vector(%rsp),%eax
leaq exception_table(%rip),%rdx
mov (%rdx, %rax, 8), %rdx
@@ -848,6 +880,7 @@ handle_ist_exception:
jne ret_from_intr
/* We want to get straight to the IRET on the NMI exit path. */
+#ifdef CONFIG_PV
testb $3,UREGS_cs(%rsp)
jzrestore_all_xen
GET_CURRENT(bx)
@@ -863,6 +896,10 @@ handle_ist_exception:
cmpb $0,DOMAIN_is_32bit_pv(%rax)
jerestore_all_guest
jmp compat_restore_all_guest
+#else
+ASSERT_INTERRUPTED_XEN_CONTEXT
+jmp restore_all_xen
+#endif
ENTRY(machine_check)
pushq $0
diff --git a/xen/include/asm-x86/asm_defns.h b/xen/include/asm-x86/asm_defns.h
index da504ea..e688cf1 100644
--- a/xen/include/asm-x86/asm_defns.h
+++ b/xen/include/asm-x86/asm_defns.h
@@ -321,10 +321,14 @@ static always_inline void stac(void)
subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp
.endm
+#ifdef CONFIG_PV
#define CR4_PV32_RESTORE \
ALTERNATIVE_2 "", \
"call cr4_pv32_restore",
[Xen-devel] [PATCH v3 4/7] x86: rearrange x86_64/entry.S
Split the file into two halves. The first half pertains to PV guest code while the second half is mostly used by the hypervisor itself to handle interrupts and exceptions. No functional change intended. Signed-off-by: Wei Liu --- v3: remove self_ipi_restore_all_guest v2: new, requested by Andrew --- xen/arch/x86/x86_64/entry.S | 65 -- 1 file changed, 35 insertions(+), 30 deletions(-) diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S index 48cb96c..9b02899 100644 --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -121,16 +121,6 @@ process_trap: call create_bounce_frame jmp test_all_events -/* No special register assumptions. */ -ENTRY(ret_from_intr) -GET_CURRENT(bx) -testb $3, UREGS_cs(%rsp) -jzrestore_all_xen -movq VCPU_domain(%rbx), %rax -cmpb $0, DOMAIN_is_32bit_pv(%rax) -jetest_all_events -jmp compat_test_all_events - .section .text.entry, "ax", @progbits /* %rbx: struct vcpu, interrupts disabled */ @@ -211,26 +201,6 @@ iret_exit_to_guest: .Lft0: iretq _ASM_PRE_EXTABLE(.Lft0, handle_exception) -ALIGN -/* No special register assumptions. */ -restore_all_xen: -/* - * Check whether we need to switch to the per-CPU page tables, in - * case we return to late PV exit code (from an NMI or #MC). - */ -GET_STACK_END(bx) -cmpb $0, STACK_CPUINFO_FIELD(use_pv_cr3)(%rbx) -UNLIKELY_START(ne, exit_cr3) -mov STACK_CPUINFO_FIELD(pv_cr3)(%rbx), %rax -mov %rax, %cr3 -UNLIKELY_END(exit_cr3) - -/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */ -SPEC_CTRL_EXIT_TO_XEN_IST /* Req: %rbx=end, Clob: acd */ - -RESTORE_ALL adj=8 -iretq - /* * When entering SYSCALL from kernel mode: * %rax= hypercall vector @@ -553,8 +523,43 @@ ENTRY(dom_crash_sync_extable) jmp asm_domain_crash_synchronous /* Does not return */ .popsection +/* --- CODE BELOW THIS LINE (MOSTLY) NOT GUEST RELATED --- */ + +.text + +ALIGN +/* No special register assumptions. */ +ENTRY(ret_from_intr) +GET_CURRENT(bx) +testb $3, UREGS_cs(%rsp) +jzrestore_all_xen +movq VCPU_domain(%rbx), %rax +cmpb $0, DOMAIN_is_32bit_pv(%rax) +jetest_all_events +jmp compat_test_all_events + .section .text.entry, "ax", @progbits +ALIGN +/* No special register assumptions. */ +restore_all_xen: +/* + * Check whether we need to switch to the per-CPU page tables, in + * case we return to late PV exit code (from an NMI or #MC). + */ +GET_STACK_END(bx) +cmpb $0, STACK_CPUINFO_FIELD(use_pv_cr3)(%rbx) +UNLIKELY_START(ne, exit_cr3) +mov STACK_CPUINFO_FIELD(pv_cr3)(%rbx), %rax +mov %rax, %cr3 +UNLIKELY_END(exit_cr3) + +/* WARNING! `ret`, `call *`, `jmp *` not safe beyond this point. */ +SPEC_CTRL_EXIT_TO_XEN_IST /* Req: %rbx=end, Clob: acd */ + +RESTORE_ALL adj=8 +iretq + ENTRY(common_interrupt) SAVE_ALL CLAC -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 0/7] Make CONFIG_PV work on x86
Hi all
This series makes CONFIG_PV work.
Booting a hypervisor with PVH Dom0 works.
Due to an issue in Xen implementation, XTF tests cause hypervisor to crash (seen
on staging as well). But with a local patch to work around the issue,
all XTF HVM tests passed.
See v1 cover letter for more information.
Wei.
Wei Liu (7):
x86: make traps.c build with !CONFIG_PV
x86/domctl: rework XEN_DOMCTL_{set,get}_address_size
x86: make PV hypercall entry points work with !CONFIG_PV
x86: rearrange x86_64/entry.S
x86: make entry point code build when !CONFIG_PV
x86: expose CONFIG_PV
x86: update help string for CONFIG_HVM
xen/arch/x86/Kconfig| 17 +++--
xen/arch/x86/domctl.c | 32 +++---
xen/arch/x86/hvm/vmx/vmcs.c | 5 +-
xen/arch/x86/traps.c| 16 +-
xen/arch/x86/x86_64/Makefile| 2 +-
xen/arch/x86/x86_64/entry.S | 104 +++--
xen/arch/x86/x86_64/traps.c | 19 +-
xen/include/asm-x86/asm_defns.h | 4 +-
xen/include/asm-x86/domain.h| 7 ++-
9 files changed, 156 insertions(+), 50 deletions(-)
base-commit: 6cb27e417e57c2f4d689fa19971f20f75e9c0708
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 6/7] x86: expose CONFIG_PV
Signed-off-by: Wei Liu Reviewed-by: Andrew Cooper --- v3: update text v2: guest -> domain --- xen/arch/x86/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 548cbf9..37af728 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -37,6 +37,14 @@ source "arch/Kconfig" config PV def_bool y + prompt "PV support" + ---help--- + Interfaces to support PV domains. These require guest kernel support + to run as a PV guest, but don't require any specific hardware support. + + This option is needed if you want to run PV domains. + + If unsure, say Y. config PV_LINEAR_PT bool "Support for PV linear pagetables" -- git-series 0.9.1 ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v3 2/7] x86/domctl: rework XEN_DOMCTL_{set, get}_address_size
Going through toolstack code, they are used for PV guests only.
Tighten their access to PV only. Return -EOPNOTSUPP if they are called
on HVM guests. Rewrite the code in a pattern that makes DCE work.
Signed-off-by: Wei Liu
---
v3: rewritten
---
xen/arch/x86/domctl.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index f79827e..33f9a86 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -609,19 +609,33 @@ long arch_do_domctl(
break;
case XEN_DOMCTL_set_address_size:
-if ( ((domctl->u.address_size.size == 64) && !d->arch.is_32bit_pv) ||
- ((domctl->u.address_size.size == 32) && d->arch.is_32bit_pv) )
-ret = 0;
-else if ( domctl->u.address_size.size == 32 )
-ret = switch_compat(d);
+if ( is_hvm_domain(d) )
+ret = -EOPNOTSUPP;
+else if ( is_pv_domain(d) )
+{
+if ( ((domctl->u.address_size.size == 64) && !d->arch.is_32bit_pv)
||
+ ((domctl->u.address_size.size == 32) && d->arch.is_32bit_pv) )
+ret = 0;
+else if ( domctl->u.address_size.size == 32 )
+ret = switch_compat(d);
+else
+ret = -EINVAL;
+}
else
-ret = -EINVAL;
+ASSERT_UNREACHABLE();
break;
case XEN_DOMCTL_get_address_size:
-domctl->u.address_size.size = is_pv_32bit_domain(d) ? 32 :
- BITS_PER_LONG;
-copyback = true;
+if ( is_hvm_domain(d) )
+ret = -EOPNOTSUPP;
+else if ( is_pv_domain(d) )
+{
+domctl->u.address_size.size =
+is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG;
+copyback = true;
+}
+else
+ASSERT_UNREACHABLE();
break;
case XEN_DOMCTL_set_machine_address_size:
--
git-series 0.9.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Julien Grall writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages] [and 2 more messages] [and 2 more messages]"):
> On 02/11/2018 15:05, Ian Jackson wrote:
> > I guess that's probably tolerable. We'd have to think about whether
> > we should snapshot them, or install them directly from upstream. The
> > latter is less coding effort in osstest (just add an apt source and
> > run the install rune I guess) but it would imply tracking these in an
> > uncontrolled way, so we would want to be confident that they are
> > maintained to a high standard, since problems with the compiler would
> > break everything for us. Also I would ask: how reliable is their apt
> > repository hosting ? If it goes down, likewise, everything would
> > break for us.
>
> Linaro hosting is pretty reliable. But AFAIK, they don't have an apt repo for
> the toolchains. We would need to download a tarball and unpack it.
That would be doable. If the tarballs have versions we could put the
version number in the osstest config and then it would be push gated.
> > Perhaps Julien has time to do that.
>
> Arm64 cross-compiler in Debian should be suitable enough for building the
> kernel. If there are any issue with them, then a bug report should be filled.
OK, that's definitely going to be easier then.
> My preference is to avoid cross-compiling if we can. This would avoid to use
> x86
> resource for building kernel that could be re-used for testing Xen itself.
We have more x86 capacity and are deploying some dedicated build
hosts. But cross-compilation is more complex (particularly the
compiler conflict...)
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Hi,
On 02/11/2018 15:05, Ian Jackson wrote:
Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1
more messages] [and 2 more messages]"):
Thank you for the detailed answer and the willingness to see osstest
changed in this respect.
Sure. It's not fixed in stone, and a variety of approachs will fit
into it I think.
Let me premise that as much as I would like this to be done, I had a
look at my schedule, and, realistically, I can only volunteer very
little time on this. In regards to the two Xilinx boards, it looks like
we'll just have to wait for Debian.
OK. That's perhaps less work overall at our end anyway. Let me know
if you think any aspect of this is getting stuck somehow; I have
contacts in Debian which I could use to enquire or whatever.
On Thu, 1 Nov 2018, Ian Jackson wrote:
The prerequisite is obviously an appropriate cross-compiler. Will the
Debian cross-compilers do ?
Probably it would work, but I don't know for sure. Most people use the
Linaro compiler and toolchain:
https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/
https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/
I guess that's probably tolerable. We'd have to think about whether
we should snapshot them, or install them directly from upstream. The
latter is less coding effort in osstest (just add an apt source and
run the install rune I guess) but it would imply tracking these in an
uncontrolled way, so we would want to be confident that they are
maintained to a high standard, since problems with the compiler would
break everything for us. Also I would ask: how reliable is their apt
repository hosting ? If it goes down, likewise, everything would
break for us.
Linaro hosting is pretty reliable. But AFAIK, they don't have an apt repo for
the toolchains. We would need to download a tarball and unpack it.
Testing the Debian cross-compiler would be very easy.
Perhaps Julien has time to do that.
Arm64 cross-compiler in Debian should be suitable enough for building the
kernel. If there are any issue with them, then a bug report should be filled.
[...]
Wei Liu writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more
messages] [and 2 more messages]"):
Debian's cross-compiler package conflicts with its native compiler,
Specifically it conflicts with the multilib style native compiler used
for Xen. This is a bug in Debian but it is intractable because of the
approach of the Debiabn GCC maintainer, so we will have to live with
it.
However, this is not a blocker because osstest could use a dedicated
x86 setup for the ARM cross builds. That's not ideal because it
shares resources less well, but it's certainly workable.
But maybe we just want to build on ThunderX. That leaves steps 4-6 of
my plan, which almost any approach (other than fixing the kernels in
Debian) require.
My preference is to avoid cross-compiling if we can. This would avoid to use x86
resource for building kernel that could be re-used for testing Xen itself.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v8 6/8] docs: documentation about static shared memory regions
George Dunlap writes ("Re: [PATCH v8 6/8] docs: documentation about static
shared memory regions"):
> > On Oct 31, 2018, at 3:35 PM, Stefano Stabellini
> > wrote:
> > On Wed, 31 Oct 2018, Ian Jackson wrote:
> >> But we need to know what the new terminology should be. Is `owner'
> >> and `borrower' a good pairing ? `Borrow' is perhaps not quite right
> >> because it implies that the original owner no longer has it while it's
> >> borrowed. OTOH Rust has read-only borrows which work similarly so
> >> borrowing in a way that doesn't exclude the original has at least some
> >> precedent...
...
> > Other options I could think of:
> >
> > proprietor / renter
> > benefactor / dependent
IMO these are definitely worse.
> > But I think owner/borrower is the best choice -- also considering that
> > "own" and "borrow" are taught in very basic English classes, anybody
> > should understand them well.
Right.
> master / slave was never the right image, because the non-owning domains
> aren’t being controlled by the owning domain. But neither really is
> “borrower” — borrowing implies that the original owner doesn’t have it for
> some period of time.
See my comments about Rust. I think this is OK,
> Given that you have one owner and a number of other domains that use it at
> the same time, it’s a lot more like a pub or a cafe than an apartment or
> loan. So “server / client” is probably the most accurate picture; if that’s
> considered too confusing, maybe “provider / consumer”, or something like that.
Server/client implies that the owner does something active to handle
the client's wishes, whereas actually the owner just sits there and
the borrowers help themselves (well, libxl helps them).
Provider/consumer is OK but `consumer' can suggest the thing is used
up. I think `borrower' is better than `consumer'. `Owner' definitely
seems right for the owner side.
I think the final decision is up to Stefano.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH] xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message
On 02/11/2018 15:04, Liam Merwick wrote:
> If a call to xenmem_reservation_increase() in gnttab_dma_free_pages()
> fails it triggers a message "Failed to decrease reservation..." which
> should be "Failed to increase reservation..."
>
> Fixes: 9bdc7304f536 ('xen/grant-table: Allow allocating buffers suitable for
> DMA')
> Reported-by: Ross Philipson
> Signed-off-by: Liam Merwick
> Reviewed-by: Mark Kanda
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] devicetree, xen: add xen, shared-memory binding
Hi Ian,
On 02/11/2018 15:30, Ian Jackson wrote:
Julien Grall writes ("Re: [PATCH v3] devicetree,xen: add xen,shared-memory
binding"):
On 11/1/18 8:40 PM, Stefano Stabellini wrote:
From the DT binding point of view, it would be fine. Conceptually it
would also be fine. However, I doubt that the current libxl
implementation would work with multiple mappings.
I can't see why it would not work. I think we designed the refcount for
this purpose.
libxl doesn't see the actual mappings, does it ? It just puts things
into the p2m.
Yes. That's why I think multiple mappings is actually possible.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v3] devicetree, xen: add xen, shared-memory binding
Julien Grall writes ("Re: [PATCH v3] devicetree,xen: add xen,shared-memory
binding"):
> On 11/1/18 8:40 PM, Stefano Stabellini wrote:
> > From the DT binding point of view, it would be fine. Conceptually it
> > would also be fine. However, I doubt that the current libxl
> > implementation would work with multiple mappings.
>
> I can't see why it would not work. I think we designed the refcount for
> this purpose.
libxl doesn't see the actual mappings, does it ? It just puts things
into the p2m.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages] [and 2 more messages]
Stefano Stabellini writes ("Re: [OSSTEST PATCH] README.hardware-acquisition
[and 1 more messages] [and 2 more messages]"):
> Thank you for the detailed answer and the willingness to see osstest
> changed in this respect.
Sure. It's not fixed in stone, and a variety of approachs will fit
into it I think.
> Let me premise that as much as I would like this to be done, I had a
> look at my schedule, and, realistically, I can only volunteer very
> little time on this. In regards to the two Xilinx boards, it looks like
> we'll just have to wait for Debian.
OK. That's perhaps less work overall at our end anyway. Let me know
if you think any aspect of this is getting stuck somehow; I have
contacts in Debian which I could use to enquire or whatever.
> On Thu, 1 Nov 2018, Ian Jackson wrote:
> > The prerequisite is obviously an appropriate cross-compiler. Will the
> > Debian cross-compilers do ?
>
> Probably it would work, but I don't know for sure. Most people use the
> Linaro compiler and toolchain:
>
> https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/
> https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/
I guess that's probably tolerable. We'd have to think about whether
we should snapshot them, or install them directly from upstream. The
latter is less coding effort in osstest (just add an apt source and
run the install rune I guess) but it would imply tracking these in an
uncontrolled way, so we would want to be confident that they are
maintained to a high standard, since problems with the compiler would
break everything for us. Also I would ask: how reliable is their apt
repository hosting ? If it goes down, likewise, everything would
break for us.
> Testing the Debian cross-compiler would be very easy.
Perhaps Julien has time to do that.
> > If the Debian cross compilers are OK, then I think the necessary
> > changes to osstest are:
...
> I thought that we could have provided a deb repository with alternative
> kernels for OSSTests to use. We would have scripts to generate those deb
> packages from the Xen ARM Linux tree in a repository on xenbits, but we
> wouldn't necessarily have OSSTest run the script. Initially, we could
> run the scripts by hand, then, we could run them automatically in
> OSSTest or elsewhere. Is that a possibility? I already have Dockerfiles
> (AKA bash scripts) to build an ARM kernel on a few distros, that's
> something I could make available.
Everything that osstest consumes should either be either:
(i) snapshotted and push gated, so that osstest always uses a version
that it itself has previously tested
(ii) maintained to a very high standard of quality and availability.
For things for which we take approach (ii), regressions of any kind,
or unavailability of the download server, cause what is effectively a
whole-system outage for osstest: every test run ends up plagued by
whatever lossage is going on. Implying no disrespect, but doing (ii)
for a kernel apt repository is very hard.
So I think (i) would be more appropriate. That would mean generating,
periodically, a whole new apt repository, alongside the old one.
Presumably they would have the generation date in the filename, like
our Debian installer images do. Updating would involve a commit to
the osstest config file, which is push-gate-controlled.
Overall I think, though, that this is probably not the best approach.
What you are saying is that you do not have the effort to automate the
building of kernel binaries, and instead you propose to do it
manually. That seems like a false economy.
The task of automating the building of kernel binaries is points 1-3
of my plan to cross build the kernels and use the result for baremetal
builds; that's not the hardest part.
> This morning Julien had one more different suggestion: building the
> kernel with OSSTest on SoftIron, that we know it works, it would be a
> native compilation. Then we could use the built kernel together with the
> Debian installer on the other boards (Xilinx, Renesas, etc.)
Yes, that is also a possibility. But it still involves steps 4-6 from
my plan.
> Either way, the kernel to be used with the embedded boards doesn't need
> to be rebuilt often, only once a month or so.
Of course we shouldn't waste it, but computer time is much cheaper
than human time. osstest already has mechanisms to optimise by
reusing builds where appropriate. The easiest thing is to tell
osstest `we want a kernel built like this' and it will DTRT.
Lars Kurth writes ("Re: [OSSTEST PATCH] README.hardware-acquisition [and 1 more
messages] [and 2 more messages]"):
> Either way, the kernel to be used with the embedded boards doesn't need
> to be rebuilt often, only once a month or so.
>
> That would fit with the https://gitlab.com/xen-project/xen/container_registry
> model
> where we store Dom0 baselines as containers for builds via the Gitlab CI
>
> This may be a stupid idea, but I
Re: [Xen-devel] [PATCH v2 11/16] x86: don't set sysenter_entry in vmcs when !CONFIG_PV
On Fri, Nov 02, 2018 at 08:32:11AM -0600, Jan Beulich wrote: > >>> On 02.11.18 at 15:05, wrote: > > On Fri, Oct 19, 2018 at 03:28:37PM +0100, Wei Liu wrote: > >> The symbol will not be available when PV is disabled. > >> > >> Signed-off-by: Wei Liu > > > > In light of the discussion of the previous patch, a stub for > > sysenter_entry will be provided, so this patch can be dropped. > > As said - SYSENTER is fine without stub, due to its different > faulting conditions compared to SYSCALL. Just zero the > respective MSR(s). OK. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 11/16] x86: don't set sysenter_entry in vmcs when !CONFIG_PV
>>> On 02.11.18 at 15:05, wrote: > On Fri, Oct 19, 2018 at 03:28:37PM +0100, Wei Liu wrote: >> The symbol will not be available when PV is disabled. >> >> Signed-off-by: Wei Liu > > In light of the discussion of the previous patch, a stub for > sysenter_entry will be provided, so this patch can be dropped. As said - SYSENTER is fine without stub, due to its different faulting conditions compared to SYSCALL. Just zero the respective MSR(s). Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [xen-unstable-smoke test] 129322: regressions - FAIL
flight 129322 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129322/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-install fail REGR. vs. 129286
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-checkfail never pass
version targeted for testing:
xen 6cb27e417e57c2f4d689fa19971f20f75e9c0708
baseline version:
xen 87e89bd112e16503f37d219a525a5b5d470e08f9
Last test of basis 129286 2018-11-01 14:00:25 Z1 days
Testing same since 129322 2018-11-02 12:01:12 Z0 days1 attempts
People who touched revisions under test:
Alexandru Isaila
Andrew Cooper
Brian Woods
Jan Beulich
Kevin Tian
Paul Durrant
Razvan Cojocaru
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl fail
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt 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
Not pushing.
commit 6cb27e417e57c2f4d689fa19971f20f75e9c0708
Author: Alexandru Isaila
Date: Fri Nov 2 12:16:32 2018 +0100
x86/hvm: clean up may_defer from hvm_* helpers
The may_defer var was left with the older bool_t type. This patch
changes the type to bool.
Signed-off-by: Alexandru Isaila
Acked-by: Razvan Cojocaru
Reviewed-by: Wei Liu
Acked-by: Brian Woods
Reviewed-by: Kevin Tian
Acked-by: Paul Durrant
commit 45cb9a4123b5550eb1f84846fe5482acae1c13a3
Author: Jan Beulich
Date: Fri Nov 2 12:15:33 2018 +0100
VMX: fix vmx_handle_eoi()
In commit 303066fdb1e ("VMX: fix interaction of APIC-V and Viridian
emulation") I screwed up: Instead of clearing SVI, other ISR bits
should be taken into account.
Introduce a new helper set_svi(), split out of vmx_process_isr(), and
use it also from vmx_handle_eoi().
Following the problems in vmx_intr_assist() (see the still present big
block of debugging code there) also warn (once) if EOI'd vector and
original SVI don't match.
Signed-off-by: Jan Beulich
Reviewed-by: Chao Gao
Acked-by: Kevin Tian
Acked-by: Andrew Cooper
(qemu changes not included)
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] README.hardware-acquisition [and 1 more messages] [and 2 more messages]
On Fri, Nov 02, 2018 at 10:16:48AM +, Lars Kurth wrote: > Hi all, > > adding Wei because of ... > > User facing part: https://gitlab.com/xen-project/xen/pipelines > Back-end: https://gitlab.com/xen-project/xen-gitlab-ci > There are also some scripts in > http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=automation;hb=HEAD related > to this > > On 01/11/2018, 18:12, "Stefano Stabellini" wrote: > > Hi Ian, > > Thank you for the detailed answer and the willingness to see OSSTest > changed in this respect. > > Let me premise that as much as I would like this to be done, I had a > look at my schedule, and, realistically, I can only volunteer very > little time on this. In regards to the two Xilinx boards, it looks like > we'll just have to wait for Debian. > > For the sake of this discussion and brainstorming solutions, I have a > couple of questions and answers on how to support different kernels with > Debian below. > > > On Thu, 1 Nov 2018, Ian Jackson wrote: > > > Yes, we should discuss the technical details on how to use our own > > > quasi-vanilla Linux branch together with the Debian installer. That's > > > all we need AFAICT. > > > > OK. So: > > > > > > I see two possible approaches: > > > > Firstly, chicken-and-egg: Use osstest's `anointed job' mechanism to > > chain one Xen ARM kernel build from the next. (The anointed job > > feature in osstest allows a certain build to be declared generally > > good for use by other jobs. The anointment typically takes place at > > the end of a push gate flight, when the build job that is being > > anointed has been shown to work properly.) > > > > Secondly, cross-compilation on x86. > > > > I think cross-compilation on x86 is probably going to be easier > > because it is conceptually simpler. It also avoids difficulties if > > the anointed build should turn out to be broken on some hosts (this > > ought to be detected by the push gate system, but...). And, frankly, > > our x86 hardware is a lot faster. > > > > So, assuming the plan is to do cross-compilation on x86. > > > > The prerequisite is obviously an appropriate cross-compiler. Will the > > Debian cross-compilers do ? > > Probably it would work, but I don't know for sure. Most people use the > Linaro compiler and toolchain: > > > https://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/ > https://releases.linaro.org/components/toolchain/gcc-linaro/latest-7/ > > Testing the Debian cross-compiler would be very easy. > > I was wondering whether we could use images in > https://gitlab.com/xen-project/xen/container_registry as baseline for > OSSTESTIN in these instances > We may be close to solving the build issues (via a WorksOnArm) via the GitLab > CI I would be wary to depend on WorksOnArm at this stage because there isn't enough information to make an informed decision. > And it should be possible to create some infrastructure to build some custom > images and put them into > https://gitlab.com/xen-project/xen/container_registry and pull them from > there. > > I don’t know whether that solves the full problem and how easy it would be: > e.g. would we still need the cross-compiler for Xen > But we could separate the Dom0 kernel / distro build from OSSTEST Debian's cross-compiler package conflicts with its native compiler, that's why Doug and I couldn't get Arm build in Gitlab CI. > > > If not then maybe this is not the best > > approach because otherwise it's not clear where we'll get a suitable > > compiler. > > > > If the Debian cross compilers are OK, then I think the necessary > > changes to osstest are: > > > > 1. Introduce a distinction between the host (GCC terminology: build) > >and target (GCC terminology: host) architectures, in ts-xen-build. > >This includes adding a call to target_install_packages to install > >the cross compiler, and appropriately amending the configure and > >make runes. Perhaps some of this will want to be in > >Osstest/BuildSupport.pm. The runvars for build jobs will need to > >be reviewed to decide whether a new runvar is needed or whether > >cross-compilation can be inferred from a currently-unsupported > >combination of runvars (particularly, arch vs., hostflags). > > > > 2. Maybe change ts-kernel-build to be able to additionally produce a > >.deb, or cpio full of modules, for use by step 5. (This should be > >optional, controlled by a runvar, since it probably doubles the > >size of the build output...) > > > > 3. Change make*flight and mfi-* to, on ARM, run the existing kernel > >build job on x86 by setting the job runvars
Re: [Xen-devel] [PATCH v3] libxl/arm: fix guest type conversion
Wei Liu writes ("[PATCH v3] libxl/arm: fix guest type conversion"):
> Commit 359970fd8b ("tools/libxl: Switch Arm guest type to PVH") missed
> changing the type field in c_info. This issue didn't surface until
> ef72c93df9 which made creating PV guest on Arm unusable.
>
> Create libxl__arch_domain_create_info_setdefault and switch the type
> there.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH] xen/grant-table: Fix incorrect gnttab_dma_free_pages() pr_debug message
If a call to xenmem_reservation_increase() in gnttab_dma_free_pages()
fails it triggers a message "Failed to decrease reservation..." which
should be "Failed to increase reservation..."
Fixes: 9bdc7304f536 ('xen/grant-table: Allow allocating buffers suitable for
DMA')
Reported-by: Ross Philipson
Signed-off-by: Liam Merwick
Reviewed-by: Mark Kanda
---
drivers/xen/grant-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 84575baceebc..97341fa75458 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -914,7 +914,7 @@ int gnttab_dma_free_pages(struct gnttab_dma_alloc_args
*args)
ret = xenmem_reservation_increase(args->nr_pages, args->frames);
if (ret != args->nr_pages) {
- pr_debug("Failed to decrease reservation for DMA buffer\n");
+ pr_debug("Failed to increase reservation for DMA buffer\n");
ret = -EFAULT;
} else {
ret = 0;
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7] arch/x86: Add registers to vm_event
On 02.11.2018 16:00, Andrew Cooper wrote:
> On 02/11/18 13:00, Jan Beulich wrote:
> On 02.11.18 at 13:54, wrote:
>>> @@ -191,9 +197,26 @@ struct vm_event_regs_x86 {
>>> uint64_t msr_efer;
>>> uint64_t msr_star;
>>> uint64_t msr_lstar;
>>> +uint32_t cs_base;
>>> +uint32_t ss_base;
>>> +uint32_t ds_base;
>>> +uint32_t es_base;
>>> uint64_t fs_base;
>>> uint64_t gs_base;
>>> -uint32_t cs_arbytes;
>>> +struct vm_event_x86_selector_reg cs;
>>> +struct vm_event_x86_selector_reg ss;
>>> +struct vm_event_x86_selector_reg ds;
>>> +struct vm_event_x86_selector_reg es;
>>> +struct vm_event_x86_selector_reg fs;
>>> +struct vm_event_x86_selector_reg gs;
>>> +uint64_t shadow_gs;
>>> +uint64_t dr6;
>>> +uint16_t cs_sel;
>>> +uint16_t ss_sel;
>>> +uint16_t ds_sel;
>>> +uint16_t es_sel;
>>> +uint16_t fs_sel;
>>> +uint16_t gs_sel;
>>> uint32_t _pad;
>>> };
>> Do we really need dr6 be 64 bits wide?
>
> Given that the other %cr and %dr registers are 64bit, I'd argue in
> favour of consistency.
>
I will keep it 64 bit and move it next to dr7.
~Alex
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v2 11/16] x86: don't set sysenter_entry in vmcs when !CONFIG_PV
On Fri, Oct 19, 2018 at 03:28:37PM +0100, Wei Liu wrote: > The symbol will not be available when PV is disabled. > > Signed-off-by: Wei Liu In light of the discussion of the previous patch, a stub for sysenter_entry will be provided, so this patch can be dropped. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] per-domain configuration and inappropriate use of globals
On Mon, Oct 22, 2018 at 02:29:40PM +0100, Andrew Cooper wrote: > On 19/10/18 19:22, Juergen Gross wrote: > > On 19/10/2018 18:57, Andrew Cooper wrote: > >> In practice, having fine grain control of all the features like would be > >> excellent for testing purposes, because it allows you to boot two > >> otherwise-identical VMs with one configuration difference between them. > >> > >> In the spirit of the already in progress domaincreate work, options like > >> these should be selectable at domain creation time, and immutable > >> thereafter. > >> > >> That said, there is a plethora of tweakables, and I'm not sure how best > >> to expose them. While most (all?) of these options are inherently > >> supported (as playing with them simulates what Xen would chose on > >> different hardware), I expect there will be ample opportunity for people > >> to break their systems if they tweak too much. > >> > >> Is there liable to be any provision in xl/libxl to have "unstable" > >> configuration, which is easily identified as "may stop working / cease > >> to exist / become invalid at any point in the future?" > >> > >> Alternatively, are there any other suggestions for alternative mechanisms? > > Per-domain parameters like in my series? You could guard the "dangerous" > > ones by a global parameter (boot-time or run-time settable). > > I was hoping to separate the discussion of what information should be > configurable, from the mechanism we used to provide said information. How do you plan to express this information in SUPPORT.md? > > Using a text-based mechanism suffers from the same stable/unstable > issues as xl.cfg, so the same concern applies there. > But that is a get-out-of-jail-free card for xl / libxl because they wouldn't need to care what is supplied. :p If the way you want this to work is inherently unstable, I think it'd be better to leave xl / libxl out of the picture from the beginning. Wei. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v7] arch/x86: Add registers to vm_event
On 02/11/18 13:00, Jan Beulich wrote:
On 02.11.18 at 13:54, wrote:
>> @@ -191,9 +197,26 @@ struct vm_event_regs_x86 {
>> uint64_t msr_efer;
>> uint64_t msr_star;
>> uint64_t msr_lstar;
>> +uint32_t cs_base;
>> +uint32_t ss_base;
>> +uint32_t ds_base;
>> +uint32_t es_base;
>> uint64_t fs_base;
>> uint64_t gs_base;
>> -uint32_t cs_arbytes;
>> +struct vm_event_x86_selector_reg cs;
>> +struct vm_event_x86_selector_reg ss;
>> +struct vm_event_x86_selector_reg ds;
>> +struct vm_event_x86_selector_reg es;
>> +struct vm_event_x86_selector_reg fs;
>> +struct vm_event_x86_selector_reg gs;
>> +uint64_t shadow_gs;
>> +uint64_t dr6;
>> +uint16_t cs_sel;
>> +uint16_t ss_sel;
>> +uint16_t ds_sel;
>> +uint16_t es_sel;
>> +uint16_t fs_sel;
>> +uint16_t gs_sel;
>> uint32_t _pad;
>> };
> Do we really need dr6 be 64 bits wide?
Given that the other %cr and %dr registers are 64bit, I'd argue in
favour of consistency.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
