[Xen-devel] [PATCH v4 4/5] Qemu-Xen-vTPM: Qemu vTPM xenstubdoms backen.
This Patch provides the glue for the TPM_TIS(Qemu frontend) to Xen
stubdom vTPM domain that provides the actual TPM functionality. It
sends data and TPM commends with xen_vtpm_frontend. It is similar as
another two vTPM backens:
*vTPM passthrough backen Since QEMU 1.5.
*vTPM libtpms-based backen.
Some details:
This part of the patch provides support for the spawning of a thread
that will interact with stubdom vTPM domain by the xen_vtpm_frontend.
It expects a signal from the frontend to wake and pick up the TPM
command that is supposed to be processed and delivers the response
packet using a callback function provided by the frontend.
The backend connects itself to the frontend by filling out an interface
structure with pointers to the function implementing support for various
operations.
(QEMU) vTPM XenStubdoms backen is initialized by Qemu command line options,
-tpmdev xenstubdoms,id=xenvtpm0 -device tpm-tis,tpmdev=xenvtpm0
--Changes in v3:
-Call vtpm_send() and vtpm_recv() directly
--Changes in v4:
-Fix the comment style
Signed-off-by: Quan Xu quan...@intel.com
---
hw/tpm/Makefile.objs | 2 +-
hw/tpm/tpm_xenstubdoms.c | 247 +++
2 files changed, 248 insertions(+), 1 deletion(-)
create mode 100644 hw/tpm/tpm_xenstubdoms.c
diff --git a/hw/tpm/Makefile.objs b/hw/tpm/Makefile.objs
index 57919fa..190e776 100644
--- a/hw/tpm/Makefile.objs
+++ b/hw/tpm/Makefile.objs
@@ -1,3 +1,3 @@
common-obj-$(CONFIG_TPM_TIS) += tpm_tis.o
common-obj-$(CONFIG_TPM_PASSTHROUGH) += tpm_passthrough.o
-common-obj-$(CONFIG_TPM_XENSTUBDOMS) += xen_vtpm_frontend.o
+common-obj-$(CONFIG_TPM_XENSTUBDOMS) += tpm_xenstubdoms.o xen_vtpm_frontend.o
diff --git a/hw/tpm/tpm_xenstubdoms.c b/hw/tpm/tpm_xenstubdoms.c
new file mode 100644
index 000..6d0dc32
--- /dev/null
+++ b/hw/tpm/tpm_xenstubdoms.c
@@ -0,0 +1,247 @@
+/*
+ * Xen Stubdom vTPM driver
+ *
+ * Copyright (c) 2015 Intel Corporation
+ * Authors:
+ *Quan Xu quan...@intel.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see http://www.gnu.org/licenses/
+ */
+
+#include dirent.h
+#include qemu-common.h
+#include qapi/error.h
+#include qemu/sockets.h
+#include qemu/log.h
+#include sysemu/tpm_backend.h
+#include tpm_int.h
+#include hw/hw.h
+#include hw/i386/pc.h
+#include hw/xen/xen_backend.h
+#include sysemu/tpm_backend_int.h
+#include tpm_tis.h
+
+#ifdef DEBUG_TPM
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+#define TYPE_TPM_XENSTUBDOMS tpm-xenstubdoms
+#define TPM_XENSTUBDOMS(obj) \
+OBJECT_CHECK(TPMXenstubdomsState, (obj), TYPE_TPM_XENSTUBDOMS)
+
+static const TPMDriverOps tpm_xenstubdoms_driver;
+
+/* Data structures */
+typedef struct TPMXenstubdomsThreadParams {
+TPMState *tpm_state;
+TPMRecvDataCB *recv_data_callback;
+TPMBackend *tb;
+} TPMXenstubdomsThreadParams;
+
+struct TPMXenstubdomsState {
+TPMBackend parent;
+TPMBackendThread tbt;
+TPMXenstubdomsThreadParams tpm_thread_params;
+bool had_startup_error;
+};
+
+typedef struct TPMXenstubdomsState TPMXenstubdomsState;
+
+/* Functions */
+static void tpm_xenstubdoms_cancel_cmd(TPMBackend *tb);
+
+static int tpm_xenstubdoms_unix_transfer(const TPMLocality *locty_data)
+{
+size_t rlen;
+struct XenDevice *xendev;
+
+xendev = xen_find_xendev(vtpm, xen_domid, xenstore_dev);
+if (xendev == NULL) {
+xen_be_printf(xendev, 0, Con not find vtpm device\n);
+return -1;
+}
+vtpm_send(xendev, locty_data-w_buffer.buffer, locty_data-w_offset);
+vtpm_recv(xendev, locty_data-r_buffer.buffer, rlen);
+return 0;
+}
+
+static void tpm_xenstubdoms_worker_thread(gpointer data,
+ gpointer user_data)
+{
+TPMXenstubdomsThreadParams *thr_parms = user_data;
+TPMBackendCmd cmd = (TPMBackendCmd)data;
+
+switch (cmd) {
+case TPM_BACKEND_CMD_PROCESS_CMD:
+
+/* here need a the cmd process function */
+tpm_xenstubdoms_unix_transfer(thr_parms-tpm_state-locty_data);
+thr_parms-recv_data_callback(thr_parms-tpm_state,
+ thr_parms-tpm_state-locty_number);
+break;
+case TPM_BACKEND_CMD_INIT:
+case TPM_BACKEND_CMD_END:
+case TPM_BACKEND_CMD_TPM_RESET:
+
+/* nothing to
[Xen-devel] [PATCH v3 1/7] vTPM: event channel bind interdomain with para/hvm virtual machine
Signed-off-by: Quan Xu quan...@intel.com
---
extras/mini-os/tpmback.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/extras/mini-os/tpmback.c b/extras/mini-os/tpmback.c
index 00b66e8..8a0a983 100644
--- a/extras/mini-os/tpmback.c
+++ b/extras/mini-os/tpmback.c
@@ -608,18 +608,21 @@ int connect_fe(tpmif_t* tpmif)
}
free(value);
- domid = tpmif-domid;
- if((tpmif-page = gntmap_map_grant_refs(gtpmdev.map, 1, domid, 0,
ringref, PROT_READ | PROT_WRITE)) == NULL) {
- TPMBACK_ERR(Failed to map grant reference %u/%u\n, (unsigned int)
tpmif-domid, tpmif-handle);
- return -1;
- }
+domid = (unsigned int)tpmif-domid;
+if ((tpmif-page = gntmap_map_grant_refs(gtpmdev.map, 1, domid, 0,
ringref,
+ PROT_READ | PROT_WRITE)) == NULL)
{
+TPMBACK_ERR(Failed to map grant reference %u/%u\n,
+tpmif-domid, tpmif-handle);
+return -1;
+}
+
+/* Bind the event channel */
+if ((evtchn_bind_interdomain(domid, evtchn, tpmback_handler, tpmif,
tpmif-evtchn))) {
+TPMBACK_ERR(%u/%u Unable to bind to interdomain event channel!\n,
+(unsigned int) tpmif-domid, tpmif-handle);
+goto error_post_map;
+}
- /*Bind the event channel */
- if((evtchn_bind_interdomain(tpmif-domid, evtchn, tpmback_handler, tpmif,
tpmif-evtchn)))
- {
- TPMBACK_ERR(%u/%u Unable to bind to interdomain event channel!\n,
(unsigned int) tpmif-domid, tpmif-handle);
- goto error_post_map;
- }
unmask_evtchn(tpmif-evtchn);
/* Write the ready flag and change status to connected */
--
1.8.3.2
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 01/12] toolstack: save / restore check
On Mon, 2015-02-09 at 11:09 +, Wei Liu wrote:
+sub saverestore_check ($) {
+my ($self) = @_;
+my $ho = $self-{Host};
+my $help = target_cmd_output_root($ho, $self-{_Command}. help);
+my $rc = ($help =~ m/^\s*save/m) ? 0 : 1;
+logm(rc=$rc);
+return $rc;
You could refactor this and the migration_check into a more generic
check for a named command helper.
And you could prepare the libvirt one for the same once migration gets
added I suppose.
Everything else looks OK to me.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [CALL-FOR-AGENDA] Monthly Xen.org Technical Call (2015-03-11)
On Thu, 2015-03-05 at 09:44 +, Ian Campbell wrote: The next Xen technical call will be at: Wed 11 Mar 17:00:00 GMT 2015 `date -d @1426093200` No agenda = no call tomorrow. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 20/24] xen/passthrough: Extend XEN_DOMCTL_assign_device to support DT device
Hi Jan,
On 11/03/2015 14:03, Jan Beulich wrote:
On 11.03.15 at 14:55, ian.campb...@citrix.com wrote:
On Wed, 2015-03-11 at 13:50 +, Julien Grall wrote:
Hmmm I think I got you point now. Do you mean have something like:
That's one option I'd be happy with, yes. Jan might disagree.
Looks quite reasonable to except for ...
switch (domctl-u.assign_device.dev)
{
#ifdef HAS_PCI
case XEN_DOMCTL_DEV_PCI:
ret = iommu_do_pci_domctl();
break;
#endif
#ifdef HAS_DEVICE_TREE
case XEN_DOMCTL_DEV_DT:
ret = iommu_do_dt_domctl()
break;
#endif
default:
ret = -ENOSYS;
... the -ENOSYS here: We commonly use e.g. -EOPNOTSUPP in
such situations.
Ok I will use it.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/2] xen: arm: sort earlyprintk related lists
Also add a bunch of missing entries to the doc Signed-off-by: Ian Campbell ian.campb...@citrix.com --- docs/misc/arm/early-printk.txt | 16 ++ xen/arch/arm/Rules.mk | 68 +++- 2 files changed, 43 insertions(+), 41 deletions(-) diff --git a/docs/misc/arm/early-printk.txt b/docs/misc/arm/early-printk.txt index 710f07e..44df35e 100644 --- a/docs/misc/arm/early-printk.txt +++ b/docs/misc/arm/early-printk.txt @@ -9,18 +9,22 @@ option should not be enable for Xens that are intended to be portable. CONFIG_EARLY_PRINTK=mach where mach is the name of the machine: - - vexpress: printk with pl011 for versatile express + - brcm: printk with 8250 on Broadcom 7445D0 boards with A15 processors. + - dra7: printk with 8250 on DRA7 platform - exynos5250: printk with the second UART - - midway: printk with the pl011 on Calxeda Midway processors - fastmodel: printk on ARM Fastmodel software emulators + - hip04-d01: printk with 8250 on HiSilicon Hip-04 D01 + - juno: printk with pl011 on Juno platform + - lager: printk with SCIF0 on Renesas R-Car H2 processors + - midway: printk with the pl011 on Calxeda Midway processors - omap5432: printk with UART3 on TI OMAP5432 processors + - seattle: printk with pl011 for AMD Seattle processor - sun6i: printk with 8250 on Allwinner A31 processors - sun7i: printk with 8250 on Allwinner A20 processors - - brcm: printk with 8250 on Broadcom 7445D0 boards with A15 processors. - - hip04-d01: printk with 8250 on HiSilicon Hip-04 D01 - - seattle: printk with pl011 for AMD Seattle processor - - lager: printk with SCIF0 on Renesas R-Car H2 processors - thunderx: printk with pl011 for Cavium ThunderX processor + - vexpress: printk with pl011 for versatile express + - xgene-mcdivitt: printk with 820 on Xgene mcdivitt platform + - xgene-storm: printk with 820 on Xgene storm platform - zynqmp: printk with Cadence UART for Xilinx ZynqMP SoCs The base address and baud rate is hardcoded in xen/arch/arm/Rules.mk, diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index 818a5bc..af3448b 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -42,10 +42,15 @@ EARLY_PRINTK := n ifeq ($(debug),y) -# Early printk for versatile express -ifeq ($(CONFIG_EARLY_PRINTK), vexpress) -EARLY_PRINTK_INC := pl011 -EARLY_UART_BASE_ADDRESS := 0x1c09 +ifeq ($(CONFIG_EARLY_PRINTK), brcm) +EARLY_PRINTK_INC := 8250 +EARLY_UART_BASE_ADDRESS := 0xF040AB00 +EARLY_UART_REG_SHIFT := 2 +endif +ifeq ($(CONFIG_EARLY_PRINTK), dra7) +EARLY_PRINTK_INC := 8250 +EARLY_UART_BASE_ADDRESS := 0x4806A000 +EARLY_UART_REG_SHIFT := 2 endif ifeq ($(CONFIG_EARLY_PRINTK), fastmodel) EARLY_PRINTK_INC := pl011 @@ -57,6 +62,19 @@ ifeq ($(CONFIG_EARLY_PRINTK), exynos5250) EARLY_PRINTK_INC := exynos4210 EARLY_UART_BASE_ADDRESS := 0x12c2 endif +ifeq ($(CONFIG_EARLY_PRINTK), hip04-d01) +EARLY_PRINTK_INC := 8250 +EARLY_UART_BASE_ADDRESS := 0xE4007000 +EARLY_UART_REG_SHIFT := 2 +endif +ifeq ($(CONFIG_EARLY_PRINTK), juno) +EARLY_PRINTK_INC := pl011 +EARLY_UART_BASE_ADDRESS := 0x7ff8 +endif +ifeq ($(CONFIG_EARLY_PRINTK), lager) +EARLY_PRINTK_INC := scif +EARLY_UART_BASE_ADDRESS := 0xe6e6 +endif ifeq ($(CONFIG_EARLY_PRINTK), midway) EARLY_PRINTK_INC := pl011 EARLY_UART_BASE_ADDRESS := 0xfff36000 @@ -66,10 +84,9 @@ EARLY_PRINTK_INC := 8250 EARLY_UART_BASE_ADDRESS := 0x4802 EARLY_UART_REG_SHIFT := 2 endif -ifeq ($(CONFIG_EARLY_PRINTK), dra7) -EARLY_PRINTK_INC := 8250 -EARLY_UART_BASE_ADDRESS := 0x4806A000 -EARLY_UART_REG_SHIFT := 2 +ifeq ($(CONFIG_EARLY_PRINTK), seattle) +EARLY_PRINTK_INC := pl011 +EARLY_UART_BASE_ADDRESS := 0xe101 endif ifeq ($(CONFIG_EARLY_PRINTK), sun6i) EARLY_PRINTK_INC := 8250 @@ -81,43 +98,24 @@ EARLY_PRINTK_INC := 8250 EARLY_UART_BASE_ADDRESS := 0x01c28000 EARLY_UART_REG_SHIFT := 2 endif -ifeq ($(CONFIG_EARLY_PRINTK), brcm) -EARLY_PRINTK_INC := 8250 -EARLY_UART_BASE_ADDRESS := 0xF040AB00 -EARLY_UART_REG_SHIFT := 2 +ifeq ($(CONFIG_EARLY_PRINTK), thunderx) +EARLY_PRINTK_INC := pl011 +EARLY_UART_BASE_ADDRESS := 0x87e02400 endif -ifeq ($(CONFIG_EARLY_PRINTK), xgene-storm) -EARLY_PRINTK_INC := 8250 -EARLY_UART_BASE_ADDRESS := 0x1c02 -EARLY_UART_REG_SHIFT := 2 +ifeq ($(CONFIG_EARLY_PRINTK), vexpress) +EARLY_PRINTK_INC := pl011 +EARLY_UART_BASE_ADDRESS := 0x1c09 endif ifeq ($(CONFIG_EARLY_PRINTK), xgene-mcdivitt) EARLY_PRINTK_INC := 8250 EARLY_UART_BASE_ADDRESS := 0x1c021000 EARLY_UART_REG_SHIFT := 2 endif -ifeq ($(CONFIG_EARLY_PRINTK), juno) -EARLY_PRINTK_INC := pl011 -EARLY_UART_BASE_ADDRESS := 0x7ff8 -endif -ifeq ($(CONFIG_EARLY_PRINTK), hip04-d01) +ifeq ($(CONFIG_EARLY_PRINTK), xgene-storm) EARLY_PRINTK_INC := 8250 -EARLY_UART_BASE_ADDRESS := 0xE4007000 +EARLY_UART_BASE_ADDRESS := 0x1c02 EARLY_UART_REG_SHIFT := 2 endif -ifeq ($(CONFIG_EARLY_PRINTK), seattle) -EARLY_PRINTK_INC := pl011 -EARLY_UART_BASE_ADDRESS := 0xe101 -endif -ifeq
Re: [Xen-devel] [PATCH v4 3/9] sysctl: Make XEN_SYSCTL_topologyinfo sysctl a little more efficient
On Mon, 2015-03-09 at 22:27 -0400, Boris Ostrovsky wrote: Instead of copying data for each field in xen_sysctl_topologyinfo separately put cpu/socket/node into a single structure and do a single copy for each processor. Do not use max_cpu_index, which is almost always used for calculating number CPUs (thus requiring adding or subtracting one), replace it with num_cpus. There is no need to copy whole op in sysctl to user at the end, we only need num_cpus. Rename xen_sysctl_topologyinfo and XEN_SYSCTL_topologyinfo to reflect the fact that these are used for CPU topology. Subsequent patch will add support for PCI topology sysctl. Replace INVALID_TOPOLOGY_ID with XEN_-prefixed macros for each invalid type (core, socket, node). Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com --- Changes in v4: * Split v3's patch into two --- one for CPU topology and one for NUMA info I think this means this is now back to how v2 looked, in which case you may feel free to reinstate my ack. I only glanced through this version but it looks ok. Let me know if it is actually different to v2 and I'll have a closer look. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] CA-162192: Fix rebooting on some EFI-booted systems
On some systems, the ResetSystem EFI runtime service is broken. Follow the
Linux (and Windows) way by preferring ACPI reboot over EFI reboot. This is
done by making BOOT_EFI a reboot mode similar to BOOT_ACPI and BOOT_KBD.
This was seen on an Intel S1200RP_SE with firmware
S1200RP.86B.02.02.0005.102320140911, version 4.6, date 2014-10-23.
Based on the following Linux commits:
de18c850af70 (x86: EFI runtime service support: EFI runtime services)
a4f1987e4c54 (x86, reboot: Add EFI and CF9 reboot methods into the
default list)
44be28e9dd98 (x86/reboot: Add EFI reboot quirk for ACPI Hardware
Reduced flag)
Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com
---
docs/misc/xen-command-line.markdown | 5 -
xen/arch/x86/shutdown.c | 26 +++---
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 63871cb..95ea5f4 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1113,7 +1113,7 @@ The following resources are available:
Technology.
### reboot
- `= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]`
+ `= t[riple] | k[bd] | a[cpi] | e[fi] | p[ci] | n[o] [, [w]arm | [c]old]`
Default: `0`
@@ -1131,6 +1131,9 @@ Specify the host reboot method.
`acpi` instructs Xen to reboot the host using RESET_REG in the ACPI FADT.
+`efi` instructs Xen to reboot the host using the ResetSystem EFI runtime
+service.
+
`pci` instructs Xen to reboot the host using PCI reset register (port CF9).
### ro-hpet
diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 236b4a1..1ffbc88 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -31,6 +31,7 @@ enum reboot_type {
BOOT_TRIPLE = 't',
BOOT_KBD = 'k',
BOOT_ACPI = 'a',
+BOOT_EFI = 'e',
BOOT_CF9 = 'p',
};
@@ -38,13 +39,14 @@ static int reboot_mode;
static bool_t reboot_default = 1;
/*
- * reboot=t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]
+ * reboot=t[riple] | k[bd] | a[cpi] | e[fi] | p[ci] | n[o] [, [w]arm | [c]old]
* warm Don't set the cold reboot flag
* cold Set the cold reboot flag
* no Suppress automatic reboot after panics or crashes
* triple Force a triple fault (init)
* kbdUse the keyboard controller. cold reset (default)
* acpi Use the RESET_REG in the FADT
+ * efiUse the ResetSystem EFI runtime service
* pciUse the so-called PCI reset register, CF9
*/
static enum reboot_type reboot_type = BOOT_ACPI;
@@ -66,6 +68,7 @@ static void __init set_reboot_type(char *str)
reboot_mode = 0x0;
break;
case 'a':
+case 'e':
case 'k':
case 't':
case 'p':
@@ -462,7 +465,14 @@ static int __init reboot_init(void)
if ( !reboot_default )
return 0;
-dmi_check_system(reboot_dmi_table);
+/*
+ * If no quirks apply and the ACPI Hardware Reduced bit is set, prefer EFI
+ * runtime services over ACPI.
+ */
+if ( !dmi_check_system(reboot_dmi_table)
+ (acpi_gbl_FADT.flags ACPI_FADT_HW_REDUCED) )
+reboot_type = BOOT_EFI;
+
return 0;
}
__initcall(reboot_init);
@@ -514,8 +524,6 @@ void machine_restart(unsigned int delay_millisecs)
tboot_shutdown(TB_SHUTDOWN_REBOOT);
}
-efi_reset_system(reboot_mode != 0);
-
/* Rebooting needs to touch the page at absolute address 0. */
*((unsigned short *)__va(0x472)) = reboot_mode;
@@ -535,12 +543,12 @@ void machine_restart(unsigned int delay_millisecs)
/*
* If this platform supports ACPI reset, we follow a Windows-style
* reboot attempt sequence:
- * ACPI - KBD - ACPI - KBD
+ * ACPI - KBD - ACPI - KBD - EFI
* After this we revert to our usual sequence:
- * KBD - TRIPLE - KBD - TRIPLE - KBD - ...
+ * TRIPLE - KBD - TRIPLE - KBD - ...
*/
reboot_type = (((attempt == 1) (orig_reboot_type == BOOT_ACPI))
- ? BOOT_ACPI : BOOT_TRIPLE);
+ ? BOOT_ACPI : BOOT_EFI);
break;
case BOOT_TRIPLE:
asm volatile (lidt %0; int3 : : m (no_idt));
@@ -550,6 +558,10 @@ void machine_restart(unsigned int delay_millisecs)
acpi_reboot();
reboot_type = BOOT_KBD;
break;
+case BOOT_EFI:
+efi_reset_system(reboot_mode != 0);
+reboot_type = BOOT_TRIPLE;
+break;
case BOOT_CF9:
{
u8 cf9 = inb(0xcf9) ~6;
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] x86: Don't apply reboot quirks if reboot set by user
On 11.03.15 at 12:44, ross.lagerw...@citrix.com wrote:
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -35,6 +35,7 @@ enum reboot_type {
};
static int reboot_mode;
+static bool_t reboot_default = 1;
__initdata
@@ -51,6 +52,8 @@ static void __init set_reboot_type(char *str)
{
for ( ; ; )
{
+reboot_default = 0;
'n', 'w', and 'c' shouldn't have this effect.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 36071: tolerable all pass - PUSHED
flight 36071 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/36071/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass
test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass
test-amd64-i386-libvirt 10 migrate-support-checkfail never pass
version targeted for testing:
libvirt b39b1397ea6e6155b5e363d456196504093edd07
baseline version:
libvirt 719cd2182bf06196b26204a8cf88d28001b1d79b
People who touched revisions under test:
Daniel P. Berrange berra...@redhat.com
Daniel Veillard veill...@redhat.com
Erik Skultety eskul...@redhat.com
James Chapman james.p.chap...@intel.com
Jim Fehlig jfeh...@suse.com
John Ferlan jfer...@redhat.com
Ján Tomko jto...@redhat.com
Martin Kletzander mklet...@redhat.com
Michal Privoznik mpriv...@redhat.com
Pavel Hrdina phrd...@redhat.com
Peter Krempa pkre...@redhat.com
Prerna Saxena pre...@linux.vnet.ibm.com
Shanzhi Yu s...@redhat.com
Stefan Berger stef...@linux.vnet.ibm.com
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=b39b1397ea6e6155b5e363d456196504093edd07
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x '!=' x/export/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push libvirt
b39b1397ea6e6155b5e363d456196504093edd07
+ branch=libvirt
+ revision=b39b1397ea6e6155b5e363d456196504093edd07
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ '[' x/export/home/osstest/repos/lock '!=' x/export/home/osstest/repos/lock
']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xensource.com:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xensource.com:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{GitCacheProxy} or die $!;
'
+++ local cache=git://drall.uk.xensource.com:9419/
+++ '[' xgit://drall.uk.xensource.com:9419/ '!=' x ']'
+++ echo
[Xen-devel] [linux-linus test] 36011: trouble: broken/fail/pass
flight 36011 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/36011/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 3 host-install(3) broken REGR. vs. 35883 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 9 guest-start fail REGR. vs. 35883 test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 35883 test-amd64-i386-freebsd10-amd64 7 freebsd-install fail like 35883 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 35883 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: linux2cf3afcd4cbe0e32b8722fc291e9255de1b4d6c6 baseline version: linuxa6c5170d1edea97c538c81e377e56c7b5c5b7e63 People who touched revisions under test: Aaron Lu aaron...@intel.com Abhilash Kesavan a.kesa...@samsung.com Alex Deucher alexander.deuc...@amd.com Alex Deucher alexdeuc...@gmail.com Alexandre Belloni alexandre.bell...@free-electrons.com Andy Lutomirski l...@amacapital.net Andy Shevchenko andriy.shevche...@linux.intel.com Anna Schumaker anna.schuma...@netapp.com Anton Blanchard an...@samba.org Ard Biesheuvel a...@linaro.org Arnd Bergmann a...@arndb.de Bard Liao bardl...@realtek.com Bjorn Helgaas bhelg...@google.com Boris Brezillon boris.brezil...@free-electrons.com Borislav Petkov b...@alien8.de Catalin Marinas catalin.mari...@arm.com Chanwoo Choi cw00.c...@samsung.com Chris Mason c...@fb.com Chris Wilson ch...@chris-wilson.co.uk Christoffer Dall christoffer.d...@linaro.org Chuck Lever chuck.le...@oracle.com Colin Ian King colin.k...@canonical.com Dan Carpenter dan.carpen...@oracle.com Dan Williams dan.j.willi...@intel.com Daniel Vetter daniel.vet...@ffwll.ch Daniel Vetter daniel.vet...@intel.com Dave Airlie airl...@gmail.com Dave Airlie airl...@redhat.com Dave Jiang dave.ji...@intel.com David E. Box david.e@linux.intel.com David Sterba dste...@suse.cz Eduardo Valentin edubez...@gmail.com Erik Rull erik.r...@rdsoftware.de Fabio Estevam fabio.este...@freescale.com Filipe Manana fdman...@suse.com Geert Uytterhoeven geert+rene...@glider.be Guenter Roeck li...@roeck-us.net Hui Wang hui.w...@canonical.com Imre Deak imre.d...@intel.com Ingo Molnar mi...@kernel.org Ivan Khoronzhuk ivan.khoronz...@linaro.org James Hogan james.ho...@imgtec.com Jamie Iles jamie.i...@oracle.com Jammy Zhou jammy.z...@amd.com Jan Kiszka jan.kis...@siemens.com Jani Nikula jani.nik...@intel.com Jeff Layton jeff.lay...@primarydata.com Jiang Liu
Re: [Xen-devel] Failed to launch xen on J6 evm
Hi Ian/Team
It finally looks like xen and dom0 are stable, but the cli seems tricky.
I can switch between xen/dom0 but cannot execute xm cmds...
Any idea where I went wrong? Please find the log below - thanks
Regards
Naveen
U-Boot SPL 2015.04-rc1 (Mar 10 2015 - 13:35:08)
DRA752 ES1.1
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img
U-Boot 2015.04-rc1 (Mar 10 2015 - 13:35:08)
CPU : DRA752 ES1.1
Board: DRA7xx
I2C: ready
DRAM: 1.5 GiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
SCSI: SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
Found 0 device(s).
Net: ethaddr not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
** Unable to read file uEnv.txt **
** File not found /boot/zImage **
switch to partitions #0, OK
mmc1(part 0) is current device
SD/MMC found on device 1
** Unrecognized filesystem type **
** No partition table - mmc 1 **
U-Boot# setenv dtb_addr_r 0x825f
U-Boot#
U-Boot# setenv xen_addr_r 0x9000
U-Boot#
U-Boot# setenv kernel_addr_r 0xa000
U-Boot#
U-Boot# setenv xen_bootargs 'dom0_mem=128M console=dtuart dtuart=serial0
dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1 noreboot early_printk'
U-Boot#
U-Boot# setenv dom0_bootargs 'console=hvc0 root=/dev/mmcblk0p2 rw rootwait
fixrtc'
U-Boot#
U-Boot# fatload mmc 0:1 $dtb_addr_r dra7-evm.dtb
reading dra7-evm.dtb
93457 bytes read in 12 ms (7.4 MiB/s)
U-Boot#
U-Boot# fatload mmc 0:1 $xen_addr_r xen-uImage
reading xen-uImage
754588 bytes read in 65 ms (11.1 MiB/s)
U-Boot#
U-Boot# fatload mmc 0:1 $kernel_addr_r uImage
reading uImage
4911296 bytes read in 398 ms (11.8 MiB/s)
U-Boot#
U-Boot# setenv fdt_high 0x8400
U-Boot#
U-Boot# fdt addr $dtb_addr_r
U-Boot#
U-Boot# fdt resize
U-Boot#
U-Boot# fdt set /chosen '#address-cells' 1
U-Boot#
U-Boot# fdt set /chosen '#size-cells' 1
U-Boot#
U-Boot# fdt set /chosen xen,xen-bootargs \$xen_bootargs\
U-Boot#
U-Boot# fdt resize
U-Boot#
U-Boot# fdt set /chosen xen,dom0-bootargs \$dom0_bootargs\
U-Boot# fdt mknode /chosen module@0
U-Boot#
U-Boot# fdt set /chosen/module@0 compatible xen,linux-zimage
xen,multiboot-module
U-Boot#
U-Boot# fdt set /chosen/module@0 reg $kernel_addr_r 0x4b
U-Boot#
U-Boot# fdt print /chosen
chosen {
xen,dom0-bootargs = console=hvc0 root=/dev/mmcblk0p2 rw rootwait
fixrtc;
xen,xen-bootargs = dom0_mem=128M console=dtuart dtuart=serial0
dom0_max_vcpus=2 bootscrub=0 flask_enforcing=1 noreboot early_printk;
#size-cells = 0x0001;
#address-cells = 0x0001;
module@0 {
reg = 0xa000 0x004b;
compatible = xen,linux-zimage, xen,multiboot-module;
};
};
U-Boot# bootm $xen_addr_r - $dtb_addr_r
## Booting kernel from Legacy Image at 9000 ...
Image Name: Xen.Trial.16
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:754524 Bytes = 736.8 KiB
Load Address: 8020
Entry Point: 8020
Verifying Checksum ... OK
## Flattened Device Tree blob at 825f
Booting using the fdt blob at 0x825f
Loading Kernel Image ... OK
reserving fdt memory region: addr=825f size=17000
Loading Device Tree to 83fe6000, end 83ff ... OK
Starting kernel ...
Xen 4.5.0
(XEN) Xen version 4.5.0 (root@) (arm-linux-gnueabihf-gcc (Ubuntu/Linaro
4.9.1-16ubuntu6) 4.9.1) debug=y Wed Mar 11 12:14:52 PDT 2015
(XEN) Latest ChangeSet:
(XEN) Processor: 412fc0f2: ARM Limited, variant: 0x2, part 0xc0f, rev 0x2
(XEN) 32-bit Execution:
(XEN) Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 10201105 2000 0124 02102211
(XEN) ISA Features: 02101110 13112111 21232041 2131 10011142
(XEN) Platform: TI DRA7
(XEN) Set AuxCoreBoot1 to dfe0004c (0020004c)
(XEN) Set AuxCoreBoot0 to 0x20
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
(XEN) Using generic timer at 6144 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=48211000
(XEN) gic_cpu_addr=48212000
(XEN) gic_hyp_addr=48214000
(XEN) gic_vcpu_addr=48216000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 192 lines, 2 cpus, secure (IID 043b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) I/O virtualisation disabled
(XEN) Allocated console ring of 16 KiB.
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) Bringing up CPU1
(XEN) CPU 1 booted.
(XEN) Brought up 2 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) *** LOADING DOMAIN 0 ***
Re: [Xen-devel] [PATCH] xen: credit2: use curr_on_cpu(cpu) in place of `per_cpu(s, c).curr'
On Fri, Feb 27, 2015 at 4:20 PM, Dario Faggioli dario.faggi...@citrix.com wrote: as 0bba5747f4bee4ddd (xen: sched_credit: define and use curr_on_cpu(cpu)) did for Credit1, hence making the code more consistent and easier to read. Signed-off-by: Dario Faggioli dario.faggi...@citrix.com Reviewed-by: George Dunlap george.dun...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Xen-users] Grant reference batch transmission
Hi Ian, Thanks for your reply. On Tue, Mar 10, 2015 at 16:22:40, Ian Campbell wrote: What is the recommended way for the donor to transmit a batch of grant references? I assume that this requires the donor to pack references into an index page, grant foreign access to the index and transmit the index grant reference. Does Linux provide any way to do this, or are xenbus drivers expected to implement their own batch transmission? A bit of each. You would indeed want to setup a shared page and push the references into it, and Linux (/the Xen interface headers) provide some helpers for this sort of thing, but each driver largely sets things up themselves using a specific ring request format etc. As far as setup of the ring itself goes typically the frontend would allocate one of its pages, grant it to the backend and communicate that to the backend via xenstore. Most drivers use a little start of day synchronisation protocol based around the state keys in the front and backend xenstore dirs, working through the states in enum xenbus_state XenbusState* from xen/include/public/io/xenbus.h. It's assumed that this setup is infrequent (i.e. corresponds to plugging in a new disk etc) In Linux (for most drivers at least, yours may not fit this infrastructure) that state machine can be driven from the .otherend_changed callback in the struct xenbus_driver ops struct. We have implemented front/backend drivers which perform this handshake via xenstore state keys, and which share a single page allocated by the frontend. I think this gives us two options for grant reference batch transmission: 1. Send the grant references via the ring buffer. This doesn't require any additional allocations, but means that if the number of grant references in the batch is greater than O(sizeof(ringbuffer) / sizeof(grant_ref_t)), cycling through the ring will be required. 2. Allocate and share one or more index page(s) which hold the grant references. This means that only a single grant_ref_t needs to be sent via the ring, but at the cost of allocating additional memory for the index. If multiple index pages are required, they could be chained together by appending to index page N a grant reference pointing to page N+1. AFAICS the existing drivers use approach #1; is there any precedent for #2? Gareth -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] CA-162192: Fix rebooting on some EFI-booted systems
On 11.03.15 at 12:44, ross.lagerw...@citrix.com wrote: On some systems, the ResetSystem EFI runtime service is broken. Follow the Linux (and Windows) way by preferring ACPI reboot over EFI reboot. This is done by making BOOT_EFI a reboot mode similar to BOOT_ACPI and BOOT_KBD. No. Just because Linux and/or Windows do things a certain way doesn't mean we should follow suit. Rebooting via EFI runtime services should still be the default when running on EFI. Quirks to overcome certain systems' limitations will of course be acceptable. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] CA-162192: Fix rebooting on some EFI-booted systems
On Wed, Mar 11, 2015 at 02:08:37PM +, Jan Beulich wrote:
On 11.03.15 at 12:44, ross.lagerw...@citrix.com wrote:
On some systems, the ResetSystem EFI runtime service is broken. Follow the
Linux (and Windows) way by preferring ACPI reboot over EFI reboot. This is
done by making BOOT_EFI a reboot mode similar to BOOT_ACPI and BOOT_KBD.
No. Just because Linux and/or Windows do things a certain way
doesn't mean we should follow suit. Rebooting via EFI runtime
services should still be the default when running on EFI. Quirks
to overcome certain systems' limitations will of course be
acceptable.
You might just use this patch (that I had forgotten to post) - and which
needs testing since the last posting.:
From 891f6df52dd9586a43cd76b1052a0caee35ee3e5 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Tue, 3 Feb 2015 11:18:04 -0500
Subject: [PATCH] efi: Allow reboot= overrides when running under EFI
By default we will always use EFI reboot mechanism when
running under EFI platforms. However some EFI platforms
are buggy and need to use the ACPI mechanism to
reboot (such as Lenovo ThinkCentre M57). As such
respect the 'reboot=' override and DMI overrides
for EFI platforms.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
docs/misc/xen-command-line.markdown | 5 -
xen/arch/x86/shutdown.c | 26 --
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 9b458e1..b1f74a1 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1110,7 +1110,7 @@ The following resources are available:
* `rmid_max` indicates the max value for rmid.
### reboot
- `= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]`
+ `= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] | [e]fi [, [w]arm | [c]old]`
Default: `0`
@@ -1130,6 +1130,9 @@ Specify the host reboot method.
`pci` instructs Xen to reboot the host using PCI reset register (port CF9).
+'efi' instructs Xen to reboot using the EFI reboot call (in EFI mode by
+ default it will use that method first).
+
### ro-hpet
`= boolean`
diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 21f6cf5..021998e 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -28,16 +28,18 @@
#include asm/apic.h
enum reboot_type {
+BOOT_INVALID = 'i',
BOOT_TRIPLE = 't',
BOOT_KBD = 'k',
BOOT_ACPI = 'a',
BOOT_CF9 = 'p',
+BOOT_EFI = 'e',
};
static int reboot_mode;
/*
- * reboot=t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]
+ * reboot=t[riple] | k[bd] | a[cpi] | p[ci] | n[o] | [e]fi [, [w]arm | [c]old]
* warm Don't set the cold reboot flag
* cold Set the cold reboot flag
* no Suppress automatic reboot after panics or crashes
@@ -45,8 +47,9 @@ static int reboot_mode;
* kbdUse the keyboard controller. cold reset (default)
* acpi Use the RESET_REG in the FADT
* pciUse the so-called PCI reset register, CF9
+ * efiUse the EFI reboot (if running under EFI)
*/
-static enum reboot_type reboot_type = BOOT_ACPI;
+static enum reboot_type reboot_type = BOOT_INVALID;
static void __init set_reboot_type(char *str)
{
for ( ; ; )
@@ -66,6 +69,7 @@ static void __init set_reboot_type(char *str)
case 'k':
case 't':
case 'p':
+case 'e':
reboot_type = *str;
break;
}
@@ -452,6 +456,9 @@ static struct dmi_system_id __initdata reboot_dmi_table[] =
{
static int __init reboot_init(void)
{
+if ( reboot_type == BOOT_INVALID )
+reboot_type = efi_enabled ? BOOT_EFI : BOOT_ACPI;
+
dmi_check_system(reboot_dmi_table);
return 0;
}
@@ -504,10 +511,9 @@ void machine_restart(unsigned int delay_millisecs)
tboot_shutdown(TB_SHUTDOWN_REBOOT);
}
-efi_reset_system(reboot_mode != 0);
-
/* Rebooting needs to touch the page at absolute address 0. */
-*((unsigned short *)__va(0x472)) = reboot_mode;
+if ( !efi_enabled )
+*((unsigned short *)__va(0x472)) = reboot_mode;
for ( attempt = 0; ; attempt++ )
{
@@ -532,13 +538,21 @@ void machine_restart(unsigned int delay_millisecs)
reboot_type = (((attempt == 1) (orig_reboot_type == BOOT_ACPI))
? BOOT_ACPI : BOOT_TRIPLE);
break;
+case BOOT_EFI:
+efi_reset_system(reboot_mode != 0);
+reboot_type = BOOT_ACPI;
+break;
case BOOT_TRIPLE:
asm volatile (lidt %0; int3 : : m (no_idt));
reboot_type = BOOT_KBD;
break;
+case BOOT_INVALID:
case BOOT_ACPI:
acpi_reboot();
-reboot_type = BOOT_KBD;
+if ( efi_enabled attempt == 0 )
+reboot_type = BOOT_EFI;
+else
Re: [Xen-devel] [PATCH 1/2] x86: Don't apply reboot quirks if reboot set by user
On Wed, Mar 11, 2015 at 11:44:51AM +, Ross Lagerwall wrote:
If reboot= is specified on the command-line, don't apply reboot quirks
to allow the command-line option to take precedence.
This is a port of Linux commit 5955633e91bf (x86/reboot: Skip DMI
checks if reboot set by user).
Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
xen/arch/x86/shutdown.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
index 21f6cf5..236b4a1 100644
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -35,6 +35,7 @@ enum reboot_type {
};
static int reboot_mode;
+static bool_t reboot_default = 1;
/*
* reboot=t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]
@@ -51,6 +52,8 @@ static void __init set_reboot_type(char *str)
{
for ( ; ; )
{
+reboot_default = 0;
+
switch ( *str )
{
case 'n': /* no reboot */
@@ -452,6 +455,13 @@ static struct dmi_system_id __initdata
reboot_dmi_table[] = {
static int __init reboot_init(void)
{
+/*
+ * Only do the DMI check if reboot_type hasn't been overridden
+ * on the command line
+ */
+if ( !reboot_default )
+return 0;
+
dmi_check_system(reboot_dmi_table);
return 0;
}
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.16 test] 36098: regressions - FAIL
flight 36098 linux-3.16 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/36098/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 15 guest-localmigrate/x10fail REGR. vs. 34167 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 34167 Tests which are failing intermittently (not blocking): test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail pass in 35974 test-amd64-i386-libvirt 3 host-install(3) broken in 35974 pass in 36098 test-amd64-amd64-xl 3 host-install(3) broken in 35974 pass in 36098 test-amd64-i386-qemuu-rhel6hvm-intel 3 host-install(3) broken in 35974 pass in 36098 test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 35974 pass in 36098 test-amd64-amd64-xl-qemut-debianhvm-amd64 3 host-install(3) broken in 35974 pass in 36098 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 34167 test-armhf-armhf-libvirt 12 guest-start.2 fail in 35974 blocked in 34167 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-amd64-amd64-xl-sedf-pin 15 guest-localmigrate/x10 fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-multivcpu 15 guest-localmigrate/x10 fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-freebsd10-i386 7 freebsd-install fail never pass test-amd64-i386-freebsd10-amd64 7 freebsd-install fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 35974 never pass test-amd64-amd64-xl-sedf15 guest-localmigrate/x10 fail in 35974 never pass version targeted for testing: linux3ad4b121bd065d8ce88bab8790b64f538842ad24 baseline version: linux19583ca584d6f574384e17fe7613dfaeadcdc4a6 1069 people touched revisions under test, not listing them all jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen
Re: [Xen-devel] [PATCH v3 4/4] libxl: add support for vscsi
On Fri, 2015-03-06 at 14:31 +, Wei Liu wrote:
+void libxl_device_vscsi_append_dev(libxl_ctx *ctx, libxl_device_vscsi *hst,
+ libxl_vscsi_dev *dev)
+{
Can this only be an internal function? I.e. use libxl__ namespace.
And take a libxl__gc *gc not a libxl_ctx, except in very exception
circumstances.
Same comment applies to similar functions.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST 09/12] ts-debian-hvm-install: stub out libvirt + ovmf / rombios
On Mon, 2015-02-09 at 11:10 +, Wei Liu wrote:
Libvirt's configuration converter doesn't know how to deal with BIOS
selection. The end result is it always use the default one (seabios).
Even with qemu-trad? Does it not use rombios in that case?
Stub out ovmf and rombios to avoid false positive results.
This restriction will be removed once libvirt's converter knows how to
deal with BIOS selection.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
ts-debian-hvm-install | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 449b96c..7fe9ca8 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -28,6 +28,13 @@ if (@ARGV $ARGV[0] =~ m/^--stage(\d+)$/) { $stage=$1;
shift @ARGV; }
defined($r{bios}) or die Need to define which bios to use;
+# Libvirt doesn't know anything about bios. It will always use the
+# default one (seabios). Stub out rombios and ovmf to avoid false
+# positive results.
+if ($r{bios} =~ m/ovmf|rombios/ $r{toolstack} eq 'libvirt') {
+die libvirt + $r{bios} is not supported yet.;
+}
+
our ($whhost,$gn) = @ARGV;
$whhost ||= 'host';
$gn ||= 'debianhvm';
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: arm: more flexible scheme for specifying early printk device
Hi Ian, On 11/03/2015 14:11, Ian Campbell wrote: This allows for early-printk to be specified (for existing UARTS at least) without the need to edit Rules.mk. The existing shortcuts are retained, but in a much more compact fashion. An unused EARLY_PRINTK_BAUD was removed from the zynqmq settings. Signed-off-by: Ian Campbell ian.campb...@citrix.com With the change suggested by Andrew: Reviewed-by: Julien Grall julien.gr...@linaro.org Although, I haven't check closely that all the values are still correctly. I guess it was mechanical changes. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] stubdom vtpm build failure in staging
On Thu, 2015-03-12 at 01:46 +, Xu, Quan wrote: I am still testing and fixing it. Sorry for that, I am not a full time open source developer. Regardless, you are expect to fix things which you broke in a timely manner, otherwise in the future I will just have to be more proactive about reverting changes. Certainly fixing things needs to take precedence over submissions of new functionality. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] libxl: add support for vscsi
On Wed, Mar 11, Ian Campbell wrote:
On Fri, 2015-03-06 at 10:45 +0100, Olaf Hering wrote:
+void libxl_device_vscsi_append_dev(libxl_ctx *ctx, libxl_device_vscsi *hst,
+ libxl_vscsi_dev *dev);
+int libxl_device_vscsi_get_host(libxl_ctx *ctx,
+uint32_t domid,
+const char *cfg,
+libxl_device_vscsi **vscsi_host);
What do these two non-standard functions do?
In general the caller would be expected to provide a libxl_device_vscsi,
which will be filled in, rather than having the function allocate one.
+int libxl_device_vscsi_parse(libxl_ctx *ctx, const char *cfg,
+ libxl_device_vscsi *vscsi_host,
+ libxl_vscsi_dev *vscsi_dev);
Like with disk, this is xend/xl specific but might be of use to other
toolstacks, therefore it belongs in libxlu not in libxl proper.
(this might apply to get_host too, depending on what it does)
libvirt for example will do the very same what xl currently does. But so
far I did not get to libvirt yet. The interface is not finished yet.
Last time I looked at libxl vs. libxlu it introduced a circular
dependency. Thats why all the simple string parsing is in libxl itself.
But I will double check if the current layout allows a split. Basically
I tried to simplify things for the caller and have all the functionality
in libxl before libxl_device_vscsi is passed to
libxl_device_vscsi_{add,remove).
I will address the other comments as well in the next round.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 18/21] libxlu: record location when parsing values
On Wed, 2015-03-11 at 15:16 +, Wei Liu wrote: On Wed, Mar 11, 2015 at 03:12:49PM +, Ian Campbell wrote: On Mon, 2015-03-09 at 12:51 +, Wei Liu wrote: Originally only setting has line number recorded. Since we're moving to more sophisticated API, record the location for individual value. It is useful for error reporting. Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com I'm leaving this one to Ian. Do we need to rerun something (bison/flex?) on commit? These commits already contains bison / flex outputs. I used Wheezy's flex and bison. I can exclude them from the patch if necessary. Since you've got the right versions and the diff is small I think we can live with them there. I think my precommit scripts will force a regen, which would highlight if there was any skew. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Failed to launch xen on J6 evm
On Wed, 2015-03-11 at 19:38 +, Korupol, Naveen (EXT) wrote: As Michael says, xm doesn't exist any more (and never existed on ARM), use xl. But, are you even getting a dom0 cli prompt? It doesn't look like it. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input - DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 280kB init memory. (XEN) *** Serial input - Xen (type 'CTRL-a' three times to switch input to DOM0) Is there no dom0 output from this point on? Have you enabled CONFIG_XEN in your dom0 kernel config, along with all the other Xen option, in particular CONFIG_HVC_XEN? You will also want to arrange for a getty process to run on hvc0 so you can login. (XEN) Physical memory information: (XEN) Xen heap: 196108kB free (XEN) heap[20]: 1211404kB free (XEN) Dom heap: 1211404kB free (XEN) Physical memory information: (XEN) Xen heap: 196108kB free (XEN) heap[20]: 1211404kB free (XEN) Dom heap: 1211404kB free (XEN) Physical memory information: (XEN) Xen heap: 196108kB free (XEN) heap[20]: 1211404kB free (XEN) Dom heap: 1211404kB free (XEN) Physical memory information: (XEN) Xen heap: 196108kB free (XEN) heap[20]: 1211404kB free (XEN) Dom heap: 1211404kB free (XEN) Physical memory information: (XEN) Xen heap: 196108kB free (XEN) heap[20]: 1211404kB free (XEN) Dom heap: 1211404kB free (XEN) *** Serial input - DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) *** Serial input - Xen (type 'CTRL-a' three times to switch input to DOM0) (XEN) Physical memory information: (XEN) Xen heap: 196108kB free (XEN) heap[20]: 1211404kB free (XEN) Dom heap: 1211404kB free Please note my new email address naveen.koru...@ext.us.panasonic.com. The old address will be available until September 15, 2015. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] libxl: add support for vscsi
On Wed, Mar 11, Ian Campbell wrote: On Fri, 2015-03-06 at 10:45 +0100, Olaf Hering wrote: +void libxl_device_vscsi_append_dev(libxl_ctx *ctx, libxl_device_vscsi *hst, + libxl_vscsi_dev *dev); +int libxl_device_vscsi_get_host(libxl_ctx *ctx, +uint32_t domid, +const char *cfg, +libxl_device_vscsi **vscsi_host); What do these two non-standard functions do? append_dev handles the single_host:many_devices layout, append yet another libxl_vscsi_dev to libxl_device_vscsi. get_host either finds an existing libxl_device_vscsi or creates a new one, to be passed to libxl_device_vscsi_add. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
On 11.03.15 at 19:26, stefano.stabell...@eu.citrix.com wrote: On Mon, 23 Feb 2015, Jan Beulich wrote: On 20.02.15 at 18:33, ian.campb...@citrix.com wrote: On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote: That's the issue we are trying to resolve, with device tree there is no explicit segment ID, so we have an essentially unindexed set of PCI buses in both Xen and dom0. How that? What if two bus numbers are equal? There ought to be some kind of topology information. Or if all buses are distinct, then you don't need a segment number. It's very possible that I simply don't have the PCI terminology straight in my head, leading to me talking nonsense. I'll explain how I'm using it and perhaps you can put me straight... My understanding was that a PCI segment equates to a PCI host controller, i.e. a specific instance of some PCI host IP on an SoC. No - there can be multiple roots (i.e. host bridges) on a single segment. Segments are - afaict - purely a scalability extension allowing to overcome the 256 bus limit. Actually this turns out to be wrong. On the PCI MCFG spec it is clearly stated: The MCFG table format allows for more than one memory mapped base address entry provided each entry (memory mapped configuration space base address allocation structure) corresponds to a unique PCI Segment Group consisting of 256 PCI buses. Multiple entries corresponding to a single PCI Segment Group is not allowed. For one, what you quote is in no contradiction to what I said. All it specifies is that there shouldn't be multiple MCFG table entries specifying the same segment. Whether on any such segment there is a single host bridge or multiple of them is of no interest here. And then the present x86 Linux code suggests that there might be systems actually violating this (the fact that each entry names not only a segment, but also a bus range also kind of suggests this despite the wording above); see commit 068258bc15 and its neighbors - even if it talks about the address ranges coming from other than ACPI tables, firmware wanting to express them by ACPI tables would have to violate that rule. I think that it is reasonable to expect device tree systems to respect this too. Not really - as soon as we leave ACPI land, we're free to arrange things however they suit us best (of course in agreement with other components involved, like Dom0 in this case), and for that case the cited Linux commit is a proper reference that it can (and has been) done differently by system designers. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
On Wed, 2015-03-11 at 18:26 +, Stefano Stabellini wrote: In other words I think that we still need PHYSDEVOP_pci_host_bridge_add (http://marc.info/?l=xen-develm=142470392016381) or equivalent, but we can drop the bus field from the struct. I think it makes sense for the struct to contain a similar set of entries to the MCFG ones, which would give us flexibility in the future if a) our interpretation of the specs is wrong or b) new specs come along which say something different (or Linux changes what it does internally). IOW I think segment+bus start+bus end is probably the way to go, even if we think bus will be unused today (which equates to it always being 0). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 15/21] libxl: define LIBXL_HAVE_VNUMA
On Mon, 2015-03-09 at 12:51 +, Wei Liu wrote: Signed-off-by: Wei Liu wei.l...@citrix.com Reviewed-by: Dario Faggioli dario.faggi...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com (IMHO it is acceptable to include this in the patch which adds the last bit of functionality which it is expected to cover, but I don't mind it separate either) --- Changes in v6: 1. Better description of the macro. --- tools/libxl/libxl.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index e3d2ae8..97a7c9c 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -67,6 +67,13 @@ * the same $(XEN_VERSION) (e.g. throughout a major release). */ +/* LIBXL_HAVE_VNUMA + * + * If this is defined the type libxl_vnode_info exists, and a + * field 'vnuma_nodes' is present in libxl_domain_build_info. + */ +#define LIBXL_HAVE_VNUMA 1 + /* LIBXL_HAVE_USERDATA_UNLINK * * If it is defined, libxl has a library function called ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 8/9] xl: make error reporting of cpupool subcommands consistent
On Wed, Mar 11, 2015 at 02:52:31PM +, Ian Campbell wrote: On Mon, 2015-03-09 at 11:01 +, Wei Liu wrote: On Fri, Mar 06, 2015 at 06:21:59PM +0100, Dario Faggioli wrote: with the rest of the file, where we return 1 on 0, rather than using libxl error codes. While being consistent is good I'm not very sure if we should go for 0/1 rather than libxl error codes. I vaguely remember at some point we discussed we should make xl exit code better but I don't remember the exact details. Ian and Ian, what do you think? TBH I'm not sure what exit() called with a negative number even results in. I think having more consistent exist codes from xl would be nice, but I don't think the libxl error codes are the ones to use, since they don't really map semantically onto what I would expect a CLI tool to fail with (I'm not sure what I would expect though, something a bit higher level on a command specific basis probably). I agree that libxl error codes are not the ones to use. Since we haven't explicitly defined any return value in xl manpage, I think we should use EXIT_SUCCESS and EXIT_FAILURE per exit(3). They are more appropriate then 0 and 1. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.10 test] 36106: regressions - trouble: broken/fail/pass
flight 36106 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/36106/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 3 host-install(3) broken REGR. vs. 26303 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3)broken REGR. vs. 26303 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail blocked in 26303 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 26303 test-amd64-amd64-xl-winxpsp3 7 windows-install fail like 26303 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 13 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-armhf-armhf-libvirt 5 xen-boot fail never pass test-armhf-armhf-xl-sedf-pin 5 xen-boot fail never pass test-armhf-armhf-xl-sedf 5 xen-boot fail never pass test-armhf-armhf-xl 5 xen-boot fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-armhf-armhf-xl-midway5 xen-boot fail never pass test-armhf-armhf-xl-multivcpu 5 xen-boot fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass version targeted for testing: linux389fb5fb0b8b812ce0e853d5eca748b08fc73289 baseline version: linuxbe67db109090b17b56eb8eb2190cd70700f107aa 961 people touched revisions under test, not listing them all jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl fail test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64fail test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 broken test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64
Re: [Xen-devel] [PATCH v2] RFC: Automatically check xen's public headers for C++ pitfalls.
At 13:16 +0100 on 05 Mar (142555), Tim Deegan wrote:
At 11:55 + on 05 Mar (1425552955), Ian Campbell wrote:
On Thu, 2015-03-05 at 11:41 +, Jan Beulich wrote:
On 05.03.15 at 12:35, ian.campb...@citrix.com wrote:
On Thu, 2015-03-05 at 12:25 +0100, Tim Deegan wrote:
So I've seen four responses in favour of just renaming the field
(Andrew Cooper, Razvan Cojocaru, Don Slutz and David Vrabel) and one
in favour of #ifdeffing it so it's only renamed in C++ (Jan Beulich).
I really don't like adding more #ifdefs to an already hard-to-read
file; I'd rather just rename the field, or else leaving it alone and
letting C++ users carry the fixup in their own code.
CC'ing the other THE REST maintainers for their opinions.
Rather than ifdefs for C++, don't we need them based on
__XEN_INTERFACE_VERSION__?
That's not applicable to the stuff under public/io/.
In which case I'd certainly prefer just changing the name and getting it
over with.
mini-os would need checking, since that's (AFAIK) the only intree user
of these headers.
mini-os doesn't in fact use this field; it's a blktap2-ism.
Here's a (non-RFC) patch to rename it and update blktap2:
Ian, Jan, can I get an Ack or Nack on this so I can clear it off my
plate? :)
Tim.
From a97715b97a02c3182914cee90b363d2939c5d416 Mon Sep 17 00:00:00 2001
From: Tim Deegan t...@xen.org
Date: Thu, 5 Mar 2015 12:11:25 +
Subject: [PATCH] xen: don't use C++ keyword 'private' in public headers.
The 'private' field in io/ring.h (for blktap2, see 1b9cecdb)
is the last thing in the Xen public headers that a C++ compiler
will object to.
Rename it to pvt, update the only in-tree user, and remove the
workaround in the C++ compatibility check.
Signed-off-by: Tim Deegan t...@xen.org
---
tools/blktap2/drivers/tapdisk-vbd.c | 2 +-
xen/include/Makefile| 3 +--
xen/include/public/io/ring.h| 4 ++--
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/tools/blktap2/drivers/tapdisk-vbd.c
b/tools/blktap2/drivers/tapdisk-vbd.c
index c665f27..6d1d94a 100644
--- a/tools/blktap2/drivers/tapdisk-vbd.c
+++ b/tools/blktap2/drivers/tapdisk-vbd.c
@@ -1684,7 +1684,7 @@ tapdisk_vbd_check_ring_message(td_vbd_t *vbd)
if (!vbd-ring.sring)
return -EINVAL;
- switch (vbd-ring.sring-private.tapif_user.msg) {
+ switch (vbd-ring.sring-pvt.tapif_user.msg) {
case 0:
return 0;
diff --git a/xen/include/Makefile b/xen/include/Makefile
index d48a642..c7a1d52 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -104,8 +104,7 @@ headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
headers++.chk: $(PUBLIC_HEADERS) Makefile
if $(CXX) -v /dev/null 21; then \
for i in $(filter %.h,$^); do \
- $(CXX) -x c++ -std=gnu++98 -Wall -Werror \
--D__XEN_TOOLS__ -Dprivate=private_is_a_keyword_in_cpp \
+ $(CXX) -x c++ -std=gnu++98 -Wall -Werror -D__XEN_TOOLS__ \
-include stdint.h -include public/xen.h \
-S -o /dev/null $$i || exit 1; \
echo $$i; \
diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 73e13d7..ba9401b 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -111,7 +111,7 @@ struct __name##_sring {
\
uint8_t msg;\
} tapif_user; \
uint8_t pvt_pad[4]; \
-} private; \
+} pvt; \
uint8_t __pad[44]; \
union __name##_sring_entry ring[1]; /* variable-length */ \
}; \
@@ -156,7 +156,7 @@ typedef struct __name##_back_ring __name##_back_ring_t
#define SHARED_RING_INIT(_s) do { \
(_s)-req_prod = (_s)-rsp_prod = 0; \
(_s)-req_event = (_s)-rsp_event = 1; \
-(void)memset((_s)-private.pvt_pad, 0, sizeof((_s)-private.pvt_pad)); \
+(void)memset((_s)-pvt.pvt_pad, 0, sizeof((_s)-pvt.pvt_pad)); \
(void)memset((_s)-__pad, 0, sizeof((_s)-__pad)); \
} while(0)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] RFC: Automatically check xen's public headers for C++ pitfalls.
On 12.03.15 at 11:03, t...@xen.org wrote: At 13:16 +0100 on 05 Mar (142555), Tim Deegan wrote: At 11:55 + on 05 Mar (1425552955), Ian Campbell wrote: On Thu, 2015-03-05 at 11:41 +, Jan Beulich wrote: On 05.03.15 at 12:35, ian.campb...@citrix.com wrote: On Thu, 2015-03-05 at 12:25 +0100, Tim Deegan wrote: So I've seen four responses in favour of just renaming the field (Andrew Cooper, Razvan Cojocaru, Don Slutz and David Vrabel) and one in favour of #ifdeffing it so it's only renamed in C++ (Jan Beulich). I really don't like adding more #ifdefs to an already hard-to-read file; I'd rather just rename the field, or else leaving it alone and letting C++ users carry the fixup in their own code. CC'ing the other THE REST maintainers for their opinions. Rather than ifdefs for C++, don't we need them based on __XEN_INTERFACE_VERSION__? That's not applicable to the stuff under public/io/. In which case I'd certainly prefer just changing the name and getting it over with. mini-os would need checking, since that's (AFAIK) the only intree user of these headers. mini-os doesn't in fact use this field; it's a blktap2-ism. Here's a (non-RFC) patch to rename it and update blktap2: Ian, Jan, can I get an Ack or Nack on this so I can clear it off my plate? :) In fact I'm not enough against the change to NAK it, but I'm also not really in favor of it, so wouldn't want to ack it. I.e. - Ian? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/6] tools/libxl: Introduce min and max macros
This is the same set used by libxc.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v2: Don't use reserved identifiers in min_t/max_t
---
tools/libxl/libxl_internal.h | 16
1 file changed, 16 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 934465a..fcbec7f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -108,6 +108,22 @@
#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
+#define min(X, Y) ({ \
+const typeof (X) _x = (X); \
+const typeof (Y) _y = (Y); \
+(void) (_x == _y); \
+(_x _y) ? _x : _y; })
+#define max(X, Y) ({ \
+const typeof (X) _x = (X); \
+const typeof (Y) _y = (Y); \
+(void) (_x == _y); \
+(_x _y) ? _x : _y; })
+
+#define min_t(type, x, y) \
+({ const type _x = (x); const type _y = (y); _x _y ? _x: _y; })
+#define max_t(type, x, y) \
+({ const type _x = (x); const type _y = (y); _x _y ? _x: _y; })
+
#define LIBXL__LOGGING_ENABLED
#ifdef LIBXL__LOGGING_ENABLED
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (two months reminder)
On 03/12/2015 10:21 AM, wei.l...@citrix.com wrote: * Credit2: introduce per-vcpu hard and soft affinity (fair) - Justin T. Weaver The most recent patches looked pretty good -- I'd be very surprised if these didn't make it in by July. I'd change this to good. * Default to credit2 (none) cpu pinning, numa affinity and cpu reservation - George Dunlap I think before actually doing a release with credit2 as the default, we want almost an entire development cycle with credit2 as the default, to shake out any latent bugs; and probably an entire release with credit2 listed as production-ready. So maybe this goal would be more helpfully stated as credit2 production ready, so that when we open the next development window we can change the default immediately? * pvUSB support in libxl (fair) - Chunyan Liu You can add in hvmUSB support in libxl here, with my name; and call it fair. * Blktap2 support (none) - George Dunlap I'm planning on doing it, but I haven't spec'd the actual work yet. Is fair the best description for that? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] x86emul: simplify asm() constraints
On 12.03.15 at 11:42, t...@xen.org wrote:
At 16:36 + on 10 Mar (1426001780), Jan Beulich wrote:
@@ -806,9 +802,9 @@ static int read_ulong(
static bool_t mul_dbl(unsigned long m[2])
{
bool_t rc;
-asm ( mul %4; seto %b2
- : =a (m[0]), =d (m[1]), =q (rc)
- : 0 (m[0]), 1 (m[1]), 2 (0) );
+asm ( mul %1; seto %b2
+ : +a (m[0]), +d (m[1]), =q (rc)
+ : 2 (0) );
Would 'bool_t rc = 0' allow you to switch operand 2 to +q and drop the
last input operand as well?
Yes.
Or did that also produce worse code?
I didn't try yet, but I can't see why it would.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 21/21] xl: vNUMA support
On Wed, 2015-03-11 at 20:14 +, Wei Liu wrote:
On Wed, Mar 11, 2015 at 03:12:06PM +, Ian Campbell wrote:
On Mon, 2015-03-09 at 12:51 +, Wei Liu wrote:
+Each BVNODE_CONFIG_OPTION is a quoted key=value pair. Supported
+BVNODE_CONFIG_OPTIONs are:
Which of these are optional and which are mandatory? All mandatory?
Yes, all mandatory for now.
Please can you say so.
+if (!xlu_cfg_get_long (config, maxmem, l, 0))
+max_memkb1 = l * 1024;
I think you should arrange that if the user has specified maxmem then it
has already been parsed and is available in b_info-max_memkb for use in
this function. Reparsing it just leaves scope to get out of sync.
In particular this doesn't handle the defaulting of maxmem to memory.
This is exactly the reason I do this here. At this point
b_info-max_memkb is always set.
If user has specified maxmem we should check if the configuration he /
she specifies matches the vnuma value to avoid misconfiguration;
otherwise we just use vnuma memory as maxmem.
But see below regarding maxvcpus=.
[...]
+if (total_cpus != b_info-max_vcpus) {
+fprintf(stderr, xl: vnuma vcpus and maxvcpus= mismatch\n);
+exit(1);
+}
Can't we do as we do with memory here and set max_vcpus if it isn't
already configured?
This can be done. It will require moving parse_vnuma_config to
beginning of parse_config_data and stubbing out parsing of maxvcpus
and maxmem if vnuma configuration presents.
I'm afraid I don't follow.
I was thinking the flow would be:
Call libxl_foo_init to set everything to the default.
f ( max_mem in cfg )
cfg-maxmem = v
if ( memory in cfg )
cfg-memory = v
if ( vcpus in cfg )
cfg-vcpus = v
do numa parsing, using fact that cfg-{maxmem,memory,vcpus} are
either default value (in which case they are set here) or
explicitly set to some value, in which case they are sanity
checked.
handle maxmem/memory/vcpus/etc still being default values by
setting the appropriate defaults.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Xen 4.6 Development Update (two months reminder)
Hi all
We are now two months into 4.6 development window. This is an email to keep
track of all the patch series I gathered. It is by no means complete and / or
acurate. Feel free to reply this email with new projects or correct my
misunderstanding.
= Timeline =
We are planning on a 9-month release cycle, but we could also release a bit
earlier if everything goes well (no blocker, no critical bug).
* Development start: 6 Jan 2015
=== We are here ===
* Feature Freeze: 10 Jul 2015
* RCs: TBD
* Release Date: 9 Oct 2015 (could release earlier)
The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.
Bug-fixes, if Acked-by by maintainer, can go anytime before the First
RC. Later on we will need to figure out the risk of regression/reward
to eliminate the possiblity of a bug introducing another bug.
= Prognosis =
The states are: none - fair - ok - good - done
none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs
= Bug Fixes =
Bug fixes can be checked in without a freeze exception throughout the
freeze, unless the maintainer thinks they are particularly high
risk. In later RC's, we may even begin rejecting bug fixes if the
broken functionality is small and the risk to other functionality is
high.
Document changes can go in anytime if the maintainer is OK with it.
These are guidelines and principles to give you an idea where we're coming
from; if you think there's a good reason why making an exception for you will
help us make Xen better than not doing so, feel free to make your case.
== Linux ==
* PV domain with memory 512GB (fair)
- Juergen Gross
* Block driver multiqueue support (fair)
RFC posted
- Bob Liu
* Block driver multi-page ring support (fair)
- Bob Liu
* Preemptable privcmd hypercalls (good)
v5 posted
- David Vrabel
* Linux ARM - Device assigment (PCI) (none)
Depends on Xen pieces which are on the Xen 4.6 list.
- Manish Jaggi
* pvUSB in Linux (fronted and backend) (Fair)
- Juergen Gross
* VPMU - 'perf' support in Linux (ok)
Depends on Xen patches
Acked by David Vrabel
- Boris Ostrovsky
* vNUMA in Linux (ok)
v6 posted
git://gitorious.org/vnuma/linux_vnuma.git
- Elena Ufimtseva
* vsyscall in Linux (fair)
- Konrad Rzeszutek Wilk
* COLO Agent in Linux (fair)
- Gui Jianfeng
- Yang Hongyang
- Dong, Eddie
* ARM64 - support 64K guest (none)
- Julien Grall
== OpenStack ==
* setup CI loop for OpenStack (fair)
- Anthony Perard
== FreeBSD ==
* PVH FreeBSD dom0 (ok)
FreeBSD 11 goal. Toolstack side done in Xen 4.5
- Roger Pau Monné
== Other OSes (MiniOS, QNX) ==
* PV drivers for automotive kernels (fair)
- Artem Mygaiev
* mini-os: xenbus changes for rump kernels (ok)
git://xenbits.xen.org/people/iwj/rumpuser-xen.git
branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1
v2 posted
- Ian Jackson
== GRUB2 ==
* GRUB2 multiboot2 (fair)
- Daniel Kiper
== OSSTEST ==
* OSSTest: studom test case (none)
- Wei Liu
* OSSTest: libvirt migration (fair)
- Wei Liu
* OSSTest: upgrade to Debian Jessie (none)
- Wei Liu
* OSSTest: performance test (fair)
- Dario Faggioli
* CPU pool test case (fair)
- Dario Faggioli
* Add a FreeBSD host (fair)
- Roger Pau Monné
* Nested virt test case (fair)
- Robert Hu
== QEMU ==
* Linux-based QEMU upstream stub domain (fair)
RFC posted
- Eric Shelton
* Using qemu-upstream in a stubdomain (none)
Will use rump kernels.
- Wei Liu
* AMD Radeon PCI GPU passthrough (none)
Focusing on Xen 4.2 and qemu-traditional
- Kelly Zytaruk
* Intel IGD PCI GPU passthrough (ok)
v5 posted
- Chen, Tiejun
== Up for grabs ==
* save/restore/migrate PVHVM guest with 32 vcpus
http://lists.xen.org/archives/html/xen-devel/2015-02/msg00244.html
* PoD fixes
if you boot with memory = maxmem we have a size estimation bug
* TLB flushing without locks in Xen
* xl does not support specifying virtual function for passthrough device
http://bugs.xenproject.org/xen/bug/22
* PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with
PCI/GPU passthrough
http://bugs.xenproject.org/xen/bug/28
* libx{c,l} error handling cleanup
* Adding missing 'xend' features in libxl
Need to define what is missing
* xl list -l doesn't contain tty console port
* xl: passing more defaults in configuration in xl.conf
There are a number of options for which it might be useful to pass a default
in xl.conf. For example, if we could have a default backend parameter for
vifs, then it would be easy to switch back and forth between a backend in a
driver domain and a backend in dom0.
* PVH - PVH working with shadow.
Based on Tim's work
* PVH - PCI passthrough for DomU.
* AMD performance regressions
* Performance due to hypercall
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
On Thu, 12 Mar 2015, Jan Beulich wrote: On 11.03.15 at 19:26, stefano.stabell...@eu.citrix.com wrote: On Mon, 23 Feb 2015, Jan Beulich wrote: On 20.02.15 at 18:33, ian.campb...@citrix.com wrote: On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote: That's the issue we are trying to resolve, with device tree there is no explicit segment ID, so we have an essentially unindexed set of PCI buses in both Xen and dom0. How that? What if two bus numbers are equal? There ought to be some kind of topology information. Or if all buses are distinct, then you don't need a segment number. It's very possible that I simply don't have the PCI terminology straight in my head, leading to me talking nonsense. I'll explain how I'm using it and perhaps you can put me straight... My understanding was that a PCI segment equates to a PCI host controller, i.e. a specific instance of some PCI host IP on an SoC. No - there can be multiple roots (i.e. host bridges) on a single segment. Segments are - afaict - purely a scalability extension allowing to overcome the 256 bus limit. Actually this turns out to be wrong. On the PCI MCFG spec it is clearly stated: The MCFG table format allows for more than one memory mapped base address entry provided each entry (memory mapped configuration space base address allocation structure) corresponds to a unique PCI Segment Group consisting of 256 PCI buses. Multiple entries corresponding to a single PCI Segment Group is not allowed. For one, what you quote is in no contradiction to what I said. All it specifies is that there shouldn't be multiple MCFG table entries specifying the same segment. Whether on any such segment there is a single host bridge or multiple of them is of no interest here. I thought that we had already established that one host bridge corresponds to one PCI config memory region, see the last sentence in http://marc.info/?l=xen-develm=142529695117142. Did I misunderstand it? If a host bridge has a 1:1 relationship with CFG space, then each MCFG entry would correspond to one host bridge and one segment. But it looks like that things are more complicated than that. And then the present x86 Linux code suggests that there might be systems actually violating this (the fact that each entry names not only a segment, but also a bus range also kind of suggests this despite the wording above); see commit 068258bc15 and its neighbors - even if it talks about the address ranges coming from other than ACPI tables, firmware wanting to express them by ACPI tables would have to violate that rule. Interesting. I think that it is reasonable to expect device tree systems to respect this too. Not really - as soon as we leave ACPI land, we're free to arrange things however they suit us best (of course in agreement with other components involved, like Dom0 in this case), and for that case the cited Linux commit is a proper reference that it can (and has been) done differently by system designers. OK. It looks like everything should work OK with the hypercall proposed by Ian anyway. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] RFC: Automatically check xen's public headers for C++ pitfalls.
At 10:14 + on 12 Mar (1426151689), Ian Campbell wrote: On Thu, 2015-03-12 at 11:03 +0100, Tim Deegan wrote: At 13:16 +0100 on 05 Mar (142555), Tim Deegan wrote: At 11:55 + on 05 Mar (1425552955), Ian Campbell wrote: On Thu, 2015-03-05 at 11:41 +, Jan Beulich wrote: On 05.03.15 at 12:35, ian.campb...@citrix.com wrote: On Thu, 2015-03-05 at 12:25 +0100, Tim Deegan wrote: So I've seen four responses in favour of just renaming the field (Andrew Cooper, Razvan Cojocaru, Don Slutz and David Vrabel) and one in favour of #ifdeffing it so it's only renamed in C++ (Jan Beulich). I really don't like adding more #ifdefs to an already hard-to-read file; I'd rather just rename the field, or else leaving it alone and letting C++ users carry the fixup in their own code. CC'ing the other THE REST maintainers for their opinions. Rather than ifdefs for C++, don't we need them based on __XEN_INTERFACE_VERSION__? That's not applicable to the stuff under public/io/. In which case I'd certainly prefer just changing the name and getting it over with. mini-os would need checking, since that's (AFAIK) the only intree user of these headers. mini-os doesn't in fact use this field; it's a blktap2-ism. Here's a (non-RFC) patch to rename it and update blktap2: Ian, Jan, can I get an Ack or Nack on this so I can clear it off my plate? :) Acked-by: Ian Campbell ian.campb...@citrix.com And pushed, thanks. Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] PML (Page Modification Logging) design for Xen
On 12/03/15 07:36, Kai Huang wrote: It might also be nice to be able to enable or disable this feature with a sysctl call; but that's just a nice-to-have. This feature should either be used or not. It is impractical to enable/disable at runtime. However, it absolutely wants a knob for tweaking. The likely consequence of a bug in the implementation is VM memory corruption on migrate, and you can get away with missing a large amount of a domains memory before it blows up noticeably. Those paragraphs sound to me like they say the opposite things. And in any case, it's being enabled and disabled for particular domains when they enable or disable logdirty mode, right? It shouldn't be hard at all to just fallback to the non-PML case if it's been disabled. Handling the case of enabling or disabling PML on domains that are already in logdirty mode is, I agree, probably more trouble than it's worth. We can just document it to say that it will only have an effect on domains that start logdirty in the future. Currently I only plan to support PML on boot parameter, but I can certainly add sysctl call to enable/disable PML dynamically if you guys think it's necessary in the future, which should be a separate nice-to-have feature and won't impact existing PML functionality. Does this sound good to all of you? I do not think a runtime switch will be useful. The boot parameter is useful for development, and debugging in that case that something goes wrong, but as soon as the feature is stable I expect noone to ever tweak the parameter again. I certainly wouldn't focus on implementing something like this for v1. If a usecase develops in the future then we can certainly can reconsider. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Adjusting patch to support napi weighting fot vif on kernel 3.4.1 using sysfs
Hello
I am trying to adjust the of Stephen Hemminger patch (
http://marc.info/?l=linux-netdevm=111773621018096w=2 ), suporting
napi weight changes for virtual paravirtualized network interfaces
like xen vif (since they use napi now) on kernel 3.4.1.
The changes are listed below.
napi-sysfs/net/core/net-sysfs.c
+static int change_weight(struct napi_struct *napi, unsigned long new_weight)
+{
+ napi-weight = new_weight;
+ return 0;
+ }
+ static ssize_t weight_store(struct device *dev, struct
device_attribute *attr, const char *buf, size_t len)
+ {
+ return netdev_store(dev, attr, buf, len, change_weight);
+ }
+NETDEVICE_SHOW_RW ( weight, fmt_dec);
static struct attribute *net_class_attrs[] = {
dev_attr_netdev_group.attr,
dev_attr_type.attr,
dev_attr_dev_id.attr,
dev_attr_dev_port.attr,
dev_attr_iflink.attr,
dev_attr_ifindex.attr,
dev_attr_name_assign_type.attr,
dev_attr_addr_assign_type.attr,
+ dev_attr_addr_weight.attr,
dev_attr_link_mode.attr,
dev_attr_address.attr,
dev_attr_broadcast.attr,
dev_attr_speed.attr,
dev_attr_duplex.attr,
dev_attr_dormant.attr,
dev_attr_operstate.attr,
dev_attr_carrier_changes.attr,
dev_attr_ifalias.attr,
dev_attr_carrier.attr,
dev_attr_mtu.attr,
dev_attr_flags.attr,
dev_attr_tx_queue_len.attr,
dev_attr_gro_flush_timeout.attr,
dev_attr_phys_port_id.attr,
dev_attr_phys_switch_id.attr,
NULL,
};
But the weight prameter is on the napi_structure, not on the struct
net_device. I tried to compile it but it shows:
--
net/core/net-sysfs.c: In function ‘format_weight’:
net/core/net-sysfs.c:268: error: ‘const struct net_device’ has no
member named ‘weight’
net/core/net-sysfs.c: In function ‘store_weight’:
net/core/net-sysfs.c:280: warning: passing argument 5 of
‘netdev_store’ from incompatible pointer type
net/core/net-sysfs.c:80: note: expected ‘int (*)(struct net_device *,
long unsigned int)’ but argument is of type ‘int (*)(struct
napi_struct *, long unsigned int)’
make[2]: *** [net/core/net-sysfs.o] Error 1
make[1]: *** [net/core] Error 2
make: *** [net] Error 2
How can i reference struct napi_stuct inide the function
change_weight, and how can i pass the new weight to netdev_store
function ?
The main idea is that a sysadmin can change the weight of vif using
sysfs , for example to use a weight of 32 for low priority vif.
Another reason that i am asking how to make those changes, is to to
make study that how the values of weights affect the network
performace of virtual machines.
Thanks in advance
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] x86/domctl: Improve XEN_DOMCTL_hypercall_init error handling
EACCES cannot be distinguished against an incorrect DOMCTL_INTERFACE_VERSION,
and will cause an incorrect need to rebuild the user-space tool set? message
from libxc.
On the libxc side, put the useful piece of information in the error message,
rathe than the -1 from do_domctl().
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Jan Beulich jbeul...@suse.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
v2: Split error between no such frame and bad type
---
tools/libxc/xc_dom_boot.c |6 +++---
xen/arch/x86/domctl.c |8 +---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index a141eb5..f82db2d 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -57,9 +57,9 @@ static int setup_hypercall_page(struct xc_dom_image *dom)
domctl.u.hypercall_init.gmfn = xc_dom_p2m_guest(dom, pfn);
rc = do_domctl(dom-xch, domctl);
if ( rc != 0 )
-xc_dom_panic(dom-xch,
- XC_INTERNAL_ERROR, %s: HYPERCALL_INIT failed (rc=%d),
- __FUNCTION__, rc);
+xc_dom_panic(dom-xch, XC_INTERNAL_ERROR,
+ %s: HYPERCALL_INIT failed: %d - %s),
+ __FUNCTION__, errno, strerror(errno));
return rc;
}
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 3e5bef1..d4f6ccf 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -386,16 +386,18 @@ long arch_do_domctl(
page = get_page_from_gfn(d, gmfn, NULL, P2M_ALLOC);
-ret = -EACCES;
if ( !page || !get_page_type(page, PGT_writable_page) )
{
if ( page )
+{
+ret = -EPERM;
put_page(page);
+}
+else
+ret = -EINVAL;
break;
}
-ret = 0;
-
hypercall_page = __map_domain_page(page);
hypercall_page_initialise(d, hypercall_page);
unmap_domain_page(hypercall_page);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
On 12.03.15 at 11:33, stefano.stabell...@eu.citrix.com wrote: On Thu, 12 Mar 2015, Jan Beulich wrote: On 11.03.15 at 19:26, stefano.stabell...@eu.citrix.com wrote: On Mon, 23 Feb 2015, Jan Beulich wrote: No - there can be multiple roots (i.e. host bridges) on a single segment. Segments are - afaict - purely a scalability extension allowing to overcome the 256 bus limit. Actually this turns out to be wrong. On the PCI MCFG spec it is clearly stated: The MCFG table format allows for more than one memory mapped base address entry provided each entry (memory mapped configuration space base address allocation structure) corresponds to a unique PCI Segment Group consisting of 256 PCI buses. Multiple entries corresponding to a single PCI Segment Group is not allowed. For one, what you quote is in no contradiction to what I said. All it specifies is that there shouldn't be multiple MCFG table entries specifying the same segment. Whether on any such segment there is a single host bridge or multiple of them is of no interest here. I thought that we had already established that one host bridge corresponds to one PCI config memory region, see the last sentence in http://marc.info/?l=xen-develm=142529695117142. Did I misunderstand it? If a host bridge has a 1:1 relationship with CFG space, then each MCFG entry would correspond to one host bridge and one segment. No, that sentence doesn't imply what you appear to think. Within the same segment (and, for ACPI's sake within the same MCFG region) you could have multiple host bridges. And then what calls itself a host bridge (via class code) may or may not be one - often there are many devices calling themselves such even on a single bus (and my prior sentence specifically means to exclude those). And finally there are systems with their PCI roots expressed only in ACPI, without any specific PCI device serving as the host bridge. There it is most obvious that firmware assigns both segment and bus numbers to its liking. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 0/7] Mem_access for ARM
On Fri, 2015-03-06 at 22:24 +0100, Tamas K Lengyel wrote: The ARM virtualization extension provides 2-stage paging, a similar mechanisms to Intel's EPT, which can be used to trace the memory accesses performed by the guest systems. This series sets up the necessary infrastructure in the ARM code to deliver the event on R/W/X traps. Finally, we turn on the compilation of mem_access and mem_event on ARM and perform the necessary changes to the tools side. This version of the series is based on master and each patch in the series has been compile tested on both ARM and x86. The following benchmarks have been completed on an Arndale board before and after applying this entire series in dom0, which had 2 vCPUs available pinned. No regressions are evident based on these benchmarks. | f0ffd60 | AFTER hackbench | 1.604 | 1.618 hackbench -pT | 1.170 | 1.126 hardinfo CPU Blowfish | 43.252 | 43.323 hardinfo CPU CryptoHash | 40.935 | 40.893 hardinfo CPU Fibonacci | 10.358 | 10.360 hardinfo CPU N-Queens | 25.773 | 25.894 hardinfo FPU FFT| 20.332 | 20.325 hardinfo FPU Raytracing | 73.017 | 73.104 Thanks for these, they are very reassuring. More for curiosities sake than anything else: Do you have any figures for the overhead of enabling memaccess? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (two months reminder)
Il 12/03/2015 11:54, George Dunlap ha scritto: On 03/12/2015 10:21 AM, wei.l...@citrix.com wrote: * Credit2: introduce per-vcpu hard and soft affinity (fair) - Justin T. Weaver The most recent patches looked pretty good -- I'd be very surprised if these didn't make it in by July. I'd change this to good. * Default to credit2 (none) cpu pinning, numa affinity and cpu reservation - George Dunlap I think before actually doing a release with credit2 as the default, we want almost an entire development cycle with credit2 as the default, to shake out any latent bugs; and probably an entire release with credit2 listed as production-ready. So maybe this goal would be more helpfully stated as credit2 production ready, so that when we open the next development window we can change the default immediately? * pvUSB support in libxl (fair) - Chunyan Liu You can add in hvmUSB support in libxl here, with my name; and call it fair. You did a new patchset version? The latest I saw, rebased and tested (including compatibility with actual spice usb redirection) was long time ago and I not saw newer posted in xen-devel. * Blktap2 support (none) - George Dunlap I'm planning on doing it, but I haven't spec'd the actual work yet. Is fair the best description for that? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (two months reminder)
On 03/12/2015 11:34 AM, Fabio Fantoni wrote: Il 12/03/2015 11:54, George Dunlap ha scritto: On 03/12/2015 10:21 AM, wei.l...@citrix.com wrote: * Credit2: introduce per-vcpu hard and soft affinity (fair) - Justin T. Weaver The most recent patches looked pretty good -- I'd be very surprised if these didn't make it in by July. I'd change this to good. * Default to credit2 (none) cpu pinning, numa affinity and cpu reservation - George Dunlap I think before actually doing a release with credit2 as the default, we want almost an entire development cycle with credit2 as the default, to shake out any latent bugs; and probably an entire release with credit2 listed as production-ready. So maybe this goal would be more helpfully stated as credit2 production ready, so that when we open the next development window we can change the default immediately? * pvUSB support in libxl (fair) - Chunyan Liu You can add in hvmUSB support in libxl here, with my name; and call it fair. You did a new patchset version? The latest I saw, rebased and tested (including compatibility with actual spice usb redirection) was long time ago and I not saw newer posted in xen-devel. No, and I'm not going to post one until the pvUSB stuff gets in, since that work will involve refactoring the pvUSB code into PV and DEVICEMODEL paths, and I don't fancy having to repeat that work every time there's another revision. :-) The core technology is working just fine; it's only the library interface that really needed work in the last patch, and that will be set by the pvUSB series. So once that's in, it should be a relatively small amount of work. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
On Thu, Mar 12, 2015 at 1:08 PM, Ian Campbell ian.campb...@citrix.com
wrote:
On Fri, 2015-03-06 at 22:24 +0100, Tamas K Lengyel wrote:
The guestcopy helpers use the MMU to verify that the given guest has
read/write
access to a given page during hypercalls. As we may have custom
mem_access
permissions set on these pages, we do a software-based type checking in
case
the MMU based approach failed, but only if mem_access_enabled is set.
These memory accesses are not forwarded to the mem_event listener.
Accesses
performed by the hypervisor are currently not part of the mem_access
scheme.
This is consistent behaviour with the x86 side as well.
Signed-off-by: Tamas K Lengyel tkleng...@sec.in.tum.de
---
v12: - Check for mfn_valid as well.
---
xen/arch/arm/guestcopy.c | 124
+--
1 file changed, 121 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 7dbaeca..d42a469 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -6,6 +6,115 @@
#include asm/mm.h
#include asm/guest_access.h
+#include asm/p2m.h
+
+/*
+ * If mem_access is in use it might have been the reason why
get_page_from_gva
+ * failed to fetch the page, as it uses the MMU for the permission
checking.
+ * Only in these cases we do a software-based type check and fetch the
page if
+ * we indeed found a conflicting mem_access setting.
+ */
+static int check_type_get_page(vaddr_t gva, unsigned long flag,
+ struct page_info** page)
+{
+long rc;
+paddr_t ipa;
+unsigned long maddr;
+unsigned long mfn;
+xenmem_access_t xma;
+p2m_type_t t;
+
+rc = gva_to_ipa(gva, ipa);
+if ( rc 0 )
+return rc;
+
+/*
+ * We do this first as this is faster in the default case when no
+ * permission is set on the page.
+ */
+rc = p2m_get_mem_access(current-domain, paddr_to_pfn(ipa), xma);
+if ( rc 0 )
+return rc;
+
+/* Let's check if mem_access limited the access. */
+switch ( xma )
+{
+default:
+case XENMEM_access_rwx:
+case XENMEM_access_rw:
If I've understood correctly then this is deliberately backwards
looking.
i.e. if we have gotten here then we have failed an earlier
get_page_from_gva check, so if xma is XENMEM_access_rwx that means that
the result of that first get_page_from_gva is valid because memaccess
hasn't been messing with the permissions.
Since this interface only does reads or writes and not executableness
rwx and rw are effectively the same.
Is my understanding correct?
Yes, correct. If mem_access had no r/w restriction on this page, the result
of get_page_from_gva is valid.
+return -EFAULT;
+case XENMEM_access_n2rwx:
+case XENMEM_access_n:
+case XENMEM_access_x:
+break;
If xenaccess contains no rw perms at all then we need to check what the
original p2m type was in order to decide what to do.
Correct.
+case XENMEM_access_wx:
+case XENMEM_access_w:
+if ( flag == GV2M_READ )
+break;
+else return -EFAULT;
If thing was a read then it might be because of xenaccess, so we must
check, but if it was a write then the origianl get_page_from_gva fault
was correct.
Correct, mem_access here had a write restriction but get_page_from_gva
faulted with read, so that fault was correct.
+case XENMEM_access_rx2rw:
+case XENMEM_access_rx:
+case XENMEM_access_r:
+if ( flag == GV2M_WRITE )
+break;
+else return -EFAULT;
and vice versa.
(sorry to be so tedious, I wanted to work through them all to ensure I'd
understood correctly and that they were right).
Yes, this is a bit complex but your understanding is correct. I will add a
comment describing it in human readable way as Julien also had the same
question couple months ago.
@@ -68,7 +180,10 @@ unsigned long raw_clear_guest(void *to, unsigned len)
page = get_page_from_gva(current-domain, (vaddr_t) to,
GV2M_WRITE);
if ( page == NULL )
-return len;
+{
+if ( check_mem_access((vaddr_t) to, GV2M_WRITE, page) 0 )
+return len;
+}
I think this would be better done by a making check_mem_access include
the initial call to get_page_from_gva and calling that helper here
instead instead of repeating this code.
I'd even consider putting the memaccess check as a call at the tail end
of get_page_from_gva, I don't think there are any callers who don't want
this behaviour.
Sure, that sounds reasonable.
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 01/13] xen/mem_event: Cleanup of mem_event structures
On Thu, Mar 12, 2015 at 1:13 PM, Tim Deegan t...@xen.org wrote:
At 01:11 +0100 on 18 Feb (1424218291), Tamas K Lengyel wrote:
+struct mem_event_mem_access {
uint64_t gfn;
uint64_t offset;
-uint64_t gla; /* if gla_valid */
+uint64_t gla; /* if flags has MEM_ACCESS_GLA_VALID set */
+uint32_t flags; /* MEM_ACCESS_* */
+uint32_t _pad;
+};
+
+struct mem_event_mov_to_cr {
+uint64_t new_value;
+uint64_t old_value;
+};
+
+struct mem_event_debug {
+uint64_t gfn;
+};
+struct mem_event_mov_to_msr {
+uint64_t msr;
+uint64_t value;
+};
+
+#define MEM_PAGING_DROP_PAGE (1 0)
+#define MEM_PAGING_EVICT_FAIL (1 1)
+
+struct mem_event_paging {
+uint64_t gfn;
uint32_t p2mt;
+uint32_t flags;
+};
+
+struct mem_event_sharing {
+uint64_t gfn;
+uint32_t p2mt;
+};
I see you have padded struct mem_event_mem_access to an 8-byte
boundary but not this -- given the union I suppose it makes no
difference but it woud be consistent to add padding here too.
Ack, will do!
In any case,
Acked-by: Tim Deegan t...@xen.org
Tim.
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 08/13] xen: Introduce monitor_op domctl
At 01:11 +0100 on 18 Feb (1424218298), Tamas K Lengyel wrote: In preparation for allowing for introspecting ARM and PV domains the old control interface via the hvm_op hypercall is retired. A new control mechanism is introduced via the domctl hypercall: monitor_op. This patch aims to establish a base API on which future applications can build on. Suggested-by: Andrew Cooper andrew.coop...@citrix.com Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com Acked-by: Tim Deegan t...@xen.org ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] x86emul: simplify asm() constraints
Use + on outputs instead of = and a matching input. Allow not just
memory for the _eflags operand (it turns out that recent gcc produces
worse code when also doing this for _dst.val, so the latter is being
avoided).
Signed-off-by: Jan Beulich jbeul...@suse.com
---
v2: Extend simplification in {,i}mul_dbl(), as suggested by Tim.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -428,7 +428,7 @@ typedef union {
/* Before executing instruction: restore necessary bits in EFLAGS. */
#define _PRE_EFLAGS(_sav, _msk, _tmp) \
/* EFLAGS = (_sav _msk) | (EFLAGS ~_msk); _sav = ~_msk; */ \
-movl %_sav,%_LO32 _tmp; \
+movl %_LO32 _sav,%_LO32 _tmp; \
push %_tmp; \
push %_tmp; \
movl %_msk,%_LO32 _tmp; \
@@ -448,7 +448,7 @@ typedef union {
pushf;\
pop %_tmp; \
andl %_msk,%_LO32 _tmp; \
-orl %_LO32 _tmp,%_sav;
+orl %_LO32 _tmp,%_LO32 _sav;
/* Raw emulation: instruction has two explicit operands. */
#define __emulate_2op_nobyte(_op,_src,_dst,_eflags,_wx,_wy,_lx,_ly,_qx,_qy)\
@@ -460,18 +460,16 @@ do{ unsigned long _tmp;
_PRE_EFLAGS(0,4,2) \
_opw %_wx3,%1; \
_POST_EFLAGS(0,4,2) \
-: =m (_eflags), =m ((_dst).val), =r (_tmp) \
-: _wy ((_src).val), i (EFLAGS_MASK), \
- m (_eflags), m ((_dst).val) ); \
+: +g (_eflags), +m ((_dst).val), =r (_tmp) \
+: _wy ((_src).val), i (EFLAGS_MASK) ); \
break; \
case 4:\
asm volatile ( \
_PRE_EFLAGS(0,4,2) \
_opl %_lx3,%1; \
_POST_EFLAGS(0,4,2) \
-: =m (_eflags), =m ((_dst).val), =r (_tmp) \
-: _ly ((_src).val), i (EFLAGS_MASK), \
- m (_eflags), m ((_dst).val) ); \
+: +g (_eflags), +m ((_dst).val), =r (_tmp) \
+: _ly ((_src).val), i (EFLAGS_MASK) ); \
break; \
case 8:\
__emulate_2op_8byte(_op, _src, _dst, _eflags, _qx, _qy); \
@@ -487,9 +485,8 @@ do{ unsigned long _tmp;
_PRE_EFLAGS(0,4,2) \
_opb %_bx3,%1; \
_POST_EFLAGS(0,4,2) \
-: =m (_eflags), =m ((_dst).val), =r (_tmp) \
-: _by ((_src).val), i (EFLAGS_MASK), \
- m (_eflags), m ((_dst).val) ); \
+: +g (_eflags), +m ((_dst).val), =r (_tmp) \
+: _by ((_src).val), i (EFLAGS_MASK) ); \
break; \
default: \
__emulate_2op_nobyte(_op,_src,_dst,_eflags,_wx,_wy,_lx,_ly,_qx,_qy);\
@@ -519,24 +516,24 @@ do{ unsigned long _tmp;
_PRE_EFLAGS(0,3,2) \
_opb %1; \
_POST_EFLAGS(0,3,2) \
-: =m (_eflags), =m ((_dst).val), =r (_tmp) \
-: i (EFLAGS_MASK), m (_eflags), m ((_dst).val) );\
+: +g (_eflags), +m ((_dst).val), =r (_tmp) \
+: i (EFLAGS_MASK) ); \
break; \
case 2:\
asm volatile ( \
_PRE_EFLAGS(0,3,2) \
_opw %1; \
_POST_EFLAGS(0,3,2) \
-: =m (_eflags), =m
Re: [Xen-devel] [PATCH v7 21/21] xl: vNUMA support
On Wed, 2015-03-11 at 20:14 +, Wei Liu wrote: On Wed, Mar 11, 2015 at 03:12:06PM +, Ian Campbell wrote: On Mon, 2015-03-09 at 12:51 +, Wei Liu wrote: +Each BVNODE_CONFIG_OPTION is a quoted key=value pair. Supported +BVNODE_CONFIG_OPTIONs are: Which of these are optional and which are mandatory? All mandatory? Yes, all mandatory for now. Indeed. I'll make some of them optional when integrating automatic placement with vNUMA. BTW, Wei, I've looked at this version, and you can have my: Reviewed-by: Dario Faggioli dario.faggi...@citrix.com Although, AFAIU, you're probably changing it further and reposting... Regards, Dario signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86emul: simplify asm() constraints
At 13:13 + on 12 Mar (1426162439), Jan Beulich wrote: Use + on outputs instead of = and a matching input. Allow not just memory for the _eflags operand (it turns out that recent gcc produces worse code when also doing this for _dst.val, so the latter is being avoided). Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Tim Deegan t...@xen.org ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 0/7] Mem_access for ARM
On Thu, 2015-03-12 at 13:24 +0100, Tamas K Lengyel wrote: On Thu, Mar 12, 2015 at 12:30 PM, Ian Campbell More for curiosities sake than anything else: Do you have any figures for the overhead of enabling memaccess? I can gather some figures if needed but it is very use-case specific depending on which pages are being trapped and how. That makes sense, was just curious so no need to go do extra work. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
On Thu, Mar 12, 2015 at 2:50 PM, Julien Grall julien.gr...@linaro.org
wrote:
Hi Tamas,
On 06/03/15 21:24, Tamas K Lengyel wrote:
+/*
+ * If mem_access is in use it might have been the reason why
get_page_from_gva
+ * failed to fetch the page, as it uses the MMU for the permission
checking.
+ * Only in these cases we do a software-based type check and fetch the
page if
+ * we indeed found a conflicting mem_access setting.
+ */
+static int check_type_get_page(vaddr_t gva, unsigned long flag,
+ struct page_info** page)
+{
+long rc;
+paddr_t ipa;
+unsigned long maddr;
+unsigned long mfn;
+xenmem_access_t xma;
+p2m_type_t t;
+
+rc = gva_to_ipa(gva, ipa);
I though a bit more about this call.
gva_to_ipa only checks if the mapping has read-permission. That would
allow a guest to write on read-only mapping.
You have to pass the flags to gva_to_ipa in order to avoid
re-introducing XSA-98 [1]
Here I really just care if the mapping exist to see if we have a mem_access
restriction, r/w permission checking is then performed afterwards by
checking the page type. If there are additional restrictions on the page
beside the type, those certainly should be added. Can you point me to where
that additional restriction is stored so I can query for it?
Regards,
[1] http://xenbits.xen.org/xsa/advisory-98.html
--
Julien Grall
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: Prune unused ASSERT/BUG/WARN infrastructure
At 14:29 + on 12 Mar (1426166977), Andrew Cooper wrote: Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Keir Fraser k...@xen.org CC: Jan Beulich jbeul...@suse.com CC: Ian Campbell ian.campb...@citrix.com CC: Stefano Stabellini stefano.stabell...@citrix.com CC: Tim Deegan t...@xen.org Acked-by: Tim Deegan t...@xen.org ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 2/3] sched_credit2.c : runqueue_per_core code
This patch do the following things:
-Insertion of runqueue_per_core code
-Boot paarmeter creation to select runqueue
Signed-off-by : Uma Sharma uma.sharma...@gmail.com
---
xen/common/sched_credit2.c | 39 ---
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index ad0a5d4..c45df87 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -85,8 +85,8 @@
* to a small value, and a fixed credit is added to everyone.
*
* The plan is for all cores that share an L2 will share the same
- * runqueue. At the moment, there is one global runqueue for all
- * cores.
+ * runqueue. At the moment, the code allows the user to choose runqueue
+ * to be used. Default used core runqueue.
*/
/*
@@ -161,10 +161,16 @@
*/
#define __CSFLAG_runq_migrate_request 3
#define CSFLAG_runq_migrate_request (1__CSFLAG_runq_migrate_request)
-
+/* CREDIT2_OPT_RUNQUEUE: Used to define the runqueue used
+ */
+#define CREDIT2_OPT_RUNQUEUE_CORE 1
+#define CREDIT2_OPT_RUNQUEUE_SOCKET 2
int opt_migrate_resist=500;
integer_param(sched_credit2_migrate_resist, opt_migrate_resist);
+static char __initdata opt_credit2_runqueue_string[10] = core;
+string_param(credit2_runqueue, opt_credit2_runqueue_string);
+int opt_credit2_runqueue=CREDIT2_OPT_RUNQUEUE_CORE;
/*
* Useful macros
@@ -1940,10 +1946,14 @@ static void init_pcpu(const struct scheduler *ops, int
cpu)
/* Figure out which runqueue to put it in */
/* NB: cpu 0 doesn't get a STARTING callback, so we hard-code it to
runqueue 0. */
-if ( cpu == 0 )
-rqi = 0;
+if ( opt_credit2_runqueue == CREDIT2_OPT_RUNQUEUE_SOCKET )
+{
+rqi = (cpu) ? cpu_to_socket(cpu) : boot_cpu_to_socket();
+}
else
-rqi = cpu_to_socket(cpu);
+{
+rqi = (cpu) ? cpu_to_core(cpu) : boot_cpu_to_core();
+}
if ( rqi 0 )
{
@@ -1988,7 +1998,7 @@ csched2_alloc_pdata(const struct scheduler *ops, int cpu)
{
/* Check to see if the cpu is online yet */
/* Note: cpu 0 doesn't get a STARTING callback */
-if ( cpu == 0 || cpu_to_socket(cpu) = 0 )
+if ( cpu == 0 || cpu_to_socket(cpu) = 0 || cpu_to_core(cpu) = 0 )
init_pcpu(ops, cpu);
else
printk(%s: cpu %d not online yet, deferring initializatgion\n,
@@ -2109,6 +2119,21 @@ csched2_init(struct scheduler *ops)
opt_load_window_shift = LOADAVG_WINDOW_SHIFT_MIN;
}
+/* Defines the runqueue used. */
+if ( !strcmp(opt_credit2_runqueue_string, socket) )
+{
+opt_credit2_runqueue=CREDIT2_OPT_RUNQUEUE_SOCKET;
+printk(Runqueue : runqueue_per_socket\n);
+}
+else if ( !strcmp(opt_credit2_runqueue_string, core) )
+{
+opt_credit2_runqueue=CREDIT2_OPT_RUNQUEUE_CORE;
+printk(Runqueue : runqueue_per_core\n);
+}
+else {
+printk(Runqueue: credit2_runqueue entered incorrect Continuing with
core\n);
+}
+
/* Basically no CPU information is available at this point; just
* set up basic structures, and a callback when the CPU info is
* available. */
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 3/3] docs : documentation for the code
This patch inserts boot paramter documentation in xen-command-line.markdown. Signed-off-by: Uma Sharma uma.sharma...@gmail.com --- docs/misc/xen-command-line.markdown | 7 +++ 1 file changed, 7 insertions(+) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 63871cb..fec18a1 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -460,6 +460,13 @@ combination with the `low_crashinfo` command line option. ### credit2\_load\_window\_shift `= integer` +### credit2\_runqueue + `= core | socket` + + Default: `credit2_runqueue=core` + +Choose the credit2 runqueue. + ### dbgp `= ehci[ integer | @pcibus:slot.func ]` -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 4/7] xen/arm: Data abort exception (R/W) mem_events.
On Fri, 2015-03-06 at 22:24 +0100, Tamas K Lengyel wrote:
This patch enables to store, set, check and deliver LPAE R/W mem_events.
As the LPAE PTE's lack enough available software programmable bits,
we store the permissions in a Radix tree. The tree is only looked at if
mem_access_enabled is turned on.
But it is maintained/updated regardless, is that deliberate?
+static int p2m_mem_access_radix_set(struct p2m_domain *p2m, unsigned long
pfn,
+ p2m_access_t a)
+{
+int rc;
+
+if ( p2m_access_rwx == a )
+{
+if ( p2m-mem_access_enabled )
In particular this is gated, but the rest of the function appears not to
be, which seems inconsistent...
+radix_tree_delete(p2m-mem_access_settings, pfn);
+
+return 0;
+}
+
+rc = radix_tree_insert(p2m-mem_access_settings, pfn,
+ radix_tree_int_to_ptr(a));
+if ( rc == -EEXIST )
+{
+/* If a setting existed already, change it to the new one */
+radix_tree_replace_slot(
+radix_tree_lookup_slot(
+p2m-mem_access_settings, pfn),
+radix_tree_int_to_ptr(a));
+rc = 0;
+}
+
+return rc;
+}
+
enum p2m_operation {
INSERT,
ALLOCATE,
REMOVE,
RELINQUISH,
CACHEFLUSH,
+MEMACCESS,
};
/* Put any references on the single 4K page referenced by pte. TODO:
@@ -560,13 +592,22 @@ static int apply_one_level(struct domain *d,
if ( p2m_valid(orig_pte) )
return P2M_ONE_DESCEND;
-if ( is_mapping_aligned(*addr, end_gpaddr, 0, level_size) )
+if ( is_mapping_aligned(*addr, end_gpaddr, 0, level_size)
+ /* We only create superpages when mem_access is not in use. */
+ (level == 3 || (level 3 !p2m-mem_access_enabled)) )
I don't think we can get away with adding this check to
is_mapping_aligned (it's used elsewhere), but perhaps you could wrap
this condition in a helper to use in both places.
mapping_allowed_at_level(p2m, level) or some such.
- /* We do not handle replacing an existing table with a superpage
*/
- (level == 3 || !p2m_table(orig_pte)) )
+ /* We do not handle replacing an existing table with a superpage
+* or when mem_access is in use. */
+ (level == 3 || (!p2m_table(orig_pte)
!p2m-mem_access_enabled)) )
Actually, this is very subtly different isn't it. Can it be unified? If
not then ignore the helper idea.
@@ -760,6 +807,47 @@ static int apply_one_level(struct domain *d,
*addr += PAGE_SIZE;
return P2M_ONE_PROGRESS_NOP;
}
+
+case MEMACCESS:
+if ( level 3 )
+{
+if ( !p2m_valid(orig_pte) )
+{
+*addr += level_size;
+return P2M_ONE_PROGRESS_NOP;
+}
+
+/* Shatter large pages as we descend */
+if ( p2m_mapping(orig_pte) )
+{
+rc = p2m_shatter_page(d, entry, level, flush_cache);
+if ( rc 0 )
+return rc;
+} /* else: an existing table mapping - descend */
+
+return P2M_ONE_DESCEND;
+}
+else
+{
+pte = orig_pte;
+
+if ( !p2m_table(pte) )
+pte.bits = 0;
What is this about? Just clobbering an invalid PTE?
@@ -783,6 +871,8 @@ static int apply_p2m_changes(struct domain *d,
unsigned int cur_root_table = ~0;
unsigned int cur_offset[4] = { ~0, ~0, ~0, ~0 };
unsigned int count = 0;
+const unsigned long sgfn = paddr_to_pfn(start_gpaddr),
+egfn = paddr_to_pfn(end_gpaddr);
bool_t flush = false;
bool_t flush_pt;
@@ -912,6 +1006,12 @@ static int apply_p2m_changes(struct domain *d,
rc = 0;
out:
+if ( flush )
+{
+flush_tlb_domain(d);
+iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+}
Is moving the flush out of the loop an independent bug fix? If so please
do in a separate commit with a rationale in the commit log. If it is
somehow related to the changes here then please mention it in this
commit log, since it's a bit subtle.
+
if ( rc 0 ( op == INSERT || op == ALLOCATE )
addr != start_gpaddr )
{
@@ -1281,6 +1381,254 @@ void __init setup_virt_paging(void)
smp_call_function(setup_virt_paging_one, (void *)val, 1);
}
+bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct npfec
npfec)
This is different to the current x86 prototype, is that due to your
other cleanup series?
+{
+int rc;
+bool_t violation;
+xenmem_access_t xma;
+mem_event_request_t *req;
+struct vcpu *v = current;
+struct p2m_domain *p2m = p2m_get_hostp2m(v-domain);
+
+/* Mem_access is not in use. */
+if ( !p2m-mem_access_enabled )
+
Re: [Xen-devel] [PATCH v7 21/21] xl: vNUMA support
On Thu, Mar 12, 2015 at 02:22:10PM +0100, Dario Faggioli wrote: On Wed, 2015-03-11 at 20:14 +, Wei Liu wrote: On Wed, Mar 11, 2015 at 03:12:06PM +, Ian Campbell wrote: On Mon, 2015-03-09 at 12:51 +, Wei Liu wrote: +Each BVNODE_CONFIG_OPTION is a quoted key=value pair. Supported +BVNODE_CONFIG_OPTIONs are: Which of these are optional and which are mandatory? All mandatory? Yes, all mandatory for now. Indeed. I'll make some of them optional when integrating automatic placement with vNUMA. BTW, Wei, I've looked at this version, and you can have my: Reviewed-by: Dario Faggioli dario.faggi...@citrix.com Thanks for reviewing. Although, AFAIU, you're probably changing it further and reposting... Yes, I've changed it and will repost... Wei. Regards, Dario ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86emul: simplify asm() constraints
On 12/03/15 13:13, Jan Beulich wrote: Use + on outputs instead of = and a matching input. Allow not just memory for the _eflags operand (it turns out that recent gcc produces worse code when also doing this for _dst.val, so the latter is being avoided). Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: avoid updating node affinity twice when removing a CPU from a cpupool
On Wed, 2015-03-11 at 16:04 +, Dario Faggioli wrote: On Wed, 2015-03-11 at 15:01 +, George Dunlap wrote: It looks like domain_update_node_affinity() is already called for each domain in the cpupool in cpu_disable_scheduler(). It doesn't look like there should be a need to call it twice. Can we just remove the call to domain_update_node_affinity() in cpupool_unassign_cpu() and not add it back? Mmm.. true, actually. I'll send a patch to that effect. Patch below, and attached. However, I think the correct thing to do would be to just revert 93be8285 update domU's node-affinity on the cpupool_unassign_cpu() path, wouldn't it? Regards, Dario 8--- xen: avoid updating node affinity twice when removing a CPU from a cpupool 93be8285 (update domU's node-affinity on the cpupool_unassign_cpu() path) introduced a call to domain_update_node_affinity() when a pCPU is removed from a cpupool, but that happens already, in cpu_disable_scheduler(). Furthermore, it causes (although only in rather awkward circumstances), the following ASSERT to trigger: (XEN) (XEN) Panic on CPU 0: (XEN) Assertion '!cpumask_empty(dom_cpumask)' failed at domain.c:460 (XEN) This change, therefore, undo that. Signed-off-by: Dario Faggioli dario.faggi...@citrix.com Cc: Juergen Gross jgr...@suse.com Cc: George Dunlap george.dun...@eu.citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Keir Fraser keir@gmail.com diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c index a758a8b..cd6aab9 100644 --- a/xen/common/cpupool.c +++ b/xen/common/cpupool.c @@ -379,12 +379,6 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu) atomic_inc(c-refcnt); cpupool_cpu_moving = c; cpumask_clear_cpu(cpu, c-cpu_valid); - -rcu_read_lock(domlist_read_lock); -for_each_domain_in_cpupool(d, c) -domain_update_node_affinity(d); -rcu_read_unlock(domlist_read_lock); - spin_unlock(cpupool_lock); work_cpu = smp_processor_id(); xen: avoid updating node affinity twice when removing a CPU from a cpupool 93be8285 (update domU's node-affinity on the cpupool_unassign_cpu() path) introduced a call to domain_update_node_affinity() when a pCPU is removed from a cpupool, but that happens already, in cpu_disable_scheduler(). Furthermore, it causes (although only in rather awkward circumstances), the following ASSERT to trigger: (XEN) (XEN) Panic on CPU 0: (XEN) Assertion '!cpumask_empty(dom_cpumask)' failed at domain.c:460 (XEN) This change, therefore, undo that. Signed-off-by: Dario Faggioli dario.faggi...@citrix.com Cc: Juergen Gross jgr...@suse.com Cc: George Dunlap george.dun...@eu.citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Keir Fraser keir@gmail.com diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c index a758a8b..cd6aab9 100644 --- a/xen/common/cpupool.c +++ b/xen/common/cpupool.c @@ -379,12 +379,6 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu) atomic_inc(c-refcnt); cpupool_cpu_moving = c; cpumask_clear_cpu(cpu, c-cpu_valid); - -rcu_read_lock(domlist_read_lock); -for_each_domain_in_cpupool(d, c) -domain_update_node_affinity(d); -rcu_read_unlock(domlist_read_lock); - spin_unlock(cpupool_lock); work_cpu = smp_processor_id(); signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 1/7] xen/arm: p2m changes for mem_access support
On Thu, Mar 12, 2015 at 1:57 PM, Julien Grall julien.gr...@linaro.org
wrote:
Hi Tamas,
On 06/03/15 21:24, Tamas K Lengyel wrote:
@@ -1090,6 +1098,8 @@ void p2m_teardown(struct domain *d)
p2m_free_vmid(d);
+radix_tree_destroy(p2m-mem_access_settings, NULL);
+
spin_unlock(p2m-lock);
}
@@ -1115,6 +1125,10 @@ int p2m_init(struct domain *d)
p2m-max_mapped_gfn = 0;
p2m-lowest_mapped_gfn = ULONG_MAX;
+p2m-default_access = p2m_access_rwx;
+p2m-mem_access_enabled = false;
false is defined for bool not bool_t.
Please use 0 here.
Ack.
[..]
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index da36504..7583d9b 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -2,8 +2,9 @@
#define _XEN_P2M_H
#include xen/mm.h
-
+#include xen/radix-tree.h
#include xen/p2m-common.h
+#include public/memory.h
#define paddr_bits PADDR_BITS
@@ -48,6 +49,18 @@ struct p2m_domain {
/* If true, and an access fault comes in and there is no mem_event
listener,
* pause domain. Otherwise, remove access restrictions. */
bool_t access_required;
+
+/* Defines if mem_access is in use for the domain. */
+bool_t mem_access_enabled;
+
+/* Default P2M access type for each page in the the domain: new
pages,
+ * swapped in pages, cleared pages, and pages that are ambiguously
+ * retyped get this access type. See definition of p2m_access_t. */
Coding style. It should be:
/*
* Default ...
*
*/
+p2m_access_t default_access;
+
+/* Radix tree to store the p2m_access_t settings as the pte's don't
have
+ * enough available bits to store this information. */
Ditto
+struct radix_tree_root mem_access_settings;
};
/* List of possible type for each page in the p2m entry.
@@ -217,6 +230,26 @@ static inline int get_page_and_type(struct
page_info *page,
/* get host p2m table */
#define p2m_get_hostp2m(d) ((d)-arch.p2m)
+/* mem_event and mem_access are supported on any ARM guest */
+static inline bool_t p2m_mem_access_sanity_check(struct domain *d)
+{
+return 1;
+}
+
+static inline bool_t p2m_mem_event_sanity_check(struct domain *d)
+{
+return 1;
+}
+
+/* Get access type for a pfn
+ * If pfn == -1ul, gets the default access type */
Ditto
Ack, however, all other comments here followed this style even for
multi-line comments. If I change the style only on my comments it will be
mixed (and ugly) IMHO.
Regards,
--
Julien Grall
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 119 (CVE-2015-2152) - HVM qemu unexpectedly enabling emulated VGA graphics backends
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory CVE-2015-2152 / XSA-119 version 3 HVM qemu unexpectedly enabling emulated VGA graphics backends UPDATES IN VERSION 3 Public release. ISSUE DESCRIPTION = When instantiating an emulated VGA device for an x86 HVM guest qemu will by default enable a backend to expose that device, either SDL or VNC depending on the version of qemu and the build time configuration. The libxl toolstack library does not explicitly disable these default backends when they are not enabled, leading to an unexpected backend running. If either SDL or VNC is explicitly enabled in the guest configuration then only the expected backends will be enabled. This affects qemu-xen and qemu-xen-traditional differently. If qemu-xen was compiled with SDL support then this would result in an SDL window being opened if $DISPLAY is valid, or a failure to start the guest if not. If qemu-xen was compiled without SDL support then qemu would instead start a VNC server listening on ::1 (IPv6 localhost) or 127.0.0.1 (IPv4 localhost) with IPv6 preferred if available. A VNC password will not be configured even if one is present in the guest configuration. qemu-xen-traditional will never start a vnc backend unless explicitly configured. However by default it will start an SDL backend if it was built with SDL support and $DISPLAY is valid. IMPACT == For qemu-xen compiled without SDL support (unexpected VNC server): Any local user on the domain 0 hosting the VM will be able to access the guest's emulated VGA console. For any qemu compiled with SDL support (unexpected SDL backend): Users who are able to control the DISPLAY environment variable of the toolstack process which creates the VM will be able to direct the SDL output to an X server of their choosing and from there gain access to the guest's emulated console. This is a practical attack only on systems where arrangements have been made for lower-privileged users to execute Xen toolstack code via means which do not sufficiently launder the process environment. This would include some restricted sudo command configurations. In both cases unexpected access to the guest console may then, depending on the guest configuration, grant further privilege or opportunities for attack. Both cases also open up the qemu process to attacks via the VNC or X network protocols. The qemu monitor is not exposed via this means unless it is explicitly enabled in the guest configuration. VULNERABLE SYSTEMS == ARM systems are not vulnerable. PV domains are not vulnerable. Systems where either SDL or VNC is explicitly enabled in the guest configuration (eg `sdl=1' or `vnc=1' in the guest config file) are not vulnerable. Systems using qemu-xen-traditional, or systems using qemu-xen where SDL support is built into qemu-xen, are not vulnerable; unless the Xen toolstack code runs in a process environment partially controlled by potential attackers. x86 systems running HVM domains, configured to disable both SDL and VNC access to the emulated VGA device, may be vulnerable. Versions of Xen from 4.2 onwards are known to be affected. Older versions have not been inspected. MITIGATION == Running qemu in a stub domain will avoid this issue. Setting nographic to true on the domain (i.e. nographic=1 in an xl configuration file) will completely disable the emulated VGA device and therefore avoid this issue. (NB that publicly visible deployment of this mitigation during the embargo is forbidden.) In order to disable the backends while retaining the emulated VGA then prepending -vnc none -display none to the qemu-xen command-line or -vnc none to the qemu-xen-traditional command-line, using e.g. a wrapper script will avoid the issue. Note that the extra_hvm option exposed by the libxl library is not useful because it appends the given options making them ineffective in this case. CREDITS === This issue was discovered by Sander Eikelenboom. RESOLUTION == Applying the appropriate attached patch resolves this issue. xsa119-unstable.patchxen-unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x xsa119-4.2.patch Xen 4.2.x $ sha256sum xsa119*.patch ee44c8f6a7cf3ca7b2d9886047b91690aaa2b091baf8629d8ab4c298022c6c47 xsa119-unstable.patch 5470eae3ca776a5100e8da9400ce15a2f4d855177f023430b2462f65e716128f xsa119-4.2.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. Deployment of a revised command qemu line which sets -vnc none - -display none or -vnc none (as applicable) is also permitted. Mitigation by passing `nographic=1' or equivalent guest configuration, is NOT permitted (except where all the guests are
Re: [Xen-devel] [PATCH 2/2] CA-162192: Fix rebooting on some EFI-booted systems
On 12.03.15 at 15:07, andrew.coop...@citrix.com wrote:
On 12/03/15 11:44, Jan Beulich wrote:
@@ -452,6 +464,7 @@ static struct dmi_system_id __initdata r
static int __init reboot_init(void)
{
+default_reboot_type();
This still suffers from the bug Ross fixed in patch 1. If the user
provides an override, the dmi quirks should be skipped so the request on
the command line is honoured.
And I assumed he'd resubmit that patch anyway, i.e. I didn't even
mean to fix this here.
@@ -532,6 +550,11 @@ void machine_restart(unsigned int delay_
reboot_type = (((attempt == 1) (orig_reboot_type ==
BOOT_ACPI))
? BOOT_ACPI : BOOT_TRIPLE);
break;
+case BOOT_EFI:
+efi_reset_system(reboot_mode != 0);
+reboot_type = acpi_disabled ? BOOT_KBD : BOOT_ACPI;
+*((unsigned short *)__va(0x472)) = reboot_mode;
+break;
Update the reboot type before calling efi_reset_system()
That way, if efi_reset_system() does fault, we will reenter
machine_restart() and take an alternate route.
The exact symptoms with the reference code is that efi_reset_system()
causes a #GP fault which breaks back into Xen, and the panic() path
reenters efi_reset_system() at which point the system wedges and needs a
hard power cycle.
Good point, flipped.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 0/4] xen: sched: rework and add performance counters
On 03/12/2015 12:51 PM, Dario Faggioli wrote: On Fri, 2015-02-27 at 17:50 +0100, Dario Faggioli wrote: Take 2 of this: http://lists.xen.org/archives/html/xen-devel/2015-02/msg03249.html I've made all the changes suggested during v1. The series has Meng's Reviewed-by for the changes to sched_rt.c, and Jan's Ack for the non-strictly scheduling related part (1 file! :-D), so I think what is missing is George's view/Ack. George, ping No intention to push, of course... just a remainder in case this failed to show up on your radar. :-D Yep, it's on my radar... just trying to catch up on stuff... I should have a chance to look at it next week, I think. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 1/3] x86: identifying the boot cpu
Provide helpers to access the socket and core IDs, resulting from
identification phase.
Initialize socket and core ID to -1 i.e invalid instead of 0.
Signed-off-by: Uma Sharma uma.sharma...@gmail.com
---
xen/arch/x86/setup.c| 7 +--
xen/arch/x86/smpboot.c | 3 ++-
xen/include/asm-x86/processor.h | 2 ++
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 7593533..251840f 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1259,6 +1259,11 @@ void __init noreturn __start_xen(unsigned long mbi_p)
microcode_grab_module(module_map, mbi, bootstrap_map);
timer_init();
+/*
+ * Identify the boot CPU, in case the scheduler initialization
+ * needs to know about it (e.g., topology, etc.)
+ */
+identify_cpu(boot_cpu_data);
init_idle_domain();
@@ -1270,8 +1275,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
arch_init_memory();
-identify_cpu(boot_cpu_data);
-
if ( cpu_has_fxsr )
set_in_cr4(X86_CR4_OSFXSR);
if ( cpu_has_xmm )
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 314e253..6ec15e2 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -59,7 +59,8 @@ DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_mask);
cpumask_t cpu_online_map __read_mostly;
EXPORT_SYMBOL(cpu_online_map);
-struct cpuinfo_x86 cpu_data[NR_CPUS];
+struct cpuinfo_x86 cpu_data[NR_CPUS] =
+{ [0 ... NR_CPUS-1] = { .phys_proc_id=-1, .cpu_core_id=-1 } };
u32 x86_cpu_to_apicid[NR_CPUS] __read_mostly =
{ [0 ... NR_CPUS-1] = BAD_APICID };
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 87d80ff..6ec9588 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -214,7 +214,9 @@ extern void detect_extended_topology(struct cpuinfo_x86 *c);
extern void detect_ht(struct cpuinfo_x86 *c);
+#define boot_cpu_to_core() (boot_cpu_data.cpu_core_id)
#define cpu_to_core(_cpu) (cpu_data[_cpu].cpu_core_id)
+#define boot_cpu_to_socket() (boot_cpu_data.phys_proc_id)
#define cpu_to_socket(_cpu) (cpu_data[_cpu].phys_proc_id)
unsigned int apicid_to_socket(unsigned int);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
On 12/03/15 14:13, Tamas K Lengyel wrote:
On Thu, Mar 12, 2015 at 2:50 PM, Julien Grall julien.gr...@linaro.org
mailto:julien.gr...@linaro.org wrote:
Hi Tamas,
On 06/03/15 21:24, Tamas K Lengyel wrote:
+/*
+ * If mem_access is in use it might have been the reason why
get_page_from_gva
+ * failed to fetch the page, as it uses the MMU for the permission
checking.
+ * Only in these cases we do a software-based type check and fetch the
page if
+ * we indeed found a conflicting mem_access setting.
+ */
+static int check_type_get_page(vaddr_t gva, unsigned long flag,
+ struct page_info** page)
+{
+long rc;
+paddr_t ipa;
+unsigned long maddr;
+unsigned long mfn;
+xenmem_access_t xma;
+p2m_type_t t;
+
+rc = gva_to_ipa(gva, ipa);
I though a bit more about this call.
gva_to_ipa only checks if the mapping has read-permission. That would
allow a guest to write on read-only mapping.
You have to pass the flags to gva_to_ipa in order to avoid
re-introducing XSA-98 [1]
Here I really just care if the mapping exist to see if we have a
mem_access restriction, r/w permission checking is then performed
afterwards by checking the page type. If there are additional
restrictions on the page beside the type, those certainly should be
added. Can you point me to where that additional restriction is stored
so I can query for it?
The R/W permission checking done afterwards is not enough.
What does get_page_from_gva is:
1) Check the permission on Stage 1 page table (controlled by the guest
and translate VA - IPA)
2) Check the permission on Stage 2 page table (controlled by the
hypervisor and translate IPA - PA).
get_page_from_gva may fail because of 1), which is not related to memaccess.
Currently, check_type_get_page emulate only the check for 2). So you may
end up to allow Xen writing in read-only mapping (from the Stage 1 POV).
This was XSA-98.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
Hi Tamas,
On 06/03/15 21:24, Tamas K Lengyel wrote:
The guestcopy helpers use the MMU to verify that the given guest has
read/write
access to a given page during hypercalls. As we may have custom mem_access
permissions set on these pages, we do a software-based type checking in case
the MMU based approach failed, but only if mem_access_enabled is set.
These memory accesses are not forwarded to the mem_event listener. Accesses
performed by the hypervisor are currently not part of the mem_access scheme.
This is consistent behaviour with the x86 side as well.
Signed-off-by: Tamas K Lengyel tkleng...@sec.in.tum.de
---
v12: - Check for mfn_valid as well.
---
xen/arch/arm/guestcopy.c | 124
+--
1 file changed, 121 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 7dbaeca..d42a469 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -6,6 +6,115 @@
#include asm/mm.h
#include asm/guest_access.h
+#include asm/p2m.h
+
+/*
+ * If mem_access is in use it might have been the reason why
get_page_from_gva
+ * failed to fetch the page, as it uses the MMU for the permission checking.
+ * Only in these cases we do a software-based type check and fetch the page
if
+ * we indeed found a conflicting mem_access setting.
+ */
+static int check_type_get_page(vaddr_t gva, unsigned long flag,
+ struct page_info** page)
+{
+long rc;
AFAICT, all the return value stored in rc are int.
+paddr_t ipa;
+unsigned long maddr;
+unsigned long mfn;
+xenmem_access_t xma;
+p2m_type_t t;
+
+rc = gva_to_ipa(gva, ipa);
+if ( rc 0 )
+return rc;
+
+/*
+ * We do this first as this is faster in the default case when no
+ * permission is set on the page.
+ */
+rc = p2m_get_mem_access(current-domain, paddr_to_pfn(ipa), xma);
+if ( rc 0 )
Maybe a likely would be good here?
+return rc;
+
+/* Let's check if mem_access limited the access. */
+switch ( xma )
+{
+default:
+case XENMEM_access_rwx:
+case XENMEM_access_rw:
+return -EFAULT;
+case XENMEM_access_n2rwx:
+case XENMEM_access_n:
+case XENMEM_access_x:
+break;
+case XENMEM_access_wx:
+case XENMEM_access_w:
+if ( flag == GV2M_READ )
+break;
+else return -EFAULT;
+case XENMEM_access_rx2rw:
+case XENMEM_access_rx:
+case XENMEM_access_r:
+if ( flag == GV2M_WRITE )
+break;
+else return -EFAULT;
+}
+
+/*
+ * 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.
+ */
+maddr = p2m_lookup(current-domain, ipa, t);
+if ( maddr == INVALID_PADDR )
+return -EFAULT;
+
+mfn = maddr PAGE_SHIFT;
+if ( !mfn_valid(mfn) )
+return -EFAULT;
+
+/*
+ * All page types are readable so we only have to check the
+ * type if writing.
+ */
That's may change in the future. A white-list may be better in order to
avoid giving wrong access when a new p2m type is added.
+if ( flag == GV2M_WRITE )
+{
+switch ( t )
+{
+case p2m_ram_rw:
+case p2m_iommu_map_rw:
+case p2m_map_foreign:
+case p2m_grant_map_rw:
+case p2m_mmio_direct:
We disallow guest copy from the above 4 types via get_page_from_gva. So
I'm not sure if it's worth to check them here.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 1/7] xen/arm: p2m changes for mem_access support
On 12/03/15 13:18, Tamas K Lengyel wrote:
+struct radix_tree_root mem_access_settings;
};
/* List of possible type for each page in the p2m entry.
@@ -217,6 +230,26 @@ static inline int get_page_and_type(struct
page_info *page,
/* get host p2m table */
#define p2m_get_hostp2m(d) ((d)-arch.p2m)
+/* mem_event and mem_access are supported on any ARM guest */
+static inline bool_t p2m_mem_access_sanity_check(struct domain *d)
+{
+return 1;
+}
+
+static inline bool_t p2m_mem_event_sanity_check(struct domain *d)
+{
+return 1;
+}
+
+/* Get access type for a pfn
+ * If pfn == -1ul, gets the default access type */
Ditto
Ack, however, all other comments here followed this style even for
multi-line comments. If I change the style only on my comments it will
be mixed (and ugly) IMHO.
Hmmm... right. Ian, Stefano, any comments?
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
Hi Tamas,
On 06/03/15 21:24, Tamas K Lengyel wrote:
+/*
+ * If mem_access is in use it might have been the reason why
get_page_from_gva
+ * failed to fetch the page, as it uses the MMU for the permission checking.
+ * Only in these cases we do a software-based type check and fetch the page
if
+ * we indeed found a conflicting mem_access setting.
+ */
+static int check_type_get_page(vaddr_t gva, unsigned long flag,
+ struct page_info** page)
+{
+long rc;
+paddr_t ipa;
+unsigned long maddr;
+unsigned long mfn;
+xenmem_access_t xma;
+p2m_type_t t;
+
+rc = gva_to_ipa(gva, ipa);
I though a bit more about this call.
gva_to_ipa only checks if the mapping has read-permission. That would
allow a guest to write on read-only mapping.
You have to pass the flags to gva_to_ipa in order to avoid
re-introducing XSA-98 [1]
Regards,
[1] http://xenbits.xen.org/xsa/advisory-98.html
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] CA-162192: Fix rebooting on some EFI-booted systems
On 12/03/15 11:44, Jan Beulich wrote:
On 11.03.15 at 19:49, konrad.w...@oracle.com wrote:
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Tue, 3 Feb 2015 11:18:04 -0500
Subject: [PATCH] efi: Allow reboot= overrides when running under EFI
By default we will always use EFI reboot mechanism when
running under EFI platforms. However some EFI platforms
are buggy and need to use the ACPI mechanism to
reboot (such as Lenovo ThinkCentre M57). As such
respect the 'reboot=' override and DMI overrides
for EFI platforms.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Further re-worked (hopefully we're reaching something
everyone is okay with):
efi: Allow reboot= overrides when running under EFI
By default we will always use EFI reboot mechanism when
running under EFI platforms. However some EFI platforms
are buggy and need to use the ACPI mechanism to
reboot (such as Lenovo ThinkCentre M57). As such
respect the 'reboot=' override and DMI overrides
for EFI platforms.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
- BOOT_INVALID is just zero
- also consider acpi_disabled in BOOT_INVALID resolution
- duplicate BOOT_INVALID resolution in machine_restart()
- don't fall back from BOOT_ACPI to BOOT_EFI (if it was overridden, it
surely was for a reason)
- adjust doc change formatting
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1145,7 +1145,7 @@ The following resources are available:
Technology.
### reboot
- `= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]`
+ `= t[riple] | k[bd] | a[cpi] | p[ci] | e[fi] | n[o] [, [w]arm | [c]old]`
Default: `0`
@@ -1165,6 +1165,9 @@ Specify the host reboot method.
`pci` instructs Xen to reboot the host using PCI reset register (port CF9).
+'efi' instructs Xen to reboot using the EFI reboot call (in EFI mode by
+ default it will use that method first).
+
### ro-hpet
`= boolean`
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -28,16 +28,18 @@
#include asm/apic.h
enum reboot_type {
+BOOT_INVALID,
BOOT_TRIPLE = 't',
BOOT_KBD = 'k',
BOOT_ACPI = 'a',
BOOT_CF9 = 'p',
+BOOT_EFI = 'e',
};
static int reboot_mode;
/*
- * reboot=t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]
+ * reboot=t[riple] | k[bd] | a[cpi] | p[ci] | n[o] | [e]fi [, [w]arm |
[c]old]
* warm Don't set the cold reboot flag
* cold Set the cold reboot flag
* no Suppress automatic reboot after panics or crashes
@@ -45,8 +47,9 @@ static int reboot_mode;
* kbdUse the keyboard controller. cold reset (default)
* acpi Use the RESET_REG in the FADT
* pciUse the so-called PCI reset register, CF9
+ * efiUse the EFI reboot (if running under EFI)
*/
-static enum reboot_type reboot_type = BOOT_ACPI;
+static enum reboot_type reboot_type = BOOT_INVALID;
static void __init set_reboot_type(char *str)
{
for ( ; ; )
@@ -63,6 +66,7 @@ static void __init set_reboot_type(char
reboot_mode = 0x0;
break;
case 'a':
+case 'e':
case 'k':
case 't':
case 'p':
@@ -106,6 +110,14 @@ void machine_halt(void)
__machine_halt(NULL);
}
+static void default_reboot_type(void)
+{
+if ( reboot_type == BOOT_INVALID )
+reboot_type = efi_enabled ? BOOT_EFI
+ : acpi_disabled ? BOOT_KBD
+ : BOOT_ACPI;
+}
+
static int __init override_reboot(struct dmi_system_id *d)
{
enum reboot_type type = (long)d-driver_data;
@@ -452,6 +464,7 @@ static struct dmi_system_id __initdata r
static int __init reboot_init(void)
{
+default_reboot_type();
This still suffers from the bug Ross fixed in patch 1. If the user
provides an override, the dmi quirks should be skipped so the request on
the command line is honoured.
dmi_check_system(reboot_dmi_table);
return 0;
}
@@ -465,7 +478,7 @@ static void noreturn __machine_restart(v
void machine_restart(unsigned int delay_millisecs)
{
unsigned int i, attempt;
-enum reboot_type orig_reboot_type = reboot_type;
+enum reboot_type orig_reboot_type;
const struct desc_ptr no_idt = { 0 };
watchdog_disable();
@@ -504,15 +517,20 @@ void machine_restart(unsigned int delay_
tboot_shutdown(TB_SHUTDOWN_REBOOT);
}
-efi_reset_system(reboot_mode != 0);
+/* Just in case reboot_init() didn't run yet. */
+default_reboot_type();
+orig_reboot_type = reboot_type;
/* Rebooting needs to touch the page at absolute address 0. */
-*((unsigned short *)__va(0x472)) = reboot_mode;
+if ( reboot_type != BOOT_EFI )
+*((unsigned short *)__va(0x472)) = reboot_mode;
for (
Re: [Xen-devel] [PATCH] xen: avoid updating node affinity twice when removing a CPU from a cpupool
On 03/12/2015 01:45 PM, Dario Faggioli wrote: On Wed, 2015-03-11 at 16:04 +, Dario Faggioli wrote: On Wed, 2015-03-11 at 15:01 +, George Dunlap wrote: It looks like domain_update_node_affinity() is already called for each domain in the cpupool in cpu_disable_scheduler(). It doesn't look like there should be a need to call it twice. Can we just remove the call to domain_update_node_affinity() in cpupool_unassign_cpu() and not add it back? Mmm.. true, actually. I'll send a patch to that effect. Patch below, and attached. However, I think the correct thing to do would be to just revert 93be8285 update domU's node-affinity on the cpupool_unassign_cpu() path, wouldn't it? Funny you should mention that... one of the things I was thinking of suggesting was trying to move the domain_update_node_affinity() out of cpupool.c and into schedule.c, somewhere on the path that brings up a cpu or assigns it to a pool, specifically so that the lack of symmetry didn't trip anybody up. But at a quick glance I couldn't find a likely candidate. Now that I find out it already *has* tripped someone up, I think we had definitely better do something about it. :-) Let me take a look and see what seems sensible... -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: avoid updating node affinity twice when removing a CPU from a cpupool
On 12.03.15 at 14:45, dario.faggi...@citrix.com wrote: Patch below, and attached. However, I think the correct thing to do would be to just revert 93be8285 update domU's node-affinity on the cpupool_unassign_cpu() path, wouldn't it? Indeed - if the presented patch is what we want, it should be carried out as a revert. But you'll then want to explain why you did what you did there in the first place: It surely wasn't without reason, and hence I'd be afraid the revert would re-introduce another problem. That explanation should then probably go in as description for the revert. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 6/7] xen/arm: Enable mem_access on ARM
On Fri, 2015-03-06 at 22:24 +0100, Tamas K Lengyel wrote: Signed-off-by: Tamas K Lengyel tkleng...@sec.in.tum.de Acked-by: Ian Campbell ian.campb...@citrix.com --- config/arm32.mk | 1 + config/arm64.mk | 1 + 2 files changed, 2 insertions(+) diff --git a/config/arm32.mk b/config/arm32.mk index 268ca9c..cd97e42 100644 --- a/config/arm32.mk +++ b/config/arm32.mk @@ -14,6 +14,7 @@ HAS_EXYNOS4210 := y HAS_OMAP := y HAS_SCIF := y HAS_NS16550 := y +HAS_MEM_ACCESS := y # Use only if calling $(LD) directly. LDFLAGS_DIRECT += -EL diff --git a/config/arm64.mk b/config/arm64.mk index 6eafda2..d2fd242 100644 --- a/config/arm64.mk +++ b/config/arm64.mk @@ -8,6 +8,7 @@ CFLAGS += #-marm -march= -mcpu= etc HAS_PL011 := y HAS_NS16550 := y +HAS_MEM_ACCESS := y # Use only if calling $(LD) directly. LDFLAGS_DIRECT += -EL ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 1/7] xen/arm: p2m changes for mem_access support
On Thu, 2015-03-12 at 13:22 +0100, Tamas K Lengyel wrote: I guess naming this patch something like groundwork for mem_access support would be more descriptive. Adding everything when they are actually getting used would have resulted in a massive patch that I think would have been harder to review. If possible, I will just clean up the patch message to better describe what is being added by this patch instead of breaking it down further. Sure, thanks. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 1/7] xen/arm: p2m changes for mem_access support
On Thu, 2015-03-12 at 13:25 +, Julien Grall wrote:
On 12/03/15 13:18, Tamas K Lengyel wrote:
+struct radix_tree_root mem_access_settings;
};
/* List of possible type for each page in the p2m entry.
@@ -217,6 +230,26 @@ static inline int get_page_and_type(struct
page_info *page,
/* get host p2m table */
#define p2m_get_hostp2m(d) ((d)-arch.p2m)
+/* mem_event and mem_access are supported on any ARM guest */
+static inline bool_t p2m_mem_access_sanity_check(struct domain *d)
+{
+return 1;
+}
+
+static inline bool_t p2m_mem_event_sanity_check(struct domain *d)
+{
+return 1;
+}
+
+/* Get access type for a pfn
+ * If pfn == -1ul, gets the default access type */
Ditto
Ack, however, all other comments here followed this style even for
multi-line comments. If I change the style only on my comments it will
be mixed (and ugly) IMHO.
Hmmm... right. Ian, Stefano, any comments?
Follow the existing style in the file.
Regards,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 7/7] tools/libxc: Allocate magic page for mem access on ARM
On Fri, 2015-03-06 at 22:24 +0100, Tamas K Lengyel wrote: Signed-off-by: Tamas K Lengyel tkleng...@sec.in.tum.de Reviewed-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com --- tools/libxc/xc_dom_arm.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c index c7feca7..aaf835c 100644 --- a/tools/libxc/xc_dom_arm.c +++ b/tools/libxc/xc_dom_arm.c @@ -26,9 +26,10 @@ #include xg_private.h #include xc_dom.h -#define NR_MAGIC_PAGES 2 +#define NR_MAGIC_PAGES 3 #define CONSOLE_PFN_OFFSET 0 #define XENSTORE_PFN_OFFSET 1 +#define MEMACCESS_PFN_OFFSET 2 #define LPAE_SHIFT 9 @@ -87,10 +88,13 @@ static int alloc_magic_pages(struct xc_dom_image *dom) xc_clear_domain_page(dom-xch, dom-guest_domid, dom-console_pfn); xc_clear_domain_page(dom-xch, dom-guest_domid, dom-xenstore_pfn); +xc_clear_domain_page(dom-xch, dom-guest_domid, base + MEMACCESS_PFN_OFFSET); xc_hvm_param_set(dom-xch, dom-guest_domid, HVM_PARAM_CONSOLE_PFN, dom-console_pfn); xc_hvm_param_set(dom-xch, dom-guest_domid, HVM_PARAM_STORE_PFN, dom-xenstore_pfn); +xc_hvm_param_set(dom-xch, dom-guest_domid, HVM_PARAM_ACCESS_RING_PFN, +base + MEMACCESS_PFN_OFFSET); /* allocated by toolstack */ xc_hvm_param_set(dom-xch, dom-guest_domid, HVM_PARAM_CONSOLE_EVTCHN, dom-console_evtchn); ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] CA-162192: Fix rebooting on some EFI-booted systems
On March 12, 2015 7:44:58 AM EDT, Jan Beulich jbeul...@suse.com wrote:
On 11.03.15 at 19:49, konrad.w...@oracle.com wrote:
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Tue, 3 Feb 2015 11:18:04 -0500
Subject: [PATCH] efi: Allow reboot= overrides when running under EFI
By default we will always use EFI reboot mechanism when
running under EFI platforms. However some EFI platforms
are buggy and need to use the ACPI mechanism to
reboot (such as Lenovo ThinkCentre M57). As such
respect the 'reboot=' override and DMI overrides
for EFI platforms.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Further re-worked (hopefully we're reaching something
everyone is okay with):
efi: Allow reboot= overrides when running under EFI
By default we will always use EFI reboot mechanism when
running under EFI platforms. However some EFI platforms
are buggy and need to use the ACPI mechanism to
reboot (such as Lenovo ThinkCentre M57). As such
respect the 'reboot=' override and DMI overrides
for EFI platforms.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
And Reviewed-by as well.
- BOOT_INVALID is just zero
- also consider acpi_disabled in BOOT_INVALID resolution
- duplicate BOOT_INVALID resolution in machine_restart()
- don't fall back from BOOT_ACPI to BOOT_EFI (if it was overridden, it
surely was for a reason)
- adjust doc change formatting
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1145,7 +1145,7 @@ The following resources are available:
Technology.
### reboot
- `= t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]`
+ `= t[riple] | k[bd] | a[cpi] | p[ci] | e[fi] | n[o] [, [w]arm |
[c]old]`
Default: `0`
@@ -1165,6 +1165,9 @@ Specify the host reboot method.
`pci` instructs Xen to reboot the host using PCI reset register (port
CF9).
+'efi' instructs Xen to reboot using the EFI reboot call (in EFI mode
by
+ default it will use that method first).
+
### ro-hpet
`= boolean`
--- a/xen/arch/x86/shutdown.c
+++ b/xen/arch/x86/shutdown.c
@@ -28,16 +28,18 @@
#include asm/apic.h
enum reboot_type {
+BOOT_INVALID,
BOOT_TRIPLE = 't',
BOOT_KBD = 'k',
BOOT_ACPI = 'a',
BOOT_CF9 = 'p',
+BOOT_EFI = 'e',
};
static int reboot_mode;
/*
- * reboot=t[riple] | k[bd] | a[cpi] | p[ci] | n[o] [, [w]arm | [c]old]
+ * reboot=t[riple] | k[bd] | a[cpi] | p[ci] | n[o] | [e]fi [, [w]arm |
[c]old]
* warm Don't set the cold reboot flag
* cold Set the cold reboot flag
* no Suppress automatic reboot after panics or crashes
@@ -45,8 +47,9 @@ static int reboot_mode;
* kbdUse the keyboard controller. cold reset (default)
* acpi Use the RESET_REG in the FADT
* pciUse the so-called PCI reset register, CF9
+ * efiUse the EFI reboot (if running under EFI)
*/
-static enum reboot_type reboot_type = BOOT_ACPI;
+static enum reboot_type reboot_type = BOOT_INVALID;
static void __init set_reboot_type(char *str)
{
for ( ; ; )
@@ -63,6 +66,7 @@ static void __init set_reboot_type(char
reboot_mode = 0x0;
break;
case 'a':
+case 'e':
case 'k':
case 't':
case 'p':
@@ -106,6 +110,14 @@ void machine_halt(void)
__machine_halt(NULL);
}
+static void default_reboot_type(void)
+{
+if ( reboot_type == BOOT_INVALID )
+reboot_type = efi_enabled ? BOOT_EFI
+ : acpi_disabled ? BOOT_KBD
+ : BOOT_ACPI;
+}
+
static int __init override_reboot(struct dmi_system_id *d)
{
enum reboot_type type = (long)d-driver_data;
@@ -452,6 +464,7 @@ static struct dmi_system_id __initdata r
static int __init reboot_init(void)
{
+default_reboot_type();
dmi_check_system(reboot_dmi_table);
return 0;
}
@@ -465,7 +478,7 @@ static void noreturn __machine_restart(v
void machine_restart(unsigned int delay_millisecs)
{
unsigned int i, attempt;
-enum reboot_type orig_reboot_type = reboot_type;
+enum reboot_type orig_reboot_type;
const struct desc_ptr no_idt = { 0 };
watchdog_disable();
@@ -504,15 +517,20 @@ void machine_restart(unsigned int delay_
tboot_shutdown(TB_SHUTDOWN_REBOOT);
}
-efi_reset_system(reboot_mode != 0);
+/* Just in case reboot_init() didn't run yet. */
+default_reboot_type();
+orig_reboot_type = reboot_type;
/* Rebooting needs to touch the page at absolute address 0. */
-*((unsigned short *)__va(0x472)) = reboot_mode;
+if ( reboot_type != BOOT_EFI )
+*((unsigned short *)__va(0x472)) = reboot_mode;
for ( attempt = 0; ; attempt++ )
{
switch ( reboot_type )
{
+case BOOT_INVALID:
+ASSERT_UNREACHABLE();
case BOOT_KBD:
/* Pulse the keyboard reset line. */
for ( i = 0; i
Re: [Xen-devel] [PATCH V13 1/7] xen/arm: p2m changes for mem_access support
On Thu, 2015-03-12 at 12:57 +, Julien Grall wrote: Hi Tamas, On 06/03/15 21:24, Tamas K Lengyel wrote: @@ -1090,6 +1098,8 @@ void p2m_teardown(struct domain *d) p2m_free_vmid(d); +radix_tree_destroy(p2m-mem_access_settings, NULL); + spin_unlock(p2m-lock); } @@ -1115,6 +1125,10 @@ int p2m_init(struct domain *d) p2m-max_mapped_gfn = 0; p2m-lowest_mapped_gfn = ULONG_MAX; +p2m-default_access = p2m_access_rwx; +p2m-mem_access_enabled = false; false is defined for bool not bool_t. Please use 0 here. I'm not convinced, false is false whatever you assign it to. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 1/7] xen/arm: p2m changes for mem_access support
On 12/03/15 13:56, Ian Campbell wrote: On Thu, 2015-03-12 at 12:57 +, Julien Grall wrote: Hi Tamas, On 06/03/15 21:24, Tamas K Lengyel wrote: @@ -1090,6 +1098,8 @@ void p2m_teardown(struct domain *d) p2m_free_vmid(d); +radix_tree_destroy(p2m-mem_access_settings, NULL); + spin_unlock(p2m-lock); } @@ -1115,6 +1125,10 @@ int p2m_init(struct domain *d) p2m-max_mapped_gfn = 0; p2m-lowest_mapped_gfn = ULONG_MAX; +p2m-default_access = p2m_access_rwx; +p2m-mem_access_enabled = false; false is defined for bool not bool_t. Please use 0 here. I'm not convinced, false is false whatever you assign it to. C specified that false expands to the constant 0, and true to the constant 1. They are fine for use with any integral type. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: Prune unused ASSERT/BUG/WARN infrastructure
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Keir Fraser k...@xen.org
CC: Jan Beulich jbeul...@suse.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Stefano Stabellini stefano.stabell...@citrix.com
CC: Tim Deegan t...@xen.org
---
Compile tested for x86, arm32 and arm64
---
xen/drivers/char/console.c | 15 ---
xen/include/xen/lib.h | 12
2 files changed, 27 deletions(-)
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index cb0c2d6..fce4cc8 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -1150,21 +1150,6 @@ void panic(const char *fmt, ...)
machine_restart(5000);
}
-void __bug(const char *file, int line)
-{
-console_start_sync();
-printk(Xen BUG at %s:%d\n, file, line);
-dump_execution_state();
-panic(Xen BUG at %s:%d, file, line);
-}
-
-void __warn(const char *file, int line)
-{
-printk(Xen WARN at %s:%d\n, file, line);
-dump_execution_state();
-}
-
-
/*
* **
* ** Console suspend/resume
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index ca3916b..6c8dd86 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -8,9 +8,6 @@
#include xen/string.h
#include asm/bug.h
-void noreturn __bug(const char *file, int line);
-void __warn(const char *file, int line);
-
#define BUG_ON(p) do { if (unlikely(p)) BUG(); } while (0)
#define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
@@ -29,15 +26,6 @@
#define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond))
#endif
-#ifndef assert_failed
-#define assert_failed(p)\
-do {\
-printk(Assertion '%s' failed, line %d, file %s\n, p , \
- __LINE__, __FILE__); \
-BUG(); \
-} while (0)
-#endif
-
#ifndef NDEBUG
#define ASSERT(p) \
do { if ( unlikely(!(p)) ) assert_failed(#p); } while (0)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
On Thu, Mar 12, 2015 at 2:43 PM, Julien Grall julien.gr...@linaro.org wrote:
On 12/03/15 13:38, Tamas K Lengyel wrote:
+if ( flag == GV2M_WRITE )
+{
+switch ( t )
+{
+case p2m_ram_rw:
+case p2m_iommu_map_rw:
+case p2m_map_foreign:
+case p2m_grant_map_rw:
+case p2m_mmio_direct:
We disallow guest copy from the above 4 types via get_page_from_gva. So
I'm not sure if it's worth to check them here.
You mean get_page_from_gva only works for p2m_ram_rw type? Is this the
case for GV2M_READ as well?
Yes, currently p2m_ram_rw is the only type bound to a struct page.
That makes the white-list quite simple, t has to be p2m_ram_rw
regardless of the flag, otherwise fault.
--
Julien Grall
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v1 0/3] credit2 runqueue_per_core code
Hi everyone, This series of patch inserts runqueue_per_core code and creates a boot parameter to choose which type of runqueue mapping to perform i.e core or socket. Core is used by default as runqueue_per_core scheduler performs better than runqueue_per_socket. This series mainly performs the following tasks : -Provide helpers to access the core and socket -Add runqueue_per_core code -Adding boot parameter to decide the runqueue This is relevant to credit2 scheduler only. Performance Analysis : Hardware Used: 4 core 2 HT per core machine. Guest 1: vcpu=4 Core 4 vcpu: make -j 1 82.183 make -j 2 39.488 make -j 4 26.568 make -j 6 24.749 make -j 8 24.835 Socket 4 vcpu: make -j 1 100.044 make -j 2 49.912 make -j 4 31.28 make -j 6 29.058 make -j 8 35.152 credit 4 vcpu: make -j 1 87.466 make -j 2 42.159 make -j 4 26.922 make -j 6 25.638 make -j 8 25.619 Guest 1: vcpu=8 Core 8 vcpu: make -j 1 95.075 make -j 2 45.346 make -j 4 28.775 make -j 6 23.475 make -j 8 21.887 Socket 8 vcpu: make -j 1 103.118 make -j 2 51.412 make -j 4 29.612 make -j 6 24.112 make -j 8 22.521 credit 8 vcpu: make -j 1 90.104 make -j 2 44.932 make -j 4 27.168 make -j 6 24.423 make -j 8 22.109 So according to these analysis core scheduler is working better than socket. And in the case of guest with 4 cores runqueue_per_core credit2 scheduler is working slightly better than credit scheduler. Signed-off-by: Uma Sharma uma.sharma...@gmail.com x86: identifying the boot cpu sched_credit2.c : runqueue_per_core code docs : documentation for the code docs/misc/xen-command-line.markdown | 7 +++ xen/arch/x86/setup.c| 7 +-- xen/arch/x86/smpboot.c | 3 ++- xen/common/sched_credit2.c | 39 ++--- xen/include/asm-x86/processor.h | 2 ++ 5 files changed, 48 insertions(+), 10 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
On Thu, Mar 12, 2015 at 2:24 PM, Julien Grall julien.gr...@linaro.org
wrote:
Hi Tamas,
On 06/03/15 21:24, Tamas K Lengyel wrote:
The guestcopy helpers use the MMU to verify that the given guest has
read/write
access to a given page during hypercalls. As we may have custom
mem_access
permissions set on these pages, we do a software-based type checking in
case
the MMU based approach failed, but only if mem_access_enabled is set.
These memory accesses are not forwarded to the mem_event listener.
Accesses
performed by the hypervisor are currently not part of the mem_access
scheme.
This is consistent behaviour with the x86 side as well.
Signed-off-by: Tamas K Lengyel tkleng...@sec.in.tum.de
---
v12: - Check for mfn_valid as well.
---
xen/arch/arm/guestcopy.c | 124
+--
1 file changed, 121 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 7dbaeca..d42a469 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -6,6 +6,115 @@
#include asm/mm.h
#include asm/guest_access.h
+#include asm/p2m.h
+
+/*
+ * If mem_access is in use it might have been the reason why
get_page_from_gva
+ * failed to fetch the page, as it uses the MMU for the permission
checking.
+ * Only in these cases we do a software-based type check and fetch the
page if
+ * we indeed found a conflicting mem_access setting.
+ */
+static int check_type_get_page(vaddr_t gva, unsigned long flag,
+ struct page_info** page)
+{
+long rc;
AFAICT, all the return value stored in rc are int.
Ack. I actually relocated this function into p2m.c in the next iteration of
the series and change the return type to struct page_info* page.
+paddr_t ipa;
+unsigned long maddr;
+unsigned long mfn;
+xenmem_access_t xma;
+p2m_type_t t;
+
+rc = gva_to_ipa(gva, ipa);
+if ( rc 0 )
+return rc;
+
+/*
+ * We do this first as this is faster in the default case when no
+ * permission is set on the page.
+ */
+rc = p2m_get_mem_access(current-domain, paddr_to_pfn(ipa), xma);
+if ( rc 0 )
Maybe a likely would be good here?
Sure.
+return rc;
+
+/* Let's check if mem_access limited the access. */
+switch ( xma )
+{
+default:
+case XENMEM_access_rwx:
+case XENMEM_access_rw:
+return -EFAULT;
+case XENMEM_access_n2rwx:
+case XENMEM_access_n:
+case XENMEM_access_x:
+break;
+case XENMEM_access_wx:
+case XENMEM_access_w:
+if ( flag == GV2M_READ )
+break;
+else return -EFAULT;
+case XENMEM_access_rx2rw:
+case XENMEM_access_rx:
+case XENMEM_access_r:
+if ( flag == GV2M_WRITE )
+break;
+else return -EFAULT;
+}
+
+/*
+ * 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.
+ */
+maddr = p2m_lookup(current-domain, ipa, t);
+if ( maddr == INVALID_PADDR )
+return -EFAULT;
+
+mfn = maddr PAGE_SHIFT;
+if ( !mfn_valid(mfn) )
+return -EFAULT;
+
+/*
+ * All page types are readable so we only have to check the
+ * type if writing.
+ */
That's may change in the future. A white-list may be better in order to
avoid giving wrong access when a new p2m type is added.
Hm, sure.
+if ( flag == GV2M_WRITE )
+{
+switch ( t )
+{
+case p2m_ram_rw:
+case p2m_iommu_map_rw:
+case p2m_map_foreign:
+case p2m_grant_map_rw:
+case p2m_mmio_direct:
We disallow guest copy from the above 4 types via get_page_from_gva. So
I'm not sure if it's worth to check them here.
You mean get_page_from_gva only works for p2m_ram_rw type? Is this the case
for GV2M_READ as well?
Regards,
--
Julien Grall
Thanks,
Tamas
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (two months reminder)
On 3/12/2015 6:54 AM, Jan Beulich wrote: * amd_ucode cleanups, verify patch size(enhancement) (mostly in master except one patch) Which one? This is in reference to the patches to microcode_amd and it's all 'done' in 4.5 itself. I think when we were tracking this, commit 8b24b07e was not in master branch. Hence the status. We can remove this from the current list of features to be tracked for 4.6 IMO. * Feature masking MSR support (enhancement) (in master) What is this about? Or what status does in master actually refer to? This is in reference to commit e74de9c0. And this is also complete, and can be removed from the list. Before I knew what status values to apply to a feature, I had used 'in master' to convey that patches are in master branch. The feature tracking list has maintained this remnant. In fact, all these patches in the list are 'done' as of 4.5 itself and can be removed IMO. *Data breakpoint Extension support (new-feat) (in master) *Support BRCM TruManage chip (Serial over LAN support) (new-feat) (in master) *fix vmce_amd* functions, unify mce_amd mcheck initialization (fixes/cleanups) *multiple AMD container files appended together in initrd (early initramfs) -Aravind and Suravee Thanks, -Aravind. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 04/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented()
+ pci_add_resource(resources, ioport_resource);
+ pci_add_resource(resources, iomem_resource);
+ pci_add_resource(resources, busn_resource);
Since I don't want to export busn_resource, you might have to allocate your
own struct resource for it here. And, of course, figure out the details of
which PCI domain you're in and whether you need to share one struct
resource across several host bridges in the same domain.
Allocate its own resource here is ok for me, as I mentioned in previous
reply,
so do we still need to add additional info to figure out which domain own
the bus resource ?
That's up to the caller. Only the platform knows which bridges it wants to
have in the same domain. In principle, every host bridge could be in its
own domain, since each bridge is the root of a unique PCI hierarchy. But
some platforms have firmware that assumes otherwise. I have no idea what
xen assumes.
I'm not xen guy, so I don't know much about it, but because it call
pci_scan_bus_parented()
before, and in which busn_resource is always shared for different host
bridges(same domain or not),
I think add a static bus resource(0,255) should be safe, at least, it would not
introduce new risk.
Something like:
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index b1ffebe..a69e529 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -446,9 +446,15 @@ static int pcifront_scan_root(struct pcifront_device *pdev,
unsigned int domain, unsigned int bus)
{
struct pci_bus *b;
+ LIST_HEAD(resources);
struct pcifront_sd *sd = NULL;
struct pci_bus_entry *bus_entry = NULL;
int err = 0;
+ static struct resource busn_res = {
+ .start = 0,
+ .end = 255,
+ .flags = IORESOURCE_BUS,
+ };
#ifndef CONFIG_PCI_DOMAINS
if (domain != 0) {
@@ -470,17 +476,21 @@ static int pcifront_scan_root(struct pcifront_device
*pdev,
err = -ENOMEM;
goto err_out;
}
+ pci_add_resource(resources, ioport_resource);
+ pci_add_resource(resources, iomem_resource);
+ pci_add_resource(resources, busn_res);
pcifront_init_sd(sd, domain, bus, pdev);
pci_lock_rescan_remove();
- b = pci_scan_bus_parented(pdev-xdev-dev, bus,
- pcifront_bus_ops, sd);
+ b = pci_scan_root_bus(pdev-xdev-dev, bus,
+ pcifront_bus_ops, sd, resources);
if (!b) {
Bjorn, what do you think about ?
Thanks!
Yijing.
pcifront_init_sd(sd, domain, bus, pdev);
pci_lock_rescan_remove();
- b = pci_scan_bus_parented(pdev-xdev-dev, bus,
-pcifront_bus_ops, sd);
+ b = pci_scan_root_bus(pdev-xdev-dev, bus,
+pcifront_bus_ops, sd, resources);
if (!b) {
dev_err(pdev-xdev-dev,
Error creating PCI Frontend Bus!\n);
err = -ENOMEM;
pci_unlock_rescan_remove();
+ pci_free_resource_list(resources);
goto err_out;
}
@@ -488,7 +494,7 @@ static int pcifront_scan_root(struct pcifront_device
*pdev,
list_add(bus_entry-list, pdev-root_buses);
- /* pci_scan_bus_parented skips devices which do not have a have
+ /* pci_scan_root_bus skips devices which do not have a
* devfn==0. The pcifront_scan_bus enumerates all devfn. */
err = pcifront_scan_bus(pdev, domain, bus, b);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-pci in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line unsubscribe linux-pci in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
--
Thanks!
Yijing
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 00/19] xen/arm: Add ITS support
Hi Julien, On Mon, Mar 9, 2015 at 11:46 PM, Julien Grall julien.gr...@linaro.org wrote: Hello Vijay, On 09/03/2015 14:57, Vijay Kilari wrote: On Tue, Mar 3, 2015 at 5:13 PM, Julien Grall julien.gr...@linaro.org wrote: Hello Vijay, On 03/03/2015 03:55, Vijay Kilari wrote: On Mon, Mar 2, 2015 at 6:49 PM, Julien Grall julien.gr...@linaro.org wrote: On 02/03/15 12:30, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com Add ITS support for arm. Following major features are supported - GICv3 ITS support for arm64 platform - Supports only single ITS node Why only one ITS node supported? I though Cavium was using 2 ITS... I will update for 2 ITS nodes later when NUMA is supported Why do you speak about NUMA? AFAICT, there is no requirement to support NUMA for having multiple ITS... With multiple ITS support, your vITS emulation will likely heavily change. So it would be nice to have this support as soon as possible. Incremental changes (as separate patch series) would be more meaningful. I will have a look at it and if possible I will incorporate in next series It doesn't make sense to not support multiple ITS from the beginning. FWIW, your code is based on the Linux driver which support multiple ITS. So why did you drop this support? Anyway, I'm pretty sure you will have to rework the vITS with the support of multiple ITS... Having a separate patch means more work for all of us: more series and more review. The changes that I envisage for supporting Multiple ITS is - Generate as many number of ITS dt nodes for Dom0 that host DT contains. - For DomU always generate only one ITS node - vITS will register MMIO handlers for all physical ITS of Dom0, but vITS will only have one VITS structure per domain. The limitation with this approach is that all vITS requests are serialized even though there are more than one physical ITS. But this approach makes implementation simple. - The right Physical ITS node command queue is chosen based on device id in the ITS commands. However few commands like MAPC, SYNC INVALL does not have device id. These commands needs special handling by either consume in vITS or send based on Collection and Target address mapped. Regards Vijay ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.6 Development Update (two months reminder)
On 3/12/2015 at 06:21 PM, in message
e1yw0fy-0002p7...@ukmail1.uk.xensource.com, wei.l...@citrix.com wrote:
Hi all
We are now two months into 4.6 development window. This is an email to keep
track of all the patch series I gathered. It is by no means complete and /
or
acurate. Feel free to reply this email with new projects or correct my
misunderstanding.
= Timeline =
We are planning on a 9-month release cycle, but we could also release a bit
earlier if everything goes well (no blocker, no critical bug).
* Development start: 6 Jan 2015
=== We are here ===
* Feature Freeze: 10 Jul 2015
* RCs: TBD
* Release Date: 9 Oct 2015 (could release earlier)
The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.
Bug-fixes, if Acked-by by maintainer, can go anytime before the First
RC. Later on we will need to figure out the risk of regression/reward
to eliminate the possiblity of a bug introducing another bug.
= Prognosis =
The states are: none - fair - ok - good - done
none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs
= Bug Fixes =
Bug fixes can be checked in without a freeze exception throughout the
freeze, unless the maintainer thinks they are particularly high
risk. In later RC's, we may even begin rejecting bug fixes if the
broken functionality is small and the risk to other functionality is
high.
Document changes can go in anytime if the maintainer is OK with it.
These are guidelines and principles to give you an idea where we're coming
from; if you think there's a good reason why making an exception for you
will
help us make Xen better than not doing so, feel free to make your case.
== Linux ==
* PV domain with memory 512GB (fair)
- Juergen Gross
* Block driver multiqueue support (fair)
RFC posted
- Bob Liu
* Block driver multi-page ring support (fair)
- Bob Liu
* Preemptable privcmd hypercalls (good)
v5 posted
- David Vrabel
* Linux ARM - Device assigment (PCI) (none)
Depends on Xen pieces which are on the Xen 4.6 list.
- Manish Jaggi
* pvUSB in Linux (fronted and backend) (Fair)
- Juergen Gross
* VPMU - 'perf' support in Linux (ok)
Depends on Xen patches
Acked by David Vrabel
- Boris Ostrovsky
* vNUMA in Linux (ok)
v6 posted
git://gitorious.org/vnuma/linux_vnuma.git
- Elena Ufimtseva
* vsyscall in Linux (fair)
- Konrad Rzeszutek Wilk
* COLO Agent in Linux (fair)
- Gui Jianfeng
- Yang Hongyang
- Dong, Eddie
* ARM64 - support 64K guest (none)
- Julien Grall
== OpenStack ==
* setup CI loop for OpenStack (fair)
- Anthony Perard
== FreeBSD ==
* PVH FreeBSD dom0 (ok)
FreeBSD 11 goal. Toolstack side done in Xen 4.5
- Roger Pau Monné
== Other OSes (MiniOS, QNX) ==
* PV drivers for automotive kernels (fair)
- Artem Mygaiev
* mini-os: xenbus changes for rump kernels (ok)
git://xenbits.xen.org/people/iwj/rumpuser-xen.git
branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1
v2 posted
- Ian Jackson
== GRUB2 ==
* GRUB2 multiboot2 (fair)
- Daniel Kiper
== OSSTEST ==
* OSSTest: studom test case (none)
- Wei Liu
* OSSTest: libvirt migration (fair)
- Wei Liu
* OSSTest: upgrade to Debian Jessie (none)
- Wei Liu
* OSSTest: performance test (fair)
- Dario Faggioli
* CPU pool test case (fair)
- Dario Faggioli
* Add a FreeBSD host (fair)
- Roger Pau Monné
* Nested virt test case (fair)
- Robert Hu
== QEMU ==
* Linux-based QEMU upstream stub domain (fair)
RFC posted
- Eric Shelton
* Using qemu-upstream in a stubdomain (none)
Will use rump kernels.
- Wei Liu
* AMD Radeon PCI GPU passthrough (none)
Focusing on Xen 4.2 and qemu-traditional
- Kelly Zytaruk
* Intel IGD PCI GPU passthrough (ok)
v5 posted
- Chen, Tiejun
== Up for grabs ==
* save/restore/migrate PVHVM guest with 32 vcpus
http://lists.xen.org/archives/html/xen-devel/2015-02/msg00244.html
* PoD fixes
if you boot with memory = maxmem we have a size estimation bug
* TLB flushing without locks in Xen
* xl does not support specifying virtual function for passthrough device
http://bugs.xenproject.org/xen/bug/22
* PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with
PCI/GPU passthrough
http://bugs.xenproject.org/xen/bug/28
* libx{c,l} error handling cleanup
* Adding missing 'xend' features in libxl
Need to define what is missing
* xl list -l doesn't contain tty console
Re: [Xen-devel] Xen 4.6 Development Update (two months reminder)
On Thu, 2015-03-12 at 10:21 +, wei.l...@citrix.com wrote: * Repurpose SEDF Scheduler for Real-time (fair) RFC patch posted (v2) - Joshua Whitehead, Robert VanVossen This was superceded by the RTDS stuff, wasn't it? === Hypervisor ARM === * Add support for Xilinx ZynqMP SoC (fair) - Edgar E. Iglesias Done * Add support for Huawei hip04-d01 platform (ok) - Frediano Ziglio Done * Thunder X platform support (ok) - Vijay Kilari Done, with one exception * ARM - SMMU resync of Linux's one (ok) - Julien Grall Done * Rearrange and cleanup installation destination directories (/var - var/lib/xen) (fair) - Daniel Kiper What is this? I've never heard about it. My local tree has these after make dist: dist/install/var dist/install/var/lib dist/install/var/lib/xen dist/install/var/lib/xenstored dist/install/var/lib/xen/xenpaging dist/install/var/log dist/install/var/log/xen dist/install/var/xen dist/install/var/xen/dump which all seems proper and correct to me. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 4/7] xen/arm: Data abort exception (R/W) mem_events.
On Thu, 2015-03-12 at 16:13 +0100, Tamas K Lengyel wrote:
and this function is nearly identical to the x86 one too.
Nearly, but not completely. IMHO consolidation may be possible on some
of these bits, but I'm not sure if it would make it any easier to
follow when the code jumps back and forth between common and arch
specific parts.
It's worse to have two similar bits of code which are supposed to do the
same thing but can get out of sync or behave subtly different.
Anyway, I'm happy for consolidation to come later.
Would be nice not to have this static const thing twice
in .rodata.
What do you mean twice? One is converting from p2m_access to
XENMEM_access, the other is XENMEM_access to p2m_access.
My mistake, they were similar but not similar enough.
+#define ACCESS(ac) [p2m_access_##ac] = XENMEM_access_##ac
+ACCESS(n),
+ACCESS(r),
+ACCESS(w),
+ACCESS(rw),
+ACCESS(x),
+ACCESS(rx),
+ACCESS(wx),
+ACCESS(rwx),
+ACCESS(rx2rw),
+ACCESS(n2rwx),
+#undef ACCESS
+};
+
+/* If no setting was ever set, just return rwx. */
+if ( !p2m-mem_access_enabled )
+{
+*access = XENMEM_access_rwx;
+return 0;
+}
+
+/* If request to get default access */
+if ( gpfn == ~0ull )
We should have a suitable constant for this, I think,
INVALID_MFN looks
like the one.
~0ull is specifically used by the mem_access API for this purpose. If
anywhere, in the cleanup series it might make sense to have a #define
added for it.
OK, can be done later then.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 4/7] xen/arm: Data abort exception (R/W) mem_events.
On 12/03/15 15:26, Tamas K Lengyel wrote:
On Thu, Mar 12, 2015 at 4:13 PM, Julien Grall julien.gr...@linaro.org
mailto:julien.gr...@linaro.org wrote:
Hi Tamas,
On 06/03/15 21:24, Tamas K Lengyel wrote:
+/*
+ * Preempt setting mem_access permissions as required by
XSA-89,
+ * if it's not the last iteration.
+ */
+if ( op == MEMACCESS count )
+{
+uint32_t progress = paddr_to_pfn(addr) - sgfn + 1;
+
+if ( (egfn - sgfn) progress !(progress mask)
+ hypercall_preempt_check() )
+{
+rc = progress;
+goto out;
+}
+}
+
Would it be possible to merge the memaccess prempt check with the
relinquish one?
That may require some change in the relinquish version but I think it
would be cleaner.
Well, I don't really see an obvious way how the two could be combined.
The preemption for relinquish has been chosen arbitrarily so it would be
possible to change it.
[..]
+bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const struct
npfec npfec)
+{
+int rc;
+bool_t violation;
+xenmem_access_t xma;
+mem_event_request_t *req;
+struct vcpu *v = current;
+struct p2m_domain *p2m = p2m_get_hostp2m(v-domain);
+
+/* Mem_access is not in use. */
+if ( !p2m-mem_access_enabled )
+return true;
true should be used with bool not boot_t.
+
+rc = p2m_get_mem_access(v-domain, paddr_to_pfn(gpa), xma);
+if ( rc )
+return true;
Ditto (I won't repeat for the few other place below)
There was just a discussion how there is no difference between 0/1 and
false/true other than maybe style. If one is preferred over the other,
I'm fine with either. Is this really an issue?
You are mixing 2 different types. bool/false/true are part of stdbool.h
rather than bool_t is part of asm/types.h
By mistake we mix both type in an handful of places in ARM. We should
avoid to introduce more.
FWIW, the headers stdbool.h has been introduced in order to share libelf
with the tools.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] stubdom vtpm build failure in staging
Olaf,
Could you share me this patch description? Then I can sign off:
Signed-off-by: Olaf Hering o...@aepfle.de
Signed-off-by: Quan Xu quan...@intel.com
..
(1)
-- /dev/null
+++ b/stubdom/vtpmmgr/common_types.h
@@ -0,0 +1,11 @@
+#ifndef VTPM_ODD_TYPES
+#define VTPM_ODD_TYPES 1
+typedef unsigned char BYTE;
+typedef unsigned char BOOL;
+typedef uint16_t UINT16;
+typedef uint32_t UINT32;
+typedef uint64_t UINT64;
+typedef UINT32 TPM_HANDLE;
+typedef UINT32 TPM_ALGORITHM_ID;
+#endif
[...]
(2)
Change from TPM_HANDLE to TPM2_HANDLE
Change from TPM_ALGORITHM_ID to TPM2_ALGORITHM_ID
(3)
Delete redundant TPMI_RH_HIERARCHY_AUTH and TPM_ALG_ID.
-Quan
-Original Message-
From: Olaf Hering [mailto:o...@aepfle.de]
Sent: Wednesday, February 11, 2015 11:21 PM
To: Xu, Quan
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] stubdom vtpm build failure in staging
On Wed, Jan 28, Xu, Quan wrote:
Thanks, I will check and fix it tomorrow. It is 23:12 PM Pacific time now.
Any progress?
These typedefs are duplicated in stubdom/vtpmmgr/tcg.h and supported
compilers do not cope with current staging:
# for i in `grep -w typedef stubdom/vtpmmgr/tcg.h | sed -n '/;/{s@^.*
@@;s@;@@p}'` # do
# if test -n `git grep -wn $i|grep -w typedef|grep -v
stubdom/vtpmmgr/tcg.h`
# then
# echo $i
# fi
# done
BYTE
BOOL
UINT16
UINT32
UINT64
TPM_HANDLE
TPM_ALGORITHM_ID
TPMI_RH_HIERARCHY_AUTH and TPM_ALG_ID are defined twice in the same
file.
This change works for me:
---
stubdom/vtpmmgr/odd_types.h | 11 +++
stubdom/vtpmmgr/tcg.h| 9 +
stubdom/vtpmmgr/tpm2_types.h | 11 +--
3 files changed, 13 insertions(+), 18 deletions(-) create mode 100644
stubdom/vtpmmgr/odd_types.h
diff --git a/stubdom/vtpmmgr/odd_types.h b/stubdom/vtpmmgr/odd_types.h
new file mode 100644 index 000..d72da9b
--- /dev/null
+++ b/stubdom/vtpmmgr/odd_types.h
@@ -0,0 +1,11 @@
+#ifndef VTPM_ODD_TYPES
+#define VTPM_ODD_TYPES 1
+typedef unsigned char BYTE;
+typedef unsigned char BOOL;
+typedef uint16_t UINT16;
+typedef uint32_t UINT32;
+typedef uint64_t UINT64;
+typedef UINT32 TPM_HANDLE;
+typedef UINT32 TPM_ALGORITHM_ID;
+#endif
+
diff --git a/stubdom/vtpmmgr/tcg.h b/stubdom/vtpmmgr/tcg.h index
7321ec6..cac1bbc 100644
--- a/stubdom/vtpmmgr/tcg.h
+++ b/stubdom/vtpmmgr/tcg.h
@@ -401,16 +401,10 @@
// *** TYPEDEFS
* -typedef unsigned char BYTE;
-typedef unsigned char BOOL; -typedef uint16_t UINT16; -typedef uint32_t
UINT32; -typedef uint64_t UINT64;
-
+#include odd_types.h
typedef UINT32 TPM_RESULT;
typedef UINT32 TPM_PCRINDEX;
typedef UINT32 TPM_DIRINDEX;
-typedef UINT32 TPM_HANDLE;
typedef TPM_HANDLE TPM_AUTHHANDLE;
typedef TPM_HANDLE TCPA_HASHHANDLE;
typedef TPM_HANDLE TCPA_HMACHANDLE;
@@ -422,7 +416,6 @@ typedef UINT32 TPM_COMMAND_CODE; typedef
UINT16 TPM_PROTOCOL_ID; typedef BYTE TPM_AUTH_DATA_USAGE;
typedef UINT16 TPM_ENTITY_TYPE; -typedef UINT32 TPM_ALGORITHM_ID;
typedef UINT16 TPM_KEY_USAGE; typedef UINT16 TPM_STARTUP_TYPE;
typedef UINT32 TPM_CAPABILITY_AREA; diff --git
a/stubdom/vtpmmgr/tpm2_types.h b/stubdom/vtpmmgr/tpm2_types.h index
ac2830d..63564cd 100644
--- a/stubdom/vtpmmgr/tpm2_types.h
+++ b/stubdom/vtpmmgr/tpm2_types.h
@@ -83,12 +83,8 @@
#defineMAX_ECC_KEY_BYTES((MAX_ECC_KEY_BITS + 7) / 8)
-typedef unsigned char BYTE;
-typedef unsigned char BOOL;
+#include odd_types.h
typedef uint8_t UINT8;
-typedef uint16_t UINT16;
-typedef uint32_t UINT32;
-typedef uint64_t UINT64;
// TPM2 command code
@@ -216,7 +212,6 @@ typedef UINT16 TPM_ST;
// TPM Handle types
-typedef UINT32 TPM_HANDLE;
typedef UINT8 TPM_HT;
@@ -233,7 +228,6 @@ typedef UINT32 TPM_RH;
#defineTPM_RH_LAST (TPM_RH)(0x400C)
// Table 4 -- DocumentationClarity Types I/O
-typedef UINT32TPM_ALGORITHM_ID;
typedef UINT32TPM_MODIFIER_INDICATOR;
typedef UINT32TPM_SESSION_OFFSET;
typedef UINT16TPM_KEY_SIZE;
@@ -261,8 +255,6 @@ typedef BYTE TPMA_LOCALITY; // Table 37 --
TPMI_YES_NO Type I/O typedef BYTE TPMI_YES_NO;
-typedef TPM_HANDLE TPMI_RH_HIERARCHY_AUTH;
-
// Table 38 -- TPMI_DH_OBJECT Type I/O typedef TPM_HANDLE
TPMI_DH_OBJECT;
@@ -304,7 +296,6 @@ typedef TPM_HANDLE TPMI_RH_LOCKOUT;
// Table 7 -- TPM_ALG_ID
typedef UINT16 TPM_ALG_ID;
-typedef UINT16 TPM_ALG_ID;
#defineTPM2_ALG_ERROR (TPM_ALG_ID)(0x) // a: ; D:
#defineTPM2_ALG_FIRST (TPM_ALG_ID)(0x0001) // a: ; D:
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
Hi Ian, On 12/03/15 15:27, Ian Campbell wrote: Currently, check_type_get_page emulate only the check for 2). So you may end up to allow Xen writing in read-only mapping (from the Stage 1 POV). This was XSA-98. XSA-98 was purely about stage-2 permissions (e.g. read-only grants). The fact that the resulting patch also checks stage-1 permissions is not a security property AFAICT. XSA-98 was for both... Without checking stage-1 permission a userspace which can issue an hypercall may be able to write into read-only kernel space. Whoops. Though it doesn't every possibility... Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 3/7] xen/arm: Allow hypervisor access to mem_access protected pages
On Thu, 2015-03-12 at 15:40 +, Julien Grall wrote: Hi Ian, On 12/03/15 15:27, Ian Campbell wrote: Currently, check_type_get_page emulate only the check for 2). So you may end up to allow Xen writing in read-only mapping (from the Stage 1 POV). This was XSA-98. XSA-98 was purely about stage-2 permissions (e.g. read-only grants). The fact that the resulting patch also checks stage-1 permissions is not a security property AFAICT. XSA-98 was for both... Without checking stage-1 permission a userspace which can issue an hypercall may be able to write into read-only kernel space. Whoops. XSA-98 doesn't make any mention of this particular attack and talks solely about guests writing to memory they shouldn't, not processes. A userspace which can issue a hypercall is already root and has lots of ways to rewrite kernel memory (starting with /dev/mem). Anyway, enough splitting hairs: it probably is worth retaining this behaviour since it seems pretty simple, just make gva_to_ipa_par take the same flags as gva_to_ma_par and use it in the same way. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 3/3] docs : documentation for the code
On 12/03/15 14:59, Uma Sharma wrote: This patch inserts boot paramter documentation in xen-command-line.markdown. Signed-off-by: Uma Sharma uma.sharma...@gmail.com This change should be in the same patch which introduced the option. ~Andrew --- docs/misc/xen-command-line.markdown | 7 +++ 1 file changed, 7 insertions(+) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 63871cb..fec18a1 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -460,6 +460,13 @@ combination with the `low_crashinfo` command line option. ### credit2\_load\_window\_shift `= integer` +### credit2\_runqueue + `= core | socket` + + Default: `credit2_runqueue=core` + +Choose the credit2 runqueue. + ### dbgp `= ehci[ integer | @pcibus:slot.func ]` ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] libxl: add support for vscsi
On Wed, Mar 11, Ian Campbell wrote:
On Fri, 2015-03-06 at 10:45 +0100, Olaf Hering wrote:
+int libxl_device_vscsi_parse_pdev(libxl__gc *gc, char *pdev, unsigned int
*hst,
+unsigned int *chn, unsigned int *tgt,
+unsigned int *lun)
+{
+
+return ERROR_NOPARAVIRT;
That's a rather odd error code to use here.
(also, unnecessary blank line)
What error should be returned?
Looks like this function can be moved to xlu. Should I introduce a
libxlu_$(OS).c or just use #ifdef in libxlu_vscsi.c?
+libxl_vscsi_hctl = Struct(vscsi_hctl, [
+(hst, uint32),
+(chn, uint32),
+(tgt, uint32),
+(lun, uint32),
+])
+
+libxl_vscsi_dev = Struct(vscsi_dev, [
+(vscsi_dev_id, libxl_devid),
+(remove, bool),
+(p_devname,string),
+(pdev_type,libxl_vscsi_pdev_type),
+(pdev, libxl_vscsi_hctl),
+(vdev, libxl_vscsi_hctl),
Are these last two valid for LIBXL_VSCSI_PDEV_TYPE != HCTL?
At least for vdev, which is always in HCTL format.
pdev is kind of orphan in case of LIBXL_VSCSI_PDEV_TYPE_WWN. The code
records pdev.lun somewhere, just in case. But in the end the LUN is
already part of the cfg string so nothing needs to make use of pdev
anymore.
+])
+
+libxl_device_vscsi = Struct(device_vscsi, [
+(backend_domid,libxl_domid),
+(devid,libxl_devid),
+(v_hst,uint32),
+(vscsi_devs, Array(libxl_vscsi_dev, num_vscsi_devs)),
+(feature_host, bool),
What is this feature thing? What does !host imply?
This enables raw SCSI command passthrough in xenlinux. If the flag is
off then each command is checked. The check allows many commands to
passthrough, one command needs emulation and unhandled commands are
rejected. The flag is a noop in pvops because it doesnt look at such
flag. I was told its not required, dont know the details.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 4/7] xen/arm: Data abort exception (R/W) mem_events.
On 12/03/15 15:19, Tamas K Lengyel wrote:
out:
+if ( flush )
+{
+flush_tlb_domain(d);
+iommu_iotlb_flush(d, sgfn, egfn - sgfn);
+}
Is moving the flush out of the loop an independent bug fix? If
so please
do in a separate commit with a rationale in the commit log. If it is
somehow related to the changes here then please mention it in this
commit log, since it's a bit subtle.
Right, it's not a bugfix and not required to be outside the loop, I
think I just moved it because it made sense to me to flush it only
once instead at every iteration. I'll place it back.
Sorry, the flush wasn't actually part of the loop to begin with. I just
moved it under the label out so that the TLB gets flushed when the
memaccess setting hypercall gets preempted. I will just set a separate
label for it before out so that the existing behavior is preserved but
the tlb is still flushed when memaccess is preempted.
Even though today it's only require for memaccess, the code move would
benefit all others caller later. Mainly if we decide to support
preemption later...
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 00/13] xen: Clean-up of mem_event subsystem
Hi, At 01:11 +0100 on 18 Feb (1424218290), Tamas K Lengyel wrote: This patch series aims to clean up the mem_event subsystem within Xen. The original use-case for this system was to allow external helper applications running in privileged domains to control various memory operations performed by Xen. Amongs these were paging, sharing and access control. The subsystem has since been extended to also deliver non-memory related events, namely various HVM debugging events (INT3, MTF, MOV-TO-CR, MOV-TO-MSR). The structures and naming of related functions however has not caught up to these new use-cases, thus leaving many ambiguities in the code. Furthermore, future use-cases envisioned for this subsystem include PV domains and ARM domains, thus there is a need to establish a common base to build on. In this series we convert the mem_event system to vm_event in which we clearly define the scope of information that is transmitted via the event delivery mechanism. Afterwards, we clean up the naming of the structures and related functions to more clearly be in line with their actual operations. Finally, the control of monitor events is moved to a new domctl, monitor_op. I've read through these and except for the comments I made on patch #11, it looks good to me. You can add my ack to patches 9, 10 and 12 as well as the ones I replied to separately. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V13 6/7] xen/arm: Enable mem_access on ARM
On Thu, Mar 12, 2015 at 4:19 PM, Julien Grall julien.gr...@linaro.org wrote: Hi Tamas, On 06/03/15 21:24, Tamas K Lengyel wrote: Signed-off-by: Tamas K Lengyel tkleng...@sec.in.tum.de It's strange to enable MEM_ACCESS before having the toolstack part support memaccess (even though it's tiny). Made the series a bit more easier to follow, first half hypervisor side, second half toolstack. Anyway, I guess it's fine: Reviewed-by: Julien Grall julien.gr...@linaro.org Regards, -- Julien Grall Thanks, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
