[Xen-devel] [PATCH v7 2/2] OSSTest: push successful raisin builds
Determine the most recent raisin revision that needs to be tested, by comparing
with the already tested xen-tested-master branch. Push to
raisin.git:xen-tested-master when the build is successful.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
ap-common|3 +++
ap-fetch-version |3 +++
ap-fetch-version-old |5 +
ap-print-url |3 +++
ap-push |5 +
cr-daily-branch |8
cri-common |1 +
7 files changed, 28 insertions(+)
diff --git a/ap-common b/ap-common
index 6e1c472..34613bf 100644
--- a/ap-common
+++ b/ap-common
@@ -48,6 +48,8 @@
# (ie ones which need $bodges=1 in ts-rumpuserxen-build)
: ${TREE_RAISIN:=git://xenbits.xen.org/raisin.git}
+: ${PUSH_TREE_RAISIN:=$XENBITS:/home/xen/git/raisin.git}
+: ${BASE_TREE_RAISIN:=$TREE_RAISIN}
: ${TREE_SEABIOS_UPSTREAM:=git://git.seabios.org/seabios.git}
: ${PUSH_TREE_SEABIOS:=$XENBITS:/home/xen/git/osstest/seabios.git}
@@ -84,6 +86,7 @@ fi
: ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
: ${LOCALREV_SEABIOS:=daily-cron.$branch}
: ${LOCALREV_OVMF:=daily-cron.$branch}
+: ${LOCALREV_RAISIN:=daily-cron.$branch}
: ${TREEBASE_LINUX_XCP:=http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27}
diff --git a/ap-fetch-version b/ap-fetch-version
index 33aaf00..fffbbcf 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -80,6 +80,9 @@ libvirt)
rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$TREE_RUMPUSERXEN master $LOCALREV_RUMPUSERXEN
+raisin)
+ repo_tree_rev_fetch_git raisin \
+ $TREE_RAISIN master $LOCALREV_RAISIN
;;
seabios)
repo_tree_rev_fetch_git seabios \
diff --git a/ap-fetch-version-old b/ap-fetch-version-old
index 0b4739b..9a2544d 100755
--- a/ap-fetch-version-old
+++ b/ap-fetch-version-old
@@ -29,6 +29,7 @@ select_xenbranch
: ${BASE_LOCALREV_LINUX:=daily-cron.$branch.old}
: ${BASE_LOCALREV_LIBVIRT:=daily-cron.$branch.old}
: ${BASE_LOCALREV_RUMPUSERXEN:=daily-cron.$branch.old}
+: ${BASE_LOCALREV_RAISIN:=daily-cron.$branch.old}
: ${BASE_LOCALREV_SEABIOS:=daily-cron.$branch.old}
: ${BASE_LOCALREV_OVMF:=daily-cron.$branch.old}
@@ -89,6 +90,10 @@ rumpuserxen)
repo_tree_rev_fetch_git rumpuserxen \
$BASE_TREE_RUMPUSERXEN xen-tested-master
$BASE_LOCALREV_RUMPUSERXEN
;;
+raisin)
+ repo_tree_rev_fetch_git raisin \
+ $BASE_TREE_RAISIN xen-tested-master $BASE_LOCALREV_RAISIN
+ ;;
seabios)
repo_tree_rev_fetch_git seabios \
$BASE_TREE_SEABIOS xen-tested-master $BASE_LOCALREV_SEABIOS
diff --git a/ap-print-url b/ap-print-url
index 3db2375..e999b65 100755
--- a/ap-print-url
+++ b/ap-print-url
@@ -55,6 +55,9 @@ libvirt)
rumpuserxen)
echo $TREE_RUMPUSERXEN
;;
+raisin)
+ echo $TREE_RAISIN
+ ;;
seabios)
echo $TREE_SEABIOS_UPSTREAM
;;
diff --git a/ap-push b/ap-push
index c141464..c869a8b 100755
--- a/ap-push
+++ b/ap-push
@@ -37,6 +37,7 @@ TREE_LIBVIRT=$PUSH_TREE_LIBVIRT
TREE_RUMPUSERXEN=$PUSH_TREE_RUMPUSERXEN
TREE_SEABIOS=$PUSH_TREE_SEABIOS
TREE_OVMF=$PUSH_TREE_OVMF
+TREE_RAISIN=$PUSH_TREE_RAISIN
if info_linux_tree $branch; then
cd $repos/linux
@@ -89,6 +90,10 @@ rumpuserxen)
cd $repos/rumpuserxen
git push $TREE_RUMPUSERXEN $revision:xen-tested-master
;;
+raisin)
+ cd $repos/raisin
+ git push $TREE_RAISIN $revision:xen-tested-master
+ ;;
seabios)
cd $repos/seabios
git push $TREE_SEABIOS $revision:refs/heads/xen-tested-master
diff --git a/cr-daily-branch b/cr-daily-branch
index c7d1071..0b7bb78 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -164,6 +164,10 @@ if [ x$REVISION_RUMPUSERXEN = x ]; then
determine_version REVISION_RUMPUSERXEN rumpuserxen RUMPUSERXEN
export REVISION_RUMPUSERXEN
fi
+if [ x$REVISION_RAISIN = x ]; then
+ determine_version REVISION_RAISIN raisin RAISIN
+ export REVISION_RAISIN
+fi
if [ x$REVISION_LINUXFIRMWARE = x ]; then
determine_version REVISION_LINUXFIRMWARE linuxfirmware LINUXFIRMWARE
export REVISION_LINUXFIRMWARE
@@ -209,6 +213,10 @@ rumpuserxen)
export REVISION_LINUX_OLD=disable
export REVISION_LIBVIRT=disable
;;
+raisin)
+ realtree=raisin
+ NEW_REVISION=$REVISION_RAISIN
+ ;;
seabios)
realtree=seabios
NEW_REVISION=$REVISION_SEABIOS
diff --git a/cri-common b/cri-common
index ad44546..c091622 100644
--- a/cri-common
+++ b/cri-common
@@ -70,6 +70,7 @@ select_xenbranch () {
linuxfirmware) tree=linuxfirmware; xenbranch=xen-unstable ;;
libvirt)tree=libvirt; xenbranch=xen-unstable ;;
rumpuserxen) tree=rumpuserxen; xenbranch=xen-unstable ;;
+ raisin) tree=raisin;xenbranch=xen-unstable ;;
seabios)tree=seabios; xenbranch=xen-unstable ;;
ovmf)
[Xen-devel] [PATCH v7 1/2] OSSTEST: introduce a raisin build test
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Changes in v7:
- update raisin git url after http://marc.info/?l=xen-develm=143472251602803
Changes in v6:
- move divide to Osstest/BuildSupport.pm and rename it to
divide_xen_build; use divide_xen_build in ts-raisin-build and
ts-xen-build.
Changes in v5:
- remove setting DEFAULT_REVISION_RAISIN to master
- disable raisin when branch is not xen*
- do not overwrite raisin default variables unless both revision_* and
tree_* are set of a given component
Changes in v4:
- introduce enable_raisin in mfi-common: only build raisin when building
xen-unstable
- start off from the default raisin config, then append osstest config
options to it
- do not write variable to the raisin config if the conrresponding
runvar is not set
- remove TREE_OVMF and TREE_SEABIOS
Changes in v3:
- use $raisindir throughout ts-raisin-build
- do not specify ENABLED_COMPONENTS so that empty REVISION variables can
be used to disable building a raisin component
Changes in v2:
- set revision_* variables in mfi-common;
- in ts-raisin-build set the *_REVISION config options based on the
revision_* variables;
- in ts-raisin-build, call store_revision appropriately;
- divide the output in an hypervisor and a tools tarball.
---
Osstest/BuildSupport.pm | 48 +
ap-common |2 +
mfi-common | 41 +++
sg-run-job |5 ++
ts-raisin-build | 133 +++
ts-xen-build| 44 +---
6 files changed, 231 insertions(+), 42 deletions(-)
create mode 100755 ts-raisin-build
diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
index 933f6e1..76a3feb 100644
--- a/Osstest/BuildSupport.pm
+++ b/Osstest/BuildSupport.pm
@@ -43,6 +43,10 @@ BEGIN {
xendist
$xendist
+ divide_xen_build
+ trapping
+ die_if_fail
+
submodulefixup submodule_have submodule_find
);
@@ -84,6 +88,50 @@ sub xendist () {
($ho, 'xendist', '', $r{buildjob});
}
+sub divide_xen_build ($$) {
+my ($subdir, $postfix) = @_;
+# Only move hv to xeninstall, so that we can have
+# xenpolicy in tools tarball.
+#
+# The files inside boot/ after `make dist' are
+# xen-$XEN_VERSION: Xen binary
+# xen.gz/xen: symlink to xen-$XEN_VERSION
+# xen-$MAJOR: symlink to xen-$XEN_VERSION
+# xen-$MAJOR.$MINOR: symlink to xen-$XEN_VERSION
+# xen-sym-$XEN_VERSION: Xen symbol
+# xenpolicy-$XEN_VERSION: flask policy binary if xsm is enabled
+#
+# So the following snippet will leave xenpolicy* in
+# install/boot and get packaged to tools tarball.
+target_cmd_build($ho, 100, $builddir, END);
+cd $subdir
+mkdir xen$postfix
+for f in *$postfix; do
+mkdir -p \$f/lib
+done
+if test -d $postfix/boot; then
+if test -f $postfix/boot/xen.gz || test -f $postfix/boot/xen; then
+mkdir xen$postfix/boot
+mvfiles=`find $postfix/boot -name 'xen[a-z]*' -prune -o -name
'xen*' -print`
+mv \$mvfiles xen$postfix/boot/.
+fi
+fi
+END
+}
+
+our @probs;
+
+sub trapping ($) {
+my ($sub) = @_;
+my $tok= eval { $sub-(); 1; };
+if (!$tok) { push @probs, $@; print STDERR failure (trapped): $@\n; }
+}
+
+sub die_if_fail () {
+die *** something failed:\n\n.(join \n\n,@probs).\n** something
failed
+if @probs;
+}
+
#- submodules -
sub submodulefixup () {
diff --git a/ap-common b/ap-common
index 64749e3..6e1c472 100644
--- a/ap-common
+++ b/ap-common
@@ -47,6 +47,8 @@
# rumpsrc-related runvars needed only for old rumpuser-xen
# (ie ones which need $bodges=1 in ts-rumpuserxen-build)
+: ${TREE_RAISIN:=git://xenbits.xen.org/raisin.git}
+
: ${TREE_SEABIOS_UPSTREAM:=git://git.seabios.org/seabios.git}
: ${PUSH_TREE_SEABIOS:=$XENBITS:/home/xen/git/osstest/seabios.git}
: ${BASE_TREE_SEABIOS:=git://xenbits.xen.org/osstest/seabios.git}
diff --git a/mfi-common b/mfi-common
index 16fc8c5..d75823d 100644
--- a/mfi-common
+++ b/mfi-common
@@ -148,6 +148,22 @@ create_build_jobs () {
*) enable_ovmf=true;
esac
+case $xenbranch in
+xen-3.*-testing) enable_raisin=false;;
+xen-4.0-testing) enable_raisin=false;;
+xen-4.1-testing) enable_raisin=false;;
+xen-4.2-testing) enable_raisin=false;;
+xen-4.3-testing) enable_raisin=false;;
+xen-4.4-testing) enable_raisin=false;;
+xen-4.5-testing) enable_raisin=false;;
+*) enable_raisin=true;
+esac
+case $branch in
+xen*) ;;
+*) enable_raisin=false;;
+esac
+
+
eval
arch_runvars=\\$ARCH_RUNVARS_$arch\
@@ -215,6 +231,31 @@ create_build_jobs () {
fi
+if [ x$REVISION_RAISIN != xdisable ] [
Re: [Xen-devel] [xen-unstable test] 58821: tolerable FAIL
On Mon, 2015-06-22 at 14:09 +, osstest service user wrote: flight 58821 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/58821/ [...] test-amd64-amd64-libvirt 11 guest-start fail like 58789 http://logs.test-lab.xenproject.org/osstest/logs/58821/test-amd64-amd64-libvirt/info.html While investigating why libvirt hasn't been succeeding very well on merlot* I came across some things in the serial log which initially struck me as odd, but which I suspect are nothing (or at least not terribly relevant), if someone could confirm that would be great. Firstly is: Jun 22 12:41:09.633294 (XEN) microcode: CPU2 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.665099 (XEN) microcode: CPU4 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.729089 (XEN) microcode: CPU6 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.793224 (XEN) microcode: CPU8 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.857118 (XEN) microcode: CPU10 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.921123 (XEN) microcode: CPU12 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.985563 (XEN) microcode: CPU14 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:10.049212 (XEN) microcode: CPU16 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:10.121106 (XEN) microcode: CPU18 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:10.185059 (XEN) microcode: CPU20 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:10.249070 (XEN) microcode: CPU22 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:10.313063 (XEN) microcode: CPU24 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:10.393217 (XEN) microcode: CPU26 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:10.457126 (XEN) microcode: CPU28 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:10.521228 (XEN) microcode: CPU30 updated from revision 0x6000822 to 0x6000832 i.e. only even numbered cpus are updated. (0 was done earlier in boot). I suspect that the answer here is hyperthreading, and the cpuinfo shows all cpus have in fact been updated. So I think that's just a red-herring. The second thing is: Jun 22 12:41:10.601103 (XEN) Brought up 32 CPUs Jun 22 12:41:10.625270 (XEN) Testing NMI watchdog on all CPUs: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 stuck i.e. at least one CPU has issues with NMI watchdog (looking at other runs it seems to vary between 29-31). Is this just that the NMI watchdog doesn't deal well with so many pCPUs? Or is it a real issue? Lastly the eventual '0' pressed - dumping Dom0's registers thing only seems to dump cpus 0..9 (inclusive). It seems to vary a bit. I suspect this is another didn't wait long enough thing, possibly on the osstest end. Ian. [0] http://logs.test-lab.xenproject.org/osstest/logs/58821/test-amd64-amd64-libvirt/serial-merlot1.log ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC v1 11/13] xen/libxl: allow creating HVM guests without a device model
Intorduce a new device model version (NONE) that can be used to specify that
no device model should be used. Propagate this to Xen by creating a new
XEN_DOMCTL_CDF_noemu flag that disables some of the emulation done inside of
Xen.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
IMHO the XEN_DOMCTL_CDF_noemu flag should be expanded into multiple smaller
flags that can be used to disable specific emulated devices, like the
vlapic, vioapic, vhpet...
Also hvm_mmio_handlers should become domain specific in order to populate it
with the usable handlers only.
---
tools/libxl/libxl.c | 7 +++
tools/libxl/libxl_create.c | 16
tools/libxl/libxl_dom.c | 6 ++
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 2 ++
xen/arch/x86/domain.c| 2 +-
xen/arch/x86/hvm/hvm.c | 14 +-
xen/arch/x86/hvm/intercept.c | 6 ++
xen/common/domctl.c | 5 -
xen/include/asm-x86/hvm/domain.h | 1 +
xen/include/asm-x86/hvm/hvm.h| 2 +-
xen/include/public/domctl.h | 3 +++
xen/include/xen/sched.h | 4
13 files changed, 57 insertions(+), 12 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d86ea62..7c83486 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1587,11 +1587,10 @@ void libxl__destroy_domid(libxl__egc *egc,
libxl__destroy_domid_state *dis)
switch (libxl__domain_type(gc, domid)) {
case LIBXL_DOMAIN_TYPE_HVM:
-if (!libxl_get_stubdom_id(CTX, domid))
-dm_present = 1;
-else
+if (libxl_get_stubdom_id(CTX, domid)) {
dm_present = 0;
-break;
+break;
+}
case LIBXL_DOMAIN_TYPE_PV:
pid = libxl__xs_read(gc, XBT_NULL, libxl__sprintf(gc,
/local/domain/%d/image/device-model-pid, domid));
dm_present = (pid != NULL);
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 86384d2..06cf02c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -164,6 +164,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
b_info-u.hvm.bios = LIBXL_BIOS_TYPE_ROMBIOS; break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
b_info-u.hvm.bios = LIBXL_BIOS_TYPE_SEABIOS; break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+break;
default:return ERROR_INVAL;
}
@@ -177,6 +179,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
if (b_info-u.hvm.bios == LIBXL_BIOS_TYPE_ROMBIOS)
return ERROR_INVAL;
break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+break;
default:abort();
}
@@ -278,6 +282,9 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
break;
}
break;
+case LIBXL_DEVICE_MODEL_VERSION_NONE:
+b_info-video_memkb = 0;
+break;
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
default:
switch (b_info-u.hvm.vga.kind) {
@@ -535,6 +542,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config
*d_config,
/* convenience aliases */
libxl_domain_create_info *info = d_config-c_info;
+libxl_domain_build_info *b_info = d_config-b_info;
assert(!libxl_domid_valid_guest(*domid));
@@ -549,6 +557,8 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config
*d_config,
flags |= XEN_DOMCTL_CDF_hvm_guest;
flags |= libxl_defbool_val(info-hap) ? XEN_DOMCTL_CDF_hap : 0;
flags |= libxl_defbool_val(info-oos) ? 0 : XEN_DOMCTL_CDF_oos_off;
+if (b_info-device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE)
+flags |= XEN_DOMCTL_CDF_noemu;
} else if (libxl_defbool_val(info-pvh)) {
flags |= XEN_DOMCTL_CDF_pvh_guest;
if (!libxl_defbool_val(info-hap)) {
@@ -1293,6 +1303,12 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
libxl__device_console_add(gc, domid, console, state, device);
libxl__device_console_dispose(console);
+if (d_config-b_info.device_model_version ==
+LIBXL_DEVICE_MODEL_VERSION_NONE) {
+domcreate_devmodel_started(egc, dcs-dmss.dm, 0);
+return;
+}
+
libxl_device_vkb_init(vkb);
libxl__device_vkb_add(gc, domid, vkb);
libxl_device_vkb_dispose(vkb);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index
[Xen-devel] [PATCH RFC v1 12/13] xen: allow 64bit HVM guests to use XENMEM_memory_map
Enable this hypercall for 64bit HVM guests in order to fetch the e820 memory
map in the absence of an emulated BIOS. The memory map is populated and
notified to Xen in arch_setup_meminit_hvm.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
I see no reason to not enable it for 32bit HVM guests, but let's leave that
for later.
---
tools/libxc/xc_dom_x86.c | 29 -
xen/arch/x86/hvm/hvm.c | 1 -
xen/arch/x86/mm.c| 6 --
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 0d9ec42..3a57ded 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -1154,6 +1154,7 @@ static int check_mmio_hole(uint64_t start, uint64_t
memsize,
return 1;
}
+#define MAX_E820_ENTRIES128
static int arch_setup_meminit_hvm(struct xc_dom_image *dom)
{
unsigned long i, vmemid, nr_pages = dom-total_pages;
@@ -1174,6 +1175,8 @@ static int arch_setup_meminit_hvm(struct xc_dom_image
*dom)
unsigned int nr_vmemranges, nr_vnodes;
xc_interface *xch = dom-xch;
uint32_t domid = dom-guest_domid;
+struct e820entry entries[MAX_E820_ENTRIES];
+int e820_index = 0;
if ( nr_pages target_pages )
memflags |= XENMEMF_populate_on_demand;
@@ -1224,6 +1227,13 @@ static int arch_setup_meminit_hvm(struct xc_dom_image
*dom)
vnode_to_pnode = dom-vnode_to_pnode;
}
+/* Add one additional memeory range to account for the VGA hole */
+if ( (nr_vmemranges + (dom-vga_hole ? 1 : 0)) MAX_E820_ENTRIES )
+{
+DOMPRINTF(Too many memory ranges);
+goto error_out;
+}
+
total_pages = 0;
p2m_size = 0;
for ( i = 0; i nr_vmemranges; i++ )
@@ -1313,9 +1323,13 @@ static int arch_setup_meminit_hvm(struct xc_dom_image
*dom)
* Under 2MB mode, we allocate pages in batches of no more than 8MB to
* ensure that we can be preempted and hence dom0 remains responsive.
*/
-if ( dom-vga_hole )
+if ( dom-vga_hole ) {
rc = xc_domain_populate_physmap_exact(
xch, domid, 0xa0, 0, memflags, dom-p2m_host[0x00]);
+entries[e820_index].addr = 0;
+entries[e820_index].size = 0xa0 PAGE_SHIFT;
+entries[e820_index++].type = E820_RAM;
+}
stat_normal_pages = 0;
for ( vmemid = 0; vmemid nr_vmemranges; vmemid++ )
@@ -1342,6 +1356,12 @@ static int arch_setup_meminit_hvm(struct xc_dom_image
*dom)
else
cur_pages = vmemranges[vmemid].start PAGE_SHIFT;
+/* Build an e820 map. */
+entries[e820_index].addr = cur_pages PAGE_SHIFT;
+entries[e820_index].size = vmemranges[vmemid].end -
+ entries[e820_index].addr;
+entries[e820_index++].type = E820_RAM;
+
while ( (rc == 0) (end_pages cur_pages) )
{
/* Clip count to maximum 1GB extent. */
@@ -1459,6 +1479,13 @@ static int arch_setup_meminit_hvm(struct xc_dom_image
*dom)
DPRINTF( 2MB PAGES: 0x%016lx\n, stat_2mb_pages);
DPRINTF( 1GB PAGES: 0x%016lx\n, stat_1gb_pages);
+rc = xc_domain_set_memory_map(xch, domid, entries, e820_index);
+if ( rc != 0 )
+{
+DOMPRINTF(unable to set memory map.);
+goto error_out;
+}
+
rc = 0;
goto out;
error_out:
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7694c9e..98109e2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4749,7 +4749,6 @@ static long hvm_memory_op(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
switch ( cmd MEMOP_CMD_MASK )
{
-case XENMEM_memory_map:
case XENMEM_machine_memory_map:
case XENMEM_machphys_mapping:
return -ENOSYS;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 9e08c9b..fcb8682 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4717,12 +4717,6 @@ long arch_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
return rc;
}
-if ( is_hvm_domain(d) )
-{
-rcu_unlock_domain(d);
-return -EPERM;
-}
-
e820 = xmalloc_array(e820entry_t, fmap.map.nr_entries);
if ( e820 == NULL )
{
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/6] AMD-PVH: Support TSC_MODE_NEVER_EMULATE for PVH
On Mon, Jun 22, 2015 at 12:37:37PM -0400, elena.ufimts...@oracle.com wrote:
From: Elena Ufimtseva elena.ufimts...@oracle.com
On AMD, MSR_AMD64_TSC_RATIO must be set for rdtsc instruction in guest
to properly read the cpu tsc. To that end, set tsc_khz in struct domain.
It looks like the TSC_MODE_DEFAULT, TSC_MODE_ALWAYS_EMULATE, and
TSC_MODE_PVRDTSCP already set tsc_khz.
Only TSC_MODE_NEVER_EMULATE hadn't set it (but that
piece of code has some continuation from TSC_MODE_DEFAULT).
And we need this otherwise the CPU tsc offset has bogus data?
Anyway if this is the way to go, you can probably delete:
1968 d-arch.tsc_khz = cpu_khz;
Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
xen/arch/x86/time.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index bbb7e6c..d9709ce 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1923,6 +1923,7 @@ void tsc_set_info(struct domain *d,
* but always_emulate does not for some reason. Figure out
* why.
*/
+d-arch.tsc_khz = cpu_khz;
switch ( tsc_mode )
{
case TSC_MODE_NEVER_EMULATE:
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 58821: tolerable FAIL
On 22.06.15 at 17:17, ian.campb...@citrix.com wrote: On Mon, 2015-06-22 at 14:09 +, osstest service user wrote: flight 58821 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/58821/ [...] test-amd64-amd64-libvirt 11 guest-start fail like 58789 http://logs.test-lab.xenproject.org/osstest/logs/58821/test-amd64-amd64-libv irt/info.html While investigating why libvirt hasn't been succeeding very well on merlot* I came across some things in the serial log which initially struck me as odd, but which I suspect are nothing (or at least not terribly relevant), if someone could confirm that would be great. Firstly is: Jun 22 12:41:09.633294 (XEN) microcode: CPU2 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.665099 (XEN) microcode: CPU4 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.729089 (XEN) microcode: CPU6 updated from revision 0x6000822 to 0x6000832 [...] i.e. only even numbered cpus are updated. (0 was done earlier in boot). I suspect that the answer here is hyperthreading, and the cpuinfo shows all cpus have in fact been updated. Yes (albeit hyperthreading is an Intel term, but iirc the same applies to the two cores per compute unit). The second thing is: Jun 22 12:41:10.601103 (XEN) Brought up 32 CPUs Jun 22 12:41:10.625270 (XEN) Testing NMI watchdog on all CPUs: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 stuck i.e. at least one CPU has issues with NMI watchdog (looking at other runs it seems to vary between 29-31). Is this just that the NMI watchdog doesn't deal well with so many pCPUs? Or is it a real issue? Very few CPUs properly responding is certainly quite odd; one would expect all or none of them to work. Perhaps our AMD maintainers (now Cc-ed) could take a look... Lastly the eventual '0' pressed - dumping Dom0's registers thing only seems to dump cpus 0..9 (inclusive). It seems to vary a bit. I suspect this is another didn't wait long enough thing, possibly on the osstest end. This looks like an issue with the serial line not coping with the amount of output (and hence dropping bits). Later on in the log there's also quite large an unreadable part, which I would also attribute to such a problem. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC v1 13/13] xenconsole: try to attach to PV console if HVM fails
HVM guests have always used the emulated serial console by default, but if
the emulated serial pty cannot be fetched from xenstore try to use the PV
console instead.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
tools/console/client/main.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/console/client/main.c b/tools/console/client/main.c
index f4c783b..c92553e 100644
--- a/tools/console/client/main.c
+++ b/tools/console/client/main.c
@@ -279,7 +279,7 @@ int main(int argc, char **argv)
{ 0 },
};
- char *dom_path = NULL, *path = NULL;
+ char *dom_path = NULL, *path = NULL, *test = NULL;
int spty, xsfd;
struct xs_handle *xs;
char *end;
@@ -357,9 +357,14 @@ int main(int argc, char **argv)
path = malloc(strlen(dom_path) + strlen(/device/console/0/tty) + 5);
if (path == NULL)
err(ENOMEM, malloc);
- if (type == CONSOLE_SERIAL)
+ if (type == CONSOLE_SERIAL) {
snprintf(path, strlen(dom_path) + strlen(/serial/0/tty) + 5,
%s/serial/%d/tty, dom_path, num);
- else {
+ test = xs_read(xs, XBT_NULL, path, NULL);
+ free(test);
+ if (test == NULL)
+ goto pv_console;
+ } else {
+pv_console:
if (num == 0)
snprintf(path, strlen(dom_path) +
strlen(/console/tty) + 1, %s/console/tty, dom_path);
else
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC v1 10/13] lib{xc/xl}: allow the creation of HVM domains with a kernel
Replace the firmware loaded into HVM guests with an OS kernel. Since the HVM
builder now uses the PV xc_dom_* set of functions this kernel will be parsed
and loaded inside the guest like on PV, but the container is a pure HVM
guest.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
Only xc_dom_elfloader has been switched in order to use hvm-3.0-x86_32,
other loaders need to be adapted also.
---
tools/libxc/xc_dom_elfloader.c | 4
tools/libxl/libxl_dom.c| 17 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
index 6ce1062..2f05015 100644
--- a/tools/libxc/xc_dom_elfloader.c
+++ b/tools/libxc/xc_dom_elfloader.c
@@ -57,6 +57,10 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
{
uint64_t machine = elf_uval(elf, elf-ehdr, e_machine);
+if ( dom-container_type == XC_DOM_HVM_CONTAINER
+ dom-parms.phys_entry != UNSET_ADDR )
+return hvm-3.0-x86_32;
+
switch ( machine )
{
case EM_386:
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 12ede26..8ee14b9 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -874,10 +874,20 @@ static int libxl__domain_firmware(libxl__gc *gc,
}
}
-rc = xc_dom_kernel_file(dom, libxl__abs_path(gc, firmware,
+if (info-kernel != NULL) {
+/* Try to load a kernel instead of the firmware. */
+rc = xc_dom_kernel_file(dom, info-kernel);
+if (rc == 0 info-ramdisk != NULL)
+rc = xc_dom_ramdisk_file(dom, info-ramdisk);
+dom-vga_hole = 0;
+} else {
+rc = xc_dom_kernel_file(dom, libxl__abs_path(gc, firmware,
libxl__xenfirmwaredir_path()));
+dom-vga_hole = 1;
+}
+
if (rc != 0) {
-LOGE(ERROR, xc_dom_kernel_file failed);
+LOGE(ERROR, xc_dom_{kernel_file/ramdisk_file} failed);
goto out;
}
@@ -931,7 +941,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
xc_dom_loginit(ctx-xch);
-dom = xc_dom_allocate(ctx-xch, NULL, NULL);
+dom = xc_dom_allocate(ctx-xch, info-cmdline, NULL);
if (!dom) {
LOGE(ERROR, xc_dom_allocate failed);
goto out;
@@ -974,7 +984,6 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
dom-lowmem_end = lowmem_end;
dom-highmem_end = highmem_end;
dom-mmio_start = mmio_start;
-dom-vga_hole = 1;
if (info-num_vnuma_nodes != 0) {
int i;
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/6] AMD-PVH: call hvm_emulate_one instead of handle_mmio
From: Elena Ufimtseva elena.ufimts...@oracle.com
Certain IOIO instructions and CR access instructions like
lmsw/clts etc need to be emulated. handle_mmio is incorrectly called to
accomplish this. Create svm_emulate() to call hvm_emulate_one which is more
appropriate, and works for pvh as well. handle_mmio call is
forbidden for pvh.
Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
xen/arch/x86/hvm/svm/svm.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 28792fe..e7262c9 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2289,6 +2289,23 @@ static struct hvm_function_table __initdata
svm_function_table = {
.nhvm_hap_walk_L1_p2m = nsvm_hap_walk_L1_p2m,
};
+static void svm_emulate(struct cpu_user_regs *regs)
+{
+int rc;
+struct hvm_emulate_ctxt ctxt;
+
+hvm_emulate_prepare(ctxt, regs);
+rc = hvm_emulate_one(ctxt);
+
+if ( rc != X86EMUL_OKAY )
+{
+ if ( ctxt.exn_pending )
+ hvm_inject_trap(ctxt.trap);
+ else
+ hvm_inject_hw_exception(TRAP_gp_fault, 0);
+}
+}
+
void svm_vmexit_handler(struct cpu_user_regs *regs)
{
uint64_t exit_reason;
@@ -2555,16 +2572,16 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
if ( handle_pio(port, bytes, dir) )
__update_guest_eip(regs, vmcb-exitinfo2 - vmcb-rip);
}
-else if ( !handle_mmio() )
-hvm_inject_hw_exception(TRAP_gp_fault, 0);
+else
+svm_emulate(regs);
break;
case VMEXIT_CR0_READ ... VMEXIT_CR15_READ:
case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE:
if ( cpu_has_svm_decode (vmcb-exitinfo1 (1ULL 63)) )
svm_vmexit_do_cr_access(vmcb, regs);
-else if ( !handle_mmio() )
-hvm_inject_hw_exception(TRAP_gp_fault, 0);
+else
+svm_emulate(regs);
break;
case VMEXIT_INVLPG:
@@ -2575,6 +2592,8 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
}
else if ( !handle_mmio() )
hvm_inject_hw_exception(TRAP_gp_fault, 0);
+ else
+svm_emulate(regs);
break;
case VMEXIT_INVLPGA:
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control
El 19/06/15 a les 16.58, Jan Beulich ha escrit:
On 19.06.15 at 16:07, roger@citrix.com wrote:
I don't mind adding a PHYSDEVOP_pci_mmcfg_reserved call to FreeBSD, but
for it to have any effect we need to stop unconditionally mapping
everything as MMIO regions on PVH Dom0.
Right, I didn't mean to imply PVH would have any chance of working
right now.
But what you didn't respond to is the (kind of implicit I admit) question
of whether FreeBSD is using MMCFG accesses for the low 256 bytes
of the config space. (I note that there's one special case in Linux -
NumaChip - whether this is the case.)
OK, I didn't get the part of the question. AFAICT yes, FreeBSD will
access the low 256 bytes of the config space. For example the stub to
write to a cfg register is as follows:
void
pci_cfgregwrite(int bus, int slot, int func, int reg, u_int32_t data, int bytes)
{
if (cfgmech == CFGMECH_PCIE
(bus = pcie_minbus bus = pcie_maxbus)
(bus != 0 || !(1 slot pcie_badslots)))
pciereg_cfgwrite(bus, slot, func, reg, data, bytes);
else
pcireg_cfgwrite(bus, slot, func, reg, data, bytes);
}
I take that you would prefer it to be:
void
pci_cfgregwrite(int bus, int slot, int func, int reg, u_int32_t data, int bytes)
{
if (cfgmech == CFGMECH_PCIE
(bus = pcie_minbus bus = pcie_maxbus)
(bus != 0 || !(1 slot pcie_badslots))
(reg PCI_REGMAX))
pciereg_cfgwrite(bus, slot, func, reg, data, bytes);
else
pcireg_cfgwrite(bus, slot, func, reg, data, bytes);
}
Where 'PCI_REGMAX' is 255.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: Add AHCI support for upstream qemu
On Mon, 22 Jun 2015, Fabio Fantoni wrote:
Usage:
ahci=0|1 (default=0)
If enabled adds ich9 disk controller in ahci mode and uses it with
upstream qemu to emulate disks instead of ide.
It doesn't support cdroms which still using ide (cdroms will use
-device ide-cd as new qemu parameter)
Ahci requires new qemu parameter but for now other emulated disks cases
remains with old ones (I did it in other patch, not needed by this one)
I did it as libxl parameter disabled by default to avoid possible
problems:
- with save/restore/migration (restoring with ahci a domU that was with
ide instead)
- windows 8 without pv drivers (a registry key change is needed for
AHCI-IDE change FWIK to avoid possible blue screen)
- windows XP or older that many not support ahci by default.
Setting AHCI with libxl parameter and default to disabled seems the best
solution.
AHCI increase hvm domUs boot performance. On linux hvm domU I saw up to
only 20% of the previous total boot time, whereas boot time decrease a
lot on W7 domUs for most of boots I have done. Small difference in boot
time compared to ide mode on W8 and newer (probably other xen
improvements or fixes are needed not ahci related)
Signed-off-by: Fabio Fantoni fabio.fant...@m2r.biz
I am OK with this patch going in Xen 4.6.
docs/man/xl.cfg.pod.5 | 9 +
tools/libxl/libxl.h | 10 ++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_dm.c | 10 +-
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c| 1 +
6 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index a3e0e2e..7e16123 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -904,6 +904,15 @@ default is Bcd.
=back
+=item Bahci=[0|1]
+
+If enabled adds ich9 disk controller in ahci mode and uses it with
+upstream qemu to emulate disks instead of ide. It decrease boot time but
+may be not supported by default in windows xp and older windows.
+The default is disabled (0).
+
+=back
+
=head3 Paging
The following options control the mechanisms used to virtualise guest
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0a7913b..6a3677d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -596,6 +596,16 @@ typedef struct libxl__ctx libxl_ctx;
#define LIBXL_HAVE_SPICE_STREAMINGVIDEO 1
/*
+ * LIBXL_HAVE_AHCI
+ *
+ * If defined, then the u.hvm structure will contain a boolean type:
+ * ahci. This value defines if ahci support is present.
+ *
+ * If this is not defined, the ahci support is ignored.
+ */
+#define LIBXL_HAVE_AHCI 1
+
+/*
* LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS 1
*
* If this is defined, libxl_domain_create_restore()'s API has changed to
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 86384d2..8ca2481 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -331,6 +331,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
libxl_defbool_setdefault(b_info-u.hvm.nested_hvm, false);
libxl_defbool_setdefault(b_info-u.hvm.usb,false);
libxl_defbool_setdefault(b_info-u.hvm.xen_platform_pci, true);
+libxl_defbool_setdefault(b_info-u.hvm.ahci, false);
libxl_defbool_setdefault(b_info-u.hvm.spice.enable, false);
if (!libxl_defbool_val(b_info-u.hvm.spice.enable)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 33f9ce6..93f191a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -818,6 +818,8 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
flexarray_append(dm_args, libxl__sprintf(gc, %PRId64, ram_size));
if (b_info-type == LIBXL_DOMAIN_TYPE_HVM) {
+if (libxl_defbool_val(b_info-u.hvm.ahci))
+flexarray_append_pair(dm_args, -device, ahci,id=ahci0);
for (i = 0; i num_disks; i++) {
int disk, part;
int dev_number =
@@ -872,7 +874,13 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
drive = libxl__sprintf
(gc,
file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback,
pdev_path, disk, format);
-else if (disk 4)
+else if (disk 6 libxl_defbool_val(b_info-u.hvm.ahci)){
One space missing.
This means that we can now have disks up to hdf. I think you should
update the in-code comment above. I think you should also update
docs/txt/misc/vbd-interface.txt, explaining that hd* mean AHCI if ahci=1
is specified.
+flexarray_vappend(dm_args, -drive,
+
GCSPRINTF(file=%s,if=none,id=ahcidisk-%d,format=%s,cache=writeback,
+pdev_path, disk, format), -device,
GCSPRINTF(ide-hd,bus=ahci0.%d,unit=0,drive=ahcidisk-%d,
+
Re: [Xen-devel] [PATCH 1/1] xen-hvm: Add trace to ioreq
On Thu, 30 Apr 2015, Don Slutz wrote:
Signed-off-by: Don Slutz dsl...@verizon.com
(cherry picked from commit b72adbe7510d0a30053d32334665ee887bec9e43)
Acked-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
I'll add it to my queue
trace-events | 7 +++
xen-hvm.c| 21 +
2 files changed, 28 insertions(+)
diff --git a/trace-events b/trace-events
index 30eba92..4666dad 100644
--- a/trace-events
+++ b/trace-events
@@ -932,6 +932,13 @@ xen_map_portio_range(uint32_t id, uint64_t start_addr,
uint64_t end_addr) id: %
xen_unmap_portio_range(uint32_t id, uint64_t start_addr, uint64_t end_addr)
id: %u start: %#PRIx64 end: %#PRIx64
xen_map_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) id: %u
bdf: %02x.%02x.%02x
xen_unmap_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) id:
%u bdf: %02x.%02x.%02x
+handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t
data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
I/O=%p type=%d dir=%d df=%d ptr=%d port=%#PRIx64 data=%#PRIx64 count=%d
size=%d
+handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t
data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
I/O=%p read type=%d df=%d ptr=%d port=%#PRIx64 data=%#PRIx64 count=%d
size=%d
+handle_ioreq_write(void *req, uint32_t type, uint32_t df, uint32_t
data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size)
I/O=%p write type=%d df=%d ptr=%d port=%#PRIx64 data=%#PRIx64 count=%d
size=%d
+cpu_ioreq_pio(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr,
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) I/O=%p pio
dir=%d df=%d ptr=%d port=%#PRIx64 data=%#PRIx64 count=%d size=%d
+cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t addr, uint32_t
size) I/O=%p pio read reg data=%#PRIx64 port=%#PRIx64 size=%d
+cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t
size) I/O=%p pio write reg data=%#PRIx64 port=%#PRIx64 size=%d
+cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr,
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) I/O=%p copy
dir=%d df=%d ptr=%d port=%#PRIx64 data=%#PRIx64 count=%d size=%d
# xen-mapcache.c
xen_map_cache(uint64_t phys_addr) want %#PRIx64
diff --git a/xen-hvm.c b/xen-hvm.c
index 315864c..6fdba98 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -832,9 +832,14 @@ static void cpu_ioreq_pio(ioreq_t *req)
{
uint32_t i;
+trace_cpu_ioreq_pio(req, req-dir, req-df, req-data_is_ptr, req-addr,
+ req-data, req-count, req-size);
+
if (req-dir == IOREQ_READ) {
if (!req-data_is_ptr) {
req-data = do_inp(req-addr, req-size);
+trace_cpu_ioreq_pio_read_reg(req, req-data, req-addr,
+ req-size);
} else {
uint32_t tmp;
@@ -845,6 +850,8 @@ static void cpu_ioreq_pio(ioreq_t *req)
}
} else if (req-dir == IOREQ_WRITE) {
if (!req-data_is_ptr) {
+trace_cpu_ioreq_pio_write_reg(req, req-data, req-addr,
+ req-size);
do_outp(req-addr, req-size, req-data);
} else {
for (i = 0; i req-count; i++) {
@@ -861,6 +868,9 @@ static void cpu_ioreq_move(ioreq_t *req)
{
uint32_t i;
+trace_cpu_ioreq_move(req, req-dir, req-df, req-data_is_ptr, req-addr,
+ req-data, req-count, req-size);
+
if (!req-data_is_ptr) {
if (req-dir == IOREQ_READ) {
for (i = 0; i req-count; i++) {
@@ -933,11 +943,18 @@ static void handle_vmport_ioreq(XenIOState *state,
ioreq_t *req)
static void handle_ioreq(XenIOState *state, ioreq_t *req)
{
+trace_handle_ioreq(req, req-type, req-dir, req-df, req-data_is_ptr,
+ req-addr, req-data, req-count, req-size);
+
if (!req-data_is_ptr (req-dir == IOREQ_WRITE)
(req-size sizeof (target_ulong))) {
req-data = ((target_ulong) 1 (8 * req-size)) - 1;
}
+if (req-dir == IOREQ_WRITE)
+trace_handle_ioreq_write(req, req-type, req-df, req-data_is_ptr,
+ req-addr, req-data, req-count,
req-size);
+
switch (req-type) {
case IOREQ_TYPE_PIO:
cpu_ioreq_pio(req);
@@ -977,6 +994,10 @@ static void handle_ioreq(XenIOState *state, ioreq_t *req)
default:
hw_error(Invalid ioreq type 0x%x\n, req-type);
}
+if (req-dir == IOREQ_READ) {
+trace_handle_ioreq_read(req, req-type, req-df, req-data_is_ptr,
+req-addr, req-data, req-count, req-size);
+}
}
static int handle_buffered_iopage(XenIOState *state)
--
1.8.4
___
Xen-devel mailing list
Re: [Xen-devel] [PATCH v25 04/15] x86/VPMU: Interface for setting PMU mode and flags
On 06/22/2015 11:10 AM, Jan Beulich wrote:
+switch ( op )
+{
+case XENPMU_mode_set:
+{
+if ( (pmu_params.val ~(XENPMU_MODE_SELF | XENPMU_MODE_HV)) ||
+ (hweight64(pmu_params.val) 1) )
+return -EINVAL;
+
+/* 32-bit dom0 can only sample itself. */
+if ( is_pv_32bit_vcpu(current) (pmu_params.val XENPMU_MODE_HV) )
+return -EINVAL;
+
+spin_lock(vpmu_lock);
+
+/*
+ * We can always safely switch between XENPMU_MODE_SELF and
+ * XENPMU_MODE_HV while other VPMUs are active.
+ */
+if ( (vpmu_count == 0) || (vpmu_mode == pmu_params.val) ||
+ ((vpmu_mode ^ pmu_params.val) ==
+ (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+vpmu_mode = pmu_params.val;
+else
+{
I think this would better be
if ( (vpmu_count == 0) ||
((vpmu_mode ^ pmu_params.val) ==
(XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
vpmu_mode = pmu_params.val;
else if ( vpmu_mode != pmu_params.val )
{
But there's no need to re-submit just because of this (it could be
changed upon commit if you agree).
This will generate an error (with a message to the log) even if we keep
the mode unchanged, something that I wanted to avoid. (Same thing for
XENPMU_feature_set, which is what Kevin mentioned last time).
Or wait - I just checked again, and while I thought this was long
addressed I still don't seen struct xen_pmu_params pad field
being checked to be zero as input, and being stored as zero when
only an output. Did this get lost? Did I forget about a reason why
this isn't being done? Unless the latter is the case, the ack above
is dependent upon this getting fixed.
Yes, we did talk about this and as result I added major version check
(which I should have had there anyway): if we decide to start using this
field we'd need to increment the major version.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v25 12/15] x86/VPMU: Handle PMU interrupts for PV(H) guests
On 19.06.15 at 20:44, boris.ostrov...@oracle.com wrote: Add support for handling PMU interrupts for PV(H) guests. VPMU for the interrupted VCPU is unloaded until the guest issues XENPMU_flush hypercall. This allows the guest to access PMU MSR values that are stored in VPMU context which is shared between hypervisor and domain, thus avoiding traps to hypervisor. Since the interrupt handler may now force VPMU context save (i.e. set VPMU_CONTEXT_SAVE flag) we need to make changes to amd_vpmu_save() which until now expected this flag to be set only when the counters were stopped. Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov Acked-by: Kevin Tian kevin.t...@intel.com Acked-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.2-testing test] 58817: FAIL
On 22.06.15 at 08:54, osst...@xenbits.xen.org wrote: flight 58817 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58817/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 58411 This has been repeating for like half a dozen (or even more) flights. Why is this state not getting cleared, considering that all these newer flights were successful, and there were no other blocking failures? And with that - will it ever clear? Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC 3/4] xen: implement SCHEDOP_soft_reset
Jan Beulich jbeul...@suse.com writes: On 03.06.15 at 15:35, vkuzn...@redhat.com wrote: @@ -1129,8 +1129,9 @@ void unmap_vcpu_info(struct vcpu *v) mfn = v-vcpu_info_mfn; unmap_domain_page_global((void *) ((unsigned long)v-vcpu_info PAGE_MASK)); - -v-vcpu_info = dummy_vcpu_info; +v-vcpu_info = ((v-vcpu_id XEN_LEGACY_MAX_VCPUS) +? (vcpu_info_t *)shared_info(d, vcpu_info[v-vcpu_id]) Is this cast really needed? Without it my gcc-4.8.3 complains: domain.c: In function ‘unmap_vcpu_info’: domain.c:1158:21: error: pointer type mismatch in conditional expression [-Werror] : dummy_vcpu_info); ^ cc1: all warnings being treated as errors -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC v1 09/13] elfnotes: intorduce a new PHYS_ENTRY elfnote
This new elfnote contains the 32bit entry point into the kernel. Xen will
use this entry point in order to launch the guest kernel in 32bit protected
mode with paging disabled.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
tools/xcutils/readnotes.c | 3 +++
xen/common/libelf/libelf-dominfo.c | 4
xen/include/public/elfnote.h | 11 ++-
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/tools/xcutils/readnotes.c b/tools/xcutils/readnotes.c
index 5fa445e..863ea5f 100644
--- a/tools/xcutils/readnotes.c
+++ b/tools/xcutils/readnotes.c
@@ -159,6 +159,9 @@ static unsigned print_notes(struct elf_binary *elf,
ELF_HANDLE_DECL(elf_note) st
case XEN_ELFNOTE_L1_MFN_VALID:
print_l1_mfn_valid_note(L1_MFN_VALID, elf , note);
break;
+ case XEN_ELFNOTE_PHYS_ENTRY:
+ print_numeric_note(PHYS_ENTRY, elf , note);
+ break;
default:
printf(unknown note type %#x\n,
(unsigned)elf_uval(elf, note, type));
diff --git a/xen/common/libelf/libelf-dominfo.c
b/xen/common/libelf/libelf-dominfo.c
index 0771323..ca0e327 100644
--- a/xen/common/libelf/libelf-dominfo.c
+++ b/xen/common/libelf/libelf-dominfo.c
@@ -120,6 +120,7 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
[XEN_ELFNOTE_BSD_SYMTAB] = { BSD_SYMTAB, 1},
[XEN_ELFNOTE_SUSPEND_CANCEL] = { SUSPEND_CANCEL, 0 },
[XEN_ELFNOTE_MOD_START_PFN] = { MOD_START_PFN, 0 },
+[XEN_ELFNOTE_PHYS_ENTRY] = { PHYS_ENTRY, 0 },
};
/* *INDENT-ON* */
@@ -213,6 +214,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
elf, note, sizeof(*parms-f_supported), i);
break;
+case XEN_ELFNOTE_PHYS_ENTRY:
+parms-phys_entry = val;
+break;
}
return 0;
}
diff --git a/xen/include/public/elfnote.h b/xen/include/public/elfnote.h
index 3824a94..b5232cd 100644
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -200,9 +200,18 @@
#define XEN_ELFNOTE_SUPPORTED_FEATURES 17
/*
+ * Physical entry point into the kernel.
+ *
+ * 32bit entry point into the kernel. Xen will use this entry point
+ * in order to launch the guest kernel in 32bit protected mode
+ * with paging disabled.
+ */
+#define XEN_ELFNOTE_PHYS_ENTRY 18
+
+/*
* The number of the highest elfnote defined.
*/
-#define XEN_ELFNOTE_MAX XEN_ELFNOTE_SUPPORTED_FEATURES
+#define XEN_ELFNOTE_MAX XEN_ELFNOTE_PHYS_ENTRY
/*
* System information exported through crash notes.
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
Before reading any further, keep in mind this is a VERY inital RFC prototype series. Many things are not finished, and those that are done make heavy use of duck tape in order to keep things into place. Now that you are warned, this series is split in the following order: - Patches from 1 to 7 switch HVM domain contruction to use the xc_dom_* family of functions, like they are used to build PV domains. - Patches from 8 to 13 introduce the creation of HVM domains without firmware, which is replaced by directly loading a kernel like it's done for PV guests. A new boot ABI based on the discussion in the thread RFC: making the PVH 64bit ABI as stable is also introduced, although it's not finished. Some things that are missing from the new boot ABI: - Although it supports loading a ramdisk, there's still now defined way into how to pass this ramdisk to the guest. I'm thinking of using a HVMPARAM or simply setting a GP register to contain the address of the ramdisk. Ideally I would like to support loading more than one ramdisk. Some patches contain comments after the SoB, which in general describe the shortcommings of the implementation. The aim of those is to initiate discussion about whether the aproach taken is TRTTD. I've only tested this on Intel hw, but I see no reason why it shouldn't work on AMD. I've managed to boot FreeBSD up to the point were it should jump into user-space (I just didn't have a VBD attached to the VM so it just sits waiting for a valid disk). I have not tried to boot it any further since I think that's fine for the purpose of this series. The series can also be found in the following git repo: git://xenbits.xen.org/people/royger/xen.git branch hvm_without_dm_v1 And for the FreeBSD part: git://xenbits.xen.org/people/royger/freebsd.git branch new_entry_point_v1 In case someone wants to give it a try, I've uploaded a FreeBSD kernel that should work when booted into this mode: https://people.freebsd.org/~royger/kernel_no_dm The config file that I've used is: config kernel=/path/to/kernel_no_dm builder=hvm device_model_version=none memory=128 vcpus=1 name = freebsd /config Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC v1 08/13] libxc: remove dead x86 HVM code
Remove xc_hvm_build_x86.c since xc_hvm_build is not longer used in order to
create HVM guests.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
tools/libxc/Makefile | 1 -
tools/libxc/include/xenguest.h| 44 ---
tools/libxc/xc_hvm_build_x86.c| 805 --
tools/libxc/xg_private.c | 9 -
tools/python/xen/lowlevel/xc/xc.c | 81
5 files changed, 940 deletions(-)
delete mode 100644 tools/libxc/xc_hvm_build_x86.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 7f860d7..c738c46 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -93,7 +93,6 @@ GUEST_SRCS-y += xc_dom_compat_linux.c
GUEST_SRCS-$(CONFIG_X86) += xc_dom_x86.c
GUEST_SRCS-$(CONFIG_X86) += xc_cpuid_x86.c
-GUEST_SRCS-$(CONFIG_X86) += xc_hvm_build_x86.c
GUEST_SRCS-$(CONFIG_ARM) += xc_dom_arm.c
GUEST_SRCS-$(CONFIG_ARM) += xc_hvm_build_arm.c
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 7581263..d96bf7d 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -233,50 +233,6 @@ struct xc_hvm_firmware_module {
uint64_t guest_addr_out;
};
-struct xc_hvm_build_args {
-uint64_t mem_size; /* Memory size in bytes. */
-uint64_t mem_target; /* Memory target in bytes. */
-uint64_t mmio_size; /* Size of the MMIO hole in bytes. */
-const char *image_file_name; /* File name of the image to load. */
-
-/* Extra ACPI tables passed to HVMLOADER */
-struct xc_hvm_firmware_module acpi_module;
-
-/* Extra SMBIOS structures passed to HVMLOADER */
-struct xc_hvm_firmware_module smbios_module;
-/* Whether to use claim hypercall (1 - enable, 0 - disable). */
-int claim_enabled;
-
-/* vNUMA information*/
-xen_vmemrange_t *vmemranges;
-unsigned int nr_vmemranges;
-unsigned int *vnode_to_pnode;
-unsigned int nr_vnodes;
-
-/* Out parameters */
-uint64_t lowmem_end;
-uint64_t highmem_end;
-uint64_t mmio_start;
-};
-
-/**
- * Build a HVM domain.
- * @parm xch libxc context handle.
- * @parm domiddomain ID for the new domain.
- * @parm hvm_args parameters for the new domain.
- *
- * The memory size and image file parameters are required, the rest
- * are optional.
- */
-int xc_hvm_build(xc_interface *xch, uint32_t domid,
- struct xc_hvm_build_args *hvm_args);
-
-int xc_hvm_build_target_mem(xc_interface *xch,
-uint32_t domid,
-int memsize,
-int target,
-const char *image_name);
-
/*
* Sets *lockfd to -1.
* Has deallocated everything even on error.
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
deleted file mode 100644
index f7616a8..000
--- a/tools/libxc/xc_hvm_build_x86.c
+++ /dev/null
@@ -1,805 +0,0 @@
-/**
- * xc_hvm_build.c
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
- */
-
-#include stddef.h
-#include inttypes.h
-#include stdlib.h
-#include unistd.h
-#include zlib.h
-
-#include xg_private.h
-#include xc_private.h
-
-#include xen/foreign/x86_32.h
-#include xen/foreign/x86_64.h
-#include xen/hvm/hvm_info_table.h
-#include xen/hvm/params.h
-#include xen/hvm/e820.h
-
-#include xen/libelf/libelf.h
-
-#define SUPERPAGE_2MB_SHIFT 9
-#define SUPERPAGE_2MB_NR_PFNS (1UL SUPERPAGE_2MB_SHIFT)
-#define SUPERPAGE_1GB_SHIFT 18
-#define SUPERPAGE_1GB_NR_PFNS (1UL SUPERPAGE_1GB_SHIFT)
-
-#define SPECIALPAGE_PAGING 0
-#define SPECIALPAGE_ACCESS 1
-#define SPECIALPAGE_SHARING 2
-#define SPECIALPAGE_BUFIOREQ 3
-#define SPECIALPAGE_XENSTORE 4
-#define SPECIALPAGE_IOREQ5
-#define SPECIALPAGE_IDENT_PT 6
-#define SPECIALPAGE_CONSOLE 7
-#define NR_SPECIAL_PAGES 8
-#define
[Xen-devel] [PATCH RFC v1 01/13] libxc: split x86 HVM setup_guest into smaller logical functions
This is just a preparatory change to clean up the code in setup_guest.
Should not introduce any functional changes.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
tools/libxc/xc_hvm_build_x86.c | 198 -
1 file changed, 117 insertions(+), 81 deletions(-)
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index 003ea06..f7616a8 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -232,28 +232,20 @@ static int check_mmio_hole(uint64_t start, uint64_t
memsize,
return 1;
}
-static int setup_guest(xc_interface *xch,
- uint32_t dom, struct xc_hvm_build_args *args,
- char *image, unsigned long image_size)
+static int xc_hvm_populate_memory(xc_interface *xch, uint32_t dom,
+ struct xc_hvm_build_args *args,
+ xen_pfn_t *page_array)
{
-xen_pfn_t *page_array = NULL;
unsigned long i, vmemid, nr_pages = args-mem_size PAGE_SHIFT;
unsigned long p2m_size;
unsigned long target_pages = args-mem_target PAGE_SHIFT;
-unsigned long entry_eip, cur_pages, cur_pfn;
-void *hvm_info_page;
-uint32_t *ident_pt;
-struct elf_binary elf;
-uint64_t v_start, v_end;
-uint64_t m_start = 0, m_end = 0;
+unsigned long cur_pages, cur_pfn;
int rc;
xen_capabilities_info_t caps;
unsigned long stat_normal_pages = 0, stat_2mb_pages = 0,
stat_1gb_pages = 0;
unsigned int memflags = 0;
int claim_enabled = args-claim_enabled;
-xen_pfn_t special_array[NR_SPECIAL_PAGES];
-xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
uint64_t total_pages;
xen_vmemrange_t dummy_vmemrange[2];
unsigned int dummy_vnode_to_pnode[1];
@@ -261,19 +253,6 @@ static int setup_guest(xc_interface *xch,
unsigned int *vnode_to_pnode;
unsigned int nr_vmemranges, nr_vnodes;
-memset(elf, 0, sizeof(elf));
-if ( elf_init(elf, image, image_size) != 0 )
-{
-PERROR(Could not initialise ELF image);
-goto error_out;
-}
-
-xc_elf_set_logfile(xch, elf, 1);
-
-elf_parse_binary(elf);
-v_start = 0;
-v_end = args-mem_size;
-
if ( nr_pages target_pages )
memflags |= XENMEMF_populate_on_demand;
@@ -346,24 +325,6 @@ static int setup_guest(xc_interface *xch,
goto error_out;
}
-if ( modules_init(args, v_end, elf, m_start, m_end) != 0 )
-{
-ERROR(Insufficient space to load modules.);
-goto error_out;
-}
-
-DPRINTF(VIRTUAL MEMORY ARRANGEMENT:\n);
-DPRINTF( Loader: %016PRIx64-%016PRIx64\n, elf.pstart, elf.pend);
-DPRINTF( Modules: %016PRIx64-%016PRIx64\n, m_start, m_end);
-DPRINTF( TOTAL:%016PRIx64-%016PRIx64\n, v_start, v_end);
-DPRINTF( ENTRY:%016PRIx64\n, elf_uval(elf, elf.ehdr, e_entry));
-
-if ( (page_array = malloc(p2m_size * sizeof(xen_pfn_t))) == NULL )
-{
-PERROR(Could not allocate memory.);
-goto error_out;
-}
-
for ( i = 0; i p2m_size; i++ )
page_array[i] = ((xen_pfn_t)-1);
for ( vmemid = 0; vmemid nr_vmemranges; vmemid++ )
@@ -563,7 +524,54 @@ static int setup_guest(xc_interface *xch,
DPRINTF( 4KB PAGES: 0x%016lx\n, stat_normal_pages);
DPRINTF( 2MB PAGES: 0x%016lx\n, stat_2mb_pages);
DPRINTF( 1GB PAGES: 0x%016lx\n, stat_1gb_pages);
-
+
+rc = 0;
+goto out;
+ error_out:
+rc = -1;
+ out:
+
+/* ensure no unclaimed pages are left unused */
+xc_domain_claim_pages(xch, dom, 0 /* cancels the claim */);
+
+return rc;
+}
+
+static int xc_hvm_load_image(xc_interface *xch,
+ uint32_t dom, struct xc_hvm_build_args *args,
+ xen_pfn_t *page_array)
+{
+unsigned long entry_eip, image_size;
+struct elf_binary elf;
+uint64_t v_start, v_end;
+uint64_t m_start = 0, m_end = 0;
+char *image;
+int rc;
+
+image = xc_read_image(xch, args-image_file_name, image_size);
+if ( image == NULL )
+return -1;
+
+memset(elf, 0, sizeof(elf));
+if ( elf_init(elf, image, image_size) != 0 )
+goto error_out;
+
+xc_elf_set_logfile(xch, elf, 1);
+
+elf_parse_binary(elf);
+v_start = 0;
+v_end = args-mem_size;
+
+if ( modules_init(args, v_end, elf, m_start, m_end) != 0 )
+{
+ERROR(Insufficient space to load modules.);
+goto error_out;
+}
+
+DPRINTF(VIRTUAL MEMORY ARRANGEMENT:\n);
+DPRINTF( Loader:
[Xen-devel] [PATCH RFC v1 04/13] libxc: allow arch_setup_meminit to populate HVM domain memory
Introduce a new arch_setup_meminit_hvm that's going to be used to populate
HVM domain memory. Rename arch_setup_meminit to arch_setup_meminit_hvm_pv
and introduce a stub arch_setup_meminit that will call the right meminit
function depending on the contains type.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
I think that both arch_setup_meminit_hvm and arch_setup_meminit_pv could be
unified into a single meminit function. I have however not looked into it,
and just created arch_setup_meminit_hvm based on the code in
xc_hvm_populate_memory.
---
tools/libxc/include/xc_dom.h | 8 +
tools/libxc/xc_dom_x86.c | 365 +--
tools/libxl/libxl_dom.c | 1 +
3 files changed, 362 insertions(+), 12 deletions(-)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index f7b5f0f..051a7de 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -186,6 +186,14 @@ struct xc_dom_image {
XC_DOM_PV_CONTAINER,
XC_DOM_HVM_CONTAINER,
} container_type;
+
+/* HVM specific fields. */
+xen_pfn_t target_pages;
+xen_pfn_t mmio_start;
+xen_pfn_t mmio_size;
+xen_pfn_t lowmem_end;
+xen_pfn_t highmem_end;
+int vga_hole;
};
/* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index b89f5c2..8a1ef24 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -40,10 +40,15 @@
/* */
-#define SUPERPAGE_PFN_SHIFT 9
-#define SUPERPAGE_NR_PFNS(1UL SUPERPAGE_PFN_SHIFT)
#define SUPERPAGE_BATCH_SIZE 512
+#define SUPERPAGE_2MB_SHIFT 9
+#define SUPERPAGE_2MB_NR_PFNS (1UL SUPERPAGE_2MB_SHIFT)
+#define SUPERPAGE_1GB_SHIFT 18
+#define SUPERPAGE_1GB_NR_PFNS (1UL SUPERPAGE_1GB_SHIFT)
+
+#define VGA_HOLE_SIZE (0x20)
+
#define bits_to_mask(bits) (((xen_vaddr_t)1 (bits))-1)
#define round_down(addr, mask) ((addr) ~(mask))
#define round_up(addr, mask) ((addr) | (mask))
@@ -758,7 +763,7 @@ static int x86_shadow(xc_interface *xch, domid_t domid)
return rc;
}
-int arch_setup_meminit(struct xc_dom_image *dom)
+static int arch_setup_meminit_pv(struct xc_dom_image *dom)
{
int rc;
xen_pfn_t pfn, allocsz, mfn, total, pfn_base;
@@ -782,7 +787,7 @@ int arch_setup_meminit(struct xc_dom_image *dom)
if ( dom-superpages )
{
-int count = dom-total_pages SUPERPAGE_PFN_SHIFT;
+int count = dom-total_pages SUPERPAGE_2MB_SHIFT;
xen_pfn_t extents[count];
dom-p2m_size = dom-total_pages;
@@ -793,9 +798,9 @@ int arch_setup_meminit(struct xc_dom_image *dom)
DOMPRINTF(Populating memory with %d superpages, count);
for ( pfn = 0; pfn count; pfn++ )
-extents[pfn] = pfn SUPERPAGE_PFN_SHIFT;
+extents[pfn] = pfn SUPERPAGE_2MB_SHIFT;
rc = xc_domain_populate_physmap_exact(dom-xch, dom-guest_domid,
- count, SUPERPAGE_PFN_SHIFT, 0,
+ count, SUPERPAGE_2MB_SHIFT, 0,
extents);
if ( rc )
return rc;
@@ -805,7 +810,7 @@ int arch_setup_meminit(struct xc_dom_image *dom)
for ( i = 0; i count; i++ )
{
mfn = extents[i];
-for ( j = 0; j SUPERPAGE_NR_PFNS; j++, pfn++ )
+for ( j = 0; j SUPERPAGE_2MB_NR_PFNS; j++, pfn++ )
dom-p2m_host[pfn] = mfn + j;
}
}
@@ -881,7 +886,7 @@ int arch_setup_meminit(struct xc_dom_image *dom)
unsigned int memflags;
uint64_t pages;
unsigned int pnode = vnode_to_pnode[vmemranges[i].nid];
-int nr_spages = dom-total_pages SUPERPAGE_PFN_SHIFT;
+int nr_spages = dom-total_pages SUPERPAGE_2MB_SHIFT;
xen_pfn_t extents[SUPERPAGE_BATCH_SIZE];
xen_pfn_t pfn_base_idx;
@@ -902,11 +907,11 @@ int arch_setup_meminit(struct xc_dom_image *dom)
nr_spages -= count;
for ( pfn = pfn_base_idx, j = 0;
- pfn pfn_base_idx + (count SUPERPAGE_PFN_SHIFT);
- pfn += SUPERPAGE_NR_PFNS, j++ )
+ pfn pfn_base_idx + (count SUPERPAGE_2MB_SHIFT);
+ pfn += SUPERPAGE_2MB_NR_PFNS, j++ )
extents[j] = dom-p2m_host[pfn];
rc = xc_domain_populate_physmap(dom-xch,
[Xen-devel] [PATCH RFC v1 05/13] libxc: introduce a domain loader for HVM guest firmware
Introduce a very simple (and dummy) domain loader to be used to load the
firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
executable the loader is fairly simple.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
tools/libxc/Makefile | 1 +
tools/libxc/include/xc_dom.h | 7 +
tools/libxc/xc_dom_hvmloader.c | 316 +
xen/include/xen/libelf.h | 1 +
4 files changed, 325 insertions(+)
create mode 100644 tools/libxc/xc_dom_hvmloader.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 55782c8..7f860d7 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -86,6 +86,7 @@ GUEST_SRCS-y += xc_dom_core.c xc_dom_boot.c
GUEST_SRCS-y += xc_dom_elfloader.c
GUEST_SRCS-$(CONFIG_X86) += xc_dom_bzimageloader.c
GUEST_SRCS-$(CONFIG_X86) += xc_dom_decompress_lz4.c
+GUEST_SRCS-$(CONFIG_X86) += xc_dom_hvmloader.c
GUEST_SRCS-$(CONFIG_ARM) += xc_dom_armzimageloader.c
GUEST_SRCS-y += xc_dom_binloader.c
GUEST_SRCS-y += xc_dom_compat_linux.c
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 051a7de..caeb1c8 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -15,6 +15,7 @@
*/
#include xen/libelf/libelf.h
+#include xenguest.h
#define INVALID_P2M_ENTRY ((xen_pfn_t)-1)
@@ -194,6 +195,12 @@ struct xc_dom_image {
xen_pfn_t lowmem_end;
xen_pfn_t highmem_end;
int vga_hole;
+
+/* Extra ACPI tables passed to HVMLOADER */
+struct xc_hvm_firmware_module acpi_module;
+
+/* Extra SMBIOS structures passed to HVMLOADER */
+struct xc_hvm_firmware_module smbios_module;
};
/* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
new file mode 100644
index 000..b6270c9
--- /dev/null
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -0,0 +1,316 @@
+/*
+ * Xen domain builder -- HVM specific bits.
+ *
+ * Parse and load ELF firmware images for HVM domains.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ *
+ */
+
+#include stdio.h
+#include stdlib.h
+#include stdarg.h
+#include inttypes.h
+#include assert.h
+
+#include xg_private.h
+#include xc_dom.h
+#include xc_bitops.h
+
+/* */
+/* parse elf binary */
+
+static elf_negerrnoval check_elf_kernel(struct xc_dom_image *dom, bool verbose)
+{
+if ( dom-kernel_blob == NULL )
+{
+if ( verbose )
+xc_dom_panic(dom-xch,
+ XC_INTERNAL_ERROR, %s: no kernel image loaded,
+ __FUNCTION__);
+return -EINVAL;
+}
+
+if ( !elf_is_elfbinary(dom-kernel_blob, dom-kernel_size) )
+{
+if ( verbose )
+xc_dom_panic(dom-xch,
+ XC_INVALID_KERNEL, %s: kernel is not an ELF image,
+ __FUNCTION__);
+return -EINVAL;
+}
+return 0;
+}
+
+static elf_negerrnoval xc_dom_probe_hvm_kernel(struct xc_dom_image *dom)
+{
+struct elf_binary elf;
+int rc;
+
+/* This loader is designed for HVM guest firmware. */
+if ( dom-container_type != XC_DOM_HVM_CONTAINER )
+return -EINVAL;
+
+rc = check_elf_kernel(dom, 0);
+if ( rc != 0 )
+return rc;
+
+rc = elf_init(elf, dom-kernel_blob, dom-kernel_size);
+if ( rc != 0 )
+return rc;
+
+/*
+ * We need to check that there are no Xen ELFNOTES, or
+ * else we might be trying to load a PV kernel.
+ */
+elf_parse_binary(elf);
+rc = elf_xen_parse(elf, dom-parms);
+if ( rc == 0 )
+return -EINVAL;
+
+return 0;
+}
+
+static elf_errorstatus xc_dom_parse_hvm_kernel(struct xc_dom_image *dom)
+/*
+
[Xen-devel] [PATCHv1] x86: only check for one watchdog NMI
Since the NMI handler can now recognize watchdog NMIs, make
check_nmi_watchdog() only check for at least one watchdog NMI. This
prevents false negatives caused by other processors (which may be
being power managed by the BIOS) running at reduced clock frequencies.
This will also slightly speed up boot times since we only wait the
full 10 ticks if the NMI watchdog on one or more CPUs is not working.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
xen/arch/x86/nmi.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
index 2ab97a0..725ea04 100644
--- a/xen/arch/x86/nmi.c
+++ b/xen/arch/x86/nmi.c
@@ -139,7 +139,18 @@ int nmi_active;
static void __init wait_for_nmis(void *p)
{
-mdelay((10*1000)/nmi_hz); /* wait 10 ticks */
+unsigned int cpu = smp_processor_id();
+unsigned int start_count = nmi_count(cpu);
+unsigned long ticks = 10 * 1000 * cpu_khz / nmi_hz;
+unsigned long s, e;
+
+s = rdtsc();
+do {
+cpu_relax();
+if ( nmi_count(cpu) start_count )
+break;
+e = rdtsc();
+} while( e - s ticks );
}
int __init check_nmi_watchdog (void)
@@ -156,15 +167,16 @@ int __init check_nmi_watchdog (void)
for_each_online_cpu ( cpu )
prev_nmi_count[cpu] = nmi_count(cpu);
-/* Wait for 10 ticks. Busy-wait on all CPUs: the LAPIC counter that
- * the NMI watchdog uses only runs while the core's not halted */
-if ( nmi_watchdog == NMI_LOCAL_APIC )
-smp_call_function(wait_for_nmis, NULL, 0);
-wait_for_nmis(NULL);
+/*
+ * Wait at most 10 ticks for a watchdog NMI on each CPU.
+ * Busy-wait on all CPUs: the LAPIC counter that the NMI watchdog
+ * uses only runs while the core's not halted
+ */
+on_selected_cpus(cpu_online_map, wait_for_nmis, NULL, 1);
for_each_online_cpu ( cpu )
{
-if ( nmi_count(cpu) - prev_nmi_count[cpu] = 5 )
+if ( nmi_count(cpu) - prev_nmi_count[cpu] 1 )
{
printk( %d, cpu);
ok = 0;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/6] AMD-PVH: Do not get/set vlapic TPR
From: Elena Ufimtseva elena.ufimts...@oracle.com
PVH doesn't use apic emulation hence vlapic-regs ptr is not set for it.
Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
xen/arch/x86/hvm/svm/svm.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index e7262c9..64d22fe 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1059,7 +1059,7 @@ static void noreturn svm_do_resume(struct vcpu *v)
hvm_asid_flush_vcpu(v);
}
-if ( !vcpu_guestmode )
+if ( !vcpu_guestmode !is_pvh_domain(v-domain) )
{
vintr_t intr;
@@ -2332,7 +2332,7 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
* NB. We need to preserve the low bits of the TPR to make checked builds
* of Windows work, even though they don't actually do anything.
*/
-if ( !vcpu_guestmode ) {
+if ( !vcpu_guestmode !is_pvh_domain(v-domain) ) {
intr = vmcb_get_vintr(vmcb);
vlapic_set_reg(vcpu_vlapic(v), APIC_TASKPRI,
((intr.fields.tpr 0x0F) 4) |
@@ -2720,15 +2720,18 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
}
out:
-if ( vcpu_guestmode )
-/* Don't clobber TPR of the nested guest. */
-return;
-
-/* The exit may have updated the TPR: reflect this in the hardware vtpr */
-intr = vmcb_get_vintr(vmcb);
-intr.fields.tpr =
-(vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) 0xFF) 4;
-vmcb_set_vintr(vmcb, intr);
+/* Don't clobber TPR of the nested guest. */
+if ( vcpu_guestmode !is_pvh_domain(v-domain) )
+{
+/*
+ * The exit may have updated the TPR: reflect this in the hardware
+ * vtpr.
+ */
+intr = vmcb_get_vintr(vmcb);
+intr.fields.tpr =
+(vlapic_get_reg(vcpu_vlapic(v), APIC_TASKPRI) 0xFF) 4;
+vmcb_set_vintr(vmcb, intr);
+}
}
void svm_trace_vmentry(void)
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 2/7] Qemu-Xen-vTPM: Create a new file xen_pvdev.c
On Sun, 17 May 2015, Quan Xu wrote:
for some common part of xen frontend and backend, such as xendevs
queue and xenstore update functions.
Signed-off-by: Quan Xu quan...@intel.com
Hi Quan,
could you please separate out the code movement from any other changes?
This patch would become two patches: the first would only move code from
xen_backend.c to xen_pvdev.c, no other changes except for the ones
actually required to build the code (Makefile.objs). The second patch
would rename xen_be_find_xendev to xen_find_xendev and any other changes
to the code that you making here. That way I can very easily go and
look only at the things you actually modify.
Thanks,
Stefano
hw/display/xenfb.c | 4 +-
hw/xen/Makefile.objs | 2 +-
hw/xen/xen_backend.c | 353 ---
hw/xen/xen_pvdev.c | 481
+++
include/hw/xen/xen_backend.h | 13 +-
5 files changed, 496 insertions(+), 357 deletions(-)
create mode 100644 hw/xen/xen_pvdev.c
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 5e324ef..10751df 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -988,8 +988,8 @@ void xen_init_display(int domid)
wait_more:
i++;
main_loop_wait(true);
-xfb = xen_be_find_xendev(vfb, domid, 0);
-xin = xen_be_find_xendev(vkbd, domid, 0);
+xfb = xen_find_xendev(vfb, domid, 0);
+xin = xen_find_xendev(vkbd, domid, 0);
if (!xfb || !xin) {
if (i 256) {
usleep(1);
diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index a0ca0aa..9ac9f7c 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
# xen backend driver support
-common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
+common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o xen_pvdev.o
obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
xen_pt_msi.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..844f918 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -44,86 +44,11 @@
/* - */
/* public */
-XenXC xen_xc = XC_HANDLER_INITIAL_VALUE;
-struct xs_handle *xenstore = NULL;
const char *xen_protocol;
/* private */
-static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs =
QTAILQ_HEAD_INITIALIZER(xendevs);
static int debug = 0;
-/* - */
-
-int xenstore_write_str(const char *base, const char *node, const char *val)
-{
-char abspath[XEN_BUFSIZE];
-
-snprintf(abspath, sizeof(abspath), %s/%s, base, node);
-if (!xs_write(xenstore, 0, abspath, val, strlen(val))) {
-return -1;
-}
-return 0;
-}
-
-char *xenstore_read_str(const char *base, const char *node)
-{
-char abspath[XEN_BUFSIZE];
-unsigned int len;
-char *str, *ret = NULL;
-
-snprintf(abspath, sizeof(abspath), %s/%s, base, node);
-str = xs_read(xenstore, 0, abspath, len);
-if (str != NULL) {
-/* move to qemu-allocated memory to make sure
- * callers can savely g_free() stuff. */
-ret = g_strdup(str);
-free(str);
-}
-return ret;
-}
-
-int xenstore_write_int(const char *base, const char *node, int ival)
-{
-char val[12];
-
-snprintf(val, sizeof(val), %d, ival);
-return xenstore_write_str(base, node, val);
-}
-
-int xenstore_write_int64(const char *base, const char *node, int64_t ival)
-{
-char val[21];
-
-snprintf(val, sizeof(val), %PRId64, ival);
-return xenstore_write_str(base, node, val);
-}
-
-int xenstore_read_int(const char *base, const char *node, int *ival)
-{
-char *val;
-int rc = -1;
-
-val = xenstore_read_str(base, node);
-if (val 1 == sscanf(val, %d, ival)) {
-rc = 0;
-}
-g_free(val);
-return rc;
-}
-
-int xenstore_read_uint64(const char *base, const char *node, uint64_t *uval)
-{
-char *val;
-int rc = -1;
-
-val = xenstore_read_str(base, node);
-if (val 1 == sscanf(val, %SCNu64, uval)) {
-rc = 0;
-}
-g_free(val);
-return rc;
-}
-
int xenstore_write_be_str(struct XenDevice *xendev, const char *node, const
char *val)
{
return xenstore_write_str(xendev-be, node, val);
@@ -195,183 +120,6 @@ int xen_be_set_state(struct XenDevice *xendev, enum
xenbus_state state)
}
/* - */
-
-struct XenDevice *xen_be_find_xendev(const char *type, int dom, int dev)
-{
-struct XenDevice *xendev;
-
-QTAILQ_FOREACH(xendev, xendevs, next) {
-if (xendev-dom != dom) {
-continue;
-}
-if (xendev-dev != dev) {
-continue;
-}
-
[Xen-devel] [PATCH RFC v1 02/13] libxc: unify xc_dom_p2m_{host/guest}
Unify both functions into xc_dom_p2m. Should not introduce any functional
change.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
stubdom/grub/kexec.c | 4 ++--
tools/libxc/include/xc_dom.h | 14 ++
tools/libxc/xc_dom_boot.c | 10 +-
tools/libxc/xc_dom_compat_linux.c | 4 ++--
tools/libxc/xc_dom_x86.c | 32
tools/libxl/libxl_dom.c | 4 ++--
6 files changed, 29 insertions(+), 39 deletions(-)
diff --git a/stubdom/grub/kexec.c b/stubdom/grub/kexec.c
index 4c33b25..0b2f4f3 100644
--- a/stubdom/grub/kexec.c
+++ b/stubdom/grub/kexec.c
@@ -358,9 +358,9 @@ void kexec(void *kernel, long kernel_size, void *module,
long module_size, char
#ifdef __x86_64__
MMUEXT_PIN_L4_TABLE,
#endif
-xc_dom_p2m_host(dom, dom-pgtables_seg.pfn),
+xc_dom_p2m(dom, dom-pgtables_seg.pfn),
dom-guest_domid)) != 0 ) {
-grub_printf(pin_table(%lx) returned %d\n, xc_dom_p2m_host(dom,
+grub_printf(pin_table(%lx) returned %d\n, xc_dom_p2m(dom,
dom-pgtables_seg.pfn), rc);
errnum = ERR_BOOT_FAILURE;
goto out_remap;
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index a7d059a..ec9e293 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -376,19 +376,9 @@ static inline void *xc_dom_vaddr_to_ptr(struct
xc_dom_image *dom,
return ptr + offset;
}
-static inline xen_pfn_t xc_dom_p2m_host(struct xc_dom_image *dom, xen_pfn_t
pfn)
+static inline xen_pfn_t xc_dom_p2m(struct xc_dom_image *dom, xen_pfn_t pfn)
{
-if (dom-shadow_enabled)
-return pfn;
-if (pfn dom-rambase_pfn || pfn = dom-rambase_pfn + dom-total_pages)
-return INVALID_MFN;
-return dom-p2m_host[pfn - dom-rambase_pfn];
-}
-
-static inline xen_pfn_t xc_dom_p2m_guest(struct xc_dom_image *dom,
- xen_pfn_t pfn)
-{
-if (xc_dom_feature_translated(dom))
+if ( dom-shadow_enabled || xc_dom_feature_translated(dom) )
return pfn;
if (pfn dom-rambase_pfn || pfn = dom-rambase_pfn + dom-total_pages)
return INVALID_MFN;
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index f82db2d..fda9e52 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -54,7 +54,7 @@ static int setup_hypercall_page(struct xc_dom_image *dom)
dom-parms.virt_hypercall, pfn);
domctl.cmd = XEN_DOMCTL_hypercall_init;
domctl.domain = dom-guest_domid;
-domctl.u.hypercall_init.gmfn = xc_dom_p2m_guest(dom, pfn);
+domctl.u.hypercall_init.gmfn = xc_dom_p2m(dom, pfn);
rc = do_domctl(dom-xch, domctl);
if ( rc != 0 )
xc_dom_panic(dom-xch, XC_INTERNAL_ERROR,
@@ -84,7 +84,7 @@ static int clear_page(struct xc_dom_image *dom, xen_pfn_t pfn)
if ( pfn == 0 )
return 0;
-dst = xc_dom_p2m_host(dom, pfn);
+dst = xc_dom_p2m(dom, pfn);
DOMPRINTF(%s: pfn 0x% PRIpfn , mfn 0x% PRIpfn ,
__FUNCTION__, pfn, dst);
rc = xc_clear_domain_page(dom-xch, dom-guest_domid, dst);
@@ -178,7 +178,7 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom,
xen_pfn_t pfn,
}
for ( i = 0; i count; i++ )
-entries[i].mfn = xc_dom_p2m_host(dom, pfn + i);
+entries[i].mfn = xc_dom_p2m(dom, pfn + i);
ptr = xc_map_foreign_ranges(dom-xch, dom-guest_domid,
count page_shift, PROT_READ | PROT_WRITE, 1 page_shift,
@@ -435,8 +435,8 @@ int xc_dom_gnttab_init(struct xc_dom_image *dom)
dom-console_domid, dom-xenstore_domid);
} else {
return xc_dom_gnttab_seed(dom-xch, dom-guest_domid,
- xc_dom_p2m_host(dom, dom-console_pfn),
- xc_dom_p2m_host(dom, dom-xenstore_pfn),
+ xc_dom_p2m(dom, dom-console_pfn),
+ xc_dom_p2m(dom, dom-xenstore_pfn),
dom-console_domid, dom-xenstore_domid);
}
}
diff --git a/tools/libxc/xc_dom_compat_linux.c
b/tools/libxc/xc_dom_compat_linux.c
index 2c14a0f..acccde9 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -65,8 +65,8 @@ static int xc_linux_build_internal(struct xc_dom_image *dom,
if ( (rc = xc_dom_gnttab_init(dom)) != 0)
goto out;
-*console_mfn = xc_dom_p2m_host(dom, dom-console_pfn);
-*store_mfn = xc_dom_p2m_host(dom,
[Xen-devel] [PATCH RFC v1 07/13] libxl: switch HVM domain building to use xc_dom_* helpers
Now that we have all the code in place HVM domain building in libxl can be
switched to use the xc_dom_* family of functions, just like they are used in
order to build PV guests.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
TBH HVM building still avoids calling some xc_dom_* functions that are
called in order to build PV guests. IMHO we should look into having the
exact same flow in order to build PV or HVM domains, so libxl__build_pv and
libxl__build_hvm can be unified into a single function.
---
tools/libxl/libxl_dom.c | 146 ---
tools/libxl/libxl_internal.h | 2 +-
tools/libxl/libxl_vnuma.c| 12 ++--
3 files changed, 105 insertions(+), 55 deletions(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 6273052..12ede26 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -801,39 +801,39 @@ static int hvm_build_set_params(xc_interface *handle,
uint32_t domid,
static int hvm_build_set_xs_values(libxl__gc *gc,
uint32_t domid,
- struct xc_hvm_build_args *args)
+ struct xc_dom_image *dom)
{
char *path = NULL;
int ret = 0;
-if (args-smbios_module.guest_addr_out) {
+if (dom-smbios_module.guest_addr_out) {
path = GCSPRINTF(/local/domain/%d/HVM_XS_SMBIOS_PT_ADDRESS, domid);
ret = libxl__xs_write(gc, XBT_NULL, path, 0x%PRIx64,
- args-smbios_module.guest_addr_out);
+ dom-smbios_module.guest_addr_out);
if (ret)
goto err;
path = GCSPRINTF(/local/domain/%d/HVM_XS_SMBIOS_PT_LENGTH, domid);
ret = libxl__xs_write(gc, XBT_NULL, path, 0x%x,
- args-smbios_module.length);
+ dom-smbios_module.length);
if (ret)
goto err;
}
-if (args-acpi_module.guest_addr_out) {
+if (dom-acpi_module.guest_addr_out) {
path = GCSPRINTF(/local/domain/%d/HVM_XS_ACPI_PT_ADDRESS, domid);
ret = libxl__xs_write(gc, XBT_NULL, path, 0x%PRIx64,
- args-acpi_module.guest_addr_out);
+ dom-acpi_module.guest_addr_out);
if (ret)
goto err;
path = GCSPRINTF(/local/domain/%d/HVM_XS_ACPI_PT_LENGTH, domid);
ret = libxl__xs_write(gc, XBT_NULL, path, 0x%x,
- args-acpi_module.length);
+ dom-acpi_module.length);
if (ret)
goto err;
}
@@ -847,7 +847,7 @@ err:
static int libxl__domain_firmware(libxl__gc *gc,
libxl_domain_build_info *info,
- struct xc_hvm_build_args *args)
+ struct xc_dom_image *dom)
{
libxl_ctx *ctx = libxl__gc_owner(gc);
const char *firmware;
@@ -873,8 +873,13 @@ static int libxl__domain_firmware(libxl__gc *gc,
break;
}
}
-args-image_file_name = libxl__abs_path(gc, firmware,
-libxl__xenfirmwaredir_path());
+
+rc = xc_dom_kernel_file(dom, libxl__abs_path(gc, firmware,
+
libxl__xenfirmwaredir_path()));
+if (rc != 0) {
+LOGE(ERROR, xc_dom_kernel_file failed);
+goto out;
+}
if (info-u.hvm.smbios_firmware) {
data = NULL;
@@ -888,8 +893,8 @@ static int libxl__domain_firmware(libxl__gc *gc,
libxl__ptr_add(gc, data);
if (datalen) {
/* Only accept non-empty files */
-args-smbios_module.data = data;
-args-smbios_module.length = (uint32_t)datalen;
+dom-smbios_module.data = data;
+dom-smbios_module.length = (uint32_t)datalen;
}
}
@@ -905,8 +910,8 @@ static int libxl__domain_firmware(libxl__gc *gc,
libxl__ptr_add(gc, data);
if (datalen) {
/* Only accept non-empty files */
-args-acpi_module.data = data;
-args-acpi_module.length = (uint32_t)datalen;
+dom-acpi_module.data = data;
+dom-acpi_module.length = (uint32_t)datalen;
}
}
@@ -920,50 +925,61 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
libxl__domain_build_state *state)
{
libxl_ctx *ctx = libxl__gc_owner(gc);
-struct xc_hvm_build_args args = {};
int ret, rc = ERROR_FAIL;
-uint64_t
[Xen-devel] [PATCH RFC v1 03/13] libxc: introduce the notion of a container type
Introduce the notion of a container type into xc_dom_image. This will be
needed by later changes that will also use xc_dom_image in order to build
HVM guests.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
tools/libxc/include/xc_dom.h | 6 ++
tools/libxc/xc_dom_x86.c | 4
tools/libxl/libxl_dom.c | 1 +
3 files changed, 11 insertions(+)
diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ec9e293..f7b5f0f 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -180,6 +180,12 @@ struct xc_dom_image {
struct xc_dom_arch *arch_hooks;
/* allocate up to virt_alloc_end */
int (*allocate) (struct xc_dom_image * dom, xen_vaddr_t up_to);
+
+/* Container type (HVM or PV). */
+enum {
+XC_DOM_PV_CONTAINER,
+XC_DOM_HVM_CONTAINER,
+} container_type;
};
/* --- pluggable kernel loader - */
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 0d80c18..b89f5c2 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -1071,6 +1071,10 @@ int arch_setup_bootlate(struct xc_dom_image *dom)
int xc_dom_feature_translated(struct xc_dom_image *dom)
{
+/* Guests running inside HVM containers are always auto-translated. */
+if ( dom-container_type == XC_DOM_HVM_CONTAINER )
+return 1;
+
return elf_xen_feature_get(XENFEAT_auto_translated_physmap, dom-f_active);
}
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index a970a8b..8907bd6 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -626,6 +626,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
}
dom-pvh_enabled = state-pvh_enabled;
+dom-container_type = XC_DOM_PV_CONTAINER;
LOG(DEBUG, pv kernel mapped %d path %s, state-pv_kernel.mapped,
state-pv_kernel.path);
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC v1 06/13] libxc: introduce a xc_dom_arch for hvm-3.0-x86_32 guests
This xc_dom_arch will be used in order to build HVM domains. The code is
based on the existing xc_hvm_populate_params function.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Elena Ufimtseva elena.ufimts...@oracle.com
---
This is abusing the alloc_magic_pages hook in order to setup everything,
which is not the best approach but it works. In later versions I would like
to break alloc_magic_pages_hvm into smaller functions that can be used to
populate the remaining hooks (start_info and shared_info).
---
tools/libxc/xc_dom_x86.c | 183 +++
1 file changed, 183 insertions(+)
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 8a1ef24..0d9ec42 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -49,6 +49,20 @@
#define VGA_HOLE_SIZE (0x20)
+#define SPECIALPAGE_PAGING 0
+#define SPECIALPAGE_ACCESS 1
+#define SPECIALPAGE_SHARING 2
+#define SPECIALPAGE_BUFIOREQ 3
+#define SPECIALPAGE_XENSTORE 4
+#define SPECIALPAGE_IOREQ5
+#define SPECIALPAGE_IDENT_PT 6
+#define SPECIALPAGE_CONSOLE 7
+#define NR_SPECIAL_PAGES 8
+#define special_pfn(x) (0xff000u - NR_SPECIAL_PAGES + (x))
+
+#define NR_IOREQ_SERVER_PAGES 8
+#define ioreq_server_pfn(x) (special_pfn(0) - NR_IOREQ_SERVER_PAGES + (x))
+
#define bits_to_mask(bits) (((xen_vaddr_t)1 (bits))-1)
#define round_down(addr, mask) ((addr) ~(mask))
#define round_up(addr, mask) ((addr) | (mask))
@@ -467,6 +481,135 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
return 0;
}
+static void build_hvm_info(void *hvm_info_page, struct xc_dom_image *dom)
+{
+struct hvm_info_table *hvm_info = (struct hvm_info_table *)
+(((unsigned char *)hvm_info_page) + HVM_INFO_OFFSET);
+uint8_t sum;
+int i;
+
+memset(hvm_info_page, 0, PAGE_SIZE);
+
+/* Fill in the header. */
+strncpy(hvm_info-signature, HVM INFO, 8);
+hvm_info-length = sizeof(struct hvm_info_table);
+
+/* Sensible defaults: these can be overridden by the caller. */
+hvm_info-apic_mode = 1;
+hvm_info-nr_vcpus = 1;
+memset(hvm_info-vcpu_online, 0xff, sizeof(hvm_info-vcpu_online));
+
+/* Memory parameters. */
+hvm_info-low_mem_pgend = dom-lowmem_end PAGE_SHIFT;
+hvm_info-high_mem_pgend = dom-highmem_end PAGE_SHIFT;
+hvm_info-reserved_mem_pgstart = ioreq_server_pfn(0);
+
+/* Finish with the checksum. */
+for ( i = 0, sum = 0; i hvm_info-length; i++ )
+sum += ((uint8_t *)hvm_info)[i];
+hvm_info-checksum = -sum;
+}
+
+static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
+{
+unsigned long i;
+void *hvm_info_page;
+uint32_t *ident_pt, domid = dom-guest_domid;
+int rc;
+xen_pfn_t special_array[NR_SPECIAL_PAGES];
+xen_pfn_t ioreq_server_array[NR_IOREQ_SERVER_PAGES];
+xc_interface *xch = dom-xch;
+
+if ( (hvm_info_page = xc_map_foreign_range(
+ xch, domid, PAGE_SIZE, PROT_READ | PROT_WRITE,
+ HVM_INFO_PFN)) == NULL )
+goto error_out;
+build_hvm_info(hvm_info_page, dom);
+munmap(hvm_info_page, PAGE_SIZE);
+
+/* Allocate and clear special pages. */
+for ( i = 0; i NR_SPECIAL_PAGES; i++ )
+special_array[i] = special_pfn(i);
+
+rc = xc_domain_populate_physmap_exact(xch, domid, NR_SPECIAL_PAGES, 0, 0,
+ special_array);
+if ( rc != 0 )
+{
+DOMPRINTF(Could not allocate special pages.);
+goto error_out;
+}
+
+if ( xc_clear_domain_pages(xch, domid, special_pfn(0), NR_SPECIAL_PAGES) )
+goto error_out;
+
+xc_hvm_param_set(xch, domid, HVM_PARAM_STORE_PFN,
+ special_pfn(SPECIALPAGE_XENSTORE));
+xc_hvm_param_set(xch, domid, HVM_PARAM_BUFIOREQ_PFN,
+ special_pfn(SPECIALPAGE_BUFIOREQ));
+xc_hvm_param_set(xch, domid, HVM_PARAM_IOREQ_PFN,
+ special_pfn(SPECIALPAGE_IOREQ));
+xc_hvm_param_set(xch, domid, HVM_PARAM_CONSOLE_PFN,
+ special_pfn(SPECIALPAGE_CONSOLE));
+xc_hvm_param_set(xch, domid, HVM_PARAM_PAGING_RING_PFN,
+ special_pfn(SPECIALPAGE_PAGING));
+xc_hvm_param_set(xch, domid, HVM_PARAM_MONITOR_RING_PFN,
+ special_pfn(SPECIALPAGE_ACCESS));
+xc_hvm_param_set(xch, domid, HVM_PARAM_SHARING_RING_PFN,
+ special_pfn(SPECIALPAGE_SHARING));
+
+/*
+ * Allocate and clear additional ioreq server pages. The default
+ * server will use the IOREQ and BUFIOREQ special pages above.
+ */
+for ( i = 0; i NR_IOREQ_SERVER_PAGES; i++ )
+
Re: [Xen-devel] [PATCH v8 4/7] Qemu-Xen-vTPM: Register Xen stubdom vTPM frontend driver
On Sun, 17 May 2015, Quan Xu wrote:
This drvier transfers any request/repond between TPM xenstubdoms
driver and Xen vTPM stubdom, and facilitates communications between
Xen vTPM stubdom domain and vTPM xenstubdoms driver. It is a glue for
the TPM xenstubdoms driver and Xen stubdom vTPM domain that provides
the actual TPM functionality.
(Xen) Xen backend driver should run before running this frontend, and
initialize XenStore as the following for communication.
[XenStore]
for example:
Domain 0: runs QEMU for guest A
Domain 1: vtpmmgr
Domain 2: vTPM for guest A
Domain 3: HVM guest A
[...]
local =
domain =
0 =
frontend =
vtpm =
2 =
0 =
backend = /local/domain/2/backend/vtpm/0/0
backend-id = 2
state = *
handle = 0
domain = Domain3's name
ring-ref = *
event-channel = *
feature-protocol-v2 = 1
backend =
qdisk =
[...]
console =
vif =
[...]
2 =
[...]
backend =
vtpm =
0 =
0 =
frontend = /local/domain/0/frontend/vtpm/2/0
frontend-id = 0 ('0', frontend is running in Domain-0)
[...]
3 =
[...]
device = (frontend device, the backend is running in QEMU/.etc)
vkbd =
[...]
vif =
[...]
..
(QEMU) xen_vtpmdev_ops is initialized with the following process:
xen_hvm_init()
[...]
--xen_fe_register(vtpm, ...)
--xenstore_fe_scan()
--xen_fe_try_init(ops)
-- XenDevOps.init()
--xen_fe_get_xendev()
-- XenDevOps.alloc()
--xen_fe_check()
--xen_fe_try_initialise()
-- XenDevOps.initialise()
--xen_fe_try_connected()
-- XenDevOps.connected()
--xs_watch()
[...]
Signed-off-by: Quan Xu quan...@intel.com
Reviewed-by: Stefan Berger stef...@linux.vnet.ibm.com
Much better than the last version I read. Only one comment:
+static void vtpm_backend_changed(struct XenDevice *xendev, const char *node)
+{
+int be_state;
+
+if (strcmp(node, state) == 0) {
+xenstore_read_be_int(xendev, node, be_state);
+switch (be_state) {
+case XenbusStateConnected:
+/* TODO */
+break;
+case XenbusStateClosing:
+case XenbusStateClosed:
+xenbus_switch_state(xendev, XenbusStateClosing);
+break;
+default:
+break;
+}
+}
+}
I thought you agreed that moving this to xen_frontend.c and make it
generic was a better idea?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v3 05/18] xen/arm: ITS: Port ITS driver to xen
Hi,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Only required changes from Linux ITS driver is ported
and compiled
Can you list the changes you took from Linux? The coding style is not
the same so it's hard to know what is the difference.
It would also have been nice to get the latest fix from Linux and say on
which version you are based.
[..]
+/*
+ * The ITS structure - contains most of the infrastructure, with the
+ * msi_controller, the command queue, the collections, and the list of
+ * devices writing to it.
+ */
+struct its_node {
+spinlock_t lock;
+struct list_headentry;
+void __iomem *base;
The indentation seems wrong.
+unsigned long phys_base;
+unsigned long phys_size;
+its_cmd_block *cmd_base;
+its_cmd_block *cmd_write;
+void*tables[GITS_BASER_NR_REGS];
+struct its_collection *collections;
+u64 flags;
+u32 ite_size;
+struct dt_device_node *dt_node;
+};
+
+#define ITS_ITT_ALIGNSZ_256
+
+static LIST_HEAD(its_nodes);
+static DEFINE_SPINLOCK(its_lock);
+static struct rdist_prop *gic_rdists;
+
+#define gic_data_rdist()(per_cpu(rdist, smp_processor_id()))
+#define gic_data_rdist_rd_base()(per_cpu(rdist,
smp_processor_id()).rbase)
You could use gic_data_rdist().rbase
[..]
+#ifdef DEBUG_GIC_ITS
+void dump_cmd(its_cmd_block *cmd)
+{
+printk(ITS: Phys_cmd CMD[0] = 0x%lx CMD[1] = 0x%lx CMD[2] = 0x%lx
CMD[3] = 0x%lx\n,
+ cmd-raw_cmd[0], cmd-raw_cmd[1], cmd-raw_cmd[2],
cmd-raw_cmd[3]);
+}
+#endif
+
+#define ITS_CMD_QUEUE_SZSZ_64K
+#define ITS_CMD_QUEUE_NR_ENTRIES(ITS_CMD_QUEUE_SZ /
sizeof(its_cmd_block))
+
+#define ALIGN(x, a) (((x) + (a - 1)) ~(a - 1))
Please use ROUNDUP which does the same job.
+
+typedef struct its_collection *(*its_cmd_builder_t)(its_cmd_block *,
+struct its_cmd_desc *);
+
+static struct its_collection *its_build_mapd_cmd(its_cmd_block *cmd,
+ struct its_cmd_desc *desc)
+{
+unsigned long itt_addr;
+u8 size;
+
+size = max(order_base_2(desc-its_mapd_cmd.dev-nr_ites), 1);
Why did you replace the ilog2 by order_base_2?
+itt_addr = __pa(desc-its_mapd_cmd.dev-itt_addr);
+itt_addr = ALIGN(itt_addr, ITS_ITT_ALIGN);
+
+memset(cmd, 0x0, sizeof(its_cmd_block));
You duplicate this line in ever build_*_cmd function. I think you should
call only in one place before the builder.
+cmd-mapd.cmd = GITS_CMD_MAPD;
+cmd-mapd.devid = desc-its_mapd_cmd.dev-device_id;
+cmd-mapd.size = size - 1;
+cmd-mapd.itt = itt_addr 8;
I think the code is more difficult to read without the helpers. You
opencode every trick in all the builder rather than in a single place.
+cmd-mapd.valid = desc-its_mapd_cmd.valid;
+
+#ifdef DEBUG_GIC_ITS
+dump_cmd(cmd);
+#endif
The dump can be done in a single place rather than in every builder.
+/* Take first collection for sync */
+return desc-its_mapd_cmd.dev-its-collections[0];
+}
+
+static struct its_collection *its_build_mapc_cmd(its_cmd_block *cmd,
+ struct its_cmd_desc *desc)
+{
+memset(cmd, 0x0, sizeof(its_cmd_block));
+cmd-mapc.cmd = GITS_CMD_MAPC;
+cmd-mapc.col = desc-its_mapc_cmd.col-col_id;
+/*
+ * Thought target address field is only 32 bit.
I don't understand what you mean with thought.
+ * So take bit[48:16]
Can you explain why you are using only the [48:16]? I.e that target
addresses must be 64KB aligned...
+ */
+cmd-mapc.ta = desc-its_mapc_cmd.col-target_address 16;
+cmd-mapc.valid = desc-its_mapc_cmd.valid;
+
+#ifdef DEBUG_GIC_ITS
+dump_cmd(cmd);
+#endif
Missing newline.
[..]
+static void its_send_single_command(struct its_node *its,
+its_cmd_builder_t builder,
+struct its_cmd_desc *desc)
+{
+its_cmd_block *cmd, *sync_cmd, *next_cmd;
+struct its_collection *sync_col;
+unsigned long flags;
+
+spin_lock_irqsave(its-lock, flags);
+
+cmd = its_allocate_entry(its);
+if ( !cmd )
+{/* We're soo screewed... */
I think the /* ... */ should go on a separate line.
+its_err_ratelimit(ITS can't allocate, dropping command\n);
+spin_unlock_irqrestore(its-lock, flags);
+return;
+}
+sync_col = builder(cmd, desc);
+its_flush_cmd(its, cmd);
+
+if ( sync_col )
+{
+sync_cmd = its_allocate_entry(its);
+if ( !sync_cmd )
+{
+its_err_ratelimit(ITS can't SYNC, skipping\n);
+goto post;
+}
+
Re: [Xen-devel] [PATCH RFC 3/4] xen: implement SCHEDOP_soft_reset
On 22.06.15 at 18:00, vkuzn...@redhat.com wrote: Jan Beulich jbeul...@suse.com writes: On 03.06.15 at 15:35, vkuzn...@redhat.com wrote: @@ -1129,8 +1129,9 @@ void unmap_vcpu_info(struct vcpu *v) mfn = v-vcpu_info_mfn; unmap_domain_page_global((void *) ((unsigned long)v-vcpu_info PAGE_MASK)); - -v-vcpu_info = dummy_vcpu_info; +v-vcpu_info = ((v-vcpu_id XEN_LEGACY_MAX_VCPUS) +? (vcpu_info_t *)shared_info(d, vcpu_info[v-vcpu_id]) Is this cast really needed? Without it my gcc-4.8.3 complains: domain.c: In function ‘unmap_vcpu_info’: domain.c:1158:21: error: pointer type mismatch in conditional expression [-Werror] : dummy_vcpu_info); ^ cc1: all warnings being treated as errors Which is the kind of warning one normally should _not_ work around by adding a cast. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 58821: tolerable FAIL
On Mon, 2015-06-22 at 17:00 +0100, Andrew Cooper wrote: On 22/06/15 16:36, Jan Beulich wrote: On 22.06.15 at 17:17, ian.campb...@citrix.com wrote: On Mon, 2015-06-22 at 14:09 +, osstest service user wrote: flight 58821 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/58821/ [...] test-amd64-amd64-libvirt 11 guest-start fail like 58789 http://logs.test-lab.xenproject.org/osstest/logs/58821/test-amd64-amd64-libv irt/info.html While investigating why libvirt hasn't been succeeding very well on merlot* I came across some things in the serial log which initially struck me as odd, but which I suspect are nothing (or at least not terribly relevant), if someone could confirm that would be great. Firstly is: Jun 22 12:41:09.633294 (XEN) microcode: CPU2 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.665099 (XEN) microcode: CPU4 updated from revision 0x6000822 to 0x6000832 Jun 22 12:41:09.729089 (XEN) microcode: CPU6 updated from revision 0x6000822 to 0x6000832 [...] i.e. only even numbered cpus are updated. (0 was done earlier in boot). I suspect that the answer here is hyperthreading, and the cpuinfo shows all cpus have in fact been updated. Yes (albeit hyperthreading is an Intel term, but iirc the same applies to the two cores per compute unit). Indeed. The microcode: patch is already at required level or greater.\n message is helpfully unconditionally compiled out. The second thing is: Jun 22 12:41:10.601103 (XEN) Brought up 32 CPUs Jun 22 12:41:10.625270 (XEN) Testing NMI watchdog on all CPUs: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 stuck i.e. at least one CPU has issues with NMI watchdog (looking at other runs it seems to vary between 29-31). Is this just that the NMI watchdog doesn't deal well with so many pCPUs? Or is it a real issue? Very few CPUs properly responding is certainly quite odd; one would expect all or none of them to work. Perhaps our AMD maintainers (now Cc-ed) could take a look... There are several things wrong with the NMI testing in Xen atm, following some recent investigation in XenServer. Time isn't accounted properly for cores under bios/hardware power control, and Xen doesn't wait for the requisite time even if the core were running at its expected frequency. I should see about making those patches appear, but for now, ignore this line. It is more than likely wrong. Thanks. I think that means all three issues are not something wrong with the host, so I shall ignore them (which leaves me none the wiser about the actual failure, oh well...) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 0/2] OSSTEST: introduce a raisin build test
Hi all, the first patch introduces a Raisin build job, meant to test Raisin itself. The second patch push-gates Raisin on successful builds. Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com Changes in v7: - update raisin git url after http://marc.info/?l=xen-develm=143472251602803 - add a patch to push-gate raisin Changes in v6: - move divide to Osstest/BuildSupport.pm and rename it to divide_xen_build; use divide_xen_build in ts-raisin-build and ts-xen-build. Changes in v5: - remove setting DEFAULT_REVISION_RAISIN to master - disable raisin when branch is not xen* - do not overwrite raisin default variables unless both revision_* and tree_* are set of a given component Changes in v4: - introduce enable_raisin in mfi-common: only build raisin when building xen-unstable - start off from the default raisin config, then append osstest config options to it - do not write variable to the raisin config if the conrresponding runvar is not set - remove TREE_OVMF and TREE_SEABIOS Changes in v3: - use $raisindir throughout ts-raisin-build - do not specify ENABLED_COMPONENTS so that empty REVISION variables can be used to disable building a raisin component Changes in v2: - set revision_* variables in mfi-common; - in ts-raisin-build set the *_REVISION config options based on the revision_* variables; - in ts-raisin-build, call store_revision appropriately; - divide the output in an hypervisor and a tools tarball. Stefano Stabellini (2): OSSTEST: introduce a raisin build test OSSTest: push successful raisin builds Osstest/BuildSupport.pm | 48 + ap-common |5 ++ ap-fetch-version|3 ++ ap-fetch-version-old|5 ++ ap-print-url|3 ++ ap-push |5 ++ cr-daily-branch |8 +++ cri-common |1 + mfi-common | 41 +++ sg-run-job |5 ++ ts-raisin-build | 133 +++ ts-xen-build| 44 +--- 12 files changed, 259 insertions(+), 42 deletions(-) create mode 100755 ts-raisin-build ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxl: Add AHCI support for upstream qemu
Usage:
ahci=0|1 (default=0)
If enabled adds ich9 disk controller in ahci mode and uses it with
upstream qemu to emulate disks instead of ide.
It doesn't support cdroms which still using ide (cdroms will use
-device ide-cd as new qemu parameter)
Ahci requires new qemu parameter but for now other emulated disks cases
remains with old ones (I did it in other patch, not needed by this one)
I did it as libxl parameter disabled by default to avoid possible
problems:
- with save/restore/migration (restoring with ahci a domU that was with
ide instead)
- windows 8 without pv drivers (a registry key change is needed for
AHCI-IDE change FWIK to avoid possible blue screen)
- windows XP or older that many not support ahci by default.
Setting AHCI with libxl parameter and default to disabled seems the best
solution.
AHCI increase hvm domUs boot performance. On linux hvm domU I saw up to
only 20% of the previous total boot time, whereas boot time decrease a
lot on W7 domUs for most of boots I have done. Small difference in boot
time compared to ide mode on W8 and newer (probably other xen
improvements or fixes are needed not ahci related)
Signed-off-by: Fabio Fantoni fabio.fant...@m2r.biz
---
docs/man/xl.cfg.pod.5 | 9 +
tools/libxl/libxl.h | 10 ++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_dm.c | 10 +-
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c| 1 +
6 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index a3e0e2e..7e16123 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -904,6 +904,15 @@ default is Bcd.
=back
+=item Bahci=[0|1]
+
+If enabled adds ich9 disk controller in ahci mode and uses it with
+upstream qemu to emulate disks instead of ide. It decrease boot time but
+may be not supported by default in windows xp and older windows.
+The default is disabled (0).
+
+=back
+
=head3 Paging
The following options control the mechanisms used to virtualise guest
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 0a7913b..6a3677d 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -596,6 +596,16 @@ typedef struct libxl__ctx libxl_ctx;
#define LIBXL_HAVE_SPICE_STREAMINGVIDEO 1
/*
+ * LIBXL_HAVE_AHCI
+ *
+ * If defined, then the u.hvm structure will contain a boolean type:
+ * ahci. This value defines if ahci support is present.
+ *
+ * If this is not defined, the ahci support is ignored.
+ */
+#define LIBXL_HAVE_AHCI 1
+
+/*
* LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS 1
*
* If this is defined, libxl_domain_create_restore()'s API has changed to
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 86384d2..8ca2481 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -331,6 +331,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
libxl_defbool_setdefault(b_info-u.hvm.nested_hvm, false);
libxl_defbool_setdefault(b_info-u.hvm.usb,false);
libxl_defbool_setdefault(b_info-u.hvm.xen_platform_pci, true);
+libxl_defbool_setdefault(b_info-u.hvm.ahci, false);
libxl_defbool_setdefault(b_info-u.hvm.spice.enable, false);
if (!libxl_defbool_val(b_info-u.hvm.spice.enable)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 33f9ce6..93f191a 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -818,6 +818,8 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
flexarray_append(dm_args, libxl__sprintf(gc, %PRId64, ram_size));
if (b_info-type == LIBXL_DOMAIN_TYPE_HVM) {
+if (libxl_defbool_val(b_info-u.hvm.ahci))
+flexarray_append_pair(dm_args, -device, ahci,id=ahci0);
for (i = 0; i num_disks; i++) {
int disk, part;
int dev_number =
@@ -872,7 +874,13 @@ static int libxl__build_device_model_args_new(libxl__gc
*gc,
drive = libxl__sprintf
(gc,
file=%s,if=scsi,bus=0,unit=%d,format=%s,cache=writeback,
pdev_path, disk, format);
-else if (disk 4)
+else if (disk 6 libxl_defbool_val(b_info-u.hvm.ahci)){
+flexarray_vappend(dm_args, -drive,
+
GCSPRINTF(file=%s,if=none,id=ahcidisk-%d,format=%s,cache=writeback,
+pdev_path, disk, format), -device,
GCSPRINTF(ide-hd,bus=ahci0.%d,unit=0,drive=ahcidisk-%d,
+disk, disk), NULL);
+continue;
+}else if (disk 4)
drive = libxl__sprintf
(gc,
file=%s,if=ide,index=%d,media=disk,format=%s,cache=writeback,
pdev_path, disk, format);
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 23f27d4..f107689 100644
--- a/tools/libxl/libxl_types.idl
+++
Re: [Xen-devel] [PATCH RFC 3/4] xen: implement SCHEDOP_soft_reset
Jan Beulich jbeul...@suse.com writes: On 22.06.15 at 18:00, vkuzn...@redhat.com wrote: Jan Beulich jbeul...@suse.com writes: On 03.06.15 at 15:35, vkuzn...@redhat.com wrote: @@ -1129,8 +1129,9 @@ void unmap_vcpu_info(struct vcpu *v) mfn = v-vcpu_info_mfn; unmap_domain_page_global((void *) ((unsigned long)v-vcpu_info PAGE_MASK)); - -v-vcpu_info = dummy_vcpu_info; +v-vcpu_info = ((v-vcpu_id XEN_LEGACY_MAX_VCPUS) +? (vcpu_info_t *)shared_info(d, vcpu_info[v-vcpu_id]) Is this cast really needed? Without it my gcc-4.8.3 complains: domain.c: In function ‘unmap_vcpu_info’: domain.c:1158:21: error: pointer type mismatch in conditional expression [-Werror] : dummy_vcpu_info); ^ cc1: all warnings being treated as errors Which is the kind of warning one normally should _not_ work around by adding a cast. In this (and in alloc_vcpu() from where this expression was copied) particular case this is probably OK: in struct shared_info we have 'struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS]' as its first member. But I may be missing something.. -- Vitaly ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/6] AMD-PVH: DomU support
From: Elena Ufimtseva elena.ufimts...@oracle.com This is a re-spin of patches for AMD PVH DomU from Mukesh Rathor. As I am diving into more details of AMD PVH, I am reposting his series with minor changes that reviewers (Jan and Boris) posted in comments. The issue with handle_mmio is not yet addressed and I would like to continue discussion Mukesh and Jan previously had in this thread http://lists.xen.org/archives/html/xen-devel/2014-08/msg01760.html The latest proposed solution was to create additional x86_emulate_ops structure that will handle pvh mmio correctly. Should I consider this approach as the one I should be working on? In vmcb construction patch comments Roger suggested to add additional parameter to vcpu_initialise as 32 bit work is in. Since Boris has posted 32-bit pvh domU support, that would be changed and I wanted to see if this is what everyone agrees on. Any other ideas/comments are also appreciated. Thank you. Changes made in this re-post: - left out setting LMA bit in construct_vmcb as its done in hvm_vcpu_initialise; - instead of checking if regs ptr is set in vcpu_vlapic, check if its pvh_domain; Elena Ufimtseva (6): pvh: domu construct vmcb 64 bit mode start AMD-PVH: cpuid intercept AMD-PVH: call hvm_emulate_one instead of handle_mmio AMD-PVH: Do not get/set vlapic TPR AMD-PVH: Support TSC_MODE_NEVER_EMULATE for PVH AMD-PVH: enable pvh if requirements met xen/arch/x86/hvm/svm/svm.c | 80 ++--- xen/arch/x86/hvm/svm/vmcb.c | 16 +++-- xen/arch/x86/time.c | 1 + 3 files changed, 68 insertions(+), 29 deletions(-) -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 5/6] AMD-PVH: Support TSC_MODE_NEVER_EMULATE for PVH
From: Elena Ufimtseva elena.ufimts...@oracle.com
On AMD, MSR_AMD64_TSC_RATIO must be set for rdtsc instruction in guest
to properly read the cpu tsc. To that end, set tsc_khz in struct domain.
Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
xen/arch/x86/time.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index bbb7e6c..d9709ce 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1923,6 +1923,7 @@ void tsc_set_info(struct domain *d,
* but always_emulate does not for some reason. Figure out
* why.
*/
+d-arch.tsc_khz = cpu_khz;
switch ( tsc_mode )
{
case TSC_MODE_NEVER_EMULATE:
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 6/6] AMD-PVH: enable pvh if requirements met
From: Elena Ufimtseva elena.ufimts...@oracle.com Finally, enable pvh if the cpu supports NPT and svm decode. Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com --- xen/arch/x86/hvm/svm/svm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 64d22fe..9945550 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -1444,6 +1444,9 @@ const struct hvm_function_table * __init start_svm(void) svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB | ((cpuid_edx(0x8001) 0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0); +if ( cpu_has_svm_npt cpu_has_svm_decode ) +svm_function_table.pvh_supported = 1; + return svm_function_table; } -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/6] AMD-PVH: cpuid intercept
From: Elena Ufimtseva elena.ufimts...@oracle.com
Call pv_cpuid for pvh cpuid intercept. Note, we modify
svm_vmexit_do_cpuid instead of the intercept switch because the guest
eip needs to be adjusted for pvh also.
Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com
---
xen/arch/x86/hvm/svm/svm.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 6734fb6..28792fe 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1584,19 +1584,22 @@ static void svm_vmexit_do_cpuid(struct cpu_user_regs
*regs)
if ( (inst_len = __get_instruction_length(current, INSTR_CPUID)) == 0 )
return;
+if ( is_pvh_vcpu(current) )
+pv_cpuid(regs);
+else
+{
+eax = regs-eax;
+ebx = regs-ebx;
+ecx = regs-ecx;
+edx = regs-edx;
-eax = regs-eax;
-ebx = regs-ebx;
-ecx = regs-ecx;
-edx = regs-edx;
-
-svm_cpuid_intercept(eax, ebx, ecx, edx);
-
-regs-eax = eax;
-regs-ebx = ebx;
-regs-ecx = ecx;
-regs-edx = edx;
+svm_cpuid_intercept(eax, ebx, ecx, edx);
+regs-eax = eax;
+regs-ebx = ebx;
+regs-ecx = ecx;
+regs-edx = edx;
+}
__update_guest_eip(regs, inst_len);
}
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/6] pvh: domu construct vmcb 64 bit mode start
From: Elena Ufimtseva elena.ufimts...@oracle.com Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com --- xen/arch/x86/hvm/svm/vmcb.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 6339d2a..70a6588 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -162,7 +162,12 @@ static int construct_vmcb(struct vcpu *v) vmcb-ds.attr.bytes = 0xc93; vmcb-fs.attr.bytes = 0xc93; vmcb-gs.attr.bytes = 0xc93; -vmcb-cs.attr.bytes = 0xc9b; /* exec/read, accessed */ + +if ( is_pvh_vcpu(v) ) +/* CS.L == 1, exec, read/write, accessed. PVH 32bitfixme. */ +vmcb-cs.attr.bytes = 0xa9b; +else +vmcb-cs.attr.bytes = 0xc9b; /* exec/read, accessed */ /* Guest IDT. */ vmcb-idtr.base = 0; @@ -184,12 +189,17 @@ static int construct_vmcb(struct vcpu *v) vmcb-tr.limit = 0xff; v-arch.hvm_vcpu.guest_cr[0] = X86_CR0_PE | X86_CR0_ET; +/* PVH domains start in paging mode */ +if ( is_pvh_vcpu(v) ) +v-arch.hvm_vcpu.guest_cr[0] |= X86_CR0_PG; hvm_update_guest_cr(v, 0); -v-arch.hvm_vcpu.guest_cr[4] = 0; +v-arch.hvm_vcpu.guest_cr[4] = is_pvh_vcpu(v) ? X86_CR4_PAE : 0; hvm_update_guest_cr(v, 4); -paging_update_paging_modes(v); +/* For pvh, paging mode is updated by arch_set_info_guest(). */ +if ( is_hvm_vcpu(v) ) +paging_update_paging_modes(v); vmcb-_exception_intercepts = HVM_TRAP_MASK -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen{trace/analyze}: don't use 64bit versions of libc functions
El 22/06/15 a les 12.09, George Dunlap ha escrit: On 06/22/2015 10:59 AM, Roger Pau Monné wrote: El 22/06/15 a les 11.08, George Dunlap ha escrit: On 06/19/2015 09:58 AM, Roger Pau Monne wrote: This is not needed, neither encouraged. Configure already checks _FILE_OFFSET_BITS and appends it when needed, so that the right functions are used. Also remove the usage of loff_t and O_LARGEFILE for the same reason. Just so I understand -- are you saying that configure at the tools directory level will notice that Linux can handle 64-bit file operations and use them automatically? Yes, according to the man page [1]: Over time, increases in the size of the stat structure have led to three successive versions of stat(): sys_stat() (slot __NR_oldstat), sys_newstat() (slot __NR_stat), and sys_stat64() (new in kernel 2.4; slot __NR_stat64). The glibc stat() wrapper function hides these details from applications, invoking the most recent version of the system call provided by the kernel, and repacking the returned information if required for old binaries. Similar remarks apply for fstat() and lstat(). OK, if you can confirm that you've actually tested this on a file larger than 4GiB, then: No, I have only build tested it since I was trying to unbreak the build. I don't think I will have time to test this until tomorrow, sorry for the delay. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/6] x86/MSI-X: be more careful during teardown
When a device gets detached from a guest, pciback will clear its
command register, thus disabling both memory and I/O decoding. The
disabled memory decoding, however, has an effect on the MSI-X table
accesses the hypervisor does: These won't have the intended effect
anymore. Even worse, for PCIe devices (but not SR-IOV virtual
functions) such accesses may (will?) be treated as Unsupported
Requests, causing respective errors to be surfaced, potentially in the
form of NMIs that may be fatal to the hypervisor or Dom0 is different
ways. Hence rather than carrying out these accesses, we should avoid
them where we can, and use alternative (e.g. PCI config space based)
mechanisms to achieve at least the same effect.
At this time it continues to be unclear whether this is fixing an
actual bug or is rather just working around bogus (but apparently
common) system behavior.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
---
Backporting note (largely to myself):
Depends on (not yet backported to 4.4 and earlier) commit 061eebe0e
x86/MSI: drop workaround for insecure Dom0 kernels (due to re-use
of struct arch_msix's warned field).
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -217,9 +217,9 @@ void destroy_irq(unsigned int irq)
}
spin_lock_irqsave(desc-lock, flags);
-desc-status |= IRQ_DISABLED;
desc-status = ~IRQ_GUEST;
desc-handler-shutdown(desc);
+desc-status |= IRQ_DISABLED;
action = desc-action;
desc-action = NULL;
desc-msi_desc = NULL;
@@ -995,8 +995,8 @@ void __init release_irq(unsigned int irq
spin_lock_irqsave(desc-lock,flags);
action = desc-action;
desc-action = NULL;
-desc-status |= IRQ_DISABLED;
desc-handler-shutdown(desc);
+desc-status |= IRQ_DISABLED;
spin_unlock_irqrestore(desc-lock,flags);
/* Wait to make sure it's not being used on another CPU */
@@ -1732,8 +1732,8 @@ static irq_guest_action_t *__pirq_guest_
BUG_ON(action-in_flight != 0);
/* Disabling IRQ before releasing the desc_lock avoids an IRQ storm. */
-desc-status |= IRQ_DISABLED;
desc-handler-disable(desc);
+desc-status |= IRQ_DISABLED;
/*
* Mark any remaining pending EOIs as ready to flush.
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -123,6 +123,27 @@ static void msix_put_fixmap(struct arch_
spin_unlock(msix-table_lock);
}
+static bool_t memory_decoded(const struct pci_dev *dev)
+{
+u8 bus, slot, func;
+
+if ( !dev-info.is_virtfn )
+{
+bus = dev-bus;
+slot = PCI_SLOT(dev-devfn);
+func = PCI_FUNC(dev-devfn);
+}
+else
+{
+bus = dev-info.physfn.bus;
+slot = PCI_SLOT(dev-info.physfn.devfn);
+func = PCI_FUNC(dev-info.physfn.devfn);
+}
+
+return !!(pci_conf_read16(dev-seg, bus, slot, func, PCI_COMMAND)
+ PCI_COMMAND_MEMORY);
+}
+
/*
* MSI message composition
*/
@@ -166,7 +187,7 @@ void msi_compose_msg(unsigned vector, co
}
}
-static void read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
+static bool_t read_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
{
switch ( entry-msi_attrib.type )
{
@@ -201,6 +222,8 @@ static void read_msi_msg(struct msi_desc
{
void __iomem *base = entry-mask_base;
+if ( unlikely(!memory_decoded(entry-dev)) )
+return 0;
msg-address_lo = readl(base + PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET);
msg-address_hi = readl(base + PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET);
msg-data = readl(base + PCI_MSIX_ENTRY_DATA_OFFSET);
@@ -212,6 +235,8 @@ static void read_msi_msg(struct msi_desc
if ( iommu_intremap )
iommu_read_msi_from_ire(entry, msg);
+
+return 1;
}
static int write_msi_msg(struct msi_desc *entry, struct msi_msg *msg)
@@ -262,6 +287,8 @@ static int write_msi_msg(struct msi_desc
{
void __iomem *base = entry-mask_base;
+if ( unlikely(!memory_decoded(entry-dev)) )
+return -ENXIO;
writel(msg-address_lo,
base + PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET);
writel(msg-address_hi,
@@ -289,7 +316,8 @@ void set_msi_affinity(struct irq_desc *d
ASSERT(spin_is_locked(desc-lock));
memset(msg, 0, sizeof(msg));
-read_msi_msg(msi_desc, msg);
+if ( !read_msi_msg(msi_desc, msg) )
+return;
msg.data = ~MSI_DATA_VECTOR_MASK;
msg.data |= MSI_DATA_VECTOR(desc-arch.vector);
@@ -349,23 +377,27 @@ int msi_maskable_irq(const struct msi_de
|| entry-msi_attrib.maskbit;
}
-static void msi_set_mask_bit(struct irq_desc *desc, bool_t host, bool_t guest)
+static bool_t msi_set_mask_bit(struct irq_desc *desc, bool_t host, bool_t
guest)
{
struct msi_desc *entry = desc-msi_desc;
+struct pci_dev *pdev;
+u16 seg;
+u8 bus, slot, func;
bool_t flag = host || guest;
ASSERT(spin_is_locked(desc-lock));
BUG_ON(!entry
[Xen-devel] [PATCH v4 4/6] x86/MSI-X: access MSI-X table only after having enabled MSI-X
As done in Linux by f598282f51 (PCI: Fix the NIU MSI-X problem in a
better way) and its broken predecessor, make sure we don't access the
MSI-X table without having enabled MSI-X first, using the mask-all flag
instead to prevent interrupts from occurring.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -144,6 +144,17 @@ static bool_t memory_decoded(const struc
PCI_COMMAND_MEMORY);
}
+static bool_t msix_memory_decoded(const struct pci_dev *dev, unsigned int pos)
+{
+u16 control = pci_conf_read16(dev-seg, dev-bus, PCI_SLOT(dev-devfn),
+ PCI_FUNC(dev-devfn), msix_control_reg(pos));
+
+if ( !(control PCI_MSIX_FLAGS_ENABLE) )
+return 0;
+
+return memory_decoded(dev);
+}
+
/*
* MSI message composition
*/
@@ -222,7 +233,8 @@ static bool_t read_msi_msg(struct msi_de
{
void __iomem *base = entry-mask_base;
-if ( unlikely(!memory_decoded(entry-dev)) )
+if ( unlikely(!msix_memory_decoded(entry-dev,
+ entry-msi_attrib.pos)) )
return 0;
msg-address_lo = readl(base + PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET);
msg-address_hi = readl(base + PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET);
@@ -287,7 +299,8 @@ static int write_msi_msg(struct msi_desc
{
void __iomem *base = entry-mask_base;
-if ( unlikely(!memory_decoded(entry-dev)) )
+if ( unlikely(!msix_memory_decoded(entry-dev,
+ entry-msi_attrib.pos)) )
return -ENXIO;
writel(msg-address_lo,
base + PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET);
@@ -381,9 +394,9 @@ static bool_t msi_set_mask_bit(struct ir
{
struct msi_desc *entry = desc-msi_desc;
struct pci_dev *pdev;
-u16 seg;
+u16 seg, control;
u8 bus, slot, func;
-bool_t flag = host || guest;
+bool_t flag = host || guest, maskall;
ASSERT(spin_is_locked(desc-lock));
BUG_ON(!entry || !entry-dev);
@@ -406,36 +419,45 @@ static bool_t msi_set_mask_bit(struct ir
}
break;
case PCI_CAP_ID_MSIX:
+maskall = pdev-msix-host_maskall;
+control = pci_conf_read16(seg, bus, slot, func,
+ msix_control_reg(entry-msi_attrib.pos));
+if ( unlikely(!(control PCI_MSIX_FLAGS_ENABLE)) )
+{
+pdev-msix-host_maskall = 1;
+pci_conf_write16(seg, bus, slot, func,
+ msix_control_reg(entry-msi_attrib.pos),
+ control | (PCI_MSIX_FLAGS_ENABLE |
+PCI_MSIX_FLAGS_MASKALL));
+}
if ( likely(memory_decoded(pdev)) )
{
writel(flag, entry-mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
readl(entry-mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
-break;
+if ( likely(control PCI_MSIX_FLAGS_ENABLE) )
+break;
+flag = 1;
}
-if ( flag )
+else if ( flag !(control PCI_MSIX_FLAGS_MASKALL) )
{
-u16 control;
domid_t domid = pdev-domain-domain_id;
-pdev-msix-host_maskall = 1;
-control = pci_conf_read16(seg, bus, slot, func,
- msix_control_reg(entry-msi_attrib.pos));
-if ( control PCI_MSIX_FLAGS_MASKALL )
-break;
-pci_conf_write16(seg, bus, slot, func,
- msix_control_reg(entry-msi_attrib.pos),
- control | PCI_MSIX_FLAGS_MASKALL);
+maskall = 1;
if ( pdev-msix-warned != domid )
{
pdev-msix-warned = domid;
printk(XENLOG_G_WARNING
- cannot mask IRQ %d: masked MSI-X on Dom%d's
%04x:%02x:%02x.%u\n,
+ cannot mask IRQ %d: masking MSI-X on Dom%d's
%04x:%02x:%02x.%u\n,
desc-irq, domid, pdev-seg, pdev-bus,
PCI_SLOT(pdev-devfn), PCI_FUNC(pdev-devfn));
}
-break;
}
-/* fall through */
+pdev-msix-host_maskall = maskall;
+if ( maskall || pdev-msix-guest_maskall )
+control |= PCI_MSIX_FLAGS_MASKALL;
+pci_conf_write16(seg, bus, slot, func,
+ msix_control_reg(entry-msi_attrib.pos), control);
+return flag;
default:
return 0;
}
@@ -461,7 +483,8 @@ static int msi_get_mask_bit(const struct
entry-msi.mpos)
entry-msi_attrib.entry_nr) 1;
case PCI_CAP_ID_MSIX:
-if ( unlikely(!memory_decoded(entry-dev)) )
+if ( unlikely(!msix_memory_decoded(entry-dev,
+ entry-msi_attrib.pos))
[Xen-devel] [PATCH v4 RFC 6/6] x86/MSI: properly track guest masking requests
... by monitoring writes to the mask register.
This allows reverting the main effect of the XSA-129 patches in qemu.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1308,6 +1308,39 @@ printk(%04x:%02x:%02x.%u: MSI-X %03x:%u
return 1;
}
+entry = find_msi_entry(pdev, -1, PCI_CAP_ID_MSI);
+if ( entry entry-msi_attrib.maskbit )
+{
+uint16_t cntl;
+uint32_t unused;
+
+pos = entry-msi_attrib.pos;
+if ( reg pos || reg = entry-msi.mpos + 8 )
+return 0;
+printk(%04x:%02x:%02x.%u: MSI %03x:%u-%04x\n, seg, bus, slot, func, reg,
size, *data);//temp
+
+if ( reg == msi_control_reg(pos) )
+return size == 2 ? 1 : -EACCES;
+if ( reg entry-msi.mpos || reg = entry-msi.mpos + 4 || size != 4 )
+return -EACCES;
+
+cntl = pci_conf_read16(seg, bus, slot, func, msi_control_reg(pos));
+unused = ~(uint32_t)0 (32 - multi_msi_capable(cntl));
+for ( pos = 0; pos entry-msi.nvec; ++pos, ++entry )
+{
+entry-msi_attrib.guest_masked =
+*data entry-msi_attrib.entry_nr;
+if ( entry-msi_attrib.host_masked )
+*data |= 1 pos;
+unused = ~(1 pos);
+}
+printk(%04x:%02x:%02x.%u: MSI - %08x (%08x)\n, seg, bus, slot, func, *data,
unused);//temp
+
+*data |= unused;
+
+return 1;
+}
+
return 0;
}
x86/MSI: properly track guest masking requests
... by monitoring writes to the mask register.
This allows reverting the main effect of the XSA-129 patches in qemu.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1308,6 +1308,39 @@ printk(%04x:%02x:%02x.%u: MSI-X %03x:%u
return 1;
}
+entry = find_msi_entry(pdev, -1, PCI_CAP_ID_MSI);
+if ( entry entry-msi_attrib.maskbit )
+{
+uint16_t cntl;
+uint32_t unused;
+
+pos = entry-msi_attrib.pos;
+if ( reg pos || reg = entry-msi.mpos + 8 )
+return 0;
+printk(%04x:%02x:%02x.%u: MSI %03x:%u-%04x\n, seg, bus, slot, func, reg,
size, *data);//temp
+
+if ( reg == msi_control_reg(pos) )
+return size == 2 ? 1 : -EACCES;
+if ( reg entry-msi.mpos || reg = entry-msi.mpos + 4 || size != 4 )
+return -EACCES;
+
+cntl = pci_conf_read16(seg, bus, slot, func, msi_control_reg(pos));
+unused = ~(uint32_t)0 (32 - multi_msi_capable(cntl));
+for ( pos = 0; pos entry-msi.nvec; ++pos, ++entry )
+{
+entry-msi_attrib.guest_masked =
+*data entry-msi_attrib.entry_nr;
+if ( entry-msi_attrib.host_masked )
+*data |= 1 pos;
+unused = ~(1 pos);
+}
+printk(%04x:%02x:%02x.%u: MSI - %08x (%08x)\n, seg, bus, slot, func, *data,
unused);//temp
+
+*data |= unused;
+
+return 1;
+}
+
return 0;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 RFC 1/6] x86/PCI: add config space write abstract intercept logic
This is to be used by MSI code, and later to also be hooked up to
MMCFG accesses by Dom0.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -,6 +,12 @@ void pci_cleanup_msi(struct pci_dev *pde
msi_free_irqs(pdev);
}
+int pci_msi_conf_write_intercept(struct pci_dev *pdev, unsigned int reg,
+ unsigned int size, uint32_t *data)
+{
+return 0;
+}
+
int pci_restore_msi_state(struct pci_dev *pdev)
{
unsigned long flags;
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -67,3 +67,28 @@ void pci_conf_write(uint32_t cf8, uint8_
spin_unlock_irqrestore(pci_config_lock, flags);
}
+
+int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
+ unsigned int reg, unsigned int size,
+ uint32_t *data)
+{
+struct pci_dev *pdev;
+int rc = 0;
+
+/*
+ * Avoid expensive operations when no hook is going to do anything
+ * for the access anyway.
+ */
+if ( reg 64 || reg = 256 )
+return 0;
+
+spin_lock(pcidevs_lock);
+
+pdev = pci_get_pdev(seg, PCI_BUS(bdf), PCI_DEVFN2(bdf));
+if ( pdev )
+rc = pci_msi_conf_write_intercept(pdev, reg, size, data);
+
+spin_unlock(pcidevs_lock);
+
+return rc;
+}
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1771,8 +1771,8 @@ static bool_t admin_io_okay(unsigned int
return ioports_access_permitted(d, port, port + bytes - 1);
}
-static bool_t pci_cfg_ok(struct domain *currd, bool_t write,
- unsigned int start, unsigned int size)
+static bool_t pci_cfg_ok(struct domain *currd, unsigned int start,
+ unsigned int size, uint32_t *write)
{
uint32_t machine_bdf;
@@ -1804,8 +1804,12 @@ static bool_t pci_cfg_ok(struct domain *
start |= CF8_ADDR_HI(currd-arch.pci_cf8);
}
-return !xsm_pci_config_permission(XSM_HOOK, currd, machine_bdf,
- start, start + size - 1, write);
+if ( xsm_pci_config_permission(XSM_HOOK, currd, machine_bdf,
+ start, start + size - 1, !!write) != 0 )
+ return 0;
+
+return !write ||
+ pci_conf_write_intercept(0, machine_bdf, start, size, write) = 0;
}
uint32_t guest_io_read(unsigned int port, unsigned int bytes,
@@ -1857,7 +1861,7 @@ uint32_t guest_io_read(unsigned int port
size = min(bytes, 4 - (port 3));
if ( size == 3 )
size = 2;
-if ( pci_cfg_ok(currd, 0, port 3, size) )
+if ( pci_cfg_ok(currd, port 3, size, NULL) )
sub_data = pci_conf_read(currd-arch.pci_cf8, port 3, size);
}
@@ -1928,7 +1932,7 @@ void guest_io_write(unsigned int port, u
size = min(bytes, 4 - (port 3));
if ( size == 3 )
size = 2;
-if ( pci_cfg_ok(currd, 1, port 3, size) )
+if ( pci_cfg_ok(currd, port 3, size, data) )
pci_conf_write(currd-arch.pci_cf8, port 3, size, data);
}
--- a/xen/include/asm-x86/pci.h
+++ b/xen/include/asm-x86/pci.h
@@ -15,4 +15,10 @@ struct arch_pci_dev {
vmask_t used_vectors;
};
+int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
+ unsigned int reg, unsigned int size,
+ uint32_t *data);
+int pci_msi_conf_write_intercept(struct pci_dev *, unsigned int reg,
+ unsigned int size, uint32_t *data);
+
#endif /* __X86_PCI_H__ */
x86/PCI: add config space write abstract intercept logic
This is to be used by MSI code, and later to also be hooked up to
MMCFG accesses by Dom0.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -,6 +,12 @@ void pci_cleanup_msi(struct pci_dev *pde
msi_free_irqs(pdev);
}
+int pci_msi_conf_write_intercept(struct pci_dev *pdev, unsigned int reg,
+ unsigned int size, uint32_t *data)
+{
+return 0;
+}
+
int pci_restore_msi_state(struct pci_dev *pdev)
{
unsigned long flags;
--- a/xen/arch/x86/pci.c
+++ b/xen/arch/x86/pci.c
@@ -67,3 +67,28 @@ void pci_conf_write(uint32_t cf8, uint8_
spin_unlock_irqrestore(pci_config_lock, flags);
}
+
+int pci_conf_write_intercept(unsigned int seg, unsigned int bdf,
+ unsigned int reg, unsigned int size,
+ uint32_t *data)
+{
+struct pci_dev *pdev;
+int rc = 0;
+
+/*
+ * Avoid expensive operations when no hook is going to do anything
+ * for the access anyway.
+ */
+if ( reg 64 || reg = 256 )
+return 0;
+
+spin_lock(pcidevs_lock);
+
+pdev = pci_get_pdev(seg, PCI_BUS(bdf), PCI_DEVFN2(bdf));
+if ( pdev )
+rc = pci_msi_conf_write_intercept(pdev, reg, size, data);
+
+
Re: [Xen-devel] [RFC PATCH v3 04/18] xen/arm: gicv3: Refactor redistributor information
Hi,
On 22/06/15 13:01, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Separate redistributor information into rdist and rdist_prop
structures.
The rdist_prop holds the redistributor common information
and rdist holds the per cpu specific information.
This percpu rdist defined as global and shared with ITS
driver
This patch does more than refactoring, you are adding new fields which
are not use here.
Please explain why you need them or move them in the patch where they
are used. Comment on the usage of the field would be nice too.
FWIW, I would be in favor of the later.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3.c | 15 ++-
xen/include/asm-arm/gic_v3_defs.h | 15 +++
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 30682cf..b5c59f6 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -53,6 +53,7 @@ static struct {
paddr_t dbase;/* Address of distributor registers */
paddr_t dbase_size;
void __iomem *map_dbase; /* Mapped address of distributor registers */
+struct rdist_prop rdist_data;
struct rdist_region *rdist_regions;
uint32_t rdist_stride;
unsigned int rdist_count; /* Number of rdist regions count */
@@ -63,10 +64,10 @@ static struct {
static struct gic_info gicv3_info;
/* per-cpu re-distributor base */
-static DEFINE_PER_CPU(void __iomem*, rbase);
+DEFINE_PER_CPU(struct rdist, rdist);
#define GICD (gicv3.map_dbase)
-#define GICD_RDIST_BASE(this_cpu(rbase))
+#define GICD_RDIST_BASE(per_cpu(rdist, smp_processor_id()).rbase)
#define GICD_RDIST_SGI_BASE(GICD_RDIST_BASE + SZ_64K)
/*
@@ -613,6 +614,7 @@ static int __init gicv3_populate_rdist(void)
uint32_t aff;
uint32_t reg;
uint64_t typer;
+uint64_t offset;
uint64_t mpidr = cpu_logical_map(smp_processor_id());
/*
@@ -648,9 +650,12 @@ static int __init gicv3_populate_rdist(void)
if ( (typer 32) == aff )
{
-this_cpu(rbase) = ptr;
-printk(GICv3: CPU%d: Found redistributor in region %d
@%p\n,
-smp_processor_id(), i, ptr);
+offset = ptr - gicv3.rdist_regions[i].map_base;
+per_cpu(rdist, smp_processor_id()).rbase = ptr;
+per_cpu(rdist, smp_processor_id()).phys_base =
gicv3.rdist_regions[i].base + offset;
+printk(GICv3: CPU%d: Found redistributor in region %d
@%PRIpaddr\n,
+smp_processor_id(), i,
+per_cpu(rdist, smp_processor_id()).phys_base);
return 0;
}
if ( gicv3.rdist_stride )
diff --git a/xen/include/asm-arm/gic_v3_defs.h
b/xen/include/asm-arm/gic_v3_defs.h
index 556f114..acbb906 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -152,6 +152,21 @@
#define ICH_SGI_IRQ_SHIFT24
#define ICH_SGI_IRQ_MASK 0xf
#define ICH_SGI_TARGETLIST_MASK 0x
+
+struct rdist {
+void __iomem *rbase;
+void * pend_page;
void *pend_page;
+paddr_t phys_base;
+};
+
+struct rdist_prop {
What does prop stand for?
+void * prop_page;
Ditto.
+intid_bits;
+uint64_t flags;
+};
+
+DECLARE_PER_CPU(struct rdist, rdist);
+
#endif /* __ASM_ARM_GIC_V3_DEFS_H__ */
/*
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v25 04/15] x86/VPMU: Interface for setting PMU mode and flags
On 19.06.15 at 20:44, boris.ostrov...@oracle.com wrote:
Add runtime interface for setting PMU mode and flags. Three main modes are
provided:
* XENPMU_MODE_OFF: PMU is not virtualized
* XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts.
* XENPMU_MODE_HV: Same as XENPMU_MODE_SELF for non-proviledged guests, dom0
can profile itself and the hypervisor.
Note that PMU modes are different from what can be provided at Xen's boot
line
with 'vpmu' argument. An 'off' (or '0') value is equivalent to
XENPMU_MODE_OFF.
Any other value, on the other hand, will cause VPMU mode to be set to
XENPMU_MODE_SELF during boot.
For feature flags only Intel's BTS is currently supported.
Mode and flags are set via HYPERVISOR_xenpmu_op hypercall.
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
Acked-by: Jan Beulich jbeul...@suse.com
with one minor comment
+switch ( op )
+{
+case XENPMU_mode_set:
+{
+if ( (pmu_params.val ~(XENPMU_MODE_SELF | XENPMU_MODE_HV)) ||
+ (hweight64(pmu_params.val) 1) )
+return -EINVAL;
+
+/* 32-bit dom0 can only sample itself. */
+if ( is_pv_32bit_vcpu(current) (pmu_params.val XENPMU_MODE_HV) )
+return -EINVAL;
+
+spin_lock(vpmu_lock);
+
+/*
+ * We can always safely switch between XENPMU_MODE_SELF and
+ * XENPMU_MODE_HV while other VPMUs are active.
+ */
+if ( (vpmu_count == 0) || (vpmu_mode == pmu_params.val) ||
+ ((vpmu_mode ^ pmu_params.val) ==
+ (XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
+vpmu_mode = pmu_params.val;
+else
+{
I think this would better be
if ( (vpmu_count == 0) ||
((vpmu_mode ^ pmu_params.val) ==
(XENPMU_MODE_SELF | XENPMU_MODE_HV)) )
vpmu_mode = pmu_params.val;
else if ( vpmu_mode != pmu_params.val )
{
But there's no need to re-submit just because of this (it could be
changed upon commit if you agree).
Or wait - I just checked again, and while I thought this was long
addressed I still don't seen struct xen_pmu_params pad field
being checked to be zero as input, and being stored as zero when
only an output. Did this get lost? Did I forget about a reason why
this isn't being done? Unless the latter is the case, the ack above
is dependent upon this getting fixed.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v25 07/15] x86/VPMU: Save VPMU state for PV guests during context switch
On 19.06.15 at 20:44, boris.ostrov...@oracle.com wrote: Save VPMU state during context switch for both HVM and PV(H) guests. A subsequent patch (x86/VPMU: NMI-based VPMU support) will make it possible for vpmu_switch_to() to call vmx_vmcs_try_enter()-vcpu_pause() which needs is_running to be correctly set/cleared. To prepare for that, call context_saved() before vpmu_switch_to() is executed. (Note that while this change could have been dalayed until that later patch, the changes are harmless to existing code and so we do it here) Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com --- Changes in v25: * Replaced is_hvm_vcpu with is_hvm_domain to be consistent with recent changes to context_switch() That's not really a change, but just a re-base (your code doesn't add any new uses), so imo doesn't invalidate previous ack/reviews. I.e. Reviewed-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1 00/13] Introduce HMV without dm and new boot ABI
Hi Roger, given that this patch series is actually using the Xen hvm builder, I take that all the PVH code paths in Xen or the guest kernel are not actually used, correct? This is more like PV on HVM without QEMU, right? Do you think think this can work for Dom0 too? Would that make all the PVH stuff in Xen and Linux effectively useless? Thanks, Stefano On Mon, 22 Jun 2015, Roger Pau Monne wrote: Before reading any further, keep in mind this is a VERY inital RFC prototype series. Many things are not finished, and those that are done make heavy use of duck tape in order to keep things into place. Now that you are warned, this series is split in the following order: - Patches from 1 to 7 switch HVM domain contruction to use the xc_dom_* family of functions, like they are used to build PV domains. - Patches from 8 to 13 introduce the creation of HVM domains without firmware, which is replaced by directly loading a kernel like it's done for PV guests. A new boot ABI based on the discussion in the thread RFC: making the PVH 64bit ABI as stable is also introduced, although it's not finished. Some things that are missing from the new boot ABI: - Although it supports loading a ramdisk, there's still now defined way into how to pass this ramdisk to the guest. I'm thinking of using a HVMPARAM or simply setting a GP register to contain the address of the ramdisk. Ideally I would like to support loading more than one ramdisk. Some patches contain comments after the SoB, which in general describe the shortcommings of the implementation. The aim of those is to initiate discussion about whether the aproach taken is TRTTD. I've only tested this on Intel hw, but I see no reason why it shouldn't work on AMD. I've managed to boot FreeBSD up to the point were it should jump into user-space (I just didn't have a VBD attached to the VM so it just sits waiting for a valid disk). I have not tried to boot it any further since I think that's fine for the purpose of this series. The series can also be found in the following git repo: git://xenbits.xen.org/people/royger/xen.git branch hvm_without_dm_v1 And for the FreeBSD part: git://xenbits.xen.org/people/royger/freebsd.git branch new_entry_point_v1 In case someone wants to give it a try, I've uploaded a FreeBSD kernel that should work when booted into this mode: https://people.freebsd.org/~royger/kernel_no_dm The config file that I've used is: config kernel=/path/to/kernel_no_dm builder=hvm device_model_version=none memory=128 vcpus=1 name = freebsd /config Thanks, Roger. ___ 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 1/6] pvh: domu construct vmcb 64 bit mode start
On 06/22/2015 12:37 PM, elena.ufimts...@oracle.com wrote: From: Elena Ufimtseva elena.ufimts...@oracle.com Signed-off-by: Mukesh Rathor mukesh.rat...@oracle.com --- All of these changes are common with Intel so we should be able to move them up to common layer. (For CS attributes the 32-bit patches that I posted earlier provide set_mode op). -boris xen/arch/x86/hvm/svm/vmcb.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c index 6339d2a..70a6588 100644 --- a/xen/arch/x86/hvm/svm/vmcb.c +++ b/xen/arch/x86/hvm/svm/vmcb.c @@ -162,7 +162,12 @@ static int construct_vmcb(struct vcpu *v) vmcb-ds.attr.bytes = 0xc93; vmcb-fs.attr.bytes = 0xc93; vmcb-gs.attr.bytes = 0xc93; -vmcb-cs.attr.bytes = 0xc9b; /* exec/read, accessed */ + +if ( is_pvh_vcpu(v) ) +/* CS.L == 1, exec, read/write, accessed. PVH 32bitfixme. */ +vmcb-cs.attr.bytes = 0xa9b; +else +vmcb-cs.attr.bytes = 0xc9b; /* exec/read, accessed */ /* Guest IDT. */ vmcb-idtr.base = 0; @@ -184,12 +189,17 @@ static int construct_vmcb(struct vcpu *v) vmcb-tr.limit = 0xff; v-arch.hvm_vcpu.guest_cr[0] = X86_CR0_PE | X86_CR0_ET; +/* PVH domains start in paging mode */ +if ( is_pvh_vcpu(v) ) +v-arch.hvm_vcpu.guest_cr[0] |= X86_CR0_PG; hvm_update_guest_cr(v, 0); -v-arch.hvm_vcpu.guest_cr[4] = 0; +v-arch.hvm_vcpu.guest_cr[4] = is_pvh_vcpu(v) ? X86_CR4_PAE : 0; hvm_update_guest_cr(v, 4); -paging_update_paging_modes(v); +/* For pvh, paging mode is updated by arch_set_info_guest(). */ +if ( is_hvm_vcpu(v) ) +paging_update_paging_modes(v); vmcb-_exception_intercepts = HVM_TRAP_MASK ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 RFC 2/6] x86/MSI-X: track host and guest mask‑all requests separately
Host uses of the bits will be added subsequently, and must not be
overridden by guests (including Dom0, namely when acting on behalf of
a guest).
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -846,6 +846,12 @@ static int msix_capability_init(struct p
if ( !msix-used_entries )
{
+msix-host_maskall = 0;
+if ( !msix-guest_maskall )
+control = ~PCI_MSIX_FLAGS_MASKALL;
+else
+control |= PCI_MSIX_FLAGS_MASKALL;
+
if ( rangeset_add_range(mmio_ro_ranges, msix-table.first,
msix-table.last) )
WARN();
@@ -1114,6 +1120,36 @@ void pci_cleanup_msi(struct pci_dev *pde
int pci_msi_conf_write_intercept(struct pci_dev *pdev, unsigned int reg,
unsigned int size, uint32_t *data)
{
+u16 seg = pdev-seg;
+u8 bus = pdev-bus;
+u8 slot = PCI_SLOT(pdev-devfn);
+u8 func = PCI_FUNC(pdev-devfn);
+struct msi_desc *entry;
+unsigned int pos;
+
+if ( pdev-msix )
+{
+entry = find_msi_entry(pdev, -1, PCI_CAP_ID_MSIX);
+pos = entry ? entry-msi_attrib.pos
+: pci_find_cap_offset(seg, bus, slot, func,
+ PCI_CAP_ID_MSIX);
+ASSERT(pos);
+
+if ( reg pos || reg = msix_pba_offset_reg(pos) + 4 )
+return 0;
+printk(%04x:%02x:%02x.%u: MSI-X %03x:%u-%04x (%d,%d)\n,//temp
+ seg, bus, slot, func, reg, size, *data, pdev-msix-host_maskall,
pdev-msix-guest_maskall);//temp
+
+if ( reg != msix_control_reg(pos) || size != 2 )
+return -EACCES;
+
+pdev-msix-guest_maskall = !!(*data PCI_MSIX_FLAGS_MASKALL);
+if ( pdev-msix-host_maskall )
+*data |= PCI_MSIX_FLAGS_MASKALL;
+
+return 1;
+}
+
return 0;
}
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -233,6 +233,7 @@ struct arch_msix {
int table_refcnt[MAX_MSIX_TABLE_PAGES];
int table_idx[MAX_MSIX_TABLE_PAGES];
spinlock_t table_lock;
+bool_t host_maskall, guest_maskall;
domid_t warned;
};
x86/MSI-X: track host and guest mask-all requests separately
Host uses of the bits will be added subsequently, and must not be
overridden by guests (including Dom0, namely when acting on behalf of
a guest).
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -846,6 +846,12 @@ static int msix_capability_init(struct p
if ( !msix-used_entries )
{
+msix-host_maskall = 0;
+if ( !msix-guest_maskall )
+control = ~PCI_MSIX_FLAGS_MASKALL;
+else
+control |= PCI_MSIX_FLAGS_MASKALL;
+
if ( rangeset_add_range(mmio_ro_ranges, msix-table.first,
msix-table.last) )
WARN();
@@ -1114,6 +1120,36 @@ void pci_cleanup_msi(struct pci_dev *pde
int pci_msi_conf_write_intercept(struct pci_dev *pdev, unsigned int reg,
unsigned int size, uint32_t *data)
{
+u16 seg = pdev-seg;
+u8 bus = pdev-bus;
+u8 slot = PCI_SLOT(pdev-devfn);
+u8 func = PCI_FUNC(pdev-devfn);
+struct msi_desc *entry;
+unsigned int pos;
+
+if ( pdev-msix )
+{
+entry = find_msi_entry(pdev, -1, PCI_CAP_ID_MSIX);
+pos = entry ? entry-msi_attrib.pos
+: pci_find_cap_offset(seg, bus, slot, func,
+ PCI_CAP_ID_MSIX);
+ASSERT(pos);
+
+if ( reg pos || reg = msix_pba_offset_reg(pos) + 4 )
+return 0;
+printk(%04x:%02x:%02x.%u: MSI-X %03x:%u-%04x (%d,%d)\n,//temp
+ seg, bus, slot, func, reg, size, *data, pdev-msix-host_maskall,
pdev-msix-guest_maskall);//temp
+
+if ( reg != msix_control_reg(pos) || size != 2 )
+return -EACCES;
+
+pdev-msix-guest_maskall = !!(*data PCI_MSIX_FLAGS_MASKALL);
+if ( pdev-msix-host_maskall )
+*data |= PCI_MSIX_FLAGS_MASKALL;
+
+return 1;
+}
+
return 0;
}
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -233,6 +233,7 @@ struct arch_msix {
int table_refcnt[MAX_MSIX_TABLE_PAGES];
int table_idx[MAX_MSIX_TABLE_PAGES];
spinlock_t table_lock;
+bool_t host_maskall, guest_maskall;
domid_t warned;
};
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 RFC 5/6] x86/MSI-X: reduce fiddling with control register during restore
Rather than disabling and enabling MSI-X once per vector, do it just
once per device.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1319,6 +1319,9 @@ int pci_restore_msi_state(struct pci_dev
struct msi_desc *entry, *tmp;
struct irq_desc *desc;
struct msi_msg msg;
+u8 slot = PCI_SLOT(pdev-devfn), func = PCI_FUNC(pdev-devfn);
+unsigned int type = 0, pos = 0;
+u16 control = 0;
ASSERT(spin_is_locked(pcidevs_lock));
@@ -1337,8 +1340,6 @@ int pci_restore_msi_state(struct pci_dev
list_for_each_entry_safe( entry, tmp, pdev-msi_list, list )
{
unsigned int i = 0, nr = 1;
-u16 control = 0;
-u8 slot = PCI_SLOT(pdev-devfn), func = PCI_FUNC(pdev-devfn);
irq = entry-irq;
desc = irq_desc[irq];
@@ -1355,31 +1356,38 @@ int pci_restore_msi_state(struct pci_dev
pdev-seg, pdev-bus, PCI_SLOT(pdev-devfn),
PCI_FUNC(pdev-devfn), i);
spin_unlock_irqrestore(desc-lock, flags);
+if ( type == PCI_CAP_ID_MSIX )
+pci_conf_write16(pdev-seg, pdev-bus, slot, func,
+ msix_control_reg(pos),
+ control ~PCI_MSIX_FLAGS_ENABLE);
return -EINVAL;
}
+ASSERT(!type || type == entry-msi_attrib.type);
+pos = entry-msi_attrib.pos;
if ( entry-msi_attrib.type == PCI_CAP_ID_MSI )
{
msi_set_enable(pdev, 0);
nr = entry-msi.nvec;
}
-else if ( entry-msi_attrib.type == PCI_CAP_ID_MSIX )
+else if ( !type entry-msi_attrib.type == PCI_CAP_ID_MSIX )
{
control = pci_conf_read16(pdev-seg, pdev-bus, slot, func,
- msix_control_reg(entry-msi_attrib.pos));
+ msix_control_reg(pos));
pci_conf_write16(pdev-seg, pdev-bus, slot, func,
- msix_control_reg(entry-msi_attrib.pos),
+ msix_control_reg(pos),
control | (PCI_MSIX_FLAGS_ENABLE |
PCI_MSIX_FLAGS_MASKALL));
if ( unlikely(!memory_decoded(pdev)) )
{
spin_unlock_irqrestore(desc-lock, flags);
pci_conf_write16(pdev-seg, pdev-bus, slot, func,
- msix_control_reg(entry-msi_attrib.pos),
+ msix_control_reg(pos),
control ~PCI_MSIX_FLAGS_ENABLE);
return -ENXIO;
}
}
+type = entry-msi_attrib.type;
msg = entry-msg;
write_msi_msg(entry, msg);
@@ -1403,9 +1411,9 @@ int pci_restore_msi_state(struct pci_dev
spin_unlock_irqrestore(desc-lock, flags);
-if ( entry-msi_attrib.type == PCI_CAP_ID_MSI )
+if ( type == PCI_CAP_ID_MSI )
{
-unsigned int cpos = msi_control_reg(entry-msi_attrib.pos);
+unsigned int cpos = msi_control_reg(pos);
control = pci_conf_read16(pdev-seg, pdev-bus, slot, func, cpos)
~PCI_MSI_FLAGS_QSIZE;
@@ -1415,12 +1423,13 @@ int pci_restore_msi_state(struct pci_dev
msi_set_enable(pdev, 1);
}
-else if ( entry-msi_attrib.type == PCI_CAP_ID_MSIX )
-pci_conf_write16(pdev-seg, pdev-bus, slot, func,
- msix_control_reg(entry-msi_attrib.pos),
- control | PCI_MSIX_FLAGS_ENABLE);
}
+if ( type == PCI_CAP_ID_MSIX )
+pci_conf_write16(pdev-seg, pdev-bus, slot, func,
+ msix_control_reg(pos),
+ control | PCI_MSIX_FLAGS_ENABLE);
+
return 0;
}
x86/MSI-X: reduce fiddling with control register during restore
Rather than disabling and enabling MSI-X once per vector, do it just
once per device.
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -1319,6 +1319,9 @@ int pci_restore_msi_state(struct pci_dev
struct msi_desc *entry, *tmp;
struct irq_desc *desc;
struct msi_msg msg;
+u8 slot = PCI_SLOT(pdev-devfn), func = PCI_FUNC(pdev-devfn);
+unsigned int type = 0, pos = 0;
+u16 control = 0;
ASSERT(spin_is_locked(pcidevs_lock));
@@ -1337,8 +1340,6 @@ int pci_restore_msi_state(struct pci_dev
list_for_each_entry_safe( entry, tmp, pdev-msi_list, list )
{
unsigned int i = 0, nr = 1;
-u16 control = 0;
-u8 slot = PCI_SLOT(pdev-devfn), func = PCI_FUNC(pdev-devfn);
irq = entry-irq;
desc = irq_desc[irq];
@@ -1355,31 +1356,38 @@ int pci_restore_msi_state(struct pci_dev
pdev-seg,
Re: [Xen-devel] [PATCH v8 3/7] Qemu-Xen-vTPM: Xen frontend driver infrastructure
On Sun, 17 May 2015, Quan Xu wrote:
This patch adds infrastructure for xen front drivers living in qemu,
so drivers don't need to implement common stuff on their own. It's
mostly xenbus management stuff: some functions to access XenStore,
setting up XenStore watches, callbacks on device discovery and state
changes, and handle event channel between the virtual machines.
Call xen_fe_register() function to register XenDevOps, and make sure,
XenDevOps's flags is DEVOPS_FLAG_FE, which is flag bit to point out
the XenDevOps is Xen frontend.
Signed-off-by: Quan Xu quan...@intel.com
---
hw/xen/Makefile.objs | 2 +-
hw/xen/xen_frontend.c| 345
+++
include/hw/xen/xen_backend.h | 8 +
3 files changed, 354 insertions(+), 1 deletion(-)
create mode 100644 hw/xen/xen_frontend.c
diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index 9ac9f7c..95eb9d0 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
# xen backend driver support
-common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o xen_pvdev.o
+common-obj-$(CONFIG_XEN_BACKEND) += xen_backend.o xen_devconfig.o
xen_frontend.o xen_pvdev.o
obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o
xen_pt_msi.o
diff --git a/hw/xen/xen_frontend.c b/hw/xen/xen_frontend.c
new file mode 100644
index 000..55af45a
--- /dev/null
+++ b/hw/xen/xen_frontend.c
@@ -0,0 +1,345 @@
+/*
+ * Xen frontend driver infrastructure
+ *
+ * Copyright (c) 2015 Intel Corporation
+ * Authors:
+ *Quan Xu quan...@intel.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/
+ */
+
+#include stdio.h
+#include stdlib.h
+#include stdarg.h
+#include string.h
+#include unistd.h
+#include fcntl.h
+#include inttypes.h
+#include sys/types.h
+#include sys/stat.h
+#include sys/mman.h
+#include sys/signal.h
+
+#include hw/hw.h
+#include sysemu/char.h
+#include qemu/log.h
+#include hw/xen/xen_backend.h
+#include xen/grant_table.h
+
+int xenstore_dev;
+
+/* private */
+static int debug;
+
+static void xen_fe_evtchn_event(void *opaque)
+{
+struct XenDevice *xendev = opaque;
+evtchn_port_t port;
+
+port = xc_evtchn_pending(xendev-evtchndev);
+if (port != xendev-local_port) {
+return;
+}
+xc_evtchn_unmask(xendev-evtchndev, port);
+
+if (xendev-ops-event) {
+xendev-ops-event(xendev);
+}
+}
This looks very similar to xen_be_evtchn_event. I think we should share
the same function between frontends and backends.
+/* - */
+
+int xen_fe_alloc_unbound(struct XenDevice *xendev, int dom, int remote_dom)
+{
+xendev-local_port = xc_evtchn_bind_unbound_port(xendev-evtchndev,
+ remote_dom);
+if (xendev-local_port == -1) {
+xen_fe_printf(xendev, 0, xc_evtchn_alloc_unbound failed\n);
+return -1;
+}
+xen_fe_printf(xendev, 2, bind evtchn port %d\n, xendev-local_port);
+qemu_set_fd_handler(xc_evtchn_fd(xendev-evtchndev),
+xen_fe_evtchn_event, NULL, xendev);
+return 0;
+}
+
+/*
+ * Make sure, initialize the 'xendev-fe' in xendev-ops-init() or
+ * xendev-ops-initialize()
+ */
+int xenbus_switch_state(struct XenDevice *xendev, enum xenbus_state xbus)
+{
+xs_transaction_t xbt = XBT_NULL;
+
+if (xendev-fe_state == xbus) {
+return 0;
+}
+
+xendev-fe_state = xbus;
+if (xendev-fe == NULL) {
+xen_fe_printf(NULL, 0, xendev-fe is NULL\n);
+return -1;
+}
+
+retry_transaction:
+xbt = xs_transaction_start(xenstore);
+if (xbt == XBT_NULL) {
+goto abort_transaction;
+}
+
+if (xenstore_write_int(xendev-fe, state, xbus)) {
+goto abort_transaction;
+}
+
+if (!xs_transaction_end(xenstore, xbt, 0)) {
+if (errno == EAGAIN) {
+goto retry_transaction;
+}
+}
+
+return 0;
+
+abort_transaction:
+xs_transaction_end(xenstore, xbt, 1);
+return -1;
+}
Given that this is xen_frontend.c, shouldn't this function be called
xenbus_fe_switch_state? Also why is
Re: [Xen-devel] PCI Passthrough ARM Design : Draft1
On Wed, Jun 17, 2015 at 03:35:02PM +0100, Stefano Stabellini wrote:
On Wed, 17 Jun 2015, Ian Campbell wrote:
On Wed, 2015-06-17 at 07:14 -0700, Manish Jaggi wrote:
On Wednesday 17 June 2015 06:43 AM, Ian Campbell wrote:
On Wed, 2015-06-17 at 13:58 +0100, Stefano Stabellini wrote:
Yes, pciback is already capable of doing that, see
drivers/xen/xen-pciback/conf_space.c
I am not sure if the pci-back driver can query the guest memory map.
Is there an existing hypercall ?
No, that is missing. I think it would be OK for the virtual BAR to be
initialized to the same value as the physical BAR. But I would let the
guest change the virtual BAR address and map the MMIO region wherever
it
wants in the guest physical address space with
XENMEM_add_to_physmap_range.
I disagree, given that we've apparently survived for years with x86 PV
guests not being able to right to the BARs I think it would be far
simpler to extend this to ARM and x86 PVH too than to allow guests to
start writing BARs which has various complex questions around it.
All that's needed is for the toolstack to set everything up and write
some new xenstore nodes in the per-device directory with the BAR
address/size.
Also most guests apparently don't reassign the PCI bus by default, so
using a 1:1 by default and allowing it to be changed would require
modifying the guests to reasssign. Easy on Linux, but I don't know about
others and I imagine some OSes (especially simpler/embedded ones) are
assuming the firmware sets up something sane by default.
Does the Flow below captures all points
a) When assigning a device to domU, toolstack creates a node in per
device directory with virtual BAR address/size
Option1:
b) toolstack using some hypercall ask xen to create p2m mapping {
virtual BAR : physical BAR } for domU
c) domU will not anytime update the BARs, if it does then it is a fault,
till we decide how to handle it
As Julien has noted pciback already deals with this correctly, because
sizing a BAR involves a write, it implementes a scheme which allows
either the hardcoded virtual BAR to be written or all 1s (needed for
size detection).
d) when domU queries BAR address from pci-back the virtual BAR address
is provided.
Option2:
b) domU will not anytime update the BARs, if it does then it is a fault,
till we decide how to handle it
c) when domU queries BAR address from pci-back the virtual BAR address
is provided.
d) domU sends a hypercall to map virtual BARs,
e) xen pci code reads the BAR and maps { virtual BAR : physical BAR }
for domU
Which option is better I think Ian is for (2) and Stefano may be (1)
In fact I'm now (after Julien pointed out the current behaviour of
pciback) in favour of (1), although I'm not sure if Stefano is too.
(I was never in favour of (2), FWIW, I previously was in favour of (3)
which is like (2) except pciback makes the hypervcall to map the virtual
bars to the guest, I'd still favour that over (2) but (1) is now my
preference)
OK, let's go with (1).
Right, and as the maintainer of pciback that means I don't have to do
anything right :-)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [DESIGN] Feature Levelling improvements
Thank you for posting this! Some comments below. Design == `struct sysctl_physinfo.levelling_caps` --- Xen shall gain a new physinfo field which reports the degree to which it can influence `CPUID` executed by a PV guest. This is a bitmap containing: * `faulting` * CPUID Faulting is available, and full control can be exercised. * `mask_ecx` * Leaf 0x0001.ECX * `mask_edx` * Leaf 0x0001.EDX * `mask_extd_ecx` * Leaf 0x8001.ECX * `mask_extd_edx` * Leaf 0x8001.EDX * `mask_xsave_eax` * Leaf 0x000D[ECX=1].EAX * `mask_therm_ecx` * Leaf 0x0006.ECX * `mask_l7s0_eax` * Leaf 0x0007[ECX=0].EAX * `mask_l7s0_ebx` Those 'l' look like '1' in the PDF. Can it be called something else? * Leaf 0x0007[ECX=0].EBX At the time of writing, these are all the masking MSRs known by Xen. The bitmap shall be extended as new MSRs become available. New 'featureset' API for use by the toolstack - A featureset is a defined as a collection of words covering the cpuid leaves which report features to the caller. It is variable length, and expected to grow over time as processors gain more features, or Xen starts supporting exposing more features to guests. At the time of writing, the leaves containing feature bits are: * 0x0001.ECX * 0x0001.EDX * 0x8001.ECX * 0x8001.EDX * 0x000D[ECX=1].EAX * 0x0007[ECX=0].EBX * 0x0006.EAX * 0x0006.ECX * 0x000A.EAX * 0x000A.EBX * 0x000F[ECX=0].EDX * 0x000F[ECX=1].EDX XEN_SYSCTL_get_featureset - Xen shall on boot create a featureset for itself, and the maximum available features for each type of guest, based on hardware features, command line options etc. A toolstack shall be able to query all of these. maximum available features? As in two sets of features - one for PV and another for HVM. The PV being a subset of HVM (since it is more constrained)? Command line options being the same old ones (the cpuid_mask..?) and then more? Or just rewrite this to be: cpuid=mask_therm_ecx=[blahbla],mask_xsave_eax=[blahbal] ? Cpuid feature-verification library -- There shall be a new library (shared between Xen and libxc in the same way as libelf etc.) which can verify the a featureset. In particular, it will s/ a // confirm that no features are enabled without their dependent features. And presumarily can compare these features and do a and-subset (or an or-subset) ? XEN_DOMCTL_set_cpuid This is an existing hypercall. Currently it just stashes the policy from userspace. It shall be extended to provide verification of the policy, and reject attempts to advertise features which Xen is incapable of providing (via hardware or emulation support). Where would be the code to trim the 'maximum available features' in the subsets (like PV) with some cpuid=X flags from user-space? VCPU context switch --- Xen shall be updated to lazily context switch all available masking MSRs. It is noted that this shall incur a performance overhead if restricted featuresets are assigned to PV guests, and _CPUID Faulting_ is not available. It shall be the responsibility of the host administrator to avoid creating such a scenario, if the performance overhead is a concern. .. and perhaps add warnings in the toolstack to tell the admin? Future work === The above is a minimum quantity of work to support feature levelling, but further problems exist. They are acknowledged as being issues, but are not in scope for fixing as part of feature levelling. * Xen has no notion of per-cpu and per-package data in the cpuid policy. In particular, this causes issues for VMs attempting to detect topology, which find inconsistent/incorrect cache information. * In the case that `domain_cpuid()` can't locate a leaf in the topology, it will fall back to issuing a plain `CPUID` instruction. This breaks VM encapsulation, as a VM which has migrated can observe differences which should be hidden. * There is currently a positioning issue with the domains cpuid policy. Verifying the register state requires the policy, but the policy is behind the register state in the migration stream. The domains cpuid policy should become an item in Xen's migration state for a VM. And potentially code in libxl to allow subset manipulation to allow leveling across different platforms. As in the common features would be exposed while all the other ones are masked? And I suppose some format to stash this so it can be ingested by the libxl tools? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 58826: regressions - FAIL
flight 58826 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58826/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 58776 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 58776 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 58776 test-amd64-i386-xl-qemuu-winxpsp3 11 guest-saverestorefail REGR. vs. 58776 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 58776 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass version targeted for testing: xen 0b1b9d165349dfc387fe7b3e466aaa960689debb baseline version: xen a24672752214b07661db594921ba70c0ee3066c5 People who touched revisions under test: Jan Beulich jbeul...@suse.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-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 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 fail test-amd64-amd64-xl-pvh-intelfail test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt
[Xen-devel] [linux-arm-xen test] 58830: tolerable all pass - PUSHED
flight 58830 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58830/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
version targeted for testing:
linux9f51b5de8c3fdd01a9d692da5633449cc6936688
baseline version:
linuxec18c9fc039971041d854e0d58551f1f1a32ff8f
800 people touched revisions under test,
not listing them all
jobs:
build-armhf-xsm pass
build-armhf pass
build-armhf-libvirt pass
build-armhf-pvopspass
test-armhf-armhf-xl pass
test-armhf-armhf-libvirt-xsm pass
test-armhf-armhf-xl-xsm pass
test-armhf-armhf-xl-arndale pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-armhf-armhf-libvirt pass
test-armhf-armhf-xl-multivcpupass
test-armhf-armhf-xl-sedf-pin pass
test-armhf-armhf-xl-sedf pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=linux-arm-xen
+ revision=9f51b5de8c3fdd01a9d692da5633449cc6936688
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push linux-arm-xen
9f51b5de8c3fdd01a9d692da5633449cc6936688
+ branch=linux-arm-xen
+ revision=9f51b5de8c3fdd01a9d692da5633449cc6936688
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-arm-xen
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{OsstestUpstream} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local
[Xen-devel] Bug in devicetree_for_each_node() in xen/arch/arm/bootfdt.c ?
I've been trying to figure out why Xen only reports 2GB on my ARM platform that
actually has 3GB, and I think I've found a bug, but I'm not familiar enough
with the Xen code to fix it.
The relevant parts of my dts are:
/dts-v1/;
/ {
model = Broadcom STB (7445d0);
compatible = brcm,bcm7445d0, brcm,brcmstb;
#address-cells = 0x2;
#size-cells = 0x2;
interrupt-parent = 0x1;
memory {
#address-cells = 0x1;
#size-cells = 0x1;
device_type = memory;
reg = 0x0 0x0 0x0 0x4000 0x0 0x4000 0x0 0x4000;
region@1000 {
contiguous-region;
reg = 0x1000 0x1f80;
linux,phandle = 0x2;
phandle = 0x2;
};
region@3000 {
contiguous-region;
reg = 0x3000 0x1000;
linux,phandle = 0x3;
phandle = 0x3;
};
region@4000 {
contiguous-region;
reg = 0x4000 0x4000;
linux,phandle = 0x4;
phandle = 0x4;
};
region@8000 {
contiguous-region;
reg = 0x8000 0x4000;
linux,phandle = 0x5;
phandle = 0x5;
};
};
As you can see, it specifies 0 + 1GB + 1GB + 1GB. When I run xl info in Dom0,
though, it reports Total 2048.
Digging into the code, I found that in bootinfo.mem.nr_banks is 2 rather than
the expected 3 (or 4?). That turned out to be because in process_memory_node(),
address_cells and size_cells were both 2 and so the prop_len of 32 was
resulting in banks being set to 2.
Looking at device_tree_for_each_node(), it looks like something is wrong
because it contains this loop:
for ( node = 0, depth = 0;
node =0 depth = 0;
node = fdt_next_node(fdt, node, depth) )
{
[...]
ret = func(fdt, node, name, depth,
address_cells[depth-1], size_cells[depth-1], data);
which looks like it will read before the start of the array for the first node,
when depth=0. My first instinct was to remove those two -1s, but the
resulting code didn't run, so I figured I'd try to enlist some help :) Of
course it's possible that my problem is unrelated to this, but reading before
the start of the array definitely seems like a bug that should be fixed
(although in practice those values are never used for node 0). Looking through
the history, it seems to have been like that since the function was first
introduced
(http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=9cf4a9a467171c8a2c3d97c2bfadb1bc8b15a3d6).
I'm happy to test out any patches.
Chris
(Not subscribed to the list)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.2-testing test] 58817: FAIL
flight 58817 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58817/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 58411 Tests which are failing intermittently (not blocking): test-i386-i386-libvirt3 host-install(3) broken in 58584 pass in 58817 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 58584 pass in 58817 test-amd64-i386-qemuu-freebsd10-amd64 3 host-install(3) broken in 58584 pass in 58817 test-amd64-i386-pair 4 host-install/dst_host(4) broken in 58584 pass in 58817 test-amd64-i386-xl-win7-amd64 3 host-install(3) broken in 58584 pass in 58817 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 58584 pass in 58817 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 58584 pass in 58817 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail in 58584 pass in 58817 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 58584 pass in 58817 test-amd64-amd64-xl-win7-amd64 16 guest-stopfail pass in 58584 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 58411 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58411 test-amd64-i386-xl-win7-amd64 16 guest-stop fail like 58411 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1)blocked in 58584 n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 5 rumpuserxen-buildfail never pass build-i386-rumpuserxen5 rumpuserxen-buildfail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-i386-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 20 leak-check/check fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 97134c441d6d81ba0d7cdcfdc4d8315115b99dce baseline version: xen 21a8344ca38a2797a13b4bf57031b6f49ae12ccb People who touched revisions under test: Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Stefano Stabellini stefano.stabell...@eu.citrix.com jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xlpass 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-qemuu-freebsd10-amd64pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64
Re: [Xen-devel] [PATCH v2][RFC] libxl: Add AHCI support for upstream qemu
On Fri, Jun 19, 2015 at 12:18 PM, Fabio Fantoni fabio.fant...@m2r.biz wrote: Il 11/06/2015 12:28, Fabio Fantoni ha scritto: Il 11/06/2015 12:06, Zir Blazer ha scritto: Since I'm not a developer I may be peeking my nose a bit too far, but based on what I know, I think that enabling AHCI by default would be a compatibility suicide. I'm not sure about Linux and Windows Vista/7/8+, but at least for Windows XP based VMs, it would be a terrible idea. Also use windows xp without security updates (support ended one year ago) is a suicide. I already did this patch considering windows domU problems (I'm using mainly them for now), ahci used with option (ahci=0|1) instead replace and default is disabled. I tried it with different windows (excluding xp...abandoned) I also tried with new winpv drivers (http://www.xenproject.org/developers/teams/windows-pv-drivers.html) With this patch applied ahci will be not used and will be used only setting ahci=1, is it a good idea or is there problem also in this case? I did many other tests in different linux hvm domUs (fedora and ubuntu) and windows (7, 8.1, 10) without found problems. Is this patch acceptable for xen 4.6? Well maybe I missed something, but: 1. The most recent version of this patch (v2) has RFC in the title; this is a specific request *not* to apply this patch. 2. The most recent version of this patch has the following in the changelog: NOTES: This patch is a only a fast draft for testing. That also sounds like you're asking people not to apply the patch. 3. After reading the changelog, many people were still unclear what the purpose of the patch is. You answered their questions by e-mail, but that information needs to be in the changelog. So you need to resend the patch 1) with RFC removed from the title; and 2) with a proper changelog that doesn't say just a draft, but that 3) explains what the purpose of the change for people reading through the revision history. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] configure: check for argp
On Mon, Jun 22, 2015 at 11:12:27AM +0100, George Dunlap wrote: On 06/19/2015 09:58 AM, Roger Pau Monne wrote: argp is only present in the GNU C library, so add a specific check for it in configure. Also check if -largp is needed for linking against it. Please run autoconf after applying. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: George Dunlap george.dun...@eu.citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Cc: Olaf Hering o...@aepfle.de --- config/Tools.mk.in | 1 + tools/configure.ac | 4 tools/xentrace/Makefile | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/config/Tools.mk.in b/config/Tools.mk.in index aef9ed6..9bd5f6c 100644 --- a/config/Tools.mk.in +++ b/config/Tools.mk.in @@ -78,5 +78,6 @@ CONFIG_GCRYPT := @libgcrypt@ EXTFS_LIBS := @EXTFS_LIBS@ CURSES_LIBS := @CURSES_LIBS@ TINFO_LIBS := @TINFO_LIBS@ +ARGP_LDFLAGS:= @argp_ldflags@ FILE_OFFSET_BITS:= @FILE_OFFSET_BITS@ diff --git a/tools/configure.ac b/tools/configure.ac index 1a06ddf..5eb4799 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -356,6 +356,10 @@ AC_CHECK_LIB([yajl], [yajl_alloc], [], AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])]) AC_CHECK_LIB([iconv], [libiconv_open], [libiconv=y], [libiconv=n]) AC_SUBST(libiconv) +AC_CHECK_HEADER([argp.h], [ +AC_CHECK_LIB([argp], [argp_usage], [argp_ldflags=-largp]) +], [AC_MSG_ERROR([Could not find argp])]) +AC_SUBST(argp_ldflags) Sorry if my config-fu isn't very good: Is this basically requiring the user to have argp available at configure time? Does this make it more difficult to build on BSDs? Or is it just a matter of adding one more library to the already long list of dependencies? This is just to make that dependency explicit. This is a step towards the right direction. It's not going to make it easier or harder to build on BSDs. Wei. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] configure: check for argp
On 06/22/2015 11:45 AM, Wei Liu wrote: On Mon, Jun 22, 2015 at 11:12:27AM +0100, George Dunlap wrote: On 06/19/2015 09:58 AM, Roger Pau Monne wrote: argp is only present in the GNU C library, so add a specific check for it in configure. Also check if -largp is needed for linking against it. Please run autoconf after applying. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: George Dunlap george.dun...@eu.citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Cc: Olaf Hering o...@aepfle.de --- config/Tools.mk.in | 1 + tools/configure.ac | 4 tools/xentrace/Makefile | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/config/Tools.mk.in b/config/Tools.mk.in index aef9ed6..9bd5f6c 100644 --- a/config/Tools.mk.in +++ b/config/Tools.mk.in @@ -78,5 +78,6 @@ CONFIG_GCRYPT := @libgcrypt@ EXTFS_LIBS := @EXTFS_LIBS@ CURSES_LIBS := @CURSES_LIBS@ TINFO_LIBS := @TINFO_LIBS@ +ARGP_LDFLAGS:= @argp_ldflags@ FILE_OFFSET_BITS:= @FILE_OFFSET_BITS@ diff --git a/tools/configure.ac b/tools/configure.ac index 1a06ddf..5eb4799 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -356,6 +356,10 @@ AC_CHECK_LIB([yajl], [yajl_alloc], [], AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])]) AC_CHECK_LIB([iconv], [libiconv_open], [libiconv=y], [libiconv=n]) AC_SUBST(libiconv) +AC_CHECK_HEADER([argp.h], [ +AC_CHECK_LIB([argp], [argp_usage], [argp_ldflags=-largp]) +], [AC_MSG_ERROR([Could not find argp])]) +AC_SUBST(argp_ldflags) Sorry if my config-fu isn't very good: Is this basically requiring the user to have argp available at configure time? Does this make it more difficult to build on BSDs? Or is it just a matter of adding one more library to the already long list of dependencies? This is just to make that dependency explicit. This is a step towards the right direction. It's not going to make it easier or harder to build on BSDs. Well the reason I was asking is that if it would be a big hassle for someone building on BSDs to install the argp library, then a better option might to just not build xenalyze. On the other hand, if it's no more difficult than installing libyajl (or any of the other dozen dependencies), then adding a dependency is fine. And naturally in that case making the dependency explicit is the right thing to do. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] configure: check for argp
On 06/22/2015 12:10 PM, Wei Liu wrote: On Mon, Jun 22, 2015 at 11:55:44AM +0100, George Dunlap wrote: On 06/22/2015 11:45 AM, Wei Liu wrote: On Mon, Jun 22, 2015 at 11:12:27AM +0100, George Dunlap wrote: On 06/19/2015 09:58 AM, Roger Pau Monne wrote: argp is only present in the GNU C library, so add a specific check for it in configure. Also check if -largp is needed for linking against it. Please run autoconf after applying. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: George Dunlap george.dun...@eu.citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Cc: Olaf Hering o...@aepfle.de --- config/Tools.mk.in | 1 + tools/configure.ac | 4 tools/xentrace/Makefile | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/config/Tools.mk.in b/config/Tools.mk.in index aef9ed6..9bd5f6c 100644 --- a/config/Tools.mk.in +++ b/config/Tools.mk.in @@ -78,5 +78,6 @@ CONFIG_GCRYPT := @libgcrypt@ EXTFS_LIBS := @EXTFS_LIBS@ CURSES_LIBS := @CURSES_LIBS@ TINFO_LIBS := @TINFO_LIBS@ +ARGP_LDFLAGS:= @argp_ldflags@ FILE_OFFSET_BITS:= @FILE_OFFSET_BITS@ diff --git a/tools/configure.ac b/tools/configure.ac index 1a06ddf..5eb4799 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -356,6 +356,10 @@ AC_CHECK_LIB([yajl], [yajl_alloc], [], AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])]) AC_CHECK_LIB([iconv], [libiconv_open], [libiconv=y], [libiconv=n]) AC_SUBST(libiconv) +AC_CHECK_HEADER([argp.h], [ +AC_CHECK_LIB([argp], [argp_usage], [argp_ldflags=-largp]) +], [AC_MSG_ERROR([Could not find argp])]) +AC_SUBST(argp_ldflags) Sorry if my config-fu isn't very good: Is this basically requiring the user to have argp available at configure time? Does this make it more difficult to build on BSDs? Or is it just a matter of adding one more library to the already long list of dependencies? This is just to make that dependency explicit. This is a step towards the right direction. It's not going to make it easier or harder to build on BSDs. Well the reason I was asking is that if it would be a big hassle for someone building on BSDs to install the argp library, then a better option might to just not build xenalyze. On the other hand, if it's no more difficult than installing libyajl (or any of the other dozen dependencies), then adding a dependency is fine. And naturally in that case making the dependency explicit is the right thing to do. Yes, package argp exist in FreeBSD and NetBSD. In which case: Acked-by: George Dunlap george.dun...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/3] gnttab: don't silently truncate frame numbers in gnttab_set_version()
On a v2 - v1 transition frame numbers previously stored in a 64-bit
field have to fit into a 32-bit one.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2597,14 +2597,32 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARA
}
}
-/* XXX: If we're going to version 2, we could maybe shrink the
- active grant table here. */
-
-if ( op.version == 2 gt-gt_version 2 )
+switch ( gt-gt_version )
{
-res = gnttab_populate_status_frames(d, gt, nr_grant_frames(gt));
-if ( res 0)
-goto out_unlock;
+case 0:
+if ( op.version == 2 )
+{
+case 1:
+/* XXX: We could maybe shrink the active grant table here. */
+res = gnttab_populate_status_frames(d, gt, nr_grant_frames(gt));
+if ( res 0)
+goto out_unlock;
+}
+break;
+case 2:
+for ( i = 0; i GNTTAB_NR_RESERVED_ENTRIES; i++ )
+{
+if ( ((shared_entry_v2(gt, i).hdr.flags GTF_type_mask) ==
+ GTF_permit_access)
+ (shared_entry_v2(gt, i).full_page.frame 32) )
+{
+gdprintk(XENLOG_WARNING,
+ tried to change grant table version to 1 with
non-representable entries\n);
+res = -ERANGE;
+goto out_unlock;
+}
+}
+break;
}
/* Preserve the first 8 entries (toolstack reserved grants) */
gnttab: don't silently truncate frame numbers in gnttab_set_version()
On a v2 - v1 transition frame numbers previously stored in a 64-bit
field have to fit into a 32-bit one.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -2597,14 +2597,32 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARA
}
}
-/* XXX: If we're going to version 2, we could maybe shrink the
- active grant table here. */
-
-if ( op.version == 2 gt-gt_version 2 )
+switch ( gt-gt_version )
{
-res = gnttab_populate_status_frames(d, gt, nr_grant_frames(gt));
-if ( res 0)
-goto out_unlock;
+case 0:
+if ( op.version == 2 )
+{
+case 1:
+/* XXX: We could maybe shrink the active grant table here. */
+res = gnttab_populate_status_frames(d, gt, nr_grant_frames(gt));
+if ( res 0)
+goto out_unlock;
+}
+break;
+case 2:
+for ( i = 0; i GNTTAB_NR_RESERVED_ENTRIES; i++ )
+{
+if ( ((shared_entry_v2(gt, i).hdr.flags GTF_type_mask) ==
+ GTF_permit_access)
+ (shared_entry_v2(gt, i).full_page.frame 32) )
+{
+gdprintk(XENLOG_WARNING,
+ tried to change grant table version to 1 with
non-representable entries\n);
+res = -ERANGE;
+goto out_unlock;
+}
+}
+break;
}
/* Preserve the first 8 entries (toolstack reserved grants) */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] gnttab: don't silently truncate frame numbers in gnttab_set_version()
On 22/06/15 12:45, Jan Beulich wrote: On a v2 - v1 transition frame numbers previously stored in a 64-bit field have to fit into a 32-bit one. Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH v3 09/18] xen/arm: ITS: Add virtual ITS commands support
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add Virtual ITS command processing support to Virtual ITS driver
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c |7 +
xen/arch/arm/vgic-v3-its.c | 393
2 files changed, 400 insertions(+)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 535fc53..2a4fa97 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -89,6 +89,7 @@ struct its_node {
#define ITS_ITT_ALIGNSZ_256
+static u32 id_bits;
static LIST_HEAD(its_nodes);
static DEFINE_SPINLOCK(its_lock);
static struct rdist_prop *gic_rdists;
@@ -146,6 +147,11 @@ void dump_cmd(its_cmd_block *cmd)
}
#endif
+u32 its_get_nr_events(void)
+{
+return (1 id_bits);
+}
+
/* RB-tree helpers for its_device */
struct its_device * find_its_device(struct rb_root *root, u32 devid)
{
@@ -1044,6 +1050,7 @@ static int its_probe(struct dt_device_node *node)
its-phys_size = its_size;
typer = readl_relaxed(its_base + GITS_TYPER);
its-ite_size = ((typer 4) 0xf) + 1;
+id_bits = GITS_TYPER_IDBITS(typer);
its-cmd_base = xzalloc_bytes(ITS_CMD_QUEUE_SZ);
if ( !its-cmd_base )
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index ea52a87..0671434 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -256,6 +256,399 @@ int remove_vits_device(struct rb_root *root, struct
vits_device *dev)
return 0;
}
+static int vgic_its_process_sync(struct vcpu *v, struct vgic_its *vits,
+ its_cmd_block *virt_cmd)
+{
+/* XXX: Ignored */
+DPRINTK(vITS:d%dv%d SYNC: ta 0x%x \n,
+ v-domain-domain_id, v-vcpu_id, virt_cmd-sync.ta);
+
+return 0;
+}
+
+static int vgic_its_process_mapvi(struct vcpu *v, struct vgic_its *vits,
+ its_cmd_block *virt_cmd)
+{
+struct vitt entry;
+struct vits_device *vdev;
+uint8_t vcol_id, cmd;
+uint32_t vid, dev_id, event;
+
+vcol_id = virt_cmd-mapvi.col;
+vid = virt_cmd-mapvi.phy_id;
+dev_id = its_decode_devid(v-domain, virt_cmd);
+cmd = virt_cmd-mapvi.cmd;
+
+DPRINTK(vITS:d%dv%d MAPVI: dev_id 0x%x vcol_id %d vid %d \n,
+ v-domain-domain_id, v-vcpu_id, dev_id, vcol_id, vid);
+
+if ( vcol_id (v-domain-max_vcpus + 1) || vid its_get_nr_events() )
+return -EINVAL;
+
+/* XXX: Enable validation later */
+vdev = find_vits_device(v-domain-arch.vits-dev_root, dev_id);
+if ( !vdev !vdev-its_dev )
+return -EINVAL;
+
+entry.valid = true;
+entry.vcollection = vcol_id;
+entry.vlpi = vid;
+
+if ( cmd == GITS_CMD_MAPI )
+vits_set_vitt_entry(v-domain, dev_id, vid, entry);
+else
+{
+event = virt_cmd-mapvi.event;
+if ( event its_get_nr_events() )
+return -EINVAL;
+
+vits_set_vitt_entry(v-domain, dev_id, event, entry);
+}
+
+return 0;
+}
+
+static int vgic_its_process_movi(struct vcpu *v, struct vgic_its *vits,
+ its_cmd_block *virt_cmd)
+{
+struct vitt entry;
+struct vits_device *vdev;
+uint32_t dev_id, event;
+uint8_t vcol_id;
+
+dev_id = its_decode_devid(v-domain, virt_cmd);
+vcol_id = virt_cmd-movi.col;
+event = virt_cmd-movi.event;
+
+DPRINTK(vITS:d%dv%d MOVI: dev_id 0x%x vcol_id %d event %d\n,
+v-domain-domain_id, v-vcpu_id, dev_id, vcol_id, event);
+if ( vcol_id (v-domain-max_vcpus + 1) || event its_get_nr_events() )
+return -EINVAL;
+
+/* Enable validation later when device assignment is done */
+vdev = find_vits_device(v-domain-arch.vits-dev_root, dev_id);
+if ( !vdev !vdev-its_dev )
+return -EINVAL;
+
+if ( vits_get_vitt_entry(v-domain, dev_id, event, entry) )
+return -EINVAL;
+entry.vcollection = vcol_id;
+if ( vits_set_vitt_entry(v-domain, dev_id, event, entry) )
+return -EINVAL;
+
+return 0;
+}
+
+static int vgic_its_process_discard(struct vcpu *v, struct vgic_its *vits,
+its_cmd_block *virt_cmd)
+{
+struct vits_device *vdev;
+struct vitt entry;
+uint32_t event, dev_id;
+
+event = virt_cmd-discard.event;
+dev_id = its_decode_devid(v-domain, virt_cmd);
+
+DPRINTK(vITS:d%dv%d DISCARD: dev_id 0x%x id %d\n,
+v-domain-domain_id, v-vcpu_id, dev_id, event);
+if ( event its_get_nr_events() )
+return -EINVAL;
+
+/* Validated later */
+vdev = find_vits_device(v-domain-arch.vits-dev_root, dev_id);
+if ( !vdev !vdev-its_dev )
+return -EINVAL;
+
+if ( vits_get_vitt_entry(v-domain, dev_id, event, entry) )
+return -EINVAL;
+entry.valid = false;
+if ( vits_set_vitt_entry(v-domain, dev_id, event, entry) )
+return -EINVAL;
+
+return 0;
+}
+
+static int vgic_its_process_inv(struct vcpu
[Xen-devel] [RFC PATCH v3 05/18] xen/arm: ITS: Port ITS driver to xen
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Only required changes from Linux ITS driver is ported
and compiled
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v3:
- Only required changes from Linux ITS driver is ported
- Xen coding style is followed.
---
xen/arch/arm/Makefile |1 +
xen/arch/arm/gic-v3-its.c | 1067 +
xen/include/asm-arm/gic-its.h | 214
xen/include/asm-arm/gic.h |1 +
xen/include/asm-arm/gic_v3_defs.h | 127 -
5 files changed, 1408 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 935999e..1821ed2 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -32,6 +32,7 @@ obj-y += shutdown.o
obj-y += traps.o
obj-y += vgic.o vgic-v2.o
obj-$(CONFIG_ARM_64) += vgic-v3.o
+obj-$(CONFIG_ARM_64) += gic-v3-its.o
obj-y += vtimer.o
obj-y += vuart.o
obj-y += hvm.o
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
new file mode 100644
index 000..b1a97c1
--- /dev/null
+++ b/xen/arch/arm/gic-v3-its.c
@@ -0,0 +1,1067 @@
+/*
+ * Copyright (C) 2013, 2014 ARM Limited, All Rights Reserved.
+ * Author: Marc Zyngier marc.zyng...@arm.com
+ *
+ * Xen changes:
+ * Vijaya Kumar K vijaya.ku...@caviumnetworks.com
+ * Copyright (C) 2014, 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 version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include xen/config.h
+#include xen/bitops.h
+#include xen/init.h
+#include xen/mm.h
+#include xen/irq.h
+#include xen/sched.h
+#include xen/errno.h
+#include xen/delay.h
+#include xen/list.h
+#include xen/sizes.h
+#include xen/vmap.h
+#include asm/p2m.h
+#include asm/domain.h
+#include asm/io.h
+#include asm/device.h
+#include asm/gic.h
+#include asm/gic_v3_defs.h
+#include asm/gic-its.h
+#include xen/log2.h
+
+#define its_print(lvl, fmt, ...) \
+printk(GIC-ITS: fmt, ## __VA_ARGS__)
+
+#define its_err(fmt, ...) its_print(XENLOG_ERR, fmt, ## __VA_ARGS__)
+
+#define its_err_ratelimit(fmt, ...) \
+its_print(XENLOG_ERR_RATE_LIMIT, fmt, ## __VA_ARGS__)
+
+#define its_dbg(fmt, ...) \
+its_print(XENLOG_DEBUG, fmt, ## __VA_ARGS__)
+
+#define its_info(fmt, ...)\
+its_print(XENLOG_INFO, fmt, ## __VA_ARGS__)
+
+#define its_warn(fmt, ...)\
+its_print(XENLOG_WARNING, fmt, ## __VA_ARGS__)
+
+//#define DEBUG_GIC_ITS
+
+#ifdef DEBUG_GIC_ITS
+# define DPRINTK(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
+#else
+# define DPRINTK(fmt, args...) do {} while ( 0 )
+#endif
+
+#define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1 0)
+#define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 0)
+
+/*
+ * The ITS structure - contains most of the infrastructure, with the
+ * msi_controller, the command queue, the collections, and the list of
+ * devices writing to it.
+ */
+struct its_node {
+spinlock_t lock;
+struct list_headentry;
+void __iomem *base;
+unsigned long phys_base;
+unsigned long phys_size;
+its_cmd_block *cmd_base;
+its_cmd_block *cmd_write;
+void*tables[GITS_BASER_NR_REGS];
+struct its_collection *collections;
+u64 flags;
+u32 ite_size;
+struct dt_device_node *dt_node;
+};
+
+#define ITS_ITT_ALIGNSZ_256
+
+static LIST_HEAD(its_nodes);
+static DEFINE_SPINLOCK(its_lock);
+static struct rdist_prop *gic_rdists;
+
+#define gic_data_rdist()(per_cpu(rdist, smp_processor_id()))
+#define gic_data_rdist_rd_base()(per_cpu(rdist, smp_processor_id()).rbase)
+
+/*
+ * ITS command descriptors - parameters to be encoded in a command
+ * block.
+ */
+struct its_cmd_desc {
+union {
+struct {
+struct its_collection *col;
+u32 event_id;
+u32 dev_id;
+} its_inv_cmd;
+
+struct {
+struct its_device *dev;
+int valid;
+} its_mapd_cmd;
+
+struct {
+struct its_collection *col;
+int valid;
+} its_mapc_cmd;
+
+struct {
+struct its_device *dev;
+struct its_collection *col;
+u32 phys_id;
+u32 event_id;
+}
[Xen-devel] [RFC PATCH v3 14/18] xen/arm: ITS: Initialize physical ITS
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com Initialize physical ITS driver from GIC v3 driver if LPIs are supported by hardware Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com --- xen/arch/arm/gic-v3.c |7 +++ xen/include/asm-arm/gic-its.h |2 ++ 2 files changed, 9 insertions(+) diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index 793f2f0..18971ed 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -700,6 +700,10 @@ static int __cpuinit gicv3_cpu_init(void) if ( gicv3_enable_redist() ) return -ENODEV; +/* Give LPIs a spin */ +if ( gicv3_info.lpi_supported ) +its_cpu_init(); + /* Set priority on PPI and SGI interrupts */ priority = (GIC_PRI_IPI 24 | GIC_PRI_IPI 16 | GIC_PRI_IPI 8 | GIC_PRI_IPI); @@ -1327,6 +1331,9 @@ static int __init gicv3_init(void) else gicv3_info.lpi_supported = 0; +if ( gicv3_info.lpi_supported ) +its_init(gicv3.rdist_data); + gicv3_dist_init(); res = gicv3_cpu_init(); gicv3_hyp_init(); diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h index f34a207..c674b3f 100644 --- a/xen/include/asm-arm/gic-its.h +++ b/xen/include/asm-arm/gic-its.h @@ -274,6 +274,8 @@ static inline uint32_t its_decode_devid(struct domain *d, its_cmd_block *cmd) return (cmd-raw_cmd[0] 32); } +int its_cpu_init(void); +int its_init(struct rdist_prop *rdist); void its_set_affinity(struct irq_desc *desc, int cpu); void lpi_set_config(struct irq_desc *desc, int enable); uint8_t vgic_its_get_priority(struct vcpu *v, uint32_t pid); -- 1.7.9.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH v3 10/18] xen/arm: ITS: Add APIs to add and assign device
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add APIs to add devices to RB-tree, assign and remove
devices to domain.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c | 246 -
xen/include/asm-arm/gic-its.h |4 +-
2 files changed, 246 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 2a4fa97..4471669 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -94,6 +94,7 @@ static LIST_HEAD(its_nodes);
static DEFINE_SPINLOCK(its_lock);
static struct rdist_prop *gic_rdists;
static struct rb_root rb_its_dev;
+static DEFINE_SPINLOCK(rb_its_dev_lock);
#define gic_data_rdist()(per_cpu(rdist, smp_processor_id()))
#define gic_data_rdist_rd_base()(per_cpu(rdist, smp_processor_id()).rbase)
@@ -152,6 +153,21 @@ u32 its_get_nr_events(void)
return (1 id_bits);
}
+static struct its_node * its_get_phys_node(u32 dev_id)
+{
+struct its_node *its;
+
+/* TODO: For now return ITS0 node.
+ * Need Query PCI helper function to get on which
+ * ITS node the device is attached
+ */
+list_for_each_entry(its, its_nodes, entry)
+{
+return its;
+}
+
+return NULL;
+}
/* RB-tree helpers for its_device */
struct its_device * find_its_device(struct rb_root *root, u32 devid)
{
@@ -459,7 +475,7 @@ void its_send_inv(struct its_device *dev, struct
its_collection *col,
its_send_single_command(dev-its, its_build_inv_cmd, desc);
}
-void its_send_mapd(struct its_device *dev, int valid)
+static void its_send_mapd(struct its_device *dev, int valid)
{
struct its_cmd_desc desc;
@@ -493,7 +509,7 @@ void its_send_mapvi(struct its_device *dev, struct
its_collection *col,
its_send_single_command(dev-its, its_build_mapvi_cmd, desc);
}
-void its_send_movi(struct its_device *dev, struct its_collection *col,
+static void its_send_movi(struct its_device *dev, struct its_collection *col,
u32 event)
{
struct its_cmd_desc desc;
@@ -596,7 +612,7 @@ int its_lpi_init(u32 id_bits)
return 0;
}
-unsigned long *its_lpi_alloc_chunks(int nirqs, int *base, int *nr_ids)
+static unsigned long *its_lpi_alloc_chunks(int nirqs, int *base, int *nr_ids)
{
unsigned long *bitmap = NULL;
int chunk_id;
@@ -636,6 +652,230 @@ out:
return bitmap;
}
+static void its_lpi_free(unsigned long *bitmap, int base, int nr_ids)
+{
+int lpi;
+
+spin_lock(lpi_lock);
+
+for ( lpi = base; lpi (base + nr_ids); lpi += IRQS_PER_CHUNK )
+{
+int chunk = its_lpi_to_chunk(lpi);
+
+BUG_ON(chunk lpi_chunks);
+if ( test_bit(chunk, lpi_bitmap) )
+clear_bit(chunk, lpi_bitmap);
+else
+its_err(Bad LPI chunk %d\n, chunk);
+}
+
+spin_unlock(lpi_lock);
+
+xfree(bitmap);
+}
+
+static int its_alloc_device_irq(struct its_device *dev, u32 *hwirq)
+{
+int idx;
+
+idx = find_first_zero_bit(dev-lpi_map, dev-nr_lpis);
+if ( idx == dev-nr_lpis )
+return -ENOSPC;
+
+*hwirq = dev-lpi_base + idx;
+set_bit(idx, dev-lpi_map);
+
+return 0;
+}
+
+static u32 its_get_plpi(struct its_device *dev, u32 event)
+{
+ASSERT(event dev-nr_lpis);
+return dev-lpi_base + event;
+}
+
+/* Device assignment. Should be called from pci_device_add */
+int its_add_device(struct domain *d, u32 devid)
+{
+struct its_device *dev;
+unsigned long *lpi_map;
+void *itt;
+int lpi_base, nr_lpis, sz;
+u32 i, nr_ites, plpi, nr_cpus;
+struct its_collection *col;
+
+spin_lock(rb_its_dev_lock);
+dev = find_its_device(rb_its_dev, devid);
+if ( dev )
+{
+spin_unlock(rb_its_dev_lock);
+dprintk(XENLOG_G_ERR, ITS:d%dv%d Device already exists dev 0x%x\n,
+d-domain_id, current-vcpu_id, dev-device_id);
+return -EEXIST;
+}
+spin_unlock(rb_its_dev_lock);
+
+DPRINTK(ITS:d%dv%d Add device devid 0x%x\n,
+d-domain_id, current-vcpu_id, devid);
+
+dev = xzalloc(struct its_device);
+if ( dev == NULL )
+return -ENOMEM;
+
+dev-its = its_get_phys_node(devid);
+/* TODO: Use pci helper to get nvecs */
+nr_ites = 64;
+sz = nr_ites * dev-its-ite_size;
+sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1;
+itt = xzalloc_bytes(sz);
+if ( !itt )
+return -ENOMEM;
+
+lpi_map = its_lpi_alloc_chunks(nr_ites, lpi_base, nr_lpis);
+if ( !lpi_map || (nr_lpis != nr_ites) )
+{
+ xfree(dev);
+ xfree(itt);
+ xfree(lpi_map);
+ return -EINVAL;
+}
+
+dev-itt_addr = (u64)itt;
+dev-nr_ites = nr_ites;
+dev-lpi_map = lpi_map;
+dev-lpi_base = lpi_base;
+/* nr_lpis should be always equal to nvecs */
+dev-nr_lpis = nr_lpis;
+dev-device_id = devid;
+
+DPRINTK(ITS:d%dv%d Adding Device with id 0x%x nvecs %d lpi_base 0x%x\n,
+
[Xen-devel] [RFC PATCH v3 13/18] xen/arm: ITS: Add irq descriptors for LPIs
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add irq descriptors for LPIs and route
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3.c |8 +++-
xen/arch/arm/gic.c| 17 +++-
xen/arch/arm/irq.c| 38 +
xen/arch/arm/vgic-v3-its.c|9 +
xen/arch/arm/vgic.c | 90 ++---
xen/include/asm-arm/domain.h |2 +
xen/include/asm-arm/gic-its.h |6 +++
xen/include/asm-arm/gic.h |3 ++
xen/include/asm-arm/vgic.h|1 +
9 files changed, 157 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 737646c..793f2f0 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -899,9 +899,13 @@ static void gicv3_update_lr(int lr, const struct
pending_irq *p,
val = (((uint64_t)state 0x3) GICH_LR_STATE_SHIFT) | grp;
val |= ((uint64_t)p-priority 0xff) GICH_LR_PRIORITY_SHIFT;
-val |= ((uint64_t)p-irq GICH_LR_VIRTUAL_MASK) GICH_LR_VIRTUAL_SHIFT;
- if ( p-desc != NULL )
+if ( is_lpi(p-irq) )
+val |= ((uint64_t)p-irq GICH_LR_VIRTUAL_MASK)
GICH_LR_VIRTUAL_SHIFT;
+else
+val |= ((uint64_t)p-irq GICH_LR_VIRTUAL_MASK)
GICH_LR_VIRTUAL_SHIFT;
+
+ if ( p-desc != NULL !(is_lpi(p-irq)) )
val |= GICH_LR_HW | (((uint64_t)p-desc-irq GICH_LR_PHYSICAL_MASK)
GICH_LR_PHYSICAL_SHIFT);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index cfc9c42..091f7e5 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -124,18 +124,31 @@ void gic_route_irq_to_xen(struct irq_desc *desc, const
cpumask_t *cpu_mask,
unsigned int priority)
{
ASSERT(priority = 0xff); /* Only 8 bits of priority */
-ASSERT(desc-irq gic_number_lines());/* Can't route interrupts that
don't exist */
+/* Can't route interrupts that don't exist */
+ASSERT(desc-irq gic_number_lines() is_lpi(desc-irq));
ASSERT(test_bit(_IRQ_DISABLED, desc-status));
ASSERT(spin_is_locked(desc-lock));
desc-handler = gic_hw_ops-gic_host_irq_type;
-gic_set_irq_properties(desc, cpu_mask, priority);
+if ( !is_lpi(desc-irq) )
+gic_set_irq_properties(desc, cpu_mask, priority);
}
/* Program the GIC to route an interrupt to a guest
* - desc.lock must be held
*/
+int gic_route_lpi_to_guest(struct domain *d, unsigned int virq,
+ struct irq_desc *desc, unsigned int priority)
+{
+ASSERT(spin_is_locked(desc-lock));
+
+desc-handler = gic_hw_ops-gic_guest_irq_type;
+set_bit(_IRQ_GUEST, desc-status);
+
+return 0;
+}
+
int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
struct irq_desc *desc, unsigned int priority)
{
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 9dbdf7d..105ef85 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -57,12 +57,22 @@ hw_irq_controller no_irq_type = {
};
static irq_desc_t irq_desc[NR_IRQS];
+static irq_desc_t irq_desc_lpi[MAX_NR_LPIS];
static DEFINE_PER_CPU(irq_desc_t[NR_LOCAL_IRQS], local_irq_desc);
irq_desc_t *__irq_to_desc(int irq)
{
+struct irq_desc *desc = NULL;
if (irq NR_LOCAL_IRQS) return this_cpu(local_irq_desc)[irq];
-return irq_desc[irq-NR_LOCAL_IRQS];
+else if ( irq = NR_LOCAL_IRQS irq NR_IRQS)
+return irq_desc[irq-NR_LOCAL_IRQS];
+else
+{
+if ( is_lpi(irq) )
+return irq_desc_lpi[irq - NR_GIC_LPI];
+}
+
+return desc;
}
int __init arch_init_one_irq_desc(struct irq_desc *desc)
@@ -83,6 +93,13 @@ static int __init init_irq_data(void)
desc-action = NULL;
}
+for ( irq = NR_GIC_LPI; irq MAX_LPI; irq++ )
+{
+struct irq_desc *desc = irq_to_desc(irq);
+init_one_irq_desc(desc);
+desc-irq = irq;
+desc-action = NULL;
+}
return 0;
}
@@ -178,7 +195,7 @@ int request_irq(unsigned int irq, unsigned int irqflags,
* which interrupt is which (messes up the interrupt freeing
* logic etc).
*/
-if ( irq = nr_irqs )
+if ( irq = nr_irqs !is_lpi(irq) )
return -EINVAL;
if ( !handler )
return -EINVAL;
@@ -237,9 +254,12 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq,
int is_fiq)
set_bit(_IRQ_INPROGRESS, desc-status);
desc-arch.eoi_cpu = smp_processor_id();
+if ( is_lpi(irq) )
+vgic_vcpu_inject_lpi(info-d, irq);
+else
/* the irq cannot be a PPI, we only support delivery of SPIs to
* guests */
-vgic_vcpu_inject_spi(info-d, info-virq);
+vgic_vcpu_inject_spi(info-d, info-virq);
goto out_no_end;
}
@@ -405,6 +425,8 @@ err:
bool_t is_assignable_irq(unsigned int irq)
{
+if ( is_lpi(irq) )
+return 1;
/* For now, we can only route SPIs to the guest */
[Xen-devel] [RFC PATCH v3 16/18] xen/arm: ITS: Handle LPI interrupts
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Handle and route LPI interrupts
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic.c |5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 091f7e5..802f82f 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -665,6 +665,11 @@ void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
do {
/* Reading IRQ will ACK it */
irq = gic_hw_ops-read_irq();
+if ( is_lpi(irq) ) {
+/* TODO: Enable irqs */
+do_IRQ(regs, irq, is_fiq);
+continue;
+}
if ( likely(irq = 16 irq 1020) )
{
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH v3 11/18] xen/arm: ITS: Add GITS registers emulation
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Emulate GITS* registers and handle LPI configuration
table update trap.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/vgic-v3-its.c| 516 +
xen/include/asm-arm/gic-its.h | 14 ++
2 files changed, 530 insertions(+)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 0671434..fa9dccc 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -63,6 +63,46 @@ static void dump_cmd(its_cmd_block *cmd)
}
#endif
+void vgic_its_disable_lpis(struct vcpu *v, uint32_t vlpi)
+{
+struct pending_irq *p;
+unsigned long flags;
+
+p = irq_to_pending(v, vlpi);
+clear_bit(GIC_IRQ_GUEST_ENABLED, p-status);
+gic_remove_from_queues(v, vlpi);
+if ( p-desc != NULL )
+{
+spin_lock_irqsave(p-desc-lock, flags);
+p-desc-handler-disable(p-desc);
+spin_unlock_irqrestore(p-desc-lock, flags);
+}
+}
+
+void vgic_its_enable_lpis(struct vcpu *v, uint32_t vlpi, uint8_t priority)
+{
+struct pending_irq *p;
+unsigned long flags;
+
+/* Get plpi for the given vlpi */
+p = irq_to_pending(v, vlpi);
+p-priority = priority;
+set_bit(GIC_IRQ_GUEST_ENABLED, p-status);
+
+spin_lock_irqsave(v-arch.vgic.lock, flags);
+
+if ( !list_empty(p-inflight)
+ !test_bit(GIC_IRQ_GUEST_VISIBLE, p-status) )
+gic_raise_guest_irq(v, irq_to_virq(p-desc), p-priority);
+
+spin_unlock_irqrestore(v-arch.vgic.lock, flags);
+if ( p-desc != NULL )
+{
+spin_lock_irqsave(p-desc-lock, flags);
+p-desc-handler-enable(p-desc);
+spin_unlock_irqrestore(p-desc-lock, flags);
+}
+}
/* ITS device table helper functions */
int vits_vdevice_entry(struct domain *d, uint32_t dev_id,
struct vdevice_table *entry, int set)
@@ -649,6 +689,482 @@ err:
return 0;
}
+static int vgic_v3_gits_lpi_mmio_read(struct vcpu *v, mmio_info_t *info)
+{
+uint32_t offset;
+struct hsr_dabt dabt = info-dabt;
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+register_t *r = select_user_reg(regs, dabt.reg);
+uint8_t cfg;
+
+offset = info-gpa -
+ (v-domain-arch.vits-propbase 0xf000UL);
+
+if ( offset SZ_64K )
+{
+DPRINTK(vITS:d%dv%d LPI Table read offset 0x%x\n,
+v-domain-domain_id, v-vcpu_id, offset);
+cfg = readb_relaxed(v-domain-arch.vits-prop_page + offset);
+*r = cfg;
+return 1;
+}
+else
+dprintk(XENLOG_G_ERR, vITS:d%dv%d LPI Table read with wrong offset
0x%x\n,
+v-domain-domain_id, v-vcpu_id, offset);
+
+
+return 0;
+}
+
+static int vgic_v3_gits_lpi_mmio_write(struct vcpu *v, mmio_info_t *info)
+{
+uint32_t offset;
+uint32_t vid;
+uint8_t cfg;
+bool_t enable;
+struct hsr_dabt dabt = info-dabt;
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+register_t *r = select_user_reg(regs, dabt.reg);
+
+offset = info-gpa -
+ (v-domain-arch.vits-propbase 0xf000UL);
+
+vid = offset + NR_GIC_LPI;
+if ( offset SZ_64K )
+{
+DPRINTK(vITS:d%dv%d LPI Table write offset 0x%x\n,
+v-domain-domain_id, v-vcpu_id, offset);
+cfg = readb_relaxed(v-domain-arch.vits-prop_page + offset);
+enable = (cfg *r) 0x1;
+
+if ( !enable )
+ vgic_its_enable_lpis(v, vid, (*r 0xfc));
+else
+ vgic_its_disable_lpis(v, vid);
+
+/* Update virtual prop page */
+writeb_relaxed((*r 0xff),
+v-domain-arch.vits-prop_page + offset);
+
+return 1;
+}
+else
+dprintk(XENLOG_G_ERR, vITS:d%dv%d LPI Table invalid write @ 0x%x\n,
+v-domain-domain_id, v-vcpu_id, offset);
+
+return 0;
+}
+
+static const struct mmio_handler_ops vgic_gits_lpi_mmio_handler = {
+.read_handler = vgic_v3_gits_lpi_mmio_read,
+.write_handler = vgic_v3_gits_lpi_mmio_write,
+};
+
+int vgic_its_unmap_lpi_prop(struct vcpu *v)
+{
+paddr_t maddr;
+uint32_t lpi_size;
+int i;
+
+maddr = v-domain-arch.vits-propbase 0xf000UL;
+lpi_size = 1UL ((v-domain-arch.vits-propbase 0x1f) + 1);
+
+DPRINTK(vITS:d%dv%d Unmap guest LPI conf table maddr 0x%lx lpi_size
0x%x\n,
+ v-domain-domain_id, v-vcpu_id, maddr, lpi_size);
+
+if ( lpi_size SZ_64K )
+{
+dprintk(XENLOG_G_ERR, vITS:d%dv%d LPI Prop page 64K\n,
+v-domain-domain_id, v-vcpu_id);
+return 0;
+}
+
+/* XXX: As per 4.8.9 each re-distributor shares a common LPI configuration
table
+ * So one set of mmio handlers to manage configuration table is enough
+ */
+for ( i = 0; i lpi_size / PAGE_SIZE; i++ )
+guest_physmap_remove_page(v-domain, paddr_to_pfn(maddr),
+
[Xen-devel] [RFC PATCH v3 08/18] xen/arm: vITS: Add virtual ITS driver
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
This patch introduces virtual ITS driver with following
functionality
- Introduces helper functions to manage device table and
ITT table in guest memory
- Helper function to handle virtual ITS devices assigned
to domain
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/Makefile |1 +
xen/arch/arm/vgic-v3-its.c| 266 +
xen/include/asm-arm/domain.h |2 +
xen/include/asm-arm/gic-its.h | 49
4 files changed, 318 insertions(+)
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1821ed2..8590846 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -33,6 +33,7 @@ obj-y += traps.o
obj-y += vgic.o vgic-v2.o
obj-$(CONFIG_ARM_64) += vgic-v3.o
obj-$(CONFIG_ARM_64) += gic-v3-its.o
+obj-$(CONFIG_ARM_64) += vgic-v3-its.o
obj-y += vtimer.o
obj-y += vuart.o
obj-y += hvm.o
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
new file mode 100644
index 000..ea52a87
--- /dev/null
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -0,0 +1,266 @@
+/*
+ * Copyright (C) 2015 Cavium Inc.
+ * Vijaya Kumar K vijaya.ku...@caviumnetworks.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include xen/bitops.h
+#include xen/config.h
+#include xen/init.h
+#include xen/irq.h
+#include xen/list.h
+#include xen/sched.h
+#include xen/sizes.h
+#include asm/device.h
+#include asm/mmio.h
+#include asm/io.h
+#include asm/gic_v3_defs.h
+#include asm/gic.h
+#include asm/vgic.h
+#include asm/gic-its.h
+#include xen/log2.h
+
+/* GITS register definitions */
+#define VITS_GITS_TYPER_HCC (0xffU 24)
+#define VITS_GITS_TYPER_PTA_SHIFT (19)
+#define VITS_GITS_DEV_BITS(0x14U 13)
+#define VITS_GITS_ID_BITS (0x13U 8)
+#define VITS_GITS_ITT_SIZE(0x7U 4)
+#define VITS_GITS_DISTRIBUTED (0x1U 3)
+#define VITS_GITS_PLPIS (0x1U 0)
+
+/* GITS_PIDRn register values for ARM implementations */
+#define GITS_PIDR0_VAL(0x94)
+#define GITS_PIDR1_VAL(0xb4)
+#define GITS_PIDR2_VAL(0x3b)
+#define GITS_PIDR3_VAL(0x00)
+#define GITS_PIDR4_VAL(0x04)
+
+// #define DEBUG_ITS
+
+#ifdef DEBUG_ITS
+# define DPRINTK(fmt, args...) dprintk(XENLOG_DEBUG, fmt, ##args)
+#else
+# define DPRINTK(fmt, args...) do {} while ( 0 )
+#endif
+
+#ifdef DEBUG_ITS
+static void dump_cmd(its_cmd_block *cmd)
+{
+printk(CMD[0] = 0x%lx CMD[1] = 0x%lx CMD[2] = 0x%lx CMD[3] = 0x%lx\n,
+ cmd-raw_cmd[0], cmd-raw_cmd[1], cmd-raw_cmd[2], cmd-raw_cmd[3]);
+}
+#endif
+
+/* ITS device table helper functions */
+int vits_vdevice_entry(struct domain *d, uint32_t dev_id,
+ struct vdevice_table *entry, int set)
+{
+uint64_t offset;
+paddr_t dt_entry;
+struct page_info *page;
+p2m_type_t p2mt;
+void *p;
+
+offset = dev_id * sizeof(struct vdevice_table);
+if ( offset d-arch.vits-dt_size )
+{
+dprintk(XENLOG_G_ERR,
+vITS:d%dv%d: Out of range offset 0x%lx id 0x%x size 0x%lx\n,
+d-domain_id, current-vcpu_id, offset, dev_id,
+d-arch.vits-dt_size);
+return -EINVAL;
+}
+
+dt_entry = d-arch.vits-dt_ipa + offset;
+
+page = get_page_from_gfn(d, paddr_to_pfn(dt_entry), p2mt, P2M_ALLOC);
+if ( !page )
+{
+dprintk(XENLOG_G_ERR, vITS:d%dv%d Failed to get VITT device table\n,
+d-domain_id, current-vcpu_id);
+return -EINVAL;
+}
+
+if ( !p2m_is_ram(p2mt) )
+{
+put_page(page);
+dprintk(XENLOG_G_ERR, vITS:d%dv%d with wrong attributes\n,
+d-domain_id, current-vcpu_id);
+return -EINVAL;
+return -EINVAL;
+}
+
+p = __map_domain_page(page);
+/* Offset within the mapped page */
+offset = dt_entry (PAGE_SIZE - 1);
+
+if ( set )
+memcpy(p + offset, entry, sizeof(struct vdevice_table));
+else
+memcpy(entry, p + offset, sizeof(struct vdevice_table));
+
+unmap_domain_page(p);
+put_page(page);
+
+return 0;
+}
+
+int vits_set_vdevice_entry(struct domain *d, uint32_t devid,
+ struct vdevice_table *entry)
+{
+return vits_vdevice_entry(d, devid, entry, 1);
+}
+
+int vits_get_vdevice_entry(struct domain *d, uint32_t devid,
+ struct vdevice_table
[Xen-devel] [RFC PATCH v3 07/18] xen/arm: ITS: implement hw_irq_controller for LPIs
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Implements hw_irq_controller api's required
to handle LPI's
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c | 39 +++
xen/arch/arm/gic-v3.c | 26 +++---
xen/arch/arm/irq.c| 16
xen/include/asm-arm/gic-its.h | 10 ++
xen/include/asm-arm/gic.h |4
xen/include/asm-arm/irq.h |4 +++-
6 files changed, 91 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 349d0bb..535fc53 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -508,6 +508,45 @@ static void its_send_invall(struct its_node *its, struct
its_collection *col)
its_send_single_command(its, its_build_invall_cmd, desc);
}
+void lpi_set_config(struct irq_desc *desc, int enable)
+{
+struct its_collection *col;
+struct its_device *its_dev = get_irq_device(desc);
+u8 *cfg;
+u32 virq = irq_to_virq(desc);
+
+ASSERT(virq its_dev-nr_lpis);
+
+cfg = gic_rdists-prop_page + desc-irq - NR_GIC_LPI;
+if ( enable )
+*cfg |= LPI_PROP_ENABLED;
+else
+*cfg = ~LPI_PROP_ENABLED;
+
+/*
+ * Make the above write visible to the redistributors.
+ * And yes, we're flushing exactly: One. Single. Byte.
+ * Humpf...
+ */
+if ( gic_rdists-flags RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING )
+clean_and_invalidate_dcache_va_range(cfg, sizeof(*cfg));
+else
+dsb(ishst);
+
+/* Get collection id for this event id */
+col = its_dev-its-collections[virq % num_online_cpus()];
+its_send_inv(its_dev, col, virq);
+}
+
+void its_set_affinity(struct irq_desc *desc, int cpu)
+{
+struct its_device *its_dev = get_irq_device(desc);
+struct its_collection *target_col;
+
+/* Physical collection id */
+target_col = its_dev-its-collections[cpu];
+its_send_movi(its_dev, target_col, irq_to_virq(desc));
+}
/*
* How we allocate LPIs:
*
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b5c59f6..556b291 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -40,6 +40,7 @@
#include asm/device.h
#include asm/gic.h
#include asm/gic_v3_defs.h
+#include asm/gic-its.h
#include asm/cpufeature.h
struct rdist_region {
@@ -427,12 +428,18 @@ static void gicv3_poke_irq(struct irq_desc *irqd, u32
offset)
static void gicv3_unmask_irq(struct irq_desc *irqd)
{
-gicv3_poke_irq(irqd, GICD_ISENABLER);
+if ( is_lpi(irqd-irq) )
+lpi_set_config(irqd, 1);
+else
+gicv3_poke_irq(irqd, GICD_ISENABLER);
}
static void gicv3_mask_irq(struct irq_desc *irqd)
{
-gicv3_poke_irq(irqd, GICD_ICENABLER);
+if ( is_lpi(irqd-irq) )
+lpi_set_config(irqd, 0);
+else
+gicv3_poke_irq(irqd, GICD_ICENABLER);
}
static void gicv3_eoi_irq(struct irq_desc *irqd)
@@ -1095,13 +1102,18 @@ static void gicv3_irq_set_affinity(struct irq_desc
*desc, const cpumask_t *mask)
spin_lock(gicv3.lock);
cpu = gicv3_get_cpu_from_mask(mask);
-affinity = gicv3_mpidr_to_affinity(cpu);
-/* Make sure we don't broadcast the interrupt */
-affinity = ~GICD_IROUTER_SPI_MODE_ANY;
-if ( desc-irq = NR_GIC_LOCAL_IRQS )
-writeq_relaxed(affinity, (GICD + GICD_IROUTER + desc-irq * 8));
+if ( is_lpi(desc-irq) )
+its_set_affinity(desc, cpu);
+else
+{
+affinity = gicv3_mpidr_to_affinity(cpu);
+/* Make sure we don't broadcast the interrupt */
+affinity = ~GICD_IROUTER_SPI_MODE_ANY;
+if ( desc-irq = NR_GIC_LOCAL_IRQS )
+writeq_relaxed(affinity, (GICD + GICD_IROUTER + desc-irq * 8));
+}
spin_unlock(gicv3.lock);
}
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 2dd43ee..9dbdf7d 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -36,6 +36,7 @@ struct irq_guest
{
struct domain *d;
unsigned int virq;
+struct its_device *dev;
};
static void ack_none(struct irq_desc *irq)
@@ -143,6 +144,21 @@ static inline struct domain *irq_get_domain(struct
irq_desc *desc)
return irq_get_guest_info(desc)-d;
}
+unsigned int irq_to_virq(struct irq_desc *desc)
+{
+return irq_get_guest_info(desc)-virq;
+}
+
+struct its_device *get_irq_device(struct irq_desc *desc)
+{
+return irq_get_guest_info(desc)-dev;
+}
+
+void set_irq_device(struct irq_desc *desc, struct its_device *dev)
+{
+irq_get_guest_info(desc)-dev = dev;
+}
+
void irq_set_affinity(struct irq_desc *desc, const cpumask_t *cpu_mask)
{
if ( desc != NULL )
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index 59a6490..a47cf26 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -205,6 +205,16 @@ static inline uint8_t its_decode_cmd(its_cmd_block *cmd)
return cmd-raw_cmd[0] 0xff;
}
+static
[Xen-devel] [RFC PATCH v3 06/18] xen/arm: ITS: Add helper functions to manage its_devices
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Helper functions to mange its devices using RB-tree
are introduced in physical ITS driver.
This is global list of all the devices.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c | 49 +
xen/include/asm-arm/gic-its.h |3 +++
2 files changed, 52 insertions(+)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index b1a97c1..349d0bb 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -92,6 +92,7 @@ struct its_node {
static LIST_HEAD(its_nodes);
static DEFINE_SPINLOCK(its_lock);
static struct rdist_prop *gic_rdists;
+static struct rb_root rb_its_dev;
#define gic_data_rdist()(per_cpu(rdist, smp_processor_id()))
#define gic_data_rdist_rd_base()(per_cpu(rdist, smp_processor_id()).rbase)
@@ -145,6 +146,53 @@ void dump_cmd(its_cmd_block *cmd)
}
#endif
+/* RB-tree helpers for its_device */
+struct its_device * find_its_device(struct rb_root *root, u32 devid)
+{
+struct rb_node *node = root-rb_node;
+
+while ( node )
+{
+struct its_device *dev;
+
+dev = container_of(node, struct its_device, node);
+if ( devid dev-device_id )
+node = node-rb_left;
+else if ( devid dev-device_id )
+node = node-rb_right;
+else
+return dev;
+}
+
+return NULL;
+}
+
+int insert_its_device(struct rb_root *root, struct its_device *dev)
+{
+struct rb_node **new, *parent;
+
+new = root-rb_node;
+parent = NULL;
+while ( *new )
+{
+struct its_device *this;
+
+this = container_of(*new, struct its_device, node);
+parent = *new;
+if ( dev-device_id this-device_id )
+new = ((*new)-rb_left);
+else if ( dev-device_id this-device_id )
+new = ((*new)-rb_right);
+else
+return -EEXIST;
+}
+
+rb_link_node(dev-node, parent, new);
+rb_insert_color(dev-node, root);
+
+return 0;
+}
+
#define ITS_CMD_QUEUE_SZSZ_64K
#define ITS_CMD_QUEUE_NR_ENTRIES(ITS_CMD_QUEUE_SZ / sizeof(its_cmd_block))
@@ -994,6 +1042,7 @@ static int its_probe(struct dt_device_node *node)
list_add(its-entry, its_nodes);
spin_unlock(its_lock);
+rb_its_dev = RB_ROOT;
return 0;
out_free_tables:
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index 4e42f7f..59a6490 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -19,6 +19,7 @@
#define __ASM_ARM_GIC_ITS_H__
#include asm/gic_v3_defs.h
+#include xen/rbtree.h
/*
* Collection structure - just an ID, and a redistributor address to
@@ -195,6 +196,8 @@ struct its_device {
u32 nr_ites;
/* Physical Device id */
u32 device_id;
+/* RB-tree entry */
+struct rb_node node;
};
static inline uint8_t its_decode_cmd(its_cmd_block *cmd)
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2][RFC] libxl: Add AHCI support for upstream qemu
Il 22/06/2015 12:34, George Dunlap ha scritto: On Fri, Jun 19, 2015 at 12:18 PM, Fabio Fantoni fabio.fant...@m2r.biz wrote: Il 11/06/2015 12:28, Fabio Fantoni ha scritto: Il 11/06/2015 12:06, Zir Blazer ha scritto: Since I'm not a developer I may be peeking my nose a bit too far, but based on what I know, I think that enabling AHCI by default would be a compatibility suicide. I'm not sure about Linux and Windows Vista/7/8+, but at least for Windows XP based VMs, it would be a terrible idea. Also use windows xp without security updates (support ended one year ago) is a suicide. I already did this patch considering windows domU problems (I'm using mainly them for now), ahci used with option (ahci=0|1) instead replace and default is disabled. I tried it with different windows (excluding xp...abandoned) I also tried with new winpv drivers (http://www.xenproject.org/developers/teams/windows-pv-drivers.html) With this patch applied ahci will be not used and will be used only setting ahci=1, is it a good idea or is there problem also in this case? I did many other tests in different linux hvm domUs (fedora and ubuntu) and windows (7, 8.1, 10) without found problems. Is this patch acceptable for xen 4.6? Well maybe I missed something, but: 1. The most recent version of this patch (v2) has RFC in the title; this is a specific request *not* to apply this patch. 2. The most recent version of this patch has the following in the changelog: NOTES: This patch is a only a fast draft for testing. That also sounds like you're asking people not to apply the patch. 3. After reading the changelog, many people were still unclear what the purpose of the patch is. You answered their questions by e-mail, but that information needs to be in the changelog. So you need to resend the patch 1) with RFC removed from the title; and 2) with a proper changelog that doesn't say just a draft, but that 3) explains what the purpose of the change for people reading through the revision history. -George Thanks for reply, I did RFC initially more than 1 month ago when I was less certainty requiring comment and experts review. Is RFC=request for comments or I'm wrong? Now after many tests on many systems and keep using it for weeks without problem seems ok. I'll post v3 including missing doc, libxl.h entry and improving changelog. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: add a 'acpi_fake_s3' boot command line parameter
On 22.06.15 at 13:28, dario.faggi...@citrix.com wrote:
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -33,6 +33,9 @@
uint32_t system_reset_counter = 1;
+static bool_t __read_mostly fake_s3 = 0;
+boolean_param(acpi_fake_s3, fake_s3);
+
static char __initdata opt_acpi_sleep[20];
string_param(acpi_sleep, opt_acpi_sleep);
@@ -177,7 +180,8 @@ static int enter_state(u32 state)
switch ( state )
{
case ACPI_STATE_S3:
-do_suspend_lowlevel();
+if ( likely(!fake_s3) )
+do_suspend_lowlevel();
system_reset_counter++;
error = tboot_s3_resume();
break;
The change is so simple that, considering it's for debugging purposes
only, I don't see why people needing to debug this code couldn't
apply it themselves when needed. Imo, if to be considered at all, it
should be made !NDEBUG dependent.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/vLAPIC: adjust types in internal read/write handling
- use 32-bit types where possible (produces slightly better code)
- drop (now) unnecessary casts
- avoid indirection where not needed
- avoid duplicate log messages in vlapic_write()
- minor other cleanup
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -556,52 +556,42 @@ static void vlapic_set_tdcr(struct vlapi
timer_divisor: %d, vlapic-hw.timer_divisor);
}
-static void vlapic_read_aligned(
-struct vlapic *vlapic, unsigned int offset, unsigned int *result)
+static uint32_t vlapic_read_aligned(struct vlapic *vlapic, unsigned int offset)
{
switch ( offset )
{
case APIC_PROCPRI:
-*result = vlapic_get_ppr(vlapic);
-break;
+return vlapic_get_ppr(vlapic);
case APIC_TMCCT: /* Timer CCR */
if ( !vlapic_lvtt_oneshot(vlapic) !vlapic_lvtt_period(vlapic) )
-{
-*result = 0;
break;
-}
-*result = vlapic_get_tmcct(vlapic);
-break;
+return vlapic_get_tmcct(vlapic);
case APIC_TMICT: /* Timer ICR */
if ( !vlapic_lvtt_oneshot(vlapic) !vlapic_lvtt_period(vlapic) )
-{
-*result = 0;
break;
-}
+/* fall through */
default:
-*result = vlapic_get_reg(vlapic, offset);
-break;
+return vlapic_get_reg(vlapic, offset);
}
+
+return 0;
}
static int vlapic_read(
struct vcpu *v, unsigned long address,
unsigned long len, unsigned long *pval)
{
-unsigned int alignment;
-unsigned int tmp;
-unsigned long result = 0;
struct vlapic *vlapic = vcpu_vlapic(v);
unsigned int offset = address - vlapic_base_address(vlapic);
+unsigned int alignment = offset 3, tmp, result = 0;
if ( offset (APIC_TDCR + 0x3) )
goto out;
-alignment = offset 0x3;
+tmp = vlapic_read_aligned(vlapic, offset ~3);
-vlapic_read_aligned(vlapic, offset ~0x3, tmp);
switch ( len )
{
case 1:
@@ -627,7 +617,7 @@ static int vlapic_read(
}
HVM_DBG_LOG(DBG_LEVEL_VLAPIC, offset %#x with length %#lx,
-and the result is %#lx, offset, len, result);
+and the result is %#x, offset, len, result);
out:
*pval = result;
@@ -657,19 +647,17 @@ int hvm_x2apic_msr_read(struct vcpu *v,
#undef REGBLOCK
};
struct vlapic *vlapic = vcpu_vlapic(v);
-uint32_t low, high = 0, reg = msr - MSR_IA32_APICBASE_MSR,
-offset = reg 4;
+uint32_t high = 0, reg = msr - MSR_IA32_APICBASE_MSR, offset = reg 4;
if ( !vlapic_x2apic_mode(vlapic) ||
(reg = sizeof(readable) * 8) || !test_bit(reg, readable) )
return X86EMUL_UNHANDLEABLE;
if ( offset == APIC_ICR )
-vlapic_read_aligned(vlapic, APIC_ICR2, high);
-
-vlapic_read_aligned(vlapic, offset, low);
+high = vlapic_read_aligned(vlapic, APIC_ICR2);
-*msr_content = (((uint64_t)high) 32) | low;
+*msr_content = ((uint64_t)high 32) |
+ vlapic_read_aligned(vlapic, offset);
return X86EMUL_OKAY;
}
@@ -687,7 +675,7 @@ static void vlapic_tdt_pt_cb(struct vcpu
}
static int vlapic_reg_write(struct vcpu *v,
-unsigned int offset, unsigned long val)
+unsigned int offset, uint32_t val)
{
struct vlapic *vlapic = vcpu_vlapic(v);
int rc = X86EMUL_OKAY;
@@ -797,8 +785,7 @@ static int vlapic_reg_write(struct vcpu
break;
}
-period = ((uint64_t)APIC_BUS_CYCLE_NS *
- (uint32_t)val * vlapic-hw.timer_divisor);
+period = (uint64_t)APIC_BUS_CYCLE_NS * val * vlapic-hw.timer_divisor;
TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(period),
TRC_PAR_LONG(vlapic_lvtt_period(vlapic) ? period : 0LL),
vlapic-pt.irq);
@@ -811,7 +798,7 @@ static int vlapic_reg_write(struct vcpu
HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
bus cycle is %uns,
-initial count %lu, period %PRIu64ns,
+initial count %u, period %PRIu64ns,
APIC_BUS_CYCLE_NS, val, period);
}
break;
@@ -847,47 +834,41 @@ static int vlapic_write(struct vcpu *v,
* According to the IA32 Manual, all accesses should be 32 bits.
* Some OSes do 8- or 16-byte accesses, however.
*/
-val = (uint32_t)val;
-if ( len != 4 )
+if ( unlikely(len != 4) )
{
-unsigned int tmp;
-unsigned char alignment;
-
-gdprintk(XENLOG_INFO, Notice: Local APIC write with len = %lx\n,len);
-
-alignment = offset 0x3;
-(void)vlapic_read_aligned(vlapic, offset ~0x3, tmp);
+unsigned int tmp = vlapic_read_aligned(vlapic, offset ~3);
+unsigned char alignment = (offset 3) * 8;
switch ( len )
{
case 1:
-val = ((tmp
[Xen-devel] [RFC PATCH v3 04/18] xen/arm: gicv3: Refactor redistributor information
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Separate redistributor information into rdist and rdist_prop
structures.
The rdist_prop holds the redistributor common information
and rdist holds the per cpu specific information.
This percpu rdist defined as global and shared with ITS
driver
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3.c | 15 ++-
xen/include/asm-arm/gic_v3_defs.h | 15 +++
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 30682cf..b5c59f6 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -53,6 +53,7 @@ static struct {
paddr_t dbase;/* Address of distributor registers */
paddr_t dbase_size;
void __iomem *map_dbase; /* Mapped address of distributor registers */
+struct rdist_prop rdist_data;
struct rdist_region *rdist_regions;
uint32_t rdist_stride;
unsigned int rdist_count; /* Number of rdist regions count */
@@ -63,10 +64,10 @@ static struct {
static struct gic_info gicv3_info;
/* per-cpu re-distributor base */
-static DEFINE_PER_CPU(void __iomem*, rbase);
+DEFINE_PER_CPU(struct rdist, rdist);
#define GICD (gicv3.map_dbase)
-#define GICD_RDIST_BASE(this_cpu(rbase))
+#define GICD_RDIST_BASE(per_cpu(rdist, smp_processor_id()).rbase)
#define GICD_RDIST_SGI_BASE(GICD_RDIST_BASE + SZ_64K)
/*
@@ -613,6 +614,7 @@ static int __init gicv3_populate_rdist(void)
uint32_t aff;
uint32_t reg;
uint64_t typer;
+uint64_t offset;
uint64_t mpidr = cpu_logical_map(smp_processor_id());
/*
@@ -648,9 +650,12 @@ static int __init gicv3_populate_rdist(void)
if ( (typer 32) == aff )
{
-this_cpu(rbase) = ptr;
-printk(GICv3: CPU%d: Found redistributor in region %d @%p\n,
-smp_processor_id(), i, ptr);
+offset = ptr - gicv3.rdist_regions[i].map_base;
+per_cpu(rdist, smp_processor_id()).rbase = ptr;
+per_cpu(rdist, smp_processor_id()).phys_base =
gicv3.rdist_regions[i].base + offset;
+printk(GICv3: CPU%d: Found redistributor in region %d
@%PRIpaddr\n,
+smp_processor_id(), i,
+per_cpu(rdist, smp_processor_id()).phys_base);
return 0;
}
if ( gicv3.rdist_stride )
diff --git a/xen/include/asm-arm/gic_v3_defs.h
b/xen/include/asm-arm/gic_v3_defs.h
index 556f114..acbb906 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -152,6 +152,21 @@
#define ICH_SGI_IRQ_SHIFT24
#define ICH_SGI_IRQ_MASK 0xf
#define ICH_SGI_TARGETLIST_MASK 0x
+
+struct rdist {
+void __iomem *rbase;
+void * pend_page;
+paddr_t phys_base;
+};
+
+struct rdist_prop {
+void * prop_page;
+intid_bits;
+uint64_t flags;
+};
+
+DECLARE_PER_CPU(struct rdist, rdist);
+
#endif /* __ASM_ARM_GIC_V3_DEFS_H__ */
/*
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH v3 02/18] xen: Add log2 functionality
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
log2 helper apis are ported from linux
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/include/xen/bitops.h |8 ++
xen/include/xen/log2.h | 205 ++
2 files changed, 213 insertions(+)
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h
index cb56f24..b01333c 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -117,6 +117,14 @@ static inline int generic_fls64(__u64 x)
# endif
#endif
+static inline unsigned fls_long(unsigned long l)
+{
+if (sizeof(l) == 4)
+return fls(l);
+
+return fls64(l);
+}
+
static __inline__ int get_bitmask_order(unsigned int count)
{
int order;
diff --git a/xen/include/xen/log2.h b/xen/include/xen/log2.h
new file mode 100644
index 000..1e73ae2
--- /dev/null
+++ b/xen/include/xen/log2.h
@@ -0,0 +1,205 @@
+/*
+ * Copyright (C) 2006 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@redhat.com)
+ *
+ * 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.
+ */
+
+#ifndef _LINUX_LOG2_H
+#define _LINUX_LOG2_H
+
+#include xen/types.h
+#include xen/bitops.h
+
+/*
+ * deal with unrepresentable constant logarithms
+ */
+extern __attribute__((const))
+int ilog2_NaN(void);
+
+/*
+ * non-constant log of base 2 calculators
+ * - the arch may override these in asm/bitops.h if they can be implemented
+ * more efficiently than using fls() and fls64()
+ * - the arch is not required to handle n==0 if implementing the fallback
+ */
+static inline __attribute__((const))
+int __ilog2_u32(u32 n)
+{
+ return fls(n) - 1;
+}
+
+static inline __attribute__((const))
+int __ilog2_u64(u64 n)
+{
+ return fls64(n) - 1;
+}
+
+/*
+ * Determine whether some value is a power of two, where zero is
+ * *not* considered a power of two.
+ */
+
+static inline __attribute__((const))
+bool is_power_of_2(unsigned long n)
+{
+ return (n != 0 ((n (n - 1)) == 0));
+}
+
+#if 1
+/*
+ * round up to nearest power of two
+ */
+static inline __attribute__((const))
+unsigned long __roundup_pow_of_two(unsigned long n)
+{
+ return 1UL fls_long(n - 1);
+}
+
+/*
+ * round down to nearest power of two
+ */
+static inline __attribute__((const))
+unsigned long __rounddown_pow_of_two(unsigned long n)
+{
+ return 1UL (fls_long(n) - 1);
+}
+#endif
+/**
+ * ilog2 - log of base 2 of 32-bit or a 64-bit unsigned value
+ * @n - parameter
+ *
+ * constant-capable log of base 2 calculation
+ * - this can be used to initialise global variables from constant data, hence
+ * the massive ternary operator construction
+ *
+ * selects the appropriately-sized optimised version depending on sizeof(n)
+ */
+#define ilog2(n) \
+( \
+ __builtin_constant_p(n) ? ( \
+ (n) 1 ? ilog2_NaN() : \
+ (n) (1ULL 63) ? 63 : \
+ (n) (1ULL 62) ? 62 : \
+ (n) (1ULL 61) ? 61 : \
+ (n) (1ULL 60) ? 60 : \
+ (n) (1ULL 59) ? 59 : \
+ (n) (1ULL 58) ? 58 : \
+ (n) (1ULL 57) ? 57 : \
+ (n) (1ULL 56) ? 56 : \
+ (n) (1ULL 55) ? 55 : \
+ (n) (1ULL 54) ? 54 : \
+ (n) (1ULL 53) ? 53 : \
+ (n) (1ULL 52) ? 52 : \
+ (n) (1ULL 51) ? 51 : \
+ (n) (1ULL 50) ? 50 : \
+ (n) (1ULL 49) ? 49 : \
+ (n) (1ULL 48) ? 48 : \
+ (n) (1ULL 47) ? 47 : \
+ (n) (1ULL 46) ? 46 : \
+ (n) (1ULL 45) ? 45 : \
+ (n) (1ULL 44) ? 44 : \
+ (n) (1ULL 43) ? 43 : \
+ (n) (1ULL 42) ? 42 : \
+ (n) (1ULL 41) ? 41 : \
+ (n) (1ULL 40) ? 40 : \
+ (n) (1ULL 39) ? 39 : \
+ (n) (1ULL 38) ? 38 : \
+ (n) (1ULL 37) ? 37 : \
+ (n) (1ULL 36) ? 36 : \
+ (n) (1ULL 35) ? 35 : \
+ (n) (1ULL 34) ? 34 : \
+ (n) (1ULL 33) ? 33 : \
+ (n) (1ULL 32) ? 32 : \
+ (n) (1ULL 31) ? 31 : \
+ (n) (1ULL 30) ? 30 : \
+ (n) (1ULL 29) ? 29 : \
+ (n) (1ULL 28) ? 28 : \
+ (n) (1ULL 27) ? 27 : \
+ (n) (1ULL 26) ? 26 : \
+ (n) (1ULL 25) ? 25 : \
+
[Xen-devel] [RFC PATCH v3 00/18] Add ITS support
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com This is based on DraftF version http://xenbits.xen.org/people/ianc/vits/draftF.pdf Following major features are supported - GICv3 ITS support for arm64 platform - Only Dom0 is supported Basic boot is tested with single ITS node with hacks in pci driver. All Comments from V2 version are not fixed as this series is based on new design. Vijaya Kumar K (18): xen/arm: Add bitmap_find_next_zero_area helper function xen: Add log2 functionality xen: console: Add ratelimit support for error message xen/arm: gicv3: Refactor redistributor information xen/arm: ITS: Port ITS driver to xen xen/arm: ITS: Add helper functions to manage its_devices xen/arm: ITS: implement hw_irq_controller for LPIs xen/arm: vITS: Add virtual ITS driver xen/arm: ITS: Add virtual ITS commands support xen/arm: ITS: Add APIs to add and assign device xen/arm: ITS: Add GITS registers emulation xen/arm: ITS: Add GICR register emulation xen/arm: ITS: Add irq descriptors for LPIs xen/arm: ITS: Initialize physical ITS xen/arm: ITS: Add domain specific ITS initialization xen/arm: ITS: Handle LPI interrupts xen/arm: ITS: Generate ITS node for Dom0 xen/arm: ITS: Map ITS translation space xen/arch/arm/Makefile |2 + xen/arch/arm/domain_build.c | 50 +- xen/arch/arm/gic-v3-its.c | 1476 + xen/arch/arm/gic-v3.c | 71 +- xen/arch/arm/gic.c| 32 +- xen/arch/arm/irq.c| 54 +- xen/arch/arm/setup.c |1 + xen/arch/arm/vgic-v3-its.c| 1259 +++ xen/arch/arm/vgic-v3.c| 70 +- xen/arch/arm/vgic.c | 90 ++- xen/common/bitmap.c | 39 + xen/drivers/char/console.c| 17 +- xen/include/asm-arm/domain.h |5 + xen/include/asm-arm/gic-its.h | 306 xen/include/asm-arm/gic.h | 17 + xen/include/asm-arm/gic_v3_defs.h | 143 +++- xen/include/asm-arm/irq.h |4 +- xen/include/asm-arm/vgic.h|2 + xen/include/xen/bitmap.h |5 + xen/include/xen/bitops.h |8 + xen/include/xen/config.h |8 +- xen/include/xen/log2.h| 205 ++ 22 files changed, 3809 insertions(+), 55 deletions(-) create mode 100644 xen/arch/arm/gic-v3-its.c create mode 100644 xen/arch/arm/vgic-v3-its.c create mode 100644 xen/include/asm-arm/gic-its.h create mode 100644 xen/include/xen/log2.h -- 1.7.9.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH v3 03/18] xen: console: Add ratelimit support for error message
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com XENLOG_ERR_RATE_LIMIT and XENLOG_G_ERR_RATE_LIMIT log levels are added to support rate limit for error messages Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com --- xen/drivers/char/console.c | 17 + xen/include/xen/config.h |8 ++-- 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index fce4cc8..b01fde5 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -92,15 +92,15 @@ static DEFINE_SPINLOCK(console_lock); * the lower threshold equal to the upper. */ #ifdef NDEBUG -#define XENLOG_UPPER_THRESHOLD 2 /* Do not print INFO and DEBUG */ +#define XENLOG_UPPER_THRESHOLD 3 /* Do not print INFO and DEBUG */ #define XENLOG_LOWER_THRESHOLD 2 /* Always print ERR and WARNING */ -#define XENLOG_GUEST_UPPER_THRESHOLD 2 /* Do not print INFO and DEBUG */ +#define XENLOG_GUEST_UPPER_THRESHOLD 3 /* Do not print INFO and DEBUG */ #define XENLOG_GUEST_LOWER_THRESHOLD 0 /* Rate-limit ERR and WARNING */ #else -#define XENLOG_UPPER_THRESHOLD 4 /* Do not discard anything */ -#define XENLOG_LOWER_THRESHOLD 4 /* Print everything */ -#define XENLOG_GUEST_UPPER_THRESHOLD 4 /* Do not discard anything */ -#define XENLOG_GUEST_LOWER_THRESHOLD 4 /* Print everything */ +#define XENLOG_UPPER_THRESHOLD 5 /* Do not discard anything */ +#define XENLOG_LOWER_THRESHOLD 5 /* Print everything */ +#define XENLOG_GUEST_UPPER_THRESHOLD 5 /* Do not discard anything */ +#define XENLOG_GUEST_LOWER_THRESHOLD 5 /* Print everything */ #endif /* * The XENLOG_DEFAULT is the default given to printks that @@ -540,7 +540,7 @@ static int printk_prefix_check(char *p, char **pp) if ( loglvl == -1 ) loglvl = XENLOG_GUEST_DEFAULT; break; -case '0' ... '3': +case '0' ... '4': loglvl = p[1] - '0'; break; } @@ -554,7 +554,8 @@ static int printk_prefix_check(char *p, char **pp) return ((atomic_read(print_everything) != 0) || (loglvl lower_thresh) || -((loglvl upper_thresh) printk_ratelimit())); +((loglvl = lower_thresh loglvl upper_thresh) + printk_ratelimit())); } static void __init parse_console_timestamps(char *s) diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h index f7258c7..b2ce0fe 100644 --- a/xen/include/xen/config.h +++ b/xen/include/xen/config.h @@ -18,6 +18,8 @@ /* * The following log levels are as follows: * + * XENLOG_ERR_RATE_LIMIT: Rate limit error message from Xen and Guest + * * XENLOG_ERR: Fatal errors, either Xen, Guest or Dom0 * is about to crash. * @@ -41,11 +43,13 @@ */ #define XENLOG_ERR 0 #define XENLOG_WARNING 1 -#define XENLOG_INFO2 -#define XENLOG_DEBUG 3 +#define XENLOG_ERR_RATE_LIMIT 2 +#define XENLOG_INFO3 +#define XENLOG_DEBUG 4 #define XENLOG_GUEST G +#define XENLOG_G_ERR_RATE_LIMIT XENLOG_GUEST XENLOG_ERR_RATE_LIMIT #define XENLOG_G_ERR XENLOG_GUEST XENLOG_ERR #define XENLOG_G_WARNING XENLOG_GUEST XENLOG_WARNING #define XENLOG_G_INFOXENLOG_GUEST XENLOG_INFO -- 1.7.9.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/3] gnttab: clean up gnttab_set_version()
On 22/06/15 12:46, Jan Beulich wrote:
- drop pointless nr_grant_entries() check from loop over reserved
entries (adding suitable BUILD_BUG_ON()s to validate that)
- adjust types
- rename d to currd
- formatting
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com, with one suggestion.
@@ -2625,66 +2633,78 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARA
break;
}
-/* Preserve the first 8 entries (toolstack reserved grants) */
-if ( gt-gt_version == 1 )
-{
-memcpy(reserved_entries, shared_entry_v1(gt, 0),
sizeof(reserved_entries));
-}
-else if ( gt-gt_version == 2 )
+/* Preserve the first 8 entries (toolstack reserved grants). */
+switch ( gt-gt_version )
{
-for ( i = 0; i GNTTAB_NR_RESERVED_ENTRIES i
nr_grant_entries(gt); i++ )
+case 1:
+memcpy(reserved_entries, shared_entry_v1(gt, 0),
+ sizeof(reserved_entries));
+break;
+case 2:
+for ( i = 0; i GNTTAB_NR_RESERVED_ENTRIES; i++ )
{
-int flags = status_entry(gt, i);
-flags |= shared_entry_v2(gt, i).hdr.flags;
-if ((flags GTF_type_mask) == GTF_permit_access)
+unsigned int flags = shared_entry_v2(gt, i).hdr.flags;
+
+switch ( flags GTF_type_mask )
{
-reserved_entries[i].flags = flags;
+case GTF_permit_access:
+reserved_entries[i].flags = flags | status_entry(gt, i);
reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
reserved_entries[i].frame = shared_entry_v2(gt,
i).full_page.frame;
-}
-else
-{
-if ((flags GTF_type_mask) != GTF_invalid)
-gdprintk(XENLOG_INFO, d%d: bad flags %x in grant %d
when switching grant version\n,
- d-domain_id, flags, i);
+break;
+default:
+gdprintk(XENLOG_INFO,
+ bad flags %x in grant %u when switching version\n,
+ flags, i);
A 0x for flags, to avoid decimal confusion.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH v3 01/18] xen/arm: Add bitmap_find_next_zero_area helper function
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
bitmap_find_next_zero_area helper function will be used
by physical ITS driver imported from linux
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v3: Moved changes to xen/common/bitmap.c and
xen/include/xen/bitmap.h
---
xen/common/bitmap.c | 39 +++
xen/include/xen/bitmap.h |5 +
2 files changed, 44 insertions(+)
diff --git a/xen/common/bitmap.c b/xen/common/bitmap.c
index 61d1ea4..ba060b2 100644
--- a/xen/common/bitmap.c
+++ b/xen/common/bitmap.c
@@ -489,6 +489,45 @@ int bitmap_allocate_region(unsigned long *bitmap, int pos,
int order)
}
EXPORT_SYMBOL(bitmap_allocate_region);
+/*
+ * bitmap_find_next_zero_area - find a contiguous aligned zero area
+ * @map: The address to base the search on
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @align_mask: Alignment mask for zero area
+ *
+ * The @align_mask should be one less than a power of 2; the effect is that
+ * the bit offset of all zero areas this function finds is multiples of that
+ * power of 2. A @align_mask of 0 means no alignment is required.
+ */
+#define ALIGN_MASK(x, mask) (((x) + (mask)) ~(mask))
+
+unsigned long bitmap_find_next_zero_area(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask)
+{
+unsigned long index, end, i;
+again:
+index = find_next_zero_bit(map, size, start);
+
+/* Align allocation */
+index = ALIGN_MASK(index, align_mask);
+
+end = index + nr;
+if (end size)
+return end;
+i = find_next_bit(map, end, index);
+if (i end) {
+start = i + 1;
+goto again;
+}
+return index;
+}
+EXPORT_SYMBOL(bitmap_find_next_zero_area);
+
#ifdef __BIG_ENDIAN
void bitmap_long_to_byte(uint8_t *bp, const unsigned long *lp, int nbits)
diff --git a/xen/include/xen/bitmap.h b/xen/include/xen/bitmap.h
index e2a3686..5c48ac3 100644
--- a/xen/include/xen/bitmap.h
+++ b/xen/include/xen/bitmap.h
@@ -101,6 +101,11 @@ extern int bitmap_scnlistprintf(char *buf, unsigned int
len,
extern int bitmap_find_free_region(unsigned long *bitmap, int bits, int order);
extern void bitmap_release_region(unsigned long *bitmap, int pos, int order);
extern int bitmap_allocate_region(unsigned long *bitmap, int pos, int order);
+extern unsigned long bitmap_find_next_zero_area(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask);
#define BITMAP_LAST_WORD_MASK(nbits) \
( \
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] configure: check for argp
On Mon, Jun 22, 2015 at 11:55:44AM +0100, George Dunlap wrote: On 06/22/2015 11:45 AM, Wei Liu wrote: On Mon, Jun 22, 2015 at 11:12:27AM +0100, George Dunlap wrote: On 06/19/2015 09:58 AM, Roger Pau Monne wrote: argp is only present in the GNU C library, so add a specific check for it in configure. Also check if -largp is needed for linking against it. Please run autoconf after applying. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: George Dunlap george.dun...@eu.citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Cc: Olaf Hering o...@aepfle.de --- config/Tools.mk.in | 1 + tools/configure.ac | 4 tools/xentrace/Makefile | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/config/Tools.mk.in b/config/Tools.mk.in index aef9ed6..9bd5f6c 100644 --- a/config/Tools.mk.in +++ b/config/Tools.mk.in @@ -78,5 +78,6 @@ CONFIG_GCRYPT := @libgcrypt@ EXTFS_LIBS := @EXTFS_LIBS@ CURSES_LIBS := @CURSES_LIBS@ TINFO_LIBS := @TINFO_LIBS@ +ARGP_LDFLAGS:= @argp_ldflags@ FILE_OFFSET_BITS:= @FILE_OFFSET_BITS@ diff --git a/tools/configure.ac b/tools/configure.ac index 1a06ddf..5eb4799 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -356,6 +356,10 @@ AC_CHECK_LIB([yajl], [yajl_alloc], [], AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])]) AC_CHECK_LIB([iconv], [libiconv_open], [libiconv=y], [libiconv=n]) AC_SUBST(libiconv) +AC_CHECK_HEADER([argp.h], [ +AC_CHECK_LIB([argp], [argp_usage], [argp_ldflags=-largp]) +], [AC_MSG_ERROR([Could not find argp])]) +AC_SUBST(argp_ldflags) Sorry if my config-fu isn't very good: Is this basically requiring the user to have argp available at configure time? Does this make it more difficult to build on BSDs? Or is it just a matter of adding one more library to the already long list of dependencies? This is just to make that dependency explicit. This is a step towards the right direction. It's not going to make it easier or harder to build on BSDs. Well the reason I was asking is that if it would be a big hassle for someone building on BSDs to install the argp library, then a better option might to just not build xenalyze. On the other hand, if it's no more difficult than installing libyajl (or any of the other dozen dependencies), then adding a dependency is fine. And naturally in that case making the dependency explicit is the right thing to do. Yes, package argp exist in FreeBSD and NetBSD. Wei. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 10/10] x86/MSI-X: provide hypercall interface for mask-all control
On 19.06.15 at 16:07, roger@citrix.com wrote: I don't mind adding a PHYSDEVOP_pci_mmcfg_reserved call to FreeBSD, but for it to have any effect we need to stop unconditionally mapping everything as MMIO regions on PVH Dom0. Actually I don't think we need this as a prereq (it's rather a pretty orthogonal change, which I nevertheless agree should be carried out soon): Even if the kernel registered the MMCFG ranges, whether it maps them up front could be of no interest to Xen in the PVH case (in the PV case we'd need to search for mappings in page tables, so we wouldn't want to lift the ordering restriction). Xen could deal with the permission change in two ways: For one, MMIO ranges are 1:1 mapped, so it could brute force adjust the affected 2nd level paging entries. Alternatively we could (ab)use p2m_mmio_write_dm for the Dom0 case, and invoke p2m_change_entry_type_global(d, p2m_mmio_direct, p2m_mmio_write_dm) upon registration of an MMCFG range. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen: add a 'acpi_fake_s3' boot command line parameter
which, if provided, prevents the function that actually
put the system in ACPI S3 suspended state to be called.
The system will, therefore, go down the suspend path,
until the second to last step, and then resume right away.
This is useful when testing and debugging S3 suspend/resume
issues.
Signed-off-by: Ben Guthro b...@guthro.net
Signed-off-by: Dario Faggioli dario.faggi...@citrix.com
---
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper andrew.coop...@citrix.com
---
docs/misc/xen-command-line.markdown | 11 +++
xen/arch/x86/acpi/power.c |6 +-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index aa684c0..adbe9b5 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -110,6 +110,17 @@ domain 0 command line
Specify which ACPI MADT table to parse for APIC information, if more
than one is present.
+### acpi\_fake\_s3
+ `= boolean`
+
+ Default: `false`
+
+When ACPI S3 suspend is requested, perform all the operations necessary
+to achieve that, except the actual low level register writes that puts
+the system to sleep (hence the system resumes right away).
+
+This is useful for testing and debugging ACPI S3 suspend/resume issues.
+
### acpi\_pstate\_strict
`= boolean`
diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
index f41f0de..562d25a 100644
--- a/xen/arch/x86/acpi/power.c
+++ b/xen/arch/x86/acpi/power.c
@@ -33,6 +33,9 @@
uint32_t system_reset_counter = 1;
+static bool_t __read_mostly fake_s3 = 0;
+boolean_param(acpi_fake_s3, fake_s3);
+
static char __initdata opt_acpi_sleep[20];
string_param(acpi_sleep, opt_acpi_sleep);
@@ -177,7 +180,8 @@ static int enter_state(u32 state)
switch ( state )
{
case ACPI_STATE_S3:
-do_suspend_lowlevel();
+if ( likely(!fake_s3) )
+do_suspend_lowlevel();
system_reset_counter++;
error = tboot_s3_resume();
break;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/3] gnttab: clean up gnttab_set_version()
- drop pointless nr_grant_entries() check from loop over reserved
entries (adding suitable BUILD_BUG_ON()s to validate that)
- adjust types
- rename d to currd
- formatting
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -465,10 +465,16 @@ static unsigned int nr_grant_entries(str
{
switch ( gt-gt_version )
{
+#define f2e(nr, ver) (((nr) PAGE_SHIFT) / sizeof(grant_entry_v##ver##_t))
case 1:
-return (nr_grant_frames(gt) PAGE_SHIFT) / sizeof(grant_entry_v1_t);
+BUILD_BUG_ON(f2e(INITIAL_NR_GRANT_FRAMES, 1)
+ GNTTAB_NR_RESERVED_ENTRIES);
+return f2e(nr_grant_frames(gt), 1);
case 2:
-return (nr_grant_frames(gt) PAGE_SHIFT) / sizeof(grant_entry_v2_t);
+BUILD_BUG_ON(f2e(INITIAL_NR_GRANT_FRAMES, 2)
+ GNTTAB_NR_RESERVED_ENTRIES);
+return f2e(nr_grant_frames(gt), 2);
+#undef f2e
}
return 0;
@@ -2563,17 +2569,17 @@ static long
gnttab_set_version(XEN_GUEST_HANDLE_PARAM(gnttab_set_version_t) uop)
{
gnttab_set_version_t op;
-struct domain *d = current-domain;
-struct grant_table *gt = d-grant_table;
+struct domain *currd = current-domain;
+struct grant_table *gt = currd-grant_table;
grant_entry_v1_t reserved_entries[GNTTAB_NR_RESERVED_ENTRIES];
-long res;
-int i;
+int res;
+unsigned int i;
-if (copy_from_guest(op, uop, 1))
+if ( copy_from_guest(op, uop, 1) )
return -EFAULT;
res = -EINVAL;
-if (op.version != 1 op.version != 2)
+if ( op.version != 1 op.version != 2 )
goto out;
res = 0;
@@ -2581,10 +2587,12 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARA
goto out;
write_lock(gt-lock);
-/* Make sure that the grant table isn't currently in use when we
- change the version number, except for the first 8 entries which
- are allowed to be in use (xenstore/xenconsole keeps them mapped).
- (You need to change the version number for e.g. kexec.) */
+/*
+ * Make sure that the grant table isn't currently in use when we
+ * change the version number, except for the first 8 entries which
+ * are allowed to be in use (xenstore/xenconsole keeps them mapped).
+ * (You need to change the version number for e.g. kexec.)
+ */
for ( i = GNTTAB_NR_RESERVED_ENTRIES; i nr_grant_entries(gt); i++ )
{
if ( read_atomic(_active_entry(gt, i).pin) != 0 )
@@ -2604,7 +2612,7 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARA
{
case 1:
/* XXX: We could maybe shrink the active grant table here. */
-res = gnttab_populate_status_frames(d, gt, nr_grant_frames(gt));
+res = gnttab_populate_status_frames(currd, gt,
nr_grant_frames(gt));
if ( res 0)
goto out_unlock;
}
@@ -2625,66 +2633,78 @@ gnttab_set_version(XEN_GUEST_HANDLE_PARA
break;
}
-/* Preserve the first 8 entries (toolstack reserved grants) */
-if ( gt-gt_version == 1 )
-{
-memcpy(reserved_entries, shared_entry_v1(gt, 0),
sizeof(reserved_entries));
-}
-else if ( gt-gt_version == 2 )
+/* Preserve the first 8 entries (toolstack reserved grants). */
+switch ( gt-gt_version )
{
-for ( i = 0; i GNTTAB_NR_RESERVED_ENTRIES i
nr_grant_entries(gt); i++ )
+case 1:
+memcpy(reserved_entries, shared_entry_v1(gt, 0),
+ sizeof(reserved_entries));
+break;
+case 2:
+for ( i = 0; i GNTTAB_NR_RESERVED_ENTRIES; i++ )
{
-int flags = status_entry(gt, i);
-flags |= shared_entry_v2(gt, i).hdr.flags;
-if ((flags GTF_type_mask) == GTF_permit_access)
+unsigned int flags = shared_entry_v2(gt, i).hdr.flags;
+
+switch ( flags GTF_type_mask )
{
-reserved_entries[i].flags = flags;
+case GTF_permit_access:
+reserved_entries[i].flags = flags | status_entry(gt, i);
reserved_entries[i].domid = shared_entry_v2(gt, i).hdr.domid;
reserved_entries[i].frame = shared_entry_v2(gt,
i).full_page.frame;
-}
-else
-{
-if ((flags GTF_type_mask) != GTF_invalid)
-gdprintk(XENLOG_INFO, d%d: bad flags %x in grant %d when
switching grant version\n,
- d-domain_id, flags, i);
+break;
+default:
+gdprintk(XENLOG_INFO,
+ bad flags %x in grant %u when switching version\n,
+ flags, i);
+/* fall through */
+case GTF_invalid:
memset(reserved_entries[i], 0, sizeof(reserved_entries[i]));
+break;
}
}
+break;
}
if ( op.version 2 gt-gt_version == 2 )
-
Re: [Xen-devel] [PATCH] Modified RTDS scheduler to use an event-driven model instead of polling.
Thank you. This clears things up a bit. I will work on this model and make (or ignore) any corner case decisions I feel adequate for now. We can focus on them after the main structure is in place. ~Dagaen On Mon, Jun 22, 2015 at 5:11 AM, Dario Faggioli dario.faggi...@citrix.com wrote: On Thu, 2015-06-18 at 14:07 -0400, Dagaen Golomb wrote: Anyway, I've zero interest in turning this into a fight over terminology... If you want to call runq_tickle() the scheduler, go ahead, it would just make communication a bit more difficult, but I'm up for the challenge! :-) Oh, BTW, while we're here, __runq_pick() being called from a bunch of places, outside of rt_schedule(), is also something I never liked (you can go check that in the archives), and I also blame the confusion between scheduling and replenishmets, for the fact that such a thing is necessary. I seriously hope this can be fixed too. I have no interest in a terminology war either. I just figured that if we want the replenishment function to only tickle when necessary, then it should check that the replenished vCPU is a greater priority than current ones. Exactly, we need a preemption check, which is part of the 'scheduling logic'... but everything in the file is part of the scheduling logic (or it will be in another one), and we don't want to put everything that is in the file in one only function! :-) An in fact, a preemption check is not the full scheduling logic it's... well... a preemption check. For example, if there are idle pCPUs, it's something very quick. Note that, right now, this preemption check is done by acquiring the global lock and checking the deadlines of currently running vCPUs on all pCPUs. In future, this can be modified/improved, by using a dedicate data structure, and a locking scheme that would reduce the pressure on the global lock. I'm not saying that you should do this as part of the work you're doing now. Rather, I'm saying that the work being done now should go in the direction of making this easier, not harder. And in fact, I want __runq_pick() and related logic to be in rt_schedule(), and nowhere else, while I want runq_tickle() to be done from replenishment (and wakeup), and nowhere else. I guess the last remaining question is this: when the scheduler is enforcing a budget and times out, should it check for replenishment before kicking the vCPU? Or assume that any relevant replenishments have occurred? This is an implementation detail that is quite hard to discuss without seeing the code. In theory, if there wasn't any overhead, etc., you shouldn't, because it should not be necessary. In practise, yes, it is possible that various sources of overhead prevent a replenishment to be notified in time, and that you end up with a vCPU running, and consuming the last bits of its budget _after_ a scheduled replenishment instant as it is, I guess, possible that you figure during a replenishment that the budget was exhausted and the vCPU had overrun a bit, I guess (or not, it again depends on the actual implementation). So, yes, you certainly need to take care of this corner cases, and you can do it in the way you think it's best, basing on how the code ends up looking like. The important thing is that they're treated for what they are, i.e., we should handle them, not design the code around them. This is the issue I mentioned before about two timers armed at the same time - I'm not sure what convention Xen uses to order them. No, I don't think this has much to do with the internals of timers' implementation, it's a corner case that, due to overhead, long critical section (or, in general, interrupts-off sections), etc., will always be present and will need to be taken care of, no mater how the scheduler is implemented. I would assume from your very reason for mentioning this change that you don't want any replenishment in rt_schedule, but then it may kick a vCPU who at that very instant is supposed to be replenished as well, and should actually stay on the pCPU. That depends of the vCPU, on it's budget and deadline, and on what's running on other pCPUs. And that is something unlikely, although possible, and it should be the exception rather than the rule. Anyway, I think it would be correct, for instance, to check during rt_schedule() whether the vCPU running on the pCPU is already beyond it's deadline/replenishment time. If yes, log/count a deadline miss (because that's what just happened!), replenish it and continue with rt_schedule(). This is assuming you still want rt_schedule to be timer-triggered to enforce budget, is this correct? Of course. However, I think this is a more minor issue that we can sort out via inspecting the default Xen behavior, or allowing a single replenishment call before kicking (I don't expect you to like that option :P), or some other method. Exactly. Thanks and Regards, Dario -- This
[Xen-devel] [RFC PATCH v3 15/18] xen/arm: ITS: Add domain specific ITS initialization
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add Domain and vcpu specific ITS initialization
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3-its.c | 17
xen/arch/arm/setup.c |1 +
xen/arch/arm/vgic-v3-its.c| 45 +
xen/arch/arm/vgic-v3.c|1 +
xen/include/asm-arm/gic-its.h |3 +++
xen/include/asm-arm/vgic.h|1 +
6 files changed, 68 insertions(+)
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 4471669..8aa1ec5 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -1234,6 +1234,23 @@ static int its_force_quiescent(void __iomem *base)
}
}
+void its_domain_init(struct domain *d)
+{
+struct its_node *its;
+
+if ( is_hardware_domain(d) )
+{
+list_for_each_entry(its, its_nodes, entry)
+{
+/* XXX: Assign only first physical ITS address */
+d-arch.vits-phys_base = its-phys_base;
+d-arch.vits-phys_size = its-phys_size;
+break;
+}
+}
+/* TODO: DomU */
+}
+
static int its_probe(struct dt_device_node *node)
{
paddr_t its_addr, its_size;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 06f8e54..0c1081a 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -776,6 +776,7 @@ void __init start_xen(unsigned long boot_phys_offset,
init_xen_time();
gic_init();
+vgic_its_init();
p2m_vmid_allocator_init();
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 543db91..00e210f 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1174,6 +1174,51 @@ static const struct mmio_handler_ops
vgic_gits_mmio_handler = {
.write_handler = vgic_v3_gits_mmio_write,
};
+int vgic_its_domain_init(struct domain *d)
+{
+int i;
+
+d-arch.vits = xzalloc(struct vgic_its);
+if ( !d-arch.vits )
+return -ENOMEM;
+
+spin_lock_init(d-arch.vits-lock);
+
+d-arch.vits-collections = xzalloc_array(struct its_collection,
+ nr_cpu_ids);
+if ( !d-arch.vits-collections )
+return -ENOMEM;
+
+for ( i = 0; i nr_cpu_ids; i++ )
+d-arch.vits-collections[i].target_address = ~0UL;
+
+for ( i = 0; i GITS_BASER_NR_REGS; i++)
+{
+/* XXX: Fix this */
+if ( i == 0 )
+d-arch.vits-baser[i] = 0x1070c00;
+else
+d-arch.vits-baser[i] = 0x0;
+}
+
+d-arch.vits-dev_root = RB_ROOT;
+
+spin_lock_init(d-arch.vits[i].lock);
+
+its_domain_init(d);
+register_mmio_handler(d, vgic_gits_mmio_handler,
+ d-arch.vits-phys_base,
+ SZ_64K);
+
+return 0;
+}
+
+void vgic_its_init(void)
+{
+if ( gic_lpi_supported() )
+its_lpi_init(gic_nr_id_bits());
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 44922fb..abb1457 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1186,6 +1186,7 @@ static int vgic_v3_domain_init(struct domain *d)
d-arch.vgic.ctlr = VGICD_CTLR_DEFAULT;
+vgic_its_domain_init(d);
return 0;
}
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index c674b3f..7e25f5b 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -276,6 +276,9 @@ static inline uint32_t its_decode_devid(struct domain *d,
its_cmd_block *cmd)
int its_cpu_init(void);
int its_init(struct rdist_prop *rdist);
+void its_domain_init(struct domain *d);
+int its_lpi_init(u32 id_bits);
+int vgic_its_domain_init(struct domain *d);
void its_set_affinity(struct irq_desc *desc, int cpu);
void lpi_set_config(struct irq_desc *desc, int enable);
uint8_t vgic_its_get_priority(struct vcpu *v, uint32_t pid);
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index f8928ab..4509e9a 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -178,6 +178,7 @@ enum gic_sgi_mode;
#define vgic_num_irqs(d)((d)-arch.vgic.nr_spis + 32)
extern int domain_vgic_init(struct domain *d, unsigned int nr_spis);
+extern void vgic_its_init(void);
extern void domain_vgic_free(struct domain *d);
extern int vcpu_vgic_init(struct vcpu *v);
extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int irq);
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH v3 12/18] xen/arm: ITS: Add GICR register emulation
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Emulate LPI related changes to GICR registers
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/gic-v3.c | 15
xen/arch/arm/gic.c| 10 ++
xen/arch/arm/vgic-v3.c| 69 ++---
xen/include/asm-arm/domain.h |1 +
xen/include/asm-arm/gic-its.h |1 +
xen/include/asm-arm/gic.h |9 +
xen/include/asm-arm/gic_v3_defs.h |1 +
7 files changed, 94 insertions(+), 12 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 556b291..737646c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -683,6 +683,11 @@ static int __init gicv3_populate_rdist(void)
return -ENODEV;
}
+static int gicv3_dist_supports_lpis(void)
+{
+return readl_relaxed(GICD + GICD_TYPER) GICD_TYPER_LPIS_SUPPORTED;
+}
+
static int __cpuinit gicv3_cpu_init(void)
{
int i;
@@ -1304,10 +1309,20 @@ static int __init gicv3_init(void)
gicv3.rdist_regions[0].size, gicv3.rdist_regions[0].map_base,
gicv3_info.maintenance_irq);
+reg = readl_relaxed(GICD + GICD_TYPER);
+
+gicv3.rdist_data.id_bits = ((reg 19) 0x1f) + 1;
+gicv3_info.nr_id_bits = gicv3.rdist_data.id_bits;
+
spin_lock_init(gicv3.lock);
spin_lock(gicv3.lock);
+if ( gicv3_dist_supports_lpis() )
+gicv3_info.lpi_supported = 1;
+else
+gicv3_info.lpi_supported = 0;
+
gicv3_dist_init();
res = gicv3_cpu_init();
gicv3_hyp_init();
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index c41e82e..cfc9c42 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -67,6 +67,16 @@ unsigned int gic_number_lines(void)
return gic_hw_ops-info-nr_lines;
}
+unsigned int gic_nr_id_bits(void)
+{
+return gic_hw_ops-info-nr_id_bits;
+}
+
+bool_t gic_lpi_supported(void)
+{
+return gic_hw_ops-info-lpi_supported;
+}
+
void gic_save_state(struct vcpu *v)
{
ASSERT(!local_irq_is_enabled());
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 4af5a84..44922fb 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -30,6 +30,7 @@
#include asm/mmio.h
#include asm/gic_v3_defs.h
#include asm/gic.h
+#include asm/gic-its.h
#include asm/vgic.h
/* GICD_PIDRn register values for ARM implementations */
@@ -93,8 +94,15 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v,
mmio_info_t *info,
switch ( gicr_reg )
{
case GICR_CTLR:
-/* We have not implemented LPI's, read zero */
-goto read_as_zero_32;
+/*
+ * Enable LPI's for ITS. Direct injection of LPI
+ * by writing to GICR_{SET,CLR}LPIR are not supported
+ */
+if ( dabt.size != DABT_WORD ) goto bad_width;
+vgic_lock(v);
+*r = v-domain-arch.vgic.gicr_ctlr;
+vgic_unlock(v);
+return 1;
case GICR_IIDR:
if ( dabt.size != DABT_WORD ) goto bad_width;
*r = GICV3_GICR_IIDR_VAL;
@@ -106,6 +114,10 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v,
mmio_info_t *info,
MPIDR_AFFINITY_LEVEL(v-arch.vmpidr, 2) 48 |
MPIDR_AFFINITY_LEVEL(v-arch.vmpidr, 1) 40 |
MPIDR_AFFINITY_LEVEL(v-arch.vmpidr, 0) 32);
+/* Set LPI support */
+aff |= (GICR_TYPER_DISTRIBUTED_IMP | GICR_TYPER_PLPIS);
+/* GITS_TYPER.PTA is 0. Provice vcpu number as ta */
+aff |= (v-vcpu_id GICR_TYPER_PROCESSOR_SHIFT);
*r = aff;
if ( v-arch.vgic.flags VGIC_V3_RDIST_LAST )
@@ -125,11 +137,13 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v,
mmio_info_t *info,
/* WO. Read as zero */
goto read_as_zero_64;
case GICR_PROPBASER:
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
+/* Remove shareability attribute we don't want dom to flush */
+*r = v-domain-arch.vits-propbase;
+return 1;
case GICR_PENDBASER:
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( dabt.size != DABT_DOUBLE_WORD ) goto bad_width;
+*r = v-domain-arch.vits-pendbase[v-vcpu_id];
case GICR_INVLPIR:
/* WO. Read as zero */
goto read_as_zero_64;
@@ -203,8 +217,15 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v,
mmio_info_t *info,
switch ( gicr_reg )
{
case GICR_CTLR:
-/* LPI's not implemented */
-goto write_ignore_32;
+/*
+ * Enable LPI's for ITS. Direct injection of LPI
+ * by writing to GICR_{SET,CLR}LPIR are not supported
+ */
+if ( dabt.size != DABT_WORD ) goto bad_width;
+vgic_lock(v);
+v-domain-arch.vgic.gicr_ctlr = (*r) GICR_CTL_ENABLE;
+vgic_unlock(v);
+return 1;
case GICR_IIDR:
/* RO */
[Xen-devel] [RFC PATCH v3 17/18] xen/arm: ITS: Generate ITS node for Dom0
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Parse host dt and generate ITS node for Dom0.
ITS node resides inside GIC node so when GIC node
is encountered look for ITS node.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/domain_build.c | 50 +++-
xen/arch/arm/gic-v3-its.c | 57 +
xen/include/asm-arm/gic-its.h |2 ++
3 files changed, 108 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index e9cb8a9..0de5a8b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -20,6 +20,7 @@
#include asm/cpufeature.h
#include asm/gic.h
+#include asm/gic-its.h
#include xen/irq.h
#include kernel.h
@@ -803,6 +804,34 @@ static int make_cpus_node(const struct domain *d, void
*fdt,
return res;
}
+static int make_its_node(const struct domain *d, void *fdt,
+ const struct dt_device_node *node)
+{
+int res = 0;
+
+DPRINT(Create GIC ITS node\n);
+
+res = its_make_dt_node(d, node, fdt);
+if ( res )
+return res;
+
+/*
+ * The value of the property phandle in the property interrupts
+ * to know on which interrupt controller the interrupt is wired.
+ */
+if ( node-phandle )
+{
+DPRINT( Set phandle = 0x%x\n, node-phandle);
+res = fdt_property_cell(fdt, phandle, node-phandle);
+if ( res )
+return res;
+}
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
static int make_gic_node(const struct domain *d, void *fdt,
const struct dt_device_node *node)
{
@@ -1119,7 +1148,13 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
DT_MATCH_TIMER,
{ /* sentinel */ },
};
+static const struct dt_device_match gits_matches[] __initconst =
+{
+DT_MATCH_GIC_ITS,
+{ /* sentinel */ },
+};
struct dt_device_node *child;
+struct dt_device_node *gic_child;
int res;
const char *name;
const char *path;
@@ -1143,7 +1178,20 @@ static int handle_node(struct domain *d, struct
kernel_info *kinfo,
/* Replace these nodes with our own. Note that the original may be
* used_by DOMID_XEN so this check comes first. */
if ( device_get_class(node) == DEVICE_GIC )
-return make_gic_node(d, kinfo-fdt, node);
+{
+if ( !make_gic_node(d, kinfo-fdt, node) )
+{
+dt_for_each_child_node(node, gic_child)
+{
+if ( gic_child != NULL )
+{
+if ( dt_match_node(gits_matches, gic_child) )
+return make_its_node(d, kinfo-fdt, gic_child);
+}
+}
+}
+return 0;
+}
if ( dt_match_node(timer_matches, node) )
return make_timer_node(d, kinfo-fdt, node);
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 8aa1ec5..fc853d4 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -27,6 +27,8 @@
#include xen/sched.h
#include xen/errno.h
#include xen/delay.h
+#include xen/device_tree.h
+#include xen/libfdt/libfdt.h
#include xen/list.h
#include xen/sizes.h
#include xen/vmap.h
@@ -1205,6 +1207,61 @@ static void its_cpu_init_collection(void)
spin_unlock(its_lock);
}
+int its_make_dt_node(const struct domain *d,
+ const struct dt_device_node *node, void *fdt)
+{
+struct its_node *its;
+const struct dt_device_node *gic;
+const void *compatible = NULL;
+u32 len;
+__be32 *new_cells, *tmp;
+int res = 0;
+
+/* Will pass only first ITS node info */
+/* TODO: Handle multi node */
+its = list_first_entry(its_nodes, struct its_node, entry);
+if ( !its )
+{
+dprintk(XENLOG_ERR, ITS node not found\n);
+return -FDT_ERR_XEN(ENOENT);
+}
+
+gic = its-dt_node;
+
+compatible = dt_get_property(gic, compatible, len);
+if ( !compatible )
+{
+dprintk(XENLOG_ERR, Can't find compatible property for the its
node\n);
+return -FDT_ERR_XEN(ENOENT);
+}
+
+res = fdt_begin_node(fdt, gic-its);
+if ( res )
+return res;
+
+res = fdt_property(fdt, compatible, compatible, len);
+if ( res )
+return res;
+
+res = fdt_property(fdt, msi-controller, NULL, 0);
+if ( res )
+return res;
+
+len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+
+new_cells = xzalloc_bytes(len);
+if ( new_cells == NULL )
+return -FDT_ERR_XEN(ENOMEM);
+tmp = new_cells;
+
+dt_set_range(tmp, node, its-phys_base, its-phys_size);
+
+res = fdt_property(fdt, reg, new_cells, len);
+xfree(new_cells);
+
+return res;
+}
+
static int its_force_quiescent(void __iomem *base)
{
u32 count = 100; /* 1s */
diff --git
[Xen-devel] [RFC PATCH v3 18/18] xen/arm: ITS: Map ITS translation space
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
ITS translation space contains GITS_TRANSLATOR
register which is written by device to raise
LPI. This space needs to mapped to every domain
address space for all physical ITS available,
so that device can access GITS_TRANSLATOR
register using SMMU.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/vgic-v3-its.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 00e210f..7cf029a 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1174,6 +1174,36 @@ static const struct mmio_handler_ops
vgic_gits_mmio_handler = {
.write_handler = vgic_v3_gits_mmio_write,
};
+/*
+ * Map the 64K ITS translation space in guest.
+ * This is required purely for device smmu writes.
+*/
+
+//static int vgic_map_translation_space(uint32_t nr_its, struct domain *d)
+static int vgic_map_translation_space(struct domain *d)
+{
+uint64_t addr, size;
+int ret;
+
+addr = d-arch.vits-phys_base + SZ_64K;
+size = SZ_64K;
+
+ret = map_mmio_regions(d,
+ paddr_to_pfn(addr PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr PAGE_MASK));
+
+ if ( ret )
+ {
+ dprintk(XENLOG_G_ERR, vITS: Unable to map to dom%d access to
+ 0x%PRIx64 - 0x%PRIx64\n,
+ d-domain_id,
+ addr PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+ }
+
+return ret;
+}
+
int vgic_its_domain_init(struct domain *d)
{
int i;
@@ -1210,7 +1240,7 @@ int vgic_its_domain_init(struct domain *d)
d-arch.vits-phys_base,
SZ_64K);
-return 0;
+return vgic_map_translation_space(d);
}
void vgic_its_init(void)
--
1.7.9.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing test] 58818: regressions - FAIL
flight 58818 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58818/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 58451 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-sedf-pin 15 guest-start/debian.repeat fail in 58790 pass in 58818 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 58790 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt 11 guest-start fail like 58530 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 58530 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a build-amd64-rumpuserxen 6 xen-buildfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-xl-credit2 6 xen-boot fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass version targeted for testing: xen de53397e342682dfe37d569a137007067a86b768 baseline version: xen 05ab7714ff84003b9b4542d7816b4651efb67679 People who touched revisions under test: Alan Robinson alan.robin...@ts.fujitsu.com Andrew Cooper andrew.coop...@citrix.com Dario Faggioli dario.faggi...@citrix.com Dietmar Hahn dietmar.h...@ts.fujitsu.com Don Dugger donald.d.dug...@intel.com George Dunlap george.dun...@eu.citrix.com Ian Campbell ian.campb...@citrix.com Jan Beulich jbeul...@suse.com Juergen Gross jgr...@suse.com Kevin Tian kevin.t...@intel.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Roger Pau Monné roger@citrix.com Ross Lagerwall ross.lagerw...@citrix.com jobs: build-amd64-xend pass build-i386-xend pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl 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 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale
Re: [Xen-devel] Interested in taking up a project
On Sun, 2015-06-21 at 06:37 +, Abhinav Gupta wrote: Hii, I'm still waiting for the confirmation. Have started looking into the code though. There's not much to confirm. The page with the list of development project may require a bit of refreshing, but, as far as I know, that item is not being worked on by anyone, and it is still something that could be interesting (it's possible that George has different information/opinion, but I don't think so). As this is in Linux since a while, I think it may be worth having a look at how it's used there these days, what's the interface, if there have been tools built upon the driver, etc. It won't be possible to share kernel code (it'll be hypervisor for us), but, as stated in the description, it would be good to check whether we can share and/or be compatible at higher layers. Just some random links: https://www.kernel.org/doc/Documentation/thermal/intel_powerclamp.txt https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon https://wiki.ubuntu.com/Kernel/PowerManagement/ThermalIssues https://wiki.archlinux.org/index.php/CPU_frequency_scaling Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 9/9] libxc/x86/pvh: Allow creation of 32b PVH guests
On Fri, 2015-06-19 at 23:09 -0400, Boris Ostrovsky wrote: Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com CC: Ian Jackson ian.jack...@eu.citrix.com CC: 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] Interested in taking up a project
On 06/21/2015 07:37 AM, Abhinav Gupta wrote: Hii, I'm still waiting for the confirmation. Have started looking into the code though. Hey Abhinav, Thanks for your interest! As others have said, it's a free world, so of course you can work on and attempt to contribute whatever you want. :-) There's nobody else working on this yet, and it's probably still a good idea, so in that sense, the project is something that you should feel free to start working on. I don't have time at the moment to commit to the level of mentorship I would if you were a GSoC intern; but as a community, we're generally pretty good about helping people who try to get involved -- as you've already found out. :-) One heads-up: A thing we've started doing in our community, before submitting a large new feature, is to post a design document describing the purpose of the new feature, and a technical overview of the changes that you want to make and why. This is *not required*; you are free to just submit patches with your changes, and many people do. However, it's not uncommon for maintainers to request significant changes to the architecture or approach on major features, which require a major re-write. This can be frustrating both for you and for us. Done properly, a design document can make things easier for all of us. Looking forward to seeing your work! -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] configure: check for argp
On 06/19/2015 09:58 AM, Roger Pau Monne wrote: argp is only present in the GNU C library, so add a specific check for it in configure. Also check if -largp is needed for linking against it. Please run autoconf after applying. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: George Dunlap george.dun...@eu.citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Cc: Olaf Hering o...@aepfle.de --- config/Tools.mk.in | 1 + tools/configure.ac | 4 tools/xentrace/Makefile | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/config/Tools.mk.in b/config/Tools.mk.in index aef9ed6..9bd5f6c 100644 --- a/config/Tools.mk.in +++ b/config/Tools.mk.in @@ -78,5 +78,6 @@ CONFIG_GCRYPT := @libgcrypt@ EXTFS_LIBS := @EXTFS_LIBS@ CURSES_LIBS := @CURSES_LIBS@ TINFO_LIBS := @TINFO_LIBS@ +ARGP_LDFLAGS:= @argp_ldflags@ FILE_OFFSET_BITS:= @FILE_OFFSET_BITS@ diff --git a/tools/configure.ac b/tools/configure.ac index 1a06ddf..5eb4799 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -356,6 +356,10 @@ AC_CHECK_LIB([yajl], [yajl_alloc], [], AC_CHECK_LIB([z], [deflateCopy], [], [AC_MSG_ERROR([Could not find zlib])]) AC_CHECK_LIB([iconv], [libiconv_open], [libiconv=y], [libiconv=n]) AC_SUBST(libiconv) +AC_CHECK_HEADER([argp.h], [ +AC_CHECK_LIB([argp], [argp_usage], [argp_ldflags=-largp]) +], [AC_MSG_ERROR([Could not find argp])]) +AC_SUBST(argp_ldflags) Sorry if my config-fu isn't very good: Is this basically requiring the user to have argp available at configure time? Does this make it more difficult to build on BSDs? Or is it just a matter of adding one more library to the already long list of dependencies? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
