Re: [Xen-devel] NUMA_BALANCING and Xen PV guest regression in 3.20-rc0
On 19/02/15 23:09, Linus Torvalds wrote: On Thu, Feb 19, 2015 at 5:06 AM, David Vrabel david.vra...@citrix.com wrote: The NUMA_BALANCING series beginning with 5d833062139d (mm: numa: do not dereference pmd outside of the lock during NUMA hinting fault) and specifically 8a0516ed8b90 (mm: convert p[te|md]_numa users to p[te|md]_protnone_numa) breaks Xen 64-bit PV guests. Any fault on a present userspace mapping (e.g., a write to a read-only mapping) is being misinterpreted as a NUMA hinting fault and not handled correctly. All userspace programs end up continuously faulting. This is because the hypervisor sets _PAGE_GLOBAL (== _PAGE_PROTNONE) on all present userspace page table entries. That's some crazy stuff, but whatever. The patch is clearly good. Applied, Thanks. Xen PV guests do not use any hardware virtualization features. In particular they do not use nested paging. A 64-bit PV guest runs in user mode for both kernel and userspace. On kernel to user mode transitions, the hypervisor flips between two sets of page tables (the user mode tables do not contain any kernel mappings, but the kernel mode tables contain both). By setting _PAGE_GLOBAL on the userspace entries, a kernel to user transition can avoid flushing the userspace mappings from the TLB. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/6] tools/libxl: Update datacopier to support sending data only
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
From: Wen Congyang we...@cn.fujitsu.com
datacopier is to read some data and write it out. If we
have some data to send it over network, we cannot use
datacopier. Update it to support this case.
Please can you clarify this commit message. Questions I'm left with
after reading it:
* What is the relevance of send it over network here, why does
it matter what the output fd is? Or is this something to do with
the lack of an input fd (in which case where does the incoming
data come from?)
* Why can datacopier not currently be used in this case, what
actually goes wrong?
* What is the nature of the update which makes it work? (possibly
becomes obvious after the previous answers)
Thanks.
Ian.
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_aoutils.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index b10d2e1..3e0c0ae 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -309,9 +309,11 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
libxl__datacopier_init(dc);
-rc = libxl__ev_fd_register(gc, dc-toread, datacopier_readable,
- dc-readfd, POLLIN);
-if (rc) goto out;
+if (dc-readfd = 0) {
+rc = libxl__ev_fd_register(gc, dc-toread, datacopier_readable,
+ dc-readfd, POLLIN);
+if (rc) goto out;
+}
rc = libxl__ev_fd_register(gc, dc-towrite, datacopier_writable,
dc-writefd, POLLOUT);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/15] xen/arm: Bug fixes for the vGIC
On Fri, 2015-02-20 at 15:56 +0530, Vijay Kilari wrote:
On Fri, Feb 20, 2015 at 3:44 PM, Ian Campbell ian.campb...@citrix.com wrote:
On Thu, 2015-02-19 at 18:01 +, Julien Grall wrote:
Based on the discussion, what about waiting until someone complain about
GICv3 support on Xen 4.5?
That sounds like a reasonable compromise.
If Xen 4.5 claims GICv3 support, then it is better to backport vgic-v3
patches.
May be ThunderX is the only platform out there with GICv3 support.
At some point of time we might require ThunderX support on 4.5 release.
If you are going to backport only on-demand then it should be for now.
Is ThunderX going to be available to purchase before the 4.6 release in
the summer?
My potential backports list now contains:
xen/arm: Bug fixes for the vGIC
- 15 patch series, many of which are tagged for backport.
- Julien: The list of GICv2 patches candidate for backporting are: #10,
#11,
#12, #13.
fed3569 xen/arm: vgic-v2: Correctly set GICD_TYPER.CPUNumber
1fefa55 xen/arm: vgic-v2: Correctly handle RAZ/WI registers
26ea82f xen/arm: vgic-v2: Take the lock when writing into GICD_CTLR
10af92d xen/arm: vgic-v2: GICD_I{S, C}PENDR* are only word-accessible
- Julien: Based on the discussion, what about waiting until someone
complain about
GICv3 support on Xen 4.5?
8206d05 xen/arm: vgic-v3: Correctly set GICD_TYPER.IDbits
834551b xen/arm: vgic-v3: Correctly set GICD_TYPER.CPUNumber
5e6958a xen/arm: vgic-v3: Correctly handle RAZ/WI registers
cfef895 xen/arm: vgic-v3: Correctly implement read into GICR_NSACR
acf65e5 xen/arm: vgic-v3: Emulate correctly the re-distributor
- Not tagged for backport:
8d91d64 xen/arm: vgic-v3: Correctly handle GICD_CTLR
4636e9f xen/arm: vgic-v3: Set stride during domain initialization
196f4ef xen/arm: vgic-v3: Use a struct to describe contiguous rdist regions
b697071 xen/arm: vgic-v3: Clarify which distributor is used in the common
emulation
a41d809 xen/arm: vgic: Drop iactive, ipend, pendsgi field
98e7c60 xen/arm: gic-v3: Update some comments in the code
Does that tally with what you intended?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] NUMA_BALANCING and Xen PV guest regression in 3.20-rc0
On 20/02/15 01:49, Linus Torvalds wrote: On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov kir...@shutemov.name wrote: I'm feeling I miss very basic background on how Xen works, but why does it set _PAGE_GLOBAL on userspace entries? It sounds strange to me. It is definitely strange. I'm guessing that it's some ancient Xen hack for the early Intel virtualization that used to have absolutely horrendous vmenter/exit costs, including very much the TLB overhead. \ These days, Intel has address space identifiers, and doesn't flush the whole TLB on VM entry/exit, so it's probably pointless to play games with the global bit. It was introduced in 2006, but has nothing to do with VT-x http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=6f562e72cdc4b7e1519e23be75f812aebbf41db3 As long mode drops segment limit checking, the only way to protect a 64bit PV kernel from its userspace (both of which run in ring3 on user pages) is to maintain two sets of pagetables and switch between them on guest kernel/user context switches. The user set lack kernel mappings. I can't comment about the performance impact of the patch (way before my time), but the justification was to try and reduce the overhead of guest context switches. I get the feeling that a lot of Xen stuff is that kind of legacy hacks that should just be cleaned up, but nobody has the energy or the interest. Time, mainly. There certainly are areas which should be up for re-evaluation, given 9 years of change in hardware. There was the whole odd crazy SHARED_KERNEL_PMD hackery too. SHARED_KERNEL_PMD is an artefact of Xen living in the same virtual address space as a PV guest, and needing to maintain linear mappings. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/6] tools/libxl: Update datacopier to support sending data only
On 20/02/15 10:27, Ian Campbell wrote: On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote: From: Wen Congyang we...@cn.fujitsu.com datacopier is to read some data and write it out. If we have some data to send it over network, we cannot use datacopier. Update it to support this case. Please can you clarify this commit message. Questions I'm left with after reading it: * What is the relevance of send it over network here, why does it matter what the output fd is? Or is this something to do with the lack of an input fd (in which case where does the incoming data come from?) * Why can datacopier not currently be used in this case, what actually goes wrong? * What is the nature of the update which makes it work? (possibly becomes obvious after the previous answers) Thanks. This is one of several patches which didn't get included as part of the libxl remus series in the end (i.e. git rebase didn't drop this hunk out), but is still needed for migration v2. Currently, the datacopier only functions when copying from readfd to writefd until EOF is hit on readfd. The datacopier infrastructure already has prefixdata which will be inserted into writefd ahead of the content of readfd, but lacks the ability to simply copy from a local buffer to writefd. This patch makes the lack of readfd non-fatal, which allows the rest of the existing infrastructure function as a proper copy from local buffer. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI
The platform APIs are enhanced to provide support for parsing pci device
tree nodes and storing the config-space address which is later used for
pci_read/pci_write config calls.
---
xen/arch/arm/platform.c| 27 +++
xen/include/asm-arm/platform.h | 18 +-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
index cb4cda8..25f07d2 100644
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -128,6 +128,33 @@ int __init platform_smp_init(void)
}
#endif
+int platform_pci_dt_node_init(struct dt_device_node *node, const void *data)
+{
+if(platform-pci_dt_node_init)
+return platform-pci_dt_node_init(node, data);
+return -1;
+}
+
+int platform_pci_write_config(unsigned int seg, unsigned int bus,
+unsigned int dev, unsigned int func,
+int reg, int size, uint32_t val)
+{
+if(platform-pci_write_config)
+return platform-pci_write_config(seg, bus, dev, func, reg, size, val);
+
+return -1;
+}
+
+int platform_pci_read_config(unsigned int seg, unsigned int bus,
+unsigned int dev, unsigned int func,
+int reg, int size, uint32_t *val)
+{
+if(platform-pci_read_config)
+return platform-pci_read_config(seg, bus, dev, func, reg, size, val);
+
+return -1;
+}
+
void platform_reset(void)
{
if ( platform platform-reset )
diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm-arm/platform.h
index eefaca6..da3cc63 100644
--- a/xen/include/asm-arm/platform.h
+++ b/xen/include/asm-arm/platform.h
@@ -26,6 +26,16 @@ struct platform_desc {
void (*reset)(void);
/* Platform power-off */
void (*poweroff)(void);
+/* PCI callback when a pci device tree node is found */
+int (*pci_dt_node_init)(struct dt_device_node *node, const void *data);
+/* PCI configspace read and write */
+int (*pci_read_config)(unsigned int seg, unsigned int bus,
+unsigned int dev, unsigned int func,
+int reg, int size, uint32_t *val);
+
+int (*pci_write_config)(unsigned int seg, unsigned int bus,
+unsigned int dev, unsigned int func,
+int reg, int size, uint32_t val);
/*
* Platform quirks
* Defined has a function because a platform can support multiple
@@ -73,7 +83,13 @@ bool_t platform_has_quirk(uint32_t quirk);
bool_t platform_device_is_blacklisted(const struct dt_device_node *node);
unsigned int platform_dom0_evtchn_ppi(void);
void platform_dom0_gnttab(paddr_t *start, paddr_t *size);
-
+int platform_pci_dt_node_init(struct dt_device_node *node, const void *data);
+int platform_pci_write_config(unsigned int seg, unsigned int bus,
+unsigned int dev, unsigned int func,
+int reg, int size, uint32_t val);
+int platform_pci_read_config(unsigned int seg, unsigned int bus,
+unsigned int dev, unsigned int func,
+int reg, int size, uint32_t *val);
#define PLATFORM_START(_name, _namestr) \
static const struct platform_desc __plat_desc_##_name __used \
__attribute__((__section__(.arch.info))) = { \
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC] [PATCH 3/3] XEN ARM PCI support
This patch adds support for pci in xen arm. Following features are
added
a) pci device tree node is parsed and platform callback is invoked
For thunderX the callback stores the reg property, which is later
used in generating address based on the s:b:d.f
b) ABI followed is segment no is mapped to the order of pci nodes in
the xen device tree.
---
xen/arch/arm/Makefile | 1 +
xen/arch/arm/pci.c| 111 ++
xen/arch/arm/setup.c | 3 +-
xen/drivers/passthrough/pci.c | 28 ---
xen/include/asm-arm/device.h | 1 +
xen/include/asm-arm/domain.h | 3 ++
xen/include/asm-arm/pci.h | 25 --
7 files changed, 159 insertions(+), 13 deletions(-)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 41aba2e..41d0eab 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -38,6 +38,7 @@ obj-y += device.o
obj-y += decode.o
obj-y += processor.o
obj-y += smc.o
+obj-$(HAS_PCI) += pci.o
#obj-bin-y += o
diff --git a/xen/arch/arm/pci.c b/xen/arch/arm/pci.c
new file mode 100644
index 000..9877726
--- /dev/null
+++ b/xen/arch/arm/pci.c
@@ -0,0 +1,111 @@
+/*
+ * Architecture-dependent PCI access functions
+ *
+ * Manish Jaggi manish.ja...@caviumnetworks.com
+ * Copyright (c) 2015 Cavium Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include xen/pci.h
+#include asm/device.h
+#include asm/io.h
+#include xen/mm.h
+#include xen/vmap.h
+#include asm/pci.h
+#include asm/platform.h
+
+static int __init pci_dt_node_init(struct dt_device_node *node, const void
*data)
+{
+return platform_pci_dt_node_init(node, data);
+}
+
+void pci_init(void)
+{
+int rc;
+struct dt_device_node *node;
+
+//Enumerate the PCI nodes in device tree
+dt_for_each_device_node( dt_host, node )
+{
+if ( !dt_device_type_is_equal(node, pci) )
+continue;
+
+rc = device_init(node, DEVICE_PCI, NULL);
+if ( !rc )
+break;
+}
+}
+
+uint8_t pci_conf_read8(unsigned int seg, unsigned int bus, unsigned int dev,
+ unsigned int func, unsigned int reg)
+{
+unsigned int val;
+
+platform_pci_read_config(seg, bus, dev, func, reg, 1, val);
+return val;
+}
+
+uint16_t pci_conf_read16(unsigned int seg, unsigned int bus, unsigned int dev,
+ unsigned int func, unsigned int reg)
+{
+unsigned int val;
+
+platform_pci_read_config(seg, bus, dev, func, reg, 2, val);
+return val;
+}
+
+uint32_t pci_conf_read32(unsigned int seg, unsigned int bus, unsigned int dev,
+ unsigned int func, unsigned int reg)
+{
+unsigned int val;
+
+platform_pci_read_config(seg, bus, dev, func, reg, 4, val);
+return val;
+}
+
+void pci_conf_write8(unsigned int seg, unsigned int bus, unsigned int dev,
+ unsigned int func, unsigned int reg, uint8_t data)
+{
+platform_pci_write_config(seg, bus, dev, func, reg, 1, data);
+}
+
+void pci_conf_write16(unsigned int seg, unsigned int bus, unsigned int dev,
+ unsigned int func, unsigned int reg, uint16_t data)
+{
+platform_pci_write_config(seg, bus, dev, func, reg, 2, data);
+}
+
+void pci_conf_write32(unsigned int seg, unsigned int bus, unsigned int dev,
+ unsigned int func, unsigned int reg, uint32_t data)
+{
+platform_pci_write_config(seg, bus, dev, func, reg, 4, data);
+}
+
+static const char * const pci_dt_compat[] __initconst =
+{
+cavium,thunder-pcie,
+NULL
+};
+
+DT_DEVICE_START(pci, PCI, DEVICE_PCI)
+.compatible =pci_dt_compat,
+.init = pci_dt_node_init,
+DT_DEVICE_END
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: BSD
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 43b626b..56119ff 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -769,7 +769,7 @@ void __init start_xen(unsigned long boot_phys_offset,
tasklet_subsys_init();
-
+pci_init();
xsm_dt_init();
init_maintenance_interrupt();
@@ -783,6 +783,7 @@ void __init start_xen(unsigned long boot_phys_offset,
arch_init_memory();
+pt_pci_init();
local_irq_enable();
local_abort_enable();
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index b93e7d8..aefaa3c 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -22,8 +22,11 @@
#include xen/prefetch.h
[Xen-devel] [PATCH v2 6/7] build system: stubdom targets now depends on mini-os target
Provide mini-os url and revision in Config.mk
Introduce Makefile.mini-os which contains mini-os specific targets.
Target mini-os-dir clones mini-os tree from upstream.
Make stubdom targets depend on mini-os-dir target. Make
subtree-force-update{,-all} depend on mini-os-dir-force-update.
Also make mktarball script generate mini-os archive.
Original mini-os directory is renamed to mini-os-intree to help reduce
patch length. That directory will be deleted in a separate patch.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
Changes in v2:
1. Use hash in Config.mk.
---
.gitignore| 6 ++
Config.mk | 6 ++
Makefile | 15 +--
Makefile.mini-os | 15 +++
[ output trimmed ]
stubdom/Makefile | 4
tools/misc/mktarball | 4 +++-
227 files changed, 39 insertions(+), 11 deletions(-)
create mode 100644 Makefile.mini-os
[ rename output trimmed ]
diff --git a/.gitignore b/.gitignore
index cdbdca7..4979018 100644
--- a/.gitignore
+++ b/.gitignore
@@ -46,10 +46,8 @@ docs/man1/
docs/man5/
docs/pdf/
docs/txt/
-extras/mini-os/include/mini-os
-extras/mini-os/include/x86/mini-os
-extras/mini-os/include/list.h
-extras/mini-os/mini-os*
+extras/mini-os
+extras/mini-os-remote
install/*
stubdom/autom4te.cache/
stubdom/binutils-*
diff --git a/Config.mk b/Config.mk
index d12ad91..f1d4c0a 100644
--- a/Config.mk
+++ b/Config.mk
@@ -245,14 +245,20 @@ OVMF_UPSTREAM_URL ?=
http://xenbits.xen.org/git-http/ovmf.git
QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-upstream-unstable.git
QEMU_TRADITIONAL_URL ?= http://xenbits.xen.org/git-http/qemu-xen-unstable.git
SEABIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/seabios.git
+MINIOS_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/mini-os.git
else
OVMF_UPSTREAM_URL ?= git://xenbits.xen.org/ovmf.git
QEMU_UPSTREAM_URL ?= git://xenbits.xen.org/qemu-upstream-unstable.git
QEMU_TRADITIONAL_URL ?= git://xenbits.xen.org/qemu-xen-unstable.git
SEABIOS_UPSTREAM_URL ?= git://xenbits.xen.org/seabios.git
+MINIOS_UPSTREAM_URL ?= git://xenbits.xen.org/mini-os.git
endif
OVMF_UPSTREAM_REVISION ?= 447d264115c476142f884af0be287622cd244423
QEMU_UPSTREAM_REVISION ?= master
+MINIOS_UPSTREAM_REVISION ?= 0cc86f6747f9bba01a332f3255c48dc743e29c4d
+# Thu Jan 29 19:10:04 2015 +
+# Mini-OS: standalone build
+
SEABIOS_UPSTREAM_REVISION ?= rel-1.7.5
# Thu May 22 16:59:16 2014 -0400
# python3 fixes for vgabios and csm builds.
diff --git a/Makefile b/Makefile
index ad6f917..d4d0f74 100644
--- a/Makefile
+++ b/Makefile
@@ -17,6 +17,8 @@ TARGS_DISTCLEAN=$(patsubst %, distclean-%, $(SUBSYSTEMS))
export XEN_ROOT=$(CURDIR)
include Config.mk
+include Makefile.mini-os
+
SUBARCH := $(subst x86_32,i386,$(XEN_TARGET_ARCH))
export XEN_TARGET_ARCH SUBARCH
export DESTDIR
@@ -37,7 +39,7 @@ build-tools:
$(MAKE) -C tools build
.PHONY: build-stubdom
-build-stubdom:
+build-stubdom: mini-os-dir
$(MAKE) -C stubdom build
ifeq (x86_64,$(XEN_TARGET_ARCH))
XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub
@@ -84,7 +86,7 @@ install-tools:
$(MAKE) -C tools install
.PHONY: install-stubdom
-install-stubdom: install-tools
+install-stubdom: install-tools mini-os-dir
$(MAKE) -C stubdom install
ifeq (x86_64,$(XEN_TARGET_ARCH))
XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom install-grub
@@ -125,11 +127,11 @@ rpmball: dist
bash ./tools/misc/mkrpm $(XEN_ROOT) $$($(MAKE) -C xen xenversion
--no-print-directory)
.PHONY: subtree-force-update
-subtree-force-update:
+subtree-force-update: mini-os-dir-force-update
$(MAKE) -C tools subtree-force-update
.PHONY: subtree-force-update-all
-subtree-force-update-all:
+subtree-force-update-all: mini-os-dir-force-update
$(MAKE) -C tools subtree-force-update-all
# Make a source tarball, including qemu sub-trees.
@@ -161,7 +163,7 @@ clean-tools:
$(MAKE) -C tools clean
.PHONY: clean-stubdom
-clean-stubdom:
+clean-stubdom: mini-os-dir
$(MAKE) -C stubdom crossclean
ifeq (x86_64,$(XEN_TARGET_ARCH))
XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom crossclean
@@ -187,11 +189,12 @@ distclean-tools:
$(MAKE) -C tools distclean
.PHONY: distclean-stubdom
-distclean-stubdom:
+distclean-stubdom: mini-os-dir
$(MAKE) -C stubdom distclean
ifeq (x86_64,$(XEN_TARGET_ARCH))
XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom distclean
endif
+ rm -rf extras/mini-os extras/mini-os-remote
.PHONY: distclean-docs
distclean-docs:
diff --git a/Makefile.mini-os b/Makefile.mini-os
new file mode 100644
index 000..46b1d80
--- /dev/null
+++ b/Makefile.mini-os
@@ -0,0 +1,15 @@
+.PHONY:
[Xen-devel] [PATCH v2 4/7] git-checkout.sh: use mkdir -p
Otherwise mkdir extras/mini-os fails because extras doesn't exist. Signed-off-by: Wei Liu wei.l...@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 --- scripts/git-checkout.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/git-checkout.sh b/scripts/git-checkout.sh index 15b3ce9..20ae31f 100755 --- a/scripts/git-checkout.sh +++ b/scripts/git-checkout.sh @@ -13,7 +13,7 @@ set -e if test \! -d $DIR-remote; then rm -rf $DIR-remote $DIR-remote.tmp - mkdir $DIR-remote.tmp; rmdir $DIR-remote.tmp + mkdir -p $DIR-remote.tmp; rmdir $DIR-remote.tmp $GIT clone $TREE $DIR-remote.tmp if test $TAG ; then cd $DIR-remote.tmp -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/7] Split off mini-os to a separate tree
This is v2 of my mini-os splitting off patch series. I use following runes to split off mini-os: git filter-branch --tag-name-filter cat \ --subdirectory-filter extras/mini-os/ -- --all # There is already a tag name 4.3.0-rc2 which points to the same commit. git tag -d xen-4.3.0-rc2 # Add xen- prefix to all tags for t in `git tag`; do git tag xen-$t $t; git tag -d $t ; done git gc --aggressive The tree can be found at: git://xenbits.xen.org/people/liuw/mini-os.git master The changeset used is 0cc86f6747f9bba01a332f3255c48dc743e29c4d which is currently the HEAD of mater branch. The Xen side patches can be pulled from: git://xenbits.xen.org/people/liuw/xen.git wip.build-system-v2 Now mini-os builds on its own. I've also done some minor adjustments to stubdom's build system, so that we can properly issue make build-stubdom in Xen tree top level directory. Wei. Wei Liu (7): stubdom: fix make build Makefile: refactor build/clean/distclean targets stubdom: don't look for mini-os source file during configure git-checkout.sh: use mkdir -p Mini-OS: standalone build build system: stubdom targets now depends on mini-os target Remove in-tree mini-os directory .gitignore |7 +- Config.mk |6 + Makefile | 58 +- Makefile.mini-os | 15 + extras/mini-os/COPYING | 36 - extras/mini-os/Config.mk | 57 - extras/mini-os/Makefile| 226 --- extras/mini-os/README | 46 - extras/mini-os/app.lds | 11 - extras/mini-os/arch/arm/arm32.S| 294 extras/mini-os/arch/arm/events.c | 31 - extras/mini-os/arch/arm/hypercalls32.S | 64 - extras/mini-os/arch/arm/minios-arm32.lds | 83 -- extras/mini-os/arch/arm/mm.c | 139 -- extras/mini-os/arch/arm/panic.c| 98 -- extras/mini-os/arch/arm/sched.c| 47 - extras/mini-os/arch/arm/setup.c| 119 -- extras/mini-os/arch/arm/time.c | 136 -- extras/mini-os/arch/x86/Makefile | 31 - extras/mini-os/arch/x86/arch.mk| 22 - extras/mini-os/arch/x86/events.c | 35 - extras/mini-os/arch/x86/ioremap.c | 75 - extras/mini-os/arch/x86/iorw.c | 35 - extras/mini-os/arch/x86/minios-x86_32.lds | 74 - extras/mini-os/arch/x86/minios-x86_64.lds | 74 - extras/mini-os/arch/x86/mm.c | 957 extras/mini-os/arch/x86/sched.c| 139 -- extras/mini-os/arch/x86/setup.c| 168 --- extras/mini-os/arch/x86/time.c | 238 --- extras/mini-os/arch/x86/traps.c| 333 - extras/mini-os/arch/x86/x86_32.S | 305 extras/mini-os/arch/x86/x86_64.S | 383 - extras/mini-os/blkfront.c | 736 -- extras/mini-os/console/console.c | 164 --- extras/mini-os/console/console.h |2 - extras/mini-os/console/xenbus.c| 195 --- extras/mini-os/console/xencons_ring.c | 195 --- extras/mini-os/daytime.c | 67 - extras/mini-os/domain_config | 19 - extras/mini-os/events.c| 269 extras/mini-os/fbfront.c | 710 - extras/mini-os/gntmap.c| 250 extras/mini-os/gnttab.c| 196 --- extras/mini-os/hypervisor.c| 132 -- extras/mini-os/include/arch/cc.h | 87 -- extras/mini-os/include/arch/perf.h | 15 - extras/mini-os/include/arch/sys_arch.h | 35 - extras/mini-os/include/arm/arch_endian.h |7 - extras/mini-os/include/arm/arch_limits.h |9 - extras/mini-os/include/arm/arch_mm.h | 38 - extras/mini-os/include/arm/arch_sched.h| 19 - extras/mini-os/include/arm/arch_spinlock.h | 36 - extras/mini-os/include/arm/arm32/arch_wordsize.h |1 - extras/mini-os/include/arm/gic.h |1 - extras/mini-os/include/arm/hypercall-arm.h | 98 -- extras/mini-os/include/arm/os.h| 216 --- extras/mini-os/include/arm/traps.h | 20 - extras/mini-os/include/blkfront.h | 54 - extras/mini-os/include/byteorder.h | 36 - extras/mini-os/include/byteswap.h | 39 - extras/mini-os/include/compiler.h
[Xen-devel] [PATCH v2 2/7] Makefile: refactor build/clean/distclean targets
Factor out per-subsystem build/clean/distclean-% targets, so that we can build subsystems independently in top level directory. The motive behind this is after splitting out mini-os from Xen tree, stubdom is in effect a downstream of mini-os. I would like to have the ability to build it independently and instrument OSSTest to test it. Signed-off-by: Wei Liu wei.l...@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 --- Makefile | 49 - 1 file changed, 44 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 6e9a4c7..ad6f917 100644 --- a/Makefile +++ b/Makefile @@ -10,6 +10,9 @@ all: dist SUBSYSTEMS?=xen tools stubdom docs TARGS_DIST=$(patsubst %, dist-%, $(SUBSYSTEMS)) TARGS_INSTALL=$(patsubst %, install-%, $(SUBSYSTEMS)) +TARGS_BUILD=$(patsubst %, build-%, $(SUBSYSTEMS)) +TARGS_CLEAN=$(patsubst %, clean-%, $(SUBSYSTEMS)) +TARGS_DISTCLEAN=$(patsubst %, distclean-%, $(SUBSYSTEMS)) export XEN_ROOT=$(CURDIR) include Config.mk @@ -23,13 +26,25 @@ export DESTDIR install: $(TARGS_INSTALL) .PHONY: build -build: +build: $(TARGS_BUILD) + +.PHONY: build-xen +build-xen: $(MAKE) -C xen build + +.PHONY: build-tools +build-tools: $(MAKE) -C tools build + +.PHONY: build-stubdom +build-stubdom: $(MAKE) -C stubdom build ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub endif + +.PHONY: build-docs +build-docs: $(MAKE) -C docs build # The test target is for unit tests that can run without an installation. Of @@ -135,28 +150,52 @@ src-tarball: subtree-force-update-all bash ./tools/misc/mktarball $(XEN_ROOT) $$(git describe) .PHONY: clean -clean:: +clean: $(TARGS_CLEAN) + +.PHONY: clean-xen +clean-xen: $(MAKE) -C xen clean + +.PHONY: clean-tools +clean-tools: $(MAKE) -C tools clean + +.PHONY: clean-stubdom +clean-stubdom: $(MAKE) -C stubdom crossclean ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom crossclean endif + +.PHONY: clean-docs +clean-docs: $(MAKE) -C docs clean # clean, but blow away tarballs .PHONY: distclean -distclean: +distclean: $(TARGS_DISTCLEAN) rm -f config/Toplevel.mk + rm -rf dist + rm -rf config.log config.status config.cache autom4te.cache + +.PHONY: distclean-xen +distclean-xen: $(MAKE) -C xen distclean + +.PHONY: distclean-tools +distclean-tools: $(MAKE) -C tools distclean + +.PHONY: distclean-stubdom +distclean-stubdom: $(MAKE) -C stubdom distclean ifeq (x86_64,$(XEN_TARGET_ARCH)) XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom distclean endif + +.PHONY: distclean-docs +distclean-docs: $(MAKE) -C docs distclean - rm -rf dist - rm -rf config.log config.status config.cache autom4te.cache # Linux name for GNU distclean .PHONY: mrproper -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/7] stubdom: fix make build
Cross compiling libxc requires some symlinks to exist. Note that make -C tools/include requires running tools/configure. But at least now the error message is much better than just a file not found error. Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jakcson ian.jack...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com Acked-by: Samuel Thibault samuel.thiba...@ens-lyon.org --- stubdom/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/stubdom/Makefile b/stubdom/Makefile index 8fb885a..58ca08c 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -333,6 +333,8 @@ $(TARGETS_MINIOS): mini-os-%: .PHONY: libxc libxc: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a libxc-$(XEN_TARGET_ARCH)/libxenguest.a libxc-$(XEN_TARGET_ARCH)/libxenctrl.a: cross-zlib + $(MAKE) -C $(XEN_ROOT)/tools/include + $(MAKE) DESTDIR= -C $(MINI_OS) links CPPFLAGS=$(TARGET_CPPFLAGS) CFLAGS=$(TARGET_CFLAGS) $(MAKE) DESTDIR= CONFIG_LIBXC_MINIOS=y -C libxc-$(XEN_TARGET_ARCH) libxc-$(XEN_TARGET_ARCH)/libxenguest.a: libxc-$(XEN_TARGET_ARCH)/libxenctrl.a -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/15] xen/arm: Bug fixes for the vGIC
Hi Ian,
On 20/02/15 10:14, Ian Campbell wrote:
On Thu, 2015-02-19 at 18:01 +, Julien Grall wrote:
Based on the discussion, what about waiting until someone complain about
GICv3 support on Xen 4.5?
That sounds like a reasonable compromise.
My potential backports list now contains:
xen/arm: Bug fixes for the vGIC
- 15 patch series, many of which are tagged for backport.
- Julien: The list of GICv2 patches candidate for backporting are: #10, #11,
#12, #13.
fed3569 xen/arm: vgic-v2: Correctly set GICD_TYPER.CPUNumber
1fefa55 xen/arm: vgic-v2: Correctly handle RAZ/WI registers
26ea82f xen/arm: vgic-v2: Take the lock when writing into GICD_CTLR
10af92d xen/arm: vgic-v2: GICD_I{S, C}PENDR* are only word-accessible
- Julien: Based on the discussion, what about waiting until someone
complain about
GICv3 support on Xen 4.5?
8206d05 xen/arm: vgic-v3: Correctly set GICD_TYPER.IDbits
834551b xen/arm: vgic-v3: Correctly set GICD_TYPER.CPUNumber
5e6958a xen/arm: vgic-v3: Correctly handle RAZ/WI registers
cfef895 xen/arm: vgic-v3: Correctly implement read into GICR_NSACR
acf65e5 xen/arm: vgic-v3: Emulate correctly the re-distributor
The re-distributor patch required 196f4ef and 4636e9f.
- Not tagged for backport:
8d91d64 xen/arm: vgic-v3: Correctly handle GICD_CTLR
Hmmm... I'm not sure why I didn't request a backport for this one. It
looks like the guest may read it to see what is enabled.
4636e9f xen/arm: vgic-v3: Set stride during domain initialization
196f4ef xen/arm: vgic-v3: Use a struct to describe contiguous rdist regions
b697071 xen/arm: vgic-v3: Clarify which distributor is used in the common
emulation
a41d809 xen/arm: vgic: Drop iactive, ipend, pendsgi field
98e7c60 xen/arm: gic-v3: Update some comments in the code
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 34707: regressions - FAIL
flight 34707 linux-next real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34707/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 34622 test-amd64-amd64-xl-qemuu-ovmf-amd64 5 xen-boot fail REGR. vs. 34622 test-amd64-i386-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 34622 test-amd64-i386-xl-qemut-win7-amd64 5 xen-boot fail REGR. vs. 34622 test-amd64-i386-xl-qemut-winxpsp3 5 xen-boot fail REGR. vs. 34622 test-amd64-i386-xl-qemuu-debianhvm-amd64 5 xen-boot fail REGR. vs. 34622 test-amd64-i386-freebsd10-amd64 5 xen-boot fail REGR. vs. 34622 test-armhf-armhf-libvirt 12 guest-start.2 fail REGR. vs. 34622 test-amd64-amd64-xl 5 xen-boot fail REGR. vs. 34622 test-amd64-amd64-xl-multivcpu 5 xen-boot fail REGR. vs. 34622 test-amd64-amd64-pair 8 xen-boot/dst_host fail REGR. vs. 34622 test-amd64-amd64-pair 7 xen-boot/src_host fail REGR. vs. 34622 test-amd64-amd64-xl-qemut-debianhvm-amd64 5 xen-boot fail REGR. vs. 34622 test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 34622 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemut-rhel6hvm-intel 5 xen-boot fail like 34622 test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 34622 test-amd64-i386-qemuu-rhel6hvm-intel 5 xen-boot fail like 34622 test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 34622 test-amd64-i386-libvirt 13 guest-destroyfail blocked in 34622 test-amd64-i386-freebsd10-i386 7 freebsd-install fail like 34622 test-amd64-i386-rhel6hvm-intel 5 xen-boot fail like 34622 test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 34622 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-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-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail 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-amd64-xl-qemut-win7-amd64 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-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-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-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: linux2bf1dcda66956b7bdf8bed2842ba3345b2bf4dcc baseline version: linuxa9724125ad014decf008d782e60447c811391326 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 fail test-armhf-armhf-xl
[Xen-devel] [RFC] [PATCH 2/3] ThunderX platform support for PCI
Support added for the thunderX platfrom for reading writing config space
---
xen/arch/arm/platforms/thunderx.c | 124 ++
1 file changed, 124 insertions(+)
diff --git a/xen/arch/arm/platforms/thunderx.c
b/xen/arch/arm/platforms/thunderx.c
index 96560e1..1b6f0c3 100644
--- a/xen/arch/arm/platforms/thunderx.c
+++ b/xen/arch/arm/platforms/thunderx.c
@@ -3,6 +3,7 @@
*
* Cavium Thunder specific settings
*
+ * Manish Jaggi manish.ja...@caviumnetworks.com
* Vijaya Kumar K vijaya.ku...@caviumnetworks.com
* Copyright (c) 2015 Cavium Inc.
*
@@ -17,8 +18,48 @@
* GNU General Public License for more details.
*/
+#include asm/device.h
+#include asm/io.h
+#include xen/mm.h
+#include xen/vmap.h
+#include asm/pci.h
#include asm/platform.h
+#define THUNDER_PCIE_BUS_SHIFT 20
+#define THUNDER_PCIE_DEV_SHIFT 15
+#define THUNDER_PCIE_FUNC_SHIFT 12
+#define MAX_PCI_BRIDGE 4
+#define MAX_PCI_BARS 4
+struct pci_conf {
+paddr_t valid;
+paddr_t base;
+paddr_t size;
+void *dt_node;
+};
+struct pci_conf thunder_pci_ctrl_confs[MAX_PCI_BRIDGE];
+static int thunder_pci_dt_node_init(struct dt_device_node *node, const void
*data)
+{
+int i, res;
+struct pci_conf *pconf;
+
+for ( i = 0; i MAX_PCI_BRIDGE; i++ )
+{
+pconf = thunder_pci_ctrl_confs[i];
+if ( pconf-valid )
+continue;
+
+res = dt_device_get_address(node, 0, pconf-base, pconf-size);
+if ( res || !pconf-base )
+ panic(PCI: Cannot find a valid PCI reg address);
+
+pconf-dt_node = node;
+pconf-valid=1;
+break;
+}
+
+return 1;
+}
+
static int thunderx_specific_mapping(struct domain *d)
{
uint64_t addr, size;
@@ -43,6 +84,86 @@ static int thunderx_specific_mapping(struct domain *d)
return 0;
}
+static paddr_t thunder_pci_build_config_addr(int seg, int bus, int dev,
+ int fn, int reg)
+{
+struct pci_conf *pconf;
+paddr_t func_cfg_base;
+pconf = thunder_pci_ctrl_confs[seg];
+
+func_cfg_base = pconf-base +
+ ((bus THUNDER_PCIE_BUS_SHIFT) |
+ (dev THUNDER_PCIE_DEV_SHIFT) |
+ (fn THUNDER_PCIE_FUNC_SHIFT));
+
+return func_cfg_base;
+}
+static int thunder_pci_read_config(unsigned int seg, unsigned int bus,
+ unsigned int dev, unsigned int func,
+ int reg, int size, uint32_t *val)
+{
+paddr_t func_cfg_base;
+void __iomem *cfg_addr = NULL;
+
+func_cfg_base = thunder_pci_build_config_addr(seg, bus, dev, func, reg);
+cfg_addr = ioremap_nocache(func_cfg_base, PAGE_SIZE);
+if ( cfg_addr )
+{
+cfg_addr += (reg ~0x3);
+*val = readl(cfg_addr);
+
+if ( size == 1 )
+*val = (*val (8 * (reg 3))) 0xff;
+else if (size == 2)
+*val = (*val (8 * (reg 3))) 0x;
+iounmap(cfg_addr);
+return 0;
+}
+return -1;
+}
+
+static int thunder_pci_write_config(unsigned int seg, unsigned int bus,
+unsigned int dev, unsigned int func,
+int reg, int size, uint32_t val)
+{
+void __iomem *cfg_addr = NULL;
+uint32_t cur_val, final_val;
+paddr_t func_cfg_base;
+
+func_cfg_base = thunder_pci_build_config_addr(seg, bus, dev, func, reg);
+cfg_addr = ioremap_nocache(func_cfg_base, PAGE_SIZE);
+if ( cfg_addr )
+{
+cfg_addr += (reg ~0x3);
+
+cur_val = readl(cfg_addr);
+
+switch ( size )
+{
+case 1:
+val = ((val 0xff) (8 * (reg 3)));
+cur_val = cur_val ~(0xff (8 * (reg 3)));
+break;
+case 2:
+val = ((val 0x) (8 * (reg 3)));
+cur_val = cur_val ~(0x (8 * (reg 3)));
+break;
+case 4:
+cur_val = 0;
+break;
+default:
+goto end;
+}
+
+final_val = cur_val | val;
+writel(final_val, cfg_addr);
+iounmap(cfg_addr);
+return 0;
+}
+end:
+return -1;
+}
+
static const char * const thunderx_dt_compat[] __initconst =
{
cavium,thunder-88xx,
@@ -52,6 +173,9 @@ static const char * const thunderx_dt_compat[] __initconst =
PLATFORM_START(thunderx, THUNDERX)
.compatible = thunderx_dt_compat,
.specific_mapping = thunderx_specific_mapping,
+.pci_read_config = thunder_pci_read_config,
+.pci_write_config = thunder_pci_write_config,
+.pci_dt_node_init = thunder_pci_dt_node_init,
.dom0_gnttab_start = 0x400,
.dom0_gnttab_size = 0x2,
PLATFORM_END
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] EPT question - XENMEM_get_access_op
On Fri, Feb 20, 2015 at 4:19 PM, Jan Beulich jbeul...@suse.com wrote: On 20.02.15 at 05:47, bsinghar...@gmail.com wrote: I'm trying to use the memevent channel to extract the permission for a particular text section. I expect to see rx as the permission, instead I am seeing rwx. I have not spent a whole lot of time looking at memaccess[] and p2m-ept.c, but I am puzzled. The OS definitely has this text segment marked as COPY-ON-WRITE, I am a little confused with the permissions returned. Is there a way to get the right thing? What the guest OS specifies doesn't matter here - EPT is not OS (L1) but hypervisor (L2) paging, and hence the permissions there are controlled by the hypervisor. Of course guest memory accesses have to pass both paging levels' access checks in order to be carried out (and not fault). Thanks Jan! Is there a way for a memevents channel consumer to get access to the L1 (OS Page tables). I presume we'll need to walk the page tables, I suspect the current access_op is broken without it and may not be returning anything meaningful in most of the cases Balbir Singh ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] EPT question - XENMEM_get_access_op
On 20.02.15 at 12:44, bsinghar...@gmail.com wrote: On Fri, Feb 20, 2015 at 4:19 PM, Jan Beulich jbeul...@suse.com wrote: On 20.02.15 at 05:47, bsinghar...@gmail.com wrote: I'm trying to use the memevent channel to extract the permission for a particular text section. I expect to see rx as the permission, instead I am seeing rwx. I have not spent a whole lot of time looking at memaccess[] and p2m-ept.c, but I am puzzled. The OS definitely has this text segment marked as COPY-ON-WRITE, I am a little confused with the permissions returned. Is there a way to get the right thing? What the guest OS specifies doesn't matter here - EPT is not OS (L1) but hypervisor (L2) paging, and hence the permissions there are controlled by the hypervisor. Of course guest memory accesses have to pass both paging levels' access checks in order to be carried out (and not fault). Thanks Jan! Is there a way for a memevents channel consumer to get access to the L1 (OS Page tables). Hardly. I presume we'll need to walk the page tables, I suspect the current access_op is broken without it and may not be returning anything meaningful in most of the cases It's not broken in any way, you just seem to have wrong expectations. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] NUMA_BALANCING and Xen PV guest regression in 3.20-rc0
On 20/02/15 11:29, Kirill A. Shutemov wrote: On Fri, Feb 20, 2015 at 10:47:52AM +, Andrew Cooper wrote: On 20/02/15 01:49, Linus Torvalds wrote: On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov kir...@shutemov.name wrote: I'm feeling I miss very basic background on how Xen works, but why does it set _PAGE_GLOBAL on userspace entries? It sounds strange to me. It is definitely strange. I'm guessing that it's some ancient Xen hack for the early Intel virtualization that used to have absolutely horrendous vmenter/exit costs, including very much the TLB overhead. \ These days, Intel has address space identifiers, and doesn't flush the whole TLB on VM entry/exit, so it's probably pointless to play games with the global bit. It was introduced in 2006, but has nothing to do with VT-x http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=6f562e72cdc4b7e1519e23be75f812aebbf41db3 As long mode drops segment limit checking, the only way to protect a 64bit PV kernel from its userspace (both of which run in ring3 on user pages) is to maintain two sets of pagetables and switch between them on guest kernel/user context switches. The user set lack kernel mappings. I can't comment about the performance impact of the patch (way before my time), but the justification was to try and reduce the overhead of guest context switches. IIUC, it tries to reduce userspace-kernel switch in guest. It's still hopeless: kernel mappings are always TLB-cold, right? There is no way to avoid the kernel mappings being TLB-cold on a guest user - kernel context switch. A lot of the legacy 32bit stuff which was dropped in AMD64 were exactly the bits Xen was using to efficiently make PV guests safe. I get the feeling that a lot of Xen stuff is that kind of legacy hacks that should just be cleaned up, but nobody has the energy or the interest. Time, mainly. There certainly are areas which should be up for re-evaluation, given 9 years of change in hardware. Is Xen PV still widely used? Dom0 realistically still needs to be PV. PVH (hardware extensions but no qemu emulating a motherboard) is on the horizon but still very much experimental with open issues needing to be solved. I'm surprised that users can tolerate this kind of overhead. For modern hardware, most workloads are now better in HVM guests, but even only 5 years ago, the vmentry/vmexit overhead tended to outweigh the PV overheads. On the other hand, unikernel virtual machines can always be more efficient as PV guests, so PV is not going to die any time soon. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 0/3] Base PCI and Cavium ThunderX PCI platform support
Hello manish, On 20/02/15 11:30, Manish Jaggi wrote: This patch series adds PCI support for XEN ARM. - pci config read writes maps to xen-arm pci.c - platform support includes parsing pci device tree node and callbacks for reading writing from configuration space - placeholder code is added which is necessary for compilation Next RFC Patch set will include RFC PCI pass-through support You series is not threaded and every patches missing a Signed-off-by. Please read http://wiki.xen.org/wiki/Submitting_Xen_Project_Patches to know how to submit a patch series. Regards, manish jaggi (3): Enhance platform support for PCI ThunderX platform support for PCI XEN ARM PCI support xen/arch/arm/Makefile | 1 + xen/arch/arm/pci.c| 111 ++ xen/arch/arm/platform.c | 27 + xen/arch/arm/platforms/thunderx.c | 124 ++ xen/arch/arm/setup.c | 3 +- xen/drivers/passthrough/pci.c | 28 ++--- xen/include/asm-arm/device.h | 1 + xen/include/asm-arm/domain.h | 3 + xen/include/asm-arm/pci.h | 25 ++-- xen/include/asm-arm/platform.h| 18 +- 10 files changed, 327 insertions(+), 14 deletions(-) create mode 100644 xen/arch/arm/pci.c -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] [PATCH 3/3] XEN ARM PCI support
On 20.02.15 at 12:47, mja...@caviumnetworks.com wrote:
@@ -287,6 +289,7 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
u8 bus, u8 devfn)
if ( pci_find_cap_offset(pseg-nr, bus, PCI_SLOT(devfn),
PCI_FUNC(devfn),
PCI_CAP_ID_MSIX) )
{
+#ifndef CONFIG_ARM
struct arch_msix *msix = xzalloc(struct arch_msix);
if ( !msix )
@@ -296,6 +299,7 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
u8 bus, u8 devfn)
}
spin_lock_init(msix-table_lock);
pdev-msix = msix;
+#endif
}
list_add(pdev-alldevs_list, pseg-alldevs_list);
@@ -396,7 +400,9 @@ static void free_pdev(struct pci_seg *pseg, struct
pci_dev *pdev)
}
list_del(pdev-alldevs_list);
+#ifndef CONFIG_ARM
xfree(pdev-msix);
+#endif
xfree(pdev);
}
@@ -424,7 +430,7 @@ int __init pci_hide_device(int bus, int devfn)
return rc;
}
-
+#ifndef CONFIG_ARM
int __init pci_ro_device(int seg, int bus, int devfn)
{
struct pci_seg *pseg = alloc_pseg(seg);
@@ -452,7 +458,7 @@ int __init pci_ro_device(int seg, int bus, int devfn)
return 0;
}
-
+#endif
struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
{
struct pci_seg *pseg = get_pseg(seg);
@@ -740,7 +746,9 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
ret = iommu_remove_device(pdev);
if ( pdev-domain )
list_del(pdev-domain_list);
+#ifndef CONFIG_ARM
pci_cleanup_msi(pdev);
+#endif
free_pdev(pseg, pdev);
printk(XENLOG_DEBUG PCI remove device %04x:%02x:%02x.%u\n,
seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
@@ -750,7 +758,7 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
spin_unlock(pcidevs_lock);
return ret;
}
-
+#ifndef CONFIG_ARM
static int pci_clean_dpci_irq(struct domain *d,
struct hvm_pirq_dpci *pirq_dpci, void *arg)
{
@@ -798,11 +806,12 @@ static int pci_clean_dpci_irqs(struct domain *d)
spin_unlock(d-event_lock);
return 0;
}
-
+#endif
int pci_release_devices(struct domain *d)
{
struct pci_dev *pdev;
u8 bus, devfn;
+#ifndef CONFIG_ARM
int ret;
spin_lock(pcidevs_lock);
@@ -812,6 +821,8 @@ int pci_release_devices(struct domain *d)
spin_unlock(pcidevs_lock);
return ret;
}
+#endif
+
while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
{
bus = pdev-bus;
@@ -1184,6 +1195,7 @@ bool_t pcie_aer_get_firmware_first(const struct pci_dev
*pdev)
static int _dump_pci_devices(struct pci_seg *pseg, void *arg)
{
+#ifndef CONFIG_ARM
struct pci_dev *pdev;
struct msi_desc *msi;
@@ -1199,7 +1211,7 @@ static int _dump_pci_devices(struct pci_seg *pseg, void
*arg)
printk(%d , msi-irq);
printk(\n);
}
-
+#endif
return 0;
}
@@ -1341,7 +1353,7 @@ static int assign_device(struct domain *d, u16 seg, u8
bus, u8 devfn)
if ( !iommu_enabled || !hd-platform_ops )
return 0;
-
+#ifndef CONFIG_ARM
/* Prevent device assign if mem paging or mem sharing have been
* enabled for this domain */
if ( unlikely(!need_iommu(d)
@@ -1349,7 +1361,7 @@ static int assign_device(struct domain *d, u16 seg, u8
bus, u8 devfn)
d-mem_event-paging.ring_page ||
p2m_get_hostp2m(d)-global_logdirty)) )
return -EXDEV;
-
+#endif
if ( !spin_trylock(pcidevs_lock) )
return -ERESTART;
All of these #ifdef-s call for better abstraction. And in no case is it
acceptable to replace blank lines with #ifdef-s like you do.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/6] tools/libxl: Introduce min and max macros
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
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
---
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..a2b6fb7 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) \
+({ type __x = (x); type __y = (y); __x __y ? __x: __y; })
+#define max_t(type,x,y) \
+({ type __x = (x); type __y = (y); __x __y ? __x: __y; })
+
#define LIBXL__LOGGING_ENABLED
#ifdef LIBXL__LOGGING_ENABLED
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/15] xen/arm: Bug fixes for the vGIC
On Fri, Feb 20, 2015 at 3:44 PM, Ian Campbell ian.campb...@citrix.com wrote:
On Thu, 2015-02-19 at 18:01 +, Julien Grall wrote:
Based on the discussion, what about waiting until someone complain about
GICv3 support on Xen 4.5?
That sounds like a reasonable compromise.
If Xen 4.5 claims GICv3 support, then it is better to backport vgic-v3 patches.
May be ThunderX is the only platform out there with GICv3 support.
At some point of time we might require ThunderX support on 4.5 release.
If you are going to backport only on-demand then it should be for now.
My potential backports list now contains:
xen/arm: Bug fixes for the vGIC
- 15 patch series, many of which are tagged for backport.
- Julien: The list of GICv2 patches candidate for backporting are: #10, #11,
#12, #13.
fed3569 xen/arm: vgic-v2: Correctly set GICD_TYPER.CPUNumber
1fefa55 xen/arm: vgic-v2: Correctly handle RAZ/WI registers
26ea82f xen/arm: vgic-v2: Take the lock when writing into GICD_CTLR
10af92d xen/arm: vgic-v2: GICD_I{S, C}PENDR* are only word-accessible
- Julien: Based on the discussion, what about waiting until someone
complain about
GICv3 support on Xen 4.5?
8206d05 xen/arm: vgic-v3: Correctly set GICD_TYPER.IDbits
834551b xen/arm: vgic-v3: Correctly set GICD_TYPER.CPUNumber
5e6958a xen/arm: vgic-v3: Correctly handle RAZ/WI registers
cfef895 xen/arm: vgic-v3: Correctly implement read into GICR_NSACR
acf65e5 xen/arm: vgic-v3: Emulate correctly the re-distributor
- Not tagged for backport:
8d91d64 xen/arm: vgic-v3: Correctly handle GICD_CTLR
4636e9f xen/arm: vgic-v3: Set stride during domain initialization
196f4ef xen/arm: vgic-v3: Use a struct to describe contiguous rdist regions
b697071 xen/arm: vgic-v3: Clarify which distributor is used in the common
emulation
a41d809 xen/arm: vgic: Drop iactive, ipend, pendsgi field
98e7c60 xen/arm: gic-v3: Update some comments in the code
Does that tally with what you intended?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/6] tools/libxl: Extend datacopier to support reading into a buffer
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
From: Ross Lagerwall ross.lagerw...@citrix.com
Implement a read-only mode for libxl__datacopier. The mode is invoked
when readbuf is set and writefd is 0. On success, the callback passes
the number of bytes read.
http://lists.xen.org/archives/html/xen-devel/2014-09/msg01803.html
Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_aoutils.c | 58
+-
tools/libxl/libxl_internal.h |4 ++-
2 files changed, 38 insertions(+), 24 deletions(-)
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 037244e..a402e5c 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -134,7 +134,7 @@ static void datacopier_check_state(libxl__egc *egc,
libxl__datacopier_state *dc)
STATE_AO_GC(dc-ao);
int rc;
-if (dc-used) {
+if (dc-used !dc-readbuf) {
if (!libxl__ev_fd_isregistered(dc-towrite)) {
rc = libxl__ev_fd_register(gc, dc-towrite, datacopier_writable,
dc-writefd, POLLOUT);
@@ -147,7 +147,7 @@ static void datacopier_check_state(libxl__egc *egc,
libxl__datacopier_state *dc)
}
} else if (!libxl__ev_fd_isregistered(dc-toread) || dc-maxread == 0) {
/* we have had eof */
-datacopier_callback(egc, dc, 0, 0);
+datacopier_callback(egc, dc, 0, dc-readbuf ? dc-used : 0);
return;
} else {
/* nothing buffered, but still reading */
@@ -215,24 +215,30 @@ static void datacopier_readable(libxl__egc *egc,
libxl__ev_fd *ev,
}
assert(revents POLLIN);
for (;;) {
-while (dc-used = dc-maxsz) {
-libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(dc-bufs);
-dc-used -= rm-used;
-assert(dc-used = 0);
-LIBXL_TAILQ_REMOVE(dc-bufs, rm, entry);
-free(rm);
-}
+libxl__datacopier_buf *buf = NULL;
+int r;
+
+if (dc-readbuf) {
+r = read(ev-fd, dc-readbuf + dc-used, dc-maxread);
+} else {
+while (dc-used = dc-maxsz) {
+libxl__datacopier_buf *rm = LIBXL_TAILQ_FIRST(dc-bufs);
+dc-used -= rm-used;
+assert(dc-used = 0);
+LIBXL_TAILQ_REMOVE(dc-bufs, rm, entry);
+free(rm);
+}
-libxl__datacopier_buf *buf =
-LIBXL_TAILQ_LAST(dc-bufs, libxl__datacopier_bufs);
-if (!buf || buf-used = sizeof(buf-buf)) {
-buf = malloc(sizeof(*buf));
-if (!buf) libxl__alloc_failed(CTX, __func__, 1, sizeof(*buf));
-buf-used = 0;
-LIBXL_TAILQ_INSERT_TAIL(dc-bufs, buf, entry);
-}
-int r = read(ev-fd, buf-buf + buf-used,
+buf = LIBXL_TAILQ_LAST(dc-bufs, libxl__datacopier_bufs);
+if (!buf || buf-used = sizeof(buf-buf)) {
+buf = malloc(sizeof(*buf));
+if (!buf) libxl__alloc_failed(CTX, __func__, 1,
sizeof(*buf));
+buf-used = 0;
+LIBXL_TAILQ_INSERT_TAIL(dc-bufs, buf, entry);
+}
+r = read(ev-fd, buf-buf + buf-used,
min_t(size_t, sizeof(buf-buf) - buf-used,
dc-maxread));
+}
if (r 0) {
if (errno == EINTR) continue;
if (errno == EWOULDBLOCK) break;
@@ -255,10 +261,12 @@ static void datacopier_readable(libxl__egc *egc,
libxl__ev_fd *ev,
return;
}
}
-buf-used += r;
+if (!dc-readbuf) {
+buf-used += r;
+assert(buf-used = sizeof(buf-buf));
+}
dc-used += r;
dc-maxread -= r;
-assert(buf-used = sizeof(buf-buf));
assert(dc-maxread = 0);
if (dc-maxread == 0)
break;
@@ -316,15 +324,19 @@ int libxl__datacopier_start(libxl__datacopier_state *dc)
libxl__datacopier_init(dc);
+assert(dc-readfd = 0 || dc-writefd = 0);
+
if (dc-readfd = 0) {
rc = libxl__ev_fd_register(gc, dc-toread, datacopier_readable,
dc-readfd, POLLIN);
if (rc) goto out;
}
-rc = libxl__ev_fd_register(gc, dc-towrite, datacopier_writable,
- dc-writefd, POLLOUT);
-if (rc) goto out;
+if (dc-writefd = 0) {
+rc = libxl__ev_fd_register(gc, dc-towrite, datacopier_writable,
+ dc-writefd, POLLOUT);
+if (rc) goto out;
+}
return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index
Re: [Xen-devel] [PATCH 3/6] tools/libxl: Allow adding larger amounts of prefixdata to datacopier
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
From: Ross Lagerwall ross.lagerw...@citrix.com
Previously, adding more than 1000 bytes of data would cause a segfault.
Now, the maximum amount of data that can be added is limited by maxsz.
http://lists.xen.org/archives/html/xen-devel/2014-09/msg01806.html:
struct libxl__datacopier_buf contains a fixed size 1000 byte
statically allocated buffer so adding 1000 bytes of data would
cause it to overrun the buffer and overwrite other memory.
http://lists.xen.org/archives/html/xen-devel/2014-09/msg01813.html
Yes, this should be the main point of the commit log though.
The commit log should mention that the current code overruns a static
1000 byte buffer and fixes it by allocating and chaining as many buffers
as are required for the amount of data.
Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_aoutils.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index 3e0c0ae..6882ca3 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -160,6 +160,8 @@ void libxl__datacopier_prefixdata(libxl__egc *egc,
libxl__datacopier_state *dc,
{
EGC_GC;
libxl__datacopier_buf *buf;
+const uint8_t *ptr;
+
/*
* It is safe for this to be called immediately after _start, as
* is documented in the public comment. _start's caller must have
@@ -170,12 +172,14 @@ void libxl__datacopier_prefixdata(libxl__egc *egc,
libxl__datacopier_state *dc,
assert(len dc-maxsz - dc-used);
-buf = libxl__zalloc(NOGC, sizeof(*buf));
-buf-used = len;
-memcpy(buf-buf, data, len);
+for (ptr = data; len; len -= buf-used, ptr += buf-used) {
+buf = libxl__malloc(NOGC, sizeof(*buf));
+buf-used = min(len, sizeof(buf-buf));
+memcpy(buf-buf, ptr, buf-used);
-dc-used += len;
-LIBXL_TAILQ_INSERT_TAIL(dc-bufs, buf, entry);
+dc-used += buf-used;
+LIBXL_TAILQ_INSERT_TAIL(dc-bufs, buf, entry);
+}
}
static int datacopier_pollhup_handled(libxl__egc *egc,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/6] tools/libxl: Allow limiting amount copied by datacopier
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote: From: Ross Lagerwall ross.lagerw...@citrix.com Add a parameter, maxread, to limit the amount of data read from the source fd of a datacopier. http://lists.xen.org/archives/html/xen-devel/2014-09/msg01802.html and followups. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: fix build failure if using perfc=y
On 19.02.15 at 18:11, dario.faggi...@citrix.com wrote: --- a/xen/include/xen/perfc_defn.h +++ b/xen/include/xen/perfc_defn.h @@ -53,4 +53,8 @@ PERFCOUNTER(vcpu_hot, csched: vcpu_hot) PERFCOUNTER(need_flush_tlb_flush, PG_need_flush tlb flushes) +/* Viridian counters */ +PERFCOUNTER(mshv_wrmsr_tsc_msr, viridian: wrmsr_tsc_msr) +PERFCOUNTER(mshv_rdmsr_tsc_msr, viridian: rdmsr_tsc_msr) They belong into xen/include/asm-x86/perfc_defn.h (you'll find a large group of other mshv_* ones there). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/6] tools/libxl: Introduce min and max macros
2015-02-18 16:34 GMT+00:00 Andrew Cooper andrew.coop...@citrix.com:
This is the same set used by libxc.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
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..a2b6fb7 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) \
+({ type __x = (x); type __y = (y); __x __y ? __x: __y; })
+#define max_t(type,x,y) \
+({ type __x = (x); type __y = (y); __x __y ? __x: __y; })
+
Surely nobody will complain about these defines but according to
standard (ie
https://www.securecoding.cert.org/confluence/display/seccode/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier)
identifiers that start with double underscore are reserved. Here you
used _x, _y and __x, __y as it's a single patch make at least
coherent.
#define LIBXL__LOGGING_ENABLED
#ifdef LIBXL__LOGGING_ENABLED
--
1.7.10.4
Frediano
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] EPT question - XENMEM_get_access_op
On 20.02.15 at 05:47, bsinghar...@gmail.com wrote: I'm trying to use the memevent channel to extract the permission for a particular text section. I expect to see rx as the permission, instead I am seeing rwx. I have not spent a whole lot of time looking at memaccess[] and p2m-ept.c, but I am puzzled. The OS definitely has this text segment marked as COPY-ON-WRITE, I am a little confused with the permissions returned. Is there a way to get the right thing? What the guest OS specifies doesn't matter here - EPT is not OS (L1) but hypervisor (L2) paging, and hence the permissions there are controlled by the hypervisor. Of course guest memory accesses have to pass both paging levels' access checks in order to be carried out (and not fault). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/6] tools/libxl: Introduce min and max macros
On 20/02/15 10:42, Frediano Ziglio wrote:
2015-02-18 16:34 GMT+00:00 Andrew Cooper andrew.coop...@citrix.com:
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 934465a..a2b6fb7 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) \
+({ type __x = (x); type __y = (y); __x __y ? __x: __y; })
+#define max_t(type,x,y) \
+({ type __x = (x); type __y = (y); __x __y ? __x: __y; })
+
Surely nobody will complain about these defines but according to
standard (ie
https://www.securecoding.cert.org/confluence/display/seccode/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier)
identifiers that start with double underscore are reserved. Here you
used _x, _y and __x, __y as it's a single patch make at least
coherent.
I will adjust in v2. No point breaking the rules given that it is
trivial to fix.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/6] tools/libxl: Update datacopier to support sending data only
On Fri, 2015-02-20 at 11:10 +, Andrew Cooper wrote: On 20/02/15 10:27, Ian Campbell wrote: On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote: From: Wen Congyang we...@cn.fujitsu.com datacopier is to read some data and write it out. If we have some data to send it over network, we cannot use datacopier. Update it to support this case. Please can you clarify this commit message. Questions I'm left with after reading it: * What is the relevance of send it over network here, why does it matter what the output fd is? Or is this something to do with the lack of an input fd (in which case where does the incoming data come from?) * Why can datacopier not currently be used in this case, what actually goes wrong? * What is the nature of the update which makes it work? (possibly becomes obvious after the previous answers) Thanks. This is one of several patches which didn't get included as part of the libxl remus series in the end (i.e. git rebase didn't drop this hunk out), but is still needed for migration v2. Currently, the datacopier only functions when copying from readfd to writefd until EOF is hit on readfd. The datacopier infrastructure already has prefixdata which will be inserted into writefd ahead of the content of readfd, but lacks the ability to simply copy from a local buffer to writefd. This patch makes the lack of readfd non-fatal, which allows the rest of the existing infrastructure function as a proper copy from local buffer. Where copy from local buffer is using the prefixdata support? Anyway, please expand the commit message with all that info. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 5/7] Mini-OS: standalone build
In order to keep the tree bisectable all the changes are done in one single commit. Things done in this commit: 1. Import necessary .mk files from Xen. 2. Move all XEN_ related variables to MINIOS_ namespace. 3. Import Xen public header files. 4. Import BSD's list.h and helper script. Mini-OS's vanilla Config.mk is modified to contain some macros copied from Xen's Config.mk. It also contains compatibility handling logic for Xen's stubdom build environment. Files modified: Config.mk Makefile arch/x86/Makefile arch/x86/arch.mk minios.mk All other files are just imported from Xen. Signed-off-by: Wei Liu wei.l...@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 [ output trimmed since this patch is acked ] ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 7/7] Remove in-tree mini-os directory
Signed-off-by: Wei Liu wei.l...@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 [ output trimmed ] ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/7] stubdom: don't look for mini-os source file during configure
Don't look for mini-os source file during configure. Mini-os source code will be fetched during build. Instead look for xenstore-minios.cfg. Please rerun autogen.sh after applying this patch. Signed-off-by: Wei Liu wei.l...@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com --- Changes in v2: 1. Look for xenstore-minios.cfg. --- stubdom/configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/stubdom/configure.ac b/stubdom/configure.ac index 6468203..9fec853 100644 --- a/stubdom/configure.ac +++ b/stubdom/configure.ac @@ -4,7 +4,7 @@ AC_PREREQ([2.67]) AC_INIT([Xen Hypervisor Stub Domains], m4_esyscmd([../version.sh ../xen/Makefile]), [xen-devel@lists.xen.org], [xen], [http://www.xen.org/]) -AC_CONFIG_SRCDIR([../extras/mini-os/kernel.c]) +AC_CONFIG_SRCDIR([xenstore-minios.cfg]) AC_CONFIG_FILES([../config/Stubdom.mk]) AC_CONFIG_AUX_DIR([../]) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] [XEN-4.2] hvmloader: Workaround uncached P2M mappings being created when relocating RAM
At 15:12 + on 19 Feb (1424355171), Jan Beulich wrote: On 19.02.15 at 15:47, malcolm.cross...@citrix.com wrote: Tim suggested posting this patch to see what general opinion was to this style of backport fix. I attempted to backport the EPT misconfig to Xen 4.4 but I ended up with quite a large number of patches and got concerned there would be a subtle error in my backport. Yeah, your change is certainly much smaller, so I'm not opposed to going this route. I've Cc-ed Tim now so he could chime in if at this point he thinks differently. I still think this is the better path - especially once it's been adjusted as Jan suggests to make the patch even smaller and clearer. One other comment, if you're respinning: +uint64_t mtrr_def_type = rdmsr(MSR_MTRRdefType); +wrmsr(MSR_MTRRdefType, (1u 11) | 6); Can this magic constant have a comment? When it's used in cacheattr.c it's commented as '/* E, default type WB */'. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] RFC: [PATCH 0/3] Base PCI and Cavium ThunderX PCI platform support
This patch series adds PCI support for XEN ARM. - pci config read writes maps to xen-arm pci.c - platform support includes parsing pci device tree node and callbacks for reading writing from configuration space - placeholder code is added which is necessary for compilation Next RFC Patch set will include RFC PCI pass-through support manish jaggi (3): Enhance platform support for PCI ThunderX platform support for PCI XEN ARM PCI support xen/arch/arm/Makefile | 1 + xen/arch/arm/pci.c| 111 ++ xen/arch/arm/platform.c | 27 + xen/arch/arm/platforms/thunderx.c | 124 ++ xen/arch/arm/setup.c | 3 +- xen/drivers/passthrough/pci.c | 28 ++--- xen/include/asm-arm/device.h | 1 + xen/include/asm-arm/domain.h | 3 + xen/include/asm-arm/pci.h | 25 ++-- xen/include/asm-arm/platform.h| 18 +- 10 files changed, 327 insertions(+), 14 deletions(-) create mode 100644 xen/arch/arm/pci.c -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 1/4] xen/arm: Make gic-v2 code handle hip04-d01 platform
The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.
Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due to some field restriction. Any value above this is already
an error.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
Signed-off-by: Zoltan Kiss zoltan.k...@huawei.com
---
xen/arch/arm/gic-v2.c | 85 ++-
xen/arch/arm/gic.c| 3 +-
xen/include/asm-arm/gic.h | 4 ++-
3 files changed, 75 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 4d1924e..7f5cfcb 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -79,16 +79,25 @@ static struct gic_info gicv2_info;
* logical CPU numbering. Let's use mapping as returned by the GIC
* itself
*/
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
/* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+static unsigned int nr_gic_cpu_if = 8;
+static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
+static unsigned int gic_cpu_mask = 0xff;
+
+#define is_hip04() (nr_gic_cpu_if == 16)
static inline void writeb_gicd(uint8_t val, unsigned int offset)
{
writeb_relaxed(val, gicv2.map_dbase + offset);
}
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+writew_relaxed(val, gicv2.map_dbase + offset);
+}
+
static inline void writel_gicd(uint32_t val, unsigned int offset)
{
writel_relaxed(val, gicv2.map_dbase + offset);
@@ -132,7 +141,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
cpumask_and(possible_mask, cpumask, cpu_possible_map);
for_each_cpu( cpu, possible_mask )
{
-ASSERT(cpu NR_GIC_CPU_IF);
+ASSERT(cpu nr_gic_cpu_if);
mask |= per_cpu(gic_cpu_id, cpu);
}
@@ -203,6 +212,15 @@ static unsigned int gicv2_read_irq(void)
return (readl_gicc(GICC_IAR) GICC_IA_IRQ);
}
+/* Set target CPU mask (RAZ/WI on uniprocessor) */
+static void gicv2_set_irq_mask(int irq, unsigned int mask)
+{
+if ( is_hip04() )
+writew_gicd(mask, GICD_ITARGETSR + irq * 2);
+else
+writeb_gicd(mask, GICD_ITARGETSR + irq);
+}
+
/*
* needs to be called with a valid cpu_mask, ie each cpu in the mask has
* already called gic_cpu_init
@@ -230,7 +248,7 @@ static void gicv2_set_irq_properties(struct irq_desc *desc,
writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
/* Set target CPU mask (RAZ/WI on uniprocessor) */
-writeb_gicd(mask, GICD_ITARGETSR + irq);
+gicv2_set_irq_mask(irq, mask);
/* Set priority */
writeb_gicd(priority, GICD_IPRIORITYR + irq);
@@ -244,16 +262,21 @@ static void __init gicv2_dist_init(void)
uint32_t gic_cpus;
int i;
-cpumask = readl_gicd(GICD_ITARGETSR) 0xff;
-cpumask |= cpumask 8;
-cpumask |= cpumask 16;
+cpumask = readl_gicd(GICD_ITARGETSR) gic_cpu_mask;
/* Disable the distributor */
writel_gicd(0, GICD_CTLR);
type = readl_gicd(GICD_TYPER);
gicv2_info.nr_lines = 32 * ((type GICD_TYPE_LINES) + 1);
-gic_cpus = 1 + ((type GICD_TYPE_CPUS) 5);
+if ( is_hip04() )
+{
+gic_cpus = 16;
+}
+else
+{
+gic_cpus = 1 + ((type GICD_TYPE_CPUS) 5);
+}
printk(GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n,
gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? : s,
(type GICD_TYPE_SEC) ? , secure : ,
@@ -264,8 +287,19 @@ static void __init gicv2_dist_init(void)
writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
/* Route all global IRQs to this CPU */
-for ( i = 32; i gicv2_info.nr_lines; i += 4 )
-writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+if ( is_hip04() )
+{
+cpumask |= cpumask 16;
+for ( i = 32; i gicv2_info.nr_lines; i += 2 )
+writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
+}
+else
+{
+cpumask |= cpumask 8;
+cpumask |= cpumask 16;
+for ( i = 32; i gicv2_info.nr_lines; i += 4 )
+writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
+}
/* Default priority for global interrupts */
for ( i = 32; i gicv2_info.nr_lines; i += 4 )
@@ -285,7 +319,7 @@ static void __cpuinit gicv2_cpu_init(void)
{
int i;
-this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) 0xff;
+this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) gic_cpu_mask;
/* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
* even though they are controlled with GICD registers, they must
@@ -366,7 +400,7 @@ static void gicv2_send_SGI(enum gic_sgi sgi, enum
gic_sgi_mode irqmode,
cpumask_and(online_mask, cpu_mask, cpu_online_map);
mask = gicv2_cpu_mask(online_mask);
[Xen-devel] [xen-4.5-testing test] 34731: tolerable FAIL - PUSHED
flight 34731 xen-4.5-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34731/ Failures :-/ but no regressions. 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 10 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-libvirt 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-armhf-armhf-xl 10 migrate-support-checkfail 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-pcipt-intel 9 guest-start fail never pass test-armhf-armhf-xl-credit2 5 xen-boot fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-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-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail 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-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-pair17 guest-migrate/src_host/dst_host 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 test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 2417e243bb510dafdbd589a5aeedb29095e62c10 baseline version: xen d8e78d691d9b4bcc945d8f0b0ed2b48713931c4d People who touched revisions under test: Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jim Fehlig jfeh...@suse.com Julien Grall julien.gr...@linaro.org Wei Liu wei.l...@citrix.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 build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass 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-amd64pass 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 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64
[Xen-devel] [PATCH] xen/arm: Handle translated addresses for hardware domains in GICv2
Translated address could have an offset applied to them.
Replicate same value for device node to avoid improper address
computation in the OS.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-v2.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Submit again after release. This patch was developed as a specific
platform patch but it applies to all platforms.
Previous discussions at
- http://lists.xen.org/archives/html/xen-devel/2014-11/msg00406.html
- http://lists.xen.org/archives/html/xen-devel/2014-11/msg00520.html
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..4d1924e 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -590,7 +590,7 @@ static int gicv2_make_dt_node(const struct domain *d,
const struct dt_device_node *gic = dt_interrupt_controller;
const void *compatible = NULL;
u32 len;
-__be32 *new_cells, *tmp;
+const __be32 *regs;
int res = 0;
compatible = dt_get_property(gic, compatible, len);
@@ -617,18 +617,18 @@ static int gicv2_make_dt_node(const struct domain *d,
if ( res )
return res;
+/* copy GICC and GICD regions */
+regs = dt_get_property(gic, reg, len);
+if ( !regs )
+{
+dprintk(XENLOG_ERR, Can't find reg property for the gic node\n);
+return -FDT_ERR_XEN(ENOENT);
+}
+
len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
len *= 2; /* GIC has two memory regions: Distributor + CPU interface */
-new_cells = xzalloc_bytes(len);
-if ( new_cells == NULL )
-return -FDT_ERR_XEN(ENOMEM);
-
-tmp = new_cells;
-dt_set_range(tmp, node, d-arch.vgic.dbase, PAGE_SIZE);
-dt_set_range(tmp, node, d-arch.vgic.cbase, PAGE_SIZE * 2);
-res = fdt_property(fdt, reg, new_cells, len);
-xfree(new_cells);
+res = fdt_property(fdt, reg, regs, len);
return res;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 3/4] xen/arm: handle GICH register changes for hip04-d01 platform
The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-v2.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 13c038e..7f2040c 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -61,6 +61,9 @@
#define GICH_V2_VMCR_PRIORITY_MASK 0x1f
#define GICH_V2_VMCR_PRIORITY_SHIFT 27
+#define HIP04_GICH_APR 0x70
+#define HIP04_GICH_LR 0x80
+
/* Global state */
static struct {
paddr_t dbase;/* Address of distributor registers */
@@ -85,6 +88,8 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
static unsigned int nr_gic_cpu_if = 8;
static unsigned int gicd_sgi_target_shift = GICD_SGI_TARGET_SHIFT;
static unsigned int gic_cpu_mask = 0xff;
+static unsigned int gich_apr = GICH_APR;
+static unsigned int gich_lr = GICH_LR;
#define is_hip04() (nr_gic_cpu_if == 16)
@@ -157,9 +162,9 @@ static void gicv2_save_state(struct vcpu *v)
* accessed simultaneously by another pCPU.
*/
for ( i = 0; i gicv2_info.nr_lrs; i++ )
-v-arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+v-arch.gic.v2.lr[i] = readl_gich(gich_lr + i * 4);
-v-arch.gic.v2.apr = readl_gich(GICH_APR);
+v-arch.gic.v2.apr = readl_gich(gich_apr);
v-arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
/* Disable until next VCPU scheduled */
writel_gich(0, GICH_HCR);
@@ -170,9 +175,9 @@ static void gicv2_restore_state(const struct vcpu *v)
int i;
for ( i = 0; i gicv2_info.nr_lrs; i++ )
-writel_gich(v-arch.gic.v2.lr[i], GICH_LR + i * 4);
+writel_gich(v-arch.gic.v2.lr[i], gich_lr + i * 4);
-writel_gich(v-arch.gic.v2.apr, GICH_APR);
+writel_gich(v-arch.gic.v2.apr, gich_apr);
writel_gich(v-arch.gic.v2.vmcr, GICH_VMCR);
writel_gich(GICH_HCR_EN, GICH_HCR);
}
@@ -185,7 +190,7 @@ static void gicv2_dump_state(const struct vcpu *v)
{
for ( i = 0; i gicv2_info.nr_lrs; i++ )
printk( HW_LR[%d]=%x\n, i,
- readl_gich(GICH_LR + i * 4));
+ readl_gich(gich_lr + i * 4));
}
else
{
@@ -439,12 +444,12 @@ static void gicv2_update_lr(int lr, const struct
pending_irq *p,
GICH_V2_LR_PHYSICAL_SHIFT);
}
-writel_gich(lr_reg, GICH_LR + lr * 4);
+writel_gich(lr_reg, gich_lr + lr * 4);
}
static void gicv2_clear_lr(int lr)
{
-writel_gich(0, GICH_LR + lr * 4);
+writel_gich(0, gich_lr + lr * 4);
}
static int gicv2v_setup(struct domain *d)
@@ -492,7 +497,7 @@ static void gicv2_read_lr(int lr, struct gic_lr *lr_reg)
{
uint32_t lrv;
-lrv = readl_gich(GICH_LR + lr * 4);
+lrv = readl_gich(gich_lr + lr * 4);
lr_reg-pirq = (lrv GICH_V2_LR_PHYSICAL_SHIFT)
GICH_V2_LR_PHYSICAL_MASK;
lr_reg-virq = (lrv GICH_V2_LR_VIRTUAL_SHIFT) GICH_V2_LR_VIRTUAL_MASK;
lr_reg-priority = (lrv GICH_V2_LR_PRIORITY_SHIFT)
GICH_V2_LR_PRIORITY_MASK;
@@ -515,7 +520,7 @@ static void gicv2_write_lr(int lr, const struct gic_lr
*lr_reg)
GICH_V2_LR_HW_SHIFT) |
((uint32_t)(lr_reg-grp GICH_V2_LR_GRP_MASK)
GICH_V2_LR_GRP_SHIFT) );
-writel_gich(lrv, GICH_LR + lr * 4);
+writel_gich(lrv, gich_lr + lr * 4);
}
static void gicv2_hcr_status(uint32_t flag, bool_t status)
@@ -538,7 +543,7 @@ static unsigned int gicv2_read_vmcr_priority(void)
static unsigned int gicv2_read_apr(int apr_reg)
{
- return readl_gich(GICH_APR);
+ return readl_gich(gich_apr);
}
static void gicv2_irq_enable(struct irq_desc *desc)
@@ -801,6 +806,8 @@ static int __init hip04_gicv2_init(struct dt_device_node
*node, const void *data
nr_gic_cpu_if = 16;
gicd_sgi_target_shift = 8;
gic_cpu_mask = 0x;
+gich_apr = HIP04_GICH_APR;
+gich_lr = HIP04_GICH_LR;
return gicv2_init_default(node, data);
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 4/4] xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform
Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-v2.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 7f2040c..05dc729 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -639,6 +639,12 @@ static int gicv2_make_dt_node(const struct domain *d,
return -FDT_ERR_XEN(ENOENT);
}
+if ( is_hip04() )
+{
+compatible = DT_COMPAT_GIC_CORTEX_A15;
+len = strlen((char*) compatible) + 1;
+}
+
res = fdt_begin_node(fdt, interrupt-controller);
if ( res )
return res;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 2/4] xen/arm: Add support for DTBs with strange names of Hip04 GICv2
This name can appear in some Linux kernel repos. Not very fortunate,
but to avoid others spending an hour to spot that few characters
difference it worth to work around it.
Signed-off-by: Zoltan Kiss zoltan.k...@huawei.com
---
xen/arch/arm/gic-v2.c | 1 +
xen/include/asm-arm/gic.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 7f5cfcb..13c038e 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -821,6 +821,7 @@ DT_DEVICE_END
static const char * const hip04_gicv2_dt_compat[] __initconst =
{
DT_COMPAT_GIC_HIP04,
+DT_COMPAT_GIC_HIP04_2,
NULL
};
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index c880867..f8ba227 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -156,11 +156,13 @@
#define DT_COMPAT_GIC_CORTEX_A15 arm,cortex-a15-gic
#define DT_COMPAT_GIC_CORTEX_A7 arm,cortex-a7-gic
#define DT_COMPAT_GIC_HIP04 hisilicon,hip04-intc
+#define DT_COMPAT_GIC_HIP04_2hisilicon,hip04-gic
#define DT_MATCH_GIC_V2 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A15), \
DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400), \
-DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
+DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04), \
+DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04_2)
#define DT_COMPAT_GIC_V3 arm,gic-v3
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5] xen/arm: Add support for Huawei hip04-d01 platform
This set of patches add Xen support for hip04-d01 platform (see https://wiki.linaro.org/Boards/D01 for details). Changes from v4: - rebased to new version; - removed patch for computing GIC addresses as it apply to all platforms; - removed patches to platform (cpu and system operations) as now they can use a bootwrapper which provide them. Changes from v3: - change the way regs property is computed for GICv2 (Julien Grall); - revert order of compaible names for GIC (Julien Grall). Changes from v2: - rewrote DTS fix patch (Ian Campbell); - use is_hip04 macro instead of doing explicit test (Julien Grall); - do not use quirks to distinguish this platform (Ian Cambell); - move some GIC constants to C files instead of header (Julien Grall); - minor changes (Julien Grall). Changes from v1: - style (Julien Grall); - make gicv2_send_SGI faster (Julien Grall); - cleanup correctly if hip04_smp_init fails (Julien Grall); - remove quirks using compatibility (Ian Campbell); - other minor suggestions by Julien Grall. Frediano Ziglio (4): xen/arm: Make gic-v2 code handle hip04-d01 platform xen/arm: Add support for DTBs with strange names of Hip04 GICv2 xen/arm: handle GICH register changes for hip04-d01 platform xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform xen/arch/arm/gic-v2.c | 119 -- xen/arch/arm/gic.c| 3 +- xen/include/asm-arm/gic.h | 6 ++- 3 files changed, 101 insertions(+), 27 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 01/13] xen/arm: gic-v2: Change the device name in DT_DEVICE_START
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: I'm not sure why a ':' has been added in the name... But none of the other usages doesn't have it. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 04/13] xen/arm: device: Rename device_type into device_class
On Fri, 2015-02-06 at 12:38 +, Stefano Stabellini wrote: On Fri, 30 Jan 2015, Julien Grall wrote: This enum was used for matching a specific class of device and not to get the type of device. Hence the name device_type will be used for another purpose later. Also rename device_get_type into device_get_class to reflect the change. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 02/13] xen/arm: vgic: Drop unecessary include asm/device.h
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: The header asm/device.h has been included in the vgic code during splitting to support multiple version. But no code within those files requires it. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ 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 20/02/15 12:10, Manish Jaggi wrote: On 20/02/15 5:33 pm, Julien Grall wrote: Hello Manish, On 20/02/15 11:34, Manish Jaggi wrote: The platform APIs are enhanced to provide support for parsing pci device tree nodes and storing the config-space address which is later used for pci_read/pci_write config calls. Can you explain why you choose to add per-platform callbacks rather than a generic solution? The platform code is similar to what linux has in drivers/pci/host/pci-platform.c. I have used the same concept. Please explain it in the commit message, it helps us to understand why you did it. Anyway, based on what you said, your approach looks wrong. Firstly, the platform code is DT-centric and we don't expect to have a such things for ACPI. Secondly, the PCI host code be shared between multiple platform. Overall, I would prefer to have a separate file and structure for handling PCI host. Also, I think we could re-use the Linux code for this purpose. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: add x86 emulator test directory to X86 ARCHITECTURE
On Tue, Feb 17, 2015 at 03:29:35PM +, Jan Beulich wrote: Signed-off-by: Jan Beulich jbeul...@suse.com Acked-by: Wei Liu wei.l...@citrix.com --- a/MAINTAINERS +++ b/MAINTAINERS @@ -347,6 +347,7 @@ F: xen/arch/x86/ F: xen/include/asm-x86/ F: tools/firmware/hvmloader/ +F: tools/tests/x86_emulator/ X86 MEMORY MANAGEMENT M: Tim Deegan t...@xen.org ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 0/3] Base PCI and Cavium ThunderX PCI platform support
On 20/02/15 11:56, Manish Jaggi wrote: On 20/02/15 5:23 pm, Julien Grall wrote: Hello manish, On 20/02/15 11:30, Manish Jaggi wrote: This patch series adds PCI support for XEN ARM. - pci config read writes maps to xen-arm pci.c - platform support includes parsing pci device tree node and callbacks for reading writing from configuration space - placeholder code is added which is necessary for compilation Next RFC Patch set will include RFC PCI pass-through support You series is not threaded and every patches missing a Signed-off-by. Please read http://wiki.xen.org/wiki/Submitting_Xen_Project_Patches to know how to submit a patch series. Do we need to add Signoff in RFC patches ? Yes, an RFC is just a different kind of patch series... We need to know who worked on it. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 0/3] Base PCI and Cavium ThunderX PCI platform support
On 20/02/15 5:23 pm, Julien Grall wrote: Hello manish, On 20/02/15 11:30, Manish Jaggi wrote: This patch series adds PCI support for XEN ARM. - pci config read writes maps to xen-arm pci.c - platform support includes parsing pci device tree node and callbacks for reading writing from configuration space - placeholder code is added which is necessary for compilation Next RFC Patch set will include RFC PCI pass-through support You series is not threaded and every patches missing a Signed-off-by. Please read http://wiki.xen.org/wiki/Submitting_Xen_Project_Patches to know how to submit a patch series. Do we need to add Signoff in RFC patches ? Regards, manish jaggi (3): Enhance platform support for PCI ThunderX platform support for PCI XEN ARM PCI support xen/arch/arm/Makefile | 1 + xen/arch/arm/pci.c| 111 ++ xen/arch/arm/platform.c | 27 + xen/arch/arm/platforms/thunderx.c | 124 ++ xen/arch/arm/setup.c | 3 +- xen/drivers/passthrough/pci.c | 28 ++--- xen/include/asm-arm/device.h | 1 + xen/include/asm-arm/domain.h | 3 + xen/include/asm-arm/pci.h | 25 ++-- xen/include/asm-arm/platform.h| 18 +- 10 files changed, 327 insertions(+), 14 deletions(-) create mode 100644 xen/arch/arm/pci.c ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] RFC: [PATCH 0/3] Base PCI and Cavium ThunderX PCI platform support
On 20/02/15 5:28 pm, Julien Grall wrote: On 20/02/15 11:56, Manish Jaggi wrote: On 20/02/15 5:23 pm, Julien Grall wrote: Hello manish, On 20/02/15 11:30, Manish Jaggi wrote: This patch series adds PCI support for XEN ARM. - pci config read writes maps to xen-arm pci.c - platform support includes parsing pci device tree node and callbacks for reading writing from configuration space - placeholder code is added which is necessary for compilation Next RFC Patch set will include RFC PCI pass-through support You series is not threaded and every patches missing a Signed-off-by. Please read http://wiki.xen.org/wiki/Submitting_Xen_Project_Patches to know how to submit a patch series. Do we need to add Signoff in RFC patches ? Yes, an RFC is just a different kind of patch series... We need to know who worked on it. ok, I will add it in next revision consolidated with other comments. I hope it is ok. Regards, ___ 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 20/02/15 5:33 pm, Julien Grall wrote: Hello Manish, On 20/02/15 11:34, Manish Jaggi wrote: The platform APIs are enhanced to provide support for parsing pci device tree nodes and storing the config-space address which is later used for pci_read/pci_write config calls. Can you explain why you choose to add per-platform callbacks rather than a generic solution? The platform code is similar to what linux has in drivers/pci/host/pci-platform.c. I have used the same concept. Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] [PATCH 3/3] XEN ARM PCI support
On 20/02/15 12:05, Manish Jaggi wrote: On 20/02/15 5:23 pm, Jan Beulich wrote: All of these #ifdef-s call for better abstraction. And in no case is it acceptable to replace blank lines with #ifdef-s like you do. Good observation. I will take care for the blank lines. A lot of code existed in generic files specific to x86, so arm specific defines. Some of us have filter to get quickly mail where we are CCed. So please reply to all rather than only the mailing list. Thanks, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 05/13] xen/iommu: arm: Remove temporary the SMMU driver
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: The current SMMU driver has completly diverged. That makes me hard to maintain. Will this temporarily regress anything in a noticeable way? I think it'll just potentially make some hypothetical platform switch back to 1:1 dom0 mode, which in practice they all use anyway, IOW no harm done, even temporarily. So: Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 06/13] xen/arm: Introduce a generic way to describe device
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote:
@@ -2,8 +2,34 @@
#define __ASM_ARM_DEVICE_H
#include xen/init.h
+
+enum device_type
+{
+DEV_DT,
I suppose no #ifdef here because an empty enum is a bit silly?
+/* TODO: Correctly implement dev_is_pci when PCI will be supported on ARM */
s/will be/is/
+#define dev_is_pci(dev) ((void)(dev), 0)
+#define dev_is_dt(dev) ((dev-type == DEV_DT)
+
enum device_class
{
DEVICE_SERIAL,
diff --git a/xen/include/asm-x86/device.h b/xen/include/asm-x86/device.h
new file mode 100644
index 000..a016112
--- /dev/null
+++ b/xen/include/asm-x86/device.h
@@ -0,0 +1,25 @@
+#ifndef __ASM_X86_DEVICE_H
+#define __ASM_X86_DEVICE_H
+
+#include xen/pci.h
+
+/*
+ * x86 is only supported PCI. Therefore it's possible to directly use
x86 is only supporting PCI or (better) x86 only supports PCI.
+#define dt_to_dev(dt_node) ((dt_node)-dev)
+
+static inline struct dt_device_node *dev_to_dt(struct device *dev)
+{
+ASSERT(dev-type == DEV_DT);
+
+return container_of(dev, struct dt_device_node, dev);
+}
Given that x86 uses a difference struct and doesn't support DT shouldn't
this either be wrapped in a HAVE_DEVICE_TREE or placed in the ARM header
(or some other common-to-all-dt-platforms header)?
+
#define MAX_PHANDLE_ARGS 16
struct dt_phandle_args {
struct dt_device_node *np;
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 8eb764a..ecb2627 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -25,6 +25,7 @@
#include xen/pci.h
#include public/hvm/ioreq.h
#include public/domctl.h
+#include asm/device.h
#include asm/iommu.h
extern bool_t iommu_enable, iommu_enabled;
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 5f295f3..3988ee68 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -13,6 +13,7 @@
#include xen/irq.h
#include xen/pci_regs.h
#include xen/pfn.h
+#include asm/device.h
#include asm/pci.h
/*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] [PATCH 3/3] XEN ARM PCI support
On 20/02/15 5:23 pm, Jan Beulich wrote:
On 20.02.15 at 12:47, mja...@caviumnetworks.com wrote:
@@ -287,6 +289,7 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
u8 bus, u8 devfn)
if ( pci_find_cap_offset(pseg-nr, bus, PCI_SLOT(devfn),
PCI_FUNC(devfn),
PCI_CAP_ID_MSIX) )
{
+#ifndef CONFIG_ARM
struct arch_msix *msix = xzalloc(struct arch_msix);
if ( !msix )
@@ -296,6 +299,7 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
u8 bus, u8 devfn)
}
spin_lock_init(msix-table_lock);
pdev-msix = msix;
+#endif
}
list_add(pdev-alldevs_list, pseg-alldevs_list);
@@ -396,7 +400,9 @@ static void free_pdev(struct pci_seg *pseg, struct
pci_dev *pdev)
}
list_del(pdev-alldevs_list);
+#ifndef CONFIG_ARM
xfree(pdev-msix);
+#endif
xfree(pdev);
}
@@ -424,7 +430,7 @@ int __init pci_hide_device(int bus, int devfn)
return rc;
}
-
+#ifndef CONFIG_ARM
int __init pci_ro_device(int seg, int bus, int devfn)
{
struct pci_seg *pseg = alloc_pseg(seg);
@@ -452,7 +458,7 @@ int __init pci_ro_device(int seg, int bus, int devfn)
return 0;
}
-
+#endif
struct pci_dev *pci_get_pdev(int seg, int bus, int devfn)
{
struct pci_seg *pseg = get_pseg(seg);
@@ -740,7 +746,9 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
ret = iommu_remove_device(pdev);
if ( pdev-domain )
list_del(pdev-domain_list);
+#ifndef CONFIG_ARM
pci_cleanup_msi(pdev);
+#endif
free_pdev(pseg, pdev);
printk(XENLOG_DEBUG PCI remove device %04x:%02x:%02x.%u\n,
seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
@@ -750,7 +758,7 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
spin_unlock(pcidevs_lock);
return ret;
}
-
+#ifndef CONFIG_ARM
static int pci_clean_dpci_irq(struct domain *d,
struct hvm_pirq_dpci *pirq_dpci, void *arg)
{
@@ -798,11 +806,12 @@ static int pci_clean_dpci_irqs(struct domain *d)
spin_unlock(d-event_lock);
return 0;
}
-
+#endif
int pci_release_devices(struct domain *d)
{
struct pci_dev *pdev;
u8 bus, devfn;
+#ifndef CONFIG_ARM
int ret;
spin_lock(pcidevs_lock);
@@ -812,6 +821,8 @@ int pci_release_devices(struct domain *d)
spin_unlock(pcidevs_lock);
return ret;
}
+#endif
+
while ( (pdev = pci_get_pdev_by_domain(d, -1, -1, -1)) )
{
bus = pdev-bus;
@@ -1184,6 +1195,7 @@ bool_t pcie_aer_get_firmware_first(const struct pci_dev
*pdev)
static int _dump_pci_devices(struct pci_seg *pseg, void *arg)
{
+#ifndef CONFIG_ARM
struct pci_dev *pdev;
struct msi_desc *msi;
@@ -1199,7 +1211,7 @@ static int _dump_pci_devices(struct pci_seg *pseg, void
*arg)
printk(%d , msi-irq);
printk(\n);
}
-
+#endif
return 0;
}
@@ -1341,7 +1353,7 @@ static int assign_device(struct domain *d, u16 seg, u8
bus, u8 devfn)
if ( !iommu_enabled || !hd-platform_ops )
return 0;
-
+#ifndef CONFIG_ARM
/* Prevent device assign if mem paging or mem sharing have been
* enabled for this domain */
if ( unlikely(!need_iommu(d)
@@ -1349,7 +1361,7 @@ static int assign_device(struct domain *d, u16 seg, u8
bus, u8 devfn)
d-mem_event-paging.ring_page ||
p2m_get_hostp2m(d)-global_logdirty)) )
return -EXDEV;
-
+#endif
if ( !spin_trylock(pcidevs_lock) )
return -ERESTART;
All of these #ifdef-s call for better abstraction. And in no case is it
acceptable to replace blank lines with #ifdef-s like you do.
Good observation. I will take care for the blank lines.
A lot of code existed in generic files specific to x86, so arm specific
defines.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 03/13] xen/dt: Extend dt_device_match to possibly store data
On Fri, 2015-02-06 at 12:37 +, Stefano Stabellini wrote: On Fri, 30 Jan 2015, Julien Grall wrote: Some drivers may want to configure differently the device depending on the compatible string. For this purpose, add a new field in the dt_device_match to store the data. Also modify the return type of dt_match_node to return the matching structure. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 07/13] xen/iommu: Consolidate device assignment ops into a single set
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: On ARM, the way to assign device tree node is exactly the same as PCI. Futhermore, all devices can be represented by a 'device_t'. Therefore there is no need to add separate ops. The x86 iommu drivers has not been modified to replace 'struct pci_dev' by device_t because the latter is an alias of the former. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Jan Beulich jbeul...@suse.com Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 10/13] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices
On 20/02/15 12:35, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: From: Andreas Herrmann andreas.herrm...@calxeda.com If DT information lists one stream ID twice for the master devices of an SMMU this can cause a multi match when stream ID matching is used. For stream ID indexing this might trigger an overwrite of an S2CR that is already in use. So better check for duplicates when DT information is parsed. Taken from the linux ML: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226099.html Cc: Andreas Herrmann herrmann.der.u...@googlemail.com Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com Signed-off-by: Julien Grall julien.gr...@linaro.org I think you were going to drop this one as it is not strictly required? I'm still not entirely clear on the motivation for this patch, looking at the v2 thread I see But, the developer made have written by mistake twice the streamid for the device. which I think you were saying that the DT might, hypothetically, be wrong and have duplicated IDs, is that right? Is it a hypothetical problem or have we seen it in a real device-tree? It's an hypothetical problem. The algo on the next patch won't work correctly otherwise. I may need to rework a bit the next patch if we drop it. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 13/13] xen/iommu: smmu: Advertise when the SMMU support coherent table walk
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: @@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct dt_device_node *dev, if ( !rc ) iommu_set_ops(arm_smmu_iommu_ops); + /* + * The last added SMMU is the first element of arm_smmu_devices. + * It's not necessary to take the lock because only the boot CPU is + * initialized the SMMU devices. Why is only the last added SMMU of interest? Do we not need to take the union and/or intersection of them all? Perhaps the code which calls iommu_set_feature should gain an else which calls iommu_clear_feature, and between them they can ensure that platform_features is correctly updated? + */ + smmu = list_entry(arm_smmu_devices.next, typeof(*smmu), list); + ASSERT(smmu != NULL); + + platform_features = smmu-features; + return rc; } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 09/13] xen/iommu: arm: Import the SMMU driver from Linux
On 20/02/15 12:31, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3. It's a verbatim of the Linux SMMU drivers code. No Xen code has yet been added and the file is not built. Compare to the previous drivers it gains support of PCI. Though it will need a bit of plumbing for Xen. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com (without reading since it is a verbatim copy) xen/arch/arm/README.LinuxPrimitives lists revisions of a bunch of stuff we import from Linux for ease of tracking, should we do something similar here, although perhaps just in a comment in the header of the file? The patch #12 adds in the header the commit used to import the drivers. I didn't put here because it's a verbatim copy. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 11/13] xen/iommu: smmu: Introduce automatic stream-id-masking
On 20/02/15 13:15, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: From: Andreas Herrmann andreas.herrm...@calxeda.com Try to determine mask/id values that match several stream IDs of a master device when doing Stream ID matching. Thus the number of used SMR groups that are required to map all stream IDs of a master device to a context should be less than the number of SMR groups used so far (currently one SMR group is used for one stream ID). Taken from the Linux ML: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226100.html Changes compare to the Linux ML version: - _fls doesn't exist on Xen so use fls Did you mean __fls? I don't see a single _ variant in Linux. I meant __fls. It's important since I think __fls and fls behave slightly differently... On ARM __fls is defined as fls() - 1. I take into account in the algo. - Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs. This former is the field used to configure SRMS Cc: Andreas Herrmann herrmann.der.u...@googlemail.com Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com Signed-off-by: Julien Grall julien.gr...@linaro.org --- This patch was sent on Linux ML back to January 2014. It has never been pushed upstream as it was only useful for Calxeda. I know that until know Calxeda has been our only platform with an SMMU, but that is no longer the case, so I'm not really convinced we want to carry divergence from the upstream driver just for the benefit of this effectively obsolete platform. Nothing prevent a platform to use more streamids than the number the number of stream matching registers. It appears that Calxeda is only one for now. But it may change later... About diverging, Linux is moving fast on the SMMU drivers and rework often. We will diverge quickly from the code. Actually 3.20 reworked heavily the driver, but I don't plan to resync the code again for Xen 4.6 (I would loose at least 2 weeks for it). As Calxeda is the only platform we have which support SMMU for now. I'm doing all my work on it, so this patch is useful for me. The SMMU used to protect the SATA on this platform has more stream id than the number of stream matching registers. Therefore we have to use stream id masking to configure correctly all the stream IDs. What controls which stream IDs are used by the SATA h/w when issuing requests? Can we constrain it somehow (ideally by omitting them from the DT) to only use a subset of the stream IDs, such that the number used is less than the number of matching registers? The StreamIDs is controlled by the device. It identifies a stream of transactions which originate from a device. The guest doesn't have any control on it. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 09/13] xen/iommu: arm: Import the SMMU driver from Linux
On Fri, 2015-02-20 at 13:33 +, Julien Grall wrote: On 20/02/15 12:31, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: Based on commit e6b5be2be4e30037eb551e0ed09dd97bd00d85d3. It's a verbatim of the Linux SMMU drivers code. No Xen code has yet been added and the file is not built. Compare to the previous drivers it gains support of PCI. Though it will need a bit of plumbing for Xen. Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com (without reading since it is a verbatim copy) xen/arch/arm/README.LinuxPrimitives lists revisions of a bunch of stuff we import from Linux for ease of tracking, should we do something similar here, although perhaps just in a comment in the header of the file? The patch #12 adds in the header the commit used to import the drivers. I didn't put here because it's a verbatim copy. Thank, I saw that later, how you have it is fine. Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv6] x86/xen: allow privcmd hypercalls to be preempted
On 19/02/15 16:50, Boris Ostrovsky wrote: On 02/19/2015 10:23 AM, David Vrabel wrote: Hypercalls submitted by user space tools via the privcmd driver can take a long time (potentially many 10s of seconds) if the hypercall has many sub-operations. A fully preemptible kernel may deschedule such as task in any upcall called from a hypercall continuation. However, in a kernel with voluntary or no preemption, hypercall continuations in Xen allow event handlers to be run but the task issuing the hypercall will not be descheduled until the hypercall is complete and the ioctl returns to user space. These long running tasks may also trigger the kernel's soft lockup detection. Add xen_preemptible_hcall_begin() and xen_preemptible_hcall_end() to bracket hypercalls that may be preempted. Use these in the privcmd driver. When returning from an upcall, call xen_maybe_preempt_hcall() which adds a schedule point if if the current task was within a preemptible hypercall. Since _cond_resched() can move the task to a different CPU, clear and set xen_in_preemptible_hcall around the call. Signed-off-by: David Vrabel david.vra...@citrix.com Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com Thanks. Applied to stable/for-linus-3.20. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 05/13] xen/iommu: arm: Remove temporary the SMMU driver
On 20/02/15 13:47, Ian Campbell wrote: On Fri, 2015-02-20 at 12:53 +, Julien Grall wrote: The main thing I'm worried about is if the bisector is searching a range which includes this change looking for some unrelated change and this commit causes some sort of spurious issue or perturbation which confuses the bisector. Perhaps a temporary stub could be put in which just marks SMMUs as used by Xen but doesn't actually use them? The changes for SMMU on the Calxeda DT never reached upstream. So at the moment, we don't have any device tree with SMMU nodes inside. So it won't impact to the bisector. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/6] tools/libxl: Fix datacopier POLLHUP handling to not always be fatal
On 20/02/15 10:43, Ian Campbell wrote:
On Wed, 2015-02-18 at 16:34 +, Andrew Cooper wrote:
POLLIN|POLLHUP is a valid revent to recieve from poll() when the far end has
hung up, but data is still available to be read.
Currently all POLLHUPs are fatal. This is a problem when using the legacy
stream conversion script which will exit 0 when it has completed its task and
has left valid data in the pipe. In this case, libxl wishes to read until
eof, rather than dying because the conversion script exited.
Adjustments are as follows:
1. The datacopier pollhup callback changes type to include a return value.
2. datacopier_handle_pollhup() takes revents by pointer, and calls the
datacopier pollhup callback ahead of killing the datacopier.
3. The callback may now indicate that the POLLHUP is not fatal, in which
case
datacopier_handle_pollhup() mask POLLHUP out of revents, and
datacopier_{read,write}able() allowed to proceed as before.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_aoutils.c| 34 ++
tools/libxl/libxl_bootloader.c | 22 --
tools/libxl/libxl_internal.h | 14 ++
3 files changed, 52 insertions(+), 18 deletions(-)
diff --git a/tools/libxl/libxl_aoutils.c b/tools/libxl/libxl_aoutils.c
index a402e5c..f3e5f98 100644
--- a/tools/libxl/libxl_aoutils.c
+++ b/tools/libxl/libxl_aoutils.c
@@ -182,21 +182,31 @@ void libxl__datacopier_prefixdata(libxl__egc *egc,
libxl__datacopier_state *dc,
}
}
-static int datacopier_pollhup_handled(libxl__egc *egc,
+/*
+ * Handle a POLLHUP signal on a datacopier fd. Return boolean indicating
+ * whether further processing should cease.
Should it return true to cease? Or false to indicate not to continue?
(More importantly than here this should be specified precisely in the
doc header near the callback definition, which it isn't, it just says
with its return value).
The sense as stated is correct, but I will spell it out.
@@ -603,12 +607,26 @@ static void bootloader_keystrokes_copyfail(libxl__egc
*egc,
libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
bootloader_copyfail(egc, bootloader input, bl, 0, onwrite, errnoval);
}
+static bool bootloader_keystrokes_pollhup(libxl__egc *egc,
+ libxl__datacopier_state *dc, int onwrite)
+{
+libxl__bootloader_state *bl = CONTAINER_OF(dc, *bl, keystrokes);
+bootloader_copyfail(egc, bootloader input, bl, 0, onwrite, -1);
Is there no valid errno here?
-1 is documented way of indicating a POLLHUP.
It's a bit of a shame that callers which don't care about specific
pollhup handling have to provide two practically identical handlers.
Up until this patch, all users either provided no POLLHUP handler, or
provided the same handler for both function pointers.
Is there any mileage in suggesting that the default callback type used
for copyfail too might return a bool too in order that they can be
shared? Even if it must always return True.
Or perhaps some method to indicate that on pollhup, if pollhip callback
is NULL, use the regular callback? (where some method might be the
pollhup_callback==NULL itself?)
Previously, every callback was issued after the datacopier had already
been killed. Now, the pollhup callback is called before the kill has
occurred, and is able to prevent the kill from happening.
A different and far less invasive approach might be to have a per-fd
revent ignore mask. This would at least allow the callbacks to be made
when the datacopier is in a consistent state.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/6] tools/libxl: Fix datacopier POLLHUP handling to not always be fatal
On Fri, 2015-02-20 at 13:55 +, Andrew Cooper wrote: It's a bit of a shame that callers which don't care about specific pollhup handling have to provide two practically identical handlers. Up until this patch, all users either provided no POLLHUP handler, or provided the same handler for both function pointers. Yes, and I'm saying it is a shame that those in the latter class now have to provide two callbacks instead of the one they used before. Is there any mileage in suggesting that the default callback type used for copyfail too might return a bool too in order that they can be shared? Even if it must always return True. Or perhaps some method to indicate that on pollhup, if pollhip callback is NULL, use the regular callback? (where some method might be the pollhup_callback==NULL itself?) Previously, every callback was issued after the datacopier had already been killed. Now, the pollhup callback is called before the kill has occurred, and is able to prevent the kill from happening. A different and far less invasive approach might be to have a per-fd revent ignore mask. This would at least allow the callbacks to be made when the datacopier is in a consistent state. Ian, any thoughts on this? ___ 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 20.02.15 at 14:45, ian.campb...@citrix.com wrote:
(Jan, curious if you have any thoughts on this, hopefully I've left
sufficient context for you to get what we are on about, the gist is we
need some way for dom0 and Xen to agree on how a PCI segment ID maps to
an actual PCI root controller, I think on x86 you either Just Know from
PC legacy or ACPI tells you?)
Yeah, without information from ACPI we'd have no way to know how
to access the config space of segments other than 0. Both I/O port
based access methods don't have room for specifying a segment
number. Since the MMCFG addresses get set up by firmware, it is
also firmware telling us the segment numbers. If you don't get them
arranged in any particular order, ...
On Fri, 2015-02-20 at 18:31 +0530, Manish Jaggi wrote:
I have added ABI that segment no maps to the position on pci node in xen
device tree. We had partially discussed about this during Linaro
connect. What is your teams view on this, should this be ok or we
introduce a property in device tree pci node {xen_segment_id = 1}
The DT node ordering cannot be relied on this way, so we certainly need
something else.
Ideally we should find a solution which doesn't require new properties.
The best solution would be to find some existing property of the PCI
host controller which is well defined and unique to each host
controller. I had been thinking that the base address of the PCI CFG
space might be a good enough handle.
... this approach would seem reasonable.
The only question is whether the data type used for segment id in the
hypercall ABI is wide enough for this, and it seems to be u16 :-(. I'm
not sure if we are going to be able to make this pci_segment_t and have
it differ for ARM.
Are you expecting to have more than 64k segments? Otherwise,
just sequentially assign segment numbers as you discover them or
get them reported by Dom0. You could even have Dom0 tell you
the segment numbers (just like we do on x86), thus eliminating the
need for an extra mechanism for Dom0 to learn them.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/13] xen/arm: Resync the SMMU driver with the Linux one
On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: I've applied the first four here: fda2934 xen/arm: device: Rename device_type into device_class 100f2a6 xen/dt: Extend dt_device_match to possibly store data 62d4269 xen/arm: vgic: Drop unecessary include asm/device.h 256bdee xen/arm: gic-v2: Change the device name in DT_DEVICE_START In theory #5 (the one which temporarily removes the driver) could go in too but I think it is best to at least batch that up with the reintroduction of the driver. For v4 if you are able to shuffle some of the (almost-)acked helper stuff (e.g. #6, #7, #8 here) to the front then those can likely be applied straight away too. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 13/13] xen/iommu: smmu: Advertise when the SMMU support coherent table walk
On 20/02/15 14:13, Ian Campbell wrote: On Fri, 2015-02-20 at 14:07 +, Julien Grall wrote: On 20/02/15 13:34, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: @@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct dt_device_node *dev, if ( !rc ) iommu_set_ops(arm_smmu_iommu_ops); + /* + * The last added SMMU is the first element of arm_smmu_devices. + * It's not necessary to take the lock because only the boot CPU is + * initialized the SMMU devices. Why is only the last added SMMU of interest? Do we not need to take the union and/or intersection of them all? It's already the case. The function arm_smmu_dt_init is called on every SMMU. So the last added SMMU is the one we are currently added. Why do we not just have it in our hand and have to go scrobbling round in a list then? [..] Rather than making assumptions about the list ordering and if we can't just get hold of the smmu pointer directly from arm_smmu_dt_init then I'd prefer an explicit walk of the list at some appropriate point after everything has been registered up. Because that would require to modify more heavily arm_smmu_dt_init. Given that we control the way we add the SMMU in the list, the explicit walk sounds pointless. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/13] xen/arm: Resync the SMMU driver with the Linux one
Hi Ian, On 20/02/15 14:15, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: I've applied the first four here: fda2934 xen/arm: device: Rename device_type into device_class 100f2a6 xen/dt: Extend dt_device_match to possibly store data 62d4269 xen/arm: vgic: Drop unecessary include asm/device.h 256bdee xen/arm: gic-v2: Change the device name in DT_DEVICE_START Thanks! In theory #5 (the one which temporarily removes the driver) could go in too but I think it is best to at least batch that up with the reintroduction of the driver. Right, For v4 if you are able to shuffle some of the (almost-)acked helper stuff (e.g. #6, #7, #8 here) to the front then those can likely be applied straight away too. I could be able to move #6 before, but the other it would prefer to avoid. I have decided to revert the SMMU before #6 to avoid modifying the SMMU drivers. I agree that makes more patch without the SMMU support but it's the resulting patch are more cleaner. Regards, -- Julien Grall ___ 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 Fri, 2015-02-20 at 12:20 +, Julien Grall wrote: Overall, I would prefer to have a separate file and structure for handling PCI host. Also, I think we could re-use the Linux code for this purpose. (caveat; I've not looked at the code yet) I had expected that PCI host controllers would be discovered via the existing device model stuff and compatible string matching, e.g. DT_DEVICE_START(some_pcihost, SOME PCI HOST CONTROLLER, DEVICE_PCIBUS) which would reference a set of compatible strings and a probe function, the probe function would then call some pci bus registration function to hook that bus into the system. Ian. ___ 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
(Jan, curious if you have any thoughts on this, hopefully I've left
sufficient context for you to get what we are on about, the gist is we
need some way for dom0 and Xen to agree on how a PCI segment ID maps to
an actual PCI root controller, I think on x86 you either Just Know from
PC legacy or ACPI tells you?)
On Fri, 2015-02-20 at 18:31 +0530, Manish Jaggi wrote:
I have added ABI that segment no maps to the position on pci node in xen
device tree. We had partially discussed about this during Linaro
connect. What is your teams view on this, should this be ok or we
introduce a property in device tree pci node {xen_segment_id = 1}
The DT node ordering cannot be relied on this way, so we certainly need
something else.
Ideally we should find a solution which doesn't require new properties.
The best solution would be to find some existing property of the PCI
host controller which is well defined and unique to each host
controller. I had been thinking that the base address of the PCI CFG
space might be a good enough handle.
The only question is whether the data type used for segment id in the
hypercall ABI is wide enough for this, and it seems to be u16 :-(. I'm
not sure if we are going to be able to make this pci_segment_t and have
it differ for ARM.
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would take e.g. the PCI CFG base
address and return a new u16 segment id to be used for all subsequent
PCI related calls. This would require the dom0 OS to hook its
pci_bus_add function, which might be doable (more doable than handling
xen_segment_id DT properties I think).
I'm not sure if this ends up being different on ACPI, where perhaps
MMCONFIG or some other table actually gives us a segment ID for each PCI
bus. Ideally whatever solution we end up with would fit into this model.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 10/13] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices
On Fri, 2015-02-20 at 13:34 +, Julien Grall wrote: On 20/02/15 12:35, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: From: Andreas Herrmann andreas.herrm...@calxeda.com If DT information lists one stream ID twice for the master devices of an SMMU this can cause a multi match when stream ID matching is used. For stream ID indexing this might trigger an overwrite of an S2CR that is already in use. So better check for duplicates when DT information is parsed. Taken from the linux ML: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226099.html Cc: Andreas Herrmann herrmann.der.u...@googlemail.com Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com Signed-off-by: Julien Grall julien.gr...@linaro.org I think you were going to drop this one as it is not strictly required? I'm still not entirely clear on the motivation for this patch, looking at the v2 thread I see But, the developer made have written by mistake twice the streamid for the device. which I think you were saying that the DT might, hypothetically, be wrong and have duplicated IDs, is that right? Is it a hypothetical problem or have we seen it in a real device-tree? It's an hypothetical problem. The algo on the next patch won't work correctly otherwise. Then lets drop, thanks. I may need to rework a bit the next patch if we drop it. Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 05/13] xen/iommu: arm: Remove temporary the SMMU driver
On Fri, 2015-02-20 at 12:53 +, Julien Grall wrote: Hi Ian, On 20/02/15 12:18, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: The current SMMU driver has completly diverged. That makes me hard to maintain. Will this temporarily regress anything in a noticeable way? I think it'll just potentially make some hypothetical platform switch back to 1:1 dom0 mode, which in practice they all use anyway, IOW no harm done, even temporarily. So: We still have to keep the 1:1 DOM0 mapping with SMMU. It's because we don't know if all devices are protected. The only possible regression is the SMMU node won't be remove from DOM0 and threfore may be used by Linux. Aside that there is no different for the user. Might that cause issues? The main thing I'm worried about is if the bisector is searching a range which includes this change looking for some unrelated change and this commit causes some sort of spurious issue or perturbation which confuses the bisector. Perhaps a temporary stub could be put in which just marks SMMUs as used by Xen but doesn't actually use them? Signed-off-by: Julien Grall julien.gr...@linaro.org Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 12/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver
Hi Ian,
On 20/02/15 13:23, Ian Campbell wrote:
On Fri, 2015-02-06 at 13:20 +, Stefano Stabellini wrote:
+#define iommu_group_get_iommudata(group) (group)-cfg
I would move all the Xen stuff at the beginning of the file or maybe to
a separate file. You could #include the linux smmu driver into it.
Maybe we cannot have runtime patching of this file, but at least we can
keep Xen and Linux stuff clearly separate.
I was going to suggest something similar e.g. #include ssmu-xen-shim.h
or something.
See my comment on Stefano's mail for this.
static DEFINE_SPINLOCK(arm_smmu_devices_lock);
static LIST_HEAD(arm_smmu_devices);
@@ -455,6 +690,8 @@ static void parse_driver_options(struct arm_smmu_device
*smmu)
static struct device_node *dev_get_dev_node(struct device *dev)
{
+ /* Xen: TODO: Add support for PCI */
+#if 0
if (dev_is_pci(dev)) {
struct pci_bus *bus = to_pci_dev(dev)-bus;
@@ -462,7 +699,7 @@ static struct device_node *dev_get_dev_node(struct
device *dev)
bus = bus-parent;
return bus-bridge-parent-of_node;
}
-
+#endif
Would it be possible instead to add:
#define dev_is_pci (0)
above among the Xen definitions?
Would be preferable if possible.
It's already done but ... if (0) doesn't mean the code inside the if
could be invalid.
In this specific case, we don't have a field struct pci_bus *bus in our
pci_dev. So it won't compile.
@@ -700,11 +938,10 @@ static irqreturn_t arm_smmu_context_fault(int irq,
void *dev)
/* Retry or terminate any stalled transactions */
if (fsr FSR_SS)
writel_relaxed(resume, cb_base + ARM_SMMU_CB_RESUME);
-
- return ret;
}
For the sake of minimizing the changes to Linux functions, could you
write a wrapper around this function instead? That might allow you to
remove the changes related to the return value.
typedef void irqreturn_t; and #define IRQ_NONE /**/ etc perhaps?
Or even just cast the function in the call to request_irq, the differing
return type shouldn't cause a problem in this context I think.
I can give a look.
+/* Xen: Page tables are shared with the processor */
+#if 0
static void arm_smmu_flush_pgtable(struct arm_smmu_device *smmu, void
*addr,
size_t size)
{
@@ -749,6 +987,7 @@ static void arm_smmu_flush_pgtable(struct
arm_smmu_device *smmu, void *addr,
DMA_TO_DEVICE);
}
}
+#endif
But then you need to fix all the call sites. I think it is best to add a
return at the beginning of the function.
Or add a nop stub... (return sounds better though)
I don't succeed to make my point on this kind of things...
While I agree that we have to minimize the changes in the code. We
shouldn't do it at the cost of an incomprehensible cost.
The function arm_smmu_flush_pgtable doesn't make any sense at all on Xen
(the parameter are even invalid).
Furthermore there is only one call site.
+#if CONFIG_ARM_32
+ /* Xen: Midway is using 40-bit address space.
I'm a bit surprised that the upstream driver isn't prepared to cope with
this sort of thing, there are a few LPAE arm32 systems around these
days. I had the same thought around the /* Xen: The fault address
maybe higher than 32 bits on arm32 */ comment too.
At the time I resynced the SMMU drivers, they were using short page
tables. And therefore the number of address bits was limited for the guest.
I don't plan to lose again minimum 2 weeks for re-syncing the driver soon.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2 1/3] xen: mark pvscsi frontend request consumed only after last read
On 17/02/15 07:02, Juergen Gross wrote: A request in the ring buffer mustn't be read after it has been marked as consumed. Otherwise it might already have been reused by the frontend without violating the ring protocol. To avoid inconsistencies in the backend only work on a private copy of the request. This will ensure a malicious guest not being able to bypass consistency checks of the backend by modifying an active request. Applied to stable/for-linus-3.20 and tagged for stable, thanks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 11/13] xen/iommu: smmu: Introduce automatic stream-id-masking
On Fri, 2015-02-20 at 13:42 +, Julien Grall wrote: - Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs. This former is the field used to configure SRMS Cc: Andreas Herrmann herrmann.der.u...@googlemail.com Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com Signed-off-by: Julien Grall julien.gr...@linaro.org --- This patch was sent on Linux ML back to January 2014. It has never been pushed upstream as it was only useful for Calxeda. I know that until know Calxeda has been our only platform with an SMMU, but that is no longer the case, so I'm not really convinced we want to carry divergence from the upstream driver just for the benefit of this effectively obsolete platform. Nothing prevent a platform to use more streamids than the number the number of stream matching registers. It appears that Calxeda is only one for now. But it may change later... About diverging, Linux is moving fast on the SMMU drivers and rework often. We will diverge quickly from the code. Actually 3.20 reworked heavily the driver, but I don't plan to resync the code again for Xen 4.6 (I would loose at least 2 weeks for it). As Calxeda is the only platform we have which support SMMU for now. I'm doing all my work on it, so this patch is useful for me. I appreciate that, but does that mean we need to take code for an already obsolete platform into mainline Xen when there are at least 2 platforms very close on the horizon which will eventually fill this niche just as well? The SMMU used to protect the SATA on this platform has more stream id than the number of stream matching registers. Therefore we have to use stream id masking to configure correctly all the stream IDs. What controls which stream IDs are used by the SATA h/w when issuing requests? Can we constrain it somehow (ideally by omitting them from the DT) to only use a subset of the stream IDs, such that the number used is less than the number of matching registers? The StreamIDs is controlled by the device. It identifies a stream of transactions which originate from a device. I understand that. What I mean is, if an SMMU has e.g. 4 stream ids (0x1, 0x2, 0x3, 0x4) and protects e.g. a single SATA device, what determines which stream id a given DMA originating from that SATA device uses? i.e. is it one of: 1. The SATA device uses a single hardcoded (in silicon) stream ID, the other three are unused,redundant. 2. The SATA device can only use a single stream ID which is configured somehow by software (either firmware or OS driver). 3. The SATA device can use multiple hardcoded stream IDs and a given DMA uses one of them based up $ALGORITHMN. 4. The SATA device can use multiple stream IDs as configured by the OS driver. 5. Something else... ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v18 05/16] x86/VPMU: Interface for setting PMU mode and flags
On 16.02.15 at 23:26, boris.ostrov...@oracle.com wrote:
--- a/xen/arch/x86/hvm/svm/vpmu.c
+++ b/xen/arch/x86/hvm/svm/vpmu.c
@@ -253,6 +253,26 @@ static int amd_vpmu_save(struct vpmu_struct *vpmu)
return 1;
}
+static void amd_vpmu_unload(struct vpmu_struct *vpmu)
+{
+struct vcpu *v;
+
+if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED | VPMU_FROZEN) )
+{
+unsigned int i;
+
+for ( i = 0; i num_counters; i++ )
+wrmsrl(ctrls[i], 0);
+context_save(vpmu);
This assumes vpmu_vcpu(vpmu) == current, yet it looks like you're
also calling it under different circumstances now.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1183,11 +1183,10 @@ int vmx_read_guest_msr(u32 msr, u64 *val)
return -ESRCH;
}
-int vmx_write_guest_msr(u32 msr, u64 val)
+int vmx_write_guest_msr_vcpu(struct vcpu *v, u32 msr, u64 val)
{
-struct vcpu *curr = current;
-unsigned int i, msr_count = curr-arch.hvm_vmx.msr_count;
-struct vmx_msr_entry *msr_area = curr-arch.hvm_vmx.msr_area;
+unsigned int i, msr_count = v-arch.hvm_vmx.msr_count;
+struct vmx_msr_entry *msr_area = v-arch.hvm_vmx.msr_area;
for ( i = 0; i msr_count; i++ )
{
Same here - while the code itself is only accessing memory, it
remains unclear whether correct behavior results when the subject
vCPU is actually executing.
In both cases, if there are restrictions on the conditions under
which unload can validly be done, I think you should ASSERT()
those conditions (at once making them explicit).
+long do_xenpmu_op(unsigned int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t)
arg)
+{
+int ret;
+struct xen_pmu_params pmu_params;
+
+if ( vpmu_disabled )
+return -EINVAL;
EOPNOTSUPP perhaps?
And I agree with Dietmar that keeping opt_vpmu_enabled instead
of introducing vpmu_disabled would seem more natural, the more
that the default is disabled.
+/* Context switch */
+static inline void vpmu_switch_from(struct vpmu_struct *prev,
+struct vpmu_struct *next)
+{
+if ( vpmu_mode (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+vpmu_save(prev);
+}
+
+static inline void vpmu_switch_to(struct vpmu_struct *prev,
+ struct vpmu_struct *next)
+{
+if ( vpmu_mode (XENPMU_MODE_SELF | XENPMU_MODE_HV) )
+vpmu_load(next);
+else if ( vpmu_is_set(next, VPMU_CONTEXT_LOADED | VPMU_RUNNING) )
+vpmu_unload(next);
I don't recall there having been an unload path here, and I don't
see this being explained anywhere either. Wouldn't that more
naturally be done in the switch-from function?
Apart from that it's also not clear why both prev and next get
passed to both of these functions. Iirc a later patch may make
use of that, but then that later patch should add the second
function parameter.
--- a/xen/include/xlat.lst
+++ b/xen/include/xlat.lst
@@ -109,6 +109,7 @@
?pmu_cntr_pair arch-x86/pmu.h
?pmu_intel_ctxt arch-x86/pmu.h
?pmu_regsarch-x86/pmu.h
+?pmu_params pmu.h
Apparently I overlooked this in earlier patches and revision: The
entries in this file are (mostly) alphabetically sorted (by filename,
then by structure name). Please don't make the situation worse
than it already is.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 12/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver
On 20/02/15 13:29, Ian Campbell wrote:
On Mon, 2015-02-09 at 23:40 +0800, Julien Grall wrote:
Hi Stefano,
On 06/02/2015 21:20, Stefano Stabellini wrote:
On Fri, 30 Jan 2015, Julien Grall wrote:
-static int force_stage;
-module_param_named(force_stage, force_stage, int, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(force_stage,
- Force SMMU mappings to be installed at a particular stage of
translation. A value of '1' or '2' forces the corresponding stage. All
other values are ignored (i.e. no stage is forced). Note that selecting a
specific stage will disable support for nested translation.);
for the sake of minimizing the diff, I would add
#define module_param_named(a, b, c, d)
#define MODULE_PARM_DESC(a, b)
to the Xen definitions above
We still have to drop force_stage because it will get unused and won't
compile.
So it's not too bad to remove the 2 other lines.
You currently redefine it as a const int -- is it really unused?
This variable is only read to force the driver to use the specify stage
(1 or 2).
On Xen, we only want to use stage-2. The driver will bail out if the
SMMU doesn't support it.
All the Xen code is beginning with /* Xen: */. Though, I could add a /*
Xen: End */ to make the separation clearer.
BTW, I was thinking to suggest replacing all the #if 0 with #ifndef
CONFIG_XEN or something, which might make some of the comments shorter
or even mean they aren't really needed.
Either way I would write it as:
#if 0 /* Xen: Comment comment */
(similarly any if (0) ...)
I prefer the #if 0 /* Xen: */
For the sake of minimizing the changes to Linux functions, could you
write a wrapper around this function instead? That might allow you to
remove the changes related to the return value.
We should avoid to try to minimize the code against the clarity of the
code...
The change you suggest would require to modify the caller of this
function, which is less clearer than this one.
Given an original function foo can you do
static void foo(void)
{
original code, unmodified
}
static void foo_wrapper(void)
{
wrapper
foo_orig
wrapper
}
#define foo foo_wrapper
or something along those lines?
There is some case where we need to modify the original function. So I'm
not sure it worth to add more line just for a wrapper.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 05/13] xen/iommu: arm: Remove temporary the SMMU driver
On 20/02/15 14:06, Ian Campbell wrote: On Fri, 2015-02-20 at 13:53 +, Julien Grall wrote: On 20/02/15 13:47, Ian Campbell wrote: On Fri, 2015-02-20 at 12:53 +, Julien Grall wrote: The main thing I'm worried about is if the bisector is searching a range which includes this change looking for some unrelated change and this commit causes some sort of spurious issue or perturbation which confuses the bisector. Perhaps a temporary stub could be put in which just marks SMMUs as used by Xen but doesn't actually use them? The changes for SMMU on the Calxeda DT never reached upstream. So at the moment, we don't have any device tree with SMMU nodes inside. So it won't impact to the bisector. Great, thanks. Maybe not worthy of the main changelog, but could you put it after the --- so I don't forget and ask the same thing next time please. Will do. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 21/29] Ovmf/Xen: move XenBusDxe to abstract XENIO_PROTOCOL
On Thu, Feb 12, 2015 at 07:19:13PM +0800, Ard Biesheuvel wrote: While Xen on Intel uses a virtual PCI device to communicate the base address of the grant table, the ARM implementation uses a DT node, which is fundamentally incompatible with the way XenBusDxe is implemented, i.e., as a UEFI Driver Model implementation for a PCI device. Contributed-under: TianoCore Contribution Agreement 1.0 Acked-by: Laszlo Ersek ler...@redhat.com Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org Reviewed-by: Anthony PERARD anthony.per...@citrix.com -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] EPT question - XENMEM_get_access_op
[snip] On Fri, Feb 20, 2015 at 5:21 PM, Jan Beulich jbeul...@suse.com wrote: Thanks Jan! Is there a way for a memevents channel consumer to get access to the L1 (OS Page tables). Hardly. I presume we'll need to walk the page tables, I suspect the current access_op is broken without it and may not be returning anything meaningful in most of the cases It's not broken in any way, you just seem to have wrong expectations. Probably, because I am interested in the final protection as seen by an application or kernel and I'm trying to find a way to get that information. For me the effective permission set is of interest. Balbir ___ 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 Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
On 20.02.15 at 14:45, ian.campb...@citrix.com wrote:
(Jan, curious if you have any thoughts on this, hopefully I've left
sufficient context for you to get what we are on about, the gist is we
need some way for dom0 and Xen to agree on how a PCI segment ID maps to
an actual PCI root controller, I think on x86 you either Just Know from
PC legacy or ACPI tells you?)
Yeah, without information from ACPI we'd have no way to know how
to access the config space of segments other than 0. Both I/O port
based access methods don't have room for specifying a segment
number. Since the MMCFG addresses get set up by firmware, it is
also firmware telling us the segment numbers. If you don't get them
arranged in any particular order, ...
On Fri, 2015-02-20 at 18:31 +0530, Manish Jaggi wrote:
I have added ABI that segment no maps to the position on pci node in xen
device tree. We had partially discussed about this during Linaro
connect. What is your teams view on this, should this be ok or we
introduce a property in device tree pci node {xen_segment_id = 1}
The DT node ordering cannot be relied on this way, so we certainly need
something else.
Ideally we should find a solution which doesn't require new properties.
The best solution would be to find some existing property of the PCI
host controller which is well defined and unique to each host
controller. I had been thinking that the base address of the PCI CFG
space might be a good enough handle.
... this approach would seem reasonable.
The only question is whether the data type used for segment id in the
hypercall ABI is wide enough for this, and it seems to be u16 :-(. I'm
not sure if we are going to be able to make this pci_segment_t and have
it differ for ARM.
Are you expecting to have more than 64k segments?
If we were to use the PCI CFG base address as the handle for a segment
then we would need a 64 bit field is all, it would of course be very
sparse ;-).
Otherwise,
just sequentially assign segment numbers as you discover them or
get them reported by Dom0. You could even have Dom0 tell you
the segment numbers (just like we do on x86),
Aha, how does this work on x86 then? I've been looking for a hypercall
which dom0 uses to tell Xen about PCI segments to no avail (I just find
ones for registering actual devices).
If there is an existing mechanism on x86 and it suits (or nearly so)
then I am entirely in favour of using it.
Ian.
thus eliminating the
need for an extra mechanism for Dom0 to learn them.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 34715: regressions - FAIL
flight 34715 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34715/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 34629 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail like 34629 test-armhf-armhf-libvirt 13 guest-destroyfail like 34529 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-sedf 10 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 10 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 10 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 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-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-armhf-armhf-xl-multivcpu 10 migrate-support-checkfail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass test-amd64-amd64-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-libvirt 10 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemut-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-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen 4f3d3612e6e1311440f0c268a7bf950d3c760839 baseline version: xen cb34a7c8d741aa447d79e1b01d71168a4088a4d7 People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Elena Ufimsteva ufimts...@gmail.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Wei Liu wei.l...@citrix.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-oldkern pass build-i386-oldkern 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 pass 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-amd64pass 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
Re: [Xen-devel] [PATCH v3 00/13] xen/arm: Resync the SMMU driver with the Linux one
On Fri, 2015-02-20 at 14:19 +, Julien Grall wrote: For v4 if you are able to shuffle some of the (almost-)acked helper stuff (e.g. #6, #7, #8 here) to the front then those can likely be applied straight away too. I could be able to move #6 before, but the other it would prefer to avoid. I have decided to revert the SMMU before #6 to avoid modifying the SMMU drivers. I agree that makes more patch without the SMMU support but it's the resulting patch are more cleaner. It's up to you either way. Ian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 13/13] xen/iommu: smmu: Advertise when the SMMU support coherent table walk
On Fri, 2015-02-20 at 14:15 +, Julien Grall wrote: On 20/02/15 14:13, Ian Campbell wrote: On Fri, 2015-02-20 at 14:07 +, Julien Grall wrote: On 20/02/15 13:34, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: @@ -2896,6 +2911,16 @@ static __init int arm_smmu_dt_init(struct dt_device_node *dev, if ( !rc ) iommu_set_ops(arm_smmu_iommu_ops); +/* + * The last added SMMU is the first element of arm_smmu_devices. + * It's not necessary to take the lock because only the boot CPU is + * initialized the SMMU devices. Why is only the last added SMMU of interest? Do we not need to take the union and/or intersection of them all? It's already the case. The function arm_smmu_dt_init is called on every SMMU. So the last added SMMU is the one we are currently added. Why do we not just have it in our hand and have to go scrobbling round in a list then? [..] Rather than making assumptions about the list ordering and if we can't just get hold of the smmu pointer directly from arm_smmu_dt_init then I'd prefer an explicit walk of the list at some appropriate point after everything has been registered up. Because that would require to modify more heavily arm_smmu_dt_init. Given that we control the way we add the SMMU in the list, In a different bit of code on the other side of an ABI. the explicit walk sounds pointless. Regards, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v18 05/16] x86/VPMU: Interface for setting PMU mode and flags
On 16.02.15 at 23:26, boris.ostrov...@oracle.com wrote:
+long do_xenpmu_op(unsigned int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t)
arg)
+{
+int ret;
+struct xen_pmu_params pmu_params;
+
+if ( vpmu_disabled )
+return -EINVAL;
+
+ret = xsm_pmu_op(XSM_OTHER, current-domain, op);
+if ( ret )
+return ret;
+
+/* Check major version when parameters are specified */
+switch ( op )
+{
+case XENPMU_mode_set:
+case XENPMU_feature_set:
+if ( copy_from_guest(pmu_params, arg, 1) )
+return -EFAULT;
+
+if ( pmu_params.version.maj != XENPMU_VER_MAJ )
+return -EINVAL;
+}
+
+switch ( op )
+{
+case XENPMU_mode_set:
+{
+unsigned int old_mode;
+static DEFINE_SPINLOCK(xenpmu_mode_lock);
+
+if ( pmu_params.val ~(XENPMU_MODE_SELF | XENPMU_MODE_HV) )
I btw also highly doubt that all compiler versions can properly track
the pmu_params is not used uninitialized here.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v18 07/16] x86/VPMU: Initialize PMU for PV(H) guests
On 16.02.15 at 23:26, boris.ostrov...@oracle.com wrote:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -437,6 +437,8 @@ int vcpu_initialise(struct vcpu *v)
vmce_init_vcpu(v);
}
+spin_lock_init(v-arch.vpmu.vpmu_lock);
This would rather seem to belong into vpmu_initialize().
@@ -503,6 +509,16 @@ int __init amd_vpmu_init(void)
return -EINVAL;
}
+if ( sizeof(struct xen_pmu_data) +
+ 2 * sizeof(uint64_t) * num_counters PAGE_SIZE )
+{
+printk(XENLOG_WARNING
+ VPMU: Register bank does not fit into VPMU shared page\n);
+counters = ctrls = NULL;
+num_counters = 0;
+return -ENOSPC;
+}
Wouldn't it be more reasonable to simply lower num_counters in
that case?
+static int pvpmu_init(struct domain *d, xen_pmu_params_t *params)
+{
+struct vcpu *v;
+struct vpmu_struct *vpmu;
+struct page_info *page;
+uint64_t gfn = params-val;
+
+if ( vpmu_mode == XENPMU_MODE_OFF )
+return -EINVAL;
+
+if ( (params-vcpu = d-max_vcpus) || (d-vcpu == NULL) ||
+ (d-vcpu[params-vcpu] == NULL) )
+return -EINVAL;
+
+if ( v-arch.vpmu.xenpmu_data )
+return -EINVAL;
+
+page = get_page_from_gfn(d, gfn, NULL, P2M_ALLOC);
+if ( !page )
+return -EINVAL;
+
+if ( !get_page_type(page, PGT_writable_page) )
+{
+put_page(page);
+return -EINVAL;
+}
+
+v = d-vcpu[params-vcpu];
+vpmu = vcpu_vpmu(v);
+spin_lock(vpmu-vpmu_lock);
+
+v-arch.vpmu.xenpmu_data = __map_domain_page_global(page);
+if ( !v-arch.vpmu.xenpmu_data )
+{
+put_page_and_type(page);
+spin_unlock(vpmu-vpmu_lock);
+return -EINVAL;
+}
+
+vpmu_initialise(v);
+
+spin_unlock(vpmu-vpmu_lock);
So what is this lock guarding against here? Certainly not overwriting
of a non-NULL v-arch.vpmu.xenpmu_data (and hence leaking a
page reference)...
@@ -504,7 +590,7 @@ long do_xenpmu_op(unsigned int op,
XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg)
if ( copy_to_guest(arg, pmu_params, 1) )
return -EFAULT;
-break;
+ break;
???
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 20.02.15 at 15:26, ian.campb...@citrix.com wrote: On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote: Otherwise, just sequentially assign segment numbers as you discover them or get them reported by Dom0. You could even have Dom0 tell you the segment numbers (just like we do on x86), Aha, how does this work on x86 then? I've been looking for a hypercall which dom0 uses to tell Xen about PCI segments to no avail (I just find ones for registering actual devices). But that's the one, plus the MMCFG reporting one (PHYSDEVOP_pci_mmcfg_reserved). Without ACPI, how do you know on ARM how to access config space for a particular segment? 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 Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote: Another option might be a new hypercall (assuming one doesn't already exist) to register a PCI bus which would take e.g. the PCI CFG base address and return a new u16 segment id to be used for all subsequent PCI related calls. This would require the dom0 OS to hook its pci_bus_add function, which might be doable (more doable than handling xen_segment_id DT properties I think). This seems ok, i will try it out. I recommend you let this subthread (e.g. the conversation with Jan) settle upon a preferred course of action before implementing any one suggestion. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v18 12/16] x86/VPMU: Merge vpmu_rdmsr and vpmu_wrmsr
On 16.02.15 at 23:26, boris.ostrov...@oracle.com wrote:
--- a/xen/arch/x86/hvm/vpmu.c
+++ b/xen/arch/x86/hvm/vpmu.c
@@ -100,65 +100,48 @@ void vpmu_lvtpc_update(uint32_t val)
apic_write(APIC_LVTPC, vpmu-hw_lapic_lvtpc);
}
-int vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, uint64_t supported)
+int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
+uint64_t supported, bool_t is_write)
{
-struct vcpu *curr = current;
+struct vcpu *curr;
struct vpmu_struct *vpmu;
+struct arch_vpmu_ops *ops;
const
+int ret = 0;
if ( !(vpmu_mode (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
-return 0;
+goto nop;
+curr = current;
This should remain the initializer of the variable.
vpmu = vcpu_vpmu(curr);
-if ( vpmu-arch_vpmu_ops vpmu-arch_vpmu_ops-do_wrmsr )
-{
-int ret = vpmu-arch_vpmu_ops-do_wrmsr(msr, msr_content, supported);
-
-/*
- * We may have received a PMU interrupt during WRMSR handling
- * and since do_wrmsr may load VPMU context we should save
- * (and unload) it again.
- */
-if ( !is_hvm_vcpu(curr) vpmu-xenpmu_data
- (vpmu-xenpmu_data-pmu.pmu_flags PMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu-arch_vpmu_ops-arch_vpmu_save(vpmu);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-
-return 0;
-}
-
-int vpmu_do_rdmsr(unsigned int msr, uint64_t *msr_content)
-{
-struct vcpu *curr = current;
-struct vpmu_struct *vpmu;
+ops = vpmu-arch_vpmu_ops;
+if ( !ops )
+goto nop;
+
+if ( is_write ops-do_wrmsr )
+ret = ops-do_wrmsr(msr, *msr_content, supported);
+else if ( !is_write ops-do_rdmsr )
+ret = ops-do_rdmsr(msr, msr_content);
+else
+goto nop;
-if ( !(vpmu_mode (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+/*
+ * We may have received a PMU interrupt while handling MSR access
+ * and since do_wr/rdmsr may load VPMU context we should save
+ * (and unload) it again.
+ */
+if ( !is_hvm_vcpu(curr)
+ vpmu-xenpmu_data (vpmu-xenpmu_data-pmu.pmu_flags
PMU_CACHED) )
{
-*msr_content = 0;
-return 0;
+vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
+ops-arch_vpmu_save(vpmu);
+vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
}
-vpmu = vcpu_vpmu(curr);
-if ( vpmu-arch_vpmu_ops vpmu-arch_vpmu_ops-do_rdmsr )
-{
-int ret = vpmu-arch_vpmu_ops-do_rdmsr(msr, msr_content);
+return ret;
-if ( !is_hvm_vcpu(curr) vpmu-xenpmu_data
- (vpmu-xenpmu_data-pmu.pmu_flags PMU_CACHED) )
-{
-vpmu_set(vpmu, VPMU_CONTEXT_SAVE);
-vpmu-arch_vpmu_ops-arch_vpmu_save(vpmu);
-vpmu_reset(vpmu, VPMU_CONTEXT_SAVE | VPMU_CONTEXT_LOADED);
-}
-return ret;
-}
-else
+ nop:
+if ( !is_write )
*msr_content = 0;
This could easily be done at the beginning of the function, avoiding
the need for the (kind of odd) nop label.
-
return 0;
Please don't delete blank lines before return statements.
With those changes
Acked-by: Jan Beulich jbeul...@suse.com
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 10/13] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices
On Fri, Feb 20, 2015 at 01:34:16PM +, Julien Grall wrote: On 20/02/15 12:35, Ian Campbell wrote: On Fri, 2015-01-30 at 18:49 +, Julien Grall wrote: From: Andreas Herrmann andreas.herrm...@calxeda.com If DT information lists one stream ID twice for the master devices of an SMMU this can cause a multi match when stream ID matching is used. For stream ID indexing this might trigger an overwrite of an S2CR that is already in use. So better check for duplicates when DT information is parsed. Taken from the linux ML: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-January/226099.html Cc: Andreas Herrmann herrmann.der.u...@googlemail.com Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com Signed-off-by: Julien Grall julien.gr...@linaro.org I think you were going to drop this one as it is not strictly required? I'm still not entirely clear on the motivation for this patch, looking at the v2 thread I see But, the developer made have written by mistake twice the streamid for the device. which I think you were saying that the DT might, hypothetically, be wrong and have duplicated IDs, is that right? Is it a hypothetical problem or have we seen it in a real device-tree? It's an hypothetical problem. The algo on the next patch won't work correctly otherwise. Seconded -- this patch is to avoid potential problems if the DT information is bogus. As the algorithm of the other patch assumes there are no duplicate streamids I needed to double-check it. Of course I had created special DTs containing this kind of error to test the check. I may need to rework a bit the next patch if we drop it. I think it's easier to keep the check when DT information is gathered. Alternative would be to drop it and to be prepared for potential bug reports about multi-match errors or random other problems in case of an overwrite of an already configured S2CR. Andreas ___ 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 Fri, 2015-02-20 at 14:39 +, Jan Beulich wrote:
On 20.02.15 at 15:26, ian.campb...@citrix.com wrote:
On Fri, 2015-02-20 at 14:11 +, Jan Beulich wrote:
Otherwise,
just sequentially assign segment numbers as you discover them or
get them reported by Dom0. You could even have Dom0 tell you
the segment numbers (just like we do on x86),
Aha, how does this work on x86 then? I've been looking for a hypercall
which dom0 uses to tell Xen about PCI segments to no avail (I just find
ones for registering actual devices).
But that's the one,
that == physdev_pci_device_add?
AFAICT that tells Xen about a given device existing on a particular
segment, but doesn't tell Xen any of the properties of that segment.
plus the MMCFG reporting one (PHYSDEVOP_pci_mmcfg_reserved).
This looks promising, but rather under-documented.
#define PHYSDEVOP_pci_mmcfg_reserved24
struct physdev_pci_mmcfg_reserved {
uint64_t address;
uint16_t segment;
uint8_t start_bus;
uint8_t end_bus;
uint32_t flags;
};
I suppose the first 4 fields correspond to entries in the MMCFG table?
Which x86 Xen can parse and so can dom0, so dom0 can then make this
hypercall, passing (address,segment,start_bus,end_bus) to set the flags?
What is address the address of? The CFG space I think?
On ARM with DT I think we only get given address, and something has to
make up segment, start/end_bus I'm not sure where we would get them
from.
So although I think we could perhaps bend this interface to ARMs needs
it would have rather different semantics to x86, i.e. instead of the
key being (address,segment,start_bus,end_bus) and the value being
flags it would be something like key = (address) and value =
(segment,start_bus,end_bus,flags).
I don't think reusing like that would be wise.
Without ACPI, how do you
know on ARM how to access config space for a particular
segment?
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.
So something somewhere needs to make up a segment ID for each PCI bus
and Xen and dom0 need to somehow agree on what the mapping is e.g. by
the one which made up the segment ID telling the other or some other TBD
means.
On x86 you solve this because both Xen and dom0 can parse the same table
and reach the same answer, sadly DT doesn't have everything needed in
it.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v18 14/16] x86/VPMU: NMI-based VPMU support
On 16.02.15 at 23:26, boris.ostrov...@oracle.com wrote:
+int pmu_nmi_interrupt(const struct cpu_user_regs *regs, int cpu)
static
+{
+return vpmu_do_interrupt(regs);
That function returning 1 makes do_nmi() not do _anything_ else, i.e.
ignore eventual SERR or IOCHK events. That's not acceptable. I guess
you'll need to make nmi_callback() return values tristate and adjust
do_nmi() to deal with both cases. Albeit - the other two users are
breaking this too, so perhaps do_nmi() should be adjusted in a prereq
(and backportable) patch to not bail in that case. Yet a tristate may
still be needed, since alternative_instructions() legitimately wants to
suppress them getting handled - it would just need to invoke their
handling once done with patching.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] EPT question - XENMEM_get_access_op
On Fri, Feb 20, 2015 at 3:21 PM, Balbir Singh bsinghar...@gmail.com wrote: [snip] On Fri, Feb 20, 2015 at 5:21 PM, Jan Beulich jbeul...@suse.com wrote: Thanks Jan! Is there a way for a memevents channel consumer to get access to the L1 (OS Page tables). Hardly. I presume we'll need to walk the page tables, I suspect the current access_op is broken without it and may not be returning anything meaningful in most of the cases It's not broken in any way, you just seem to have wrong expectations. Probably, because I am interested in the final protection as seen by an application or kernel and I'm trying to find a way to get that information. For me the effective permission set is of interest. Balbir You can get the guest pagetable permissions via LibVMI: http://libvmi.com/api/#func_vmi_pagetable_lookup_extended Cheers, Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v18 15/16] x86/VPMU: VPMU should not exist when vpmu_initialise() is called
On 16.02.15 at 23:26, boris.ostrov...@oracle.com wrote: We don't need to try to destroy it since it can't be already allocated at the time we try to initialize it. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Suggested-by: Andrew Cooper andrew.coop...@citrix.com --- xen/arch/x86/hvm/vpmu.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/vpmu.c b/xen/arch/x86/hvm/vpmu.c index cdead13..fa34127 100644 --- a/xen/arch/x86/hvm/vpmu.c +++ b/xen/arch/x86/hvm/vpmu.c @@ -480,10 +480,8 @@ void vpmu_initialise(struct vcpu *v) BUILD_BUG_ON(sizeof(struct xen_pmu_regs) XENPMU_REGS_PAD_SZ); BUILD_BUG_ON(sizeof(struct compat_pmu_regs) XENPMU_REGS_PAD_SZ); -if ( vpmu_is_set(vpmu, VPMU_CONTEXT_ALLOCATED) ) -vpmu_destroy(v); -vpmu_clear(vpmu); -vpmu-context = NULL; +ASSERT(!vpmu-flags !vpmu-context); + If this is legitimately a separate patch, it would seem to belong at the beginning of the series. Otherwise it should be integrated into whatever patch arranges for this no longer being possible. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 11/13] xen/iommu: smmu: Introduce automatic stream-id-masking
On 20/02/15 13:55, Ian Campbell wrote: On Fri, 2015-02-20 at 13:42 +, Julien Grall wrote: - Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs. This former is the field used to configure SRMS Cc: Andreas Herrmann herrmann.der.u...@googlemail.com Signed-off-by: Andreas Herrmann andreas.herrm...@calxeda.com Signed-off-by: Julien Grall julien.gr...@linaro.org --- This patch was sent on Linux ML back to January 2014. It has never been pushed upstream as it was only useful for Calxeda. I know that until know Calxeda has been our only platform with an SMMU, but that is no longer the case, so I'm not really convinced we want to carry divergence from the upstream driver just for the benefit of this effectively obsolete platform. Nothing prevent a platform to use more streamids than the number the number of stream matching registers. It appears that Calxeda is only one for now. But it may change later... About diverging, Linux is moving fast on the SMMU drivers and rework often. We will diverge quickly from the code. Actually 3.20 reworked heavily the driver, but I don't plan to resync the code again for Xen 4.6 (I would loose at least 2 weeks for it). As Calxeda is the only platform we have which support SMMU for now. I'm doing all my work on it, so this patch is useful for me. I appreciate that, but does that mean we need to take code for an already obsolete platform into mainline Xen when there are at least 2 platforms very close on the horizon which will eventually fill this niche just as well? I agree that we will have ARM64 board with SMMU very soon. But this is the only ARM32 box the SMMU we have on OSStest. Even though the platform is deprecated, it would be nice if we can catch ARM32 SMMU regression. On a side note, we consider this platform deprecated we should either drop the code from Xen or write on the wiki that we don't fully support it anymore. The SMMU used to protect the SATA on this platform has more stream id than the number of stream matching registers. Therefore we have to use stream id masking to configure correctly all the stream IDs. What controls which stream IDs are used by the SATA h/w when issuing requests? Can we constrain it somehow (ideally by omitting them from the DT) to only use a subset of the stream IDs, such that the number used is less than the number of matching registers? The StreamIDs is controlled by the device. It identifies a stream of transactions which originate from a device. I understand that. What I mean is, if an SMMU has e.g. 4 stream ids (0x1, 0x2, 0x3, 0x4) and protects e.g. a single SATA device, what determines which stream id a given DMA originating from that SATA device uses? i.e. is it one of: 1. The SATA device uses a single hardcoded (in silicon) stream ID, the other three are unused,redundant. 2. The SATA device can only use a single stream ID which is configured somehow by software (either firmware or OS driver). 3. The SATA device can use multiple hardcoded stream IDs and a given DMA uses one of them based up $ALGORITHMN. 4. The SATA device can use multiple stream IDs as configured by the OS driver. 5. Something else... There is a unique ID per-stream. Having multiple streamIDs means multiple DMA request can generated at the same time. The StreamID is decided between the SMMU and the device. We can't interfere and say use only those streamIDs. The only things that a guest can do is associating a specific streamIDs to a context in the SMMU. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/xsm: Generate the permission in a spec-compliant way
On 02/20/2015 10:58 AM, Julien Grall wrote: Each class can contains 32 permisions which are encoded on a word (one bit per permission). Currently the awk script will generate an hexadecimal value for each permission. This may result to generate an invalid value on some version of awk. For instance debian jessie is using a version of mawk where (1 31) will result to 0x7fff. This is because the awk specification requires to do the arithmetic with float. So the resulting integer may vary following the implementation. As the generated headers are only used by C code, generate the permission define via 1UL n. Signed-off-by: Julien Grall julien.gr...@linaro.org The fix looks correct. For backporting: this is only a problem since the auto-generation was moved into the hypervisor build (between 4.2 and 4.3). Prior to this, the headers were manually generated, and apparently nobody ran the script on a system with this bug - in part because nobody ran Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov Wow, that's quite an annoying bug. Thankfully, it's more likely to make a broken system than an insecure one, since doing an access check on the permission 0x7fff will result in checking for access to all 31 other permissions instead of the one you intended to check for. For Xen, it looks like this is unlikely to succeed, and also won't do something like prevent the system from booting: class xen: setscheduler would check kexec others class domain: set_virq_handler would check transition destroy - in the example policy, transition is only allowed for *_building - * - in any other policy, transition is unlikely to be allowed at the same time as destroy There are no other uses of permission bit 32. -- Daniel De Graaf National Security Agency ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 34747: regressions - FAIL
flight 34747 ovmf real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34747/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33686 test-amd64-i386-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33686 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 33686 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf-pin 9 guest-start fail REGR. vs. 33686 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 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-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-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-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-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-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3 14 guest-stopfail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 7 windows-install fail never pass version targeted for testing: ovmf 53596a72cd96f84c7ca83254246f3520a49861b1 baseline version: ovmf 447d264115c476142f884af0be287622cd244423 People who touched revisions under test: Gao, Liming liming@intel.com Long, Qin qin.l...@intel.com Yao, Jiewen jiewen@intel.com Aaron Pop aar...@ami.com Abner Chang abner.ch...@hp.com Alex Williamson alex.william...@redhat.com Anderw Fish af...@apple.com Andrew Fish af...@apple.com Anthony PERARD anthony.per...@citrix.com Ard Biesheuvel ard.biesheu...@linaro.org Ard Biesheuvel a...@linaro.org Ari Zigler a...@mellanox.com Brendan Jackman brendan.jack...@arm.com Bruce Cran bruce.c...@gmail.com Cecil Sheng cecil.sh...@hp.com Chao Zhang chao.b.zh...@intel.com Chao, Zhang chao.b.zh...@intel.com Chen Fan chen.fan.f...@cn.fujitsu.com Chris Phillips chr...@hp.com Chris Ruffin chris.ruf...@intel.com Cinnamon Shia cinnamon.s...@hp.com Daryl McDaniel daryl.mcdan...@intel.com Daryl McDaniel daryl.mcdan...@intel.com daryl.mcdaniel daryl.mcdan...@intel.com daryl.mcdan...@intel.com darylm503 darylm503@Edk2 David Wei david@intel.com David Woodhouse david.woodho...@intel.com Deric Cole deric_c...@phoenix.com Dong Eric eric.d...@intel.com Dong Guo guo.d...@intel.com Dong, Guo guo.d...@intel.com Elvin Li elvin...@intel.com Eric Dong eric.d...@intel.com Erik Bjorge erik.c.bjo...@intel.com Eugene Cohen eug...@hp.com Feng Tian feng.t...@intel.com Feng, Bob C bob.c.f...@intel.com Fu Siyuan siyuan...@intel.com Fu, Siyuan siyuan...@intel.com Gabriel Somlo so...@cmu.edu Gao, Liming liming@intel.com Gao, Liming liming.gao Gao, Liming liming@intel.com Gao, Liming liming@intel.com Garrett Kirkendall garrett.kirkend...@amd.com Gary Lin g...@suse.com Grzegorz Milos gm...@cam.ac.uk Hao Wu hao.a...@intel.com Harry Liebel harry.lie...@arm.com Hess Chen hesheng.c...@intel.com Hot Tian hot.t...@intel.com isakov-sl isakov...@bk.ru isakov...@bk.ru Jaben Carsey jaben.car...@intel.com jcarsey jcarsey jcarsey jcarsey@Edk2 Jeff Bobzin (jeff.bobzin Jeff Bobzin (jeff.bob...@insyde.com) Jeff Bobzin (jeff.bob...@insyde.com) Jeff Fan jeff@intel.com Jiewen Yao jiewen@intel.com Joe Peterson joe.peter...@intel.com Jordan Justen jordan.l.jus...@intel.com jyao1 jyao1 jyao1 jyao1@Edk2 Kinney, Michael D michael.d.kin...@intel.com Larry Cleeton lclee...@microsoft.com Laszlo Ersek ler...@redhat.com Leandro G. Biss Becker lbec...@positivo.com.br Lee Leahy leroy.p.le...@intel.com Leif Lindholm leif.lindh...@linaro.org leroy.p.leahy leroy.p.le...@intel.com
[Xen-devel] [xen-4.3-testing test] 34807: regressions - trouble: blocked/broken/fail/pass
flight 34807 xen-4.3-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34807/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 3 host-install(3)broken REGR. vs. 34190 build-amd64 5 xen-build fail REGR. vs. 34190 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-rumpuserxen 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-sedf-pin 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pv 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xend-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-pv1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a build-i386-rumpuserxen6 xen-buildfail 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-credit2 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-armhf-armhf-xl-midway5 xen-boot fail never pass version targeted for testing: xen 9ebac5765496b34f15b2328f41c00f789ed6d712 baseline version: xen ef73de2a84a3042c3481c9a521e8e0c756b793f2 People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Boris Ostrovsky boris.ostrov...@oracle.com Ian Jackson ian.jack...@eu.citrix.com jobs: build-amd64
